from:"Jonathan McDowell"

Bug#1070885: [Pkg-electronics-devel] Bug#1070885: openocd: FTBFS with libgpiod/2.1

2024-05-12 Thread Jonathan McDowell

On Sat, May 11, 2024 at 03:35:36PM +0800, Gavin Lai wrote:
> Source: openocd
> Version: 0.12.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> I am planning to have a transition for libgpiod.
> https://release.debian.org/transitions/html/auto-libgpiod.html
> 
> Many APIs were changed in this transition.
> I tested libgpiod with openocd 0.12.0.
> As a result, it seems FTBFS. Please have a check.
> Feel free to let me know if any information is needed.

It looks like upstream OpenOCD has modified its configure.ac to prevent
trying to build with libgpiod v2. There are patches out for review
around adding proper support, but they're all currently works in
progress.

J.

-- 
... Avoid temporary variables and strange women.

Bug#1067778: retroarch ftbfs in unstable

2024-03-26 Thread Jonathan McDowell

Control: forcemerge 1064681 1067778

On Tue, Mar 26, 2024 at 05:20:33PM +0100, Matthias Klose via Pkg-games-devel 
wrote:
> Package: src:retroarch
> Version: 1.16.0.3+dfsg-1
> Severity: serious
> Tags: sid trixie ftbfs
> 
> retroarch ftbfs in unstable
> 
> [...]
> Checking existence of -lglslang ... yes
> Checking existence of -lOSDependent ... yes
> Checking existence of -lOGLCompiler ... no
> Checking existence of -lMachineIndependent ... yes
> Checking existence of -lGenericCodeGen ... yes
> Checking existence of -lHLSL ... no
> Checking existence of -lSPIRV ... yes
> Checking existence of -lSPIRV-Tools-opt ... yes
> Checking existence of -lSPIRV-Tools ... yes
> Notice: System glslang libraries not found, disabling glslang support.
> Notice: glslang is disabled, slang support will also be disabled.
> Error: glslang is disabled and forced to build with SPIRV-Cross support.
> make[1]: *** [debian/rules:48: override_dh_auto_configure] Error 1
> make[1]: Leaving directory '/home/packages/tmp/retroarch-1.16.0.3+dfsg'
> make: *** [debian/rules:42: binary] Error 2
> 
> ___
> Pkg-games-devel mailing list
> pkg-games-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel

J.

-- 
101 things you can't have too much of : 1 - Cable ties.

Bug#1067263: [Pkg-electronics-devel] Bug#1067263: sigrok-firmware-fx2lafw: FTBFS: sdcpp: fatal error: cannot execute 'cc1': execvp: No such file or directory

2024-03-20 Thread Jonathan McDowell

Control: reassign -1 sdcc

This is going to be a result of the 4.4.0 sdcc upload I did over the
weekend.

On Wed, Mar 20, 2024 at 10:04:12PM +0100, Lucas Nussbaum wrote:
> Source: sigrok-firmware-fx2lafw
> Version: 0.1.7-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240319 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > sdcc -mmcs51 -I./include -I./fx2lib/include -c fx2lafw.c -o fx2lafw.rel
> > sdcc -mmcs51 -I./include -I./fx2lib/include -c gpif-acquisition.c -o 
> > gpif-acquisition.rel
> > sdcpp: fatal error: cannot execute 'cc1': execvp: No such file or directory
> > compilation terminated.
> > sdcpp: fatal error: cannot execute 'cc1': execvp: No such file or directory
> > at 1: warning 190: ISO C forbids an empty translation unit
> > subprocess error 256
> > compilation terminated.
> > at 1: warning 190: ISO C forbids an empty translation unit
> > subprocess error 256
> > make[1]: *** [Makefile:991: fx2lafw.rel] Error 1
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2024/03/19/sigrok-firmware-fx2lafw_0.1.7-1_unstable.log
> 
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240319;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240319=lu...@debian.org=1=1=1=1#results
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please mark it as 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.
> 
> ___
> Pkg-electronics-devel mailing list
> pkg-electronics-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-electronics-devel

J.

-- 
] https://www.earth.li/~noodles/ []  Shopping is hard. Let's do Math!  [
]  PGP/GPG Key @ the.earth.li[][
] via keyserver, web or email.   [][
] RSA: 4096/0x94FA372B2DA8B985   [][

Bug#1064731: [Pkg-electronics-devel] Bug#1064731: sdcc: FTBFS: /bin/sh: 1: inkscape: not found

2024-03-18 Thread Jonathan McDowell

Control: retitle -1 sdcc: FTBFS: Error building LyX documentation

On Sun, Feb 25, 2024 at 08:45:34PM +0100, Lucas Nussbaum via 
Pkg-electronics-devel wrote:
> Source: sdcc
> Version: 4.2.0+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240224 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

The inkscape error here is a red herring; even switching from
librsvg2-bin back to inkscape doesn't do any better. Something in the
LyX -> LaTeX dependency tree must have changed. :(

J.

-- 
... "What the f**k was that?" -- Mayor of Hiroshima

Bug#1064681: retroarch: FTBFS: make[1]: *** [debian/rules:48: override_dh_auto_configure] Error 1

2024-02-26 Thread Jonathan McDowell

Control: tags -1 - trixie
Control: severity -1 important

On Sun, Feb 25, 2024 at 08:48:32PM +0100, Lucas Nussbaum via Pkg-games-devel 
wrote:
> Source: retroarch
> Version: 1.16.0.3+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240224 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This looks like a glslang issue; #1062799 and the associated autopkgtest
failures for glslang's migration to trixie (e.g.
https://ci.debian.net/packages/g/glslang/testing/amd64/43341664/).

I'm dropping this to important until glslang is fixed.

> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > sed 's/@DEB_HOST_MULTIARCH@/x86_64-linux-gnu/g' \
> > retroarch.cfg > debian/retroarch.cfg
> > # See ./configure --help for valid flags
> > # disable flags (i.e. --disable-ffmpeg for example) if there is no package 
> > relative to the feature in Build-Depends
> > ./configure --prefix=/usr \
> > --disable-builtinmbedtls \
> > --disable-builtinbearssl \
> > --disable-builtinflac \
> > --disable-builtinglslang \
> > --disable-builtinzlib \
> > --disable-update_assets \
> > --disable-oss \
> > --disable-vg \
> > --enable-dbus \
> > --enable-spirv_cross \
> > --enable-vulkan \
> > --enable-sse
> > Checking operating system ... Linux 
> > Checking for suitable working C compiler ... /usr/bin/gcc works
> > Checking for suitable working C++ compiler ... /usr/bin/g++ works
> > Checking for pkg-config ... /usr/bin/pkgconf
> > Checking for availability of switch -std=gnu99 in /usr/bin/gcc ... yes
> > Checking for availability of switch -std=c++17 in /usr/bin/g++ ... yes
> > Checking for availability of switch -Wno-unused-result in /usr/bin/gcc ... 
> > yes
> > Checking for availability of switch -Wno-unused-variable in /usr/bin/gcc 
> > ... yes
> > Checking function sd_get_machine_names in -lsystemd ... no
> > Checking presence of package bcm_host ... no
> > Checking function bcm_host_init in -lbcm_host ... no
> > Checking presence of header file EGL/eglext.h ... yes
> > Checking presence of package egl ... 1.5
> > Checking function ass_library_init in -lfribidi -lass ... no
> > Checking existence of -msse -msse2 ... yes
> > Checking function pthread_create in -lpthread ... yes
> > Checking function pthread_key_create in -lpthread ... yes
> > Checking presence of package check >= 0.15 ... no
> > Checking presence of header file scsi/sg.h ... yes
> > Checking function dlopen in -ldl ... yes
> > Checking function socket in -lc ... yes
> > Checking function getaddrinfo in -lc ... yes
> > Checking function fcntl in -lc ... yes
> > Checking function getopt_long in -lc ... yes
> > Checking presence of package alsa ... 1.2.10
> > Checking presence of package libsixel >= 1.6.0 ... no
> > Checking presence of predefined macro AUDIO_SETINFO in sys/audioio.h ... no
> > Checking presence of package rsound >= 1.1 ... no
> > Checking presence of package libroar >= 1.0.12 ... no
> > Checking presence of package jack >= 0.120.1 ... 1.9.21
> > Checking presence of package libpulse ... 16.1
> > Checking presence of package sdl >= 1.2.10 ... no
> > Checking presence of package sdl2 >= 2.0.0 ... 2.30.0
> > Checking presence of package Qt5Core >= 5.2 ... 5.15.10
> > Checking presence of package Qt5Gui >= 5.2 ... 5.15.10
> > Checking presence of package Qt5Widgets >= 5.2 ... 5.15.10
> > Checking presence of package Qt5Concurrent >= 5.2 ... 5.15.10
> > Checking presence of package Qt5Network >= 5.2 ... 5.15.10
> > Checking presence of package openssl >= 1.0.0 ... no
> > Checking presence of package flac ... 1.4.3
> > Checking existence of -lmbedtls -lmbedx509 -lmbedcrypto ... no
> > Notice: HID is disabled, libusb support will also be disabled.
> > Checking existence of -ldinput8 ... no
> > Checking existence of -ld3d9 ... no
> > Checking existence of -ldsound ... no
> > Checking existence of -ld3dx8 ... no
> > Checking existence of -ld3dx9 ... no
> > Checking presence of header file GL/gl.h ... yes
> > Checking existence of -lGL ... yes
> > Checking function cgCreateContext in -lCg -lCgGL ... no
> > Checking presence of package zlib ... 1.3
> > Checking presence of package libavcodec >= 57 ... 60.31.102
> > Checking presence of package libavformat >= 57 ... 60.16.100
> > Checking presence of package libavdevice >= 57 ... 60.3.100
> > Checking presence of package libswresample >= 2 ... 4.12.100
> > Checking presence of package libavutil >= 55 ... 58.29.100
> > Checking presence of package libswscale >= 4 ... 7.5.100
> > Checking presence of header file libavutil/channel_layout.h ... yes
> > Checking function dlopen in -ldl ... yes
> > Checking presence of package gbm >= 9.0 ... 24.0.1-1
> > Checking presence of package libdrm ... 2.4.120
> > Checking presence of package dbus-1 ... 1.14.10
> > Checking presence of package libudev ... 255
> > Checking presence of

Bug#1059562: contributors.debian.org: some contributors are missing

2023-12-28 Thread Jonathan McDowell

On Thu, Dec 28, 2023 at 02:07:25PM +0100, Pierre Gruet wrote:
> I feel some contributors are missing from the page [0]. For instance, I 
> (Pierre
> Gruet ) have never been on it although I have contributed on a regular
> basis since 2020.
> I have no idea of the number of missing people.
> 
> I feel pointing this out now is relevant as we are currently [1] discussing
> figures based on the contents of [0].

If I look at https://contributors.debian.org/contributor/pgt/ there are
no identifiers listed for you, but does know how to map your username to
your real name. Compare this to my page,
https://contributors.debian.org/contributor/noodles/, which lists email
addresses, fingerprints + logins. Have you tried adding some
associations there (and if you can't login, would you like me to?) -
without any listed it won't be able to match up incoming data.

J.

--

Bug#1051541: ITP: rustic -- fast, encrypted, and deduplicated backups powered by Rust

2023-12-05 Thread Jonathan McDowell

On Tue, Dec 05, 2023 at 08:59:56AM -0700, Scarlett Moore wrote:
> * Package name: rustic
>   Version : 0.5.4
>   Upstream Contact: Alexander Weiss
> * URL : https://github.com/rustic-rs/rustic
> * License : Apache-2.0 or MIT
>   Programming Lang: Rust
>   Description : fast, encrypted, and deduplicated backups powered by Rust
> 
> Restic (https://github.com/restic/restic/) is a great backup tool IMHO. The
> compatible Rust implementation rustic is a lot faster and has a lot more other
> features over the Golang version, for example:
...
> I think that'd be a very useful utility to have in Debian.

Perhaps once it no longer states:

| rustic currently is in beta state and misses regression tests. It is not
| recommended to use it for production backups, yet.

J.

-- 
The end is nearer. |  .''`.  Debian GNU/Linux Developer
   | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Bug#1043168: please include missing stub_flasher_32.json file

2023-11-05 Thread Jonathan McDowell

On Thu, Aug 31, 2023 at 02:28:20AM +0300, Faidon Liambotis wrote:
> A lot of work has happened in Debian and with upstream over the years to
> build these binaries from unmodified sources, which culminated with
> Debian shipping the stubs for the ESP8266, as well as for the ESP32
> RISC-V variants (ESP32-C2, ESP32-C3, ESP32-C6, ESP32-H2). See the
> 4.5.1+dfsg-0.1 and 4.6.2+dfsg-0.1 changelog entries, Debian bug #948096,
> as well as upstream issues #458, #499 and PRs #500, #501, #856, #858.
> 
> The reason that the same has not happened yet for the ESP32, ESP32-S2
> and ESP32-S3 stubs is that we lack the toolchain for them in Debian
> (gcc, binutils & picolibc). picolibc seems to have gained ESP32 support
> upstream in 1.7.9, and Keith Packard is both upstream and the Debian
> maintainer for it, so I suppose it won't be too hard to persuade him.
> gcc and binutils are more complicated. #868895 provides some context,
> and Jonathan McDowell, who maintains gcc-xtensa-lx106 and
> binutils-xtensa-lx106, is aware of the need. I think there is more of a
> backstory there, but he has the details.

When I originally ITPed the lx106/ESP8266 variants I got some strong
pushback about how we should really have a unified gcc/binutils that
would be able to cope with various Xtensa variants. That doesn't seem to
have happened. Faidon has done some work on building multiple versions
from a single source, and I've finally accepted this is a better
situation for now than not having the support at all.

As a first step I've renamed the source binutils-xtensa-lx106 package to
binutils-xtensa. I've got some changes pulled in from Faidon's work that
will then build an ESP32 binutils package (I don't have later devices to
test with) that I'll look at uploading once the new source package
clears NEW.

GCC is a bit more complex; when I tried previously I had problems with
ESP-IDF, and I don't think a version that doesn't allow building with
the upstream SDK is useful. I'll have a further poke at that to see if I
can figure out what was going wrong.

J.

-- 
Revd Jonathan McDowell, ULC | Protect the Human

Bug#1053190: RetroArch compiled with debian flags (--disable-spirv) fail to load some cores

2023-09-29 Thread Jonathan McDowell

On Fri, Sep 29, 2023 at 04:26:03PM +1000, Борисенко Виктор wrote:
> Package: retroarch
> Version: 1.14.0+dfsg-1build1 In debian/rules there is flag
> --disable-spirv_cross for configure and SPIRV-cross sources does not
> included in "deps" subdir. SPIRV-cross  has Apache license which seems
> friendly to debian so I do not know why it was purged.
> With this flag there is no glcore or vulkan (which also disabled explicitly 
> for some reason by --disable-vulkan) video drivers compiled in.

I disabled this when updating to 1.14.0; spirv-cross is already in
Debian but I hit build failures when trying to compile against it so
took the decision to get 1.14 uploaded rather than fight it further. As
I had to strip various non-DFSG-free bits from the tarball anyway I also
stripped out deps that weren't being used to help reduce the size.

1.15 is out and I'd already started trying to get it uploaded, but got
stalled. I'll take a closer look at how to build against the copy of
spirv-cross in Debian.

J.

-- 
] https://www.earth.li/~noodles/ []Don't do it![
]  PGP/GPG Key @ the.earth.li[][
] via keyserver, web or email.   [][
] RSA: 4096/0x94FA372B2DA8B985   [][

Bug#1049948: RM: remote-tty -- ROM; unmaintained; other options exist

2023-08-17 Thread Jonathan McDowell

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: remote-...@packages.debian.org, nood...@earth.li
Control: affects -1 + src:remote-tty


Please remove remote-tty. It's a leaf package which I have not given
much love to in years and no longer use myself. There has been no active
upstream work on it during the time I've maintained it.

Looking at other options within the archive both conserver and conman
appear to fulfil the same niche and be actively maintained. If I was
looking for this functionality again these days that is where I'd look.

Thanks,
J.

Bug#1007607: remote-tty: please consider upgrading to 3.0 source format

2023-08-16 Thread Jonathan McDowell

On Wed, Aug 16, 2023 at 07:20:33PM +0200, Bastian Germann wrote:
> If you do not want to move to format 3.0, please at least specify 1.0 format
> so that dpkg-source can move to default 3.0 format.

TBH I think remote-tty can probably be removed entirely.

J.

-- 
Revd Jonathan McDowell, ULC | It's deja-vu all over again.

Bug#1042109: Please upgrade python-fido2 to 1.1.2

2023-07-26 Thread Jonathan McDowell

Package: python3-fido2
Version: 0.9.1-1
Severity: wishlist
X-Debbugs-Cc: nood...@earth.li

python-fido2 is currently at version 0.9.1, released in February 2021.
There have been several releases since then and the latest is 1.1.2,
released last month.

(I note that although the package doesn't seem to have the appropriate
Vcs-* metadata the package is maintained on salsa at
https://salsa.debian.org/auth-team/python-fido2 so I will try to find
some time to submit an update there.)

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

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

Versions of packages python3-fido2 depends on:
ii  python3   3.11.2-1+b1
ii  python3-cryptography  38.0.4-3
ii  python3-six   1.16.0-4

python3-fido2 recommends no packages.

python3-fido2 suggests no packages.

-- no debconf information

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

2023-07-25 Thread Jonathan McDowell

On Mon, Jul 17, 2023 at 05:16:47PM +0200, Simon Josefsson wrote:
> Jonathan McDowell  writes:
> > On Wed, Jul 12, 2023 at 09:18:27AM +0200, Simon Josefsson wrote:
> >> Christian Kastner  writes:
> >> > On 2023-06-12 17:01, Sune Stolborg Vuorela wrote:
> >> >> Any chance you can give Andreas a go ahead to push a newer Gnupg2
> >> >> to at least
> >> >> experimental, or preferably unstable ?
> >> >
> >> > I, too, would appreciate a newer version. It turns out that in versions
> >> > prior to 2.3, the 'kdf-setup' option with cards does not work [1]. At
> >> > least, that was the case with both Yubikeys and Nitrokeys here on my end.
> >> 
> >> How about uploading ametzler's branch to experimental, as a start?  It
> >> is good time after the bookworm release.  I offer to help maintain GnuPG
> >> in Debian.  Perhaps uploading it to mentors would be a first step, any
> >> objections?
> >> 
> >> There are some new features in GnuPG 2.4.x that I rely on, having to
> >> build it locally is a pain.
> >
> > +1 for an upload of 2.4 to experimental; I'm quite interested in playing
> > with the support for TPM backed keys.
> 
> I cloned
...
> Any feedback on this libgpg-error update?

I think if we're debating over whether the upload should happen or not
then we shouldn't be adding new uploaders to the package yet.

> GnuPG 2.4.x requires libgpg-error 1.47, so uploading a new version of
> libgpg-error would be a first step.

Given this, and the fact we've just been going round in circles with no
feedback from the listed maintainers, I've taken Andreas' work on
libgpg-error and uploaded it to experimental.

I haven't had a chance to look at the gnupg changes yet, which sounds
like they're a bit bigger, but I see no reason they shouldn't also be
uploaded to experimental after review.

The longer term question is whether any of us are stepping up to help
out with full package maintenance, which I believe should be a
prerequisite of an upload to unstable if we don't hear from Eric or dkg.

J.

-- 
Minorities are the foundation of society.

signature.asc
Description: PGP signature

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

2023-07-15 Thread Jonathan McDowell

On Wed, Jul 12, 2023 at 09:18:27AM +0200, Simon Josefsson wrote:
> Christian Kastner  writes:
> > On 2023-06-12 17:01, Sune Stolborg Vuorela wrote:
> >> Any chance you can give Andreas a go ahead to push a newer Gnupg2 to at 
> >> least 
> >> experimental, or preferably unstable ?
> >
> > I, too, would appreciate a newer version. It turns out that in versions
> > prior to 2.3, the 'kdf-setup' option with cards does not work [1]. At
> > least, that was the case with both Yubikeys and Nitrokeys here on my end.
> 
> How about uploading ametzler's branch to experimental, as a start?  It
> is good time after the bookworm release.  I offer to help maintain GnuPG
> in Debian.  Perhaps uploading it to mentors would be a first step, any
> objections?
> 
> There are some new features in GnuPG 2.4.x that I rely on, having to
> build it locally is a pain.

+1 for an upload of 2.4 to experimental; I'm quite interested in playing
with the support for TPM backed keys.

I haven't seen dkg or Eric weigh in on this thread, but they've had a
few months to object and given gnupg lives under the debian/ tree in
salsa I'd take that as an indication that an upload to experimental
would be acceptable.

J.

-- 
I am afraid of the dark.


signature.asc
Description: PGP signature

Bug#1035942: unblock: libretro-bsnes-mercury/094+git20220807-8

2023-05-11 Thread Jonathan McDowell

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libretro-bsnes-merc...@packages.debian.org
Control: affects -1 + src:libretro-bsnes-mercury

Please consider unblocking libretro-bsnes-mercury. The upload fixes the
incorrect location of the buttonmap.xml file for the Kodi libretro
plugins, without which it is not possible to use game controllers with
the emulator.

[ Tests ]

Manually confirmed generated kodi-game-* debs have buttonmap.xml in
resources/ subdirectory, confirmed correct operation of game controller
with package.

[ Risks ]

This is a trivial fix that just corrects the location of the button map
for the Kodi plugins.

[ Checklist ]

  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libretro-bsnes-mercury/094+git20220807-8

git show --stat:

commit 8fa1fad276c3ede227c0c70037a486e2ef23fa96 (HEAD -> master, tag: 
debian/094+git20220807-8)
Author: Jonathan McDowell 
Date:   Thu May 11 10:48:30 2023 +

Fix Kodi plugins buttonmap.xml location (Closes: #1034583)

The buttonmap.xml file needs to live in the resources subdirectory, not
the parent plugin directory.

 debian/changelog   
| 7 +++
 debian/kodi-game/game.libretro.bsnes-mercury-accuracy/{ => 
resources}/buttonmap.xml| 0
 debian/kodi-game/game.libretro.bsnes-mercury-balanced/{ => 
resources}/buttonmap.xml| 0
 debian/kodi-game/game.libretro.bsnes-mercury-performance/{ => 
resources}/buttonmap.xml | 0
 4 files changed, 7 insertions(+)

J.

-- 
I'm not allowed to talk to you any more.
diff -Nru libretro-bsnes-mercury-094+git20220807/debian/changelog 
libretro-bsnes-mercury-094+git20220807/debian/changelog
--- libretro-bsnes-mercury-094+git20220807/debian/changelog 2023-04-19 
08:49:56.0 +
+++ libretro-bsnes-mercury-094+git20220807/debian/changelog 2023-05-11 
10:47:35.0 +
@@ -1,3 +1,10 @@
+libretro-bsnes-mercury (094+git20220807-8) unstable; urgency=medium
+
+  * Team upload
+  * Fix Kodi plugins buttonmap.xml location (Closes: #1034583)
+
+ -- Jonathan McDowell   Thu, 11 May 2023 10:47:35 +
+
 libretro-bsnes-mercury (094+git20220807-7) unstable; urgency=medium
 
   * Team upload
diff -Nru 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
--- 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
  2023-01-22 15:29:27.0 +
+++ 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
  1970-01-01 00:00:00.0 +
@@ -1,17 +0,0 @@
-
-
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-
diff -Nru 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
--- 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
1970-01-01 00:00:00.0 +
+++ 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
2023-05-11 10:47:35.0 +
@@ -0,0 +1,17 @@
+
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
diff -Nru 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
--- 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
  2023-01-22 15:29:27.0 +
+++ 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
  1970-01-01 00:00:00.0 +
@@ -1,17 +0,0 @@
-
-
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-
diff -Nru 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/resources/buttonmap.xml
 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanc

Bug#1034583: kodi-game-libretro: Joystick input doesn't work in games

2023-05-11 Thread Jonathan McDowell

Control: reassign -1 src:libretro-bsnes-mercury

On Tue, Apr 18, 2023 at 09:44:57PM +, Hugh Cole-Baker wrote:
> In Kodi 20 in Debian testing, game addons don't seem to receive any input from
> a USB game controller.
> 
> I have an attached USB game controller (VID 2dc8, PID 9001, 8Bitdo NES30 Pro)
> which is working OK to control the user interface in Kodi to navigate menus,
> etc, but when I launch a game in Kodi, the game doesn't receive any input from
> the controller. The Kodi UI still seems to receive game controller input while
> the game is running, for example I can press Select+Start to exit the game,
> or hold Start to bring up the Kodi game settings menu, but the actual game
> can't be controlled at all.
> 
> This is a regression from the previous version, since I had the same game
> controller working with the libretro-based game addons in Kodi 19 on Bullseye.

There was no kodi-game-libretro that was part of Bullseye, so I think
that must have been from an external repository.

> I have mapped the buttons in Kodi's settings for both the default type of
> controller (named "Kodi" in the UI) and the "Super Nintendo" control scheme,
> and have tested and found this problem with the libretro
> "kodi-game-libretro-bsnes-mercury-performance" Debian package, but also with
> other libretro addons I've built locally, so I don't think it's specific to
> any single libretro game addon, and the controller works fine in other Kodi
> UI, so kodi-game-libretro seemed like the most appropriate package to report
> the bug against.

I can't comment on the local addons you've tried, but I've managed to
reproduce this and the issue is with the
kodi-game-libretro-bsnes-mercury-* packages. They are failing to
install the buttonmap.xml into the correct subdirectory; I think what's
happened is my testing left around a buttonmap.xml in the correct
place, which is why I never noticed.

Try:

sudo mv 
/usr/share/kodi/addons/game.libretro.bsnes-mercury-performance/buttonmap.xml 
/usr/share/kodi/addons/game.libretro.bsnes-mercury-performance/resources/

which will move the button map into the correct location.

> Some things I've noticed that could be useful info:
> - if I hold Start while a game is running in the BSNES emulator, and go into
>   Settings->Controls, the Kodi UI shows "Super Nintendo" under the controller
>   profile, and a picture of a SNES gamepad, but under the list of "Buttons"
>   it says "Nothing to map". I'd sorta expect the SNES gamepad buttons to be
>   listed there.

The controller mapping needs to be done in the main Kodi configuration
screen: System -> Input -> Configure attached controllers. You should
see "Super Nintendo" listed there.

J.

-- 
In case of nuclear attack, delete this message.

Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)

2023-04-24 Thread Jonathan McDowell

On Mon, Apr 24, 2023 at 12:55:04AM +0200, David Hedlund wrote:
> I filed this issue: https://github.com/libretro/RetroArch/issues/15210 --
> Should I close it or merge it to Debian?
> 
> I'll close it if the "Update Assets" entry has been removed from the
> retroarch package in Debian.

Your report there appears to be about Ubuntu, and I can't comment on
what they do. The Debian package explicitly disables the "Update Assets"
option, because it doesn't make sense to allow a random program to
update something that's been installed from a .deb

J.

-- 
...  you should see the damage a bear on fire can do to a rack
of switches.

Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)

2023-04-23 Thread Jonathan McDowell

On Sun, Apr 23, 2023 at 01:39:51PM +0200, David Hedlund wrote:
> On 2023-04-23 13:04, Jonathan McDowell wrote:
> > On Fri, Apr 21, 2023 at 07:37:44PM +0200, David Hedlund wrote:
> > > On 2023-04-21 19:00, Jonathan McDowell wrote:
> > > > On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote:
> > > > > Package: retroarch-assets
> > > > > Version: 1.3.6+git20160731+dfsg1-2
> > > > > 
> > > > > Open the attached Debian_11_Stable.png screenshot. As you can see, 
> > > > > these
> > > > > icons are missing:
> > > > > 
> > > > ...
> > > > > This issue has been fixed in:
> > > > > 
> > > > > Debian 11 Testing (see attached screenshot)
> > > > > Package: retroarch
> > > > > Version: 1.14.0+dfsg-1
> > > > > Package: retroarch-assets
> > > > > Version: 1.7.6+git20221024+dfsg-2
> > > > Yes, that's expected. The retroarch-assets package in bullseye was
> > > > extremely dated and this has been corrected for bookworm.
> > > > 
> > > Thanks. This bug is marked as solved, why aren't these two PNG files going
> > > to be added to the stable retroarch-assets package?
> > Debian generally doesn't update packages in the stable release unless
> > there's a security issue or a serious functionality issue. While it
> > might be a minor fix here it's also primarily a cosmetic issue.
> > 
> Thanks. Personally, I think the lack of these icons in this stable package
> release make it look unstable, because it's on the main interface. Don't you
> agree?

I don't agree this is a critical enough bug to roll out to stable (bullseye),
even if we weren't so close to releasing bookworm. retroarch in bullseye
is not in great shape, but I believe I have resolved that for bookworm.

J.

-- 
/-\ | Let's not go there.
|@/  Debian GNU/Linux Developer |
\-  |

Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)

2023-04-23 Thread Jonathan McDowell

On Fri, Apr 21, 2023 at 07:37:44PM +0200, David Hedlund wrote:
> On 2023-04-21 19:00, Jonathan McDowell wrote:
> > On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote:
> > > Package: retroarch-assets
> > > Version: 1.3.6+git20160731+dfsg1-2
> > > 
> > > Open the attached Debian_11_Stable.png screenshot. As you can see, these
> > > icons are missing:
> > > 
> > ...
> > > This issue has been fixed in:
> > > 
> > > Debian 11 Testing (see attached screenshot)
> > > Package: retroarch
> > > Version: 1.14.0+dfsg-1
> > > Package: retroarch-assets
> > > Version: 1.7.6+git20221024+dfsg-2
> > Yes, that's expected. The retroarch-assets package in bullseye was
> > extremely dated and this has been corrected for bookworm.
> > 
> Thanks. This bug is marked as solved, why aren't these two PNG files going
> to be added to the stable retroarch-assets package?

Debian generally doesn't update packages in the stable release unless
there's a security issue or a serious functionality issue. While it
might be a minor fix here it's also primarily a cosmetic issue.

J.

-- 
///\oo/\\\ There are no more bugs. ///\oo/\\\ ///\oo/\\\

Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)

2023-04-21 Thread Jonathan McDowell

Control: forcemerge 926811 -1

On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote:
> Package: retroarch-assets
> Version: 1.3.6+git20160731+dfsg1-2
> 
> Open the attached Debian_11_Stable.png screenshot. As you can see, these
> icons are missing:
> 
...
> 
> This issue has been fixed in:
> 
> Debian 11 Testing (see attached screenshot)
> Package: retroarch
> Version: 1.14.0+dfsg-1
> Package: retroarch-assets
> Version: 1.7.6+git20221024+dfsg-2

Yes, that's expected. The retroarch-assets package in bullseye was
extremely dated and this has been corrected for bookworm.

J.

-- 
Web [  I am a passenger.   ]
site: https:// [  ]  Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24

Bug#1034524: libretro-bsnes-mercury: uses invalid architecture wildcards

2023-04-18 Thread Jonathan McDowell

Control: severity -1 important

On Mon, Apr 17, 2023 at 05:32:06PM +0100, Graham Inggs wrote:
> Source: libretro-bsnes-mercury
> Version: 094+git20220807-6
> Severity: serious
> 
> Hi Maintainer
> 
> Since the upload of 094+git20220807-6, the
> kodi-game-libretro-bsnes-mercury-* binary packages are no longer built
> on armel and armhf [1][2][3].  This is due to the use of invalid
> architecture wildcards 'any-armel' and 'any-armhf'.  These should be
> replaced by 'any-arm' for each of three

This is an unfortunate mistake on my part, but given the stage we're at
in the release process, the fact these are leaf packages and the fact
the packages didn't ship as part of bullseye I don't think this counts
as release critical.

> kodi-game-libretro-bsnes-mercury-* binary packages in debian/control,
> as follows:
> 
> -Architecture: any-amd64 any-arm64 any-armel any-armhf any-i386
> any-powerpc any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64
> 
> +Architecture: any-amd64 any-arm64 any-arm any-i386 any-powerpc
> any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64
> 
> Regards
> Graham
> 
> 
> [1] 
> https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-accuracy
> [2] 
> https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-balanced
> [3] 
> https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-performance

J.

-- 
... If we sleep together, will you like me better?

Bug#1032731: Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback'

2023-03-11 Thread Jonathan McDowell

Package: trezor
Version: 0.12.4-1
Severity: grave
X-Debbugs-Cc: nood...@earth.li
Control: forwarded -1 https://github.com/trezor/trezor-firmware/issues/2199

Installed trezor and tried to run it, got a traceback:

$ trezorctl 
Traceback (most recent call last):
  File "/usr/bin/trezorctl", line 33, in 
sys.exit(load_entry_point('trezor==0.12.4', 'console_scripts', 
'trezorctl')())
 ^^
  File "/usr/bin/trezorctl", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/trezorlib/cli/trezorctl.py", line 171, 
in 
@cli.resultcallback()
 ^^
AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback'. Did 
you mean: 'result_callback'?

Looks like this is an issue with the Click usage and was fixed upstream in 
0.13.1.

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

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

Versions of packages trezor depends on:
ii  python3 3.11.2-1
ii  python3-trezor  0.12.4-1

trezor recommends no packages.

trezor suggests no packages.

-- no debconf information

Bug#1032246: unblock: sg3-utils/1.46-3

2023-03-02 Thread Jonathan McDowell

On Thu, Mar 02, 2023 at 03:23:01PM +0100, Paul Gevers wrote:
> On 02-03-2023 10:30, Jonathan McDowell wrote:
> > This is a prerequest, before uploading to unstable. The package has
> > already passed through NEW and is available in experimental.
> 
> Thanks.
> 
> > -Package: libsgutils2-2
> > +Package: libsgutils2-1.46-2
> >   Section: libs
> >   Depends: ${shlibs:Depends}, ${misc:Depends}
> >   Architecture: any
> > -Conflicts: libsgutils2
> > -Replaces: libsgutils2
> > +Conflicts: libsgutils2-2 (= 1.46-1)
> > +Replaces: libsgutils2-2 (= 1.46-1)
> 
> Any specific reason why this is a Conflicts and not a Breaks, other than
> that was what was already there?
> 
> Feel free to upload with either Conflicts or Breaks.

Yeah, I don't think there's any compelling reason to keep it as a
Conflicts, so I've downgraded it to a Breaks and uploaded 1.46-3 to
unstable.

J.

-- 
I know the feeling, that perfect feeling


signature.asc
Description: PGP signature

Bug#1032246: unblock: sg3-utils/1.46-3

2023-03-02 Thread Jonathan McDowell

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sg3-ut...@packages.debian.org
Control: affects -1 + src:sg3-utils
Control: block 1031927 by -1 

Please unblock package sg3-utils.

This is a prerequest, before uploading to unstable. The package has
already passed through NEW and is available in experimental.

[ Reason ]

The libsgutils2-2 package contains a library, libsgutils, which has
started embedding the package version in the library name since the
1.45 release upstream. This means that if we ship sg3-utils as is we'll
end up shipping libsgutils2-2 in bookworm containing a different soname
than libsgutils2-2 in bullseye.

Note this will require rebuilds of the rdepends of libsgutils2-2 which
appear to be:

  tableau-parm
  ledmon
  libgpod

I *think* the appropriate transition rule is:

title = "sg3-utils";
is_affected = .depends ~ "libsgutils2-2" | .depends ~ "libsgutils2-1.46-2";
is_good = .depends ~ "libsgutils2-1.46-2";
is_bad = .depends ~ "libsgutils2-2";


[ Impact ]

If not permitted then we'll end up with potential problems for the rdeps
of libsgutils2-2 during upgrades.


[ Tests ]

There is no functional code change here, just a package rename. It has
been confirmed that:

 * It will not co-exist with the libsgutils2-2 package in bookworm
   (thanks to the versioned breaks/replaces)
 * It will co-exist with the libsgutils2-2 package in bullseye
   (which is 1.45-1 and has no overlapping files)
 * Operation of the sg3-utils package with this new build is fine


[ Risks ]

If we don't update this in bookworm we run the risk of soname skew.


[ Checklist ] (TBD)

 [x] All changes are documented in the d/changelog
 [x] I have reviewed all changes and I approve them
 [x] attach diff against the package in testing

TBD:

unblock sg3-utils/1.46-3

diff --git a/debian/changelog b/debian/changelog
index 6aeaa17..9ba46b1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+sg3-utils (1.46-3) unstable; urgency=medium
+
+  * Upload to unstable
+
+ -- Jonathan McDowell   Thu, 02 Mar 2023 09:13:12 +
+
+sg3-utils (1.46-2) experimental; urgency=medium
+
+  [ Debian Janitor ]
+  * Use secure URI in Homepage field.
+
+  [ Jonathan McDowell ]
+  * Rename libsgutils2-2 package to include package version (Closes: #994758)
+
+ -- Jonathan McDowell   Wed, 01 Mar 2023 09:24:47 +
+
 sg3-utils (1.46-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --git a/debian/control b/debian/control
index 71b7c6d..5ed0768 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Ritesh Raj Sarraf 
 Uploaders: Jonathan McDowell 
 Build-Depends: debhelper-compat (= 13), libtool, libcam-dev [kfreebsd-any], 
dpkg-dev (>= 1.16.1~)
 Standards-Version: 4.5.1
-Homepage: http://sg.danny.cz/sg/
+Homepage: https://sg.danny.cz/sg/
 Vcs-Git: https://salsa.debian.org/linux-blocks-team/sg3-utils.git
 Vcs-Browser: https://salsa.debian.org/linux-blocks-team/sg3-utils
 
@@ -24,12 +24,12 @@ Description: utilities for devices using the SCSI command 
set
  between supported SCSI and ATA commands and utility names in this package
  see the COVERAGE file.
 
-Package: libsgutils2-2
+Package: libsgutils2-1.46-2
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Architecture: any
-Conflicts: libsgutils2
-Replaces: libsgutils2
+Conflicts: libsgutils2-2 (= 1.46-1)
+Replaces: libsgutils2-2 (= 1.46-1)
 Suggests: sg3-utils
 Multi-Arch: same
 Description: utilities for devices using the SCSI command set (shared 
libraries)
@@ -47,7 +47,7 @@ Description: utilities for devices using the SCSI command set 
(shared libraries)
 Package: libsgutils2-dev
 Section: libdevel
 Architecture: any
-Depends: libsgutils2-2 (= ${binary:Version}), ${shlibs:Depends}, 
${kfreebsd:Depends}, ${misc:Depends}
+Depends: libsgutils2-1.46-2 (= ${binary:Version}), ${shlibs:Depends}, 
${kfreebsd:Depends}, ${misc:Depends}
 Conflicts: libsgutils1-dev
 Suggests: sg3-utils
 Multi-Arch: same
diff --git a/debian/libsgutils2-2.install b/debian/libsgutils2-1.46-2.install
similarity index 100%
rename from debian/libsgutils2-2.install
rename to debian/libsgutils2-1.46-2.install
diff --git a/debian/libsgutils2-2.symbols b/debian/libsgutils2-1.46-2.symbols
similarity index 99%
rename from debian/libsgutils2-2.symbols
rename to debian/libsgutils2-1.46-2.symbols
index f161c52..8d05b85 100644
--- a/debian/libsgutils2-2.symbols
+++ b/debian/libsgutils2-1.46-2.symbols
@@ -1,4 +1,4 @@
-libsgutils2-1.46.so.2 libsgutils2-2 #MINVER#
+libsgutils2-1.46.so.2 libsgutils2-1.46-2 #MINVER#
  check_pt_file_handle@Base 1.43
  clear_scsi_pt_obj@Base 1.27
  construct_scsi_pt_obj@Base 1.27
diff --git a/debian/libsgutils2-2.symbols.kfreebsd 
b/debian/libsgutils2-1.46-2.symbols.kfreebsd
similarity index 98%
rename from debian/libsgutils2-2.symbols.kfreebsd
rename to debian/libsgutils2-1.46-2.symbols.kfreebsd
index ef2c062..748424b 100

Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore

2023-03-01 Thread Jonathan McDowell

On Wed, Mar 01, 2023 at 08:07:09AM +, Jonathan McDowell wrote:
> On Mon, Feb 27, 2023 at 09:11:46PM +0100, Paul Gevers wrote:
> > On 25-02-2023 14:30, Adrian Bunk wrote:
> > > With the bookworm-ignore for #994758,
> > 
> > I'll admit that I misjudged that bug; with this message I'll clear the
> > bookworm-ignore tag.
> > 
> > > bullseye and bookworm
> > > will ship libsgutils2-2 packages with different so-name.
> > 
> > Although the transition freeze has started long time ago, it seems that
> > doing a proper transition is the best way to fix this issue. If somebody is
> > up to the task to prepare the upload, we can ask ftp-master to process the
> > upload swiftly. (Please upload to experimental to avoid the ftp-master from
> > rejecting the package immediately and to enable reviewing if that's not done
> > before the upload.)
> 
> This does not look overly hard and I have some familiarity with the
> package having uploaded in the past. If no one else is already looking
> at it I'll aim to have a version with a libsgutils2-1.46 library package
> uploaded to experimental by the end of today.

Now sitting in NEW for experimental:

https://ftp-master.debian.org/new/sg3-utils_1.46-2.html

I have confirmed:

 * It will not co-exist with the libsgutils2-2 package in bookworm
   (thanks to the versioned breaks/replaces)
 * It will co-exist with the libsgutils2-2 package in bullseye (which is
   1.45-1 and has no overlapping files)
 * Operation of the sg3-utils package with this new build

It turns out I do not have access to the salsa git repo at present, but
I've requested it and will push the changes there when it is granted.

J.

-- 
No one told you when to run, you missed the starting gun.
This .sig brought to you by the letter L and the number 39
Product of the Republic of HuggieTag


signature.asc
Description: PGP signature

Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore

2023-03-01 Thread Jonathan McDowell

On Mon, Feb 27, 2023 at 09:11:46PM +0100, Paul Gevers wrote:
> Control: tags 994758 - bookworm-ignore
> 
> Hi Adrian,
> 
> Thanks for caring.
> 
> On 25-02-2023 14:30, Adrian Bunk wrote:
> > With the bookworm-ignore for #994758,
> 
> I'll admit that I misjudged that bug; with this message I'll clear the
> bookworm-ignore tag.
> 
> > bullseye and bookworm
> > will ship libsgutils2-2 packages with different so-name.
> 
> Although the transition freeze has started long time ago, it seems that
> doing a proper transition is the best way to fix this issue. If somebody is
> up to the task to prepare the upload, we can ask ftp-master to process the
> upload swiftly. (Please upload to experimental to avoid the ftp-master from
> rejecting the package immediately and to enable reviewing if that's not done
> before the upload.)

This does not look overly hard and I have some familiarity with the
package having uploaded in the past. If no one else is already looking
at it I'll aim to have a version with a libsgutils2-1.46 library package
uploaded to experimental by the end of today.

J.

-- 
/-\ |   If at first you don't succeed,
|@/  Debian GNU/Linux Developer |   create an "NT" version.
\-  |


signature.asc
Description: PGP signature

Bug#1027903: Co-maintainer access

2023-01-22 Thread Jonathan McDowell

On Sun, Jan 22, 2023 at 03:15:08PM +, Vasyl Gello wrote:
> Thanks for packaging this one!

Thanks for all the work you do on Kodi!

> Is it OK for you to move the Salsa repo to of kodi-game-libretro
> to  https://salsa.debian.org/multimedia-team/kodi-media-center ?
> Then all Kodi stuff will be in one place :)
> 
> If you dont want to move it, please grant me the co-maintainer
> access so I can keep the addon in sync with all others.

There are a whole bunch of kodi-game-libretro-* packages I'm hoping to
add (I just updated libretro-bsnes with the first set) that will all
live under libretro/ in the games-team, so I think it makes more sense
for kodi-game-libretro to live alongside those. However I'm happy to
grant you access to the repo - what's your Salsa username?

J.

-- 
/-\ |  "This sentence no verb." -- Robin
|@/  Debian GNU/Linux Developer |  Stevens, ox.talk
\-  |

Bug#1027903: ITP: kodi-game-libretro -- Libretro compatibility layer for the Kodi Game API

2023-01-04 Thread Jonathan McDowell

Package: wnpp
Severity: wishlist
Owner: Jonathan McDowell 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-devel-ga...@lists.debian.org, debian-multime...@lists.debian.org, 
nood...@earth.li

* Package name: kodi-game-libretro
  Version : 20.2.0
* URL : https://github.com/kodi-game/game.libretro
* License : GPL
  Programming Lang: C++
  Description : Libretro compatibility layer for the Kodi Game API

This add-on provides a wrapper that allows Libretro cores to be loaded
as game add-ons within Kodi. Libretro cores are shared libraries that
use the Libretro API, so the wrapper is responsible for translating
function calls between the Libretro API and the Kodi Game API.

I plan to maintain this as part of the Debian Games team - while Kodi is
under the Multimedia team the only requirement from that side is the
kodi-addons-dev package.

Bug#1027741: Add retroarch-dev package with includes

2023-01-02 Thread Jonathan McDowell

Package: retroarch
Severity: wishlist

The libretro-common/ subdirectory has various bits of use to libretro
emulators and users (e.g the Kodi wrapper). It would be useful to have a
libretro-dev or retroarch-dev that at least has the include files in it.

J.

-- 
101 things you can't have too much of : 1 - Cable ties.
This .sig brought to you by the letter A and the number 33
Product of the Republic of HuggieTag

Bug#1027427: ITP: rcheevos -- RetroAchievements helper library for game emulators

2022-12-31 Thread Jonathan McDowell

Package: wnpp
Severity: wishlist
Owner: Jonathan McDowell 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-devel-ga...@lists.debian.org, nood...@earth.li

* Package name: rcheevos
  Version : 10.5.0
* URL : https://github.com/RetroAchievements/rcheevos
* License : MIT
  Programming Lang: C
  Description : RetroAchievements helper library for game emulators

rcheevos is a set of C code, or a library if you will, that tries to make it
easier for emulators to process RetroAchievements data, providing support for
achievements and leader boards for their players.

Keep in mind that rcheevos does not provide HTTP network connections. Clients
must get data from RetroAchievements, and pass the response down to rcheevos
for processing.

Not all structures defined by rcheevos can be created via the public API, but
are exposed to allow interactions beyond just creation, destruction, and
testing, such as the ones required by UI code that helps to create them.

Finally, rcheevos does not allocate or manage memory by itself. All structures
that can be returned by it have a function to determine the number of bytes
needed to hold the structure, and another one that actually builds the
structure using a caller-provided buffer to bake it.


At present rcheevos does not build a dynamic library, so my plan is to
package the header files and a static .a in librcheevos-dev. It is
currently embedded in the retroarch package, but is also required by the
Kodi libretro wrapper, which I am working on.

I plan to maintain this as part of the Debian Games team.

Bug#1024874: debian-keyring: gnupg files make lintian generate hundreds of warnings

2022-11-27 Thread Jonathan McDowell

On Sun, Nov 27, 2022 at 11:45:31AM +0100, Gioele Barabucci wrote:
> Package: debian-keyring
> Version: 2022.11.26
> Severity: minor
> Tags: patch
> 
> lintian v2.115.3 generates hundreds of spurious warnings related to the
> extension of gpg files and their content (long lines).
> 
> The attached patch adds the appropriate lintian-overrides files to silence
> these warnings.

This seems like at least partly a lintian issue. *.gpg for OpenPGP is
far from uncommon, so I don't believe debian/lintian-overrides is
appropriate here; lintian should know to ignore such files.

For the source override we're not using the file extension, but 'file'
can clearly detect the files as being OpenPGP keyrings and there's no
common file extension that would suggest a text file, so again I think
lintian is being over zealous here.

J.

-- 
Web [   She's the one for me. She's all I really need, oh yeah.]
site: https:// [  ]  Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24

Bug#1021344: Please stop failing DM ACL changes based on debian-keyring package

2022-10-06 Thread Jonathan McDowell

Package: dput-ng

The dcut command in dput-ng makes use of the debian-keyring package to
verify that modifications to DM access permissions are valid. This is
the wrong thing to do; the package is not actually what the
infrastructure is using and even if it was then you would be making the
tool only useful on sid.

As it is we do not reliably update the package every time we do a
keyring update, only concentrating on ensuring freshness around release
time. If you feel the need to fail hard if the key is not in the active
keyring then you should be rsyncing the active keyring from
keyring.debian.org. Otherwise I suggest the check is change to be purely
advisory.

J.

-- 
101 things you can't have too much of : 32 - Answers.
This .sig brought to you by the letter R and the number 12
Product of the Republic of HuggieTag

Bug#1009751: onak's keyd uses 100% CPU

2022-05-23 Thread Jonathan McDowell

On Wed, May 18, 2022 at 01:04:37PM +0200, Marc SCHAEFER wrote:
> Hello,
> 
> it looks like with sid's version 0.6.1-1 the problem has disappeared.

That's good to know; I'd been trying to find the time to setup an i386
chroot so I could try the database files you'd sent but done so yet.

> Architecture: i386
> Version: 0.6.1-1
> 
> patch /etc/onak.ini
> 11,12c11,14
> < use_keyd=false
> < sock_dir=/run
> ---
> > use_keyd=true
> > ;sock_dir=/var/run
> > ;sock_dir=/run
> > sock_dir=/var/lib/onaka
> 
> The initially configured sock_dir=/run misses the permissions for user
> onak. Doesn't hurt much.

Ah, I think I've seen something similar myself. Will try to get that
sorted.

J.

-- 
Web [   What's the worse that could happen?  Smoke. - Anonymous]
site: https:// [ HWHacker ]  Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24

Bug#1010689: Crashes with "malloc(): invalid next size (unsorted)"

2022-05-07 Thread Jonathan McDowell

On Sat, May 07, 2022 at 11:54:07AM +0100, Jonathan McDowell wrote:
> Package: libtpm2-pkcs11-1
> Version: 1.7.0-1
> Severity: important
> X-Debbugs-Cc: nood...@earth.li
> 
> I've upgraded my system from bullseye to bookworm today and as a result 
> libtpm2-pkcs11-1 has gone from 1.5.0-4 to 1.7.0-1. I'm now unable to use
> the library with SSH:
> 
> | noodles@sevai:~$ ssh the.earth.li 
> | malloc(): invalid next size (unsorted)
> | Aborted

Downgrading to 1.5.0-4 (no other package changes) makes things work
again, fwiw.

J.

-- 
   Suburbia: where they tear out   |  .''`.  Debian GNU/Linux Developer
   the trees & then name streets   | : :' :  Happy to accept PGP signed
after them.| `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Bug#1010689: Crashes with "malloc(): invalid next size (unsorted)"

2022-05-07 Thread Jonathan McDowell

Package: libtpm2-pkcs11-1
Version: 1.7.0-1
Severity: important
X-Debbugs-Cc: nood...@earth.li

I've upgraded my system from bullseye to bookworm today and as a result 
libtpm2-pkcs11-1 has gone from 1.5.0-4 to 1.7.0-1. I'm now unable to use
the library with SSH:

| noodles@sevai:~$ ssh the.earth.li 
| malloc(): invalid next size (unsorted)
| Aborted

Commenting out the:

PKCS11Provider /usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1

line in my .ssh/config makes things work fine. I ran ssh under GDB and
got the following backtrace:

debug1: Connection established.
malloc(): invalid next size (unsorted)

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x77a3f546 in __GI_abort () at abort.c:79
#2  0x77a96eb8 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x77bb4a78 "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#3  0x77a9e91a in malloc_printerr (
str=str@entry=0x77bb7418 "malloc(): invalid next size (unsorted)") at 
malloc.c:5628
#4  0x77aa1d2c in _int_malloc (av=av@entry=0x77bebba0 , 
bytes=bytes@entry=1536)
at malloc.c:3964
#5  0x77aa3364 in __GI___libc_malloc (bytes=1536) at malloc.c:3229
#6  0x772735ab in yaml_document_initialize () from 
/lib/x86_64-linux-gnu/libyaml-0.so.2
#7  0x775049ab in emit_attributes_to_string () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#8  0x7750213f in _db_update_tobject_attrs () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#9  0x775027c1 in ?? () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#10 0x77503a37 in db_new () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#11 0x774fdb70 in backend_init () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#12 0x775065e6 in general_init () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#13 0x774f7438 in C_Initialize () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#14 0x555e0bc5 in ?? ()
#15 0x5556309f in ?? ()
#16 0x77a407fd in __libc_start_main (main=0xf960, argc=3, 
argv=0x7fffe1f8, 
init=, fini=, rtld_fini=, 
stack_end=0x7fffe1e8)
at ../csu/libc-start.c:332
#17 0x5556487a in ?? ()
(gdb) 


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

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

Versions of packages libtpm2-pkcs11-1 depends on:
ii  libc6 2.33-7
ii  libsqlite3-0  3.38.3-1
ii  libssl1.1 1.1.1n-1
ii  libtss2-esys-3.0.2-0  3.2.0-1
ii  libtss2-mu0   3.2.0-1
ii  libtss2-rc0   3.2.0-1
ii  libtss2-tctildr0  3.2.0-1
ii  libyaml-0-2   0.2.2-1

libtpm2-pkcs11-1 recommends no packages.

libtpm2-pkcs11-1 suggests no packages.

-- no debconf information

Bug#1009751: onak's keyd uses 100% CPU

2022-04-25 Thread Jonathan McDowell

On Sat, Apr 16, 2022 at 10:11:52AM +0200, Marc SCHAEFER wrote:
> Package: onak
> Version: 0.5.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> on a buster system, keyd uses 100% CPU:
> 
> onak 30318 98.6  0.0   8864  4884 ?Rs   08:04   5:39 
> /usr/sbin/keyd -f
> 
> vz15:~# strace -p 30318 2>&1 | head -20
> strace: Process 30318 attached
> _newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
> accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
...
> This is in a LXC container running also on a buster host kernel 
> 4.19.0-17-amd64.
> 
> Any idea what I should try?

Is this a fresh install? I've not seen that behaviour before. I suspect
FD 3 is the keyd socket (in ${sock_dir}/keyd.sock), but if it couldn't
be opened then keyd should have failed to start rather than busy waiting
on the FD.

Anything in the onak.log file?

J.

-- 
Do not expose this tagline to direct sunlight.
This .sig brought to you by the letter W and the number  1
Product of the Republic of HuggieTag

Bug#1008870: [Pkg-electronics-devel] Bug#1008870: openocd: segfault when using stm32f1x config

2022-04-20 Thread Jonathan McDowell

On Sun, Apr 03, 2022 at 12:26:05PM +0300, Matsievskiy S.V. wrote:
> Package: openocd
> Version: 0.11.0-1
> Severity: important
> X-Debbugs-Cc: seregaxvm.m...@gmail.com
> 
> Dear Maintainer,
> 
> OpenOCD segfaults when using target/stm32f1x.cfg configuration. I do not
> experience this issue with newer version built from source (Open On-Chip
> Debugger 0.11.0+dev-02226-gf6ffede8b).
> 
> dmesg entry:
> [ 7388.531636] openocd[36055]: segfault at 14 ip 7f64e097b12d sp
> 7ffdde27a090 error 4 in libusb-1.0.so.0.3.0[7f64e0974000+f000]
> 
> Way to reproduce:
> 1. Connect STLinkV2
> 2. Run command openocd -f openocd.cfg (file is attached)

I don't have STLinkV2 hardware so am unable to reproduce. Can you
confirm the upstream git version you're using - I don't see "f6ffede8b"
in the usptream git tree.

Also, if you're able to, can you try recompiling the 0.11.0 Debian
package on your system just to narrow down that it's a fix upstream
we're looking for rather than a build issue? I *think* it's going to be
cff0e417da58adef1ceef9a63a99412c2cc87ff3 that's the issue, which means
the problem won't exist in bullseye (libusb-1.0 is at 1.0.24).

J.

-- 
"Time for bed" said Zebedee.  "Yours or mine" said Florence.

Bug#1007999: debian-keyring: New release?

2022-03-21 Thread Jonathan McDowell

On Sun, Mar 20, 2022 at 12:00:07PM +0100, Bastian Germann wrote:
> Package: debian-keyring
> Version: 2021.12.24
> 
> There are tags in debian-keyring's git repo for 2022.01.25 and 2022.02.24 
> releases.
> They were never uploaded. Is there any problem? Please think about releasing 
> a new version.

The active keyring does not relate to the package version in the
archive. These monthly, tagged, updates have all been pushed to the
active infrastructure even if they were not uploaded to the archive.

Are you observing some problem that caused you to raise this bug? You
might find:

https://keyring.debian.org/keyring-workflow.html

an useful read, and if you're working with the keyring for some reason
then the most up-to-date keyrings are available via rsync:

rsync -az --progress keyring.debian.org::keyrings/keyrings/ .

(there is a signed checksum file in there to allow you to validate the
retrieved data)

J.

-- 
101 things you can't have too much of : 29 - T-shirts.

Bug#996750: Causes external monitor to fail to wake from DPMS sleep

2021-10-18 Thread Jonathan McDowell

Package: pipewire
Version: 0.3.38-2
Severity: important
X-Debbugs-Cc: nood...@earth.li

I recently tried out pipewire as my system audio daemon; in particular I
installed pipewire-pulse so that it would take over from Pulse Audio.
While audio ends up working just fine it turns out this breaks waking up
my external monitor. As part of screen lock both the internal laptop LCD
and external LCD monitor are powersaved via DPMS. A mouse/keyboard event
will then wake both up and present the lock screen. When pipewire-pulse
is installed the internal LCD wakes up fine, but the external screen
does not. It looks like xrandr etc all think the external screen is
connected ok, but it takes a press of the monitor menu/power button to
wake it up.

The screen is connected via HDMI and is acting as my main audio output,
so I suspect there's some sort of odd interaction going on with that,
but the same setup with Pulse does not have any such issues.

edid-decode of the external monitor attached, in case that's helpful.

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pipewire depends on:
ii  init-system-helpers  1.60
ii  libpipewire-0.3-modules  0.3.38-2
ii  pipewire-bin 0.3.38-2

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information
edid-decode (hex):

00 ff ff ff ff ff ff 00 1e 6d f6 76 80 9b 03 00
04 1a 01 03 80 50 22 78 ea ca 95 a6 55 4e a1 26
0f 50 54 21 08 00 71 40 81 80 81 c0 a9 c0 b3 00
d1 c0 81 00 01 01 e7 7c 70 a0 d0 a0 29 50 30 20
3a 00 20 4f 31 00 00 1a 9d 67 70 a0 d0 a0 22 50
30 20 3a 00 20 4f 31 00 00 1a 00 00 00 fd 00 38
3d 1e 5a 20 00 0a 20 20 20 20 20 20 00 00 00 fc
00 4c 47 20 55 4c 54 52 41 57 49 44 45 0a 01 f4

02 03 1e f1 23 09 07 07 49 10 04 03 01 1f 13 59
5a 12 83 01 00 00 67 03 0c 00 10 00 38 40 9f 3d
70 a0 d0 a0 15 50 30 20 3a 00 20 4f 31 00 00 1a
7e 48 00 e0 a0 38 1f 40 40 40 3a 00 20 4f 31 00
00 18 01 1d 00 72 51 d0 1e 20 6e 28 55 00 20 4f
31 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00
20 4f 31 00 00 18 00 00 00 ff 00 36 30 34 4e 54
4c 45 36 59 34 31 36 0a 00 00 00 00 00 00 00 23



Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
Manufacturer: GSM
Model: 30454
Serial Number: 236416
Made in: week 4 of 2016
  Basic Display Parameters & Features:
Digital display
Maximum image size: 80 cm x 34 cm
Gamma: 2.20
DPMS levels: Standby Suspend Off
RGB color display
First detailed timing is the preferred timing
  Color Characteristics:
Red  : 0.6513, 0.3320
Green: 0.3066, 0.6308
Blue : 0.1503, 0.0595
White: 0.3134, 0.3291
  Established Timings I & II:
DMT 0x04:   640x48059.940 Hz   4:331.469 kHz  25.175 MHz
DMT 0x09:   800x60060.317 Hz   4:337.879 kHz  40.000 MHz
DMT 0x10:  1024x76860.004 Hz   4:348.363 kHz  65.000 MHz
  Standard Timings:
GTF :  1152x86460.000 Hz   4:353.700 kHz  81.624 MHz
DMT 0x23:  1280x1024   60.020 Hz   5:463.981 kHz 108.000 MHz
DMT 0x55:  1280x72060.000 Hz  16:945.000 kHz  74.250 MHz
DMT 0x53:  1600x90060.000 Hz  16:960.000 kHz 108.000 MHz (RB)
DMT 0x3a:  1680x1050   59.954 Hz  16:10   65.290 kHz 146.250 MHz
DMT 0x52:  1920x1080   60.000 Hz  16:967.500 kHz 148.500 MHz
DMT 0x1c:  1280x80059.810 Hz  16:10   49.702 kHz  83.500 MHz
  Detailed Timing Descriptors:
DTD 1:  3440x1440   59.973 Hz  43:18   88.819 kHz 319.750 MHz (800 mm x 335 
mm)
 Hfront   48 Hsync  32 Hback  80 Hpol P
 Vfront3 Vsync  10 Vback  28 Vpol N
DTD 2:  3440x1440   49.987 Hz  43:18   73.681 kHz 265.250 MHz (800 mm x 335 
mm)
 Hfront   48 Hsync  32 Hback  80 Hpol P
 Vfront3 Vsync  10 Vback  21 Vpol N
  Display Range Limits:
Monitor ranges (GTF): 56-61 Hz V, 30-90 kHz H, max dotclock 320 MHz
Display Product Name: 'LG ULTRAWIDE'
  Extension blocks: 1
Checksum: 0xf4



Block 1, CTA-861 Extension Block:
  Revision: 3
  Underscans IT Video Formats by default
  Basic audio support
  Supports YCbCr 4:4:4
  Supports YCbCr 4:2:2
  Native detailed modes: 1
  Audio Data Block:
Linear PCM:
  Max channels: 2
  Supported sample rates (kHz): 48 44.1 32
  Supported sample sizes (bits): 24 20 16
  Video Data Block:
VIC  16:  1920x1080   60.000 Hz  16:967.500 kHz 148.500 MHz
VIC   4:  1280x72060.000 Hz  16:945.000 kHz  74.250 MHz
VIC   3:   720x48059.940 Hz  16:931.469 kHz  27.000 MHz
VIC   1:   640x48059.940 Hz   4:331.469 kHz  25.175 MHz

Bug#994453: Hit with linux-image-5.14.0-1-amd64 on Ryzen 5 3500U

2021-09-28 Thread Jonathan McDowell

I've hit this issue with the linux-image-5.14.0-1-amd64 (5.14.6-2) that
has made its way to testing this week; symptom is grub never shows
anything after the loading the initrd message. earlycon=efifb and
earlyprintk=efi didn't give any extra output. mem_encrypt=off resulted
in a successful boot.

Hardware is a Ryzen 3 3500U laptop. It seems like this is a potential
interaction between the memory encryption and amdgpu?

J.

-- 
... "What's the philosophical difference between a killfile and the
automoderation?" "A killfile throws away good posts.  Automoderation
throws away bad posts." -- Jonathan H N Chin to Calle Dybedahl

Bug#994476: [Pkg-electronics-devel] Bug#994476: libserialport-0.1.1 fix on recent kernels

2021-09-16 Thread Jonathan McDowell

On Thu, Sep 16, 2021 at 11:12:32AM +, Esteve Varela wrote:
> Package: libserialport0
> Version: 0.1.1-4

Are you absolutely sure this version is correct? 0.1.1-4 should have the
fix you mention below, it's the only change over 0.1.1.-3:

https://salsa.debian.org/electronics-team/sigrok/libserialport/-/commit/4166546d99d7a830c445b8dbc79de595c71eead4

> Upstream bug report: https://sigrok.org/bugzilla/show_bug.cgi?id=1687
> Upstream fix to apply:
> https://sigrok.org/gitweb/?p=libserialport.git;a=commitdiff;h=6f9b03e597ea7200eb616a4e410add3dd1690cb1
> 
> Rationale:
> This issue makes the library inoperable on any recent kernel, even the
> current linux LTS version 5.10.46-4. Any program that opens a serial
> port using sp_open() will fail. If LIBSERIALPORT_DEBUG is set in the
> environment, the following relevant messages will appear:
> 
> sp: sp_open(0x55f7f28596b0, 0x3) called.
> sp: Opening port /dev/ttyACM0.
> sp: get_config(0x55f7f28596b0, 0x7ffc8c7459e0, 0x7ffc8c7459b0) called.
> sp: Getting configuration for port /dev/ttyACM0.
> sp: get_flow(3, 0x7ffc8c7459e0) called.
> sp: Getting advanced flow control.
> sp: sp_last_error_message() called.
> sp: sp_last_error_message returning Inappropriate ioctl for device.
> sp: get_flow returning SP_ERR_FAIL: Getting termiox failed:
> Inappropriate ioctl for device.
> sp: sp_free_error_message(Inappropriate ioctl for device) called.
> sp: sp_free_error_message returning.
> sp: get_config returning SP_ERR_FAIL.
> sp: sp_close(0x55f7f28596b0) called.
> sp: Closing port /dev/ttyACM0.
> sp: sp_close returning SP_OK.
> sp: sp_open returning SP_ERR_FAIL.
> 
> Kernel patch causing the change:
> https://www.spinics.net/lists/linux-serial/msg41926.html
> Lines causing the bug:
> https://sigrok.org/gitweb/?p=libserialport.git;a=blob;f=serialport.c;h=e6097eeda975f914ec7b960f72c9e2df546e8281;hb=HEAD#l1774

J.

-- 
] https://www.earth.li/~noodles/ []  Even the Evening Herald slags me  [
]  PGP/GPG Key @ the.earth.li[]off.[
] via keyserver, web or email.   [][
] RSA: 4096/0x94FA372B2DA8B985   [][

Bug#991821: unblock: debian-keyring/2021.07.26

2021-08-02 Thread Jonathan McDowell

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: keyring-ma...@debian.org

Please unblock package debian-keyring

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]

This is the usual request to unblock debian-keyring so that the most up
to date version of it can be included with the release. There was a
request for 2021.06.25 at the point it looked like we might just miss
this update, but this has got in with enough time to migrate.

[ Impact ]

If not unblocked then bullseye will ship with the June 2021 keyring
update.

[ Tests ]

N/A

[ Risks ]

This is a leaf package and there shouldn't be any risks associated with
including it in the release.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]

I have not included a debdiff as I do not believe it is useful in any
fashion for this request.

unblock debian-keyring/2021.07.26

J.

-- 
... "For the Limit, I will forgive all." -- David Damerell, afw.

Bug#990936: unblock: debian-keyring/2021.06.25

2021-07-11 Thread Jonathan McDowell

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: keyring-ma...@debian.org

Please unblock package debian-keyring

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]

This is the usual request to unblock debian-keyring so that the most up
to date version of it can be included with the release. There will
probably be another update just before the actual release, but not with
enough time to migrate cleanly (~ 24th July).

[ Impact ]

If not unblocked then bullseye will ship with the December 2020 keyring
update.

[ Tests ]

N/A

[ Risks ]

This is a leaf package and there shouldn't be any risks associated with
including it in the release.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]

I have not included a debdiff as I do not believe it is useful in any
fashion for this request.

unblock debian-keyring/2021.06.25

Bug#990893: unblock: libserialport/0.1.1-4

2021-07-11 Thread Jonathan McDowell

Control: tags -1 - moreinfo

On Sun, Jul 11, 2021 at 10:18:03AM +0200, Graham Inggs wrote:
> On Sat, 10 Jul 2021 at 19:03, Jonathan McDowell  wrote:
> > unblock libserialport/0.1.1-3
> 
> I'm assuming this bug was meant as a pre-approval request for 0.1.1-4.
> Please go ahead and upload to unstable, then remove the moreinfo tag
> once it has built.

It was, thanks. Now uploaded and built for all release archs.

J.

-- 
No program done by a hacker will work unless he is on the system.

Bug#990893: unblock: libserialport/0.1.1-3

2021-07-10 Thread Jonathan McDowell

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libserialport

[ Reason ]

I've been made aware in bug #990863 that linux 5.10.38-1, uploaded late
May, has removed support for termiox. This has broken the libserialport
package, which uses termiox when it's discovered.

(I'm aware this is extremely late in the release cycle, but the bug was
only raised yesterday.)

[ Impact ]

With the attached debdiff, taken from upstream, detection of termiox is
disabled and we fall back to the supported termios2.

[ Tests ]

Tim Small, the original reporter of the bug, has confirmed this fixes
the issue on bullseye.

[ Risks ]

Although the regression has been caused by a kernel update during the
freeze rather than any change to libserialport it seems that this is the
more correct fix and limits any risk only to users of the libserialport
package. Without the patch serial port usage via libserialport will
fail, so the package is entirely non-functional.

[ Checklist ]

  [x] all debian/ changes are documented in the d/changelog
  [x] I reviewed all debian/ changes and I approve them
  [x] attach debian/ diff against the package in testing

unblock libserialport/0.1.1-3

diff -Nru libserialport-0.1.1/debian/changelog 
libserialport-0.1.1/debian/changelog
--- libserialport-0.1.1/debian/changelog2018-05-18 09:44:24.0 
+0100
+++ libserialport-0.1.1/debian/changelog2021-07-10 17:21:59.0 
+0100
@@ -1,3 +1,10 @@
+libserialport (0.1.1-4) unstable; urgency=high
+
+  * Avoid the use of termiox now the kernel has dropped support for it.
+Thanks to Tim Small. (Closes: #990863)
+
+ -- Jonathan McDowell   Sat, 10 Jul 2021 17:21:59 +0100
+
 libserialport (0.1.1-3) unstable; urgency=medium
 
   * VCS is at Salsa.
diff -Nru libserialport-0.1.1/debian/patches/avoid-termiox.diff 
libserialport-0.1.1/debian/patches/avoid-termiox.diff
--- libserialport-0.1.1/debian/patches/avoid-termiox.diff   1970-01-01 
01:00:00.0 +0100
+++ libserialport-0.1.1/debian/patches/avoid-termiox.diff   2021-07-10 
17:20:33.0 +0100
@@ -0,0 +1,34 @@
+Subject: Don't even check for termiox
+Origin: 
https://sigrok.org/gitweb/?p=libserialport.git;a=commit;h=6f9b03e597ea7200eb616a4e410add3dd1690cb1
+Bug: https://sigrok.org/bugzilla/show_bug.cgi?id=1687
+Bug-Debian: https://bugs.debian.org/990863
+Author: Karl Palsson 
+Last-Update: 2021-07-10
+
+Don't check for termiox, as it has been remove from Linux in e0efb3168d34
+
+Some more information available in 
https://www.spinics.net/lists/linux-serial/msg41926.html
+
+Attempting to use the termiox ioctls on more modern kernels results in
+"Inappropriate IOCTL" errors.
+
+While the "right" solution might be to remove the termiox code from the
+linux path, simply not checking for termiox builds a libserialport that
+functions on modern linux kernels.
+
+diff --git a/configure.ac b/configure.ac
+index b1af16f..a26b851 100644
+--- a/configure.ac
 b/configure.ac
+@@ -112,7 +112,7 @@ AC_SYS_LARGEFILE
+ AC_TYPE_SIZE_T
+ 
+ # Check for specific termios structures.
+-AC_CHECK_TYPES([struct termios2, struct termiox],,,
++AC_CHECK_TYPES([struct termios2],,,
+   [[#include ]])
+ AC_CHECK_MEMBERS([struct termios.c_ispeed, struct termios.c_ospeed,
+   struct termios2.c_ispeed, struct termios2.c_ospeed],,,
+-- 
+2.30.2
+
diff -Nru libserialport-0.1.1/debian/patches/series 
libserialport-0.1.1/debian/patches/series
--- libserialport-0.1.1/debian/patches/series   2018-05-18 09:44:24.0 
+0100
+++ libserialport-0.1.1/debian/patches/series   2021-07-10 17:20:45.0 
+0100
@@ -1,2 +1,3 @@
 non-linux-build-fix.diff
 fix_for_alpha_where_BOTHER_is_not_defined.diff
+avoid-termiox.diff

Bug#990863: [Pkg-electronics-devel] Bug#990863: Bug#990863: libserialport0: libserialport tries to use termiox on bullseye, and fails to open serial ports

2021-07-10 Thread Jonathan McDowell

Control: tags -1 pending

On Fri, Jul 09, 2021 at 06:06:52PM +0100, Jonathan McDowell wrote:
> On Fri, Jul 09, 2021 at 05:55:52PM +0100, Tim Small wrote:
> > Package: libserialport0
> > Version: 0.1.1-3+b1
> > Severity: important
> > Tags: upstream patch
> > X-Debbugs-Cc: t...@seoss.co.uk
> > 
> > Serial port open seems to fail on bullseye.  Strace output follows:
> > 
> > 1512868 openat(AT_FDCWD, "/dev/ttyACM0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 9
> > 1512868 ioctl(9, TCGETS, {B9600 opost isig icanon echo ...}) = 0
> > 1512868 ioctl(9, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS]) = 0
> > 1512868 ioctl(9, TCGETX, 0x55cd7cc80df0) = -1 ENOTTY (Inappropriate ioctl 
> > for device)
> > 1512868 close(9)= 0
> > 1512868 write(2, "sr: ", 4) = 4
> > 1512868 write(2, "serial-libsp: Error opening port"..., 71) = 71
> > 1512868 write(2, "No devices found.\n", 18) = 18
> > 
> > Applying upstream commit 6f9b03e597ea fixes the issue.  I tested this
> > with:
> > 
> > /usr/local/bin/sigrok-cli --driver=rdtech-tc:conn=/dev/ttyACM0 --continuous
> > 
> > Patch here:
> > 
> > https://github.com/sigrokproject/libserialport/commit/6f9b03e597ea7200eb616a4e410add3dd1690cb1
> > 
> > I suspect that libserialport0 will fail to open all serial ports on
> > bullseye without this fix, so this bug may unfortunately be RC?
> 
> It looks like the kernel broke this in the v5.10.37 update
> (eef2158b0c44baa8cd9855091b1d99a35e16afdb), which hit
> unstable towards the end of May. Not clear why this was backported to
> the stable tree but I guess fixing libserialport is going to be the
> easier solution.

Fixed in
https://salsa.debian.org/electronics-team/sigrok/libserialport/-/tree/Bug990863
and unblock request sent to the release team; given we're so close to
release I'll understand entirely if this has to wait until the first
point release.

J.

-- 
101 things you can't have too much of : 53 - Space.

Bug#990863: [Pkg-electronics-devel] Bug#990863: libserialport0: libserialport tries to use termiox on bullseye, and fails to open serial ports

2021-07-09 Thread Jonathan McDowell

On Fri, Jul 09, 2021 at 05:55:52PM +0100, Tim Small wrote:
> Package: libserialport0
> Version: 0.1.1-3+b1
> Severity: important
> Tags: upstream patch
> X-Debbugs-Cc: t...@seoss.co.uk
> 
> Serial port open seems to fail on bullseye.  Strace output follows:
> 
> 1512868 openat(AT_FDCWD, "/dev/ttyACM0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 9
> 1512868 ioctl(9, TCGETS, {B9600 opost isig icanon echo ...}) = 0
> 1512868 ioctl(9, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS]) = 0
> 1512868 ioctl(9, TCGETX, 0x55cd7cc80df0) = -1 ENOTTY (Inappropriate ioctl for 
> device)
> 1512868 close(9)= 0
> 1512868 write(2, "sr: ", 4) = 4
> 1512868 write(2, "serial-libsp: Error opening port"..., 71) = 71
> 1512868 write(2, "No devices found.\n", 18) = 18
> 
> Applying upstream commit 6f9b03e597ea fixes the issue.  I tested this
> with:
> 
> /usr/local/bin/sigrok-cli --driver=rdtech-tc:conn=/dev/ttyACM0 --continuous
> 
> Patch here:
> 
> https://github.com/sigrokproject/libserialport/commit/6f9b03e597ea7200eb616a4e410add3dd1690cb1
> 
> I suspect that libserialport0 will fail to open all serial ports on
> bullseye without this fix, so this bug may unfortunately be RC?

It looks like the kernel broke this in the v5.10.37 update
(eef2158b0c44baa8cd9855091b1d99a35e16afdb), which hit
unstable towards the end of May. Not clear why this was backported to
the stable tree but I guess fixing libserialport is going to be the
easier solution.

J.

-- 
] https://www.earth.li/~noodles/ []  Minorities are the foundation of  [
]  PGP/GPG Key @ the.earth.li[]  society.  [
] via keyserver, web or email.   [][
] RSA: 4096/0x94FA372B2DA8B985   [][

Bug#980589: [Pkg-electronics-devel] Bug#980589: libsigrok: FTBFS: tests/strutil.c:157:2: error: too few arguments to function ‘_ck_assert_failed’

2021-01-21 Thread Jonathan McDowell

This is a result of the new "check" 0.15.2 package (updated from
0.12.0), in particular upstream commit
82540c5428d3818b64d6a8aefb601e722520651f:

https://github.com/libcheck/check/commit/82540c5428d3818b64d6a8aefb601e722520651f

"For users of these APIs who do pass a message there will
be a new warning about too many arguments."

Gee, thanks. These are deprecated functions so I'll look at getting
sigrok updated to use the new ones.

On Wed, Jan 20, 2021 at 09:28:27PM +0100, Lucas Nussbaum wrote:
> Source: libsigrok
> Version: 0.5.2-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210120 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > gcc -DHAVE_CONFIG_H   -Iinclude -I./include -I./src -I. 
> > -Ibindings/cxx/include -I./bindings/cxx/include -Ibindings/cxx 
> > -DFIRMWARE_DIR='"/usr/share/sigrok-firmware"' -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -std=c99 -fvisibility=hidden -Wall -Wextra 
> > -Wmissing-prototypes -pthread -I/usr/include/libftdi1 -I/usr/include/hidapi 
> > -I/usr/include/libusb-1.0 -I/usr/include/libmount -I/usr/include/blkid 
> > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -c -o tests/driver_all.o tests/driver_all.c
> > In file included from tests/strutil.c:21:
> > tests/strutil.c: In function ‘test_sr_vsnprintf_ascii’:
> > tests/strutil.c:63:4: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >63 |"Invalid result for '%s': len = %i.", expected, len);
> >   |^~~~
> > tests/strutil.c:65:4: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >65 |"Invalid result for '%s': %s.", expected, s);
> >   |^~
> > tests/strutil.c: In function ‘test_sr_vsprintf_ascii’:
> > tests/strutil.c:87:4: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >87 |"Invalid result for '%s': len = %i.", expected, len);
> >   |^~~~
> > tests/strutil.c:89:4: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >89 |"Invalid result for '%s': %s.", expected, s);
> >   |^~
> > tests/strutil.c: In function ‘test_samplerate’:
> > tests/strutil.c:100:7: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >   100 |   "Invalid result for '%s': %s.", expected, s);
> >   |   ^~
> > tests/strutil.c: In function ‘test_period’:
> > tests/strutil.c:111:7: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >   111 |   "Invalid result for '%s': %s.", expected, s);
> >   |   ^~
> > tests/strutil.c: In function ‘test_rational’:
> > tests/strutil.c:121:28: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >   121 |  fail_unless(ret == SR_OK, "Unexpected rc for '%s': %d, errno %d.",
> >   |^~~
> > tests/strutil.c:124:7: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >   124 |   "Invalid result for '%s': %ld/%ld'.",
> >   |   ^~~~
> > tests/strutil.c: In function ‘test_rational_fail’:
> > tests/strutil.c:134:28: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >   134 |  fail_unless(ret != SR_OK, "Unexpected success for '%s'.", input);
> >   |^~
> > tests/strutil.c: In function ‘test_voltage’:
> > tests/strutil.c:144:7: warning: too many arguments for format 
> > [-Wformat-extra-args]
> >   144 |   "Invalid result for '%s': %s.", expected, s);
> >   |   ^~
> > tests/strutil.c: In function ‘test_locale_fn’:
> > tests/strutil.c:157:2: error: too few arguments to function 
> > ‘_ck_assert_failed’
> >   157 |  ck_assert_msg(saved_locale != NULL);
> >   |  ^
> > /usr/include/check.h:505:27: note: declared here
> >   505 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, int 
> > line,
> >   |   ^
> > gcc -DHAVE_CONFIG_H   -Iinclude -I./include -I./src -I. 
> > -Ibindings/cxx/include -I./bindings/cxx/include -Ibindings/cxx 
> > -DFIRMWARE_DIR='"/usr/share/sigrok-firmware"' -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -std=c99 -fvisibility=hidden -Wall -Wextra 
> > -Wmissing-prototypes -pthread -I/usr/include/libftdi1 -I/usr/include/hidapi 
> > -I/usr/include/libusb-1.0 -I/usr/include/libmount -I/usr/include/blkid 
> > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -c -o

Bug#975199: [Pkg-electronics-devel] Bug#975199: pulseview: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONF

2020-11-19 Thread Jonathan McDowell

Control: severity -1 important

On Thu, Nov 19, 2020 at 10:47:32AM +0100, Lucas Nussbaum wrote:
> Source: pulseview
> Version: 0.4.2-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201119 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

I think this has managed to happen during the Python3.9 default
transition. In particular:

> > --   Package 'python-3.8-embed', required by 'libsigrokdecode', not found

libsigrokdecode has only just been updated to fix this, but it seems a
build-dep on python3-dev is not actually sufficient to tie the
versioning together for the -dev package i.e. the build dependency check
should have failed rather than it getting this far.

J.

-- 
Web [  101 things you can't have too much of : 31 - Hot showers.   ]
site: https:// [  ]  Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24

Bug#972769: Still fine in unstable

2020-11-06 Thread Jonathan McDowell

Control: severity -1 important
Control: tag -1 pending

This is still building fine with the python3-defaults in unstable so
doesn't warrant the serious severity. Upstream has a minor fix to enable
Python3.9 which I will pull in.

J.

-- 
/-\ | 101 things you can't have too much
|@/  Debian GNU/Linux Developer |   of : 18 - Roleplaying.
\-  |

Bug#862195: sendip: please make the build reproducible

2020-09-02 Thread Jonathan McDowell

Control: tags -1 + pending

On Tue, Sep 01, 2020 at 10:58:10PM -, Chris Lamb wrote:
> Dear Maintainer,
> 
> > Source: sendip
> > Version: 2.5-7
> > Tags: patch
> 
> There hasn't seem to be any update on this bug in 1210 days, in which
> time the Reproducible Builds effort has come on a long way.
> 
> Would you consider applying this patch and uploading?

That's, er, a perfectly reasonable request after such a long time. The
package needs some other cleanup, but I've applied your patch to the
current work:

https://salsa.debian.org/noodles/sendip/-/commit/c0757c237448e8d16d90084a73fd11b84bbead87

J.

-- 
Revd Jonathan McDowell, ULC | Shopping is hard. Let's do Math!

Bug#942091: Any progress on tpm2-pkcs11 package?

2020-04-24 Thread Jonathan McDowell

On Thu, Apr 23, 2020 at 10:24:13PM +0800, SZ Lin (林上智) wrote:
> Jonathan McDowell  於 2020年2月23日 週日 上午3:00寫道：
> > Just a gentle prod to see if there's any progress on a tpm2-pkcs11
> > package; I've downloaded tpm2-pkcs11-1.0.1 and it builds fine with the
> > pieces available in bullseye so it would be nice to get a proper package
> > available.
> 
> This package was packaged and uploaded to the NEW queue last month [1],
> let's wait for the review from the FTP master.

Great! I look forward to it getting through NEW.

> [1] https://ftp-master.debian.org/new/tpm2-pkcs11_1.1.0-1.html

J.

-- 
Too many freaks, not enough circuses.

Bug#958310: nm.debian.org: no mention what keyserver to use

2020-04-21 Thread Jonathan McDowell

On Mon, Apr 20, 2020 at 05:18:54PM +0200, Mattia Rizzolo wrote:
> On Mon, Apr 20, 2020 at 05:06:43PM +0200, Adam Borowski wrote:
> > On Mon, Apr 20, 2020 at 04:32:04PM +0200, Mattia Rizzolo wrote:
> > > On Mon, Apr 20, 2020 at 02:21:06PM +0200, Adam Borowski wrote:
> > > > Thus, this section would need to either:
> > > > * say where to upload the key to (--keyserver), or
> > > 
> > > Usually we use keyserver.ubuntu.com that still works decently, but
> > > keyring-maint might use something else, since they fetch the key
> > > indempendently.
> > 
> > Care to check that, so we know what to tell to new applicants?
> 
> Looking at keyring-maint's scripts, I *believe* they use
> pool.sks-keyservers.net, but that's just a default configuration, it's
> easily overrided during runtime… so I don't think you can rely on
> keyring-maint not using something else.
> 
> I confirm that nm.d.o currently uses keyserver.ubuntu.com.

pool.sks-keyservers.net is indeed our default configuration; I tend to
use the.earth.li and have a manual syncing script that goes and tries
keyserver.ubuntu.com, amongst others, when that doesn't work.

J.

-- 
I'm a *daemon*! Demons are evil. Daemons are not!
This .sig brought to you by the letter I and the number 15
Product of the Republic of HuggieTag


signature.asc
Description: PGP signature

Bug#944181: [Pkg-electronics-devel] Bug#944181: ghdl: non-standard gcc/g++ used for build (gcc-8)

2020-03-28 Thread Jonathan McDowell

Control: block -1 with 954826

On Thu, Mar 26, 2020 at 10:48:27PM +0100, Emilio Pozuelo Monfort wrote:
> On Tue, 05 Nov 2019 13:23:02 + Matthias Klose  wrote:
> > Package: ghdl
> > Severity: important
> > Tags: sid bullseye
> > User: debian-...@lists.debian.org
> > Usertags: non-standard-compiler, gcc-8, gcc-8-legacy
> > 
> > This package builds with a non standard compiler version; please check
> > if this package can be built with the default version of gcc/g++, or
> > with gcc-9/g++-9.
> > 
> > Please keep this report open until the package uses the default
> > compiler version (or gcc-9) for the package build.
> > 
> > If the package cannot be built anymore, please file a bug report for
> > ftp.debian.org, asking for the removal of the package.
> > 
> > The severity of this report is likely to be raised before the release,
> > so that the gcc-8 package can be removed for the release.
> 
> GCC 8 is being removed, so this is now serious.

I started pulling in 0.37 from upstream and switching to GCC 9, but
unfortunately #954826 currently means GHDL can't compile as it wants
LLVM which then wants libgcc-8-dev which is now uninstallable.

J.

-- 
Is it real, or is it Mimozine?

Bug#952468: libtss2-dev: Don't ship libtss2-tcti-default.so

2020-02-24 Thread Jonathan McDowell

Package: libtss2-dev
Version: 2.3.2-1
Severity: normal

The existence of libtss2-tcti-default.so changes the default ordering of
how TSS2 tries to find the TPM2 device. Without the -dev package
installed everything is ok, but with it the symlink from default to
device causes /dev/tpm0 to be tried first resulting in errors being
output:

ERROR:tcti:src/tss2-tcti/tcti-device.c:439:Tss2_Tcti_Device_Init() Failed to 
open device file /dev/tpm0: Permission denied  
WARNING:tcti:src/tss2-tcti/tctildr.c:62:tcti_from_init() TCTI init for function 
0x7efc49ceee00 failed with a000a 
WARNING:tcti:src/tss2-tcti/tctildr.c:92:tcti_from_info() Could not initialize 
TCTI named: tcti-device 
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:150:tcti_from_file() Could not initialize 
TCTI file: libtss2-tcti-default.so 

It does fall back to /dev/tpmrm0 after this, but it would be better not
to output the errors/warnings at all.

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

Kernel: Linux 5.5.6 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtss2-dev depends on:
ii  libgcrypt20-dev  1.8.5-3
ii  libtss2-esys02.3.2-1

libtss2-dev recommends no packages.

libtss2-dev suggests no packages.

-- no debconf information

Bug#951980: [Pkg-electronics-devel] Bug#951980: sigrok-cli: FTBFS: configure: error: Package requirements (glib-2.0 >= 2.32.0 libsigrok >= 0.5.0 libsigrokdecode >= 0.5.0) were not met

2020-02-23 Thread Jonathan McDowell

Control: reassign -1 libsigrok-dev
Control: retitle -1 Missing bluetooth + hidapi deps on -dev package cause 
FTBFSes

On Sun, Feb 23, 2020 at 07:53:00AM +0100, Lucas Nussbaum wrote:
> Source: sigrok-cli
> Version: 0.7.1-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: buster sid
> Usertags: ftbfs-20200222 ftbfs-buster

This has been caused by the update to libsigrok 0.5.2 with bluetooth +
hidapi support, and missing deps on the -dev.

J.

-- 
"Remind me never to buy software from you." -- Geraint Jones, marking
an Operating Systems question.

Bug#942091: Any progress on tpm2-pkcs11 package?

2020-02-22 Thread Jonathan McDowell

Hi,

Just a gentle prod to see if there's any progress on a tpm2-pkcs11
package; I've downloaded tpm2-pkcs11-1.0.1 and it builds fine with the
pieces available in bullseye so it would be nice to get a proper package
available.

J.

-- 
... Design a system any fool can use, and only a fool will want to use it.

Bug#948842: nm.debian.org: please let people upload their OpenPGP certificate directly

2020-01-17 Thread Jonathan McDowell

On Thu, Jan 16, 2020 at 03:18:54PM -0500, Daniel Kahn Gillmor wrote:
> On Wed 2020-01-15 21:40:38 +0000, Jonathan McDowell wrote:
> > Y'all are welcome to (and tell prospective contributors to) send keys to
> > the.earth.li, which is not SKS and still accepts third party
> > certifications. It does some limited signature verification which I'm
> > generally working to improve when time allows, but I think it's a
> > half-way house between what we current have (trust a failing keyserver
> > network to have the data) and what's being proposed (implement a very
> > specific service to suit our needs for retrieving 3rd party certs).
> 
> It looks to me like the only thing nm needs the keyserver for is a
> placeholder for keys until they land in the debian keyring (or the
> debian-maintainer keyring), at which point we can rely on
> keyring.debian.org.
> 
> right?
> 
> if the applicant is expected to submit this key somehow, it seems
> simpler to me to have them just submit it to nm directly with the rest
> of the application (e.g. "here are 9 questions, one of them needs you to
> paste your OpenPGP certificate")  than to say "here are 8 questions; for
> the 9th question, send your OpenPGP certificate to service X, and then
> paste the fingerprint of the certificate here, and we'll reassemble it
> from service X later".

Mostly my concern is about avoiding the effort of having to code the
bits of nm.d.o to accept keys from the applicant and forward them to
keyring-maint, and the piece on the keyring-maint side of automatically
putting the key into the repo (i.e as part of process-rt). If someone
else is saying they'll do all that work then I have no objections!

J.

-- 
  It's more than good enough so I  |  .''`.  Debian GNU/Linux Developer
  ain't switch'n.  | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.


signature.asc
Description: PGP signature

Bug#948842: nm.debian.org: please let people upload their OpenPGP certificate directly

2020-01-15 Thread Jonathan McDowell

On Wed, Jan 15, 2020 at 07:12:36PM +0100, Enrico Zini wrote:
> On Mon, Jan 13, 2020 at 05:03:50PM -0500, Daniel Kahn Gillmor wrote:
> > > With the SKS network slowly dying, gpg not receiving third-party
> > > certifications anymore by default and other changes to the ecosystem,
> > > retrieving OpenPGP certificates and third-party certifications may be
> > > harder in the future.
> > >
> > > It is simpler to let applicants provide a certificate themselves
> > > directly.
> > 
> > I endorse this suggestion :)
> > 
> > I note that we shouldn't *require* users to upload their certificate
> > necessarily.  The change asked for here is just to make it possible for
> > them to do the upload if they choose to.
> 
> I like the sentiment, and I am slightly afraid of turning nm.debian.org
> into the debian keyserver replacement.
> 
> I mean, we could, but I'd like to figure out where we want to have the
> authoritative source of key material for Debian.
> 
> Here are various options that I can think of:
> 
>  - nm.debian.org, needs the data
>  - contributors.debian.org has a much more comprehensive user database
>  - keyring.debian.org primarily manages key material
>  - sso.debian.org is the authoritative user database
>  - the oncoming replacement of sso.debian.org will be the actual
>authoritative user database
> 
> I'd feel better having this information together with the authoritative
> user database, which at this point in time would mean waiting for the
> new SSO to be up, and then hooking into that somehow.
> 
> Alternatively, having this information managed by the authoritative
> team, which could mean keyring-maint providing a key upload service tied
> to the new SSO. In this case, I don't mind helping to write the key
> upload service for keyring-maint, if you want.

[wearing no hat other than operator of the keyserver in question]

Y'all are welcome to (and tell prospective contributors to) send keys to
the.earth.li, which is not SKS and still accepts third party
certifications. It does some limited signature verification which I'm
generally working to improve when time allows, but I think it's a
half-way house between what we current have (trust a failing keyserver
network to have the data) and what's being proposed (implement a very
specific service to suit our needs for retrieving 3rd party certs).

J.

-- 
  "I'm not anti-establishment, I   |  .''`.  Debian GNU/Linux Developer
   just don't see the point." --   | : :' :  Happy to accept PGP signed
  Matthew Kirkwood, OxLUG mailing  | `. `'   or encrypted mail - RSA
   list.   |   `-key on the keyservers.


signature.asc
Description: PGP signature

Bug#930890: [Pkg-electronics-devel] Bug#930890: Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.

2019-09-28 Thread Jonathan McDowell

On Sat, Sep 28, 2019 at 07:02:31AM +0200, Gianfranco Costamagna wrote:
> control: severity -1 serious
> control: found -1 0.35+git20181129+dfsg-3
> 
> I know this isn't the right bug, but since this bug is about a non-existing 
> version that FTBFS, lets recycle it :)

I think you wanted to alter #923190 instead, which is about adding LLVM
8 support.

J.

-- 
... 101 things you can't have too much of : 38 - clean underwear.

Bug#935274: [Pkg-electronics-devel] Bug#935274: binutils-xtensa-lx106: FTBFS on amd64

2019-08-21 Thread Jonathan McDowell

On Wed, Aug 21, 2019 at 10:40:29AM +, Ivo De Decker wrote:
> A binnmu of binutils-xtensa-lx106 in unstable fails on amd64:
> 
> https://buildd.debian.org/status/package.php?p=binutils-xtensa-lx106
> 
> It probably needs to be updated for the newer binutils.

binutils has helpfully changed its version string to not match the
directory the source untars to. I had a look at fixing this up yesterday
but then hit a problem compiling readelf (which isn't patched by
binutils-xtensa-lx106). I'll try to fight it some more this week.

J.

-- 
101 things you can't have too much of : 10 - CDs.

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-27 Thread Jonathan McDowell

On Sat, Jul 27, 2019 at 10:40:00PM +0100, Ian Jackson wrote:
> Jonathan McDowell writes ("Bug#932753: tag2upload should record git tag 
> signer info in .dsc [and 1 more messages]"):
> > My understanding is this was true in the days of v3 keys/fingerprints
> > but is not the case for v4. If we get to the point we find a collision
> > then that's a SHA1 issue that's going to cause bigger issues.
> 
> It would be good to prepare for changing the fingerprint hash
> function.  Would including these parameters do that ?  I think it
> would, provided that "hash-algo" is in fact the algorithm used for the
> fingerprint hash.
> 
> An alternative, perhaps, is to leave this out now, and intend to
> introduce a `fingnerprintv5' value later.

A v5 fingerprint is SHA256 based and 32 bytes (64 ASCII characters)
long.

J.

-- 
Beware of programmers carrying screwdrivers.
This .sig brought to you by the letter X and the number 23
Product of the Republic of HuggieTag

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-27 Thread Jonathan McDowell

On Fri, Jul 26, 2019 at 09:18:29PM +0100, Sean Whitton wrote:
> For the purposes of tag2upload work, would you mind confirming this:
> 
> On Tue 23 Jul 2019 at 06:38AM +01, Sean Whitton wrote:
> 
> > AIUI a fingerprint fails to uniquely identify a PGP key unless you also
> > include the cryptographic algorithm that was used and the key size.  So
> > for example, my current key is uniquely identified by writing both 4096R
> > and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.
> >
> > Even though it's unlikely we'll get a clash of fingerprints within the
> > Debian keyring, it seems the algorithm and keysize ought to be included
> > alongside the fingerprint, if the above is right.

My understanding is this was true in the days of v3 keys/fingerprints
but is not the case for v4. If we get to the point we find a collision
then that's a SHA1 issue that's going to cause bigger issues.

J.

-- 
] https://www.earth.li/~noodles/ []  I'm absolutely  [
]  PGP/GPG Key @ the.earth.li[]  convinced one day soon I'm going  [
] via keyserver, web or email.   [] to get "masturbation" and  [
] RSA: 4096/0x94FA372B2DA8B985   []   "meditation" mixed up.   [

Bug#932694: dgit clone produces non-working origin remote

2019-07-21 Thread Jonathan McDowell

Package: dgit
Version: 9.3
Severity: normal

noodles@mixian:~/foo$ dgit clone agda
canonical suite name for unstable is sid
starting new git history
downloading http://ftp.debian.org/debian//pool/main/a/agda/agda_2.5.4.1-3.dsc...
last upload to archive: NO git hash
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 1942k  100 1942k0 0   907k  0  0:00:02  0:00:02 --:--:--  907k
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  9928  100  99280 0  20386  0 --:--:-- --:--:-- --:--:-- 20344
dpkg-source: info: extracting agda in agda-2.5.4.1
dpkg-source: info: unpacking agda_2.5.4.1.orig.tar.gz
dpkg-source: info: unpacking agda_2.5.4.1-3.debian.tar.xz
synthesised git commit from .dsc 2.5.4.1-3
HEAD is now at ba16b82 var-lib-agda
dgit ok: ready for work in agda
noodles@mixian:~/foo$ ls
agda  agda_2.5.4.1-3.debian.tar.xz  agda_2.5.4.1.orig.tar.gz
noodles@mixian:~/foo$ cd agda/
noodles@mixian:~/foo/agda$ git remote -v
dgit
origin  https://git.dgit.debian.org/agda (fetch)
origin  https://git.dgit.debian.org/agda (push)
vcs-git https://salsa.debian.org/haskell-team/DHG_packages.git [p/agda] (fetch)
vcs-git https://salsa.debian.org/haskell-team/DHG_packages.git [p/agda] (push)
noodles@mixian:~/foo/agda$ git remote update
Fetching origin
fatal: repository 'https://git.dgit.debian.org/agda/' not found
error: Could not fetch origin
Fetching vcs-git
fatal: unable to access 'https://salsa.debian.org/haskell-team/DHG_packages.git 
[p/agda]/': The requested URL returned error: 400
error: Could not fetch vcs-git
noodles@mixian:~/foo/agda$

(as requested by Ian)

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit depends on:
ii  apt 1.8.2
ii  ca-certificates 20190110
ii  coreutils   8.30-3
ii  curl7.65.1-1
ii  devscripts  2.19.5
ii  dpkg-dev1.19.7
ii  dput1.0.3
ii  git [git-core]  1:2.20.1-2
ii  git-buildpackage0.9.14
ii  libdigest-sha-perl  6.02-1+b1
ii  libdpkg-perl1.19.7
ii  libjson-perl4.02000-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblocale-gettext-perl  1.07-3+b4
ii  libtext-glob-perl   0.10-1
ii  libtext-iconv-perl  1.7-6
ii  libwww-perl 6.39-1
ii  perl5.28.1-6

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:8.0p1-3

Versions of packages dgit suggests:
ii  cowbuilder  0.88
ii  pbuilder0.230.4

-- no debconf information

Bug#931118: unblock: debian-keyring/2019.06.25

2019-06-30 Thread Jonathan McDowell

On Sun, Jun 30, 2019 at 10:12:32PM +0200, Mattia Rizzolo wrote:
> On Sun, Jun 30, 2019 at 08:38:52PM +0200, Paul Gevers wrote:
> > On 26-06-2019 16:10, Mattia Rizzolo wrote:
> > > The last upload of debian-keyring done yesterday updates the
> > > security team key.  See #928222 for more context.
> > > 
> > > I think it would be good if this change could find its way into
> > > buster.  With this package providing data only, there are no
> > > regression potentials, imho.  Also, with it shipping mostly binary
> > > files, a debdiff is quite useless.
> > 
> > The time for unblocks for buster has come and gone. The deadline was
> > last Tuesday, we are now in deep freeze and we were not able to
> > process your unblock request and give it an exception. I assume this
> > could be fixed via a stable release update targeting buster, such
> > that this can be fixed in the first point release. If that doesn't
> > work for you and I am wrong, please just close this bug.
> 
> Sure, it can be done, it just feels incredibly silly from my point of
> view (with this package being data only, and either way I'd suspect a
> pu upload being less "tested" in a case like this).
> 
> Not to mention that I personally have little interest in doing this
> work (I just recalled the security team opening that bug, then it
> being fixed very late, so I asked an explicit unblock).

keyring-maint have historically tried to do a keyring update as close to
the release as possible, and this has always had an unblock in the past;
jessie has 2015.04.10 (release date: 2014-04-26) and stretch has
2017.05.28 (release date: 2017-06-17). If we've missed it this time then
so be it.

J.

-- 
Revd Jonathan McDowell, ULC | Don't hit the keys so hard, it hurts.

Bug#931123: Puts systemd service files in arch tuple lib directory

2019-06-26 Thread Jonathan McDowell

Package: tpm2-abrmd
Version: 2.1.0-1
Severity: normal

This package puts its systemd service file in a /usr/lib//
directory:

/usr/lib/x86_64-linux-gnu/systemd/system/tpm2-abrmd.service
/usr/lib/x86_64-linux-gnu/systemd/system-preset/tpm2-abrmd.preset

These should be:

/lib/systemd/system/tpm2-abrmd.service
/lib/systemd/system-preset/tpm2-abrmd.preset

as otherwise systemd does not pick them up.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tpm2-abrmd depends on:
ii  libc6  2.28-10
ii  libglib2.0-0   2.58.3-2
ii  libtss2-esys0  2.1.0-4

tpm2-abrmd recommends no packages.

tpm2-abrmd suggests no packages.

-- no debconf information

Bug#930890: [Pkg-electronics-devel] Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.

2019-06-24 Thread Jonathan McDowell

Control: severity -1 wishlist
Control: retitle -1 Update GHDL packaging for newer releases

On Sun, Jun 23, 2019 at 11:57:33PM +0200, Pavel Pisa wrote:
> On Sunday 23 of June 2019 10:52:47 Jonathan McDowell wrote:
> > On Sat, Jun 22, 2019 at 12:26:36AM +0200, Pavel Pisa wrote:
> > > Source: ghdl
> > > Version: 0.36+20190617
> >
> > This is not a version of GHDL from Debian. testing/unstable both have
> > 0.35+git20181129+dfsg-3. I don't think this is a valid bug against the
> > Debian package - it seems that you've obtained an updated package from
> > somewhere else, or have manually updated to a newer release?
> 
> I have used original Debian package as "debian" directory
> source to port newer GHDL version for Debian Buster.
> 
> I am not sure if the problem applies to old version,
> but solution should work for all versions. I have built older
> version but on the system where GHDL has already been installed.
> So I expect that the problem may be there as well.

You have raised a release critical bug stating the package currently in
Debian fails to build from source. I think what you wanted to raise was
a wishlist bug requesting the packaging be updated to support newer
versions of GHDL. Retitling and updating the severity to indicate this
fact. This can be looked at once we have Buster released.

(I've confirmed that I can still build 0.35+git20181129+dfsg-3 in a
clean sbuild environment, so the FTBFS does not apply to the Debian
package and thus there's no need to fix it to ensure it's ok for Buster.)

J.

-- 
/-\ |   Evil is as evil does, but evil
|@/  Debian GNU/Linux Developer | doesn't wear shoes.
\-  |

Bug#930890: [Pkg-electronics-devel] Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.

2019-06-23 Thread Jonathan McDowell

On Sat, Jun 22, 2019 at 12:26:36AM +0200, Pavel Pisa wrote:
> Source: ghdl
> Version: 0.36+20190617

This is not a version of GHDL from Debian. testing/unstable both have
0.35+git20181129+dfsg-3. I don't think this is a valid bug against the
Debian package - it seems that you've obtained an updated package from
somewhere else, or have manually updated to a newer release?

> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> When Debianized GHDL package is build it fails with message
> 
>   Error: No installed ghdl backend found. Terminating!
> 
> in context
> 
>   install -m 755 -p libghdl-0_37_dev.so ../../debian/tmp/usr/lib/ghdl/mcode/
> ../../debian/tmp/usr/bin/ghdl --disp-standard --std=87 >
> ../../debian/tmp/usr/lib/ghdl/mcode/vhdl/src/std/standard.v87
>   Error: No installed ghdl backend found. Terminating!
>   make[2]: *** [Makefile:131: install] Error 2
>   make[2]: Leaving directory '/home/user/repo/ghdl/ghdl-git/builddir/mcode'
>   make[1]: *** [debian/rules:140: override_dh_auto_install] Error 2
>   make[1]: Leaving directory '/home/user/repo/ghdl/ghdl-git'
>   make: *** [debian/rules:54: binary] Error 2
>   dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned
> exit status 2
> 
> The reason for the problem is the file /debian/ghdl.wrapper which prevents
> install when there is not already installed some "ghdl" package because
> it ignores "ghdl-mcode" already redy to be run in "debian/tmp/usr/bin"
> directory.

J.

-- 
/-\ |  I am afraid of the dark.
|@/  Debian GNU/Linux Developer |
\-  |

Bug#929610: RM: l2tpns -- ROM: Unmaintained upstream

2019-05-27 Thread Jonathan McDowell

Package: ftp.debian.org

Hi,

The l2tpns package has not seen any upstream love in many years, and I
personally have not used it in production in over a decade. I put out a
RFA (#838771) back in 2016 and got some interest that never went
anywhere. As this is a software package intended to connect to the
public internet and handle all manner of traffic I think the wisest
course of action is to finally remove this from Debian before Buster
releases, rather than give the impression that it is still actively
maintained and secure.

J.

-- 
 I coded the turtle to make a circle.
This .sig brought to you by the letter V and the number 25
Product of the Republic of HuggieTag


signature.asc
Description: PGP signature

Bug#928222: debian-keyring: Please update Security Team key in debian-role-keys.gpg (extended expiry)

2019-05-27 Thread Jonathan McDowell

Control: tag -1 pending

On Tue, Apr 30, 2019 at 08:19:53AM +0200, Salvatore Bonaccorso wrote:
> Hi
> 
> The current Security Team key in debian-role-keys.gpg was going to
> expire during the buster release cycle. Its expiry has been extended.
> Can you please update the key in the debian-role-keys.gpg keyring,
> which hopefully can be included then further in buster?

Updated in our working tree. For future requests can you please include
the key fingerprint? It makes our life much easier - in this case it was
easy enough to work out which key you meant, but generally we prefer
explicit confirmation.

Thanks,
J.

-- 
Nine times out of ten the statisticians are wrong.

signature.asc
Description: PGP signature

Bug#928101: onak FTCBFS: abuses AC_CHECK_FILE

2019-05-12 Thread Jonathan McDowell

On Sun, May 12, 2019 at 12:19:55PM +0200, Helmut Grohne wrote:
> On Sun, May 12, 2019 at 11:07:30AM +0100, Jonathan McDowell wrote:
> > I'm all for being able to be cross-built, but I'm not applying this
> > during the freeze. Also upstream I've moved over to cmake, so the next
> > onak release should be cross-buildable out of the box.
> 
> I didn't expect you to apply this during freeze. At an earlier time, I
> included some boiler plate about patches during freeze, but that also
> confused people, so I think "severity normal isn't freeze material" is
> kinda common sense, no?

I was mostly following up to indicate I had seen the bug + thought it was
reasonable, rather than just letting it sit uncommented.

> If you switch the build system to cmake, please just close the bug
> without checking cross building. That'll trigger a retest on my side and
> I'll reopen if something is broken then.

Cool, will do.

J.

-- 
Make friends.

Bug#928101: onak FTCBFS: abuses AC_CHECK_FILE

2019-05-12 Thread Jonathan McDowell

On Sun, Apr 28, 2019 at 06:57:36AM +0200, Helmut Grohne wrote:
> onak fails to cross build from source, because the upstream configure.ac
> abuses AC_CHECK_FILE. The macro is meant to check for files on the host,
> but it uses it to examine the build tree. A simple test -f is better in
> this case. Please consider applying the attached patch. It makes onak
> cross buildable.

I'm all for being able to be cross-built, but I'm not applying this
during the freeze. Also upstream I've moved over to cmake, so the next
onak release should be cross-buildable out of the box.

J.

-- 
"The best thing about Debian is that it's boring." -- Peter Corlett

Bug#924337: debdiff re-enabling mqtt/varnish plugins

2019-04-04 Thread Jonathan McDowell

Attached patch re-enables the plugins and builds fine for me within
sbuild on sid (and works fine for MQTT on buster).

J.

-- 
Professional Geek + recovering Law Student
https://www.linkedin.com/in/noodles

101 things you can't have too much of : 51 - News.
diff -Nru collectd-5.8.1/debian/changelog collectd-5.8.1/debian/changelog
--- collectd-5.8.1/debian/changelog	2018-12-25 11:08:23.0 +
+++ collectd-5.8.1/debian/changelog	2019-04-03 21:56:47.0 +0100
@@ -1,3 +1,10 @@
+collectd (5.8.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Re-enable mqtt + varnish plugins. (Closes: #924337)
+
+ -- Jonathan McDowell   Wed, 03 Apr 2019 21:56:47 +0100
+
 collectd (5.8.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru collectd-5.8.1/debian/control collectd-5.8.1/debian/control
--- collectd-5.8.1/debian/control	2018-12-19 14:51:04.0 +
+++ collectd-5.8.1/debian/control	2019-04-03 21:55:59.0 +0100
@@ -32,6 +32,7 @@
  libmicrohttpd-dev,
  libmodbus-dev,
  libmongoc-dev,
+ libmosquitto-dev,
  libmnl-dev [linux-any],
  libnotify-dev,
  libopenipmi-dev,
@@ -54,7 +55,7 @@
  libtokyotyrant-dev [linux-any],
  libudev-dev [linux-any],
  libupsclient-dev | libupsclient1-dev,
-# libvarnishapi-dev,
+ libvarnishapi-dev,
  libvirt-dev (>= 0.4.0-6) [linux-any],
  libxen-dev [amd64 arm64 armhf i386],
  libxml2-dev,
diff -Nru collectd-5.8.1/debian/rules collectd-5.8.1/debian/rules
--- collectd-5.8.1/debian/rules	2018-12-19 14:51:28.0 +
+++ collectd-5.8.1/debian/rules	2019-04-03 21:56:12.0 +0100
@@ -88,14 +88,6 @@
 # Cf. https://github.com/collectd/collectd/issues/1574
 confflags += --disable-sigrok
 
-# temporarily disable varnish plugin, as #879471 blocks collectd from
-# migrating to testing.
-confflags += --disable-varnish
-
-# temporarily disable mqtt plugin, as #911265, #911266 blocks collectd from
-# migrating to testing.
-confflags += --disable-mqtt
-
 # disable lvm plugin, liblvm2app is deprecated upstream, #915692
 # Cf. https://github.com/collectd/collectd/issues/2647
 confflags += --disable-lvm

Bug#924337: Causes regression with upgrades from stretch

2019-04-03 Thread Jonathan McDowell

Control: merge 924337 925420
Control: severity 924337 serious

This causes failures on upgrades from stretch to buster, and bit me
today. Ideally the mqtt/varnish plugins would be re-enabled but failing
that a note in NEWS.Debian and the release notes seems appropriate.

J.

-- 
  Don't hit the keys so hard, it   |  .''`.  Debian GNU/Linux Developer
  hurts.   | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Bug#925206: [Pkg-electronics-devel] Bug#925206: /usr/bin/pulseview: Dependency missing: libpython3.6

2019-03-21 Thread Jonathan McDowell

On Thu, Mar 21, 2019 at 10:29:30AM +0100, Philipp Marek wrote:
> Package: pulseview
> Version: 0.4.1-1+b1
> Severity: important
> File: /usr/bin/pulseview
> 
> Without libpython3.6, running PV only gives an error:
> 
> /usr/bin/pulseview: error while loading shared libraries:
> libpython3.6m.so.1.0: cannot open shared object file: No such file or
> directory

I can't see how you're getting that error. pulseview does not directly
require libpython, this comes from libsigrokdecode4, which correctly has
a dependency on libpython3.7 and is linked against that. What version of
libsigrokdecode are you running - is it from testing as well? I
correctly see a libpython3.7m.so.1.0 linkage and a libpython3.7 package
dependency with 0.5.2-1+b1 on amd64/testing.

J.

-- 
... I'm only here for the salad bar.

Bug#914992: network-manager-openconnect-gnome: Unable to select realm when connecting to Juniper VPN

2019-03-12 Thread Jonathan McDowell

On Tue, Mar 12, 2019 at 10:31:31AM -0700, Mike Miller wrote:
> On Thu, Nov 29, 2018 at 10:49:19 +0000, Jonathan McDowell wrote:
> > When trying to login to a Juniper Network Connect VPN using the NM VPN
> > login dialog I get a form that provides a drop down "realm" to select as
> > well as requesting the username + password. Upon selecting a realm other
> > than the default as soon as focus switches away from that form entry the
> > realm switches back to the initial entry. This means it's impossible to
> > use the graphical login interface for a Juniper VPN.
> 
> Does this work for you now with openconnect 8.02-1?
> 
> There is an upstream bug report, where it is reported that updating to
> openconnect 8 fixed this.
> 
>   https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/issues/5
> 
> If it still persists for you, can you comment on this upstream report?

I can confirm that using my Buster/testing machine I'm now able to
correctly select the realm and login to the VPN. Versions are:

openconnect 8.02-1
network-manager-openconnect-gnome   1.2.4-2

J.

-- 
Professional Geek + recovering Law Student
Do not expose this tagline to direct sunlight.


signature.asc
Description: PGP signature

Bug#921851: [Pkg-electronics-devel] Bug#921851: unnecessary b-d's libisl-0.18-dev and libcloog-isl-dev, to be removed for buster

2019-02-09 Thread Jonathan McDowell

On Sat, Feb 09, 2019 at 01:39:34PM +0100, Matthias Klose wrote:
> Package: src:binutils-xtensa-lx106
> Version: 1
> Severity: serious
> Tags: sid buster

> unnecessary b-d's libisl-0.18-dev and libcloog-isl-dev, to be removed
> for buster

Where should I have been paying attention to find this out? It seems
prudent to do the removal well enough in advance of the freeze rather
than the packages in question still being present less than a week
before soft freeze.

J.

-- 
Web [Why are we here?  Because we're here.  Roll the bones.]
site: https:// [  ]  Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24

Bug#921547: u-boot: Please consider making u-boot-sunxi arch:all

2019-02-07 Thread Jonathan McDowell

On Wed, Feb 06, 2019 at 12:31:08PM -0800, Vagrant Cascadian wrote:
> On 2019-02-06, Jonathan McDowell wrote:
> > The u-boot-sunxi package contains a bunch of u-boot images which can be
> > written to SD cards or sent over USB to the device via sunxi-fel.
> > There's no binary which actually runs under Linux. As such I think it's
> > appropriate to switch to arch:all, allowing it's installation on other
> > machines which are creating the SD image or remotely debugging the sunxi
> > device.
> 
> Interesting timing... yesterday I worked on updating Ivo De Decker's
> work on cross-building u-boot images for multiple architectures and
> building an arch:all u-boot-qemu package:
> 
>   https://bugs.debian.org/907573
> 
> Which demonstrates that in theory it would be possible to make almost
> all of the u-boot packages arch:all... essentially any architecture with
> working cross-compilers for amd64.

H. And that discussion raises the issue of a lack in our
infrastructure; the resulting package is arch:all but it needs to be
built on a specific arch (i.e. arm, in this case) or using a cross
compiler. For ARM that isn't a problem as the cross compiler exists in
the archive, but I'm not sure that's true for all of the u-boot targets?

> On the other hand, people went through a lot of trouble to make
> multi-arch a reality, and you can also install u-boot-sunxi packages
> using multi-arch.

multi-arch is great, but I don't think it's applicable here. The
u-boot-sunxi package contains ARM binaries, but they do not run under
the Debian (or Linux) system. Effectively where I'm coming from is that
any host that can install sunxi-tools may potentially want u-boot-sunxi
to be available, as the image to send via USB. (I'll note, in passing,
that I was pleased to discover the wide range of support in the u-boot
package.)

…

> One thought would be to build a single arch:all package with all of the
> cross-buildable targets, and appropriate Provides and Conflicts on other
> u-boot-* packages, while still building natively as well... maybe a
> little redundant essentially having the same u-boot images in two
> places.
> 
> Certainly too late for buster, of course, but an interesting idea to
> mull over for bullseye...

I think we need a way to say "This produces an arch:all package, but
needs to build on arch:arm (or whatever)" and I don't think we have
that. Which means it's not just the simple change I'd hoped it would be.
I'll leave it in your capable hands to think about.

J.

-- 
  This is not a daffodil! This is  |  .''`.  Debian GNU/Linux Developer
  not a daffodil!  | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

signature.asc
Description: PGP signature

Bug#921547: u-boot: Please consider making u-boot-sunxi arch:all

2019-02-06 Thread Jonathan McDowell

Source: u-boot
Severity: wishlist

The u-boot-sunxi package contains a bunch of u-boot images which can be
written to SD cards or sent over USB to the device via sunxi-fel.
There's no binary which actually runs under Linux. As such I think it's
appropriate to switch to arch:all, allowing it's installation on other
machines which are creating the SD image or remotely debugging the sunxi
device.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#917850: Fwd: Server Error (500) on nm.d.o

2019-01-05 Thread Jonathan McDowell

On Fri, Jan 04, 2019 at 11:12:24PM -0300, eamanu15 wrote:
> > > I am trying to update my keyring using: *gpg --keyserver
> > > keyring.debian.org  --send-keys ...*
> > > But I don't see the change. On Debian wiki say that this could
> > > take some time, because the keyring push is monthly. Do you know
> > > approx when it occur? Or, there are other way to update the key?
> >
> > keyring.debian.org is only for keys that are already part of the
> > Debian keyring, not for new applicants. Your key will be accepted
> > and silently discarded there. You should send your updated key to
> > the keyserver network (nm.debian.org is currently using
> > keys.gnupg.net I believe, which is a pointer to the SKS keyserver
> > network).
> >
> Hmmm I've just upload my keyring to keys.gnupg.net.
>  Currently If I run --recv-key this is ok. But
> on nm.debian.org still give me the same error :(

You have renewed the certificate/signing part of your key, but the
encryption key is still expired. The challenge is encrypted, so there is
still no usable part of your key for this step:

$ gpg -v --list-key 630362FCC33595B4CA3BCFB1D85007169B2B9F26
pub   rsa4096 2017-11-03 [SC] [expires: 2028-10-07]
  6303 62FC C335 95B4 CA3B  CFB1 D850 0716 9B2B 9F26
uid   [ unknown] Emmanuel Arias (eamanu ) 

sub   rsa4096 2017-11-03 [E] [expired: 2018-11-03]

J.

-- 
] https://www.earth.li/~noodles/ []   If I follow you home, will you   [
]  PGP/GPG Key @ the.earth.li[]  keep me?  [
] via keyserver, web or email.   [][
] RSA: 4096/0x94FA372B2DA8B985   [][

Bug#917850: Fwd: Server Error (500) on nm.d.o

2019-01-04 Thread Jonathan McDowell

On Fri, Jan 04, 2019 at 09:56:10AM -0300, eamanu15 wrote:
> El lun., 31 de dic. de 2018 a la(s) 05:02, Jonathan McDowell (
> nood...@earth.li) escribió:
> > On Sun, Dec 30, 2018 at 11:29:33PM -0300, eamanu15 wrote:
> > > I joined to NM and in my personal web I have on *pending *the next line:
> > > "This is a new entry that requires confirmation before Jan. 2, 2019.
> > > Click here to send the email challenge again."
> > >
> > > I don't receive the email. And when I click on "here" link this give me a
> > > Server Error (500).
> > >
> > > What would be the problem?
> >
> > Your GPG key has expired, so the system can't encrypt the challenge to
> > you. You need to update your key (and we need to fix the system so it
> > prints a proper error message in that case).
> >
> I am trying to update my keyring using: *gpg --keyserver
> keyring.debian.org <http://keyring.debian.org> --send-keys ...* But I
> don't see the change. On Debian wiki say that this could take some
> time, because the keyring push is monthly. Do you know approx when it
> occur? Or, there are other way to update the key?

keyring.debian.org is only for keys that are already part of the Debian
keyring, not for new applicants. Your key will be accepted and silently
discarded there. You should send your updated key to the keyserver
network (nm.debian.org is currently using keys.gnupg.net I believe,
which is a pointer to the SKS keyserver network).

J.

-- 
101 things you can't have too much of : 17 - Money.

Bug#917850: Fwd: Server Error (500) on nm.d.o

2018-12-31 Thread Jonathan McDowell

On Sun, Dec 30, 2018 at 11:29:33PM -0300, eamanu15 wrote:
> I joined to NM and in my personal web I have on *pending *the next line:
> "This is a new entry that requires confirmation before Jan. 2, 2019. Click
> here to send the email challenge again."
> 
> I don't receive the email. And when I click on "here" link this give me a
> Server Error (500).
> 
> What would be the problem?

Your GPG key has expired, so the system can't encrypt the challenge to
you. You need to update your key (and we need to fix the system so it
prints a proper error message in that case).

J.

-- 
Web [  Just 'cause I remembered one thing doesn't make me smart!   ]
site: https:// [  ]  Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24

Bug#868895: lx106 toolchain ITPs filed / uploaded to new

2018-12-30 Thread Jonathan McDowell

I filed Bug#917546 (binutils-xtensa-lx106) and Bug#917547
(gcc-xtensa-lx106) this week and both packages are now sitting in NEW.
They target only the lx106 (ESP8266) Xtensa variant, but will hopefully
be useful to others. I think this RFP should remain open, as long term
it would be good to have a single Xtensa toolchain that is runtime
configurable for multiple platforms.

J.

-- 
"Scattered f***ing showers my ass." -- Noah

Bug#917692: [Pkg-electronics-devel] Bug#917692: sdcc: FTBFS: LaTeX Error: File `footnotehyper.sty' not found.

2018-12-29 Thread Jonathan McDowell

On Sat, Dec 29, 2018 at 10:39:07PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
...
> > ! LaTeX Error: File `footnotehyper.sty' not found.
> > 
> > Type X to quit or  to proceed,
> > or enter new name. (Default extension: sty)
> > 
> > Enter file name: 
> > ! Emergency stop.
> >  
> >  
> > l.22 \usepackage
> > {amstext}^^M
> > No pages of output.
> > Transcript written on sdccman.log.
> > make[1]: *** [Makefile:67: sdccman.dvi] Error 1

Looks like lyx has changed again; we now need a build-dep on
texlive-latex-extra for this (lyx only recommends it).

J.

-- 
 No program done by a hacker will  |  .''`.  Debian GNU/Linux Developer
 work unless he is on the system.  | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Bug#917546: binutils-xtensa-lx106 is a wrong name

2018-12-29 Thread Jonathan McDowell

On Sat, Dec 29, 2018 at 07:26:12PM +0100, Oleksij Rempel wrote:
> Am 29.12.18 um 19:11 schrieb Jonathan McDowell:
> > On Sat, Dec 29, 2018 at 05:41:47PM +0100, Oleksij Rempel wrote:
> >> If it is plain Xtensa Diamond 106Micro, then it should have proper
> >> naming. If there are some differences, it is better to know about it.
> >> Seeking for Xtensa lx106 provides no usable result to get idea about
> >> this architecture.
> > 
> > I don't think we're going to come to agreement here. I've chosen the
> > package naming that matches current usage. lx106 seems to be used
> > extensively in the ESP8266 and not elsewhere, so if your concerns about
> > variations are correct then that isn't stomping on a 106micro package
> > option, or a different variation for the other 106Micro variants.
> 
> A assume this kind of disagreement can be solve only by official
> distribution regulations/conventions:
> https://wiki.debian.org/Multiarch/Tuples
> https://wiki.debian.org/CoinstallableToolchains

Those pages talk about triples for Debian multiarch compilers; we're
talking about an embedded platform compiler here.

> We are missing only architecture name. From my understanding lx106 is
> just some name. It is not architecture name. Please provide
> documentation if I'm wrong.

As I have stated several times this toolchain is named after the
standard toolchain for the platform. It does not appear to conflict with
any other usage of the prefix. As such I'm not going to rename things; I
don't believe that serves any useful purpose to our users.

If FTP-master wishes to disagree that's of course within their rights,
and they can reject the package from NEW. I'll take that risk; I think
I've explained my reasoning throughout this ITP discussion.

J.

-- 
Web [   Asking whether machines can think is like asking whether   ]
site: https:// [   submarines can swim.   ]  Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24


signature.asc
Description: PGP signature

Bug#917546: binutils-xtensa-lx106 is a wrong name

2018-12-29 Thread Jonathan McDowell

On Sat, Dec 29, 2018 at 05:41:47PM +0100, Oleksij Rempel wrote:
> Am 29.12.18 um 16:56 schrieb Jonathan McDowell:
> > On Sat, Dec 29, 2018 at 02:02:01PM +0100, Oleksij Rempel wrote:
> >> Am 29.12.18 um 12:16 schrieb Jonathan McDowell:
> >>> On Sat, Dec 29, 2018 at 08:11:31AM +0100, Oleksij Rempel wrote:
> >>>> in my experience with xtensa, it has some basic customizable
> >>>> core/instruction set (in this case it is lx106) which is then optimized
> >>>> for some application (for example for esp8266). At the end, this
> >>>> toolchain won't be able to build binary for different lx106 based
> >>>> hardware. In this case the naming is wrong. It should be:
> >>>> binutils-xtensa-lx106-esp8266
> >>>> binutils-espressif-esp8266
> >>>> binutils-xtensa-lx106-espressif-esp8266
> >>>> or some thing like this...
> >>>
> >>> My understanding is the core is the "xtensa" architecture and "lx106"
> >>> refers to the customizations of that core. The ESP8266 and ESP32 both
> >>> use the Xtensa architecture, but the variant in the ESP8266 is the lx106
> >>> and in the ESP32 it's an lx108.
> >>
> >> Uff.. let's do together your home work in manner of OSINT investigation.
> >> https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf
> >> "Besides the Wi-Fi functionalities, ESP8266EX also integrates an
> >> enhanced version of Tensilica’s L106 Diamond series 32-bit processor and
> >> on-chip SRAM."
> >>
> >> I interpret is as following:
> >> 1. not xtensa lx106, it is xtensa Diamond variant L106
> >> 2. it is enhanced version of Tensilica’s L106 Diamond
> >>
> >> Means, what ever toolchain is provided by this request, it is not clean
> >> Xtensa Diamond L106.
> > 
> > There's no indication that the enhancements of the ESP8266 change the
> > architecture / instruction set. The Diamond L106 is cacheless while the
> > ESP8266 has internal cache, for example.
> 
> Really?
> 
> the config provided by you looks like this:
> #undef XCHAL_ICACHE_SIZE
> #define XCHAL_ICACHE_SIZE   0
> 
> #undef XCHAL_DCACHE_SIZE
> #define XCHAL_DCACHE_SIZE   0
> 
> #undef XCHAL_ICACHE_LINESIZE
> #define XCHAL_ICACHE_LINESIZE   16
> 
> #undef XCHAL_DCACHE_LINESIZE
> #define XCHAL_DCACHE_LINESIZE   16
> 
> #undef XCHAL_ICACHE_LINEWIDTH
> #define XCHAL_ICACHE_LINEWIDTH  4
> 
> #undef XCHAL_DCACHE_LINEWIDTH
> #define XCHAL_DCACHE_LINEWIDTH  4
> 
> #undef XCHAL_DCACHE_IS_WRITEBACK
> #define XCHAL_DCACHE_IS_WRITEBACK   0
> 
> If both caches have no size, are they limit less?

I'm guessing GCC cares about the internal caches, but the Espressif chip
has some caches outside the 106 core to handle the flash. I don't know
for certain, I'm just going on the data sheets you provided.

> > I'm not disagreeing it's probably the 106Micro which is also referred to
> > as the L106 in various places. It's not clear to me that this means
> > there's a *different* variant with a different binary requirement than
> > the lx106 toolchain proposed here.
> 
> can you proof it?

No, I can't prove there isn't an lx106 that is different enough to need
a separate compiler, all I can say is that all indications of the lx106
are related to the ESP8266 and that it appears to be a 106Micro core.

> >>> Looking at the HTC firmware package it appears *it's* the one
> >>> engaging in namespace problems by using xtensa-elf for the
> >>> customised core. I think it should probably be xtensa-htc-elf at
> >>> least.
> >>
> >> What ever is used insight of the package can't be seen as "engaging in
> >> namespace problems".
> > 
> > Sure, internal names used only in build don't matter, but you brought
> > up the HTC case as another example of Xtensa hardware and I'm pointing
> > out I don't believe the naming chosen for this package causes problems
> > for the HTC firmware building case.
> 
> I didn't said, that naming of this package can cause a problem for the
> htc package. Back in 2016 I tried to provide a tool chain for HTC
> firmware and the answer was, there is no reason to accept a toolchain to
> support only one chip.
> If your package will be accepted, this mean, the toolchain for HTC
> firmware should be accepted as well. And both should be properly named.

I can't comment on the HTC compiler not being accepted, but I think the
ESP8266 platform is more widely d

Bug#917546: binutils-xtensa-lx106 is a wrong name

2018-12-29 Thread Jonathan McDowell

On Sat, Dec 29, 2018 at 02:02:01PM +0100, Oleksij Rempel wrote:
> Am 29.12.18 um 12:16 schrieb Jonathan McDowell:
> > On Sat, Dec 29, 2018 at 08:11:31AM +0100, Oleksij Rempel wrote:
> >> in my experience with xtensa, it has some basic customizable
> >> core/instruction set (in this case it is lx106) which is then optimized
> >> for some application (for example for esp8266). At the end, this
> >> toolchain won't be able to build binary for different lx106 based
> >> hardware. In this case the naming is wrong. It should be:
> >> binutils-xtensa-lx106-esp8266
> >> binutils-espressif-esp8266
> >> binutils-xtensa-lx106-espressif-esp8266
> >> or some thing like this...
> > 
> > My understanding is the core is the "xtensa" architecture and "lx106"
> > refers to the customizations of that core. The ESP8266 and ESP32 both
> > use the Xtensa architecture, but the variant in the ESP8266 is the lx106
> > and in the ESP32 it's an lx108.
> 
> Uff.. let's do together your home work in manner of OSINT investigation.
> https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf
> "Besides the Wi-Fi functionalities, ESP8266EX also integrates an
> enhanced version of Tensilica’s L106 Diamond series 32-bit processor and
> on-chip SRAM."
> 
> I interpret is as following:
> 1. not xtensa lx106, it is xtensa Diamond variant L106
> 2. it is enhanced version of Tensilica’s L106 Diamond
> 
> Means, what ever toolchain is provided by this request, it is not clean
> Xtensa Diamond L106.

There's no indication that the enhancements of the ESP8266 change the
architecture / instruction set. The Diamond L106 is cacheless while the
ESP8266 has internal cache, for example.

> Continue to seek for Xtensa L106 gives me this link:
> https://ip.cadence.com/uploads/white_papers/Diamond_Tensilica.pdf
> 
> Diamond Controller Cores:
> 106Micro - Smallest 32-bit, ultra-low power, cache-less RISC controller
> with local memories.
> 108Mini - Ultra-low power, cacheless controller core with rich interrupt
> architecture, minimal gate count for lowest silicon cost.
> 212GP - Flexible mid-range controller core with instruction and data
> caches and user-defined local memory sizes
> Diamond CPU Cores:
> 232L - Flexible mid-range CPU with a Memory-Management Unit (MMU) for
> Linux OS support
> 570T - Extremely high-performance, 2- or 3-issue static superscalar
> processor.
> 
> The price segment of ESP8266 let me assume, it is not a new Xtensa
> development, it is probably some thing old and not so expensive. I would
> say, most probably it is Xtensa Diamond 106Micro.

I'm not disagreeing it's probably the 106Micro which is also referred to
as the L106 in various places. It's not clear to me that this means
there's a *different* variant with a different binary requirement than
the lx106 toolchain proposed here.

> > Looking at the HTC firmware package it appears *it's* the one
> > engaging in namespace problems by using xtensa-elf for the
> > customised core. I think it should probably be xtensa-htc-elf at
> > least.
> 
> What ever is used insight of the package can't be seen as "engaging in
> namespace problems".

Sure, internal names used only in build don't matter, but you brought
up the HTC case as another example of Xtensa hardware and I'm pointing
out I don't believe the naming chosen for this package causes problems
for the HTC firmware building case.

> > There's an open RFP for gcc-xtensa (#868895). I think with the right
> > amount of work a single pair of binutils-xtensa/gcc-xtensa packages
> > could be built that allowed run time configuration of which core was
> > being targeted
> Probably it should go as is... see my last comment.
> 
> > but I've been using these ESP8266/lx106 packages for the
> > past 4 months and it seems reasonable to get them uploaded and available
> > for use.
> 
> NACK.
> It looks like work made by Max Filippov is in usable shape, so i hope,
> it is a way to go:
> https://github.com/jcmvbkbc/xtensa-dynconfig

Longer term I think that's the ultimate solution (dynamic config with
-xtensa packages) but for now I think our users are well served by a set
of build tools for the ESP8266 which don't obviously stamp over any
other usage of the xtensa-lx106- namespace and match the naming already
used throughout the ecosystem.

J.

-- 
Never test for an error unless you're ready to handle it.
This .sig brought to you by the letter P and the number 29
Product of the Republic of HuggieTag


signature.asc
Description: PGP signature

Bug#917546: binutils-xtensa-lx106 is a wrong name

2018-12-29 Thread Jonathan McDowell

On Sat, Dec 29, 2018 at 08:11:31AM +0100, Oleksij Rempel wrote:
> in my experience with xtensa, it has some basic customizable
> core/instruction set (in this case it is lx106) which is then optimized
> for some application (for example for esp8266). At the end, this
> toolchain won't be able to build binary for different lx106 based
> hardware. In this case the naming is wrong. It should be:
> binutils-xtensa-lx106-esp8266
> binutils-espressif-esp8266
> binutils-xtensa-lx106-espressif-esp8266
> or some thing like this...

My understanding is the core is the "xtensa" architecture and "lx106"
refers to the customizations of that core. The ESP8266 and ESP32 both
use the Xtensa architecture, but the variant in the ESP8266 is the lx106
and in the ESP32 it's an lx108.

> If debian maintainers will decide to include this toolchain, then we
> need to develop unified naming shema for this kind of toolchains,
> because we already have completely opened firmware based on xtenas for
> different hardware, see firmware-ath9k-htc package. Extra toolchain for
> this package will make step forward reproducible builds.

xtensa-lx106-elf is the common prefix in the wild for the ESP8266,
xtensa-esp32-elf is in use for the ESP32/lx108 pairing. Looking at the
HTC firmware package it appears *it's* the one engaging in namespace
problems by using xtensa-elf for the customised core. I think it should
probably be xtensa-htc-elf at least.

There's an open RFP for gcc-xtensa (#868895). I think with the right
amount of work a single pair of binutils-xtensa/gcc-xtensa packages
could be built that allowed run time configuration of which core was
being targeted, but I've been using these ESP8266/lx106 packages for the
past 4 months and it seems reasonable to get them uploaded and available
for use.

J.

-- 
] https://www.earth.li/~noodles/ []Why do I get the feeling I'm[
]  PGP/GPG Key @ the.earth.li[]   going to regret this?[
] via keyserver, web or email.   [][
] RSA: 4096/0x94FA372B2DA8B985   [][

signature.asc
Description: PGP signature

Bug#917547: ITP: gcc-xtensa-lx106 -- GNU C compiler for Xtensa lx106 core

2018-12-28 Thread Jonathan McDowell

Package: wnpp
Severity: wishlist
Owner: Jonathan McDowell 

* Package name: gcc-xtensa-lx106
  Version : 8.2.0-13+1
* URL : http://gcc.gnu.org/
* License : GPL
  Programming Lang: C
  Description : GNU C compiler for Xtensa lx106 core

Bare metal C cross compiler for chips using the Xtensa lx106 core, such
as the Espressif ESP8266 wireless SoCs. This package is primarily for
those developing for the ESP8266 platform and is not needed by normal
users or developers.

This is the counterpart to the binutils-xtensa-lx106 ITP (#917546). As
stated there the ESP8266 is a commonly used component in the IoT
ecosystem; devices such as the SonOff power switches and various wifi
lightbulbs are all based upon it, as well as a full Arduino stack being
available.  Espressif have committed to availability until at least
2026. As this is targeted towards embedded platforms it will be
maintained within the Debian Electronics Team. It is built using the
gcc-8-source base package rather than pulling in an additional copy of
gcc-8.

Bug#917546: ITP: binutils-xtensa-lx106 -- GNU binary utilities, for Xtensa lx106 core

2018-12-28 Thread Jonathan McDowell

Package: wnpp
Severity: wishlist
Owner: Jonathan McDowell 

* Package name: binutils-xtensa-lx106
  Version : 2.31.1-11+1
* URL : https://www.gnu.org/software/binutils/
* License : GPL
  Programming Lang: C
  Description : GNU binary utilities, for Xtensa lx106 core

Bare metal binutils for chips using the Xtensa lx106 core, such as the
Espressif ESP8266 wireless modules. The programs in this package are
used to manipulate binary and object files that may have been created
for the Xtensa architecture. This package is primarily for those
developing for the ESP8266 platform and is not needed by normal users or
developers.


The ESP8266 is a commonly used component in the IoT ecosystem; devices
such as the SonOff power switches and various wifi lightbulbs are all
based upon it, as well as a full Arduino stack being available.
Espressif have committed to availability until at least 2026. As this is
targeted towards embedded platforms it will be maintained within the
Debian Electronics Team. It is built using the binutils-source base
package rather than pulling in an additional copy of binutils.

Bug#914992: network-manager-openconnect-gnome: Unable to select realm when connecting to Juniper VPN

2018-11-29 Thread Jonathan McDowell

Package: network-manager-openconnect-gnome
Version: 1.2.4-1.1
Severity: normal
Tags: upstream

When trying to login to a Juniper Network Connect VPN using the NM VPN
login dialog I get a form that provides a drop down "realm" to select as
well as requesting the username + password. Upon selecting a realm other
than the default as soon as focus switches away from that form entry the
realm switches back to the initial entry. This means it's impossible to
use the graphical login interface for a Juniper VPN.

Unfortunately this appears to be an upstream issue and I can't find any
indication of a fix yet. It was discussed on the openconnect-devel list
back in November 2017:

http://lists.infradead.org/pipermail/openconnect-devel/2017-November/004558.html

Upstream bug is:

https://bugzilla.gnome.org/show_bug.cgi?id=775453

It has been raised in Ubuntu:

Dhttps://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1764047

It has also been raised (and closed out without fix) in Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=1433997


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages network-manager-openconnect-gnome depends on:
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-8
ii  libcairo-gobject21.16.0-1
ii  libcairo21.16.0-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.1-2
ii  libnm0   1.14.4-3
ii  libopenconnect5  7.08-3
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libsecret-1-00.18.6-3
ii  libxml2  2.9.4+dfsg1-7+b1
ii  network-manager-openconnect  1.2.4-1.1

network-manager-openconnect-gnome recommends no packages.

network-manager-openconnect-gnome suggests no packages.

-- no debconf information

Bug#868895: xtensa toolchain(s)

2018-10-30 Thread Jonathan McDowell

On Wed, Oct 24, 2018 at 11:29:00PM +0200, Helmut Grohne wrote:
> On Fri, Aug 03, 2018 at 04:46:16AM +0100, Jonathan McDowell wrote:
> > I've been looking at generating binutils + gcc packages based on the
> > binutils-source + gcc-7-source packages for the xtensa-lx106 target
> > (ESP8266). I have something that seems to be working, and I'm
> > considering uploading them, but I don't think it's possible to build a
> > single toolchain that will target the ESP8266, ESP32 + ath9k Xtensa
> > variants. The xtensa-lx106 binary packages are turning out at about 20M
> > between them; is there enough use that it would be worth having all 3
> > options present in Debian?
> 
> Let me argue that yes, that would be a good idea.
> 
> We have esptool in the archive. The esptool comes with a flasher_stub
> (https://sources.debian.org/src/esptool/2.5.0+dfsg-1/flasher_stub/).
> Presently it cannot be built, because the toolchain would be required
> for doing so. It needs the xtensa-lx106-elf and xtensa-esp32-elf
> toolchains.

Yeah, I've ended up having to use the non-packaged esptool on occasion
because the flasher stub makes things easier.

> The open-ath9k-htc-firmware package presently builds an xtensa toolchain
> from gcc-7 sources during build
> https://sources.debian.org/src/open-ath9k-htc-firmware/1.4.0-97-g75b3e59+dfsg-1/debian/cross-toolchain.mk/
> using --target xtensa-elf. Having separate binary packages could
> simplify the packaging of open-ath9k-htc-firmware.
> 
> Maybe the ath9k toolchain is less relevant as most users will be using
> open-ath9k-htc-firmware or firmware-atheros. Those that need can quite
> easily produce the toolchain from the open-ath9k-htc-firmware source
> package. But given the rising popcon of esptool (~200 now), toolchains
> for ESP8266 and ESP32 seem sensible to me.

To answer the question you asked on IRC (you left before I could
answer); I'm using the ESP8266 toolchain built from the pkg-electronics
git repo myself, with the esp-open-sdk and no problems. However I got
the ESP32 toolchain built and had problems getting it integrated with
the esp-idf SDK; various issues with not finding the system includes.
I'm sure it's a matter of fighting with the build system a bit more, but
I'm just getting started with the ESP32 so haven't investigated further.

> Note that any practical use will also need esp-idf. In particular, the
> flasher_stub from esptool needs esp-idf. Do you have any plans for
> packaging esp-idf?

The ESP8266 is of much greater interest to me. I'm a bit torn about
packaging the SDKs up, because they seem to be moving targets and aren't
as relevant from the Debian side of things. So I have no immediate plans
to do so, though I had some conversations with Keith Packard about at
least getting newlib/nano support for the ESP chips into Debian.

> Also moving to gcc-8-source seems in order.

I've had this on my todo for a while, just not got round to it yet.

J.

-- 
I may be cool Beavis, but I can't change the future.

Bug#909995: LyX issues with Python 3 move

2018-10-05 Thread Jonathan McDowell

Control: retitle -1 Clean LyX install fails to configure correctly
Control: reassign -1 lyx
Control: tag -1 patch
Control: affects -1 sdcc

Confirmed that this is a LyX issue. A fresh install of LyX results in
the same /usr/share/lyx/configure.py failure, and removing ~/.lyx/ on an
existing install reproduces the issue. It does not occur when ~/.lyx/ is
already setup. Problem is related to the move to Python 3 and
comparisons of bytes and strings.

Following patch fixes things for me:

-
--- configure.py.old2018-10-05 10:45:21.568724157 +0100
+++ configure.py2018-10-05 10:40:04.494039200 +0100
@@ -1312,8 +1312,8 @@
 prereq_latex = b','.join(prereq_list)
 prereq_docbook = {'true':b'', 'false':b'docbook'}[bool_docbook]
 prereq = {b'LaTeX':prereq_latex, 
b'DocBook':prereq_docbook}[classtype]
-classdeclaration = (b'"%s" "%s" "%s" "%s" "%s"'
-   % (classname, opt, desc, avai, prereq))
+classdeclaration = ('"%s" "%s" "%s" "%s" "%s"'
+   % (classname, opt, desc, avai, prereq)).encode()
 if categorydeclaration != b'""':
 return classdeclaration + b" " + categorydeclaration
 if qres != None:
@@ -1367,7 +1367,7 @@
 foundClasses.append(cleanclass)
 retval = processLayoutFile(file, bool_docbook)
 if retval != b"":
-tx.write(retval + os.linesep)
+tx.write(retval + os.linesep.encode())
 tx.close()
 logger.info('\tdone')
 if not os.path.isfile('packages.lst') or not check_config:
-

J.

-- 
/-\ |   Trust me, you wouldn't like us
|@/  Debian GNU/Linux Developer |  when we're angry.
\-  |

Bug#909995: Looks like LyX?

2018-10-04 Thread Jonathan McDowell

Weird. This built fine in my sbuild environment for upload to the
archive, but is now failing, so looks like one of the deps has changed.
The failing build log includes:

Traceback (most recent call last):
  File "/usr/share/lyx/configure.py", line 1886, in 
ret = checkLatexConfig(lyx_check_config and LATEX != '', bool_docbook)
  File "/usr/share/lyx/configure.py", line 1368, in checkLatexConfig
retval = processLayoutFile(file, bool_docbook)
  File "/usr/share/lyx/configure.py", line 1316, in processLayoutFile
% (classname, opt, desc, avai, prereq))
TypeError: %b requires a bytes-like object, or an object that implements 
__bytes__, not 'str'
support/Systemcall.cpp (294): Systemcall: 'python3 -tt 
"/usr/share/lyx/configure.py" --binary-dir="/usr/bin/"' finished with exit code 
1
LyX: Done!
LayoutFile.cpp (172): LayoutFileList::Read: no textclasses found!
Error: Document class not found

and later:

Error: Cannot convert file

No information for converting svg format files to eps.
Define a converter in the preferences.

which implies LyX wants something extra now. Will poke.

J.

-- 
They say that sex is like napalm.

Bug#907861: DAK/DM-Admin: Please add John Sullivan to DM Admin ACL

2018-09-03 Thread Jonathan McDowell

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi.

John Sullivan has been added to the keyring-maint team as per:

https://lists.debian.org/debian-devel-announce/2018/08/msg7.html

Please can his key (A4626CBAFF376039D2D7554497BA9CE761A0963B) be added
to the Command::DM-Admin / AdminFingerprints list in dak.conf so he is
able to remove / change DM fingerprints in response to DM → DD
transitions and DM key migrations?

Thanks,
J.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEERUuPEyEc/2gMWDpQ/xYvxc8/utEFAluM+08ACgkQ/xYvxc8/
utGEtg//YVtIgyv1Kl0Ire3QpjXSuzuPzb1bYLz4MUI4lvn+w9U0QHzzcGqg3Bl4
zuF0ZQYiu4eEI0a4lPT31r31HNWVEfPzRI8JCsHh51CzeFrbvUpD97F9e6zhYbA/
bvBTkBletE9nOn/EkPdg+9zEONXacA7wYk0df3kCi4hsC6suqvc+YU/5yfTw9ZOa
ImL9m5KAK5dw46Bnpvi/HnJKxyX3toRi0vKXeceYFphsqpTml5NxiJWmRfSnDQkh
+5cae/STiGhSW169ibl6Y6iZHd+B5ay1que8IITDIcKlXO1D4uPK0Z6StavfPjtu
6BwSkegcBy+lvNgAewxWjR4B1AqH40Q71nzBwQa/sXqf/hiZZzeAkHq0+Ze5KWNd
7gGy74AfvxkzW4pOJBZKkAVZ7E12ggBNsk4tbpUhpZC2QQxn6k3cZfogYTeBG4q6
10jJEEKGkA9QxKtS1vmQsHYVOCMPt+hAsd0E40hUi8/YxbD5dKz/DXBdSWSedoMt
ACnCdxQIZEbkGFtYTH1jJ1PfAN/yyJhsojndp6Dx47ZoZqepFieRpF9Qw6OXnQDC
3/rPI2Lte+HpS6WAv/PZq5q0MvBGie2GOv50UESVbbGPaJLCZt5gZEw0kCdk0a+S
P/vybf17YNVc3XHQEYaPXTsUkD7IZl8VopN6Pjyr7xnaLWR44X8=
=5zH+
-END PGP SIGNATURE-

Bug#906062: esptool: Doesn't support recent bootloaders; needs new upstream

2018-08-13 Thread Jonathan McDowell

Package: esptool
Version: 2.1+dfsg1-2
Severity: important
Tags: upstream

Please update this package to a more recent upstream, it is not reliable
for development with current Espressif SDKs for the ESP8266 and I find I
waste a lot of time with bad flashes or image creation that work just
fine with the upstream esptool.py. 2.5 is now current, but 2.4 fixes
compatibility with recent bootloaders.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages esptool depends on:
ii  python3 3.6.5-3
ii  python3-ecdsa   0.13-3
ii  python3-pyaes   1.6.1-1
ii  python3-serial  3.4-4

esptool recommends no packages.

esptool suggests no packages.

-- no debconf information

Bug#900552: Bug #900552: Add privacy policy to the Debian website

2018-07-29 Thread Jonathan McDowell

On Sat, Jul 28, 2018 at 01:03:23AM +0200, Laura Arjona Reina wrote:
> Sorry for the delay in dealing with this.
> 
> I have created the merge request
> 
> https://salsa.debian.org/webmaster-team/webwml/merge_requests/10
> 
> with what I think it's ready to be published:
> 
> * The document /english/legal/privacy.wml (Section of LDAP
> updated-expanded, as per conversation with the team at
> data-protect...@debian.org)
> 
> * Updated /english/legal/index.wml to link to the new document
> 
> * Updated the footer in homepage and other pages to include "Legal Info"
> and "Data Privacy" in the "About" section.
> 
> I'm attaching a diff, with these changes (the same that are included in
> the merge request), and the result of a local build of
> /legal/index.en.html and /legal/privacy.en.html files.
> 
> If there are not objections, I will merge this in 2-3 days.

Thanks. This all looks good to me. Once it's merged we can make the
project as a whole aware and collate any clean-ups that service owners
come forward with.

J.

-- 
I'm a *daemon*! Demons are evil. Daemons are not!
This .sig brought to you by the letter J and the number 39
Product of the Republic of HuggieTag

Bug#897838: Pulseview GCC8 fix pending

2018-07-29 Thread Jonathan McDowell

Control: tags -1 + pending
Control: block -1 by 897895

I've backported the upstream fix to 0.4.0 but the build still fails due
to #897895 in libsigc++2.0. It's fixed upstream so once that hits
unstable I can upload:

https://github.com/libsigcplusplus/libsigcplusplus/issues/1

J.

-- 
   Life would be easier if I had   |  .''`.  Debian GNU/Linux Developer
 the source code.  | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Bug#886817: x86info: Crashes with "readEntry: Bad address"

2018-07-13 Thread Jonathan McDowell

Package: x86info
Version: 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1+b1
Followup-For: Bug #886817

I see this too on an Intel(R) Xeon(R) CPU E3-1270 V2 in a Dell Poweredge
T110, but only when I run as root. Running as a normal user gives:

$ x86info
x86info v1.31pre  Dave Jones 2001-2011
Feedback to .

Found 8 identical CPUs
Extended Family: 0 Extended Model: 3 Family: 6 Model: 58 Stepping: 9
Type: 0 (Original OEM)
CPU Model (x86info's best guess): Unknown model.
Processor name string (BIOS programmed): Intel(R) Xeon(R) CPU E3-1270 V2 @ 
3.50GHz

Total processor threads: 8
This system has 1 quad-core processor with hyper-threading (2 threads per core) 
running at an estimated 3.50GHz

Failing case:

# x86info
x86info v1.31pre  Dave Jones 2001-2011
Feedback to .

readEntry: Bad address
Found 8 identical CPUserror reading 1K from 0x9e400

And dmesg:

[357069.945561] memremap attempted on mixed range 0x0009e000 size: 
0x1000
[357069.945570] WARNING: CPU: 7 PID: 30032 at 
/build/linux-uwVqDp/linux-4.16.16/kernel/memremap.c:98 memremap+0x104/0x170
[357069.945571] Modules linked in: nfnetlink nfsv3 nfs_acl rpcsec_gss_krb5 
auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache devlink uas usb_storage 
fuse rfcomm bnep binfmt_misc snd_hda_codec_hdmi snd_hda_intel snd_hda_codec 
snd_hda_core btusb snd_usb_audio btrtl snd_usbmidi_lib btbcm btintel 
snd_rawmidi snd_seq_device snd_hwdep snd_pcm bluetooth snd_timer snd drbg 
ansi_cprng ftdi_sio tpm_tis tpm_tis_core tpm nouveau mxm_wmi video mgag200 
usbserial dcdbas iTCO_wdt ecdh_generic iTCO_vendor_support rfkill intel_rapl 
ttm drm_kms_helper x86_pkg_temp_thermal intel_powerclamp soundcore drm evdev 
coretemp rng_core i2c_algo_bit kvm_intel lpc_ich sg kvm shpchp ie31200_edac 
irqbypass button wmi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
intel_cstate ipmi_si ipmi_devintf pcspkr ipmi_msghandler intel_uncore
[357069.945610]  intel_rapl_perf jc42 parport_pc ppdev sunrpc lp parport 
ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb 
dm_mod sr_mod cdrom sd_mod hid_generic usbhid hid crc32c_intel ahci libahci 
libata scsi_mod aesni_intel ehci_pci aes_x86_64 crypto_simd ehci_hcd cryptd 
glue_helper tg3 i2c_i801 libphy usbcore usb_common thermal fan
[357069.945633] CPU: 7 PID: 30032 Comm: x86info Not tainted 4.16.0-2-amd64 #1 
Debian 4.16.16-2
[357069.945633] Hardware name: Dell Inc. PowerEdge T110 II/0PM2CW, BIOS 2.8.0 
06/24/2014
[357069.945636] RIP: 0010:memremap+0x104/0x170
[357069.945637] RSP: 0018:b559087dfe48 EFLAGS: 00010282
[357069.945638] RAX:  RBX: 0400 RCX: 
0006
[357069.945639] RDX: 0007 RSI: 0086 RDI: 
9427ffdd6730
[357069.945640] RBP: 0001 R08: 051e R09: 
0004
[357069.945640] R10:  R11: 0001 R12: 
1000
[357069.945641] R13: 7ffdcc99ce90 R14: 94255dff4000 R15: 

[357069.945642] FS:  7f73d042f740() GS:9427ffdc() 
knlGS:
[357069.945643] CS:  0010 DS:  ES:  CR0: 80050033
[357069.945644] CR2: 7ffdcc99ce80 CR3: 0002cb906006 CR4: 
001606e0
[357069.945645] Call Trace:
[357069.945652]  xlate_dev_mem_ptr+0x25/0x40
[357069.945656]  read_mem+0x6b/0x180
[357069.945659]  vfs_read+0x89/0x130
[357069.945660]  SyS_read+0x52/0xc0
[357069.945663]  do_syscall_64+0x6c/0x130
[357069.945667]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[357069.945669] RIP: 0033:0x7f73cfd7f061
[357069.945669] RSP: 002b:7ffdcc99ce48 EFLAGS: 0246 ORIG_RAX: 

[357069.945671] RAX: ffda RBX: 0400 RCX: 
7f73cfd7f061
[357069.945671] RDX: 0400 RSI: 7ffdcc99ce90 RDI: 
0003
[357069.945672] RBP: 0008 R08: 0001 R09: 
7ffdcc9dcdc7
[357069.945673] R10:  R11: 0246 R12: 
0009e400
[357069.945674] R13: 7ffdcc9dced8 R14: 7ffdcc99ce90 R15: 
7ffdcc99ce7e
[357069.945675] Code: 48 83 c4 08 5b 5d 41 5c c3 80 3d 5f 49 f5 00 00 75 b7 4c 
89 e2 48 89 e6 48 c7 c7 f0 42 e3 9a c6 05 49 49 f5 00 01 e8 1c 9d ed ff <0f> 0b 
eb 9a 4c 89 e6 48 89 df e8 6d 4b ec ff 48 85 c0 74 99 48
[357069.945700] ---[ end trace 43bb71df74c44b55 ]---


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'testing-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages x86info depends on:
ii  libc62.27-3
ii  libpci3  1:3.5.2-1
ii  udev 239-5

x86info recommends no packages.

x86info suggests no packages.

-- no debconf information

Bug#897838: gcc-8 patch already upstream

2018-06-16 Thread Jonathan McDowell

Control: tags -1 + fixed-upstream

This is already fixed upstream:

https://sigrok.org/gitweb/?p=pulseview.git;a=commit;h=30677c1392b54604b01558cf29b44572731659fc

It has not yet been part of a release; if we get to the point that gcc-8
is the default and there's still no new upstream release I'll back port
it, but otherwise wait until a new upstream.

J.

-- 
/-\ | Purrr.
|@/  Debian GNU/Linux Developer |
\-  |

1 2 3 4 >

1 - 100 of 358 matches

Mail list logo