Bug#1025211: /usr/bin/riscv64-unknown-elf-g++: Missing C++ headers for riscv64-unknown-elf-g++

2022-11-30 Thread Joel Stanley 
Package: gcc-riscv64-unknown-elf
Version: 12.1.0-7+11
Severity: important
File: /usr/bin/riscv64-unknown-elf-g++

Hello Keith,

I am using the riscv elf toolchain to build a C++ program. It
tries to look for headers here:

$ echo | riscv64-unknown-elf-g++ -E -Wp,-v -
ignoring nonexistent directory 
"/usr/lib/gcc/riscv64-unknown-elf/12.1.0/../../../riscv64-unknown-elf/sys-include"
ignoring nonexistent directory 
"/usr/lib/gcc/riscv64-unknown-elf/12.1.0/../../../riscv64-unknown-elf/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/riscv64-unknown-elf/12.1.0/include
 /usr/lib/gcc/riscv64-unknown-elf/12.1.0/include-fixed
End of search list.

There's no C++ headers in this location. How should users get C++
headers with the elf toolchain?

Or is this unsupported, and we should instead use the linux toolchain
for C++ programs?

I'm not usually a C++ developer so please clarify if I've made some bad
assumptions here.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 6.0.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-riscv64-unknown-elf depends on:
ii  binutils-riscv64-unknown-elf  2.39-8+4
ii  libc6 2.36-5
ii  libgcc-s1 12.2.0-9
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  libisl23  0.25-1
ii  libmpc3   1.2.1-2
ii  libmpfr6  4.1.0-3
ii  libstdc++612.2.0-9
ii  zlib1g1:1.2.11.dfsg-4.1

gcc-riscv64-unknown-elf recommends no packages.

gcc-riscv64-unknown-elf suggests no packages.

-- no debconf information

Bug#1008918: unbound: New upstream version

2022-04-04 Thread Joel Stanley 
Source: unbound
Version: 1.13.1-1
Severity: normal

Dear Maintainer,

I've been noticing segfaults in unbound on an internet facing server
running 1.13.1-1 on Debian stable. When hunting around for similar bug
reports I noticed there's since been a few new releases.

I took a stab at updating the packaging and I'm running this version
now:

 https://github.com/shenki/unbound-debian

It's been stable for a few weeks now. Please consider uploading the
latest version to unstable.

Bug#1008580: sparse: Update gcc-10 dependency

2022-03-28 Thread Joel Stanley 
Package: sparse
Version: 0.6.4-1+b1
Severity: normal

Dear Maintainer,

Sparse in testing depends on gcc-10. As the kernel has moved to depend
on gcc-11, sparse is the only package on my system pulling in the older
compiler as a dependency.

Perhaps it could be made to depend on simply 'gcc', or changed to
gcc-11.

Versions of packages sparse depends on:
ii  gcc-1010.3.0-14
ii  libc6 2.33-7
ii  libgcc-s1 12-20220319-1
ii  libllvm13 1:13.0.1-3+b1
ii  libsqlite3-0  3.38.1-1
ii  libxml2   2.9.13+dfsg-1
ii  perl  5.34.0-3

Bug#991262: Missing mdio network module on armhf ASPEED AST2600 system

2021-07-18 Thread Joel Stanley 
Package: installation-reports
Severity: important

Boot method: network
Image version: https://d-i.debian.org/daily-images/armhf/daily/device-tree/ 
20210719-00:04:35
Date: 2021-07-19

Machine: ASPEED AST2600 EVB

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

Comments/Problems:

The installer was prepared by creating a FIT to boot from u-boot:

mkimage -f auto -A arm -O linux -T kernel -C none \
 -a 0x8000 -e 0x8000 -d vmlinuz \
 -b aspeed-ast2600-evb.dtb -i initrd.gz \
 debian-installer

And then tftp booted from the vendor u-boot, using a serial console. The
installer starts fine but fails when detecting network.

The system uses the ftgmac100 network device, and requires the
aspeed_mdio module to be present too. The mdio module is not included in
the installer so network detection fails.

In the past this could be worked around by booting with an upstream
kernel with all the required drivers built in, however now d-i will fail
the install when it cannot find the kernel version in the apt archives.
Being able to override this behaviour would be useful for installing on
systems that don't yet have full kernel support in the Debian archive.

Bug#979542: gcc-riscv64-unknown-elf: Unable to use stdint.h

2021-01-07 Thread Joel Stanley 
Package: gcc-riscv64-unknown-elf
Version: 8.3.0.2019.08+dfsg-1
Severity: normal

Dear Maintainer,

I am trying to use the riscv toolchain to build a bare metal
application. It appears to have a broken stdint.h:

$ cat test.c
#include 
$ riscv64-unknown-elf-gcc -E   -march=rv32i  -mabi=ilp32  -c test.c
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "/usr/lib/gcc/riscv64-unknown-elf/8.3.0/include/stdint.h" 1 3 4
In file included from test.c:1:
/usr/lib/gcc/riscv64-unknown-elf/8.3.0/include/stdint.h:9:16: fatal error: 
stdint.h: No such file or directory
 # include_next 
^~

$ cat /usr/lib/gcc/riscv64-unknown-elf/8.3.0/include/stdint.h
#ifndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
#  undef __STDC_LIMIT_MACROS
#  define __STDC_LIMIT_MACROS
#  undef __STDC_CONSTANT_MACROS
#  define __STDC_CONSTANT_MACROS
# endif
# include_next 
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif

$ riscv64-unknown-elf-gcc -E   -march=rv32i  -mabi=ilp32 -dM -nostdlib - < 
/dev/null |grep STDC_HOSTED
#define __STDC_HOSTED__ 1

stdint-gcc.h is a "real" stdint.h, containing the definitions I want.
I'm not sure how a user is supposed to tell the toolchain to use that
instead, if they can at all.

Comparing it to Debian's arm bare metal toolchain:

$ dpkg -L gcc-arm-none-eabi |grep stdint
/usr/lib/gcc/arm-none-eabi/8.3.1/include/stdint.h
/usr/lib/gcc/arm-none-eabi/8.3.1/plugin/include/config/newlib-stdint.h

The stdint.h here is equivalent to the riscv stdint-gcc.h, so the test
program compiles in that case.

Is this something that can be fixed with the riscv toolchain? Or is it
user error on my part?

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages gcc-riscv64-unknown-elf depends on:
ii  binutils-riscv64-unknown-elf  2.32.2020.04+dfsg-2
ii  libc6 2.31-6
ii  libgcc-s1 [libgcc1]   10.2.1-3
ii  libgmp10  2:6.2.1+dfsg-1
ii  libmpc3   1.2.0-1
ii  libmpfr6  4.1.0-3
ii  libstdc++610.2.1-3
ii  zlib1g1:1.2.11.dfsg-2

gcc-riscv64-unknown-elf recommends no packages.

gcc-riscv64-unknown-elf suggests no packages.

-- no debconf information

Bug#978532: openconnect: libtss2-esys0 dependency is broken

2020-12-28 Thread Joel Stanley 
Package: openconnect
Version: 8.10-2+b1
Severity: important

Dear Maintainer,

libopenconnect depends on libtss2-esys0 which has been renamed to
libtss2-esys-3.0.2-0 (bug #974837).

In testing, when libtss2-esys0 is replaced with the renamed package
openconnect will be removed.

I believe the fix is to update the libopenconnect dependency from
libtss2-esys0 to libtss2-esys-3.0.2-0.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages openconnect depends on:
ii  libc62.31-5
ii  libgnutls30  3.7.0-3
ii  libopenconnect5  8.10-1
ii  libproxy1v5  0.4.16-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  vpnc-scripts 0.1~git20200930-1

Versions of packages openconnect recommends:
ii  python3 3.9.0-4
ii  python3-asn1crypto  1.4.0-1
ii  python3-mechanize   1:0.4.5-2
ii  python3-netifaces   0.10.9-0.2+b3

Versions of packages openconnect suggests:
ii  bash-completion  1:2.11-2

-- no debconf information

Bug#804350: ITP: vizzini -- Kernel driver for Exar XR21V1414 USB UART

2015-12-21 Thread Joel Stanley 
Hi Ben,

On Tue, 10 Nov 2015 22:06:20 + Ben Hutchings <b...@decadent.org.uk> wrote:
> However, as this device doesn't really seem to follow the CDC-ACM class
> at all, I suspect that the way to support it upstream is with a custom
> USB serial driver.  I've attached a patch against Linux 4.3 which
> implements that.  This involved a certain amount of guesswork as I have
> no experience with serial drivers, but I think it's worth trying.

Thanks for the patch. Similarly, I don't have experience with serial
drivers. We managed to get it working with some changes to skip over
the interrupt endpoint. While this hack works, we need to work out
what we're missing by ignoring this descriptor.

I have a tree with my patch atop Bens here:

 https://github.com/shenki/linux/tree/vizzini

Cheers,

Joel
From 36b15d5c5a6374acf075f3dbe38ecd67757f8564 Mon Sep 17 00:00:00 2001
From: Joel Stanley <j...@jms.id.au>
Date: Sun, 15 Nov 2015 17:30:19 +1030
Subject: [PATCH] usb-serial/vizzini: Fix probing for 1410 device

This device has the following configuration:

 device
  - interface
- interrupt endpoint
  - interface
- in bulk endpoint
- out bulk endpoint

The first interface should be ignored in order to correctly probe. The
device appears to operate correctly, but this may be a horrible hack.

Signed-off-by: Joel Stanley <j...@jms.id.au>
---
 drivers/usb/serial/vizzini.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/usb/serial/vizzini.c b/drivers/usb/serial/vizzini.c
index b462cb694ed5..ee33366348a7 100644
--- a/drivers/usb/serial/vizzini.c
+++ b/drivers/usb/serial/vizzini.c
@@ -294,6 +294,32 @@ static void vizzini_set_termios(struct tty_struct *tty,
 vizzini_enable(port);
 }
 
+static int vizzini_probe(struct usb_serial *serial,
+			 const struct usb_device_id *id)
+{
+	struct usb_host_interface *iface_desc = serial->interface->
+cur_altsetting;
+	struct usb_endpoint_descriptor *endpoint;
+	int num_bulk_out = 0;
+	int i;
+
+	for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
+		endpoint = _desc->endpoint[i].desc;
+		if (usb_endpoint_is_bulk_out(endpoint)) {
+			dev_dbg(>dev->dev,
+"found bulk out on endpoint %d\n", i);
+			++num_bulk_out;
+		}
+	}
+
+	if (num_bulk_out == 0) {
+		dev_dbg(>dev->dev, "Invalid interface, discarding\n");
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
 static const struct usb_device_id id_table[] = {
 	{ USB_DEVICE(0x04e2, 0x1410), },
 	{ USB_DEVICE(0x04e2, 0x1412), },
@@ -314,6 +340,7 @@ static struct usb_serial_driver vizzini_1410_device = {
 	.id_table =		vizzini_1410_id_table,
 	.num_ports =		1,
 	.set_termios =		vizzini_set_termios,
+	.probe =		vizzini_probe,
 };
 
 static const struct usb_device_id vizzini_1412_id_table[] = {
-- 
2.6.4