Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed

[Karsten Merker]

Control: tags -1 upstream
X-Debbugs-CC: debian-ri...@lists.debian.org

On Wed, Jan 11, 2023 at 09:21:42AM -0800 Vagrant Cascadian wrote:

> Definitely would be good to mention to upstream. Please Cc me if you do!

I've sent the bugreport upstream:
https://lists.denx.de/pipermail/u-boot/2023-January/504466.html

Regards,
Karsten
-- 
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed

[Karsten Merker]

X-Debbugs-CC: debian-ri...@lists.debian.org

On Tue, Jan 10, 2023 at 09:22:02PM +0100 Karsten Merker wrote:

> I've also taken a look at the u-boot changelogs and there have
> been quite a few changes concerning u-boot's handling of
> device-trees between the working and the non-working versions. 
> Unfortunately I'm not familiar enough with the inner workings of
> u-boot to understand the implications of several of these
> changes.

Hello,

I've tried narrowing down the source of the issue by using
git bisect on the u-boot tree and that has resulted in
the following commit as the potential culprit:

  commit a56f663f07073713042bb0fd08053aeb667e717b
  Author: Simon Glass 
  Date:   Thu Oct 20 18:23:14 2022 -0600

vbe: Add info about the VBE device to the fwupd node

At present we put the driver in the /chosen node in U-Boot. This is a bit
strange, since U-Boot doesn't normally use that node itself. It is better
to put it under the bootstd node.

To make this work we need to copy create the node under /chosen when
fixing up the device tree. Copy over all the properties so that fwupd
knows what to do.

Update the sandbox device tree accordingly.

Signed-off-by: Simon Glass 

I'm not sure whether this is the actual culprit or just an
operation that happens to expose a problem elsewhere, though.
I'm inclined to forward the bug report to u-boot upstream unless
somebody has another idea how to get this narrowed down further.

Regards,
Karsten
-- 
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed

[Karsten Merker]

Control: found -1 2023.01+dfsg-1
X-Debbugs-CC: debian-ri...@lists.debian.org

On Tue, Jan 10, 2023 at 09:23:04AM -0800 Vagrant Cascadian wrote:
> On 2023-01-10, Cheng Li wrote:
[...]
> > Moving Image from 0x8400 to 0x8020, end=815d8000
> > ## Flattened Device Tree blob at ff733ef0
> >     Booting using the fdt blob at 0xff733ef0
> > Working FDT set to ff733ef0
> >     Using Device Tree in place at ff733ef0, end ff738dd2
> > Working FDT set to ff733ef0
> > ERROR: fdt fixup event failed: -22
> >   - must RESET the board to recover.
> >
> > FDT creation failed! hanging...### ERROR ### Please RESET the board ###
> 
> I wonder if this is relevent?
> 
>   docs/firmware: Update FW_JUMP documentation
>   
> https://github.com/riscv-software-src/opensbi/commit/7105c189f67028ef73720d7e9816c800ab53dda5
> 
> Basically changing the address offsets to avoid clobbering one another...

Hello,

some clobbering could indeed be the source of the problem, though
I currently fail to see why that would happen.  When running the
objdump dance on the working u-boot 2022.10, this gives me the
following address blocks:

0x802001a4
0x80200e60
0x80259bbc
0x80275a38
0x802769d1
0x802770c8
0x802778b8
0x80283d60
0x80283e70
0x80284628
0x80287f88
0x80288138
0x8029c2b0
0x8029d9a8
0x802a8008

On the non-working u-boot 2023.01 that is in unstable since today
this gives me

0x802001a4
0x80200e70
0x8025a604
0x802762f4
0x802772e8
0x802779ec
0x802781f4
0x802847a8
0x802848b8
0x80285098
0x80288a08
0x80288bb8
0x8029cf40
0x8029e6b0
0x802a8d08

i.e. the used area is a little bit larger in the non-working case, but still
way below one MB.  On the other hand OpenSBI's ./platform/generic/config.mk
contains

  FW_JUMP_FDT_ADDR=$(shell printf "0x%X" $$(($(FW_TEXT_START) + 0x220)))

i.e. AIUI it reserves an area of 0x220 bytes (34MB) for it's payload, so
there should be plenty of space and no clobbering should occur.


I've also taken a look at the u-boot changelogs and there have
been quite a few changes concerning u-boot's handling of
device-trees between the working and the non-working versions. 
Unfortunately I'm not familiar enough with the inner workings of
u-boot to understand the implications of several of these
changes.

Regards,
Karsten
-- 
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed

[Karsten Merker]

Source: u-boot
Version: 2023.01~rc4+dfsg-2
Severity: important
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-CC: debian-ri...@lists.debian.org

Hello,

when booting a riscv64 VM in qemu 1:7.0+dfsg-1 with OpenSBI 1.1-2
and u-boot-qemu 2023.01~rc4+dfsg-2 with the following commandline

  qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios 
/usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel 
/usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object 
rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 
-append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device 
virtio-blk-device,drive=hd0 -drive file=riscv64.img,format=raw,id=hd0 -device 
virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::2-:22

the following error occurs:

-8<--8<--8<--8<--8<-

OpenSBI v1.1
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name : riscv-virtio,qemu
Platform Features : medeleg
Platform HART Count   : 4
Platform IPI Device   : aclint-mswi
Platform Timer Device : aclint-mtimer @ 1000Hz
Platform Console Device   : uart8250
Platform HSM Device   : ---
Platform Reboot Device: sifive_test
Platform Shutdown Device  : sifive_test
Firmware Base : 0x8000
Firmware Size : 312 KB
Runtime SBI Version   : 1.0

Domain0 Name  : root
Domain0 Boot HART : 2
Domain0 HARTs : 0*,1*,2*,3*
Domain0 Region00  : 0x0200-0x0200 (I)
Domain0 Region01  : 0x8000-0x8007 ()
Domain0 Region02  : 0x-0x (R,W,X)
Domain0 Next Address  : 0x8020
Domain0 Next Arg1 : 0x8220
Domain0 Next Mode : S-mode
Domain0 SysReset  : yes

Boot HART ID  : 2
Boot HART Domain  : root
Boot HART Priv Version: v1.12
Boot HART Base ISA: rv64imafdch
Boot HART ISA Extensions  : time,sstc
Boot HART PMP Count   : 16
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Count  : 16
Boot HART MIDELEG : 0x1666
Boot HART MEDELEG : 0x00f0b509


U-Boot 2023.01-rc4+dfsg-2 (Jan 06 2023 - 03:38:24 +)

CPU:   rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc
Model: riscv-virtio,qemu
DRAM:  8 GiB
Core:  31 devices, 15 uclasses, devicetree: board
Flash: 32 MiB
Loading Environment from nowhere... OK
In:serial@1000
Out:   serial@1000
Err:   serial@1000
Net:   eth0: virtio-net#2
Working FDT set to ff7344b0
Hit any key to stop autoboot:  0 

Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 102400.0 MB = 100.0 GB (209715200 x 512)
... is now current device
Scanning virtio 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
U-Boot menu
1:  Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
2:  Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target)
3:  Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64
4:  Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target)
5:  Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64
6:  Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target)
Enter choice: 1:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
Retrieving file: /boot/initrd.img-6.1.0-1-riscv64
Retrieving file: /boot/vmlinux-6.1.0-1-riscv64
append: root=/dev/vda1 rw noquiet
Moving Image from 0x8400 to 0x8020, end=815e5000
## Flattened Device Tree blob at ff7344b0
   Booting using the fdt blob at 0xff7344b0
Working FDT set to ff7344b0
   Using Device Tree in place at ff7344b0, end ff738dea
Working FDT set to ff7344b0
ERROR: fdt fixup event failed: -22
 - must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###

-8<--8<--8<--8<--8<-

The source of the issue seems to be in u-boot as with u-boot-qemu
2022.10+dfsg-2 (the previous u-boot release in Debian/sid)
everything works without problems (boot log below).

The problem appears to be independent from the kernel image that
gets booted - all three installed kernels boot fine with
u-boot-qemu 2022.10+dfsg-2 but trying to boot any of them
with u-boot-qemu 2023.01~rc4+dfsg-2 shows the above error.

I've also tested the previous u-boot 2023.01 release candidates
from experimental (2023.01-rc2+dfsg-1 and 2023.01-rc3+dfsg-1) and
they show the same behaviour as 2023.01~rc4+dfsg-2.


For comparison, a working boot process with u-boot-qemu
2022.10+dfsg-2:

Bug#962917: libatomic-ops: FTBFS in the testsuite on riscv64 due to missing -pthread

[Karsten Merker]

On Sat, Jun 20, 2020 at 12:20:14AM +0300, Ivan Maidanski wrote:

> Please disregard my previous patch, and use the following one:
> https://github.com/ivmai/libatomic_ops/commit/f067c258d5df3dc364857c11718be4516ca73ea0.patch
>  
> Karsten, could you please test it?

Hello,

will do, but it will probably take some days.  Yesterday my computer's
system drive started showing massive malfunctions and I'm currently
waiting for a replacement to be delivered so that I can get the system
up again.

Regards,
Karsten
-- 
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

Bug#962917: libatomic-ops: FTBFS in the testsuite on riscv64 due to missing -pthread

[Karsten Merker]

control: severity 962917 important
control: tags 962917 patch

On Tue, Jun 16, 2020 at 12:40:52AM +0200, Karsten Merker wrote:

> libatomic-ops FTBFS on riscv64 due to link failures in the
> testsuite. The build log is available at
> 
>   
> https://buildd.debian.org/status/fetch.php?pkg=libatomic-ops=riscv64=7.6.10-1=1588631725=0
> 
> The source of the link failures is that the tests aren't built
> with the "-pthread" compiler flag.
> 
> Some architectures such as risc64 have native atomics support,
> but only for word-sized operands and not for smaller entities. 
> When called with "-pthread", gcc automatically links in the
> necessary wrapper functions to provide the missing atomic
> operations on those architectures, but this doesn't happen when
> one just links in libpthread with "-lpthread".
> 
> Building the tests with "-pthread" in CFLAGS solves the build
> failures. It would be great if you could upload a new version
> of the package with a corresponding change.

Hello,

attached is a corresponding patch. If the patch is ok for you and
you would like me to perform an NMU, just let me know.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
>From 2c4627e01637b6e2b4ad3c7d8b8ed92ff020e92b Mon Sep 17 00:00:00 2001
From: Karsten Merker 
Date: Wed, 17 Jun 2020 20:34:06 +0200
Subject: [PATCH] Fix FTFBS in the testsuite on riscv64

---
 debian/changelog |  9 +
 .../libatomic-ops-enable-pthread-in-tests.diff   | 12 
 debian/patches/series|  1 +
 3 files changed, 22 insertions(+)
 create mode 100644 debian/patches/libatomic-ops-enable-pthread-in-tests.diff
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index 2731759..a0c6b39 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libatomic-ops (7.6.10-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTFBS in the testsuite on riscv64 by adding "-pthread" to
+the testsuite's CFLAGS and thereby making sure that gcc enables
+full atomics support on all platforms. (Closes: #962917)
+
+ -- Karsten Merker   Wed, 17 Jun 2020 19:37:31 +0200
+
 libatomic-ops (7.6.10-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/patches/libatomic-ops-enable-pthread-in-tests.diff b/debian/patches/libatomic-ops-enable-pthread-in-tests.diff
new file mode 100644
index 000..9e6891b
--- /dev/null
+++ b/debian/patches/libatomic-ops-enable-pthread-in-tests.diff
@@ -0,0 +1,12 @@
+diff -Nur libatomic-ops-7.6.10.orig/tests/Makefile.am libatomic-ops-7.6.10/tests/Makefile.am
+--- libatomic-ops-7.6.10.orig/tests/Makefile.am
 libatomic-ops-7.6.10/tests/Makefile.am
+@@ -10,7 +10,7 @@
+ -I$(top_builddir)/src -I$(top_srcdir)/src \
+ -I$(top_builddir)/tests -I$(top_srcdir)/tests
+ 
+-CFLAGS += $(CFLAGS_EXTRA)
++CFLAGS += $(CFLAGS_EXTRA) -pthread
+ 
+ TESTS = test_atomic$(EXEEXT) test_atomic_generalized$(EXEEXT) \
+ test_stack$(EXEEXT) test_malloc$(EXEEXT)
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..6bd8bef
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+libatomic-ops-enable-pthread-in-tests.diff
-- 
2.20.1

Bug#962917: libatomic-ops: FTBFS in the testsuite on riscv64 due to missing -pthread

[Karsten Merker]

Source: libatomic-ops
Version: 7.6.10-1
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

libatomic-ops FTBFS on riscv64 due to link failures in the
testsuite. The build log is available at

  
https://buildd.debian.org/status/fetch.php?pkg=libatomic-ops=riscv64=7.6.10-1=1588631725=0

The source of the link failures is that the tests aren't built
with the "-pthread" compiler flag.

Some architectures such as risc64 have native atomics support,
but only for word-sized operands and not for smaller entities. 
When called with "-pthread", gcc automatically links in the
necessary wrapper functions to provide the missing atomic
operations on those architectures, but this doesn't happen when
one just links in libpthread with "-lpthread".

Building the tests with "-pthread" in CFLAGS solves the build
failures. It would be great if you could upload a new version
of the package with a corresponding change.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.

Bug#933603: linux 5.2.1-1~exp1: riscv64 updates, including a FTBFS fix

[Karsten Merker]

Source: linux
Severity: important
Tags: patch

Hello,

current git master for src:linux FTBFS on riscv64.  Recently
CONFIG_LOAD_UEFI_KEYS has been enabled in the top-level kernel
config fragment (debian/config/config), but this option depends
on EFI support which is not yet available on riscv64.
Therefore CONFIG_LOAD_UEFI_KEYS must be disabled in the
architecture-specific config, otherwise the package fails to
build on riscv64 due to undefined symbols.

I have created a merge request on salsa that addresses this issue
and also provides some other riscv64-related updates:

  [riscv64] Backport kernel image header support from kernel 5.3
  [riscv64] Enable clock drivers for the SiFive FU540
  [riscv64] Enable SiFive UART and UART console support
  [riscv64] Disable CONFIG_LOAD_UEFI_KEYS for riscv64 (fixes FTBFS)

https://salsa.debian.org/kernel-team/linux/merge_requests/161/commits

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.

Bug#928735: u-boot-menu: Avoid hard-coding "vmlinuz"

[Karsten Merker]

On Thu, 09 May 2019, Vagrant Cascadian  wrote:

> Package: u-boot-menu
> Severity: normal
> Version: 3
> Tags: patch
> 
> Some architectures which might make use of u-boot-menu do not have
> kernel files matching "vmlinuz" (e.g. riscv64 has "vmlinux").
> 
> The attached patch uses "linux-version list --paths" to output the path
> of each versioned kernel, which outputs the matching kernel filenames.

Hello,

may I kindly ping you on this bugreport?  I'm working on d-i
support for riscv64 and would like to use the u-boot-menu package
there, but without Vagrant's patch it isn't usable on riscv64
(and on quite a number of other architectures as well, please see
below).  It would be great if you could upload a new version of
u-boot-menu with the patch applied to unstable.  If you are ok
with the patch but don't have time for preparing an upload, I
would offer doing an NMU if that would be ok for you.

An overview of vmlinuz- vs. vmlinux-using Debian architectures:

vmlinuz: alpha, amd64, arm64, armel, armhf, hppa, i386, ia64,
 s390x, sh4

vmlinux: m68k, mips{,64}{,r6}{,el}, powerpc, powerpcspe, ppc64,
 ppc64el, riscv64, sparc64

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.

Bug#928832: elfutils: diff for NMU version 0.176-1.1

[Karsten Merker]

Control: tags 928832 + pending

Dear maintainer,

as previously discussed I've prepared an NMU for elfutils
(versioned as 0.176-1.1) and will upload it shortly.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
diff -Nru elfutils-0.176/debian/changelog elfutils-0.176/debian/changelog
--- elfutils-0.176/debian/changelog	2019-02-16 14:54:50.0 +0100
+++ elfutils-0.176/debian/changelog	2019-05-28 20:53:12.0 +0200
@@ -1,3 +1,10 @@
+elfutils (0.176-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload with maintainer permission
+  * Fixes FTBFS on riscv64 (Closes: #928832)
+
+ -- Karsten Merker   Tue, 28 May 2019 20:53:12 +0200
+
 elfutils (0.176-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru elfutils-0.176/debian/control elfutils-0.176/debian/control
--- elfutils-0.176/debian/control	2018-06-24 20:54:48.0 +0200
+++ elfutils-0.176/debian/control	2019-05-28 20:52:01.0 +0200
@@ -1,7 +1,7 @@
 Source: elfutils
 Priority: optional
 Maintainer: Kurt Roeckx 
-Build-Depends: debhelper (>= 9), autotools-dev, autoconf, automake, bzip2, zlib1g-dev, zlib1g-dev:native, libbz2-dev, liblzma-dev, m4, gettext, autoconf, automake, gawk, dpkg-dev (>= 1.16.1~), gcc-multilib [any-amd64 sparc64] , libc6-dbg [powerpc powerpcspe ppc64 ppc64el armel armhf arm64 sparc64], flex, bison
+Build-Depends: debhelper (>= 9), autotools-dev, autoconf, automake, bzip2, zlib1g-dev, zlib1g-dev:native, libbz2-dev, liblzma-dev, m4, gettext, autoconf, automake, gawk, dpkg-dev (>= 1.16.1~), gcc-multilib [any-amd64 sparc64] , libc6-dbg [powerpc powerpcspe ppc64 ppc64el armel armhf arm64 sparc64 riscv64], flex, bison
 Build-Conflicts: autoconf2.13, automake1.4
 Standards-Version: 4.1.0
 Section: libs
diff -Nru elfutils-0.176/debian/patches/riscv-retval-workaround.patch elfutils-0.176/debian/patches/riscv-retval-workaround.patch
--- elfutils-0.176/debian/patches/riscv-retval-workaround.patch	1970-01-01 01:00:00.0 +0100
+++ elfutils-0.176/debian/patches/riscv-retval-workaround.patch	2019-05-28 20:52:01.0 +0200
@@ -0,0 +1,11 @@
+--- a/backends/riscv_retval.c
 b/backends/riscv_retval.c
+@@ -111,7 +111,7 @@
+ 		   Dwarf_Die *arg1 __attribute__ ((unused)))
+ {
+   /* ??? */
+-  return 1;
++  return 0;
+ }
+ 
+ static int
diff -Nru elfutils-0.176/debian/patches/series elfutils-0.176/debian/patches/series
--- elfutils-0.176/debian/patches/series	2019-02-16 14:54:50.0 +0100
+++ elfutils-0.176/debian/patches/series	2019-05-28 20:52:01.0 +0200
@@ -11,3 +11,4 @@
 ignore_strmerge.diff
 disable_werror.patch
 mips_cfi.patch
+riscv-retval-workaround.patch

Bug#928832: [PATCH] elfutils: FTBFS on riscv64

[Karsten Merker]

On Sat, May 11, 2019 at 10:26:37PM +0200, Karsten Merker wrote:

> elfutils currently FTBFS for riscv64 and this is the last remaining
> blocker to get a working debian-installer for riscv64.  As already
> discussed together with elfutils upstream, there is a workaround that
> requires only a one-line change in a riscv-specific file plus
> extending the existing architecture-specific build-dependency on
> libc6-dbg for [powerpc powerpcspe ppc64 ppc64el armel armhf arm64
> sparc64] to also include riscv64.
> 
> I would therefore like to ask you to upload a version of elfutils
> with the attached patch to unstable.  The patch should pose no
> problem with the freeze as it only touches an arch-specific source
> file for a non-release architecture and doesn't have any effect at
> all on any release architecture.  At the same time it is very
> important for the riscv64 port as without the patch we cannot make
> progress with d-i on riscv64, and having a working d-i is a
> significant milestone for the riscv64 port.

Hello Kurt,

may I kindly ping you on this bugreport?  Is there anything that
speaks against application of the patch?  If you think that the
patch is ok but you don't have time for preparing a new upload, I
would offer doing an NMU if that would be ok for you.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.

Bug#928832: [PATCH] elfutils: FTBFS on riscv64

[Karsten Merker]

Source: elfutils
Version: 0.176-1
Severity: important
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello Kurt,

elfutils currently FTBFS for riscv64 and this is the last remaining
blocker to get a working debian-installer for riscv64.  As already
discussed together with elfutils upstream, there is a workaround that
requires only a one-line change in a riscv-specific file plus
extending the existing architecture-specific build-dependency on
libc6-dbg for [powerpc powerpcspe ppc64 ppc64el armel armhf arm64
sparc64] to also include riscv64.

I would therefore like to ask you to upload a version of elfutils
with the attached patch to unstable.  The patch should pose no
problem with the freeze as it only touches an arch-specific source
file for a non-release architecture and doesn't have any effect at
all on any release architecture.  At the same time it is very
important for the riscv64 port as without the patch we cannot make
progress with d-i on riscv64, and having a working d-i is a
significant milestone for the riscv64 port.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
diff -Nur elfutils-0.176/debian/control elfutils-0.176.patched/debian/control
--- elfutils-0.176/debian/control
+++ elfutils-0.176.patched/debian/control
@@ -1,7 +1,7 @@
 Source: elfutils
 Priority: optional
 Maintainer: Kurt Roeckx 
-Build-Depends: debhelper (>= 9), autotools-dev, autoconf, automake, bzip2, zlib1g-dev, zlib1g-dev:native, libbz2-dev, liblzma-dev, m4, gettext, autoconf, automake, gawk, dpkg-dev (>= 1.16.1~), gcc-multilib [any-amd64 sparc64] , libc6-dbg [powerpc powerpcspe ppc64 ppc64el armel armhf arm64 sparc64], flex, bison
+Build-Depends: debhelper (>= 9), autotools-dev, autoconf, automake, bzip2, zlib1g-dev, zlib1g-dev:native, libbz2-dev, liblzma-dev, m4, gettext, autoconf, automake, gawk, dpkg-dev (>= 1.16.1~), gcc-multilib [any-amd64 sparc64] , libc6-dbg [powerpc powerpcspe ppc64 ppc64el armel armhf arm64 sparc64 riscv64], flex, bison
 Build-Conflicts: autoconf2.13, automake1.4
 Standards-Version: 4.1.0
 Section: libs
diff -Nur elfutils-0.176/debian/patches/riscv-retval-workaround.patch elfutils-0.176.patched/debian/patches/riscv-retval-workaround.patch
--- elfutils-0.176/debian/patches/riscv-retval-workaround.patch	1970-01-01 01:00:00.0 +0100
+++ elfutils-0.176.patched/debian/patches/riscv-retval-workaround.patch	2019-05-11 20:26:06.736089789 +0200
@@ -0,0 +1,11 @@
+--- a/backends/riscv_retval.c
 b/backends/riscv_retval.c
+@@ -111,7 +111,7 @@
+ 		   Dwarf_Die *arg1 __attribute__ ((unused)))
+ {
+   /* ??? */
+-  return 1;
++  return 0;
+ }
+ 
+ static int
diff -Nur elfutils-0.176/debian/patches/series elfutils-0.176.patched/debian/patches/series
--- elfutils-0.176/debian/patches/series
+++ elfutils-0.176.patched/debian/patches/series
@@ -11,3 +11,4 @@
 ignore_strmerge.diff
 disable_werror.patch
 mips_cfi.patch
+riscv-retval-workaround.patch

Bug#928451: linux: riscv64 updates (change kernel image type to flat image and enable vdso)

[Karsten Merker]

ting OpenNTPd Network Time Protocol...
[  OK  ] Started OpenNTPd Network Time Protocol.
[  OK  ] Started Raise network interfaces.
 Starting Online ext4 Metad…a Check for All Filesystems...
 Starting Rotate log files...
 Starting Daily man-db regeneration...
[  OK  ] Reached target Network.
 Starting Permit User Sessions...
 Starting OpenBSD Secure Shell server...
[  OK  ] Reached target Network is Online.
 Starting LSB: exim Mail Transport Agent...
 Starting Daily apt download activities...
[  OK  ] Started Permit User Sessions.
[  OK  ] Started Serial Getty on ttyS0.
[  OK  ] Started Getty on tty1.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started OpenBSD Secure Shell server.
[  OK  ] Started Online ext4 Metadata Check for All Filesystems.
[  OK  ] Started Rotate log files.
[  OK  ] Started Recover schroot sessions.

Debian GNU/Linux 10 riscv64 ttyS0

riscv64 login: 

-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
>From de70ae43563da85568562e49c6f3bc1f27741dfc Mon Sep 17 00:00:00 2001
From: Karsten Merker 
Date: Sat, 4 May 2019 19:41:45 +0200
Subject: [PATCH 1/2] [riscv64] Change the kernel image format from ELF to flat
 Image.

The riscv64 architecture is changing its standard kernel image
format from ELF to a flat kernel image with a PE/COFF-compatible
header (similar to arm64) to make EFI stub support possible.
Ship arch/riscv/boot/Image instead of an ELF vmlinux in
accordance with this change.
---
 debian/config/riscv64/defines | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/config/riscv64/defines b/debian/config/riscv64/defines
index 2ea6d75977f1..e83b750ea74a 100644
--- a/debian/config/riscv64/defines
+++ b/debian/config/riscv64/defines
@@ -4,7 +4,7 @@ featuresets:
  none
 
 [build]
-image-file: vmlinux
+image-file: arch/riscv/boot/Image
 
 [image]
 install-stem: vmlinux
-- 
2.20.1

>From 5fda00263bfe81d8a62dd4162c66527b51ea1755 Mon Sep 17 00:00:00 2001
From: Karsten Merker 
Date: Sat, 4 May 2019 19:51:14 +0200
Subject: [PATCH 2/2] [riscv64] Enable vdso

When riscv64 support was originally added to the Debian Linux
kernel package, the mainline kernel lacked a vdso_install target
for riscv64.  This has in the meantime been added with upstream
commit f157d411a9eb170d2ee6b766da7a381962017cc9 ("riscv: add
missing vdso_install target"), so we can now enable the
corresponding option in the kernel package.
---
 debian/config/riscv64/defines | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/config/riscv64/defines b/debian/config/riscv64/defines
index e83b750ea74a..1d5a58b7313a 100644
--- a/debian/config/riscv64/defines
+++ b/debian/config/riscv64/defines
@@ -5,6 +5,7 @@ featuresets:
 
 [build]
 image-file: arch/riscv/boot/Image
+vdso: true
 
 [image]
 install-stem: vmlinux
-- 
2.20.1

Bug#928079: mmdebstrap: fails when passing --include="linux-image-amd64"

[Karsten Merker]

Package: mmdebstrap
Version: 0.4.1-2

Hello,

when trying to include a kernel image in the package list for
mmdebstrap, mmdebstrap fails when running the deferred trigger for
update-initramfs.  The effect is independent of the architecture
(tested on amd64, armhf and riscv64).  When doing a standard install
without the "--include" parameter, switching to the chroot and
manually installing the same kernel package everything works without
problems.

Following are three logs:
- mmdebstrap called with --include="linux-image-amd64"
- mmdebstrap called without --include and manual kernel installation
  afterwards
- same as before but trying to (at least partially) replicate the apt
  environment in mmdebstrap 

Failure log
===
$ sudo mmdebstrap --aptopt='Acquire::http { Proxy "http://127.0.0.1:3142;; }' 
--architectures=amd64 --include="linux-image-amd64" sid /tmp/amd64-chroot "deb 
http://deb.debian.org/debian/ sid main"
I: automatically chosen mode: root
I: chroot architecture amd64 is equal to the host's architecture
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
Reading package lists...
Building dependency tree...
adduser is already the newest version (3.118).
apt is already the newest version (1.8.0).
debconf is already the newest version (1.5.71).
debian-archive-keyring is already the newest version (2019.1).
gpgv is already the newest version (2.2.13-1).
mawk is already the newest version (1.3.3-17+b3).
libpam-modules is already the newest version (1.3.1-5).
libpam-modules-bin is already the newest version (1.3.1-5).
libpam-runtime is already the newest version (1.3.1-5).
passwd is already the newest version (1:4.5-1.1).
fdisk is already the newest version (2.33.1-0.1).
The following additional packages will be installed:
  dmsetup initramfs-tools initramfs-tools-core klibc-utils libapparmor1
  libapt-inst2.0 libargon2-1 libbsd0 libcap2 libcap2-bin libcom-err2
  libcryptsetup12 libdevmapper1.02.1 libdns-export1104 libelf1 libestr0
  libext2fs2 libfastjson4 libidn11 libip4tc0 libip6tc0 libiptc0
  libisc-export1100 libjson-c3 libklibc libkmod2 liblocale-gettext-perl
  liblognorm5 libmnl0 libncurses6 libnetfilter-conntrack3 libnewt0.52
  libnfnetlink0 libnftnl11 libpopt0 libprocps7 libslang2 libss2 libssl1.1
  libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libxtables12
  linux-base linux-image-4.19.0-4-amd64 lsb-base xxd
Suggested packages:
  cpp wamerican | wordlist whois vacation libarchive1 anacron checksecurity
  gpart parted fuse2fs e2fsck-static ppp rdnssd bash-completion iproute2-doc
  resolvconf avahi-autoipd isc-dhcp-client-ddns linux-doc-4.19
  debian-kernel-handbook grub-pc | grub-efi-amd64 | extlinux nfs-common spell
  readline-doc rsyslog-mysql | rsyslog-pgsql rsyslog-mongodb rsyslog-doc
  rsyslog-gnutls rsyslog-gssapi rsyslog-relp systemd-container policykit-1
  indent
Recommended packages:
  default-mta | mail-transport-agent e2fsprogs-l10n lvm2 busybox
  | busybox-static pigz libatm1 nftables libpam-cap libgpm2 libfribidi0
  firmware-linux-free irqbalance apparmor bsd-mailx | mailx psmisc
  libpam-systemd dbus libnss-systemd laptop-detect
The following NEW packages will be installed:
  apt-utils bsdmainutils cpio cron debconf-i18n dmidecode dmsetup e2fsprogs
  gdbm-l10n ifupdown init initramfs-tools initramfs-tools-core iproute2
  iptables iputils-ping isc-dhcp-client isc-dhcp-common klibc-utils kmod less
  libapparmor1 libapt-inst2.0 libargon2-1 libbsd0 libcap2 libcap2-bin
  libcom-err2 libcryptsetup12 libdevmapper1.02.1 libdns-export1104 libelf1
  libestr0 libext2fs2 libfastjson4 libidn11 libip4tc0 libip6tc0 libiptc0
  libisc-export1100 libjson-c3 libklibc libkmod2 liblocale-gettext-perl
  liblognorm5 libmnl0 libncurses6 libnetfilter-conntrack3 libnewt0.52
  libnfnetlink0 libnftnl11 libpopt0 libprocps7 libslang2 libss2 libssl1.1
  libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libxtables12
  linux-base linux-image-4.19.0-4-amd64 linux-image-amd64 logrotate lsb-base
  mount nano netbase procps readline-common rsyslog sensible-utils systemd
  systemd-sysv tasksel tasksel-data tzdata udev vim-common vim-tiny whiptail
  xxd
0 upgraded, 82 newly installed, 0 to remove and 0 not upgraded.
Need to get 66.0 MB of archives.
After this operation, 334 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian sid/main amd64 libcom-err2 amd64 1.45.0-1 
[69.1 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 libext2fs2 amd64 1.45.0-1 
[256 kB]
Get:3 http://deb.debian.org/debian sid/main amd64 libss2 amd64 1.45.0-1 [73.6 
kB]
Get:4 http://deb.debian.org/debian sid/main amd64 e2fsprogs amd64 1.45.0-1 [592 
kB]
Get:5 http://deb.debian.org/debian sid/main amd64 mount amd64 2.33.1-0.1 [174 
kB]
Get:6 http://deb.debian.org/debian sid/main amd64 

Bug#927744: debmake: Please add support for SPDX-License-Identifiers

[Karsten Merker]

Package: debmake
Version: 4.3.1-1
Severity: wishlist

Hello,

more and more upstream projects (including a number of high-profile
ones such as the Linux kernel) are moving to including SPDX license
identifiers (https://spdx.org/ids) instead of the full license text
(in case of BSD- and MIT-style licenses) respectively the
short-form (L)GPL notice in their source files.  These identifiers
are intended to make the license a piece of code is distributed
under easily machine-parsable while keeping them human-readable.

Examples:
-
SPDX-License-Identifier: BSD-2-Clause
SPDX-License-Identifier: GPL-2.0
SPDX-License-Identifier: GPL-2.0-or-later

Currently "debmake -cc" doesn't recognize the SPDX IDs and flags
all files using them as ""License: __UNKNOWN__".  It would be great
if you could extend the patterns that "debmake -cc" matches on for
recognizing the various licenses to include the corresponding SPDX
license identifiers.  A list of the identifiers and the
corresponding full license text is available at
https://spdx.org/licenses/.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.

Bug#918428: choose-mirror: mirror list generation broken for all ports architectures

[Karsten Merker]

Source: choose-mirror
Version: 2.96

Hello,

while working on riscv64 support in d-i I have stumbled over a problem
with choose-mirror: instead of providing a mirror list, choose-mirror
only offers the option "enter information manually", even if
Mirrors.masterlist is extended to contain a "riscv64" entry in the
"Ports-architecture" field for deb.debian.org and ftp.ports.debian.org.

I have tracked the source of this issue down to the part of the
"mirrorlist" script that tries to filter out mirrors that don't carry
the architecture for which choose-mirror is currently built:

https://salsa.debian.org/installer-team/choose-mirror/blob/8bc40f7e97afa5fb075535f501abc31614a574dd/mirrorlist#L107

This filter function only takes the "Archive-architecture" fields from
Mirrors.masterlist into account, but not the "Ports-architecture"
fields, so it always results in an empty list for Debian-Ports
architectures.  Unfortunately I don't really speak perl (just enough to
have a rough idea of what the mirrorlist script does, but not enough to
make modifications to it with good conscience), so it would be great
if somebody from debian-boot with better perl knowledge than me could
take a look.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#908161: Please enable building a riscv64 kernel image

[Karsten Merker]

Control: tags 908161 + patch

On Tue, Sep 18, 2018 at 08:57:01PM +0200, Karsten Merker wrote:
> On Sat, Sep 08, 2018 at 11:15:36PM +0100, Ben Hutchings wrote:
> 
> [Building a linux-image-*-riscv64 binary package]
> 
> > The addition of riscv will have to wait until it has support
> > for an initramfs.
> > 
> > Is this commit sufficient to make booting with an initramfs work:
> > 
> > commit cdc7274029ca5984350a057a2399aaa340d3be2d
> > Author: Guenter Roeck 
> > Date:   Tue Aug 28 17:33:46 2018 -0700
> > 
> > riscv: Do not overwrite initrd_start and initrd_end
> > 
> > or are more changes needed?
> 
> Hello,
> 
> just a short status update: the aforementioned patch has been
> included in the upstream 4.19-rc4 release and I can confirm
> that the initramfs support for riscv64 works with 4.19-rc4.
> 
> The other major issue in this bug (unversioned symbols breaking
> the package build) is still unresolved; I'll report back as soon
> as I have received feedback from the upstream RISC-V architecture
> maintainer.

Hello,

all previously mentioned issues have been addressed in
the meantime:

- The broken initrd support has been fixed upstream in kernel
  4.19-rc4.

- The symbol version issue has been fixed upstream in kernel
  4.19-rc6.

- The riscv64 kernel config has been modularized as far as
  possible and all redundant entries have been removed.

- Headings have been added to the kernel config.

Attached is a new patch, alternatively it is available as a merge
request on salsa as suggested earlier in the discussion:

  https://salsa.debian.org/kernel-team/linux/merge_requests/66

The resulting kernel has been successfully tested on a qemu
"virt" board:

[0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
[0.00] Linux version 4.19.0-rc7-riscv64 
(debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-7)) #1 SMP 
Debian 4.19~rc7-1~exp2 (2018-10-08)
[0.00] bootconsole [early0] enabled
[0.00] Initial ramdisk at: 0x(ptrval) (43521258 bytes)
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x8020-0x]
[0.00]   Normal   [mem 0x0001-0x2fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x8020-0x0002]
[0.00] Initmem setup node 0 [mem 0x8020-0x0002]
[0.00] On node 0 totalpages: 2620928
[0.00]   DMA32 zone: 8184 pages used for memmap
[0.00]   DMA32 zone: 0 pages reserved
[0.00]   DMA32 zone: 523776 pages, LIFO batch:63
[0.00]   Normal zone: 32768 pages used for memmap
[0.00]   Normal zone: 2097152 pages, LIFO batch:63
[0.00] software IO TLB: mapped [mem 0xfbfff000-0xf000] (64MB)
[0.00] elf_hwcap is 0x112d
[0.00] percpu: Embedded 19 pages/cpu @(ptrval) s39384 r8192 
d30248 u77824
[0.00] pcpu-alloc: s39384 r8192 d30248 u77824 alloc=19*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 2579976
[0.00] Kernel command line: console=ttyS0 ro root=/dev/vda
[0.00] Dentry cache hash table entries: 2097152 (order: 12, 16777216 
bytes)
[0.00] Inode-cache hash table entries: 1048576 (order: 11, 8388608 
bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 10178016K/10483712K available (4955K kernel code, 504K 
rwdata, 1633K rodata, 446K init, 934K bss, 305696K reserved, 0K cma-reserved)
[0.00] random: get_random_u64 called from 
__kmem_cache_create+0x46/0x55c with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 21055 entries in 83 pages
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
[0.00] plic: mapped 10 interrupts to 4 (out of 8) handlers.
[0.00] clocksource: riscv_clocksource: mask: 0x 
max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[0.004000] Console: colour dummy device 80x25
[0.008000] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 20.00 BogoMIPS (lpj=4)
[0.012000] pid_max: default: 32768 minimum: 301
[0.016000] Security Framework initialized
[0.016000] Yama: disabled by default; enable with sysctl kernel.yama.*
[0.02] AppArmor: AppArmor initialized
[0.024000] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes)
[0.028000] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 
bytes)
[0.072000] rcu: Hierarchical SRCU

Bug#910044: mmdebstrap: problem with sources.list-style mirror parameter handling

[Karsten Merker]

On Tue, Oct 02, 2018 at 10:13:42AM +0200, Johannes Schauer wrote:
> Quoting Johannes Schauer (2018-10-02 04:23:54)
> > > Another thing that I have stumbled upon is that providing a sources.list 
> > > on
> > > stdin only works when no target directory is provided on the commandline,
> > > i.e. when automatically creating a tarball. While
> > > 
> > >   echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
> > > http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
> > > --architectures=riscv64 > /tmp/rv64-chroot.tar
> > > 
> > > works, the following doesn't:
> > > 
> > >   echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
> > > http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
> > > --architectures=riscv64 sid /tmp/rv64-chroot
> > > 
> > > It results in
> > > 
> > >   I: riscv64 cannot be executed, falling back to qemu-user
> > >   I: automatically chosen mode: root
> > >   I: running apt-get update...
> > >   done
> > >   apt-get update didn't download anything at /usr/bin/mmdebstrap line 721.
> > 
> > This is actually a feature. In your second invocation, you didn't specify 
> > the
> > "MIRROR" argument. The docs say:
> > 
> > > If no MIRROR option is provided, http://deb.debian.org/debian is used.
> > 
> > In your first invocation, you also didn't specify the "SUITE" argument. The
> > docs say:
> > 
> > > If no SUITE was specified, then a single MIRROR "-" is added and thus the
> > > information of the desired suite has to come from standard input as part 
> > > of a
> > > valid apt sources.list file.
> > 
> > So the implicit '-' as the mirror argument only works if there was no 
> > SUITE. If
> > you pass a SUITE, you need to explicitly tell it that you want to read the
> > mirror from stdin. This is to have compatibility with how debootstrap also 
> > just
> > uses deb.debian.org/debian as the mirror if the mirror argument is missing.
> > 
> > To make the cause of the problem more obvious, I'm now printing the content 
> > of
> > /etc/apt/sources.list in the chroot in case apt-get didn't download 
> > anything:
> > 
> > https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/1f13d0157bc8364ac491203a6a9156a78f6228a9
> > 
> > But we could turn this bug into a feature request of the following form:
> > 
> > If no MIRROR was provided *and* something was specified on standard input, 
> > then
> > don't use deb.debian.org/debian but use whatever was given on standard input
> > instead.
> > 
> > Or even more liberal:
> > 
> > If anything is provided on standard input and there is no '-' MIRROR 
> > argument,
> > then just append whatever is given on standard input to the apt sources.list
> > inside the chroot.
> > 
> > What do you think?
> 
> now that I've slept about it, I think your idea makes sense. If you don't
> specify a mirror but you pass something on standard input, then the default
> mirror should *not* be used. The default mirror should only be used if neither
> a mirror nor anything from standard input was given.
> 
> I pushed a fix to the upstream repository. I would be happy if you could
> download the latest version of the shell script from there and test if it 
> works
> as you had expected it to work.

Many thanks!  I've run a number of tests covering different
options (native/foreign chroot, implicit/explicit mirror,
plain-url/sources.list-entry, mirror information via stdin/on the
commandline, target directory/tarball) with the current upstream
git head and everything looks good:

* native chroot with default mirror and with a directory
  as the target:

  # mmdebstrap --include="debian-ports-archive-keyring" sid /tmp/amd64-chroot
  I: chroot architecture amd64 is equal to the host's architecture
  I: automatically chosen mode: root
  I: running apt-get update...
  done
  I: downloading packages with apt...
  done
  I: extracting archives...
  done
  I: installing packages...
  done
  I: downloading apt...
  done
  I: installing apt...
  done
  I: installing remaining packages inside the chroot...
  done
  I: cleaning package lists and apt cache...
  done
  done

* native chroot with a mirror URL on the commandline and a
  directory as the target:

  # mmdebstrap --include="debian-ports-archive-keyring" sid /tmp/amd64-chroot 
http://deb.debian.org/debian
  I: chroot architecture amd64 is equal to the host's architecture
  I: automatically chosen mode: root
  I: running apt-get update...
  done
  I: downloading packages with apt...
  done
  I: extracting archives...
  done
  I: installing packages...
  done
  I: downloading apt...
  done
  I: installing apt...
  done
  I: installing remaining packages inside the chroot...
  done
  I: cleaning package lists and apt cache...
  done
  done

* foreign (riscv64) chroot with sources.list passed on stdin and
  with a directory as the target:

  # echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 

Bug#910044: mmdebstrap: problem with sources.list-style mirror parameter handling

[Karsten Merker]

Package: mmdebstrap
Version: 0.1.0-2

Hello,

many thanks for creating mmdebstrap!  I'm using it for creating
chroots for Debian-Ports architectures, where we need to pull the
packages from two suites: unstable and unreleased.  While using
mmdebstrap, I've stumbled over two issues.  Everything works fine
when creating a sources.list, feeding it to mmdebstrap on stdin
and having mmdebstrap automatically generate a tarball, i.e. 
with something like

  echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
--architectures=riscv64 > /tmp/rv64-chroot.tar

The process fails when one tries to pass the mirrors on the
commandline, though.  Due to the fact that there is more than one
suite to use, the mirrors need to be passed in sources.list
style, i.e. as "deb http:///debian-ports  main".

Running mmdebstrap with

  mmdebstrap --architectures=riscv64 sid /tmp/rv64-chroot "deb 
http://deb.debian.org/debian-ports/ sid main" "deb 
http://deb.debian.org/debian-ports/ unreleased main"

results in

  E: Malformed entry 1 in list file /tmp/rv64-chroot/etc/apt/sources.list (URI 
parse)
  E: The list of sources could not be read.
  apt-get update failed at /usr/bin/mmdebstrap line 548.
  # cat /tmp/rv64-chroot/etc/apt/sources.list
  deb deb http://deb.debian.org/debian-ports/ sid main sid main
  deb deb http://deb.debian.org/debian-ports/ unreleased main sid main

The manpage states:

  If a MIRROR option starts with "deb " or "deb-src " then it is
  used as a one-line-style format entry for apt's sources.list
  inside the chroot.  If a MIRROR option contains a "://" then it
  is interpreted as a mirror URI and the apt line inside the chroot
  is assembled as "deb [arch=A] B C D" where A is the host's native
  architecture, B is the MIRROR, C is the given SUITE and D is the
  components given via --components (defaults to "main").

It looks like the second part is applied unconditionally on
all mirror parameters that contain a "://", although that should
not happen if the mirror parameter starts with a "deb " or
"deb-src " and thereby already constitutes a complete sources.list
entry.

Another thing that I have stumbled upon is that providing a
sources.list on stdin only works when no target directory is
provided on the commandline, i.e. when automatically creating a
tarball. While

  echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
--architectures=riscv64 > /tmp/rv64-chroot.tar

works, the following doesn't:

  echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
--architectures=riscv64 sid /tmp/rv64-chroot

It results in

  I: riscv64 cannot be executed, falling back to qemu-user
  I: automatically chosen mode: root
  I: running apt-get update...
  done
  apt-get update didn't download anything at /usr/bin/mmdebstrap line 721.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#908161: Please enable building a riscv64 kernel image

[Karsten Merker]

On Thu, Sep 06, 2018 at 10:28:19PM +0100, Ben Hutchings wrote:
> On Thu, 2018-09-06 at 22:06 +0200, Karsten Merker wrote:
> > Source: linux
> > Version: 4.19~rc2-1~exp1
> > Severity: wishlist
[...]
> > starting with version 4.19rc2, the mainline Linux kernel includes
> > all drivers necessary for running a riscv64 system in qemu, so it
> > would be great if the "linux" source package could be extended to
> > build a linux-image-*-riscv64 binary package.
> > 
> > Attached is a patch that tries to add the necessary bits.
> 
> This config sets a whole lot of things to be built-in, but our policy
> is to build everything as modules if it works properly work as a
> module.  This will also cause the building of installer udebs to fail
> (empty packages are treated as a fatal error).

Hello,

the reason for using a static config was that using an initrd
isn't possible on riscv64 with kernel 4.19rc2.  This will
hopefully change sometime before the final 4.19 release so that
we can move to a fully modularized config, but for now everyting
required to mount the rootfs and bring up init has to be
built-in.  I can probably trim down the current static config a
bit more, but e.g. filesystem drivers need to be built-in for
now, otherwise mounting the rootfs isn't possible.

> It also seems to have some redundant settings.  debian/config/config is
> always used first (see README.source), so don't repeat anything that's
> in there.

Many thanks for the pointer, I'll take that into account for the
next version of the patch.

> Finally you should use kconfigeditor2 to add headings to the config
> file.  You need to check out the kernel-team.git repository, and then
> in the linux repository run something like:
> 
> ../kernel-team/utils/kconfigeditor2/process.py .

Ok, will do.

> > Unfortunately, with the patch applied the kernel itself builds
> > successfully, but the package build process then fails with
> > 
> > -8<--8<--8<--8<--8<-
> > 
> > make[3]: Leaving directory 
> > '<>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
> > debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 
> > none riscv64
> > ABI is not completely versioned!  Refusing to continue.
> > 
> > Unversioned symbols:
> > _mcount  module: vmlinux, version: 
> > 0x, export: EXPORT_SYMBOL
> > return_to_handlermodule: vmlinux, version: 
> > 0x, export: EXPORT_SYMBOL
> > Can't read ABI reference.  ABI not checked!
> > make[2]: *** [debian/rules.real:217: 
> > debian/stamps/build_riscv64_none_riscv64] Fehler 1
> > 
> > -8<--8<--8<--8<--8<-
> > 
> > I'm somewhat stuck here - is this an upstream issue or
> > have I overlooked something on the packaging side? Pointers
> > welcome :).
> 
> It's an upstream issue, but not a fatal error there.  For Debian it is
> a fatal error becasue unversioned symbols potentially undermine code
> signing.
> 
> Any symbol exported from an assembly-language file won't automatically
> get a symbol version, since there's no type information there.  The way
> to fix this is to include (or directly) add the function prototypes in
> arch/riscv/include/asm/asm-prototypes.h.
> 
> I don't think that return_to_handler should be exported at all.  No
> other architecture does.  As for _mcount, that is declared in
> , so  should just be:
> 
> /* SPDX-License-Identifier: GPL-2.0 */
> #include 

Thanks for the explanation, I'll contact the upstream RISC-V
kernel maintainer regarding this.

> Finally, you have added module lists for installer udebs, but this
> won't have any effect unless you also add the new architecture and
> flavour to debian/installer/kernel-versions.

Again thanks for the pointer, I'll look into it.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#908161: Please enable building a riscv64 kernel image

[Karsten Merker]

Source: linux
Version: 4.19~rc2-1~exp1
Severity: wishlist
Tags: patch
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

starting with version 4.19rc2, the mainline Linux kernel includes
all drivers necessary for running a riscv64 system in qemu, so it
would be great if the "linux" source package could be extended to
build a linux-image-*-riscv64 binary package.

Attached is a patch that tries to add the necessary bits. 
Unfortunately, with the patch applied the kernel itself builds
successfully, but the package build process then fails with

-8<--8<--8<--8<--8<-

make[3]: Leaving directory 
'<>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none 
riscv64
ABI is not completely versioned!  Refusing to continue.

Unversioned symbols:
_mcount  module: vmlinux, version: 
0x, export: EXPORT_SYMBOL
return_to_handlermodule: vmlinux, version: 
0x, export: EXPORT_SYMBOL
Can't read ABI reference.  ABI not checked!
make[2]: *** [debian/rules.real:217: debian/stamps/build_riscv64_none_riscv64] 
Fehler 1

-8<--8<--8<--8<--8<-

I'm somewhat stuck here - is this an upstream issue or
have I overlooked something on the packaging side? Pointers
welcome :).

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
>From d1d47c22d5c41bb3b1924d2534aa06e86a16c10d Mon Sep 17 00:00:00 2001
From: Karsten Merker 
Date: Sat, 1 Sep 2018 23:02:11 +0200
Subject: [PATCH] Build a kernel image for riscv64

---
 debian/config/riscv64/config  | 79 +++
 debian/config/riscv64/defines |  6 +-
 debian/config/riscv64/none/defines|  3 +
 debian/installer/modules/riscv64/ata-modules  |  1 +
 .../installer/modules/riscv64/btrfs-modules   |  1 +
 .../modules/riscv64/compress-modules  |  1 +
 debian/installer/modules/riscv64/crc-modules  |  1 +
 .../modules/riscv64/crypto-dm-modules |  1 +
 .../installer/modules/riscv64/crypto-modules  |  1 +
 .../installer/modules/riscv64/event-modules   |  1 +
 debian/installer/modules/riscv64/ext4-modules |  1 +
 debian/installer/modules/riscv64/fat-modules  |  1 +
 debian/installer/modules/riscv64/fuse-modules |  1 +
 debian/installer/modules/riscv64/i2c-modules  |  1 +
 .../installer/modules/riscv64/input-modules   |  1 +
 .../installer/modules/riscv64/isofs-modules   |  1 +
 debian/installer/modules/riscv64/jfs-modules  |  1 +
 debian/installer/modules/riscv64/kernel-image |  1 +
 debian/installer/modules/riscv64/leds-modules |  1 +
 debian/installer/modules/riscv64/loop-modules |  1 +
 debian/installer/modules/riscv64/md-modules   |  1 +
 debian/installer/modules/riscv64/mmc-modules  |  1 +
 debian/installer/modules/riscv64/mtd-modules  |  1 +
 .../modules/riscv64/multipath-modules |  1 +
 debian/installer/modules/riscv64/nbd-modules  |  1 +
 debian/installer/modules/riscv64/nic-modules  |  1 +
 .../modules/riscv64/nic-shared-modules|  1 +
 .../installer/modules/riscv64/nic-usb-modules |  1 +
 .../modules/riscv64/nic-wireless-modules  |  1 +
 debian/installer/modules/riscv64/pata-modules |  1 +
 debian/installer/modules/riscv64/ppp-modules  |  1 +
 debian/installer/modules/riscv64/sata-modules |  1 +
 .../modules/riscv64/scsi-core-modules |  1 +
 debian/installer/modules/riscv64/scsi-modules |  2 +
 .../modules/riscv64/squashfs-modules  |  1 +
 debian/installer/modules/riscv64/udf-modules  |  1 +
 .../installer/modules/riscv64/uinput-modules  |  1 +
 debian/installer/modules/riscv64/usb-modules  |  1 +
 .../modules/riscv64/usb-storage-modules   |  1 +
 .../installer/modules/riscv64/virtio-modules  |  1 +
 debian/installer/modules/riscv64/zlib-modules |  1 +
 41 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 debian/config/riscv64/config
 create mode 100644 debian/config/riscv64/none/defines
 create mode 100644 debian/installer/modules/riscv64/ata-modules
 create mode 100644 debian/installer/modules/riscv64/btrfs-modules
 create mode 100644 debian/installer/modules/riscv64/compress-modules
 create mode 100644 debian/installer/modules/riscv64/crc-modules
 create mode 100644 debian/installer/modules/riscv64/crypto-dm-modules
 create mode 100644 debian/installer/modules/riscv64/crypto-modules
 create mode 100644 debian/installer/modules/riscv64/event-modules
 create mode 100644 debian/installer/modules/riscv64/ext4-modules
 create mode 100644 debian/installer/modules/riscv64/fat-modules
 create mode 100644 debian/installer/modules/riscv64/fuse-modules
 create mode 100644 debian/i

Bug#899118: flash-kernel: add missing arm64 boards

[Karsten Merker]

On Mon, May 21, 2018 at 01:01:56AM +0200, Heinrich Schuchardt wrote:
> On 05/20/2018 09:15 PM, Karsten Merker wrote:
> > On Sat, May 19, 2018 at 02:57:41PM +0200, Heinrich Schuchardt wrote:
> > 
> >> Package: flash-kernel
> >> Version: 3.94
> >> Severity: normal
> >> Tags: patch
> >>
> >> Add 60 missing database entries for arm64 boards
> >> supported both by U-Boot and by Linux:
[...]
> > many thanks for the patch.  Just to make sure that we don't run
> > into problems later on: do all these boards really use u-boot's
> > config_distro_bootcmd.h and thereby work properly with
> > bootscr.uboot-generic?
> > 
> > When looking at the defconfigs for several of these systems, I
> > see e.g. CONFIG_BOOTARGS settings that don't really match what I
> > would expect for systems using config_distro_bootcmd.h.
> > Three random examples:
> > 
> > - r8a77995_draak_defconfig:
> >   CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs 
> > nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"
> > 
> > - ls1088ardb_sdcard_qspi_defconfig:
> >   CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
> > earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 
> > default_hugepagesz=2m hugepagesz=2m hugepages=256"
> > 
> > - hikey_defconfig:
> >   CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"
[,,,]
> For a board to be able to benefit from flash-kernel U-Boot must:
> 
> - be capable to load and execute boot.scr
> - provide the booti command
> - allow the definition of the following environment variables:
>   - devtype, devnum, partition
>   - fdtfile
>   - kernel_addr_r
>   - fdt_addr_r
>   - ramdisk_addr_r
> 
> In your examples above I could not find any evidence that U-Boot cannot
> be configured and built to fulfill these requirements.
> 
> For instance build
> 
> make r8a77995_draak_defconfig
> make menuconfig
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_BOOTARGS="console=ttySC0,115200"
> CONFIG_ENV_IS_IN_MMC=y (this is a default value)
> make -j6
> 
> Setup missing environment variables interactively and save them to MMC
> and you can rely on flash-kernel for booting.
> 
> ls1088ardb_sdcard_qspi_defconfig and hikey_defconfig select
> CONFIG_DISTRO_DEFAULTS=y. CONFIG_BOOTARGS has to be reconfigured.
> 
> This patch is only about providing flash-kernel for the boards. It is
> not about providing U-Boot configured to match flash-kernel's requirements.
> 
> I think that even for boards for which we do not provide U-Boot as a
> Debian package we should allow the usage of flash-kernel without setting
> up a local override for the machine database (/etc/flash-kernel/db).

Hello,

our policy has always been to only add an entry for an
armhf/arm64 system to the flash-kernel database if this entry
works out of the box with the default mainline u-boot
configuration for the respective device.  Users usually expect
that a system boots out of the box without having to build a
non-standard u-boot configuration and modify the default
environment if the system is listed in the flash-kernel machine
db.

I'm open to arguments to the contrary, but for now I believe that
is makes sense to keep this policy.

Having to build u-boot with an undocumented non-standard
configuration and having to modify various non-obvious parts of
the default environment (which possibly includes having to find
out the platform-specific kernel_addr_r, fdt_addr_r and
ramdisk_addr_r values for systems where they are not already
defined in the default environment) to make the system boot is an
extremely high and completely unexpected hurdle for a "normal"
user, and I believe that we would do a large part of our userbase
a misservice by including entries that do not work out of the
box.

For somebody who has the knowledge to perform all the
aforementioned steps on the u-boot side, it's usually easy to
also add a corresponding local entry to /etc/flash-kernel/db.

I'm CCing debian-arm for further opinions on the matter.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#899118: flash-kernel: add missing arm64 boards

[Karsten Merker]

On Sat, May 19, 2018 at 02:57:41PM +0200, Heinrich Schuchardt wrote:

> Package: flash-kernel
> Version: 3.94
> Severity: normal
> Tags: patch
> 
> Add 60 missing database entries for arm64 boards
> supported both by U-Boot and by Linux:
> 
> Amlogic Meson GXL (S905X) P212 Development Board
> BananaPi-M64
> Freescale Layerscape 2080a QDS Board
> Freescale Layerscape 2080a RDB Board
> FriendlyARM NanoPi A64
> FriendlyARM NanoPi NEO 2
> FriendlyARM NanoPi NEO Plus2
> GeekBox
> HiKey Development Board
> HiSilicon Poplar Development Board
> Khadas VIM
> Libre Computer Board ALL-H3-CC H5
> Libre Technology CC
> LS1012A Freedom Board
> LS1012A QDS Board
> LS1012A RDB Board
> LS1043A RDB Board
> LS1046A RDB Board
> LS1088A QDS Board
> LS1088A RDB Board
> Marvell Armada 3720 Development Board DB-88F3720-DDR3
> Marvell Armada 7040 DB board
> NVIDIA Tegra210 P2371 (P2530/P2595) reference design
> NVIDIA Tegra210 P2571 reference design
> Olimex A64-Olinuxino
> OrangePi Win/Win Plus
> OrangePi Zero Plus2
> Pine64
> Renesas Draak board based on r8a77995
> Renesas Eagle board based on r8a77970
> Renesas H3ULCB board based on r8a7795 ES2.0+
> Renesas M3ULCB board based on r8a7796
> Renesas Salvator-X board based on r8a7795 ES2.0+
> Renesas Salvator-X board based on r8a7796
> Renesas Salvator-X board based on r8a77965
> Rockchip PX5 EVB
> Rockchip RK3328 EVB
> SoCFPGA Stratix 10 SoCDK
> UniPhier LD11 Global Board (REF_LD11_GP)
> UniPhier LD11 Reference Board
> UniPhier LD20 Global Board (REF_LD20_GP)
> UniPhier LD20 Reference Board
> UniPhier PXs3 Reference Board
> Xunlong Orange Pi PC 2
> Xunlong Orange Pi Prime
> ZynqMP ZC1232 RevA
> ZynqMP ZC1254 RevA
> ZynqMP ZC1275 RevA
> ZynqMP zc1751-xm015-dc1 RevA
> ZynqMP zc1751-xm016-dc2 RevA
> ZynqMP zc1751-xm017-dc3 RevA
> ZynqMP zc1751-xm018-dc4
> ZynqMP zc1751-xm019-dc5 RevA
> ZynqMP ZCU100 RevC
> ZynqMP ZCU102 Rev1.0
> ZynqMP ZCU102 RevA
> ZynqMP ZCU102 RevB
> ZynqMP ZCU104 RevA
> ZynqMP ZCU106 RevA
> ZynqMP ZCU111 RevA

Hello,

many thanks for the patch.  Just to make sure that we don't run
into problems later on: do all these boards really use u-boot's
config_distro_bootcmd.h and thereby work properly with
bootscr.uboot-generic?

When looking at the defconfigs for several of these systems, I
see e.g. CONFIG_BOOTARGS settings that don't really match what I
would expect for systems using config_distro_bootcmd.h.
Three random examples:

- r8a77995_draak_defconfig:
  CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs 
nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"

- ls1088ardb_sdcard_qspi_defconfig:
  CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 default_hugepagesz=2m 
hugepagesz=2m hugepages=256"

- hikey_defconfig:
  CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#890791: stretch-pu: package dpkg/1.18.25

[Karsten Merker]

On Sun, Apr 22, 2018 at 12:39:42AM +0200, Manuel A. Fernandez Montecelo wrote:
> 2018-04-20 1:52 GMT+02:00 Guillem Jover :
> > On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote:
> >> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
> >> > 2018-02-18 22:26 Guillem Jover:
> >> > > I'd like to update dpkg in stretch. This includes several fixes for
> >> > > documentation, regressions, misbheavior, minor security issues, and
> >> > > a new arch definition so that DAK can accept packages using it. The
> >> > > fixes have been in sid/buster for a while now.
> >> >
> >> > We depend on this version being accepted and installed in the systems
> >> > where DAK lives to learn about the new architecture.  After that,
> >> > several other packages can add support for the architecture, without
> >> > receiving an automatic reject when uploaded.
> >> >
> >> > It would be great if this update could enter in the next stable
> >> > update, so we can make progress on that front.
> >
> >> We've been discussing this amongst the SRMs and are quite wary of a
> >> dpkg update this close to the p-u freeze. We appreciate that the
> >> changes individually seem self-contained but would like to have an
> >> update of such a key package able to be tested more than is feasible in
> >> the time available.
> >>
> >> (On a related note, in practical terms it's very unlikely that there
> >> would be sufficient time to get the new strings that are introduced
> >> translated.)
> >
> > Is there perhaps anything you are waiting for me to do here?
> >
> > For the strings I realized afterwards I can take the ones from sid.
> > I've not yet checked how many, or if I'd really need a call for
> > translation, but I'd rather do that only after I know which parts you
> > are going to accept. :) But TBH, this being gettext I'm not sure it
> > matters that much, as only those strings might end up not being
> > translated and dpkg does not have 100% coverage for all languages
> > anyway. :)
[...]
> So in the 2+ months since that original request, we went from
> scattered packages outside the Debian infrastructure to having a port
> in debian-ports infra, with >60% of packages built.
> 
> Unfortunately, important packages like binutils, glibc or linux-* have
> to stay in the separate "unreleased" suite for that reason, so the
> lack of support in dak for riscv64 is causing us to do this extra
> work, which would be otherwise unneeded

To add some further information: having to always manually build
and upload a number of otherwise perfectly working essential
riscv64 packages like glibc to unreleased due to the missing
dpkg/stable update doesn't only cause unnecessary additional work
for the riscv64 porters but also poses practical problems for
package maintainers trying to sort out portability issues as they
cannot simply debootstrap a current riscv64 chroot (and therefore
easily use pbuilder) because debootstrap cannot handle pulling
the base system from more than one suite (unstable+unreleased in
this case).

Previous stretch point releases have been published every 2.5-3
months, and since the 9.4 release more than two months have
passed already, so I would again like to ask the stable release
managers what exactly they require to be done for the proposed
dpkg update to be accepted into the 9.5 release.  Guillem had
asked a similar question already three weeks ago (see above), but
has AFAICS received no reply to it.  I would really like to avoid
the dpkg/stable update necessary for proper riscv64 support being
pushed back yet another release cycle because of communication
issues...

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#894297: cyrus-sasl2: diff for NMU version 2.1.27~101-g0780600+dfsg-3.1

[Karsten Merker]

Control: tags 894297 + pending

Hello,

I've uploaded an NMU for cyrus-sasl2 (versioned as 2.1.27~101-g0780600+dfsg-3.1)
to unstable as discussed in bug #894297. Attached is the nmudiff.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nru cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/changelog cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/changelog
--- cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/changelog	2017-03-19 13:30:33.0 +0100
+++ cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/changelog	2018-04-21 18:20:16.0 +0200
@@ -1,3 +1,10 @@
+cyrus-sasl2 (2.1.27~101-g0780600+dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload with maintainer permission.
+  * Add support for build-profiles. (Closes: #894297)
+
+ -- Karsten Merker <mer...@debian.org>  Sat, 21 Apr 2018 18:20:16 +0200
+
 cyrus-sasl2 (2.1.27~101-g0780600+dfsg-3) unstable; urgency=medium
 
   [ Holger Levsen ]
diff -Nru cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/control cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/control
--- cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/control	2016-12-31 15:59:34.0 +0100
+++ cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/control	2018-04-21 18:20:06.0 +0200
@@ -11,17 +11,17 @@
autotools-dev,
chrpath,
debhelper (>= 9),
-   default-libmysqlclient-dev | libmysqlclient-dev,
+   default-libmysqlclient-dev  | libmysqlclient-dev ,
dh-autoreconf,
docbook-to-man,
groff-base,
-   heimdal-multidev,
-   krb5-multidev,
+   heimdal-multidev ,
+   krb5-multidev ,
libdb-dev,
-   libkrb5-dev,
-   libldap2-dev,
+   libkrb5-dev ,
+   libldap2-dev ,
libpam0g-dev,
-   libpq-dev,
+   libpq-dev ,
libsqlite3-dev,
libssl-dev,
po-debconf,
@@ -119,6 +119,7 @@
 Depends: libsasl2-modules (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
+Build-Profiles: 
 Description: Cyrus SASL - pluggable authentication modules (LDAP)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
@@ -145,6 +146,7 @@
 Depends: libsasl2-modules (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
+Build-Profiles: 
 Description: Cyrus SASL - pluggable authentication modules (SQL)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
@@ -160,6 +162,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Conflicts: libsasl2-modules-gssapi-heimdal
+Build-Profiles: 
 Description: Cyrus SASL - pluggable authentication modules (GSSAPI)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
@@ -189,6 +192,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Conflicts: libsasl2-modules-gssapi-mit
+Build-Profiles: 
 Description: Pluggable Authentication Modules for SASL (GSSAPI)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
diff -Nru cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/rules cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/rules
--- cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/rules	2016-12-31 15:59:34.0 +0100
+++ cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/rules	2018-04-21 18:20:06.0 +0200
@@ -37,7 +37,7 @@
 BDB_VERSION ?= $(shell LC_ALL=C dpkg-query -l 'libdb[45].[0-9]-dev' | grep ^ii | sed -e 's|.*\s\libdb\([45]\.[0-9]\)-dev\s.*|\1|')
 
 # SQL support may be turned off during the build, but is on by default.
-ifeq (,$(findstring no-sql,$(DEB_BUILD_OPTIONS)))
+ifeq (,$(findstring no-sql,$(DEB_BUILD_OPTIONS))$(findstring pkg.cyrus-sasl2.nosql,$(DEB_BUILD_PROFILES)))
 	CONFIGURE_SQL=--enable-sql
 else
 	CONFIGURE_SQL=--disable-sql
@@ -45,7 +45,7 @@
 endif
 
 # LDAP support may be turned off during the build, but is on by default.
-ifeq (,$(findstring no-ldap,$(DEB_BUILD_OPTIONS)))
+ifeq (,$(findstring no-ldap,$(DEB_BUILD_OPTIONS))$(findstring pkg.cyrus-sasl2.noldap,$(DEB_BUILD_PROFILES)))
 	CONFIGURE_LDAP=--with-ldap
 	CONFIGURE_LDAPDB=--enable-ldapdb
 else
@@ -55,7 +55,7 @@
 endif
 
 # GSSAPI support may be turned off during the build, but is on by default
-ifeq (,$(findstring no-gssapi,$(DEB_BUILD_OPTIONS)))
+ifeq (,$(findstring no-gssapi,$(DEB_BUILD_OPTIONS))$(findstring pkg.cyrus-sasl2.nogssapi,$(DEB_BUILD_PROFILES)))
 	CONFIGURE_GSSAPI=--enable-gssapi
 else
 	CONFIGURE_GSSAPI=--disable-gssapi
@@ -206,7 +206,7 @@
 	# Alter the rpath of certain binaries and shared libraries.
 	chrpath -d debian/tmp/usr/sbin/sasldbl

Bug#894297: Intent to NMU cyrus-sasl2 (was: [PATCH] cyrus-sasl2: please add build-profile support)

[Karsten Merker]

On Wed, Mar 28, 2018 at 04:53:43PM +0200, Karsten Merker wrote:

[Architeture bootstrapping issues with cyrus-sasl2]
> Cyrus-sasl2 is involved in a circular dependency chain whose
> untangling requires building the package in multiple steps with
> reduced functionality and reduced build-dependencies.  To achieve
> that, debian/rules currently supports passing a number of options
> (no-sql, no-ldap and no-gssapi) in $(DEB_BUILD_OPTIONS).  This
> mechanism has the limitation that it requires manually adjusting the
> build-dependency list based on the options set and makes it hard to
> autobuild the package in a bootstrapping context.  The use of
> build-profiles (https://wiki.debian.org/BuildProfileSpec) would make
> this process quite a bit easier.  Attached is a patch that adds
> build-profile support to the packge while keeping the original
> $(DEB_BUILD_OPTIONS)-based mechanism in place.
> 
> The build profile names follow the "extension namespace" conventions
> from the build profile specification:
> 
> DEB_BUILD_OPTIONS -> build-profile name
> -
> no-sql-> pkg.cyrus-sasl2.nosql
> no-ldap   -> pkg.cyrus-sasl2.noldap
> no-gssapi -> pkg.cyrus-sasl2.nogssapi
> 
> It would be very helpful for our bootstrapping efforts if you could
> upload a version of the cyrus-sasl2 package with this patch applied to
> unstable in the near future.  For a standard build the patch changes
> nothing, so there should be no significant risk in applying it.

Hello Ondřej,

unless you should object, I intend to perform an NMU of cyrus-sasl2
with the patch from bug #894297 under Low-Threshold-NMU rules on
Sunday.

Reasons:

- Judging from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799864,
  the package changelog and the lack of activity on the
  pkg-cyrus-sasl2-debian-devel mailinglist, you appear to be the
  only remaining person in the cyrus-sasl2 packaging team.

- You have marked all your packages as "Low-Threshold-NMU" at
  https://wiki.debian.org/LowThresholdNmu.

- The patch from bug #894297 is largely noninvasive as it doesn't
  touch the actual cyrus-sasl2 codebase, only has any effect
  at all if a build-profile is explicitly enabled during building
  the package and uses the existing DEB_BUILD_OPTIONS-based
  infrastructure in debian/rules.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#896063: gcc-default-ports: cross compiler for RISC-V 32bit

[Karsten Merker]

On Thu, Apr 19, 2018 at 07:58:13AM +0200, Heinrich Schuchardt wrote:

> Source: gcc-defaults-ports
> Version: 1.176
> Severity: wishlist
> 
> Dear Maintainer,
> 
> we have a package to cross compile RISC-V 64-bit (gcc-riscv64-linux-gnu).
> 
> Could you, please, also provide a similar package to cross compile RISC-V
> 32-bit.
> 
> This package is needed when developing software for 32-bit embedded RISC-V
> systems.

Hello,

providing a gcc-riscv32-linux-gnu cross-compiler in Debian
unfortunately isn't possible yet as upstream glibc currently has
only support for riscv64, but not for riscv32.  Making
predictions about the future is obviously difficult, but from
looking at the current state of development I would guess that
riscv32 support probably won't make it into the glibc 2.28
release which is planned for August 1, 2018, so we are probably
talking about a timeframe of "sometime in 2019".

I'm CCing the debian-riscv list in case somebody there should
have further insights regarding riscv32 support in glibc.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic

[Karsten Merker]

On Wed, Apr 18, 2018 at 11:36:16AM +0200, Alberto Garcia wrote:
> On Wed, Apr 18, 2018 at 08:36:29AM +0200, Karsten Merker wrote:
> > Source: webkit2gtk
> > Version: 2.20.1-1
> > X-Debbugs-CC: debian-ri...@lists.debian.org
> > User: debian-ri...@lists.debian.org
> > Usertags: riscv64
> > 
> > Hello,
> > 
> > webkit2gtk 2.20.1-1 FTBFS on the riscv64 architecture with "undefined
> > reference to `__atomic_compare_exchange_1'". Full log at:
> 
> Is there any way that I can have access to / set up a riscv64 build
> environment in order to debug this problem?

Hello,

we don't yet have a "regular" porterbox for riscv64, but you can
run a local qemu-based riscv64 virtual machine.  A step-by-step
description of how to set it up is available in the Debian wiki
at

https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine

If there should be any problems with the setup, feel free to ask
me.

> Or, do you have a working patch for this ?

Unfortunately not.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#895934: [PATCH 1/1] flash-kernel: add Rockchip RK3288 Tinker Board

[Karsten Merker]

Control: tag 895934 pending

On Tue, Apr 17, 2018 at 05:41:51PM +0200, Heinrich Schuchardt wrote:
> Package: flash-kernel
> Version: 3.94
> Severity: wishlist
> Tags: patch
> 
> Add database entry for the Tinker Board.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  db/all.db | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/db/all.db b/db/all.db
> index 28d40b1..ff92e17 100644
> --- a/db/all.db
> +++ b/db/all.db
> @@ -412,6 +412,13 @@ Boot-Script-Path: /boot/boot.scr
>  U-Boot-Script-Name: bootscr.uboot-generic
>  Required-Packages: u-boot-tools
>  
> +Machine: Rockchip RK3288 Tinker Board
> +Kernel-Flavors: armp armmp-lpae
> +DTB-Id: rk3288-tinker.dtb
> +Boot-Script-Path: /boot/boot.scr
> +U-Boot-Script-Name: bootscr.uboot-generic
> +Required-Packages: u-boot-tools
> +
>  Machine: Firefly-RK3399 Board
>  Kernel-Flavors: arm64
>  DTB-Id: rk3399-firefly.dtb

Hello,

I've committed the patch to the flash-kernel git repository with
two tiny changes:

- I've fixed a typo in the kernel-flavors line (s/armp/armmp/).

- I've moved the entry to another position as we (at least
  nominally) sort the entries by the "Machine" field and not by
  the "DTB-Id" field.

I'll probably upload the package sometime on the upcoming
weekend.

Regards,
Karsten
--  
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#892504: [PATCH] nspr: Please add support for the RISC-V architecture

[Karsten Merker]

On Mon, Apr 09, 2018 at 09:35:29PM +0200, Karsten Merker wrote:

> attached is an updated packaging patch adding support for the
> RISC-V architecture to nspr package version 2:4.19-1.  The
> original patch that had been submitted to this bug had been for
> package version 2:4.18-1 and doesn't apply cleanly on version
> 2:4.19-1.
> 
> In addition to the updated packaging patch I have also attached
> a "bare" patch directly against upstream.

Hello,

upstream has reviewed the patch and accepted it for inclusion
into the upstream NSPR mercurial repository:

  https://hg.mozilla.org/projects/nspr/rev/f47871e2aeb1

It would be great if you could upload a new version of the Debian
nspr 2:4.19 package with the patch included.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#892504: [PATCH] nspr: Please add support for the RISC-V architecture

[Karsten Merker]

Hello,

attached is an updated packaging patch adding support for the
RISC-V architecture to nspr package version 2:4.19-1.  The
original patch that had been submitted to this bug had been for
package version 2:4.18-1 and doesn't apply cleanly on version
2:4.19-1.

In addition to the updated packaging patch I have also attached
a "bare" patch directly against upstream.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur nspr-4.19.orig/debian/patches/Add-type-definitions-for-the-RISC-V-architecture.patch nspr-4.19/debian/patches/Add-type-definitions-for-the-RISC-V-architecture.patch
--- nspr-4.19.orig/debian/patches/Add-type-definitions-for-the-RISC-V-architecture.patch	1970-01-01 00:00:00.0 +
+++ nspr-4.19/debian/patches/Add-type-definitions-for-the-RISC-V-architecture.patch	2018-04-09 18:37:58.232415922 +
@@ -0,0 +1,131 @@
+From d4b3321b5eeb7976a8ca2169128a3754e3b2a8bd Mon Sep 17 00:00:00 2001
+From: Karsten Merker <mer...@debian.org>
+Date: Fri, 9 Mar 2018 19:38:12 +0100
+Subject: [PATCH] Add type definitions for the RISC-V architecture.
+
+---
+ nspr/pr/include/md/_linux.cfg | 92 +++
+ nspr/pr/include/md/_linux.h   |  4 ++
+ 2 files changed, 96 insertions(+)
+
+diff --git a/nspr/pr/include/md/_linux.cfg b/nspr/pr/include/md/_linux.cfg
+index b4c0ed4..afc407c 100644
+--- a/nspr/pr/include/md/_linux.cfg
 b/nspr/pr/include/md/_linux.cfg
+@@ -1020,6 +1020,98 @@
+ #define PR_BYTES_PER_WORD_LOG2   2
+ #define PR_BYTES_PER_DWORD_LOG2  3
+ 
++#elif defined(__riscv) && (__riscv_xlen == 32)
++
++#undef  IS_BIG_ENDIAN
++#define IS_LITTLE_ENDIAN 1
++#undef  IS_64
++
++#define PR_BYTES_PER_BYTE   1
++#define PR_BYTES_PER_SHORT  2
++#define PR_BYTES_PER_INT4
++#define PR_BYTES_PER_INT64  8
++#define PR_BYTES_PER_LONG   4
++#define PR_BYTES_PER_FLOAT  4
++#define PR_BYTES_PER_DOUBLE 8
++#define PR_BYTES_PER_WORD   4
++#define PR_BYTES_PER_DWORD  8
++
++#define PR_BITS_PER_BYTE8
++#define PR_BITS_PER_SHORT   16
++#define PR_BITS_PER_INT 32
++#define PR_BITS_PER_INT64   64
++#define PR_BITS_PER_LONG32
++#define PR_BITS_PER_FLOAT   32
++#define PR_BITS_PER_DOUBLE  64
++#define PR_BITS_PER_WORD32
++
++#define PR_BITS_PER_BYTE_LOG2   3
++#define PR_BITS_PER_SHORT_LOG2  4
++#define PR_BITS_PER_INT_LOG25
++#define PR_BITS_PER_INT64_LOG2  6
++#define PR_BITS_PER_LONG_LOG2   5
++#define PR_BITS_PER_FLOAT_LOG2  5
++#define PR_BITS_PER_DOUBLE_LOG2 6
++#define PR_BITS_PER_WORD_LOG2   5
++
++#define PR_ALIGN_OF_SHORT   2
++#define PR_ALIGN_OF_INT 4
++#define PR_ALIGN_OF_LONG4
++#define PR_ALIGN_OF_INT64   8
++#define PR_ALIGN_OF_FLOAT   4
++#define PR_ALIGN_OF_DOUBLE  8
++#define PR_ALIGN_OF_POINTER 4
++#define PR_ALIGN_OF_WORD4
++
++#define PR_BYTES_PER_WORD_LOG2  2
++#define PR_BYTES_PER_DWORD_LOG2 3
++
++#elif defined(__riscv) && (__riscv_xlen == 64)
++
++#undef  IS_BIG_ENDIAN
++#define IS_LITTLE_ENDIAN 1
++#define IS_64
++
++#define PR_BYTES_PER_BYTE   1
++#define PR_BYTES_PER_SHORT  2
++#define PR_BYTES_PER_INT4
++#define PR_BYTES_PER_INT64  8
++#define PR_BYTES_PER_LONG   8
++#define PR_BYTES_PER_FLOAT  4
++#define PR_BYTES_PER_DOUBLE 8
++#define PR_BYTES_PER_WORD   8
++#define PR_BYTES_PER_DWORD  8
++
++#define PR_BITS_PER_BYTE8
++#define PR_BITS_PER_SHORT   16
++#define PR_BITS_PER_INT 32
++#define PR_BITS_PER_INT64   64
++#define PR_BITS_PER_LONG64
++#define PR_BITS_PER_FLOAT   32
++#define PR_BITS_PER_DOUBLE  64
++#define PR_BITS_PER_WORD64
++
++#define PR_BITS_PER_BYTE_LOG2   3
++#define PR_BITS_PER_SHORT_LOG2  4
++#define PR_BITS_PER_INT_LOG25
++#define PR_BITS_PER_INT64_LOG2  6
++#define PR_BITS_PER_LONG_LOG2   6
++#define PR_BITS_PER_FLOAT_LOG2  5
++#define PR_BITS_PER_DOUBLE_LOG2 6
++#define PR_BITS_PER_WORD_LOG2   6
++
++#define PR_ALIGN_OF_SHORT   2
++#define PR_ALIGN_OF_INT 4
++#define PR_ALIGN_OF_LONG8
++#define PR_ALIGN_OF_INT64   8
++#define PR_ALIGN_OF_FLOAT   4
++#define PR_ALIGN_OF_DOUBLE  8
++#define PR_ALIGN_OF_POINTER 8
++#define PR_ALIGN_OF_WORD8
++
++#define PR_BYTES_PER_WORD_LOG2  3
++#define PR_BYTES_PER_DWORD_LOG2 3
++
+ #else
+ 
+ #error "Unknown CPU architecture"
+diff --git a/nspr/pr/include/md/_linux.h b/nspr/pr/include/md/_linux.h
+index b4b298b..2370ab8 100644
+--- a/nspr/pr/include/md/_linux.h
 b/nspr/pr/include/md/_linux.h
+@@ -57,6 +57,10 @@
+ #define _PR_SI_ARCHITECTURE "m32r"
+ #elif defined(__or1k__)
+ #define _PR_SI_ARCHITECTURE "or1k"
++#elif defined(__riscv) && (__riscv_xlen == 32)
++#define _PR_SI_ARCHITECTURE "riscv32"
++#elif defined(__riscv) && (__riscv_xlen == 64)
++#define _PR_SI_ARCHITECTURE "riscv64"
+ #else
+ #error "Unknown CPU architecture"
+ #endif
+-- 
+2.11.

Bug#894505: [PATCH] meson: meson-related problem when crossbuilding systemd

[Karsten Merker]

Package: meson
Version: 0.45.1-1
Tags: patch
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V).  The
systemd package - which uses meson as its build system - is part
of the build-dependency chain for the essential package set, so
we need to cross-build systemd to be able to complete the
bootstrap process.  Due to the meson issue at

  https://github.com/mesonbuild/meson/issues/3113

it currently isn't possible to crossbuild the systemd package in
Debian. A fix for this is already in upstream meson git at

  
https://github.com/mesonbuild/meson/commit/c4192a04fd3d46ac7a0ee81a158e7b1e3d4f06f8

but not part of the most-recent upstream meson release (0.45.1). 
It would be great if you could carry this one-line patch in the
Debian meson package until a new upstream release including this
fix is available.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#894385: [PATCH] cracklib2: Add support for a "nopython" build-profile

[Karsten Merker]

Package: cracklib2
Version: 2.9.2-5.1
Severity: wishlist
Tags: patch
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V). The
libcrack2-dev, libcrack2 and cracklib-runtime packages are part
of the build-dependency chain for the essential package set, so
we need to build them to be able to complete the bootstrap
process.

Currently the cracklib2 source package unconditionally
build-depends on python2 and python3, but those aren't available
during early architecture bootstrap and are only needed for
building python{,3}-cracklib, but not for cracklib-runtime,
libcrack2 and libcrack2-dev.  The package's debian/rules already
contains support for a build without python by setting the
DEB_STAGE variable to "stage1", but this mechanism has the
limitation that it requires manually adjusting the
build-dependency list and makes it hard to autobuild the package
in a bootstrapping context.  Because of this limitation, the
DEB_STAGE mechanism has been deprecated; packages should now
support build-profiles (https://wiki.debian.org/BuildProfileSpec).

Attached is a patch that adds support for the standard "nopython"
build-profile to the package while keeping the original
DEB_STAGE-based mechanism in place.  As the cracklib2 package is
on the "Low Threshold NMU" list, I intend to do an NMU with this
patch on the upcoming weekend unless you should object.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur cracklib2-2.9.2.orig/debian/control cracklib2-2.9.2/debian/control
--- cracklib2-2.9.2.orig/debian/control
+++ cracklib2-2.9.2/debian/control
@@ -14,10 +14,10 @@
docbook-xml,
dpkg-dev (>= 1.16.1~),
libtool,
-   python-all-dev (>= 2.6.6-3~),
-   python-setuptools,
-   python3-all-dev (>= 3.1.3-2~),
-   python3-setuptools
+   python-all-dev (>= 2.6.6-3~) ,
+   python-setuptools ,
+   python3-all-dev (>= 3.1.3-2~) ,
+   python3-setuptools 
 Homepage: http://sourceforge.net/projects/cracklib
 Vcs-Git: https://anonscm.debian.org/git/pkg-cracklib/pkg-cracklib.git
 Vcs-Browser: https://anonscm.debian.org/gitweb/?p=pkg-cracklib/pkg-cracklib.git
@@ -90,6 +90,7 @@
  ${shlibs:Depends}
 Provides: ${python:Provides}
 Conflicts: python-crack
+Build-Profiles: 
 Description: Python bindings for password checker library cracklib2
  This package provides Python bindings for cracklib. It contains a
  pythonic interface to cracklib's functions and some Python
@@ -108,6 +109,7 @@
  ${python3:Depends},
  ${shlibs:Depends}
 Provides: ${python3:Provides}
+Build-Profiles: 
 Description: Python3 bindings for password checker library cracklib2
  This package provides Python bindings for cracklib. It contains a
  pythonic interface to cracklib's functions and some Python
diff -Nur cracklib2-2.9.2.orig/debian/rules cracklib2-2.9.2/debian/rules
--- cracklib2-2.9.2.orig/debian/rules
+++ cracklib2-2.9.2/debian/rules
@@ -10,11 +10,13 @@
 DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
-ifneq ($(DEB_STAGE),stage1)
+ifeq ($(filter stage1,$(DEB_STAGE))$(filter nopython,$(DEB_BUILD_PROFILES)),)
 PYVERS := $(shell pyversions -vs)
 PY3VERS := $(shell py3versions -vs)
+DH_WITH_PARAMETERS := python2,python3,autotools_dev
 else
 NOPYTHON_OPTIONS = -Npython-cracklib -Npython3-cracklib
+DH_WITH_PARAMETERS := autotools_dev
 endif
 
 ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
@@ -48,7 +50,7 @@
 
 override_dh_auto_build:
 	$(MAKE) -C $(CURDIR)/debian/buildtmp/base
-ifneq ($(DEB_STAGE),stage1)
+ifeq ($(filter stage1,$(DEB_STAGE))$(filter nopython,$(DEB_BUILD_PROFILES)),)
 	ln -s $(CURDIR)/debian/crack.py $(CURDIR)/python; \
 	for i in $(PYVERS) $(PY3VERS); do \
 		cd $(CURDIR)/debian/buildtmp/python$$i; \
@@ -62,7 +64,7 @@
 
 override_dh_auto_test:
 	mkdir $(CURDIR)/debian/tmp
-ifneq ($(DEB_STAGE),stage1)
+ifeq ($(filter stage1,$(DEB_STAGE))$(filter nopython,$(DEB_BUILD_PROFILES)),)
 	$(CRACKLIB_PACKER) $(CURDIR)/debian/tmp/cracklib_dict < \
 	 $(CURDIR)/dicts/cracklib-small
 	for i in $(PYVERS) $(PY3VERS); do \
@@ -120,7 +122,7 @@
 	  $(CURDIR)/debian/cracklib-runtime/usr/sbin/cracklib-packer \
 	  $(CURDIR)/debian/cracklib-runtime/usr/sbin/cracklib-unpacker
 
-ifneq ($(DEB_STAGE),stage1)
+ifeq ($(filter stage1,$(DEB_STAGE))$(filter nopython,$(DEB_BUILD_PROFILES)),)
 	for i in $(PYVERS); do \
 		cd $(CURDIR)/debian/buildtmp/python$$i/python; \
 		python$$i setup.py install --install-layout=deb --root $(CURDIR)/debian/python-cracklib; \
@@ -139,7 +141,7 @@
 

Bug#894314: [PATCH] audit: Please add support for a pkg.audit.noldap build-profile

[Karsten Merker]

Package: audit
Version: 1:2.8.2-1
Severity: wishlist
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V). The
audit package is part of the build-dependency chain for the
essential package set, so we need to build it to be able to
complete the bootstrap process.

Unfortunately audit is involved in a circular set of
build-dependencies: audit build-depends on openldap, openldap
build-depends on cyrus-sasl, cyrus-sasl build-depends on pam and
pam build-depends on audit, which is where the cat chases its
tail :-).

To break this circular dependency in a proper way, it is necessary
to add a build-profile (https://wiki.debian.org/BuildProfileSpec)
to audit which allows building the package without support for
openldap.  AIUI, the only binary package built from the audit
source that actually needs openldap is audispd-plugins, in
particular the zos-remote plugin.  Attached is a patch that adds
support for a pkg.audit.noldap build-profile that does two things
when enabled:

  - disable the build-dependency on libldap2-dev
  - disable building the audispd-plugins binary package

It would be great if you could upload a version of audit with
this patch included to unstable soon as we depend on it for
continuing with our bootstrapping efforts.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur audit-2.8.2.orig/debian/control audit-2.8.2.new/debian/control
--- audit-2.8.2.orig/debian/control
+++ audit-2.8.2.new/debian/control
@@ -10,7 +10,7 @@
 # audit sources embed their own patched version of libev
 #   libev-dev,
libkrb5-dev,
-   libldap2-dev,
+   libldap2-dev ,
libprelude-dev,
libwrap0-dev,
python-all-dev:any (>= 2.6.6-3~) ,
@@ -138,6 +138,7 @@
 Section: admin
 Architecture: linux-any
 Depends: auditd, ${misc:Depends}, ${shlibs:Depends}
+Build-Profiles: 
 Description: Plugins for the audit event dispatcher
  The audispd-plugins package provides plugins for the real-time
  interface to the audit system, audispd. These plugins can do things
diff -Nur audit-2.8.2.orig/debian/rules audit-2.8.2.new/debian/rules
--- audit-2.8.2.orig/debian/rules	2017-12-18 08:13:02.0 +
+++ audit-2.8.2.new/debian/rules	2018-03-28 17:38:29.354936110 +
@@ -30,6 +30,10 @@
   EXTRA_ARCH_TABLE := --with-hppa
 endif
 
+ifneq ($(filter pkg.audit.noldap,$(DEB_BUILD_PROFILES)),)
+  CONFIGURE_FLAGS += --disable-zos-remote
+endif
+
 %:
 	dh $@ --builddirectory=debian/build --buildsystem=autoconf $(DH_ADDONS)
 

Bug#894297: [PATCH] cyrus-sasl2: please add build-profile support

[Karsten Merker]

Package: cyrus-sasl2
Version: 2.1.27~101-g0780600+dfsg-3
Severity: wishlist
Tags: patch
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V). The
cyrus-sasl2 package is part of the build-dependency chain for the
essential package set, so we need to build it to be able to
complete the bootstrap process.

Cyrus-sasl2 is involved in a circular dependency chain whose
untangling requires building the package in multiple steps with
reduced functionality and reduced build-dependencies.  To achieve
that, debian/rules currently supports passing a number of options
(no-sql, no-ldap and no-gssapi) in $(DEB_BUILD_OPTIONS).  This
mechanism has the limitation that it requires manually adjusting the
build-dependency list based on the options set and makes it hard to
autobuild the package in a bootstrapping context.  The use of
build-profiles (https://wiki.debian.org/BuildProfileSpec) would make
this process quite a bit easier.  Attached is a patch that adds
build-profile support to the packge while keeping the original
$(DEB_BUILD_OPTIONS)-based mechanism in place.

The build profile names follow the "extension namespace" conventions
from the build profile specification:

DEB_BUILD_OPTIONS -> build-profile name
-
no-sql-> pkg.cyrus-sasl2.nosql
no-ldap   -> pkg.cyrus-sasl2.noldap
no-gssapi -> pkg.cyrus-sasl2.nogssapi

It would be very helpful for our bootstrapping efforts if you could
upload a version of the cyrus-sasl2 package with this patch applied to
unstable in the near future.  For a standard build the patch changes
nothing, so there should be no significant risk in applying it.

JFTR one thing that I have found while testing the patch: the three
options/profiles are in practice not completely independent from each
other.  The main purpose of the no-gssapi option is to remove the
dependency on kerberos, but if the package is built with SQL support
(i.e. pkg.cyrus-sasl2.nogssapi is set but pkg.cyrus-sasl2.nosql is
not), libpq5 by default pulls in krb5 nonetheless.  The same limitation
applies to the existing mechanism, so this isn't a regression compared
to what we have now.  It definitely makes sense to have separate
options/profiles for no-gssapi and no-sql though, as postgresql
supports a stage1 build without krb5 for bootstrapping purposes and in
this case they are really independent from each other.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur cyrus-sasl2-2.1.27~101-g0780600+dfsg.orig/debian/control cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/control
--- cyrus-sasl2-2.1.27~101-g0780600+dfsg.orig/debian/control
+++ cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/control
@@ -11,17 +11,17 @@
autotools-dev,
chrpath,
debhelper (>= 9),
-   default-libmysqlclient-dev | libmysqlclient-dev,
+   default-libmysqlclient-dev  | libmysqlclient-dev ,
dh-autoreconf,
docbook-to-man,
groff-base,
-   heimdal-multidev,
-   krb5-multidev,
+   heimdal-multidev ,
+   krb5-multidev ,
libdb-dev,
-   libkrb5-dev,
-   libldap2-dev,
+   libkrb5-dev ,
+   libldap2-dev ,
libpam0g-dev,
-   libpq-dev,
+   libpq-dev ,
libsqlite3-dev,
libssl-dev,
po-debconf,
@@ -119,6 +119,7 @@
 Depends: libsasl2-modules (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
+Build-Profiles: 
 Description: Cyrus SASL - pluggable authentication modules (LDAP)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
@@ -145,6 +146,7 @@
 Depends: libsasl2-modules (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
+Build-Profiles: 
 Description: Cyrus SASL - pluggable authentication modules (SQL)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
@@ -160,6 +162,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Conflicts: libsasl2-modules-gssapi-heimdal
+Build-Profiles: 
 Description: Cyrus SASL - pluggable authentication modules (GSSAPI)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
@@ -189,6 +192,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Conflicts: libsasl2-modules-gssapi-mit
+Build-Profiles: 
 Description: Pluggable Authentication Modules for SASL (GSSAPI)
  This is the 

Bug#891341: libatomic-ops: [PATCH] Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Karsten Merker]

On Sat, Feb 24, 2018 at 06:09:30PM +0100, Manuel A. Fernandez Montecelo wrote:

> Source: libatomic-ops
> Version: 7.6.2-1
> Severity: normal
> Tags: patch upstream fixed-upstream
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> Forwarded: 
> https://github.com/ivmai/libatomic_ops/commit/27ca1b0f306cb99f14f863b22d490bb30c778300
> 
> Hello,
> 
> We need support in this package for RISC-V, to bootstrap the riscv64
> architecture.
> 
> A patch has been submitted upstream a few days ago, so it would be great if 
> you
> could include it as a patch and release a new version for unstable.
> 
> If we can help by NMUing the package or anything else, please let me/us know.
> 
> Thanks and cheers.
> --
> Manuel A. Fernandez Montecelo 

Hello Ian,

as one month has passed since the submission above I wanted to
kindly ask you about the state of affairs regarding this bug. 
Libatomic-ops is a hard requirement for building the essential
package set and a lot of packages transitively build-depend on
it, so the Debian riscv64 port cannot move forward without
having RISC-V support in the libatomic-ops package.

Attached is a patch against the Debian packaging that adds
four patches cherry-picked from upstream as quilt patches:

  
https://github.com/ivmai/libatomic_ops/commit/27ca1b0f306cb99f14f863b22d490bb30c778300
  
https://github.com/ivmai/libatomic_ops/commit/84ef64ebbf3df35756d083d08620b167547d6860
  
https://github.com/ivmai/libatomic_ops/commit/4f68118ead90f5a2940cea6baa28d24ab2fb9f74
  
https://github.com/ivmai/libatomic_ops/commit/393d7a7ff54565230f44e59a9c73addc9e627f56

It would be great if you could upload a new version of
libatomic-ops to unstable with these patches applied, so
that we can move forward with our port.

Kind regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur libatomic-ops-7.6.2.orig/debian/patches/riscv-0001-Add-RISC-V-support.patch libatomic-ops-7.6.2/debian/patches/riscv-0001-Add-RISC-V-support.patch
--- libatomic-ops-7.6.2.orig/debian/patches/riscv-0001-Add-RISC-V-support.patch
+++ libatomic-ops-7.6.2/debian/patches/riscv-0001-Add-RISC-V-support.patch
@@ -0,0 +1,65 @@
+From 235b22468d0cdc0718feed41067a5ceeb7079f98 Mon Sep 17 00:00:00 2001
+From: Shea Levy 
+Date: Sun, 18 Feb 2018 00:47:44 -0500
+Subject: [PATCH 1/4] Add RISC-V support
+Origin: https://github.com/ivmai/libatomic_ops/commit/27ca1b0f306cb99f14f863b22d490bb30c778300
+
+Issue #31 (libatomic_ops).
+
+* src/Makefile.am (nobase_private_HEADERS): Add riscv.h entry.
+* src/atomic_ops.h [__riscv]: Include riscv.h file.
+* src/atomic_ops/sysdeps/gcc/riscv.h: New file (just include generic.h).
+---
+ src/Makefile.am|  1 +
+ src/atomic_ops.h   |  3 +++
+ src/atomic_ops/sysdeps/gcc/riscv.h | 12 
+ 3 files changed, 16 insertions(+)
+ create mode 100644 src/atomic_ops/sysdeps/gcc/riscv.h
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index dadc932..084dd3c 100644
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -92,6 +92,7 @@ nobase_private_HEADERS = atomic_ops/ao_version.h \
+   atomic_ops/sysdeps/gcc/mips.h \
+   atomic_ops/sysdeps/gcc/nios2.h \
+   atomic_ops/sysdeps/gcc/powerpc.h \
++  atomic_ops/sysdeps/gcc/riscv.h \
+   atomic_ops/sysdeps/gcc/s390.h \
+   atomic_ops/sysdeps/gcc/sh.h \
+   atomic_ops/sysdeps/gcc/sparc.h \
+diff --git a/src/atomic_ops.h b/src/atomic_ops.h
+index 187e1f9..22e516f 100644
+--- a/src/atomic_ops.h
 b/src/atomic_ops.h
+@@ -352,6 +352,9 @@
+ # if defined(__tile__)
+ #   include "atomic_ops/sysdeps/gcc/tile.h"
+ # endif
++# if defined(__riscv)
++#   include "atomic_ops/sysdeps/gcc/riscv.h"
++# endif
+ #endif /* __GNUC__ && !AO_USE_PTHREAD_DEFS */
+ 
+ #if (defined(__IBMC__) || defined(__IBMCPP__)) && !defined(__GNUC__) \
+diff --git a/src/atomic_ops/sysdeps/gcc/riscv.h b/src/atomic_ops/sysdeps/gcc/riscv.h
+new file mode 100644
+index 000..412c395
+--- /dev/null
 b/src/atomic_ops/sysdeps/gcc/riscv.h
+@@ -0,0 +1,12 @@
++/*
++ * THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED
++ * OR IMPLIED.  ANY USE IS AT YOUR OWN RISK.
++ *
++ * Permission is hereby granted to use or copy this program
++ * for any purpose,  provided the above notices are retained on all copies.
++ * Permission to modify the code and to distribute modified code is granted,
++ * provided the above notices are retained, and a notice that the code was
++ * modified is included with the above copyright notice.
++ */
++
++#include "generic.h"
+-- 
+2.11.0
+
diff -Nur libatomic-ops-7.6.2.orig/debian/patches/riscv-0002-Update-AUTHORS-file-add-Shea-Levy.patch libatomic-ops-7.6.2/debian/patches/riscv-0002-Update-AUTHORS-file-add-Shea-Levy.patch
--- 

Bug#893300: cdebconf: Adding support for a pkg.cdebconf.nogtk build-profile

[Karsten Merker]

On Mon, Mar 26, 2018 at 12:47:18AM +0100, Colin Watson wrote:
> On Sat, Mar 17, 2018 at 09:09:11PM +0100, Karsten Merker wrote:
> > I would like to add support for a "pkg.cdebconf.nogtk" build-profile
> > to cdebconf.  Background for that is that cdebconf (in particular
> > libdebconfclient0) is needed rather early in the process of
> > bootstrapping a new Debian architecture, but getting it built during
> > early architecture bootstrap is difficult due to its build-dependency
> > on gtk+cairo, which pulls in an enormous list of transitive
> > build-dependencies that are effectively impossible to fullfill in a
> > bootstrap scenario.
> 
> This approach and patch looks good to me.  I'm OK with you committing
> and uploading it, modulo the comments below.
> 
> > diff --git a/debian/rules b/debian/rules
> > index b2b35f4d..8b85a7af 100755
> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -21,6 +21,11 @@ LIBDEBCONF=libdebconfclient0
> >  DEB_FRONTENDS=passthrough text newt gtk
> >  UDEB_FRONTENDS=passthrough text newt gtk
> >  
> > +ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
> > +DEB_FRONTENDS:=$(filter-out gtk,$(DEB_FRONTENDS))
> > +UDEB_FRONTENDS:=$(filter-out gtk,$(UDEB_FRONTENDS))
> > +endif
> 
> I think this would be clearer reversed, i.e.:
> 
>   DEB_FRONTENDS=passthrough text newt
>   UDEB_FRONTENDS=passthrough text newt
> 
>   ifeq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
>   DEB_FRONTENDS+=gtk
>   UDEB_FRONTENDS+=gtk
>   endif

That's probably a matter of taste :-).  I found it clearer to
have the primary DEB_FRONTENDS and UDEB_FRONTENDS assignments to
always represent the default case when no build-profiles are
enabled and only modify them in the "non-standard" case of having
a build-profile set.  If you have a strong preference for the
"additive" version instead of the "subtractive" version, please
let me know and I'll change that.
 
> > +ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
> > +   dh_install -plibdebconfclient0-dev 
> > src/modules/frontend/gtk/cdebconf_gtk.h usr/include/cdebconf/
> > +endif
> 
> I think I may understand what this is doing now after some confusion,
> but it's pretty opaque and definitely needs at least a comment.  I think
> you're trying to keep the package contents identical regardless of build
> profile, since the main build system won't handle it in this case due to
> the change in *_FRONTENDS?

Exactly. I'll add a comment explaining that.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#891803: cracklib2: diff for NMU version 2.9.2-5.1

[Karsten Merker]

Control: tags 891803 + patch
Control: tags 891803 + pending

Dear maintainer,

I've prepared an NMU for cracklib2 (versioned as 2.9.2-5.1) and
will upload it now. Attached is the nmudiff.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nru cracklib2-2.9.2/debian/changelog cracklib2-2.9.2/debian/changelog
--- cracklib2-2.9.2/debian/changelog	2017-05-27 11:41:18.0 +0200
+++ cracklib2-2.9.2/debian/changelog	2018-03-21 22:39:38.0 +0100
@@ -1,3 +1,11 @@
+cracklib2 (2.9.2-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove the ":native" annotation from the "cracklib-runtime "
+build-dependency. (Closes: #891803)
+
+ -- Karsten Merker <mer...@debian.org>  Wed, 21 Mar 2018 22:39:38 +0100
+
 cracklib2 (2.9.2-5) unstable; urgency=medium
 
   * Add Breaks: cracklib-runtime (<< 2.9.2-4) to libcrack2 to configure
diff -Nru cracklib2-2.9.2/debian/control cracklib2-2.9.2/debian/control
--- cracklib2-2.9.2/debian/control	2017-05-27 11:06:18.0 +0200
+++ cracklib2-2.9.2/debian/control	2018-03-21 22:39:20.0 +0100
@@ -8,7 +8,7 @@
automake (>= 1.10),
autotools-dev,
chrpath,
-   cracklib-runtime:native ,
+   cracklib-runtime ,
debhelper (>= 9),
docbook-utils,
docbook-xml,

Bug#890791: stretch-pu: package dpkg/1.18.25

[Karsten Merker]

On Wed, Feb 28, 2018 at 06:45:49PM +, Adam D. Barratt wrote:
> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
> [..]
> > 2018-02-18 22:26 Guillem Jover:
> [...]
> > > I'd like to update dpkg in stretch. This includes several fixes for
> > > documentation, regressions, misbheavior, minor security issues, and
> > > a new arch definition so that DAK can accept packages using it. The
> > > fixes have been in sid/buster for a while now.
> > 
> > We depend on this version being accepted and installed in the systems
> > where DAK lives to learn about the new architecture.  After that,
> > several other packages can add support for the architecture, without
> > receiving an automatic reject when uploaded.
> > 
> > It would be great if this update could enter in the next stable
> > update, so we can make progress on that front.
> 
> We've been discussing this amongst the SRMs and are quite wary of a
> dpkg update this close to the p-u freeze. We appreciate that the
> changes individually seem self-contained but would like to have an
> update of such a key package able to be tested more than is feasible in
> the time available.
> 
> (On a related note, in practical terms it's very unlikely that there
> would be sufficient time to get the new strings that are introduced 
> translated.)
> 
> We understand that this is inconvenient for the riscv porters, so are
> exploring whether it would be possible to have the dak support made
> available via p-u after the upcoming point release.

Hello,

I wanted to kindly ask whether there are any news on this topic
and whether there is anything that the RISC-V porters can do 
to help.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#721358: bug#28574: coreutils: use dummy man when cross build

[Karsten Merker]

Control: user debian-ri...@lists.debian.org
Control: usertag -1 + riscv64

[coreutils not cross-buildable due to help2man issues]

On Sat, Sep 30, 2017 at 08:56:53PM -0700, Pádraig Brady wrote:
> On 23/09/17 20:18, Peter Bohning wrote:
> > Cross compiling for aarch64 from amd64
> >  
> > Is there no way to disable the man pages in configure options?  Thanks.
> >  
> > https://lists.gnu.org/archive/html/coreutils/2014-11/msg0.html
> 
> I've seen this issue in various places now (CC'd).
> 
> We should probably reinstate distribution of man pages
> since these generated pages are so similar on various systems.
> Also given the amount of old ChangeLogs removed recently
> I don't think the addition of 273K (uncompressed) is prohibitive.
> 
> The attached was tested in these modes:
>  git repo build
>  tarball build with/without help2man
>  tarball vpath build with/without help2man
>  make distcheck
>  make install  (and ensure only enabled program man pages installed)
> 
> I've not applied this yet, but hope to soon after a bit more testing.
> 
> cheers,
> Pádraig

Hello,

we are currently in the process of bootstrapping a new Debian
architecture (riscv64, https://wiki.debian.org/RISC-V) and
therefore affected by this problem.  The underlying issue has
been solved in upstream coreutils 8.29, so I would like to ask
whether it would perhaps be possible for you to update coreutils
in unstable to version 8.29.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#891803: [PATCH] cracklib2: please remove the ":native" annotation from the cracklib-runtime build-dependency for cross-builds

[Karsten Merker]

On Thu, Mar 01, 2018 at 12:07:39AM +0100, Karsten Merker wrote:
> Source: cracklib2
> Version: 2.9.2-5
> Severity: normal
> Tags: patch
> X-Debbugs-CC: debian-ri...@lists.debian.org
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Hello,
> 
> the cracklib2 build-dependency list in debian/control currently
> contains the following entry:
> 
>   Build-Depends: cracklib-runtime:native 
> 
> The cracklib-runtime package is (correctly) marked as "Multi-Arch:
> foreign".  Because of this the ":native" annotation in the
> cracklib2 build-depends needs to be removed as it creates an
> unresolvable cross-dependency due to the fact that dpkg doesn't
> consider M-A:foreign packages as valid candidates for fulfilling a
> dependency with a ":native" annotation.
> 
> For more information regarding this please cf.
> https://wiki.debian.org/Multiarch/MissingRationale#Why_do_M-A:foreign_packages_not_satisfy_:native_qualified_dependencies_in_build-dependencies.3F
> 
> Attached is a corresponding patch against the current
> pkg-cracklib git head.

Hello,

I've just seen that the package is on the lowNMU list, so unless you
should object, I intend to do an NMU within the next days.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#893300: cdebconf: Adding support for a pkg.cdebconf.nogtk build-profile

[Karsten Merker]

Package: cdebconf
Version: 0.241
Priority: wishlist
X-Debbugs-CC: Cyril Brulebois <k...@debian.org>, Christian Perrier 
<bubu...@debian.org>, Regis Boudin <re...@debian.org>, Colin Watson 
<cjwat...@debian.org>, debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

[CCing the uploaders for cdebconf]

Hello,

I would like to add support for a "pkg.cdebconf.nogtk" build-profile
to cdebconf.  Background for that is that cdebconf (in particular
libdebconfclient0) is needed rather early in the process of
bootstrapping a new Debian architecture, but getting it built during
early architecture bootstrap is difficult due to its build-dependency
on gtk+cairo, which pulls in an enormous list of transitive
build-dependencies that are effectively impossible to fullfill in a
bootstrap scenario.

AIUI, the only binary packages built from the cdebconf source package
that actually need gtk+cairo are cdebconf-gtk and cdebconf-gtk-udeb,
and these aren't required during an architecture bootstrap, so the
approach is to add a build-profile that does two things when set:

- disable building of these two binary packages
- remove the gtk+cairo build-dependency

Attached is a patch that implements that. As nothing changes when
the build-profile isn't explicitly activiated, this should be a
low-risc modification, but as I normally don't work on cdebconf, I
would like to gather feedback from the regular uploaders (in CC)
whether you see some reason to object to this change.
The debdiff between a standard build and a build with the
build-profile set is clean; the only difference with the
build-profile enabled is that the gtk-related binary packages
aren't built.

If the patch is ok for you, I'll apply it to cdebconf git and
upload a new version.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
>From acd6f9d3065137727e7c372c306cda67adfff9b9 Mon Sep 17 00:00:00 2001
From: Karsten Merker <mer...@debian.org>
Date: Thu, 15 Mar 2018 20:10:33 +
Subject: [PATCH] Add a pkg.cdebconf.nogtk build-profile.

When the pkg.cdebconf.nogtk profile is set, the build-dependency on
gtk and cairo gets removed and the cdebconf-gtk and cdebconf-gtk-udeb
binary packages (which are the only ones actually depending on gtk
and cairo) aren't built.  This is important when bootstrapping a new
architecture as cdebconf is required for building the essential
package set and a dependency on gtk and cairo pulls in an enormous
list of transitive build-dependencies that are effectively impossible
to fullfill in a bootstrap scenario.
---
 debian/control | 6 --
 debian/rules   | 8 
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 1a194849..b87c0861 100644
--- a/debian/control
+++ b/debian/control
@@ -9,8 +9,8 @@ Build-Depends:
  libtextwrap-dev (>= 0.1-5),
  libdebian-installer4-dev (>= 0.41) | libdebian-installer-dev,
  libglib2.0-dev (>= 2.31),
- libgtk2.0-dev (>= 2.24),
- libcairo2-dev (>= 1.8.10-3),
+ libgtk2.0-dev (>= 2.24) ,
+ libcairo2-dev (>= 1.8.10-3) ,
  libselinux1-dev (>= 2.3) [linux-any] | libselinux-dev [linux-any],
  dh-autoreconf,
  dh-exec,
@@ -42,6 +42,7 @@ Section: admin
 Depends: cdebconf, ${shlibs:Depends}, ${misc:Depends}
 Replaces: cdebconf (<< 0.144)
 Priority: extra
+Build-Profiles: 
 Description: Gtk+ frontend for Debian Configuration Management System
  Debconf is a configuration management system for Debian packages. It is
  used by some packages to prompt you for information before they are
@@ -151,6 +152,7 @@ Architecture: any
 Section: debian-installer
 Depends: cdebconf-udeb, ${shlibs:Depends}, ${misc:Depends}, rootskel-gtk [!s390 !s390x]
 Package-Type: udeb
+Build-Profiles: 
 Description: Gtk+ frontend for Debian Configuration Management System
  Debconf is a configuration management system for Debian packages. It is
  used by some packages to prompt you for information before they are
diff --git a/debian/rules b/debian/rules
index b2b35f4d..8b85a7af 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,6 +21,11 @@ LIBDEBCONF=libdebconfclient0
 DEB_FRONTENDS=passthrough text newt gtk
 UDEB_FRONTENDS=passthrough text newt gtk
 
+ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
+DEB_FRONTENDS:=$(filter-out gtk,$(DEB_FRONTENDS))
+UDEB_FRONTENDS:=$(filter-out gtk,$(UDEB_FRONTENDS))
+endif
+
 ifeq ($(DEB_HOST_ARCH_OS),linux)
 SELINUXFLAG=--enable-selinux
 else
@@ -128,6 +133,9 @@ binary-arch: install-arch
 	dh_installdocs -s
 	dh_installdebconf -s
 	dh_installdirs -s
+ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
+	dh_install -plibdebconfclient0-dev src/modules/frontend/gtk/cdebconf_gtk.h usr/include/cdebconf/
+endif
 	dh_lintian -s
 	dh_strip -s
 	dh_compress -s
-- 
2.11.0

Bug#892935: libdebian-installer: Please add support for "nodoc" build options and profile

[Karsten Merker]

Control: tags 892935 pending

On Wed, Mar 14, 2018 at 06:29:24PM +0100, Manuel A. Fernandez Montecelo wrote:
> Source: libdebian-installer
> Version: 0.114
> Severity: wishlist
> Tags: patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Hi,
> 
> We need changes in this package to help to bootstrap the riscv64 architecture,
> in particular it will help to skip using doxygen (in a clean way) for the time
> being.
> 
> It will be available at some point in the future, but it's complicate to have 
> it
> in the initial stages, due to the build-depends needed (particularly
> yui-compressor and ruby-compass at this moment).  This is probably the case 
> for
> any other architecture being bootstrapped now or in the near future.
> 
> I am attaching a patch that makes possible to compile the package by using
> profiles (or options) "nodoc", avoiding the dependency in d/control (with
> profile) and avoiding those files.  The profile helps to avoid the
> build-dependency entirel, not needing to force to build with missing
> dependencies.
> 
> Besides that, "nodoc" is a standard build option that would be nice to have in
> any case.
> 
> Please consider applying the patch (that I will upload in minutes, to have a 
> bug
> number) or providing some alternative solution to the same effect.

Looks good to me and local testbuilds haven't shown any problems.

The patch has been committed to the libdebian-installer git
repository; the CI build on jenkins was successful.  I intend to
upload the package with the patch included on the weekend unless
somebody @debian-boot should voice objections.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#892593: [PATCH] libverto: FTCBFS / Please add a pkg.libverto.noglib build profile

[Karsten Merker]

Source: libverto
Version: 0.2.4-2.1
Severity: wishlist
X-Debbugs-CC: debian-ri...@lists.debian.org
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V). The
binary packages libverto-dev and libverto-libev1 are part of the
build-dependency chain for the essential package set, so we need
to cross-build them for riscv64 to be able to complete the
bootstrap process.  Unfortunately it is currently impossible to
cross-build libverto as-is due to the following situation:

The package curently has a "hard" build-dependency on
libglib2.0-dev, which is only needed for building libverto-glib1,
but not for the other binary packages built from the libverto
source package.  For cross-building libverto-glib1, one would
need to install libglib2.0-dev for the host architecture, but
that isn't possible due to components of glib2.0 pulled in by
that not being multiarch-coinstallable with their build-arch
equivalents and debhelper transitively depending on the same
components for the build-arch.

The solution for this issue is adding a pkg.libverto.noglib
build-profile to the package, which disables building the
libverto-glib1 binary package and the corresponding
build-dependency when set. Attached is a patch implementing
that.

It would be great if you could upload a new version of libverto
with the patch applied to unstable soon as we depend on this
for completing our bootstrapping efforts.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur libverto-0.2.4/debian/control libverto-0.2.4.patched/debian/control
--- libverto-0.2.4/debian/control	2015-10-29 13:00:37.0 +
+++ libverto-0.2.4.patched/debian/control	2018-03-11 08:09:28.721190904 +
@@ -1,7 +1,7 @@
 Source: libverto
 Priority: optional
 Maintainer: Sam Hartman 
-Build-Depends: debhelper (>= 9), libev-dev, libglib2.0-dev, dh-autoreconf
+Build-Depends: debhelper (>= 9), libev-dev, libglib2.0-dev , dh-autoreconf
 Build-Conflicts: libevent-dev, libtevent-dev
 Standards-Version: 3.9.4
 Section: libs
@@ -58,6 +58,7 @@
 PRe-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Multi-Arch: same
+Build-Profiles: 
 Description: Event loop abstraction for Libraries - glib
  Libverto exists to isolate libraries from the particular event loop
  chosen by an application. Libverto provides an asynchronous
diff -Nur libverto-0.2.4/debian/rules libverto-0.2.4.patched/debian/rules
--- libverto-0.2.4/debian/rules	2015-10-29 12:14:17.0 +
+++ libverto-0.2.4.patched/debian/rules	2018-03-11 08:09:56.128680957 +
@@ -9,9 +9,13 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+ifeq (,$(filter libverto-glib1, $(shell dh_listpackages)))
+	CONFOPTS += --without-glib
+endif
+
 %:
 	dh $@ --with autoreconf
 
 override_dh_auto_configure:
 	chmod a+x configure
-	dh_auto_configure -- --libdir=/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+	dh_auto_configure -- $(CONFOPTS) --libdir=/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

Bug#892566: [PATCH] make-dfsg: Please add support for a "noguile" build-profile.

[Karsten Merker]

Source: make-dfsg
Version: 4.2.1-1
Severity: wishlist
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

the make-dfsg source package currently has a "hard" build-dependency
on guile-2.0-dev, which is only used for building the "make-guile"
binary package.  During bootstrapping a new architecture one needs to
build "make" but not "make-guile", and being able to do so easily
without requiring guile and its build-dependencies for the new
architecture would be really helpful.

Attached is a trivial patch that adds a "noguile" build profile
to the make-dfsg package.  It just modifies debian/control as
debian/rules already has all necessary infrastructure in place.
It would be great if you could upload a new version of make-dfsg
with this patch and the glibc-2.27 build fix from
https://bugs.debian.org/891365 to unstable.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
>From aafe1a5ca4f95a2d12e13fdb28c4f3ba63bd7c3c Mon Sep 17 00:00:00 2001
From: Karsten Merker <mer...@debian.org>
Date: Sat, 10 Mar 2018 16:59:30 +0100
Subject: [PATCH] Add a "noguile" build-profile.

The "noguile" profile results in dropping the build-dependency
on guile-2.0-dev and disabling the creation of the "make-guile"
binary package.  This eases (cross-)building the make package
when bootstrapping a new architecture.
---
 debian/control | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 04aad43..a92c92a 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,8 @@ Standards-Version: 4.1.3
 Homepage: http://www.gnu.org/software/make/
 Build-Depends: gettext, po-debconf, debhelper (>= 9.0.0), dh-autoreconf,
autoconf, automake | automaken, autopoint, file, pkg-config,
-   guile-2.0-dev, procps, libbsd-resource-perl 
+   procps, libbsd-resource-perl ,
+   guile-2.0-dev 
 
 Package: make
 Suggests: make-doc
@@ -37,6 +38,7 @@ Provides: make
 Replaces: make
 Architecture: any
 Multi-Arch: allowed
+Build-Profiles: 
 Description: utility for directing compilation with guile support
  GNU Make is a utility which controls the generation of executables
  and other target files of a program from the program's source
-- 
2.11.0

Bug#892217: [PATCH] libffi: Please add support for the riscv64 architecture

[Karsten Merker]

Source: libffi
Version: 3.3~20180131
Severity: wishlist
X-Debbugs-CC: debian-ri...@lists.debian.org
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V).  The
libffi package is part of the build-dependency chain for the
essential package set, so we need to build it for riscv64 to be
able to complete the bootstrap process.

Current upstream libffi doesn't yet have support for the RISC-V
architecture, but a pull request to add it has been submitted:

  https://github.com/libffi/libffi/pull/281/ respectively
  https://patch-diff.githubusercontent.com/raw/libffi/libffi/pull/281.patch

The pull request has been authored by one of the Fedora riscv64
porters and the Fedora riscv64 port already uses this patchset. 
It would be great if you could add the patchset to the Debian
libffi package as well.

The RISC-V support provided by the patchset is not all-encompassing
(please cf. the last comment from Stefan O'Rear in the pull
request), but it provides the same amount of features that libffi
has for a number of other Debian-supported architectures, so that
shouldn't be a problem.  The symbols file would need to be
adjusted, though:

dh_makeshlibs -plibffi7 --add-udeb=libffi7-udeb
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libffi7/DEBIAN/symbols doesn't match 
completely debian/libffi7.symbols
--- debian/libffi7.symbols (libffi7_3.3~20180131-2_riscv64)
+++ dpkg-gensymbols50ytax   2018-03-06 21:11:57.533480937 +
@@ -2,5 +2,5 @@
  (symver)LIBFFI_BASE_7.0 3.3~20170512
  (symver)LIBFFI_BASE_7.1 3.3~20170512
  (symver)LIBFFI_CLOSURE_7.0 3.3~20170512
- (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64el !powerpc !powerpcspe 
!ppc64 !ppc64el !sh4)LIBFFI_COMPLEX_7.0 3.3~20170512
- (symver|arch=!hppa !ia64 !m68k !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20170512
+#MISSING: 3.3~20180131-2# (symver|arch=!hppa !ia64 !m68k !mips !mipsel 
!mips64el !powerpc !powerpcspe !ppc64 !ppc64el !sh4)LIBFFI_COMPLEX_7.0 
3.3~20170512
+#MISSING: 3.3~20180131-2# (symver|arch=!hppa !ia64 !m68k 
!sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20170512

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#891663: [PATCH] libgpg-error: Add support for the riscv64 architecture

[Karsten Merker]

Source: libgpg-error
Version: 1.27-6
X-Debbugs-CC: debian-ri...@lists.debian.org
Tags: patch
Severity: wishlist
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V).  The
libgpg-error package is part of the build-dependency chain for
the essential package set, so we need to build it for riscv64 to
be able to complete the bootstrap process.

AIUI, libgpg-error requires a per-architecture header file
"src/syscfg/lock-obj-pub..h", which upstream doesn't
provide for riscv64.  Based on the information in the header
files for the other architectures, I have created such a file for
riscv64 by cross-building and executing (in qemu) the
gen-posix-lock-obj helper program:

$ riscv64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../src -I..   -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/usr/src/repositories/libgpg-error=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wpointer-arith -Wno-psabi -fvisibility=hidden -c 
-o gen-posix-lock-obj.o ../../src/gen-posix-lock-obj.c
$ /bin/bash ../libtool  --tag=CC   --mode=link riscv64-linux-gnu-gcc  -g -O2 
-fdebug-prefix-map=/usr/src/repositories/libgpg-error=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wpointer-arith -Wno-psabi -fvisibility=hidden  
-specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now -o 
gen-posix-lock-obj gen-posix-lock-obj.o
libtool: link: riscv64-linux-gnu-gcc -g -O2 
-fdebug-prefix-map=/usr/src/repositories/libgpg-error=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wpointer-arith -Wno-psabi -fvisibility=hidden 
-specs=/usr/share/dpkg/pie-link.specs -Wl,-z -Wl,relro -Wl,-z -Wl,now -o 
gen-posix-lock-obj gen-posix-lock-obj.o
$ ./gen-posix-lock-obj   # (executed in qemu via binfmt-misc)
## lock-obj-pub.riscv64-unknown-linux-gnu.h
## File created by gen-posix-lock-obj - DO NOT EDIT
## To be included by mkheader into gpg-error.h

typedef struct
{
  long _vers;
  union {
volatile char _priv[40];
long _x_align;
long *_xp_align;
  } u;
} gpgrt_lock_t;

#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0}}}
##
## Local Variables:
## mode: c
## buffer-read-only: t
## End:
##

Attached is the raw header file as well as a patch for the
packaging to carry this header file as a Debian patch.  I would
apprechiate very much if you could upload a new package version
that includes this patch to unstable in the near future as we
depend on it for continuing our bootstrap efforts.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
## lock-obj-pub.riscv64-unknown-linux-gnu.h
## File created by gen-posix-lock-obj - DO NOT EDIT
## To be included by mkheader into gpg-error.h

typedef struct
{
  long _vers;
  union {
volatile char _priv[40];
long _x_align;
long *_xp_align;
  } u;
} gpgrt_lock_t;

#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0}}}
##
## Local Variables:
## mode: c
## buffer-read-only: t
## End:
##
>From cec778b68abe56de49f838af5754348494778abe Mon Sep 17 00:00:00 2001
From: Karsten Merker <mer...@debian.org>
Date: Tue, 27 Feb 2018 19:43:09 +
Subject: [PATCH] add riscv64-unknown-linux-gnu lock-obj definitions

---
 ...bj-pub-file-for-riscv64-unknown-linux-gnu.patch | 30 ++
 debian/patches/series  |  1 +
 2 files changed, 31 insertions(+)
 create mode 100644 debian/patches/0017-syscfg-Add-lock-obj-pub-file-for-riscv64-unknown-linux-gnu.patch

diff --git a/debian/patches/0017-syscfg-Add-lock-obj-pub-file-for-riscv64-unknown-linux-gnu.patch b/debian/patches/0017-syscfg-Add-lock-obj-pub-file-for-riscv64-unknown-linux-gnu.patch
new file mode 100644
index 000..19ec11a
--- /dev/null
+++ b/debian/patches/0017-syscfg-Add-lock-obj-pub-file-for-riscv64-unknown-linux-gnu.patch
@@ -0,0 +1,30 @@
+Index: libgpg-error/src/syscfg/lock-obj-pub.riscv64-unknown-linux-gnu.h
+===
+--- /dev/null
 libgpg-error/src/syscfg/lock-obj-pub.riscv64-unknown-linux-gnu.h
+@@ -0,0 +1,25 @@
++## lock-obj-pub.riscv64-unknown-linux-gnu.h
++## File created by gen-posix-lock-obj - DO NOT EDIT
++## To be included b

Bug#887139: d-i daily 2018-01-14 amd64 damages UEFI setup on Fujitsu Lifebook AH532

[Karsten Merker]

Package: installation-reports
Version: 2.66
Severity: critical

-- Package-specific info:

Boot method: Netinstall CD image from USB stick
Image version: 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo
   dated 2018-01-14 04:22
Date: 2018-01-14

Machine: Fujitsu Lifebook AH532, first version (with BIOS version 1.09)

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:  [O]
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]

Problems:

Short summary:
The installation process completed successfully, but the UEFI
firmware is broken afterwards; it is impossible to get into the
UEFI setup, boot from any external device anymore or get the
system to use the CSM to boot from a classical MBR.

Detailed description:
This was an installation in EFI mode (for the first time on this
device).  The system was previously running an older BIOS-mode
installation without problems, but got a new, bigger harddisk and
therefore required a new installation which was done in EFI mode
(which is nowadays the default mode the installer starts in). 
The installation itself worked without problems and the resulting
Debian system works fine, but it isn't possible anymore to get
into the BIOS/UEFI setup of the machine nor boot from any other
device.  When powering on the system, the message ": Boot
Menu, : BIOS Setup" appears (as always), pressing F2 results
in a short "Please wait..." (als always), but then one doesn't
get into the UEFI/BIOS setup but instead the system directly
boots GRUB.  Pressing F12 for the boot menu results in a screen
with a menu with the following structure:

- Boot Menu
  debian
- Application Menu
  Diagnostic Screen

"Diagnostic Screen" just shows the Firmware splash screen:

"Phoenix SecureCore Tiano(TM)
 Copyright 1985-2011 Phoenix Technologies Ltd.
 All Rights Reserved

 Fixed Disk: 
 ATAPI CDROM: 

 Press any key to exit"

and the "debian" boot menu entry obviously starts GRUB.

There is no way to make the system boot from any external device
anymore, so it is impossible to boot a rescue system or reinstall
the device from scratch.  Fallback to BIOS-mode booting also
doesn't work any more.  Plugging back the the old harddisk with a
BIOS-mode install results in a non-booting system.  The UEFI/BIOS
always tries to boot the "debian" EFI entry which for obvious
reasons doesn't work with a BIOS-mode setup on the disk.

There is also a Window 7 UEFI-mode installation on the (new)
disk, which can be started from GRUB, but it doesn't show up any
more in the firmware-provided boot-menu (which it did before
installing Debian).

Running "efibootmgr -v" from the installed systems results in "No
BootOrder is set; firmware will attempt recovery", which is what
doesn't seem to work.  It somewhat looks like the UEFI/BIOS
setup, the Firmware-level boot menu and the CSM for BIOS-mode
booting are EFI applications that cannot be started anymore
because some NVRAM entry is broken.

BIOS Information from dmidecode:
Vendor: FUJITSU // Phoenix Technologies Ltd.
Version: Version 1.09
Release Date: 05/22/2012
Address: 0xE
Runtime Size: 128 kB
ROM Size: 4096 kB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 kB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 1.9

This is the newest BIOS version that is available for this
device; newer versions (2.xx) are only available for a newer
board revision and are not compatible with this board revision.

How can one bring the NVRAM back into a sane state that allows
getting into the setup and booting from external devices?

Regards,
Karsten

Technical information about the system:

Bug#885712: libdebian-installer should not use -Werror

[Karsten Merker]

Control: tag 885712 pending

On Fri, Dec 29, 2017 at 01:36:47PM +0100, Helmut Grohne wrote:
> Source: libdebian-installer
> Version: 0.112
> Severity: wishlist
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> The packaging of libdebian-installer insterts a -Werror into CFLAGS.
> This has caused FTBFS with gcc-6 and gcc-7 already and will cause more
> FTBFS with gcc-8. Given that these issues are not fixed proactively, it
> complicates architecture bootstrap, which somestimes has to use
> unreleased compilers. I thus ask you to disable use of -Werror.  This
> avoids unexpected FTBFS. I still recommend doing maintainer builds with
> -Werror to catch issues early. Just save everyone else from the fallout
> please.
> 
> Helmut

> diff --minimal -Nru libdebian-installer-0.112/debian/changelog 
> libdebian-installer-0.112+nmu1/debian/changelog
> --- libdebian-installer-0.112/debian/changelog2017-11-19 
> 18:12:25.0 +0100
> +++ libdebian-installer-0.112+nmu1/debian/changelog   2017-12-29 
> 13:32:02.0 +0100
> @@ -1,3 +1,10 @@
> +libdebian-installer (0.112+nmu1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Do not compile with -Werror by default.  Closes: #-1.
> +
> + -- Helmut Grohne   Fri, 29 Dec 2017 13:32:02 +0100
> +
>  libdebian-installer (0.112) unstable; urgency=medium
>  
>[ Reiner Herrmann ]
> diff --minimal -Nru libdebian-installer-0.112/debian/rules 
> libdebian-installer-0.112+nmu1/debian/rules
> --- libdebian-installer-0.112/debian/rules2017-11-19 17:26:42.0 
> +0100
> +++ libdebian-installer-0.112+nmu1/debian/rules   2017-12-29 
> 13:31:59.0 +0100
> @@ -6,7 +6,7 @@
>  DEB_HOST_MULTIARCH  := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
>  
>  #CFLAGS = -Wall -W -Werror -ggdb -Wstrict-prototypes -Wmissing-declarations 
> -Wmissing-prototypes
> -CFLAGS = -Wall -W -Werror -ggdb -Wmissing-declarations
> +CFLAGS = -Wall -W -ggdb -Wmissing-declarations
>  
>  ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
>   CFLAGS += -O0

Hello,

the patch has been applied to the libdebian-installer git repository.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#864562: u-boot: broken ethernet support on Olimex A20-Olinuxino-Micro Rev. J

[Karsten Merker]

control: reassign 864562 u-boot-sunxi
control: retitle 864562 u-boot: broken ethernet support on Olimex 
A20-Olinuxino-Micro Rev. J
control: tags 864562 patch

On Mon, Oct 16, 2017 at 10:45:57PM +0200, Karsten Merker wrote:
> On Mon, Oct 16, 2017 at 09:39:36PM +0200, Jean-Louis Mounier wrote:

[Ethernet not working on Olimex A20-Olinuxino Micro Rev. J]
> > I discovered a new installer release but the bug is still
> > present.
> > 
> > Now the test :
> > 
> > => gpio clear PA17
> > gpio: pin PA17 (gpio 17) value is 0
> > =>run bootcmd
> > 
> > after that, the installer got IPV4 and IPV6 addresses wwith DHCP and then
> > ran fine.
> > 
> > Hope it helps
> 
> Yes, that helps as it confirms that a change in u-boot alone is
> enough to work around the issue in Linux as well (although it is
> debateable whether the kernel should rely on the bootloader in
> this case or not).  There has recently been an attempt to address
> the issue in mainline u-boot, but that didn't work out as planned
> and the patch got rejected:
> 
> https://lists.denx.de/pipermail/u-boot/2017-September/307778.html

Hello,

a patch to address this issue has finally been accepted today by
the upstream u-boot custodian for the sunxi platform, targeting
u-boot v2018.01:

https://patchwork.ozlabs.org/patch/833763/

Vagrant, could you include the patch in the next u-boot package
upload?

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#881969: making bootable SD cards

[Karsten Merker]

Control: severity 881969 wishlist

[CCing Vagrant Cascadian, the Debian u-boot maintainer]

On Thu, Nov 16, 2017 at 07:54:42PM -0400, Joey Hess wrote:
> Package: flash-kernel
> Version: 3.87
> Severity: normal
> 
>   Therefore you usually have to setup an SD card with the appropriate u-boot
>   version for your particular device (see below) as a prerequisite for
>   installing Debian. If you use the pre-made SD card images with the
>   installer, this step is not necessary, as these images already contain
>   u-boot.
>   -- https://wiki.debian.org/InstallingDebianOn/Allwinner
> 
> This seems to fall squarely in flash-kernel's wheelhouse, since it
> already handles the other parts of u-boot installation, and it knows
> the name of the board being installed.
> 
> The d-i SD card images avoid the problem, but they are only one way to
> install; there are even other ways to use d-i to install that need this
> manual step first.
> 
> The main difficulty in putting it in flash-kernel is that it might be
> installed in a chroot in a situation where it should not be altering
> the boot sector of the host's disk. So, something like grub-installer
> seems to be called for, so the user specifies the device to install to.
> 
> A utility in flash-kernel would be much nicer than needing to puzzle out dd
> commands from README.Debian files and hope you got it right. I'm currently
> having to embed those dd commands inside propellor; they're also embedded
> inside debian-installer (build/boot/arm/u-boot-image-config).

Hello,

to use d-i/flash-kernel on the target device, one obviously needs
to already have put a u-boot onto the device in some form (such
as preinstalled in the d-i SD card images), otherwise one
couldn't have booted it, i.e. flash-kernel could only cover the
topic of updating u-boot from within a running system.  There has
been a discussion about the latter in the past and the consensus
reached at that time was that it is practically impossible to
safely determine the version of an already installed u-boot image
in a platform-independant way, and installing u-boot
unconditionally on every invocation of flash-kernel is considered
too riscy as there are a number of unsolved problems with such an
approach.

Among the points of this discussion were:

- On some devices u-boot isn't stored on an SD card but on an
  onboard SPI flash chip with a rather limited number of write
  cycles (in the area of ~1000) and no defects management. 
  Unconditionally writing u-boot on every invocation of
  flash-kernel (which includes everything that modifies the
  initrd) would have the potential to kill these devices in
  comparatively short time.

- Knowing the device type one is running on isn't necessarily
  enough.  Several supported devices are available in different
  hardware configuration variants that influence where the u-boot
  image can get written to (SD card, onboard eMMC, onboard raw
  NAND, SPI flash, and combinations thereof).  Once Linux is
  running, there is no way to determine where the u-boot that
  brought the system up was loaded from.  Flash-kernel pulls the
  system type from a /proc entry, but that doesn't provide the
  information whether the current device e.g. has the SPI flash
  for u-boot populated or not, and if yes, whether it has
  actually been used for booting the system, so flash-kernel
  cannot decide without user-interaction where to write the
  u-boot image.

- As u-boot is more than just a bootloader - it also provides
  BIOS-like functionality - there can be a major difference
  between messing up automatically installing GRUB and messing up
  automatically installing u-boot.  In the GRUB case, the user
  can simply boot a rescue system and fix the bootloader.  In
  case of a broken u-boot installation to an SPI flash or to an
  eMMC on systems where these have a higher boot priority than
  the SD slot, the system can be completely dead and require
  specific hardware tooling (such as an external SPI flasher) to
  revive the system again.

As a result of these issues, it was deemed unsuitable for
flash-kernel to attempt installing u-boot.

What we might do sometime in the future is adding a
u-boot-installer udeb to d-i which on a very limited subset of
systems allows the user to explicitly decide to install u-boot to
a user-selected device (such as eMMC or SPI flash) after being
informed about the riscs of doing so.  I had started designing a
proof-of-concept for such a udeb, but have had to put that on
hold due to having to take care of a number of higher-priority
issues.

I'm setting the severity of this bug down from "normal"
to "wishlist" as it is about requesting the addition of
a new feature and not about a bug in existing functionality.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#868166: flash-kernel: Patch for Radxa Rock2 Square support

[Karsten Merker]

Control: tags 868166 pending

On Wed, Jul 12, 2017 at 03:57:13PM +, Eva Ramon wrote:
> Package: flash-kernel
> Version: 3.82
> Severity: wishlist
> 
> Dear Maintainer,
> 
> please apply the patch provided in order to add support for the Radxa Rock2 
> Square board to flash-kernel.
> 
> --- /usr/share/flash-kernel/db/all.db.old 2017-07-12 15:08:15.380566406 
> +
> +++ /usr/share/flash-kernel/db/all.db 2017-07-12 15:08:34.300272594 +
> @@ -378,6 +378,13 @@
>  U-Boot-Script-Name: bootscr.uboot-generic
>  Required-Packages: u-boot-tools
>  
> +Machine: Radxa Rock 2 Square
> +Kernel-Flavors: armmp armmp-lpae
> +DTB-Id: rk3288-rock2-square.dtb
> +Boot-Script-Path: /boot/boot.scr
> +U-Boot-Script-Name: bootscr.uboot-generic
> +Required-Packages: u-boot-tools
> +
>  Machine: Freescale i.MX53 Quick Start Board
>  Machine: Freescale MX53 LOCO Board
>  Kernel-Flavors: armmp mx5
> 
> Thanks!

Hello,

many thanks for the patch submission. The machine db entry has
been added to the flash-kernel git repository and will enter the
archive on the next package upload (probably in a few days).

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#866521: [PATCH] initramfs-tools: rootfs on USB mass storage broken for a number of armhf systems

[Karsten Merker]

Package: initramfs-tools
Severity: important
Tags: patch

Hello,

with newer kernels (including kernel 4.9 as used in stretch),
initializing the USB host controllers on a number of armhf
systems is not possible without having the "axp20x_usb_power"
power supply driver module available.  To be able to have the
rootfs on a USB mass storage device on such systems it is
therefore necessary to include this module in the initramfs,
which currently isn't the case.

Attached is a patch that adds the "axp20x_usb_power" module to
the "base" module list for the "MODULES=most" setting.  

JFTR: The patch doesn't address the "MODULES=dep" case; rootfs on
USB mass storage currently doesn't work at all with "MODULES=dep"
as the necessary USB controller drivers don't get included.  An
Example (Allwinner A20) with MODULES=dep:

  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb/common
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb/common/usb-common.ko
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb/phy
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb/phy/phy-generic.ko
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/scsi
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/scsi/sd_mod.ko
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/scsi/scsi_mod.ko
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/i2c
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/i2c/busses
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/i2c/busses/i2c-mv64xxx.ko
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/phy
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/phy/phy-sun4i-usb.ko
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/extcon
  lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/extcon/extcon-core.ko

Missing are at least ehci_platform, ehci_hcd, ohci_platform,
ohci_hcd and usbcore (when using the OTG controller also
musb_hdrc and udc_core) plus the axp20x_regulator regulator
driver and the axp20x_usb_power power supply driver.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
>From 7358533bcf35c7237ad8ab57dd2fe0b7db5f553c Mon Sep 17 00:00:00 2001
From: Karsten Merker <mer...@debian.org>
Date: Thu, 29 Jun 2017 20:51:03 +0200
Subject: [PATCH] Include the axp20x_usb_power module in the base modules list
 for MODULES=most

With newer kernels (including kernel 4.9 as used in stretch),
initializing the USB host controllers on a number of armhf systems
is not possible without having the "axp20x_usb_power" power supply
driver module available. To be able to have the rootfs on a USB
mass storage device on such systems it is therefore necessary to
include this module in the initramfs.
---
 hook-functions | 4 
 1 file changed, 4 insertions(+)

diff --git a/hook-functions b/hook-functions
index 679e11d..4c68c90 100644
--- a/hook-functions
+++ b/hook-functions
@@ -513,6 +513,10 @@ auto_add_modules()
 			copy_modules_dir kernel/drivers/usb/renesas_usbhs
 			# and any extcon drivers for USB
 			modules="$modules extcon-usb-gpio"
+			# Add the axp20x_usb_power power supply driver,
+			# required to initialize the USB host controllers
+			# on a number of armhf systems
+			modules="$modules axp20x_usb_power"
 
 			# Include all HID drivers unless we're sure they
 			# don't support keyboards.  hid-*ff covers various
-- 
2.13.2

Bug#864457: [d-i daily hd-media 20170608] kernel doesn't initialize USB ports inside d-i on a sunxi-based system

[Karsten Merker]

On Thu, Jun 08, 2017 at 10:50:57PM +0200, Karsten Merker wrote:
> Package: installation-reports
> 
> Boot method: hd-media tarball from USB stick
> Image version: 
> https://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz
> Date: 2017-06-08
> 
> Machine: LeMaker Banana Pi
> Processor: Allwinner A20 (2x Cortex A7)
> Memory: 1GB
[...]
> Comments/Problems: 
> Installation method is a d-i hd-media tarball and a Debian CD/DVD
> ISO image on a USB stick.  Booting d-i from the stick works fine,
> but inside the installer the USB ports are dead and no USB
> devices get recognized by the kernel.
> 
> In an installed system on the same hardware (installed with the
> netboot image), the USB ports work normally.  In the d-i
> environment, the ehci platform driver gets loaded, but for some
> reason doesn't initialize the actual host controller. All
> relevant USB host driver modules appear to be there:
> 
> Module  Size  Used by
> usb_storage45835  0
> phy_generic 4686  1 sunxi
> musb_hdrc 113325  1 sunxi
> udc_core   26444  1 musb_hdrc
> ohci_platform   4786  0
> ohci_hcd   37898  1 ohci_platform
> ehci_platform   5462  0
> ehci_hcd   64996  1 ehci_platform
> phy_sun4i_usb   8637  1 sunxi
> extcon_core13223  2 sunxi,phy_sun4i_usb
> usbcore   196310  6 
> usb_storage,ehci_hcd,musb_hdrc,ohci_hcd,ehci_platform,ohci_platform
> usb_common  3659  5 udc_core,sunxi,musb_hdrc,phy_sun4i_usb,usbcore
> 
> In the d-i environment:
> [2.694030] usbcore: registered new interface driver usbfs
> [2.699958] usbcore: registered new interface driver hub
> [2.703305] SCSI subsystem initialized
> [2.716192] usbcore: registered new device driver usb
> [2.724836] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [2.736947] sunxi-mmc 1c0f000.mmc: base:0xf08f4000 irq:28 
> [2.750665] ehci-platform: EHCI generic platform driver   
> [2.751130] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [2.752551] ohci-platform: OHCI generic platform driver
> 
> While on the installed system:
> [2.162185] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver  
> [2.168314] ehci-platform: EHCI generic platform driver
> [6.187194] ehci-platform 1c14000.usb: EHCI Host Controller
> [6.187256] ehci-platform 1c14000.usb: new USB bus registered, assigned 
> bus number 2
> [6.192414] ehci-platform 1c14000.usb: irq 30, io mem 0x01c14000
> [6.205562] ehci-platform 1c14000.usb: USB 2.0 started, EHCI 1.00
> [6.206170] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> [6.206184] usb usb2: New USB device strings: Mfr=3, Product=2, 
> SerialNumber=1
> [6.206191] usb usb2: Product: EHCI Host Controller
> [6.206198] usb usb2: Manufacturer: Linux 4.9.0-3-armmp-lpae ehci_hcd
> [6.206204] usb usb2: SerialNumber: 1c14000.usb
> [6.207443] hub 2-0:1.0: USB hub found
> [6.207557] hub 2-0:1.0: 1 port detected
> [6.209230] ehci-platform 1c1c000.usb: EHCI Host Controller
> [6.209289] ehci-platform 1c1c000.usb: new USB bus registered, assigned 
> bus number 3
> [6.216403] ehci-platform 1c1c000.usb: irq 34, io mem 0x01c1c000
> [6.230524] ehci-platform 1c1c000.usb: USB 2.0 started, EHCI 1.00
> [6.231044] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
> [6.231058] usb usb3: New USB device strings: Mfr=3, Product=2, 
> SerialNumber=1
> [6.231066] usb usb3: Product: EHCI Host Controller
> [6.231072] usb usb3: Manufacturer: Linux 4.9.0-3-armmp-lpae ehci_hcd
> [6.231079] usb usb3: SerialNumber: 1c1c000.usb
> 
> We might have a problem with the USB port power supply here. 
> Comparing the available modules between the installed system and
> the d-i environment (full list below) and looking for possibly
> related modules shows that the "axp20x_regulator" and
> "axp20x_usb_power" modules are available in the installed system,
> but not in the d-i environment.  I am not sure whether
> axp20x_usb_power is really responsible for providing power _to_
> the USB hosts ports, though.  It could be that it is responsible
> for powering the system _from_ a USB-OTG port, so it might be
> unrelated to the problem at hand.  "axp20x_regulator" would
> possibly be a candidate for a power-supply problem.  I have also
> tried using a powered USB hub between the USB stick and the host
> port, but even then no USB device gets recognized, which kind of
> speaks against the theory of only a missing 5V-supply on the USB
> port as the sole source of the problem.  Possibly 

Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot

[Karsten Merker]

On Sun, Jan 15, 2017 at 12:02:56PM +0100, permondes - sagen wrote:
> Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker:

> > This points at a problem with either your u-boot version or your
> > u-boot environment.  The oldest u-boot version that Debian has
> > ever shipped for the Olinuxino A20 LIME as part of the official
> > Debian-Installer images has been mainline u-boot v2014.10, and
> > all mainline u-boot versions since v2014.10 provide a default
> > environment that is compatible with this boot script.
> > 
> > Please note that u-boot keeps its old environment on upgrade by
> > default, i.e. if you originally had e.g. some vendor-specific
> > u-boot installed and upgraded to mainline u-boot later, this
> > would have kept the environment from the vendor u-boot. You can
> > reset the u-boot environment to its current default by running
> > "env default -a; saveenv" at the u-boot command prompt.
> > 
> > HTH,
> > Karsten
> 
> The device is being used as a FreedomBox, a flavour of Debian. They
> provide an initial "live" image which is quite old actually. Updating to
> the current version, which is done automatically during set-up, makes
> this change of boot.scr, so I guess they switched to standard u-boot.

Not necessarily.  The boot.scr is generated by the flash-kernel
package on every kernel update, but the u-boot in the boot area is
not automatically updated with an update of the u-boot-sunxi
package, so unless the people who have built the freedombox upgrade
mechanism have explicitly implemented a function to update the
u-boot in the boot area (which I doubt), you will probably still
have whatever older u-boot version was used when building the
original freedombox image.

> I would like to test the reset of the environment, how do I get into
> u-boot prompt? I just have ssh access to the box, no serial, nor
> keyboard or so.

Hm, that poses a problem.  The "normal" way is via serial console,
or, if the u-boot version is relatively new, via a display
connected to the HDMI port and a USB keyboard.  U-Boot isn't memory
resident (except for the PSCI functions), i.e. once the Linux
kernel is booted, there is no u-boot anymore with which one could
interact directly.

What you could try is clobbering the area on the SD card in which
u-boot stores the environment.  This results in a checksum mismatch
and u-boot falls back to the integrated default environment.  On
the LIME, the u-boot environment is stored on the SD card starting
at offset 544kB from the start of the device, and is 128kB in size. 
So on the LIME running

$ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0

should overwrite the complete environment area with zeros,
resulting in u-boot falling back to the built-in defaults. But
without some form of console you still won't be able to see which
version of u-boot is really installed (cf. my mail to debian-arm)
and what exactly happens at boot time.  If you want to make sure
that you have a current u-boot version installed, you can replace
whatever version is currently on the SD card by running

$ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin 
of=/dev/mmcblk0 bs=1k seek=8

Doing all this "blind" without console is of course inherently
dangerous, so make an image backup of your SD card that you can
restore in case of problems before trying any of this.

HTH,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot

[Karsten Merker]

On Sun, Jan 15, 2017 at 10:45:29AM +0100, permondes - sagen wrote:

> Package: flash-kernel
> Version: 3.73
> Severity: important
> 
> Dear Maintainer,
> 
> I am using an OLinuXino A20 LIME with arm. 
> boot.scr used to have the following content (I removed the initial
> non-readable characters) which let boot the device without issues:
> 
> setenv mmcpart 1
> 
> setenv mmcroot /dev/mmcblk0p2 ro
> setenv mmcrootfstype btrfs rootwait fixrtc
> setenv mmcrootflags subvol=@
> 
> setenv console ttyS0,115200n8
> 
> setenv kernel_file vmlinuz-4.8.0-2-armmp-lpae
> setenv initrd_file initrd.img-4.8.0-2-armmp-lpae
> setenv fdtfile sun7i-a20-olinuxino-lime.dtb
> 
> setenv loadaddr 0x4600
> setenv initrd_addr 0x4800
> setenv fdtaddr 0x4700
> 
> setenv initrd_high 0x
> setenv fdt_high 0x
> 
> setenv loadkernel load mmc ${mmcdev}:${mmcpart} ${loadaddr}
> ${kernel_file}
> setenv loadinitrd load mmc ${mmcdev}:${mmcpart} ${initrd_addr}
> ${initrd_file}\; setenv initrd_size \${filesize}
> setenv loadfdt load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}
> 
> setenv loadfiles run loadkernel\; run loadinitrd\; run loadfdt
> setenv mmcargs setenv bootargs console=${console} root=${mmcroot}
> rootfstype=${mmcrootfstype} rootflags=${mmcrootflags}
> 
> run loadfiles; run mmcargs; bootz ${loadaddr} ${initrd_addr}:
> ${initrd_size} ${fdtaddr}
> 
> <-- end of file

To my knowledge Debian has never provided a boot script with this
content as a part of its official flash-kernel releases.  Is this
perhaps from some non-official Debian image that somebody else
has produced, e.g. from some image provided by the hardware
manufacturer or from some other project that uses Debian as its
base but doesn't use Debian's normal mechanisms for handling the
boot scripts?

Which u-boot version do you have installed? Can you provide the
output of the "printenv" command at the u-boot prompt?

> The new content of that file is:
> 
> # boot script for Allwinner SunXi-based devices
> 
> # Mainline u-boot v2014.10 introduces a new default environment and
> # a new common bootcmd handling for all platforms, which is not fully
> # compatible with the old-style environment used by u-boot-sunxi.
> # This script therefore needs to check in which environment it
> # is running and set some variables accordingly.
> 
> # On u-boot-sunxi, this script assumes that ${device} and ${partition}
> # are set.
> 
> # The new-style environment predefines ${boot_targets}, the old-style
> # environment does not.
> if test -n "${boot_targets}"
> then
>   echo "Mainline u-boot / new-style environment detected."
>   # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and
>   # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}.
>   # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01.
>   if test -z "${device}"; then setenv device "${devtype}"; fi
>   if test -z "${partition}${distro_bootpart}"; then setenv partition
> "${devnum}:${bootpart}"; fi
>   if test -z "${partition}"; then setenv partition "${devnum}:
> ${distro_bootpart}"; fi
> else
>   echo "U-boot-sunxi / old-style environment detected."
>   # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and
>   # ramdisk_addr_r, so they have to be manually set. Use the values
>   # from mainline u-boot v2014.10, except for ramdisk_addr_r,
>   # which is set to 0x4430 to allow for initrds larger than
>   # 13MB on u-boot-sunxi.
>   setenv kernel_addr_r 0x4200
>   setenv fdt_addr_r 0x4300
>   setenv ramdisk_addr_r 0x4430
> fi
> 
> if test -n "${console}"; then
>   setenv bootargs "${bootargs} console=${console}"
> fi
> 
> setenv bootargs  ${bootargs} quiet
> 
> 
> image_locations='/boot/ /'
> if test -z "${fk_kvers}"; then
>setenv fk_kvers '4.8.0-2-armmp-lpae'
> fi
> 
> if test -n "${fdtfile}"; then
>setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
> else
>setenv fdtpath dtb-${fk_kvers}
> fi
> 
> for pathprefix in ${image_locations}
> do
>   if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers}
>   then
> load ${device} ${partition} ${kernel_addr_r}
> ${pathprefix}vmlinuz-${fk_kvers} \
> && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath}
> \
> && load ${device} ${partition} ${ramdisk_addr_r}
> ${pathprefix}initrd.img-${fk_kvers} \
> && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..."
> \
> && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
> ${fdt_addr_r}
>   fi
> done
> 
> <- end of file
> 
> Which does not allow the device to boot. 
> None of the variables in that script is set in the current environment.

This points at a problem with either your u-boot version or your
u-boot environment.  The oldest u-boot version that Debian has
ever shipped for the Olinuxino A20 LIME as part of the official
Debian-Installer images has been mainline u-boot v2014.10, and
all mainline u-boot versions since v2014.10 provide a default
environment that is compatible with this boot script.

Bug#830169: u-boot 2016.07~rc3+dfsg1-1: FTBFS for openrd_base, openrd_client and openrd_ultimate targets

[Karsten Merker]

Source: u-boot
Version: 2016.07~rc3+dfsg1-1
Severity: important
Tags: upstream

U-Boot v2016.07~rc3 fails to build from source for the (armel)
targets openrd_base, openrd_client and openrd_ultimate  The
problem is not specific to the Debian package but exists in
upstream git as well.  A bug report has been sent to the upstream
u-boot development list.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#777334: [jessie daily 2015-02-07] [armhf] installation-report: A20-OLinuXino-LIME

[Karsten Merker]

Package: installation-reports

Boot method: hd-media + CD image on a USB stick
hd-media version: 
http://d-i.debian.org/daily-images/armhf/20150207-05:30/hd-media/hd-media.tar.gz
CD version: Debian GNU/Linux testing Jessie - Official Snapshot armhf CD 
Binary-1 20150202-10:45
from 
http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo,
dated 2015-02-02 12:06
Date: 2015-02-07

Machine: Olimex A20-OLinuXino-LIME
Processor: Allwinner A20 (2x Cortex A7)
Memory: 512MB
Console: serial console, 115200 baud

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:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:
The installation was done to a 16GB Micro-SD card using serial
console (on the UART0 header) and worked without problems;
network (100MBit) and the USB host ports work as expected. 
Partitioning was done using the guided partitioning, all files
in one partition option.  I have not tested using a SATA disk
with the board due to lack of a SATA power cable that fits into
the board's SATA power connector (2-pin JST-style).

As an informational note: due to bug #773645 (lack of u-boot
tools on the first armhf CD), hd-media/CD installations on armhf
platforms currently require network connectivity during the
installation process; pure offline installations are not possible
with hd-media/CD at the moment.

dmesg output:
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-4-armmp-lpae 
(debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-16) ) #1 SMP 
Debian 3.16.7-ckt2-1 (2014-12-08)
[0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=30c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine model: Olimex A20-OLinuXino-LIME
[0.00] Forcing write-allocate cache policy for SMP
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 131072
[0.00] free_area_init_node: node 0, pgdat c0a0cb00, node_mem_map 
dfbf9000
[0.00]   DMA zone: 1024 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 131072 pages, LIFO batch:31
[0.00] psci: probing for conduit method from DT.
[0.00] psci: Using PSCI v0.1 Function IDs from DT
[0.00] PERCPU: Embedded 9 pages/cpu @dfbd4000 s13312 r8192 d15360 u36864
[0.00] pcpu-alloc: s13312 r8192 d15360 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 130048
[0.00] Kernel command line: console=ttyS0,115200 quiet
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Memory: 497040K/524288K available (6562K kernel code, 838K 
rwdata, 2216K rodata, 701K init, 396K bss, 27248K reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xffc0 - 0xffe0   (2048 kB)
vmalloc : 0xe080 - 0xff00   ( 488 MB)
lowmem  : 0xc000 - 0xe000   ( 512 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf00 - 0xbfe0   (  14 MB)
  .text : 0xc0008000 - 0xc089aeb8   (8780 kB)
  .init : 0xc089b000 - 0xc094a400   ( 701 kB)
  .data : 0xc094c000 - 0xc0a1dab8   ( 839 kB)
   .bss : 0xc0a1dab8 - 0xc0a80eb4   ( 397 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  RCU dyntick-idle grace-period acceleration is enabled.
[0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] Architected cp15 timer(s) running at 24.00MHz (phys).
[0.09] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 
2863311519744ns
[0.19] Switching to timer-based delay loop
[0.001002] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 
178956969942ns
[0.001363] sched_clock: 32 bits at 160MHz, resolution 6ns, wraps every 
26843545593ns
[0.001801] Console: colour dummy device 80x30
[0.001837] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 48.00 BogoMIPS (lpj=96000)
[   

Bug#774067: linux 3.16.7-ckt: [patch] please add a dts for the LinkSprite pcDuino V3

[Karsten Merker]

Source: linux
Version: 3.16.7-ckt2-1
Severity: wishlist
Tags: patch

On the debian-arm mailinglist, a user has asked for support for
the LinkSprite pcDuino V3 board (see the thread starting at
https://lists.debian.org/debian-arm/2014/12/msg00052.html).

Driver-wise all core components of the board (serial console,
MMC, SATA, USB, wired ethernet) are supported by kernel 3.16, it
just lacks an appropriate device-tree file, which was added
upstream in kernel 3.17.  Attached is a patch to backport the
device-tree file.  As this is a completely self-contained
addition and does not bring any code changes, I believe this to
be suitable for inclusion into Jessie despite the freeze.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Index: debian/patches/features/arm/dts-sun7i-Add-board-support-for-LinkSprite-pcDuino-V3.patch
===
--- debian/patches/features/arm/dts-sun7i-Add-board-support-for-LinkSprite-pcDuino-V3.patch	(revision 0)
+++ debian/patches/features/arm/dts-sun7i-Add-board-support-for-LinkSprite-pcDuino-V3.patch	(working copy)
@@ -0,0 +1,206 @@
+From 04089927981f295b42cd695485383b2d11283d59 Mon Sep 17 00:00:00 2001
+From: Zoltan HERPAI wigy...@uid0.hu
+Date: Mon, 30 Jun 2014 23:57:56 +0200
+Subject: ARM: dts: sun7i: Add board support for LinkSprite pcDuino V3
+Origin: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=04089927981f295b42cd695485383b2d11283d59
+
+The LinkSprite pcDuino V3 is an A20 based development board featuring
+arduino compatible io headers, 1G RAM, 4G nand, sata, rtl8188cus usb wifi
+and 100 Mbit ethernet using an ip101a phy:
+
+http://www.pcduino.com/pcduino-v3/
+
+Signed-off-by: Zoltan HERPAI wigy...@uid0.hu
+[hdego...@redhat.com: Various cleanups, correct led pins]
+[hdego...@redhat.com: Add axp209, ir and gpio-keys nodes]
+Signed-off-by: Hans de Goede hdego...@redhat.com
+Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
+
+--- a/arch/arm/boot/dts/Makefile
 b/arch/arm/boot/dts/Makefile
+@@ -381,7 +381,8 @@
+ 	sun7i-a20-cubietruck.dtb \
+ 	sun7i-a20-i12-tvbox.dtb \
+ 	sun7i-a20-olinuxino-lime.dtb \
+-	sun7i-a20-olinuxino-micro.dtb
++	sun7i-a20-olinuxino-micro.dtb \
++	sun7i-a20-pcduino3.dtb
+ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
+ 	tegra20-iris-512.dtb \
+ 	tegra20-medcom-wide.dtb \
+--- /dev/null
 b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
+@@ -0,0 +1,173 @@
++/*
++ * Copyright 2014 Zoltan HERPAI
++ * Zoltan HERPAI wigy...@uid0.hu
++ *
++ * The code contained herein is licensed under the GNU General Public
++ * License. You may obtain a copy of the GNU General Public License
++ * Version 2 or later at the following locations:
++ *
++ * http://www.opensource.org/licenses/gpl-license.html
++ * http://www.gnu.org/copyleft/gpl.html
++ */
++
++/dts-v1/;
++/include/ sun7i-a20.dtsi
++/include/ sunxi-common-regulators.dtsi
++#include dt-bindings/gpio/gpio.h
++#include dt-bindings/input/input.h
++
++/ {
++	model = LinkSprite pcDuino3;
++	compatible = linksprite,pcduino3, allwinner,sun7i-a20;
++
++	soc@01c0 {
++		mmc0: mmc@01c0f000 {
++			pinctrl-names = default;
++			pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_reference_design;
++			vmmc-supply = reg_vcc3v3;
++			bus-width = 4;
++			cd-gpios = pio 7 1 0; /* PH1 */
++			cd-inverted;
++			status = okay;
++		};
++
++		usbphy: phy@01c13400 {
++			usb1_vbus-supply = reg_usb1_vbus;
++			usb2_vbus-supply = reg_usb2_vbus;
++			status = okay;
++		};
++
++		ehci0: usb@01c14000 {
++			status = okay;
++		};
++
++		ohci0: usb@01c14400 {
++			status = okay;
++		};
++
++		ahci: sata@01c18000 {
++			target-supply = reg_ahci_5v;
++			status = okay;
++		};
++
++		ehci1: usb@01c1c000 {
++			status = okay;
++		};
++
++		ohci1: usb@01c1c400 {
++			status = okay;
++		};
++
++		pinctrl@01c20800 {
++			ahci_pwr_pin_a: ahci_pwr_pin@0 {
++allwinner,pins = PH2;
++			};
++
++			led_pins_pcduino3: led_pins@0 {
++allwinner,pins = PH15, PH16;
++allwinner,function = gpio_out;
++allwinner,drive = 0;
++allwinner,pull = 0;
++			};
++
++			key_pins_pcduino3: key_pins@0 {
++allwinner,pins = PH17, PH18, PH19;
++allwinner,function = gpio_in;
++allwinner,drive = 0;
++allwinner,pull = 0;
++			};
++		};
++
++		ir0: ir@01c21800 {
++			pinctrl-names = default;
++			pinctrl-0 = ir0_pins_a;
++			status = okay;
++		};
++
++		uart0: serial@01c28000 {
++			pinctrl-names = default;
++			pinctrl-0 = uart0_pins_a;
++			status = okay;
++		};
++
++		i2c0: i2c@01c2ac00 {
++			pinctrl-names = default;
++			pinctrl-0 = i2c0_pins_a;
++			status = okay;
++
++			axp209: pmic@34 {
++compatible = x-powers,axp209;
++reg = 0x34;
++interrupt-parent = nmi_intc;
++interrupts = 0 8;
++
++interrupt-controller;
++#interrupt-cells = 1;
++			};
++		};
++
++		gmac: 

Bug#773645: debian-cd: [armhf/armel/arm64] u-boot-tools missing on CD1 - d-i fails

[Karsten Merker]

Package: debian-cd
Severity: important

Hello,

in the current daily CD builds, the first armhf CD does not
include the package u-boot-tools.  This package is required by
d-i to make the system bootable at the end of the installation on
nearly all armhf systems.  As a consequence, single-CD
installations, respectively hd-media installations that use the
first CD iso, fail completely if no network access is available
during the d-i run. From looking at the flash-kernel machine
database, the situation will probably be the same for armel and
arm64, so please include u-boot-tools on the first CD for
armhf/armel/arm64.

From the d-i log with CD1 but no network access:

in-target: Setting up flash-kernel (3.28) ...
in-target:
in-target: Creating config file /etc/default/flash-kernel with new version^
in-target: Reading package lists...
in-target:
in-target: Building dependency tree...
in-target:
in-target: Reading state information...
in-target:
in-target: Package u-boot-tools is not available, but is referred to by another 
package.
in-target: This may mean that the package is missing, has been obsoleted, or
in-target: is only available from another source
in-target:
in-target: E: Package 'u-boot-tools' has no installation candidate
flash-kernel-installer: error: apt-install u-boot-tools failed

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773127: installation-reports: mostly Successful: Wandboard Quad [armhf]

[Karsten Merker]

On Sun, Dec 14, 2014 at 02:31:45PM -0800, Vagrant Cascadian wrote:
 On 2014-12-14, Karsten Merker wrote:
  Could you perhaps give a short list of which hardware components
  are working with Debian's kernel, so that I can add that to the
  installation guide as well?  I understand from your installation
  report that MMC, LAN, USB and HDMI video work.
 
 Yes, those all work.

[SATA and serial console ok, WLAN/Bluetooth and Audio not working]

Thanks, I have added this information to the installation guide.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773127: installation-reports: mostly Successful: Wandboard Quad [armhf]

[Karsten Merker]

On Sun, Dec 14, 2014 at 12:02:09PM -0800, Vagrant Cascadian wrote:

 Package: installation-reports
 Boot method: netboot
 Image version: 
 http://d-i.debian.org/daily-images/armhf/20141214-05:27/netboot/
 Date: 20141214
 
 Machine: Wandboard Quad

 Installing with the console installer worked fine.

Hello,

based on your installation report, I have just added the
Wandboard Quad to the list of supported systems in the
installation guide.

Could you perhaps give a short list of which hardware components
are working with Debian's kernel, so that I can add that to the
installation guide as well?  I understand from your installation
report that MMC, LAN, USB and HDMI video work.  The module list
shows modules loaded for SATA and WLAN, but I cannot assess from
the module list whether these actually work correctly (on some
systems there can be be issues with GPIO-controlled regulators
for the SATA power or a requirement for OOB communication to the
SDIO WLAN module), so I would appreciate an explicit
confirmation.  Besides these, do the following components work?

- Serial Console
- Audio (HDMI, analog, S/PDIF)
- USB OTG
- Bluetooth

Kind Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769728: [jessie daily 2014-11-15] installation-report: regression when deselecting the standard system utilities task

[Karsten Merker]

Package: installation-reports

Boot method: netboot
Image version: http://d-i.debian.org/daily-images/armhf/daily/netboot/
   dated 15-Nov-2014 05:25
Date: 2014-11-15

Machine: Cubietech Cubietruck
Processor: Allwinner A20 (2x Cortex A7)
Memory: 2GB

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:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[E]

Comments/Problems:
The installation itself works flawlessly, but when installing a
minimal system by deselecting standard system utilities in
tasksel, on booting the installed system the systemd error
message [FAILED] Failed to start Login Service gets shown
several times.

systemctl status -l systemd-logind.service results in:
-8--8--8--8--8--8-
 systemd-logind.service - Login Service
   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
   Active: failed (Result: start-limit) since Sat 2014-11-15 22:21:56 CET; 1min 
13s ago
 Docs: man:systemd-logind.service(8)
   man:logind.conf(5)
   http://www.freedesktop.org/wiki/Software/systemd/logind
   http://www.freedesktop.org/wiki/Software/systemd/multiseat
  Process: 273 ExecStart=/lib/systemd/systemd-logind (code=exited, 
status=1/FAILURE)
 Main PID: 273 (code=exited, status=1/FAILURE)
   Status: Shutting down...

Nov 15 22:21:56 debian systemd[1]: Failed to start Login Service.
Nov 15 22:21:56 debian systemd[1]: Unit systemd-logind.service entered failed 
state.
Nov 15 22:21:56 debian systemd[1]: systemd-logind.service has no holdoff time, 
scheduling restart.
Nov 15 22:21:56 debian systemd[1]: Stopping Login Service...
Nov 15 22:21:56 debian systemd[1]: Starting Login Service...
Nov 15 22:21:56 debian systemd[1]: systemd-logind.service start request 
repeated too quickly, refusing to start.
Nov 15 22:21:56 debian systemd[1]: Failed to start Login Service.
Nov 15 22:21:56 debian systemd[1]: Unit systemd-logind.service entered failed 
state.
-8--8--8--8--8--8-

When standard system utilities is selected in tasksel, the
problem does not occur.  Deselecting standard system utilities
did not have any negatve effect on the boot process when d-i
still installed SysV-init as the default init system, so this is
a regression.

Following is a full boot log of an installation with standard
system utilities deselected in tasksel:

-8--8--8--8--8--8-

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-4-armmp-lpae 
(debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP 
Debian 3.16.7-2 (2014-11-06)
[0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=30c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine model: Cubietech Cubietruck
[0.00] Forcing write-allocate cache policy for SMP
[0.00] Memory policy: Data cache writealloc
[0.00] psci: probing for conduit method from DT.
[0.00] psci: Using PSCI v0.1 Function IDs from DT
[0.00] PERCPU: Embedded 9 pages/cpu @ee7cc000 s13248 r8192 d15424 u36864
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 522768
[0.00] Kernel command line: console=ttyS0,115200 console=ttyS0,115200
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 2057220K/2097152K available (6558K kernel code, 837K 
rwdata, 2208K rodata, 700K init, 396K bss, 39932K reserved, 1318912K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xffe0   (2048 kB)
[0.00] vmalloc : 0xf000 - 0xff00   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xef80   ( 760 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc0897da0   (8768 kB)
[0.00]   .init : 0xc0898000 - 0xc09473c0   ( 701 kB)
[0.00]   .data : 0xc0948000 - 0xc0a197f8   ( 838 kB)
[0.00].bss : 0xc0a197f8 - 0xc0a7cbf4   ( 397 kB)
[

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Karsten Merker]

Control: tag -1 patch

On Wed, Nov 05, 2014 at 09:52:40PM +0100, Karsten Merker wrote:

 [Failing ethernet PHY detection in d-i on the BananaPi]

 Further experiments show that increasing the startup-delay-us
 value in the regulator definition seems to solve the issue.  I'll
 do some further experiments to determine a value that is long
 enough for a reliable detection without being unnecessary long
 and discuss the issue with the upstream author.

A patch to solve the issue has been accepted upstream (see
https://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/301727.html).
Attached is a backport of this patch for inclusion into the
upcoming linux 3.16.7-3 package.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Index: debian/patches/features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch
===
--- debian/patches/features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch	(Revision 0)
+++ debian/patches/features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch	(Arbeitskopie)
@@ -0,0 +1,35 @@
+From f82f99afaa65fd28d0f8409c50e8fcc65ee5e15b Mon Sep 17 00:00:00 2001
+From: Karsten Merker mer...@debian.org
+Date: Wed, 12 Nov 2014 00:01:46 +0100
+Subject: ARM: dts: sunxi: Banana Pi: increase startup-delay for the GMAC PHY  regulator
+Origin: https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/commit/?h=sunxi/dt-for-3.19id=f82f99afaa65fd28d0f8409c50e8fcc65ee5e15b
+
+On the LeMaker Banana Pi, probing the external ethernet PHY connected
+to the SoC's internal GMAC module sometimes fails. The PHY power
+supply is handled via a GPIO-controlled regulator, and the existing
+regulator startup-delay of 5us is too short to make sure that the
+PHY is always fully powered up when it is queried by phylib. Tests
+have shown that to provide a reliable PHY detection, the startup-delay
+has to be increased to at least 6us. To have a certain safety margin
+and to cater for manufacturing variations between different boards,
+the delay gets set to 10us as discussed on the linux-arm-kernel
+mailinglist.
+
+Signed-off-by: Karsten Merker mer...@debian.org
+Acked-by: Hans de Goede hdego...@redhat.com
+Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
+
+diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+index 3de847d..1cf1214 100644
+--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
 b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+@@ -207,7 +207,7 @@
+ 		regulator-name = gmac-3v3;
+ 		regulator-min-microvolt = 330;
+ 		regulator-max-microvolt = 330;
+-		startup-delay-us = 5;
++		startup-delay-us = 10;
+ 		enable-active-high;
+ 		gpio = pio 7 23 0;
+ 	};
+
Index: debian/patches/series
===
--- debian/patches/series	(Revision 22061)
+++ debian/patches/series	(Arbeitskopie)
@@ -113,6 +113,7 @@
 features/arm/dts-sun7i-Add-spi0_pins_a-pinctrl-setting.patch
 features/arm/dts-sun7i-Add-uart3_pins_b-pinctrl-setting.patch
 features/arm/dts-sun7i-Add-Banana-Pi-board.patch
+features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch
 features/arm/dts-sun7i-Add-support-for-Olimex-A20-OLinuXino-LIME.patch
 features/arm64/drivers-net-Add-APM-X-Gene-SoC-ethernet-driver-suppo.patch
 features/arm64/drivers-net-NET_XGENE-should-depend-on-HAS_DMA.patch

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Karsten Merker]

On Wed, Nov 05, 2014 at 10:45:12AM +, Ian Campbell wrote:
 On Tue, 2014-11-04 at 22:37 +0100, Karsten Merker wrote:
 
  I have run further installation tests with today's current d-i images
  (still based on the same 3.16.5-1 kernel)
 
 OOI if you bodge your way through the install does the resulting system
 boot and discover the PHY reliably? IOW is it specific to d-i or not?

Ethernet works in the installed system (tested with several cold
and warm boots):

[2.448442] stmmaceth 1c5.ethernet: no reset control found
[2.454322]  Ring mode enabled
[2.457396]  No HW DMA feature register supported
[2.461941]  Normal descriptors
[2.465279]  TX Checksum insertion supported
[2.495563] libphy: stmmac: probed
[2.499078] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
[2.505490] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
 
  i.e. the PHY appears to have a seperate regulator on the
  BananaPi but not on the Cubietruck and I wonder whether the
  
  startup-delay-us = 5;
  
  might play a role here.
 
 I think that's a decent theory. Decent enoguh that it is probably worth
 taking it up with the sunxi kernel folks.
 
 Might also be the power supply differs between the two boards?

Running the BananaPi with the Cubietruck's power supply does not
change the behaviour.

I have now run several tests with a modified BananaPi dtb in
which I have added a regulator-always-on stanza to the
reg_gmac_3v3 definition.  With this change the PHY detection in
d-i has worked every time, so this would support the theory that
the regulator might not be powered up fast enough for the PHY
detection to succeed, but I cannot see why this problem only
occurs within the d-i environment.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Karsten Merker]

On Wed, Nov 05, 2014 at 09:01:08PM +0100, Karsten Merker wrote:

[Failing ethernet PHY detection in d-i on the BananaPi]
 I have now run several tests with a modified BananaPi dtb in
 which I have added a regulator-always-on stanza to the
 reg_gmac_3v3 definition.  With this change the PHY detection in
 d-i has worked every time, so this would support the theory that
 the regulator might not be powered up fast enough for the PHY
 detection to succeed, but I cannot see why this problem only
 occurs within the d-i environment.

Further experiments show that increasing the startup-delay-us
value in the regulator definition seems to solve the issue.  I'll
do some further experiments to determine a value that is long
enough for a reliable detection without being unnecessary long
and discuss the issue with the upstream author.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Karsten Merker]

On Mon, Nov 03, 2014 at 12:26:33AM +, Ben Hutchings wrote:

 On Sun, 2014-11-02 at 21:43 +0100, Karsten Merker wrote:
 [...]
  Following is the log from a d-i run where /sbin/modprobe and
  /sbin/insmod have been replaced by a script that logs all
  invocations of these two binaries with a modules-debug prefix
  before executing the original binary:
 [...]
  The entry at 00:03:37 does not show a modprobe invocation before
  the initialization of the stmmac module, so the module does not
  seem to be loaded by calling modprobe, which would explain why no
  autoloading of the PHY driver happens there.  What I do not
  understand is that I also see no insmod invocation, and logging
  insmod invocations works when I run insmod from a shell. So the
  question remains: how is the stmmac module loaded at that point?
  I first thought that something might invoke kmod directly (i.e. 
  not by calling the insmod/modprobe aliases), but logging direct
  kmod invocations also shows nothing, so I am probably overlooking
  something.
  
  Any ideas?
 
 So far as I can see, ethdetect runs hw-detect, which runs update-dev,
 which runs 'udevadm trigger --action=add --subsystem-nomatch=sound' and
 that should result in udev loading stmmac.  (udev won't have done that
 when it started because the stmmac module wasn't included in the
 initramfs.)
 
 udev is now linked with libkmod, so it can load modules without running
 modprobe, and most driver modules get loaded that way.  But as I said
 before, this isn't the case for the PHY driver modules.
 
 So, I think this shows the kernel is not running modprobe for some
 reason.

Things are getting even stranger:

I have run further installation tests with today's current d-i images
(still based on the same 3.16.5-1 kernel)

- http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz
  dated 04-Nov-2014 05:16 and
- 
http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo
  dated 2014-11-03 12:14)

on a Cubietruck and on the BananaPi. On the Cubietruck everything
works while on the BananaPi the PHY is not found. Both are
booted from the same USB stick, so there cannot be any
differences in the installer image.  The hardware on both is
rather similar (Allwinner A20 SoC with integrated MAC, external
Realtek PHY) and they show the same PHY ID once the probing was
successful, so I assume that they use identical PHY chips:

Cubietruck:
---
Jan  1 00:06:47 main-menu[179]: INFO: Menu item 'ethdetect' selected
Jan  1 00:06:48 kernel: [   78.983839] cfg80211: Calling CRDA to update world 
regulatory domain
Jan  1 00:06:49 kernel: [   78.998759] brcmfmac_sdio mmc1:0001:1: firmware: 
failed to load brcm/brcmfmac43362-sdio.bin (-2)
Jan  1 00:06:49 kernel: [   79.057067] stmmaceth 1c5.ethernet: no regulator 
found
Jan  1 00:06:49 kernel: [   79.057202] stmmaceth 1c5.ethernet: no reset 
control found
Jan  1 00:06:49 kernel: [   79.057218]  Ring mode enabled
Jan  1 00:06:49 kernel: [   79.057226]  No HW DMA feature register supported
Jan  1 00:06:49 kernel: [   79.057233]  Normal descriptors
Jan  1 00:06:49 kernel: [   79.057241]  TX Checksum insertion supported
Jan  1 00:06:49 kernel: [   79.171058] libphy: stmmac: probed
Jan  1 00:06:49 kernel: [   79.171089] eth0: PHY ID 001cc915 at 0 IRQ POLL 
(stmmac-0:00) active
Jan  1 00:06:49 kernel: [   79.171100] eth0: PHY ID 001cc915 at 1 IRQ POLL 
(stmmac-0:01)


BananaPi:
-
 No Ethernet card was detected. If you know the name of the driver
 needed by your Ethernet card, you can select it from the list.

-- shell

~ # lsmod |grep realtek
~ # dmesg | tail -8
[   32.138512] ISO 9660 Extensions: RRIP_1991A
[   77.235117] stmmaceth 1c5.ethernet: no reset control found
[   77.235192]  Ring mode enabled
[   77.235202]  No HW DMA feature register supported
[   77.235211]  Normal descriptors
[   77.235219]  TX Checksum insertion supported
[   77.242678] libphy: stmmac: probed
[   77.242708] eth0: No PHY found
~ # rmmod stmmac
~ # modprobe stmmac
~ # lsmod |grep realtek
realtek 1563  0
~ # dmesg | tail -8
[  148.823456] stmmaceth 1c5.ethernet: no reset control found
[  148.823487]  Ring mode enabled
[  148.823496]  No HW DMA feature register supported
[  148.823502]  Normal descriptors
[  148.823509]  TX Checksum insertion supported
[  148.854654] libphy: stmmac: probed
[  148.854683] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
[  148.854694] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
~ #

The main visible difference between the two systems is that the
Cubietruck also has a Broadcom 43362 SDIO Wifi module and d-i
asks for the non-free firmware for it before the stmmac gets
initialized, but I do not see how that should make a difference
regarding the realtek PHY driver.

What makes me wonder is the line

  stmmaceth 1c5.ethernet: no regulator found

on the Cubietruck that does not appear on the BananaPi. Could
there perhaps be some

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Karsten Merker]

On Tue, Oct 28, 2014 at 11:14:40PM +0100, Karsten Merker wrote:
 On Mon, Oct 27, 2014 at 11:54:47PM +, Ben Hutchings wrote:

  I don't understand this.
  
   Karsten Merker mer...@debian.org (2014-10-27):
  [...]
[   73.104782] libphy: stmmac: probed
[   73.104812] eth0: No PHY found

i.e. the correct ethernet MAC driver (stmmac) gets loaded
automatically, but the necessary PHY driver (realtek) does not.
  [...]
[  499.392561] libphy: stmmac: probed
[  499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
[  499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)

and the ethernet interface works. The kernel version used in this
installer build is 3.16.5-1.
  
  $ modinfo -F alias realtek
  mdio:???111001100100100010101
  mdio:???111001100100100010010
  
  In hex those are 1cc915 and 1cc912.  (The 11 most significant bits are
  unspecified.)  So modprobe certainly should find this module when
  requested by phylib.
 
 I have retried the installation today and tried something I had
 not done yesterday: just rmmod and directly afterwards modprobe
 the stmmac module.  This results in the realtek PHY module
 getting auto-loaded, so the modprobe mechanism seems to work
 correctly there, but the question remains why this does not
 happen upon the first loading of the stmmac module.
 
 A protocol from d-i:
 
 No Ethernet card was detected. If you know the name of the driver
  needed by your Ethernet card, you can select it from the list.
 
 -- start shell
 
 ~ # lsmod
 Module  Size  Used by
 stmmac 73442  0
 nls_utf81170  2
 nls_cp437   4767  1
 loop   16202  2
 isofs  31318  1
 vfat9621  1
 fat52693  1 vfat
 ext4  485433  0
 crc16   1146  1 ext4
 mbcache 8210  1 ext4
 jbd2   88199  1 ext4
 sg 20824  0
 sd_mod 38535  2
 crc_t10dif  1041  1 sd_mod
 crct10dif_common1159  1 crc_t10dif
 usb_storage41751  1
 ahci_sunxi  2652  0
 libahci_platform4679  1 ahci_sunxi
 libahci23069  1 libahci_platform
 libata161761  3 libahci,libahci_platform,ahci_sunxi
 ohci_platform   4062  0
 ohci_hcd   37591  1 ohci_platform
 scsi_mod  175644  4 sg,usb_storage,libata,sd_mod
 ehci_platform   4526  0
 phy_sun4i_usb   4216  4
 ehci_hcd   64373  1 ehci_platform
 sunxi_mmc  10557  0
 ~ # dmesg | tail -8
 [   31.558145] ISO 9660 Extensions: RRIP_1991A
 [   77.839161] stmmaceth 1c5.ethernet: no reset control found
 [   77.839194]  Ring mode enabled
 [   77.839202]  No HW DMA feature register supported
 [   77.839210]  Normal descriptors
 [   77.839217]  TX Checksum insertion supported
 [   77.844560] libphy: stmmac: probed
 [   77.844589] eth0: No PHY found
 ~ # rmmod stmmac
 ~ # modprobe stmmac
 ~ # dmesg | tail -8
 [  330.112850] stmmaceth 1c5.ethernet: no reset control found
 [  330.112883]  Ring mode enabled
 [  330.112891]  No HW DMA feature register supported
 [  330.112898]  Normal descriptors
 [  330.112905]  TX Checksum insertion supported
 [  330.140101] libphy: stmmac: probed
 [  330.140139] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
 [  330.140150] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
 ~ # lsmod
 Module  Size  Used by
 realtek 1563  0
 stmmac 73442  0
 nls_utf81170  2
 nls_cp437   4767  1
 loop   16202  2
 isofs  31318  1
 vfat9621  1
 fat52693  1 vfat
 ext4  485433  0
 crc16   1146  1 ext4
 mbcache 8210  1 ext4
 jbd2   88199  1 ext4
 sg 20824  0
 sd_mod 38535  2
 crc_t10dif  1041  1 sd_mod
 crct10dif_common1159  1 crc_t10dif
 usb_storage41751  1
 ahci_sunxi  2652  0
 libahci_platform4679  1 ahci_sunxi
 libahci23069  1 libahci_platform
 libata161761  3 libahci,libahci_platform,ahci_sunxi
 ohci_platform   4062  0
 ohci_hcd   37591  1 ohci_platform
 scsi_mod  175644  4 sg,usb_storage,libata,sd_mod
 ehci_platform   4526  0
 phy_sun4i_usb   4216  4
 ehci_hcd   64373  1 ehci_platform
 sunxi_mmc  10557  0
 
  As udev is *not* involved in loading MDIO PHY drivers (NIC drivers
  expect them to be bound synchronously) it isn't easy to monitor what's
  going on.  You could replace modprobe with a script that logs its
  arguments to a file before calling the real modprobe.  That should tell
  us whether the bug is in the kernel or userland.
 
 I

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Karsten Merker]

On Mon, Oct 27, 2014 at 11:54:47PM +, Ben Hutchings wrote:
 On Tue, 2014-10-28 at 00:18 +0100, Cyril Brulebois wrote:
  Cc+=debian-kernel@ for input since I seem to recall having seen PHY
  drivers (including in a realtek context) being mentioned lately, at
  least on IRC, maybe on list as well.
 
 I don't understand this.
 
  Karsten Merker mer...@debian.org (2014-10-27):
 [...]
   [   73.104782] libphy: stmmac: probed
   [   73.104812] eth0: No PHY found
   
   i.e. the correct ethernet MAC driver (stmmac) gets loaded
   automatically, but the necessary PHY driver (realtek) does not.
 [...]
   [  499.392561] libphy: stmmac: probed
   [  499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
   [  499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
   
   and the ethernet interface works. The kernel version used in this
   installer build is 3.16.5-1.
 
 $ modinfo -F alias realtek
 mdio:???111001100100100010101
 mdio:???111001100100100010010
 
 In hex those are 1cc915 and 1cc912.  (The 11 most significant bits are
 unspecified.)  So modprobe certainly should find this module when
 requested by phylib.

I have retried the installation today and tried something I had
not done yesterday: just rmmod and directly afterwards modprobe
the stmmac module.  This results in the realtek PHY module
getting auto-loaded, so the modprobe mechanism seems to work
correctly there, but the question remains why this does not
happen upon the first loading of the stmmac module.

A protocol from d-i:

No Ethernet card was detected. If you know the name of the driver
 needed by your Ethernet card, you can select it from the list.

-- start shell

~ # lsmod
Module  Size  Used by
stmmac 73442  0
nls_utf81170  2
nls_cp437   4767  1
loop   16202  2
isofs  31318  1
vfat9621  1
fat52693  1 vfat
ext4  485433  0
crc16   1146  1 ext4
mbcache 8210  1 ext4
jbd2   88199  1 ext4
sg 20824  0
sd_mod 38535  2
crc_t10dif  1041  1 sd_mod
crct10dif_common1159  1 crc_t10dif
usb_storage41751  1
ahci_sunxi  2652  0
libahci_platform4679  1 ahci_sunxi
libahci23069  1 libahci_platform
libata161761  3 libahci,libahci_platform,ahci_sunxi
ohci_platform   4062  0
ohci_hcd   37591  1 ohci_platform
scsi_mod  175644  4 sg,usb_storage,libata,sd_mod
ehci_platform   4526  0
phy_sun4i_usb   4216  4
ehci_hcd   64373  1 ehci_platform
sunxi_mmc  10557  0
~ # dmesg | tail -8
[   31.558145] ISO 9660 Extensions: RRIP_1991A
[   77.839161] stmmaceth 1c5.ethernet: no reset control found
[   77.839194]  Ring mode enabled
[   77.839202]  No HW DMA feature register supported
[   77.839210]  Normal descriptors
[   77.839217]  TX Checksum insertion supported
[   77.844560] libphy: stmmac: probed
[   77.844589] eth0: No PHY found
~ # rmmod stmmac
~ # modprobe stmmac
~ # dmesg | tail -8
[  330.112850] stmmaceth 1c5.ethernet: no reset control found
[  330.112883]  Ring mode enabled
[  330.112891]  No HW DMA feature register supported
[  330.112898]  Normal descriptors
[  330.112905]  TX Checksum insertion supported
[  330.140101] libphy: stmmac: probed
[  330.140139] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
[  330.140150] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
~ # lsmod
Module  Size  Used by
realtek 1563  0
stmmac 73442  0
nls_utf81170  2
nls_cp437   4767  1
loop   16202  2
isofs  31318  1
vfat9621  1
fat52693  1 vfat
ext4  485433  0
crc16   1146  1 ext4
mbcache 8210  1 ext4
jbd2   88199  1 ext4
sg 20824  0
sd_mod 38535  2
crc_t10dif  1041  1 sd_mod
crct10dif_common1159  1 crc_t10dif
usb_storage41751  1
ahci_sunxi  2652  0
libahci_platform4679  1 ahci_sunxi
libahci23069  1 libahci_platform
libata161761  3 libahci,libahci_platform,ahci_sunxi
ohci_platform   4062  0
ohci_hcd   37591  1 ohci_platform
scsi_mod  175644  4 sg,usb_storage,libata,sd_mod
ehci_platform   4526  0
phy_sun4i_usb   4216  4
ehci_hcd   64373  1 ehci_platform
sunxi_mmc  10557  0

 As udev is *not* involved in loading MDIO PHY drivers (NIC drivers
 expect them to be bound synchronously) it isn't easy to monitor what's
 going on.  You could replace modprobe with a script that logs its
 arguments to a file before calling the real modprobe.  That should tell
 us

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Karsten Merker]

Package: installation-reports

Boot method: hd-media (installer booted from USB stick)
Image version:
  http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz
  (dated 27-Oct-2014 05:17) together with
  
http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo
  (dated 2014-10-27 11:58)
Date: 2014-10-27
U-Boot: 2014.10+dfsg1-1

Machine: LeMaker Banana Pi
Processor: Allwinner A20 (2x Cortex A7)
Memory: 1GB
Mass Storage: 16GB SD card

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

Initial boot:   [O]
Detect network card:[E] (see comments below, getting this to work 
 requires manual loading of the proper
 ethernet PHY driver module)
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:
The detect network hardware step fails with
No Ethernet card was detected. If you know the name of the driver
 needed by your Ethernet card, you can select it from the list.

dmesg shows:
[   73.100072] stmmaceth 1c5.ethernet: no reset control found
[   73.100103]  Ring mode enabled
[   73.100112]  No HW DMA feature register supported
[   73.100120]  Normal descriptors
[   73.100127]  TX Checksum insertion supported
[   73.104782] libphy: stmmac: probed
[   73.104812] eth0: No PHY found

i.e. the correct ethernet MAC driver (stmmac) gets loaded
automatically, but the necessary PHY driver (realtek) does not.
Loading the realtek module after the stmmac driver has probed
for a PHY does not change anything; the stmmac driver does not
re-probe for a PHY upon later loading of the PHY driver.
Manually unloading the stmmac module, loading the PHY driver
and then loading the stmmac module again from a shell by
running

~ # rmmod stmmac
~ # modprobe realtek
~ # modprobe stmmac

results in

[  499.364044] stmmaceth 1c5.ethernet: no reset control found
[  499.364076]  Ring mode enabled
[  499.364084]  No HW DMA feature register supported
[  499.364090]  Normal descriptors
[  499.364097]  TX Checksum insertion supported
[  499.392561] libphy: stmmac: probed
[  499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
[  499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)

and the ethernet interface works. The kernel version used in this
installer build is 3.16.5-1.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764967: Please backport dts for the Olimex A20-OLinuXino-LIME

[Karsten Merker]

On Sun, 12 Oct 2014 18:23:24 +0200 Christian Kastner deb...@kvr.at wrote:

 would it be possible to include the dts for the Olimex
 A20-OLinuXino-LIME in 3.16 so that it can be used with Jessie? This
 device is almost identical to the already existing A10-OLinuXino-LIME;
 they only differ in the processor.
 
 The relevant commit from 3.17 is:
 
   a71b443   ARM: sun7i: Add support for Olimex A20-OLinuXino-LIME

The patch from 

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=a71b4438af8242f383906071205db95a8b8e7b6d

does not apply cleanly against the current 3.16.5-2 kernel
package SVN.  A patch against current SVN with a refreshed
version of the original patch (no content changes) is attached.
A test build is currently running, but will take until tomorrow.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Index: debian/patches/features/arm/dts-sun7i-Add-support-for-Olimex-A20-OLinuXino-LIME.patch
===
--- debian/patches/features/arm/dts-sun7i-Add-support-for-Olimex-A20-OLinuXino-LIME.patch	(Revision 0)
+++ debian/patches/features/arm/dts-sun7i-Add-support-for-Olimex-A20-OLinuXino-LIME.patch	(Arbeitskopie)
@@ -0,0 +1,160 @@
+From a71b4438af8242f383906071205db95a8b8e7b6d Mon Sep 17 00:00:00 2001
+From: FUKAUMI Naoki nao...@gmail.com
+Date: Wed, 20 Aug 2014 14:25:03 +0900
+Subject: ARM: sun7i: Add support for Olimex A20-OLinuXino-LIME
+
+This patch adds support for Olimex A20-OLinuXino-LIME board.
+
+Signed-off-by: FUKAUMI Naoki nao...@gmail.com
+Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
+
+--- a/arch/arm/boot/dts/Makefile
 b/arch/arm/boot/dts/Makefile
+@@ -380,6 +380,7 @@
+ 	sun7i-a20-cubieboard2.dtb \
+ 	sun7i-a20-cubietruck.dtb \
+ 	sun7i-a20-i12-tvbox.dtb \
++	sun7i-a20-olinuxino-lime.dtb \
+ 	sun7i-a20-olinuxino-micro.dtb
+ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
+ 	tegra20-iris-512.dtb \
+--- /dev/null
 b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
+@@ -0,0 +1,137 @@
++/*
++ * This is based on sun4i-a10-olinuxino-lime.dts
++ *
++ * Copyright 2014 - Hans de Goede hdego...@redhat.com
++ * Copyright (c) 2014 FUKAUMI Naoki nao...@gmail.com
++ *
++ * The code contained herein is licensed under the GNU General Public
++ * License. You may obtain a copy of the GNU General Public License
++ * Version 2 or later at the following locations:
++ *
++ * http://www.opensource.org/licenses/gpl-license.html
++ * http://www.gnu.org/copyleft/gpl.html
++ */
++
++/dts-v1/;
++/include/ sun7i-a20.dtsi
++/include/ sunxi-common-regulators.dtsi
++
++/ {
++	model = Olimex A20-OLinuXino-LIME;
++	compatible = olimex,a20-olinuxino-lime, allwinner,sun7i-a20;
++
++	soc@01c0 {
++		mmc0: mmc@01c0f000 {
++			pinctrl-names = default;
++			pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_reference_design;
++			vmmc-supply = reg_vcc3v3;
++			bus-width = 4;
++			cd-gpios = pio 7 1 0; /* PH1 */
++			cd-inverted;
++			status = okay;
++		};
++
++		usbphy: phy@01c13400 {
++			usb1_vbus-supply = reg_usb1_vbus;
++			usb2_vbus-supply = reg_usb2_vbus;
++			status = okay;
++		};
++
++		ehci0: usb@01c14000 {
++			status = okay;
++		};
++
++		ohci0: usb@01c14400 {
++			status = okay;
++		};
++
++		ahci: sata@01c18000 {
++			target-supply = reg_ahci_5v;
++			status = okay;
++		};
++
++		ehci1: usb@01c1c000 {
++			status = okay;
++		};
++
++		ohci1: usb@01c1c400 {
++			status = okay;
++		};
++
++		pinctrl@01c20800 {
++			ahci_pwr_pin_olinuxinolime: ahci_pwr_pin@1 {
++allwinner,pins = PC3;
++allwinner,function = gpio_out;
++allwinner,drive = 0;
++allwinner,pull = 0;
++			};
++
++			led_pins_olinuxinolime: led_pins@0 {
++allwinner,pins = PH2;
++allwinner,function = gpio_out;
++allwinner,drive = 1;
++allwinner,pull = 0;
++			};
++		};
++
++		uart0: serial@01c28000 {
++			pinctrl-names = default;
++			pinctrl-0 = uart0_pins_a;
++			status = okay;
++		};
++
++		i2c0: i2c@01c2ac00 {
++			pinctrl-names = default;
++			pinctrl-0 = i2c0_pins_a;
++			status = okay;
++
++			axp209: pmic@34 {
++compatible = x-powers,axp209;
++reg = 0x34;
++interrupt-parent = nmi_intc;
++interrupts = 0 8;
++
++interrupt-controller;
++#interrupt-cells = 1;
++			};
++		};
++
++		gmac: ethernet@01c5 {
++			pinctrl-names = default;
++			pinctrl-0 = gmac_pins_mii_a;
++			phy = phy1;
++			phy-mode = mii;
++			status = okay;
++
++			phy1: ethernet-phy@1 {
++reg = 1;
++			};
++		};
++	};
++
++	leds {
++		compatible = gpio-leds;
++		pinctrl-names = default;
++		pinctrl-0 = led_pins_olinuxinolime;
++
++		green {
++			label = a20-olinuxino-lime:green:usr;
++			gpios = pio 7 2 0;
++			default-state = on;
++		};
++	};
++
++	reg_ahci_5v: ahci-5v {
++		pinctrl-0 = ahci_pwr_pin_olinuxinolime;
++		gpio = pio 2 3 0;
++		status = okay;
++	};
++
++	

Bug#763005: installation-guide is marked for autoremoval from testing

[Karsten Merker]

Control: reassign -1 www.debian.org
Control: severity -1 normal
thanks

On Sun, Oct 12, 2014 at 04:39:03AM +, Debian testing autoremoval watch 
wrote:
 installation-guide 20140916 is marked for autoremoval from testing on 
 2014-10-26
 
 It is affected by these RC bugs:
 763005: installation-guide-amd64: website for wheezy leads to jessie 
 installation guide

From looking at the bug report this has not actually been a bug
in the installation-guide package, but a problem in the cron job
that puts the installtion guide onto the website, so this should
not result in a package removal from testing.

The cron job has been manually fixed up, so the actual problem
(wrong version of the guide on the website) does not occur
anymore at the moment.  What is still open is how to change the
cronjob to handle this better/automatically in the future, but
that IMHO does not justify an RC bug against the manual itself.

I therefore assign this bug to www.debian.org and lower the
severity to normal.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763897: linux 3.16.3-2: [PATCH] Please add a dts for the LeMaker Banana Pi

[Karsten Merker]

Source: linux 
Version: 3.16.3-2
Severity: Wishlist
Tags: patch

Hello,

the LeMaker Banana Pi is a small ARM development board based on
the Allwinner A20 SoC.  Several DDs have received one of these
boards at Debconf 14 and it would be really nice to have it
supported in Jessie's kernel 3.16.

Driver support for the board (UART, MMC, SATA, USB, Ethernet)
is already available in kernel 3.16, just the device-tree
information is missing.

A dts patchset for the board has been written by Hans de Goede
(see 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/292110.html)
and has been accepted upstream
(see 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/292431.html).

Attached is a patch against the current sid linux package SVN tree that
contains a backport of this patchset to kernel 3.16.  No content changes
were applied to the patchset, the patches were just refreshed to apply
cleanly against 3.16.  Included is also another dts patch from linux-next,
on which the patchset depends:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=0fc2b7af8cd5918c0101dfb178b5a3a4b021a50b

I would apprechiate very much if you could include this patch
into the linux 3.16.3-3 package for Jessie.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Index: debian/patches/features/arm/dts-sun7i-Add-Banana-Pi-board.patch
===
--- debian/patches/features/arm/dts-sun7i-Add-Banana-Pi-board.patch	(revision 0)
+++ debian/patches/features/arm/dts-sun7i-Add-Banana-Pi-board.patch	(working copy)
@@ -0,0 +1,244 @@
+From: Hans de Goede hdego...@redhat.com
+Subject: [PATCH v2 3/3] ARM: dts: sun7i: Add Banana Pi board
+Date: Wed,  1 Oct 2014 09:26:06 +0200
+
+The Banana Pi is an A20 based development board using Raspberry Pi compatible
+IO headers. It comes with 1 GB RAM, 1 Gb ethernet, 2x USB host, sata, hdmi
+and stereo audio out + various expenansion headers:
+
+http://www.lemaker.org/
+
+Signed-off-by: Hans de Goede hdego...@redhat.com
+---
+ arch/arm/boot/dts/Makefile   |   1 +
+ arch/arm/boot/dts/sun7i-a20-bananapi.dts | 214 +++
+ 2 files changed, 215 insertions(+)
+ create mode 100644 arch/arm/boot/dts/sun7i-a20-bananapi.dts
+
+--- a/arch/arm/boot/dts/Makefile
 b/arch/arm/boot/dts/Makefile
+@@ -376,6 +376,7 @@
+ 	sun6i-a31-colombus.dtb \
+ 	sun6i-a31-m9.dtb
+ dtb-$(CONFIG_MACH_SUN7I) += \
++	sun7i-a20-bananapi.dtb \
+ 	sun7i-a20-cubieboard2.dtb \
+ 	sun7i-a20-cubietruck.dtb \
+ 	sun7i-a20-i12-tvbox.dtb \
+--- /dev/null
 b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+@@ -0,0 +1,214 @@
++/*
++ * Copyright 2014 Hans de Goede hdego...@redhat.com
++ *
++ * Hans de Goede hdego...@redhat.com
++ *
++ * This file is dual-licensed: you can use it either under the terms
++ * of the GPL or the X11 license, at your option. Note that this dual
++ * licensing only applies to this file, and not this project as a
++ * whole.
++ *
++ *  a) This library is free software; you can redistribute it and/or
++ * modify it under the terms of the GNU General Public License as
++ * published by the Free Software Foundation; either version 2 of the
++ * License, or (at your option) any later version.
++ *
++ * This library is distributed in the hope that it will be useful,
++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++ * GNU General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public
++ * License along with this library; if not, write to the Free
++ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
++ * MA 02110-1301 USA
++ *
++ * Or, alternatively,
++ *
++ *  b) Permission is hereby granted, free of charge, to any person
++ * obtaining a copy of this software and associated documentation
++ * files (the Software), to deal in the Software without
++ * restriction, including without limitation the rights to use,
++ * copy, modify, merge, publish, distribute, sublicense, and/or
++ * sell copies of the Software, and to permit persons to whom the
++ * Software is furnished to do so, subject to the following
++ * conditions:
++ *
++ * The above copyright notice and this permission notice shall be
++ * included in all copies or substantial portions of the Software.
++ *
++ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
++ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
++ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
++ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
++ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
++ * 

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Karsten Merker]

On Tue, Sep 23, 2014 at 11:42:08PM +0200, Michael Prokop wrote:
 * Karsten Merker [Tue Sep 23, 2014 at 11:22:32PM +0200]:

  Please always include ohci-platform, ehci-platform and
  phy-sun4i-usb into the initramfs if they are provided by the
  kernel for which the initramfs is built.
 
 Does this look like it would provide what you're asking for?
 http://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/?h=mika/bug_762634id=3b835665015c0a9287284c2548b12ab7c8cabc78

Hello,

outside d-i and for the MODULES=most configuration, this works
fine:

$ grep MODULES /etc/initramfs-tools/initramfs.conf
# MODULES: [ most | netboot | dep | list ]
MODULES=most
$ sudo update-initramfs -u -k 3.16-2-armmp-lpae
update-initramfs: Generating /boot/initrd.img-3.16-2-armmp-lpae
Installing sun7i-a20-cubietruck.dtb 3.16-2-armmp-lpae into /boot
Installing sun7i-a20-cubietruck.dtb 3.16-2-armmp-lpae into /boot
flash-kernel: installing version 3.16-2-armmp-lpae
Generating boot script u-boot image... done.
Taking backup of boot.scr.
Installing new boot.scr.
$ lsinitramfs /boot/initrd.img-3.16-2-armmp-lpae |grep -e hci-platform -e 
phy-sun4i-usb
lib/modules/3.16-2-armmp-lpae/kernel/drivers/phy/phy-sun4i-usb.ko
lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host/ohci-platform.ko
lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host/ehci-platform.ko

Inside the /target chroot created by d-i, update-initramfs is by default
configured to run with MODULES=dep and gives only the following
modules on my armhf/sunxi test system:

lib/modules/3.16-2-armmp-lpae/kernel/drivers
lib/modules/3.16-2-armmp-lpae/kernel/drivers/scsi
lib/modules/3.16-2-armmp-lpae/kernel/drivers/scsi/scsi_mod.ko
lib/modules/3.16-2-armmp-lpae/kernel/drivers/scsi/sd_mod.ko
lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb
lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host
lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host/ehci-hcd.ko
lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host/ehci-platform.ko
lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/storage
lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/storage/usb-storage.ko
lib/modules/3.16-2-armmp-lpae/kernel/drivers/md
lib/modules/3.16-2-armmp-lpae/kernel/drivers/md/dm-mod.ko
lib/modules/3.16-2-armmp-lpae/kernel/lib
lib/modules/3.16-2-armmp-lpae/kernel/lib/crc16.ko
lib/modules/3.16-2-armmp-lpae/kernel/lib/crc-t10dif.ko
lib/modules/3.16-2-armmp-lpae/kernel/fs
lib/modules/3.16-2-armmp-lpae/kernel/fs/mbcache.ko
lib/modules/3.16-2-armmp-lpae/kernel/fs/ext4
lib/modules/3.16-2-armmp-lpae/kernel/fs/ext4/ext4.ko
lib/modules/3.16-2-armmp-lpae/kernel/fs/jbd2
lib/modules/3.16-2-armmp-lpae/kernel/fs/jbd2/jbd2.ko
lib/modules/3.16-2-armmp-lpae/kernel/crypto
lib/modules/3.16-2-armmp-lpae/kernel/crypto/crct10dif_generic.ko
lib/modules/3.16-2-armmp-lpae/kernel/crypto/crct10dif_common.ko

The phy-sun4i-usb module is missing there, although it is loaded
by the running kernel:

# lsmod  |grep phy_sun4i_usb
phy_sun4i_usb   4260  4

Without phy_sun4i_usb, USB support does not work at all on this
platform, so this module would always have to be included.

The missing ohci-hcd and ohci-platform modules would be explained
by the fact that this particular device technically has both EHCI
and OHCI controllers, but the platform-dependent OHCI glue code
is not yet implemented in the kernel, so the OHCI part is
currently invisible to the kernel.


When manually running update-initramfs with MODULES=most inside
the d-i /target chroot, all three modules (ohci-platform,
ehci-platform and phy-sun4i-usb) are there, but by default the
user is not presented with a choice regarding MODULES=dep vs. 
MODULES=most in d-i.  The relevant debconf prompt is only
presented at debconf priority medium, i.e. when running d-i in
expert mode, so I would appreciate very much if you could
include the missing phy-sun4i-usb module also when building the
initramfs with MODULES=dep.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Karsten Merker]

On Thu, Sep 25, 2014 at 01:31:16PM +0200, Michael Prokop wrote:
 * Cyril Brulebois [Thu Sep 25, 2014 at 12:32:22PM +0200]:
  Michael Prokop m...@debian.org (2014-09-25):
   * Karsten Merker [Thu Sep 25, 2014 at 08:15:48AM +0200]:
 
Inside the /target chroot created by d-i, update-initramfs is by default
configured to run with MODULES=dep and gives only the following
modules on my armhf/sunxi test system:
 
   Hmpf, I so much am not a fan of this default MODULES=dep behaviour
   of d-i...
 
  Can you please clarify? I see this in base-installer:
  | if db_get base-installer/initramfs-tools/driver-policy  
  \
  |[ -z $RET ]; then
  | # Get default for architecture

[snip] 

  Granted, no coffee yet. But I seem to recall that people having issues
  with MODULES=dep are those who actually selected it manually (e.g.
  through expert install).
 
 I'm just not a friend of MODULES=dep as a default behaviour, good
 to know that d-i uses a sane default here. :) Thanks for verifying!
 
  My local test confirms that a basic installation (netboot-gtk image on
  amd64 using udebs from sid) leads to MODULES=most in /target. I didn't
  go further than the popcon prompt though.

Hello,

I have just run another test on armhf with today's daily d-i
build (dated 25-Sep-2014 05:17) and default debconf priority
(at which no debconf prompt regarding initramfs-tools gets
displayed). This results in:

  ~ # cat /target/etc/initramfs-tools/conf.d/driver-policy
  # Driver inclusion policy selected during installation
  # Note: this setting overrides the value set in the file
  # /etc/initramfs-tools/initramfs.conf
  MODULES=dep

and the short module list in the initramfs confirms that it was
really built with MODULES=dep. The comment marked above suggests
that this is an architecture-dependent default, so we could
possibly both be right ;-). If yes, we will have to find a
solution regarding the inclusion of the phy-sun4i-usb module
when building the initramfs with MODULES=dep, though.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Karsten Merker]

On Thu, Sep 25, 2014 at 09:21:57AM +0200, Michael Prokop wrote:

 Is there a /sys/... entry which would make it obvious for i-t that
 phy-sun4i-usb exists/should be loaded?

Sorry, I do not know that. A possible approach could be parsing
some of the information in /proc/device-tree, as the module
initialization is triggered by the existence of certain
compatible properties in the device-tree.

From drivers/phy/phy-sun4i-usb.c in the kernel sources:

  static const struct of_device_id sun4i_usb_phy_of_match[] = {
  { .compatible = allwinner,sun4i-a10-usb-phy },
  { .compatible = allwinner,sun5i-a13-usb-phy },
  { .compatible = allwinner,sun6i-a31-usb-phy },
  { .compatible = allwinner,sun7i-a20-usb-phy },
  { },
  };
  MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);

Something like grepping for the compatible strings in the result of
a find /proc/device-tree/ -iname compatible might work, but
I have not actually tested that yet.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762634: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Karsten Merker]

Package: initramfs-tools
Version: 0.116

Hello,

running Debian with the root filesystem on a USB mass storage
device (such as a USB harddisk) requires that the driver modules
for the USB host controllers of the system are available in the
initramfs.  If they are missing, the root filesystem cannot be
mounted, which currently happens on a number of armhf systems.

On i386/amd64, the OHCI/EHCI host controllers are PCI devices
which are supported by the ohci-pci and ehci-pci modules.  On
many armhf systems the USB host controllers are
OHCI/EHCI-compatible, but implemented as a platform device, so
they are not supported by ohci-pci and ehci-pci.  Instead these
systems need the following platform device driver modules:

- ohci-platform
- ehci-platform

and in the case of armhf/sunxi-based systems an additional
USB phy driver module:

- phy-sun4i-usb

These modules are not included in the initramfs built by
initramfs-tools (even if MODULES=most is set in initramfs.conf),
which makes it impossible to boot with the rootfs on a USB disk
on such systems.

Please always include ohci-platform, ehci-platform and
phy-sun4i-usb into the initramfs if they are provided by the
kernel for which the initramfs is built.

Regards,
Karsten 
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762253: Tasksel 3.25: fails due to wrong apt invocation (missing -o in front of additional apt option)

[Karsten Merker]

Package: tasksel
Version: 3.25
Severity: grave
Justification: breaks d-i

Hello,

the upload of tasksel 3.25 has broken tasksel in d-i:

Sep 20 06:04:28 pkgsel: starting tasksel
Sep 20 06:04:56 in-target: E
Sep 20 06:04:56 in-target: :
Sep 20 06:04:56 in-target: Invalid operation APT::Acquire::Retries=3
Sep 20 06:04:56 in-target:
Sep 20 06:04:56 in-target: tasksel: apt-get failed (100)
Sep 20 06:04:57 main-menu[190]: WARNING **: Configuring 'pkgsel' failed with 
error code 1
Sep 20 06:04:57 main-menu[190]: WARNING **: Menu item 'pkgsel' failed.

This is caused by the following commit:

http://anonscm.debian.org/cgit/tasksel/tasksel.git/commit/?id=645455083756a71f1843c3deebdb73bc6324c66a

where a -o is missing before the added APT::Acquire::Retries=3.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762219: linux 3.16.3-1 FTBS for the armel kirkwood flavor due to size limit

[Karsten Merker]

source: linux
version: 3.16.3-1

[CCing debian-arm@lists.d.o]

Hello,

according to 

https://buildd.debian.org/status/fetch.php?pkg=linuxarch=armelver=3.16.3-1stamp=1411133746

linux 3.16.3-1 FTBFS for the armel kirkwood flavor due to the
resulting image being too big for the platform by 648 bytes, so the
kernel configuration for this platform will probably have to be trimmed
down:

make[3]: Leaving directory 
'/«PKGBUILDDIR»/debian/build/build_armel_none_kirkwood'
python debian/bin/buildcheck.py debian/build/build_armel_none_kirkwood armel 
none kirkwood
Can't read ABI reference.  ABI not checked!  Continuing.
Image too large (2097728  2097080)!  Refusing to continue.
make[2]: *** [debian/stamps/build_armel_none_kirkwood_plain] Error 1
debian/rules.real:158: recipe for target 
'debian/stamps/build_armel_none_kirkwood_plain' failed

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762221: linux 3.16.3-1 FTFBS for s390x with undefined reference to compat_sys_ni_syscall

[Karsten Merker]

source: linux
version: 3.16.3-1

[CCing debian-s390@lists.d.o]

According to

https://buildd.debian.org/status/fetch.php?pkg=linuxarch=s390xver=3.16.3-1stamp=1411128376

linux 3.16.3-1 FTBFS on s390x with the following error:

  LINKvmlinux
  LD  vmlinux.o
  MODPOST vmlinux.o
  GEN .version
  CHK include/generated/compile.h
  UPD include/generated/compile.h
  CC  init/version.o
  LD  init/built-in.o
arch/s390/built-in.o: In function `sys_call_table_emu':
(.rodata+0x2bbc): undefined reference to `compat_sys_ni_syscall'
arch/s390/built-in.o: In function `sys_call_table_emu':
(.rodata+0x2bc0): undefined reference to `compat_sys_ni_syscall'
make[5]: *** [vmlinux] Error 1
/«PKGBUILDDIR»/Makefile:891: recipe for target 'vmlinux' failed
make[4]: *** [sub-make] Error 2

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761591: linux 3.16.2-3: missing usb platform modules in udeb

[Karsten Merker]

On Sun, Sep 14, 2014 at 10:31:56PM +0200, Karsten Merker wrote:

 the usb-modules udeb built by the linux 3.16.2-3 package does not
 contain the usb platform driver modules ehci-platform and
 ohci-platform.
 
 Systems that have EHCI- or OHCI-compatible USB host controllers
 which are not implemented as PCI devices, but as platform
 devices, need these modules to provide the necessary glue to make
 ehci-hcd and ohci-hcd work.  Without them, there is no USB
 support in the Debian-installer on e.g. all sunxi-based devices.
 
 Attached is a small patch that should add the necessary modules
 to the udeb (test build still running).

The test build has completed in the meantime and I have locally
built a debian-installer based on it.  Unfortunately my original
patch has not been sufficient - besides the (ehci|ohci)-platform
modules, on sunxi-based devices an additional phy driver 
(phy-sun4i-usb) appears to be required.

Follwing is a new version of my original patch - a test build
is running but due to the build host being rather slow, I
probably won't be able to actually test it in d-i before tomorrow
evening.

Index: debian/installer/modules/usb-modules
===
--- debian/installer/modules/usb-modules(Revision 21845)
+++ debian/installer/modules/usb-modules(Arbeitskopie)
@@ -1,7 +1,10 @@
 ehci-hcd ?
 ehci-pci ?
+ehci-platform ?
 ohci-hcd ?
 ohci-pci ?
+ohci-platform ?
 uhci-hcd ?
 xhci-hcd ?
 usbcore ?
+phy-sun4i-usb ?

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761514: [armhf/sunxi] [d-i daily 20140914] Cubietruck installation report (installation to MMC)

[Karsten Merker]

Package: installation-reports

Boot method:   netboot
Image version: http://d-i.debian.org/daily-images/armhf/daily/netboot/
   dated 2014-09-14 05:17
Install Date:  2014-09-14

Machine:   Cubietech Cubietruck
Processor: Allwinner A20 (2x Cortex A7)
Memory:2GB
U-boot:u-boot 2014.10~rc2+dfsg1-1 from experimental
Console:   serial console

Partitions (SD card):
/dev/mmcblk0p1 ext2240972  10175218356   5% /boot
/dev/mmcblk0p2 ext4  14136820 802108  12593544   6% /

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]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments:
- The installation was done in expert mode (debconf priority medium).
- I selected Sid instead of Jessie as target suite as kernel 3.16
  (required for installation on MMC) has not yet migrated to Jessie.
- Partitioning was done using the guided partitioning option.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761514: [armhf/sunxi] [d-i daily 20140914] Cubietruck installation report (installation to MMC)

[Karsten Merker]

On Sun, Sep 14, 2014 at 05:25:57PM +0200, Cyril Brulebois wrote:
 Karsten Merker mer...@debian.org (2014-09-14):
  U-boot:u-boot 2014.10~rc2+dfsg1-1 from experimental
 
 [...]
 
  Comments:
  - The installation was done in expert mode (debconf priority medium).
  - I selected Sid instead of Jessie as target suite as kernel 3.16
(required for installation on MMC) has not yet migrated to Jessie.
  - Partitioning was done using the guided partitioning option.
 
 I see you also need u-boot from experimental; I'm not sure it'll reach
 sid + testing in time for the next release. Are you in touch with its
 maintainer/do you his short term plans?

[CCing Vagrant Cascadian (Debian u-boot package maintainer)
 and Ian Campbell (mainline u-boot sunxi platform custodian)]

U-Boot v2014.10 is scheduled to be released on Oct 13, 2014. 
Vagrant is tracking the rc releases in experimental and the plan
is to get the final u-boot v2014.10 into unstable as soon as it
is released. That is a tight schedule, but I think it is
feasible.

The mainline u-boot version currently in jessie (2014.07+dfsg1-1)
has only very limited sunxi platform support.  It works on the
Cubietruck, but does not support several other sunxi-based
systems for which we have support in d-i, so we are very
strongly interested in getting v2014.10 into Jessie.


D-i can also work with older u-boot-sunxi versions that are
supplied by some board vendors (flash-kernel takes explicit care
in the boot scripts it creates to handle this properly), but
those older versions do not have the full featureset that
mainline u-boot v2014.10 provides. The two major features
missing in the vendor-supplied versions are

- PSCI support, without which there is no SMP, i.e. the kernel
  can only initalize the first CPU core

- AHCI support, i.e. booting from SATA harddisk is not possible.

So using old u-boot-sunxi versions instead of current mainline
is technically possible, but from a user point of view really
undesireable.
 
Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751704: libparted ped_disk_clobber() overwrites firmware on some arm systems

[Karsten Merker]

Control: tags -1 pending
thanks

On Thu, Aug 28, 2014 at 10:31:43PM +0200, Karsten Merker wrote:

 as libparted upstream has now confirmed that modifying
 PedDisk.needs_clobber from within the calling application is
 ok, I would like to apply the following patch to partman-base
 unless somebody has further objections against it.
 
 Functionally it is the same patch that I had posted earlier
 already, just with some coding style cleanups.

The patch has been committed to the partman-base git repository.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751704: libparted ped_disk_clobber() overwrites firmware on some arm systems

[Karsten Merker]

Hello,

as libparted upstream has now confirmed that modifying
PedDisk.needs_clobber from within the calling application is
ok, I would like to apply the following patch to partman-base
unless somebody has further objections against it.

Functionally it is the same patch that I had posted earlier
already, just with some coding style cleanups.

Regards,
Karsten

From bd3e4f79ea620fefb48c768dec22a3f7d1ad31a2 Mon Sep 17 00:00:00 2001
From: Karsten Merker mer...@debian.org
Date: Thu, 28 Aug 2014 20:38:12 +0200
Subject: [PATCH] Take care of the firmware area on sunxi-based systems

By default partman calls ped_disk_clobber when writing a new
partition table, but on the MMC device of sunxi-based systems this
would overwrite the firmware area, resulting in an unbootable system
(see bug #751704). Handle this as a special case in command_commit().
---
 parted_server.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/parted_server.c b/parted_server.c
index 55cf151..a6283f6 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -1330,6 +1330,25 @@ command_dump()
 oprintf(OK\n);
 }
 
+/* Check whether we are running on a sunxi-based system. */
+int
+is_sunxi_system()
+{
+int cpuinfo_handle;
+int result = 0;
+char buf[4096];
+int length;
+
+if ((cpuinfo_handle = open(/proc/cpuinfo, O_RDONLY)) != -1) {
+length = read(cpuinfo_handle, buf, sizeof(buf)-1);
+buf[length]='\0';
+if (strstr(buf, Allwinner) != NULL)
+result = 1;
+close(cpuinfo_handle);
+}
+return result;
+}
+
 void
 command_commit()
 {
@@ -1337,6 +1356,20 @@ command_commit()
 if (dev == NULL)
 critical_error(The device %s is not opened., device_name);
 log(command_commit());
+
+/* The boot device on sunxi-based systems needs special handling.
+ * By default partman calls ped_disk_clobber when writing the
+ * partition table, but on sunxi-based systems this would overwrite
+ * the firmware area, resulting in an unbootable system (see
+ * bug #751704).
+ */
+if (is_sunxi_system()  !strcmp(disk-dev-path, /dev/mmcblk0)) {
+disk-needs_clobber = 0;
+log(Sunxi platform detected. Disabling ped_disk_clobber  \
+for the boot device %s to protect the firmware  \
+area., disk-dev-path);
+}
+
 open_out();
 if (disk != NULL  named_is_changed(device_name))
 ped_disk_commit(disk);
-- 
2.1.0


-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751704: libparted ped_disk_clobber() overwrites firmware on some arm systems

[Karsten Merker]

Hello,

the following is a discussion from the Debian bugtracking system regarding
Debian Bug#751704 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704).
It needs involvement from parted upstream, therefore I am forwarding it to 
bug-par...@gnu.org.

Kind regards,
Karsten

- Forwarded message from Jim Meyering j...@meyering.net -

Date: Sun, 17 Aug 2014 14:51:41 -0700
From: Jim Meyering j...@meyering.net
Subject: Bug#751704: libparted questions (was: Bug#751704: partman-base 173: 
partman overwrites
parts of u-boot)

On Wed, Aug 13, 2014 at 12:07 PM, Karsten Merker mer...@debian.org wrote:
 [CCing Otavio Salvador and Jim Meyering; the following is a short summary
  of the situation; the full history can be read in bug #751704:

  Debian-Installer uses partman for partitioning, which in turn is
  based on libparted. On sunxi-based systems, upon writing the partition
  table, partman/libparted overwrites parts of u-boot which are
  located between the end of the partition table and the beginning of the
  first partition which results in an unbootable system.
  An attempt to solve this problem has been to conditionally set
  PedDisk.needs_clobber to 0 in partman when it detects that it is
  trying to write to a boot device on sunxi-based systems.]

 Colin Watson cjwat...@debian.org wrote:
 PedDisk.needs_clobber is marked as office use only in parted; I
 interpret that as meaning that it really shouldn't be fiddled with
 outside parted, even though it's technically exposed.  Could you please
 look at fixing parted to avoid clobbering the firmware area instead?  I
 think that would be more correct.

 I have no idea what is really meant with the comment

   /* office use only ;-) */
   int needs_clobber;

 in /usr/include/parted/disk.h, so I would like to ask upstream
 for clarification. Otavio, Jim: you are listed as parted
 upstream maintainers on http://www.gnu.org/software/parted/ - could
 you shed some light on this? Is it ok for an application to fiddle
 with the needs_clobber element or is this to be considered
 strictly libparted-internal?


 @Colin: If the solution is to be completely encapsulated in
 libparted, I see a large problem in how to solve the conflict between
 space after the partition table being very differently used by
 firmware for different SoCs on one side, and libparted trying to make
 sure that there are no remains of other partition table formats in
 the respective area on the other side - at least with the
 prerequisite of keeping both the current defaults (clobbering) as
 well as keeping the libparted API unchanged.  With the current there
 is one erase size for all platforms method in ped_disk_clobber() in
 libparted/disk.c, we inevitably end up with conflicting requirements.
 An example: the source for ped_disk_clobber() states:

 /* How many sectors to zero out at each end.
This must be large enough to zero out the magic bytes
starting at offset 8KiB on a DASD partition table.
Doing the same from the end of the disk is probably
overkill, but at least on GPT, we do need to zero out
the final sector.  */

 So for at least one platform (according to Wikipedia DASD seems to be
 some s/390 format), the area at offset 8KiB has to be wiped out while
 for another (armhf/sunxi) it may not be wiped out as the u-boot SPL is
 located there and cannot be relocated because its sector address is
 hardcoded in the SoC.

 According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#25,
 similar problems (but at other offsets) come up for other SoCs.
 According to the examples listed there, for TI SoCs libparted would
 have to stop clobbering the GPT header after writing a DOS MBR, but
 could wipe the DASD area.  For a Freescale i.MX SoC libparted could
 legally clobber the GPT header, but would have to refrain from
 clobbering the areas behind it.  If you extrapolate this to the large
 number of different SoC families, to handle this completely inside
 libparted, the library would have to know what exactly is the target
 system for which it writes a partition table and special-case the
 handling for each of them.  While one might assume that the partition
 table is for an s/390 system when a DASD partition table is
 generated, this does not work as easily for the plethora of different
 architectures and systems that use DOS MBR partition tables.  This
 gets even more complicated by the fact that libparted may run on one
 platform but modify partition tables for another platform, such as
 when operating on disk images for use with emulators or when
 operating on hd-media images for different arm platforms (with
 different firmware/bootloader requirements) on one autobuild host, so
 trying to do runtime detection of the host system would still not cover
 all use cases. In the case of creating images from scratch, the problem
 can be circumvented by (re-)writing

Bug#751704: bug#18289: libparted ped_disk_clobber() overwrites firmware on some arm systems

[Karsten Merker]

On Mon, Aug 18, 2014 at 09:59:49AM -0700, Brian C. Lane wrote:
 On Mon, Aug 18, 2014 at 08:19:17AM +0200, Karsten Merker wrote:
  Hello,
  
  the following is a discussion from the Debian bugtracking system regarding
  Debian Bug#751704 
  (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704).
  It needs involvement from parted upstream, therefore I am forwarding it to 
  bug-par...@gnu.org.
 
 Thanks for forwarding this. parted should only be clobbering these extra
 sectors when a new disklabel is applied (eg. mklabel in the ui) which, I
 think, is the appropriate thing to do.
 
 If you are operating on an existing disklabel and want to preserver a
 boot loader in the space before the 1st partition you shouldn't be
 calling ped_disk_new_fresh(). If you are creating a new disklabel then
 any boot loader code should be installed after partitioning.
 
 I don't think parted needs any changes.

Hello,

thanks for your swift reply. I fully understand your position,
but unfortunately things on arm are fundamentally different from
the PC world.  U-Boot is more of a BIOS than a bootloader like
GRUB; it is highly board specific and handles low-level stuff
such as setting the IO pinmuxing for the specific board and
configuring the DRAM controller.  Without it, the board is
completely dead from a user perspective.

On a PC, the BIOS is always available in ROM/Flash even when all
disk devices have been wiped and the user can still select some
other device (such as the network, a CDROM drive or a USB memory
stick) to boot from.  On the arm systems we are talking about,
there is no ROM BIOS and the u-boot image on the SD card (or on
an eMMC chip) is the only way to interact with the system at all. 
The usual case is that the u-boot image is written raw onto the
storage medium, i.e. there is no partition table or filesystem
on it by default, so we need to create a new disklabel in the
installer.

You are fully right that normally a bootloader should be
installed after partitioning.  This works well for the case of a
bootloader that uses universally available BIOS functions and is
not hardware-specific, such as is the case on PCs.  In the case
of u-boot on the other hand, in PC-lingo we would have to provide
the installer with the ability to flash the BIOS for every PC
model on the market as part of the operating system installation,
which is not feasible.  We might be able to do that for a small
selection of devices, but not for all of them -- we need to keep
the u-boot image that is on the device even when creating a new
disklabel, but we are unsure what is the best way to handle this.

The approach in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#60
(setting PedDisk.needs_clobber to 0 before calling ped_disk_commit
for specific devices) works in practice, but the question was
whether it is ok for the calling application to fiddle around with
the needs_clobber flag, or whether we should take some other
approach.

Kind Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751704: libparted questions (was: Bug#751704: partman-base 173: partman overwrites parts of u-boot)

[Karsten Merker]

[CCing Otavio Salvador and Jim Meyering; the following is a short summary
 of the situation; the full history can be read in bug #751704:

 Debian-Installer uses partman for partitioning, which in turn is
 based on libparted. On sunxi-based systems, upon writing the partition
 table, partman/libparted overwrites parts of u-boot which are
 located between the end of the partition table and the beginning of the
 first partition which results in an unbootable system.
 An attempt to solve this problem has been to conditionally set
 PedDisk.needs_clobber to 0 in partman when it detects that it is
 trying to write to a boot device on sunxi-based systems.]

Colin Watson cjwat...@debian.org wrote:
 PedDisk.needs_clobber is marked as office use only in parted; I
 interpret that as meaning that it really shouldn't be fiddled with
 outside parted, even though it's technically exposed.  Could you please
 look at fixing parted to avoid clobbering the firmware area instead?  I
 think that would be more correct.

I have no idea what is really meant with the comment 

  /* office use only ;-) */
  int needs_clobber;

in /usr/include/parted/disk.h, so I would like to ask upstream
for clarification. Otavio, Jim: you are listed as parted
upstream maintainers on http://www.gnu.org/software/parted/ - could
you shed some light on this? Is it ok for an application to fiddle
with the needs_clobber element or is this to be considered
strictly libparted-internal?


@Colin: If the solution is to be completely encapsulated in
libparted, I see a large problem in how to solve the conflict between
space after the partition table being very differently used by
firmware for different SoCs on one side, and libparted trying to make
sure that there are no remains of other partition table formats in
the respective area on the other side - at least with the
prerequisite of keeping both the current defaults (clobbering) as
well as keeping the libparted API unchanged.  With the current there
is one erase size for all platforms method in ped_disk_clobber() in
libparted/disk.c, we inevitably end up with conflicting requirements. 
An example: the source for ped_disk_clobber() states:

/* How many sectors to zero out at each end.
   This must be large enough to zero out the magic bytes
   starting at offset 8KiB on a DASD partition table.
   Doing the same from the end of the disk is probably
   overkill, but at least on GPT, we do need to zero out
   the final sector.  */

So for at least one platform (according to Wikipedia DASD seems to be
some s/390 format), the area at offset 8KiB has to be wiped out while
for another (armhf/sunxi) it may not be wiped out as the u-boot SPL is
located there and cannot be relocated because its sector address is
hardcoded in the SoC.

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#25,
similar problems (but at other offsets) come up for other SoCs. 
According to the examples listed there, for TI SoCs libparted would
have to stop clobbering the GPT header after writing a DOS MBR, but
could wipe the DASD area.  For a Freescale i.MX SoC libparted could
legally clobber the GPT header, but would have to refrain from
clobbering the areas behind it.  If you extrapolate this to the large
number of different SoC families, to handle this completely inside
libparted, the library would have to know what exactly is the target
system for which it writes a partition table and special-case the
handling for each of them.  While one might assume that the partition
table is for an s/390 system when a DASD partition table is
generated, this does not work as easily for the plethora of different
architectures and systems that use DOS MBR partition tables.  This
gets even more complicated by the fact that libparted may run on one
platform but modify partition tables for another platform, such as
when operating on disk images for use with emulators or when
operating on hd-media images for different arm platforms (with
different firmware/bootloader requirements) on one autobuild host, so
trying to do runtime detection of the host system would still not cover
all use cases. In the case of creating images from scratch, the problem
can be circumvented by (re-)writing the bootloader at the end of the
process, but when the task is to modify existing images with unknown
content, this workaround is not available.

As a conclusion, I think that the decision whether to clobber the
area between the partition table and the beginning of the first
partition has to be taken by the calling application and not
internally by the library.

Kind Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? 

Bug#751704: partman-base 173: partman overwrites parts of u-boot

[Karsten Merker]

Control: tag -1 patch

On Wed, Jun 18, 2014 at 09:44:12PM +0200, Karsten Merker wrote:

[On sunxi-based systems, upon writing the partition table, partman
 overwrites parts of u-boot which are located between the end of
 the partition table and the beginning of the first partition.]

Hello,

the following patch solves the issue for me. I have run a
successful jessie installation on a Cubietruck with this patch
applied to a locally built d-i based on kernel 3.16 from
experimental.

If there are no objections, I would like apply it to the
partman-base git repository.

Regards,
Karsten

From 35d41e3bfce60fd08c4da6dc0696a479c78bdcdd Mon Sep 17 00:00:00 2001
From: Karsten Merker mer...@debian.org
Date: Tue, 12 Aug 2014 23:10:13 +0200
Subject: [PATCH] Take care of the firmware area on sunxi-based systems

By default partman calls ped_disk_clobber when writing the
partition table, but on sunxi-based systems this would overwrite
the firmware area, resulting in an unbootable system (see
bug #751704). Handle this as a special case in command_commit().
---
 parted_server.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/parted_server.c b/parted_server.c
index 55cf151..bc4523a 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -1330,6 +1330,25 @@ command_dump()
 oprintf(OK\n);
 }
 
+/* Check whether we are running on a sunxi-based system. */
+int
+is_sunxi_system()
+{
+int cpuinfo_handle;
+int result=0;
+char buf[4096];
+int length;
+
+if ((cpuinfo_handle = open(/proc/cpuinfo, O_RDONLY)) != -1  ) {
+length = read(cpuinfo_handle, buf, sizeof(buf)-1);
+buf[length]='\0';
+if (strstr(buf,Allwinner)!=NULL)
+result=1;
+close(cpuinfo_handle);
+}
+return result;
+}
+
 void
 command_commit()
 {
@@ -1337,6 +1356,21 @@ command_commit()
 if (dev == NULL)
 critical_error(The device %s is not opened., device_name);
 log(command_commit());
+
+/*
+ * The boot device on sunxi-based systems needs special handling.
+ * By default partman calls ped_disk_clobber when writing the
+ * partition table, but on sunxi-based systems this would overwrite
+ * the firmware area, resulting in an unbootable system (see
+ * bug #751704).
+ */
+if (is_sunxi_system()  !strcmp(disk-dev-path, /dev/mmcblk0)) {
+disk-needs_clobber=0;
+log(Sunxi platform detected. Disabling ped_disk_clobber  \
+for the boot device %s to protect the firmware  \
+area., disk-dev-path);
+}
+
 open_out();
 if (disk != NULL  named_is_changed(device_name))
 ped_disk_commit(disk);
-- 
2.1.0.rc1


-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751704: partman-base 173: partman overwrites parts of u-boot

[Karsten Merker]

Source: partman-base
Version: 173
Severity: important

Upon testing a locally built debian-installer based on linux
3.15-1 (from experimental) on an Allwinner sunXi-based armhf
system, I have found that the system does not boot anymore after
partman has written a new partition table to the SD card from
which the system loads u-boot.

Kernel 3.15-1 is the first kernel in Debian that contains an
MMC/SD driver for this platform, i.e. with older versions
partitions could only be created on an attached SATA disk but not
on the SD card, so this problem has not shown up earlier.

In my first attempt, the partition table has been created by the
guided partitioning option in d-i, which has created the
following layout:

Disk /dev/sdd: 15 GB, 15718510080 bytes
255 heads, 63 sectors/track, 1911 cylinders, total 30700215 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot  Start End  Blocks   Id  System 
/dev/sdd1   *2048  499711  257008   83  Linux
Warning: Partition 1 does not end on cylinder boundary.   
/dev/sdd2  4997122930687914402272   83  Linux
Warning: Partition 2 does not end on cylinder boundary.   
/dev/sdd32930892630701567  6988275  Extended
Warning: Partition 3 does not end on cylinder boundary.   
/dev/sdd52930892830701567  698827   82  Linux swap
Warning: Partition 5 does not end on cylinder boundary.   

The layout itself appears ok as the first partition starts at
sector 2048, i.e. at 1MB offset, but comparing the state of the
first MB of data on the device before and after partman has
written the partition table shows that not only the partition
table has been written, but also the area from offset 0x2000 up
to 0x25ff has been zeroed out.  On all Allwinner sunXi-based
systems this area contains the u-boot SPL, without which the
system cannot boot anymore.

A second attempt with manual partitioning showed the same
behaviour, i.e. it appears to be a general partman problem and
not specific to partman-auto.

Partman should only write the partition table but should not
touch the area between the partition table and the beginning
of the first partition as this area is used by bootloaders.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751012: [flash-kernel] Flash-kernel should fail with exit 0 under debrootstrap

[Karsten Merker]

On Mon, Jun 09, 2014 at 05:54:35PM +0200, Bastien ROUCARIES wrote:
 On Mon, Jun 9, 2014 at 5:21 PM, Karsten Merker mer...@debian.org wrote:
  On Mon, Jun 09, 2014 at 03:48:11PM +, bastien ROUCARIES wrote:
 
  Package: flash-kernel
  Severity: important
 
  Flash-kernel should detect it run under debrootstrap and fail gracefully/
 
  Install message:
 
  Processing triggers for libc-bin (2.18-7) ...
  Processing triggers for initramfs-tools (0.115) ...
  update-initramfs: Generating /boot/initrd.img-3.14-1-kirkwood
  /bin/df: Warning: cannot read table of mounted file systems: No such file 
  or directory
  warning: failed to read mtab
  ^Cdpkg: error processing package initramfs-tools (--configure):
   subprocess installed post-installation script was interrupted
  Errors were encountered while processing:
   initramfs-tools
  E: Sub-process /usr/bin/dpkg returned an error code (1)
 
  Hello,
 
  I am trying to understand which problem exactly you have
  encountered, but I am a bit confused: you have filed a bug
  against flash-kernel but in the log you have provided, it is not
  flash-kernel that shows an error message, but initramfs-tools.  I
  also cannot see in which context that has happened and how it
  relates to debootstrap - by default debootstrap does neither
  install a kernel image nor flash-kernel.  From your log, it looks
  like you have manually interrupted the update-initramfs process,
  resulting in the error message above:
 
 No I have not interupted.
 
 I have installed te kirkwood kernel and flash-kernel on my chroot.

Hello,

I unfortunately cannot yet reproduce your problem. Due to the
kernel version (3.14-1) I assume that you are debootstrapping
jessie or sid.  I have just debootstrapped a sid/armel chroot
that included flash-kernel and linux-image-3.14-1-kirkwood on
a sid/armhf system without problems:

# debootstrap --arch=armel --include=flash-kernel,linux-image-kirkwood sid 
armel-sid-chroot http://ftp.de.debian.org/debian
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553)
[...]
I: Configuring linux-image-3.14-1-kirkwood...
I: Configuring flash-kernel...
I: Configuring libgnutls-openssl27:armel...
I: Configuring wget...
I: Configuring libcwidget3:armel...
I: Configuring aptitude...
I: Configuring linux-image-kirkwood...
I: Configuring iputils-ping...
I: Configuring tasksel...
I: Configuring tasksel-data...
I: Configuring perl-modules...
I: Configuring perl...
I: Configuring init-system-helpers...
I: Configuring cron...
I: Configuring rsyslog...
I: Configuring logrotate...
I: Configuring libc-bin...
I: Configuring initramfs-tools...
I: Base system installed successfully.
#

Just to be sure: On which kind of hardware (kirkwood or
non-kirkwood system) and in which Debian release (wheezy, jessie
or sid) are you running the debootstrap command and which release
are you bootstrapping with debootstrap (jessie or sid)?

Have you created your chroot like I did above, i.e. with the
--include parameter, or have you first run debootstrap without it
and later on manually installed linux-image-3.14-1-kirkwood and
flash-kernel in the already-created chroot?

Please provide a full log of the whole process starting with the
invocation of debootstrap up to the point where flash-kernel runs
but should not.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745972: Please enable additional kernel config options for sunxi support (starting with kernel 3.14)

[Karsten Merker]

Package: linux
Severity: wishlist

Hello,

I am working on getting ARM platforms based on the Allwinner A10
(sun4i) and A20 (sun7i) SOCs better supported in Debian.  During
the last months quite a bit of drivers for these SOCs have been
integrated into the mainline Linux kernel.  I would therefore like
to ask for the following additional kernel configuration options
to be enabled in future Debian kernel packages:

Kernel 3.14
===
CONFIG_RTC_DRV_SUNXI=m (sunxi realtime clock support)

CONFIG_USB_EHCI_HCD_PLATFORM=m (platform device for enabling the
embedded EHCI controller)

CONFIG_USB_OHCI_HCD_PLATFORM=m (platform device for enabling the
embedded OHCI controller)

CONFIG_SUNXI_WATCHDOG=m(embedded watchdog device)


Kernel 3.15 (drivers accepted in 3.15rc1)
===
CONFIG_PHY_SUN4I_USB=m (PHY driver for the embedded OHCI
and EHCI controllers)

CONFIG_SPI=y
CONFIG_SPI_SUNXI=m (sunxi SPI master driver)


Kernel 3.16 (driver submitted and currently in review)
===
CONFIG_MMC_SUNXI=m (sunxi MMC/SD controller driver)

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744365: lb config does not create config directory

[Karsten Merker]

Package: live-build
Version: 4.0~alpha33-1
Tags: patch

Hello,

running lb config from the current unstable live-build package
(4.0~alpha33-1, identical to current git as of commit
145418141e4965691dad1757c6fbdffa4a96290c) in an empty directory
results in

P: Creating config tree for a debian/wheezy/amd64 system
/usr/lib/live/build/config: 892: /usr/lib/live/build/config: cannot create 
config/common: Directory nonexistent

The code fragment responsible for this is:

884 if [ ! -e config ]
885 then
886 Echo_message Creating config tree for a 
${LB_MODE}/${LB_DISTRIBUTION}/${LIVE_IMAGE_ARCHITECTURE} system
887 else
888 Echo_message Updating config tree for a 
${LB_MODE}/${LB_DISTRIBUTION}/${LIVE_IMAGE_ARCHITECTURE} system
889 fi
890 
891 # Creating live-build configuration
892 cat  config/common  EOF

The if clause in line 884 checks for the existence of the config
directory, but does not create it when missing, so trying to
create config/common in line 892 fails when running lb config
without an existing config directory.  The following one-line
patch fixes that.


diff --git a/scripts/build/config b/scripts/build/config
index 5261c65..9430c5e 100755
--- a/scripts/build/config
+++ b/scripts/build/config
@@ -884,6 +884,7 @@ Check_defaults
 if [ ! -e config ]
 then
Echo_message Creating config tree for a 
${LB_MODE}/${LB_DISTRIBUTION}/${LIVE_IMAGE_ARCHITECTURE} system
+   mkdir -p config
 else
Echo_message Updating config tree for a 
${LB_MODE}/${LB_DISTRIBUTION}/${LIVE_IMAGE_ARCHITECTURE} system
 fi


Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735092: flash-kernel: add Raspberry Pi support

[Karsten Merker]

Package: flash-kernel
Version: 3.11
Severity: wishlist
Tags: patch

The attached patch adds Raspberry Pi support to flash-kernel.
It is based on current flash-kernel git (as of
7f52719ab0a607b89555baffd1cc8c14207c0f8f).

It is available for merging in the rpi-support-rebased branch at
http://anonscm.debian.org/gitweb/?p=users/merker/flash-kernel.git;a=shortlog;h=refs/heads/rpi-support-rebased

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
From ff2103a10fc27f77c2763d9dd4b043254b6e489d Mon Sep 17 00:00:00 2001
From: K. Merker mer...@debian.org
Date: Wed, 1 Jan 2014 13:17:13 +0100
Subject: [PATCH] Initial Raspberry Pi support

Add a method rpiconfigtxt and a new machine database entry for
the Raspberry Pi.  The method rpiconfigtxt enables flash-kernel
to update the kernel file name to be booted by the Raspberry Pi
firmware.

As the Raspberry Pi firmware can only boot from a FAT partition,
using symlinks to point to the kernel to be booted is not
possible.  Therefore the kernel filename entry in the firmware
config has to be changed after installation of a new kernel
package.
---
 README|   10 +-
 db/all.db |5 +
 functions |   19 +++
 test_db   |2 +-
 4 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 51aa15f..c7cde61 100644
--- a/README
+++ b/README
@@ -49,6 +49,7 @@ The following systems are supported:
  - QNAP TS-409
  - QNAP TS-410 and TS-410U Turbo NAS
  - QNAP TS-419P and TS-419U Turbo NAS
+ - Raspberry Pi
  - Seagate FreeAgent DockStar
  - SheevaPlug
  - SheevaPlug eSATA
@@ -153,12 +154,19 @@ The supported fields are:
 
 * Method: (optional) indicates how to support this particular machine;
   the default is generic; other available methods are: android, multi,
-  redboot, slug, symlink
+  redboot, slug, symlink, rpiconfigtxt
 
 * Boot-Device: (optional) block device to mount before installing
   kernel,  initrd and U-Boot script; Boot-Kernel-Path, Boot-Initrd-Path and
   Boot-Script-Path are then taken relative to this boot device
 
+* Rpi-ConfigTxt-Path: (optional) Raspberry Pi firmware configuration pathname.
+  The Raspberry Pi firmware configuration is stored in a text file on the
+  first (FAT formatted) partition of the SD card in the system and 
+  contains settings like kernel file name, video mode, memory split 
+  between CPU and GPU, overclocking parameters, etc. Rpi-ConfigTxt-Path
+  contains the full path to this file (default value: /boot/config.txt).
+
 
 Configuration
 - - - - - - -
diff --git a/db/all.db b/db/all.db
index c28432a..c0fdf27 100644
--- a/db/all.db
+++ b/db/all.db
@@ -382,3 +382,8 @@ Method: android
 Android-Boot-Device: /dev/mmcblk0
 Required-Packages: abootimg
 Bootloader-Sets-Root: no
+
+Machine: BCM2708
+Method: rpiconfigtxt
+Rpi-ConfigTxt-Path: /boot/config.txt
+Bootloader-Sets-Root: yes
diff --git a/functions b/functions
index 1233981..26a16ed 100644
--- a/functions
+++ b/functions
@@ -440,6 +440,7 @@ boot_script_path=$(get_machine_field $machine Boot-Script-Path) || :
 boot_dtb_path=$(get_machine_field $machine Boot-DTB-Path) || :
 boot_multi_path=$(get_machine_field $machine Boot-Multi-Path) || :
 android_boot_device=$(get_machine_field $machine Android-Boot-Device) || :
+rpi_configtxt_path=$(get_machine_field $machine Rpi-ConfigTxt-Path) || :
 
 if [ -n $dtb_append_from ]; then
 if dtb_append_required; then
@@ -711,6 +712,24 @@ case $method in
 		}  $imtd || error failed.
 		echo done. 2
 	;;
+	rpiconfigtxt)
+		rpi_configtxt_path=${rpi_configtxt_path:-/boot/config.txt}
+		rpi_configtxt_tempfile=$(tempfile)
+
+		if [ ! -e ${rpi_configtxt_path} ]; then
+			echo ${rpi_configtxt_path} not found. Creating it.
+			touch ${rpi_configtxt_path}
+		fi
+
+		grep -E -v ^#fk-old-  ${rpi_configtxt_path} | \
+		sed -e 's/^kernel=/#fk-old-kernel=/' \
+		-e 's/^initramfs/#fk-old-initramfs/' \
+		-e 's/^ramfsfile/#fk-old-ramfsfile/' \
+		-e 's/^ramfsaddr/#fk-old-ramfsaddr/'  ${rpi_configtxt_tempfile}
+
+		echo -n kernel=$(basename ${kfile})\ninitramfs $(basename ${ifile})\n  ${rpi_configtxt_tempfile}
+		mv ${rpi_configtxt_tempfile} ${rpi_configtxt_path}
+	;;
 esac
 }
 
diff --git a/test_db b/test_db
index aec83f1..217fe64 100755
--- a/test_db
+++ b/test_db
@@ -22,7 +22,7 @@
 MACHINE_DB=$(cat ${FK_CHECKOUT:-$FK_DIR}/db/*.db)
 
 test_no_unknown_fields() {
-local expected='Android-Boot-Device Boot-Device Boot-DTB-Path Boot-Initrd-Path Boot-Kernel-Path Boot-Multi-Path Boot-Script-Path Bootloader-Sets-Root DTB-Append DTB-Append-From DTB-Id Kernel-Flavors Machine Machine-Id Method Mtd-Initrd Mtd-Kernel Optional-Packages Required-Packages U-Boot-Initrd-Address U-Boot-Kernel-Address U-Boot-Kernel-Entry-Point U-Boot-Multi-Address U-Boot-Script-Address U-Boot-Script-Name'
+local expected='Android-Boot-Device Boot-Device 

Bug#735093: flash-kernel: does not correctly handle removal of the highest-versioned installed kernel package

[Karsten Merker]

Package: flash-kernel
Version: 3.11
Severity: normal
Tags: patch

Flash-Kernel 3.11 does not properly handle a removal of the
highest-versioned kernel package.  The same applies to current
git as of 2014-01-12 which will probably be released as 3.12.

When called from the kernel postinst in this case, it just aborts
instead of flashing the remaining then-highest-versioned kernel,
which in specific cases could lead to an unbootable system.

Attached is a patch against current mainline flash-kernel git
(as of 7f52719ab0a607b89555baffd1cc8c14207c0f8f).

It is available for merging in the rpi-support-rebased branch at
http://anonscm.debian.org/gitweb/?p=users/merker/flash-kernel.git;a=shortlog;h=refs/heads/rpi-support-rebased

Regards,
Karsten

-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
From 989312441af9bdec76ba571eb3c6ae3d65f93d4e Mon Sep 17 00:00:00 2001
From: K. Merker mer...@debian.org
Date: Thu, 2 Jan 2014 14:34:32 +0100
Subject: [PATCH] Add extended kernel package removal handling

Until now, flash-kernel has not properly handled a removal of the
highest-versioned kernel package.  When called from the kernel
postinst in this case, it just aborted instead of flashing the
remaining then-highest-versioned kernel, which could lead to an
unbootable system.

This patch adds extended removal handling which takes care
of the issue.
---
 debian/copyright|1 +
 flash-kernel.8  |   18 ++---
 functions   |   63 +++
 kernel-hook/zz-flash-kernel |6 +++--
 4 files changed, 71 insertions(+), 17 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index af21da0..e9fb23c 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -6,6 +6,7 @@ Copyright:
 Copyright (C) 2006  Joey Hess  jo...@debian.org
 Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011  Martin Michlmayr t...@cyrius.com
 Copyright (C) 2011  Loïc Minier l...@dooz.org
+Copyright (C) 2014  Karsten Merker mer...@debian.org
 
 This program is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License
diff --git a/flash-kernel.8 b/flash-kernel.8
index 7b5bad5..8165372 100644
--- a/flash-kernel.8
+++ b/flash-kernel.8
@@ -3,7 +3,7 @@
 .SH NAME
 flash-kernel \- put kernel and initramfs in boot location
 .SH SYNOPSIS
-.B flash-kernel [--supported] [kvers]
+.B flash-kernel [--machine machine-type] [--context calling-context] [--supported] [kvers]
 .SH DESCRIPTION
 flash-kernel is a script which will put the kernel and initramfs in
 the boot location of embedded devices that don't load the kernel and
@@ -11,7 +11,7 @@ initramfs directly from /boot.  flash-kernel supports devices that
 boot from flash memory (hence the name) as well as some devices that
 require a special boot image on the disk.
 .P
-Optionally, it can be passed a version of the kernel to flash; only
+Optionally, it can be passed a version of the kernel to process; only
 the highest version will be flashed and other versions will be
 ignored.  Kernel and initrd are read from /boot.
 .P
@@ -20,7 +20,17 @@ the subarchitectures of the machine and the image to be flashed
 match. Valid filenames for images to flash are suffixed with the
 subarchitecture.
 .P
-If the \-\-supported option is used, flash\-kernel will test to see if
+If the \-\-supported option is used, flash\-kernel will test whether
 the hardware is supported, and return a true or false value.
+.P
+The \-\-machine option allows to manually override the auto-detected
+machine type string.
+.P
+The \-\-context option is used internally by the kernel
+postinst/postrm scripts which call flash-kernel upon kernel package
+installations and removals.  It provides flash-kernel with the
+information that it is running in the kernel packages
+postinst/postrm context. Valid values are postinst.d* and
+postrm.d*.
 .SH AUTHOR
-Martin Michlmayr t...@cyrius.com
+Martin Michlmayr t...@cyrius.com, Karsten Merker mer...@debian.org
\ No newline at end of file
diff --git a/functions b/functions
index 26a16ed..4b1745e 100644
--- a/functions
+++ b/functions
@@ -351,28 +351,69 @@ android_flash() {
 }
 
 main() {
-if [ x$1 = x--machine ]; then
-	machine=$2
-	shift 2
-else
+
+while [ $# -gt 0 ]
+do
+if [ x$1 = x--machine ]; then
+machine=$2
+shift 1
+elif [ x$1 = x--context ]; then
+context=$2
+shift 1
+elif [ x$1 = x--supported ]; then
+do_check_supported=true
+elif [ $# -eq 1 ]; then
+kvers=$1
+fi
+shift 1
+done
+
+if [ -z $machine ]; then
 	get_machine
 fi
 
-if [ x$1 = x--supported ]; then
+if [ -n $do_check_supported ]; then
 	if check_supported $machine; then
 		exit 0
+	else
+		exit 1
 	fi
-	exit 1
 fi
 
-# kernel

Bug#735092: flash-kernel: add Raspberry Pi support

[Karsten Merker]

On Sun, Jan 12, 2014 at 07:01:36PM +, Ian Campbell wrote:
 On Sun, 2014-01-12 at 19:24 +0100, Karsten Merker wrote:
  On Sun, Jan 12, 2014 at 06:00:24PM +, Ben Hutchings wrote:
   On Sun, 2014-01-12 at 18:34 +0100, Karsten Merker wrote:
  
The attached patch adds Raspberry Pi support to flash-kernel.
  [SNIP]
   So the boot partition is mounted at /boot?  Doesn't that make it
   impossible to install packaged kernels (as dpkg needs to create hard
   links)?
  
  Installing a kernel package (locally built using make-kpkg) with
  a VFAT /boot does not show any problems here:
 
 The normal way of dealing with this is to not have the bootloader
 partition mounted on boot, this is described in flash-kernel via the
 Boot-Device field. I think this should be honoured for Rpi too.
 Rpi-ConfigTxt-Path would then be relative to this device.

Having the vfat boot partition as /boot is the standard way in
Raspbian (Debian/armhf rebuild for the Pi/armv6, official OS
distribution for the Pi) and is described this way in all user
documentation for the Pi.  This is also expected by other
software, in particular the firmware update mechanism, which
expects the firmware image to be at
/boot/bootcode.bin, as well as by the Raspberry Pi foundation's
kernel updates (which do not come as a Debian kernel package).

Not mounting the vfat boot partition at /boot would of course be
technically possible, but nobody actually does that on a Pi
and it would pose several problems:

- The firmware update mechanism would have to be changed. This is
  outside the scope of Debian and as installing firmware updates
  is something that happens rather frequently on the Pi, that
  must work without problems.

- All the Pi user documentation would have to be changed, which
  is also outside the scope of Debian.

- In case the vfat boot partition is not mounted at /boot,
  the firmware cannot anymore directly boot the /boot/vmlinuz-*
  and /boot/initrd.img-* files from the kernel package.
  That would therefore require copying the files from /boot
  to the actual vfat boot partition. 

  As having the vfat boot partition mounted on /boot is the
  actual default case, flash-kernel would have to handle this as
  well.  This means either special handling depending on whether
  the vfat partition is at /boot or not, or generally copying the
  kernel to the vfat partition under another name.  The latter
  would in the case vfat-at-/boot result in having the kernel and
  initrd twice on the already quite small system vfat partition,
  which is a route I would like to avoid.

All things taken together I think that we should simply
accept that the vfat boot partition gets mounted at /boot
on the Pi and use it this way.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735092: flash-kernel: add Raspberry Pi support

[Karsten Merker]

On Sun, Jan 12, 2014 at 07:32:56PM +, Ben Hutchings wrote:
 On Sun, 2014-01-12 at 19:24 +0100, Karsten Merker wrote:
  On Sun, Jan 12, 2014 at 06:00:24PM +, Ben Hutchings wrote:

   So the boot partition is mounted at /boot?  Doesn't that make it
   impossible to install packaged kernels (as dpkg needs to create hard
   links)?
  
  Installing a kernel package (locally built using make-kpkg) with
  a VFAT /boot does not show any problems here:
 [...]
 
 Please also test upgrading (or simply reinstalling the same package
 again).

Indeed, reinstalling fails:

dpkg: error processing linux-image-3.12.6-rpi+_2014010201_armhf.deb (--install):
 unable to make backup link of `./boot/vmlinuz-3.12.6-rpi+' before installing 
new version: Operation not permitted

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728014: [PATCH] Fix cross-building armhf kernel packages

[Karsten Merker]

Package: kernel-package
Version: 12.036+nmu3
Tags: patch

I am rather new to the arm architecture and currently trying to
get a couple of things working on a Raspberry Pi.  Building
kernel packages natively on a 700MHz single-core ARMv6 cpu takes
ages, so I have been looking into possibilities for
cross-building kernel packages from faster architectures. 
According to the make-kpkg manpage, the following command

  $ make-kpkg --arch armhf --cross_compile arm-rpi-linux-gnueabi- \
--revision 20131002 --append_to_version -rpi --initrd \
--us --uc --rootcmd fakeroot kernel_image

should build an armhf kernel package on an amd64 host with an
arm-rpi-linux-gnueabi-crosstoolchain installed. With
kernel-package 12.036+nmu3 this fails with

  debian/ruleset/misc/checks.mk:36: *** Error. I do not know
  where the kernel image goes to [kimagedest undefined] The usual
  case for this is that I could not determine which arch or
  subarch this machine belongs to.  Please specify a subarch, and
  try again..  Stop.

It looks like there are just a few definitions for armhf missing,
which are only used in the case of cross-building - native builds
work fine.  With the attached patch, cross-building kernel
packages for armhf works for me, i.e. it results in working
kernel-image packages for the Raspberry Pi.  I had asked on
debian-arm whether anybody sees issues with the patch, but have
received no reply.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur kernel-package-12.036+nmu3/kernel/ruleset/arches/armhf.mk kernel-package-12.036+nmu3.patched/kernel/ruleset/arches/armhf.mk
--- kernel-package-12.036+nmu3/kernel/ruleset/arches/armhf.mk	1970-01-01 01:00:00.0 +0100
+++ kernel-package-12.036+nmu3.patched/kernel/ruleset/arches/armhf.mk	2013-10-02 22:02:47.0 +0200
@@ -0,0 +1,34 @@
+# -*- Mode: Makefile-Gmake -*- 
+## armhf.mk --- 
+## 
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+##
+###
+
+### ARMHF
+ifeq ($(strip $(architecture)),armhf)
+  kimage := vmlinuz
+  target = zImage
+  NEED_DIRECT_GZIP_IMAGE=NO
+  kimagesrc = arch/$(KERNEL_ARCH)/boot/zImage
+  kimagedest = $(INT_IMAGE_DESTDIR)/vmlinuz-$(KERNELRELEASE)
+  DEBCONFIG = $(CONFDIR)/config.armhf
+  kelfimagesrc = vmlinux
+  kelfimagedest = $(INT_IMAGE_DESTDIR)/vmlinux-$(KERNELRELEASE)
+endif
+
+#Local variables:
+#mode: makefile
+#End:
diff -Nur kernel-package-12.036+nmu3/kernel/ruleset/architecture.mk kernel-package-12.036+nmu3.patched/kernel/ruleset/architecture.mk
--- kernel-package-12.036+nmu3/kernel/ruleset/architecture.mk	2012-03-04 02:22:23.0 +0100
+++ kernel-package-12.036+nmu3.patched/kernel/ruleset/architecture.mk	2013-10-02 22:01:08.0 +0200
@@ -59,6 +59,10 @@
 ifeq ($(strip $(architecture)),armeb)
 include $(DEBDIR)/ruleset/arches/armeb.mk
 endif
+ifeq ($(strip $(architecture)),armhf)
+include $(DEBDIR)/ruleset/arches/armhf.mk
+endif
+
 
 # PowerPC and PowerPC architecture 
 ifneq ($(strip $(filter ppc powerpc ppc64 powerpc64,$(architecture))),)
diff -Nur kernel-package-12.036+nmu3/kernel/ruleset/misc/kernel_arch.mk kernel-package-12.036+nmu3.patched/kernel/ruleset/misc/kernel_arch.mk
--- kernel-package-12.036+nmu3/kernel/ruleset/misc/kernel_arch.mk	2012-03-04 02:39:27.0 +0100
+++ kernel-package-12.036+nmu3.patched/kernel/ruleset/misc/kernel_arch.mk	2013-10-02 21:55:54.0 +0200
@@ -56,6 +56,10 @@
   KERNEL_ARCH := arm
 endif
 
+ifeq ($(strip $(architecture)),armhf)
+  KERNEL_ARCH := arm
+endif
+
 ifeq ($(strip $(architecture)),hppa)
   KERNEL_ARCH := parisc
 endif

Bug#706583: Installation report Wheezy DI rc2 amd64 xfce: installation ok

[Karsten Merker]

Package: installation-reports

Boot method: isohybrid image booted from USB stick
Image version: 
http://cdimage.debian.org/cdimage/wheezy_di_rc2/amd64/iso-cd/debian-wheezy-DI-rc2-amd64-netinst.iso
Date: 2013-05-01

Mainboard: ECS P35T-A
Processor: Intel E3300
Memory: 4GB

Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM 
Controller [8086:29c0] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation 82G33/G31/P35/P31 Express PCI 
Express Root Port [8086:29c1] (rev 02)
00:19.0 Ethernet controller [0200]: Intel Corporation 82566DC-2 Gigabit Network 
Connection [8086:294c] (rev 02)
00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 [8086:2937] (rev 02)
00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 [8086:2938] (rev 02)
00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #2 [8086:293c] (rev 02)
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio 
Controller [8086:293e] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 1 [8086:2940] (rev 02)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 2 [8086:2942] (rev 02)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 3 [8086:2944] (rev 02)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 4 [8086:2946] (rev 02)
00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 5 [8086:2948] (rev 02)
00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #1 [8086:2934] (rev 02)
00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #2 [8086:2935] (rev 02)
00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #3 [8086:2936] (rev 02)
00:1d.3 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #6 [8086:2939] (rev 02)
00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #1 [8086:293a] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 
92)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801IH (ICH9DH) LPC Interface 
Controller [8086:2912] (rev 02)
00:1f.2 IDE interface [0101]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 
port SATA Controller [IDE mode] [8086:2920] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller 
[8086:2930] (rev 02)
00:1f.5 IDE interface [0101]: Intel Corporation 82801I (ICH9 Family) 2 port 
SATA Controller [IDE mode] [8086:2926] (rev 02)
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI 
RV505 [Radeon X1550 Series] [1002:7143]
01:00.1 Display controller [0380]: Advanced Micro Devices [AMD] nee ATI RV505 
[Radeon X1550 Series] (Secondary) [1002:7163]
06:00.0 SATA controller [0106]: JMicron Technology Corp. JMB361 AHCI/IDE 
[197b:2361] (rev 02)
06:00.1 IDE interface [0101]: JMicron Technology Corp. JMB361 AHCI/IDE 
[197b:2361] (rev 02)

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:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

The installation process worked flawlessly.  Installation
was done using a network mirror; network connectivity was
provided via a TP-Link TL-WN727N 802.11n WLAN dongle
(USB ID: 148f:5370, Ralink RT5370 chipset).

The installer prompted for the WLAN dongle's firmware, which was
provided on a USB stick (downloaded from
http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/wheezy/current/).

Basic X11 functionality worked out of the box, advanced X11
features (in particular XVideo support) required installation of
the non-free radeon firmware from the package firmware-linux-nonfree.

A sidenote: while the WLAN via the TL-WN727N generally works,
interactive use (in particular using logins via ssh) shows that
the connection often has short lags or hangs.  This happens even
when the WLAN dongle is within 2m of the access point with direct
line of sight.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683692: installation report: [i386] [daily 2012/08/02] installation hangs forever

[Karsten Merker]

Package: installation-reports

Boot method: credit card image booted from USB key
Image version: 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/jigdo-cd/debian-testing-i386-netinst.jigdo
Image date: 2012/08/02 17:27

Installation date: 2012/08/02

Machine: Desktop PC
Processor: Pentium DualCore E2200
Memory: 2 GB
Partitions: installer fails before partitioning stage

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

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

Comments/Problems:

The machine has a TP-Link TL-WN721N 802.11n WLAN dongle (based on an
Atheros AR9271 chipset) connected via USB.  As long as this device is
connected to the computer, the detect network stage just hangs
forever.  If the WLAN dongle is not connected to the machine, d-i works
as expected.

The firmware for the WLAN dongle is non-free and therefore not included
in d-i, but the installation should not hang completely just because
the device is connected to the computer.

The device itself is supported by Linux and works when connected after
the installation is finished, provided the (non-free) package
firmware-atheros has been installed.

Relevant syslog entries:
Aug  2 19:03:39 kernel: [2.448030] usb 1-3: new high-speed USB device 
number 4 using ehci_hcd
Aug  2 19:03:39 kernel: [2.604889] usb 1-3: New USB device found, 
idVendor=0cf3, idProduct=9271
Aug  2 19:03:39 kernel: [2.611200] usb 1-3: New USB device strings: Mfr=16, 
Product=32, SerialNumber=48
Aug  2 19:03:39 kernel: [2.617486] usb 1-3: Product: USB2.0 WLAN
Aug  2 19:03:39 kernel: [2.623615] usb 1-3: Manufacturer: ATHEROS
Aug  2 19:03:39 kernel: [2.629689] usb 1-3: SerialNumber: 12345

Aug  2 19:03:49 hw-detect: Missing modules 'eth1394 (FireWire ethernet)
Aug  2 19:03:50 check-missing-firmware: /dev/.udev/firmware-missing does not 
exist, skipping
Aug  2 19:03:50 check-missing-firmware: /run/udev/firmware-missing does not 
exist, skipping
Aug  2 19:03:50 check-missing-firmware: no missing firmware in 
/dev/.udev/firmware-missing /run/udev/firmware-missing

Aug  2 19:04:59 kernel: [   85.337797] cfg80211: Calling CRDA to update world 
regulatory domain
Aug  2 19:04:59 net/hw-detect.hotplug: Detected hotpluggable network interface 
lo
Aug  2 19:04:59 kernel: [   85.424081] usb 1-3: ath9k_htc: Firmware - 
htc_9271.fw not found
Aug  2 19:04:59 kernel: [   85.424092] ath9k_htc: probe of 1-3:1.0 failed with 
error -22
Aug  2 19:04:59 kernel: [   85.424112] usbcore: registered new interface driver 
ath9k_htc
Aug  2 19:04:59 net/hw-detect.hotplug: Detected hotpluggable network interface 
eth0
Aug  2 19:04:59 hw-detect: Missing modules 'eth1394 (FireWire ethernet)
Aug  2 19:05:00 check-missing-firmware: /dev/.udev/firmware-missing does not 
exist, skipping
Aug  2 19:05:00 check-missing-firmware: missing firmware files (htc_9271.fw) 
for ath9k_htc
Aug  2 19:05:01 kernel: [   87.334257] FAT-fs (sda): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Aug  2 19:05:01 kernel: [   87.363899] FAT-fs (sda): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Aug  2 19:05:01 kernel: [   87.11] FAT-fs (sdc): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Aug  2 19:05:01 kernel: [   87.519037] FAT-fs (sdc): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Aug  2 19:05:01 kernel: [   87.584031] end_request: I/O error, dev fd0, sector 0
Aug  2 19:05:01 kernel: [   87.608030] end_request: I/O error, dev fd0, sector 0
Aug  2 19:05:01 kernel: [   87.632033] end_request: I/O error, dev fd0, sector 0
Aug  2 19:05:01 kernel: [   87.656029] end_request: I/O error, dev fd0, sector 0
Aug  2 19:05:01 kernel: [   87.675372] FAT-fs (sda1): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Aug  2 19:05:01 kernel: [   87.705927] FAT-fs (sda1): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Aug  2 19:05:01 kernel: [   87.833271] FAT-fs (sda): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Aug  2 19:05:01 kernel: [   87.846341] FAT-fs (sda): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Aug  2 19:05:01 kernel: [   87.926912] FAT-fs (sdc): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Aug  2 19:05:01 kernel: [   88.001788] FAT-fs (sdc): utf8 is not a recommended 
IO charset for FAT