Bug#1056183: texlive-luatex: lualatex exits immediately due to new zlib

2023-11-18 Thread Nick Black (Public gmail account)
Package: texlive-luatex
Version: 2023.20231007-1
Severity: important
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I recently updated zlib1g:amd64 (1:1.2.13.dfsg-3, 1:1.3.dfsg-2) in unstable.

lualatex immediately stopped working, with the error:

[schwarzgerat](0) $ lualatex
PANIC: unprotected error in call to Lua API (zlib library version does not
match - header: 1.2.13, library: 1.3)
Aborted (core dumped)
[schwarzgerat](134) $

Should just need a rebuild, but perhaps this (unnecessary?) check ought be
removed? Isn't this what SOVERSIONs are for?


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2496 2023-11-10 04:56 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2022-10-12 17:25 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2023-10-08 16:00 /usr/share/texlive/texmf-dist/ls-R 
-> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2023-10-08 16:00 /usr/share/texlive/texmf-dist/ls-R 
-> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2023-08-28 14:30 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2023-10-08 16:00 /usr/share/texmf/web2c/fmtutil.cnf 
-> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2023-10-08 16:00 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5289 2023-11-10 04:54 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2016-02-22 09:54 mktex.cnf
-rw-r--r-- 1 root root 475 2023-08-28 14:30 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.9nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-luatex depends on:
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1
ii  lmodern   2.005-1
ii  tex-common6.18
ii  texlive-base  2023.20231007-1
ii  texlive-binaries  2023.20230311.66589-7

texlive-luatex recommends no packages.

texlive-luatex suggests no packages.

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.8

Versions of packages texlive-luatex is related to:
ii  tex-common6.18
ii  texlive-binaries  2023.20230311.66589-7

-- no debconf information



Bug#1051290: Acknowledgement (fonts-sil-gentiumplus: gentium plus v6.200 has been released)

2023-09-20 Thread Nick Black (Public gmail account)
i've uploaded 6.200, and it has entered unstable. this bug can be closed.



Bug#1051290: fonts-sil-gentiumplus: gentium plus v6.200 has been released

2023-09-05 Thread Nick Black (Public gmail account)
Package: fonts-sil-gentiumplus
Version: 6.101-1
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Gentium Plus v6.200 was released 2023-02-01.

I'd really like to be able to use U+2227/U+2228 from this great font, among
other recent changes.

Please package the new version when you find time. Thank you!


-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  fontconfig 2.14.2-5  amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.13.2+dfsg-1 amd64FreeType 2 font engine, 
shared library files
ii  libxft2:amd64  2.3.6-1   amd64FreeType-based font drawing 
library for X

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.9nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information



Bug#1036960: plocate: coredump on any search

2023-05-30 Thread Nick Black (Public gmail account)
Package: plocate
Version: 1.1.18-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

   * What led up to the situation?

I've been using plocate for many months on all my machines without problems.
Recently, I get a coredump on any search, on all the machines on which I've
tested. I've got a stack trace that points at do_search_file():

Thread 1 (Thread 0x7f426c687740 (LWP 914015) "locate"):
#0  __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7f426c2a9d2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f426c25aef2 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3  0x7f426c245472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7f426c29e2d0 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f426c3b8459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5  0x7f426c2b364a in malloc_printerr (str=str@entry=0x7f426c3b60b1
"free(): invalid pointer") at ./malloc/malloc.c:5660
#6  0x7f426c2b53d4 in _int_free (av=, p=,
have_lock=have_lock@entry=0) at ./malloc/malloc.c:4435
#7  0x7f426c2b7d2f in __GI___libc_free (mem=) at
./malloc/malloc.c:3385
#8  0x5617abf86e1a in do_search_file (needles=std::vector of length 1,
capacity 1 = {...}, filename="plocate.db") at ../plocate.cpp:491
#9  0x5617abf804b8 in main (argc=, argv=) at
../plocate.cpp:995

this also happens with an empty database.


-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.4nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages plocate depends on:
ii  adduser 3.134
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libstdc++6  12.2.0-14
ii  liburing2   2.3-3
ii  libzstd11.5.4+dfsg2-5

plocate recommends no packages.

Versions of packages plocate suggests:
ii  nocache 1.1-1+b1
ii  powermgmt-base  1.37
ii  systemd-sysv252.6-1

-- Configuration Files:
/etc/updatedb.conf changed:
PRUNE_BIND_MOUNTS="yes"
PRUNEPATHS="/tmp /var/spool /media/usb /media/dank /media/mtp /media/killermike 
/var/lib/os-prober /var/lib/ceph /home/.ecryptfs /var/lib/schroot"
PRUNEFS="NFS afs autofs binfmt_misc ceph cgroup cgroup2 cifs coda configfs 
curlftpfs debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fuse.cryfs 
fuse.encfs fuse.glusterfs fuse.gocryptfs fuse.gvfsd-fuse fuse.mfs fuse.rclone 
fuse.rozofs fuse.sshfs fusectl fusesmb hugetlbfs iso9660 lustre lustre_lite mfs 
mqueue ncpfs nfs nfs4 ocfs ocfs2 proc pstore rpc_pipefs securityfs shfs smbfs 
sysfs tmpfs tracefs udev udf usbfs"


-- no debconf information



Bug#1032620: doctest: new 2.4.10 out, fixes pernicious bugs

2023-03-10 Thread Nick Black (Public gmail account)
Source: doctest
Version: 2.4.9~ds-1
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Hello! My package notcurses depends on doctest. doctest 2.4.9 was released with
some issues that led to FTBFS without patchery. Thankfully, 2.4.10 has these
fixed. Hopefully it's possible to get an upgrade in before hard freeze. Thanks!


-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.2.2nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)



Bug#1018106: sshd: pam_env(sshd:session): deprecated reading of user environment enabled

2023-02-01 Thread nick black
the cause of this output is the following line in /etc/pam.d/sshd:

  # In Debian 4.0 (etch), locale-related environment variables were moved to
  # /etc/default/locale, so read that as well.
  sessionrequired pam_env.so user_readenv=1 envfile=/etc/default/locale

i'm guessing from the comment that user_readenv=1 is in place
primarily to allow overrides of the default locale? etch was
quite some time ago, possibly preceding support for SendEnv?
that seems sufficient workaround if user_readenv is deprecated,
but this is all speculative.



Bug#1027976: ITP: libcpucycles -- Microlibrary for counting CPU cycles

2023-01-05 Thread Nick Black (Public gmail account)
Package: wnpp
Severity: wishlist
Owner: nick black  
X-Debbugs-Cc: debian-de...@lists.debian.org, dankamong...@gmail.com

* Package name: libcpucycles
  Version : 20230105
  Upstream Contact: Daniel J. Bernstein 
* URL : https://cpucycles.cr.yp.to/download.html
* License : Public domain
  Programming Lang: C
  Description : Microlibrary for counting CPU cycles

libcpucycles understands machine-level cycle counters for amd64 (both PMC and
TSC), arm32, arm64 (both PMC and VCT), mips64, ppc32, ppc64, riscv32, riscv64,
sparc64, and x86. libcpucycles also understands four OS-level mechanisms, which
give varying levels of accuracy: mach_absolute_time, perf_event,
CLOCK_MONOTONIC, and, as a fallback, microsecond-resolution gettimeofday.

When the program first calls cpucycles(), libcpucycles automatically benchmarks
the available mechanisms and selects the mechanism that does the best job.
Subsequent cpucycles() calls are thread-safe and very fast. An accompanying
cpucycles-info program prints a summary of cycle-counter accuracy.



Bug#1027820: nctetris man page: bad description in NAME section

2023-01-03 Thread nick black
https://github.com/dankamongmen/notcurses/issues/2693

thanks! i'll fix this upstream and report here.



Bug#1027035: libcpuset1: cpuset.3 references nonexistent bootcpuset.8, bootcpuset.conf.5

2022-12-26 Thread Nick Black (Public gmail account)
Package: libcpuset1
Version: 1.0-6+b1
Severity: minor
Tags: upstream
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

The cpuset.3 man page references bootcpuset.8 and bootcpuset.conf.5. Neither of
these man pages appear to exist in any package.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcpuset1 depends on:
ii  libbitmask1  2.0-5
ii  libc62.36-7

libcpuset1 recommends no packages.

libcpuset1 suggests no packages.

-- no debconf information



Bug#1024089: ITP: accel-config -- Utility for configuring the DSA subsystem for Linux

2022-11-14 Thread nick black
Colin Ian King left as an exercise for the reader:
> Package: wnpp
> Severity: wishlist
> Owner: Colin Ian King 
> X-Debbugs-Cc: debian-de...@lists.debian.org

Hey Colin! I'm hoping to work with the Intel folks on this, and
it seems you started the endeavor and guided it thus far. Can I
assist you in any way at the moment?

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature


Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

2022-10-14 Thread nick black
i'm pretty sure that the corruption issues leading to the
nodelalloc option were considered largely remedied by the
"auto_da_alloc" capability introduced (and enabled by default)
in 2.6.30? how would nodelalloc equal the performance of
delalloc? nodelalloc was all about reliability for programs that
weren't conforming to certain POSIX semantics, as i recall.



Bug#1021639: wayfire: symbol lookup error: wayfire: undefined symbol: wlr_backend_get_renderer

2022-10-11 Thread Nick Black (Public gmail account)
Version: 0.7.4-2
close 1021639


i'm stupid. /usr/local strikes again. sorry!


signature.asc
Description: PGP signature


Bug#1021639: wayfire: symbol lookup error: wayfire: undefined symbol: wlr_backend_get_renderer

2022-10-11 Thread Nick Black (Public gmail account)
Package: wayfire
Version: 0.7.4-2
Severity: important
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I installed wayfire 0.7.4-2, and attempted to run wayfire. It refused to start,
due to an undefined symbol. Prior to this, it printed several diagnostics, so
I'm guessing this symbol is used by some plugin or dynlib.

[schwarzgerat](0) $ wayfire
II 11-10-22 21:58:23.668 - [src/main.cpp:288] Starting wayfire version
0.8.0-bbe63a72 (Dec  1 2021, branch 'master')
II 11-10-22 21:58:23.669 - [backend/x11/backend.c:397] Creating X11 backend
II 11-10-22 21:58:23.669 - [backend/x11/backend.c:480] X11 does not support
shared pixmaps
EE 11-10-22 21:58:23.669 - [backend/x11/backend.c:609] Failed to query DRI3 DRM
FD
wayfire: symbol lookup error: wayfire: undefined symbol:
wlr_backend_get_renderer

Also, is the version number correct? The diagnostic indicates 0.8.0, but the
package is 0.7.4.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.14nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wayfire depends on:
ii  libc62.35-3
ii  libcairo21.16.0-6
ii  libgcc-s112.2.0-5
ii  libgles2 1.5.0-1
ii  libglib2.0-0 2.74.0-2
ii  libinput10   1.21.0-1
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpixman-1-00.40.0-1
ii  libpng16-16  1.6.38-2
ii  libstdc++6   12.2.0-5
ii  libwayland-server0   1.21.0-1
ii  libwf-config10.7.1-2
ii  libwf-utils0 0.7.4-2
ii  libwlroots10 0.15.1-3
ii  libxcb1  1.15-1
ii  libxkbcommon01.4.1-1

wayfire recommends no packages.

wayfire suggests no packages.

-- no debconf information



Bug#1021049: fritzing: new version 0.9.10 is available

2022-10-01 Thread Nick Black (Public gmail account)
Package: fritzing
Version: 0.9.6+dfsg-2+b1
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Version 0.9.10 of fritzing was released 2022-05-22. It includes a beta
simulator, a powerful new addition to fritzing. It would be great to have it in
Debian. If you need assistance updating, I'm happy to help out; if you were
unaware of the new version, just making you aware =].

Thanks for your efforts.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.11nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fritzing depends on:
ii  fritzing-data0.9.6+dfsg-2
ii  fritzing-parts   0.9.6~unreleased-1
ii  libc62.35-1
ii  libgcc-s112.2.0-3
ii  libgit2-1.3  1.3.0+dfsg.1-3
ii  libqt5core5a 5.15.4+dfsg-5
ii  libqt5gui5   5.15.4+dfsg-5
ii  libqt5network5   5.15.4+dfsg-5
ii  libqt5printsupport5  5.15.4+dfsg-5
ii  libqt5serialport55.15.4-2
ii  libqt5sql5   5.15.4+dfsg-5
ii  libqt5sql5-sqlite5.15.4+dfsg-5
ii  libqt5svg5   5.15.4-2
ii  libqt5widgets5   5.15.4+dfsg-5
ii  libqt5xml5   5.15.4+dfsg-5
ii  libstdc++6   12.2.0-3
ii  zlib1g   1:1.2.11.dfsg-4.1

fritzing recommends no packages.

fritzing suggests no packages.

-- no debconf information



Bug#1020676: prometheus-mqtt-exporter: new version available (0.1.6)

2022-09-24 Thread Nick Black (Public gmail account)
Package: prometheus-mqtt-exporter
Version: 0.1.4-2+b9
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I was attempting to determine why promtheus-mqtt-exporter as packaged in Debian
wasn't honoring the MQTT2PROM_MQTT_USER and _PASSWORD variables defined in a
systemd override file. It appears that the version being shipped is 0.1.4.
Version 0.1.6 has been available from upstream for some time now (since
January), and adds support for these variables. It would be good to upgrade, I
think.

I'm also wondering whether this fixes a problem I was seeing where metrics were
being dropped. I'm going to grab 0.1.6, built it myself, and see what happens.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.10nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages prometheus-mqtt-exporter depends on:
ii  init-system-helpers  1.65.2
ii  libc62.35-1
ii  systemd-sysv 251.4-3

prometheus-mqtt-exporter recommends no packages.

prometheus-mqtt-exporter suggests no packages.

-- Configuration Files:
/etc/prometheus/mqtt-exporter.yaml changed:
mqtt:
  # The MQTT broker to connect to
  server: tcp://localhost:1883
  # user and password are specified in systemd dropin
  topic_path: mora3
  # Optional: Regular expression to extract the device ID from the topic path. 
The default regular expression, assumes
  # that the last "element" of the topic_path is the device id.
  # The regular expression must contain a named capture group with the name 
deviceid
  # For example the expression for tasamota based sensors is 
"tele/(?P.*)/.*"
  # device_id_regex: "(.*/)?(?P.*)"
  # The MQTT QoS level
  qos: 0
cache:
  # Timeout. Each received metric will be presented for this time if no update 
is send via MQTT.
  # Set the timeout to -1 to disable the deletion of metrics from the cache. 
The exporter presents the ingest timestamp
  # to prometheus.
  timeout: 60m
metrics:
  -
prom_name: mora3coolant
mqtt_name: therm
help: Coolant temperature as measured at MO-RA3
type: gauge
const_labels:
  sensor_type: k10
  -
prom_name: mora3rpm
mqtt_name: rpm
help: RPM measurements from MO-RA3 fans
type: gauge
const_labels:
  sensor_type: arcticp14


-- no debconf information



Bug#1016883: prometheus service ought depend on time-sync

2022-08-08 Thread Nick Black (Public gmail account)
Package: prometheus
Version: 2.24.1+ds-1
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I run prometheus on a Libre Computer Potato SBC, lacking an RTC,
collecting from prometheus-node-exporter on my workstation. In the
default configuration, prometheus fills logs with errors along the lines
of:

Aug 08 17:00:40 amoled prometheus[2337]: level=warn ts=2022-08-08T21:00:40.522Z 
caller=scrape.go:1372 component="scrape manager" scrape_pool=prometheus 
target=http://localhost:9090/metrics msg="Error on ingesting out-of-order 
samples" num_dropped=404

and doesn't append to my records. Upon restarting promtheus with

  systemctl restart prometheus

the problem goes away, and I can begin collecting stats anew.

I believe this is due to the prometheus service not depending on
time-sync.target. I've added

  [Unit]
  Before=time-sync.target
  Wants=time-sync.target

to a drop-in, and with this change, I do not hit the problem.

Given prometheus's fundamental dependency on time-ordered databases, I
feel this dependency ought be present in the default prometheus systemd
unit.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.15nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages prometheus depends on:
ii  adduser  3.123
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-2
ii  init-system-helpers  1.64
ii  libc62.34-1
ii  libjs-bootstrap4 4.6.1+dfsg1-3
pn  libjs-eonasdan-bootstrap-datetimepicker  
ii  libjs-jquery 3.6.0+dfsg+~3.5.13-1
ii  libjs-jquery-hotkeys 0~20130707+git2d51e3a9+dfsg-2.1
pn  libjs-moment 
pn  libjs-moment-timezone
pn  libjs-mustache   
ii  libjs-popper.js  1.16.1+ds-5
pn  libjs-rickshaw   

Versions of packages prometheus recommends:
ii  prometheus-node-exporter  1.3.1-1+b1

prometheus suggests no packages.



Bug#1015747: libnotcurses-core-dev: missing dependency on libtinfo-dev

2022-07-21 Thread nick black
thanks for the report. i'll look into it ASAP! it seems it ought
be pretty simple to fix.



Bug#799549: systemd: Provide system-log-daemon

2022-06-09 Thread nick black
i'm running into this thanks to zoneminder (it looks like some
packages which were depending on rsyslogd|system-log-daemon, ala
the aforementioned nullmailer, no longer do). looking at
/var/lib/dpkg/info/systemd.postinst, it appears that persistent
journal in auto-mode *is* enabled by default on new installs and
upgrades:

 # Enable persistent journal, in auto-mode, by default on new installs and 
upgrades
 if dpkg --compare-versions "$2" lt "244.1-2~"; then
 mkdir -p /var/log/journal

ought this bug be revisited given this fact? i see the last
comment is from 2017, and systemd 244 was released in 2019.

i see reference to some other, small package which enables
persistent logging, but i'm unaware of any such package, and it
seems unlikely to exist given the code above.


signature.asc
Description: PGP signature


Bug#1009050: libcpuset1: man page references wrong path for documentation

2022-04-06 Thread Nick Black (Public gmail account)
Package: libcpuset1
Version: 1.0-6
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

CPUSET.3 claims

"For  additional  documentation  on  cpusets,  and  for  details  of  the  all  
the   other,   advanced,   routines,   see
 /usr/share/doc/packages/libcpuset/libcpuset.html and
 /usr/share/doc/packages/libbitmask/libbitmask.html.   These  same  documents  
are  available  in  plain  text  format  as
 /usr/share/doc/packages/libcpuset/libcpuset.txt and
 /usr/share/doc/packages/libbitmask/libbitmask.txt."

The actual paths are /usr/share/doc/libcpuset-dev/*


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.1nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcpuset1 depends on:
ii  libbitmask1  2.0-4
ii  libc62.33-7

libcpuset1 recommends no packages.

libcpuset1 suggests no packages.

-- no debconf information



Bug#1001661: Info received (Bug#1001661: Info received ((no subject)))

2022-04-04 Thread nick black
wait...even the most recent of these logs shows that it is
testing notcurses 3.0.4, which indeed had this timing problem on
input, which was fixed in notcurses 3.0.5:

Get:1 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (dsc) 
[3,148 B]   

 
Get:2 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (tar) 
[7,391 kB]  

 
Get:3 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (asc) 
[833 B] 

 
Get:4 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (diff) 
[17.1 kB] 

but apt-show-versions confirms only 3.0.7 in the archive:

[schwarzgerat](0) $ apt-show-versions -a notcurses-bin
notcurses-bin:amd64 3.0.7+dfsg.1-1 install ok installed
No stable version
No testing version
notcurses-bin:amd64 3.0.7+dfsg.1-1 unstable ftp.us.debian.org
No experimental version
notcurses-bin:amd64/unstable 3.0.7+dfsg.1-1 uptodate
[schwarzgerat](0) $

oh, i guess "No testing version" indicates it's gone from
testing. so why isn't 3.0.7 in unstable the candidate for
testing? 3.0.4 is definitely known to be bad.



Bug#1001661: Info received ((no subject))

2022-04-04 Thread nick black
i'm tracking this upstream at 
https://github.com/dankamongmen/notcurses/issues/2645



Bug#1001661: notcurses: flaky autopkgtests on armhf

2022-04-04 Thread nick black
i'm pretty sure raspberry pi is armhf, so i ought be able to dig
that one RPi4 i've got up and explore this. if we can reproduce
the problem interactively, it ought fall pretty quickly.



Bug#1001661: (no subject)

2022-04-03 Thread nick black
note that armhf is a 32-bit arm7 machine, unlike arm64 which is
arm8. might be time to revisit some assumptions unconsciously
made involving processor width.



Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1

2022-02-28 Thread nick black
> However, I don't think that adding lmodern to the package Depends is the
> right solution, as that would lead to parts of tex (admittely, a small
> part, but still) having to be installed on the system, which is not
> required by pandoc itself.
> The right solution, I believe, is to add lmodern to the tests/control
> Depends, and I've just realized that I prepared that in git, but I never
> actually did the upload (ups), and was wondering why it wasn't
> working.

agreed, so long as it's not required by most outputs (i.e. you
can run pypandoc without it and it works).

> I will do the upload myself in the next few days, since I have an
> up-to-date copy of the repo locally (and salsa is down).

alrightie. this was my NM application bug; i guess i will find
another one. have a good day!


signature.asc
Description: PGP signature


Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1

2022-02-28 Thread nick black
Control: tags 1005778 + patch
Control: tags 1005778 + pending

Dear maintainer,

I've prepared an NMU for pypandoc (versioned as 1.7.2+ds0-1.1) and
it will be uploaded by my Account Manager, Sebastian Ramacher.
Please feel free to tell me if he should delay it.

lmodern needed be listed as a regular Depends, not just a
Build-Depends, in order for the autopkgtests to successfully
run. I have added it, and verified that this fixes the
autopkgtests on the testing distribution.

hack on, nick
diff -Nru pypandoc-1.7.2+ds0/debian/changelog pypandoc-1.7.2+ds0/debian/changelog
--- pypandoc-1.7.2+ds0/debian/changelog	2021-12-29 05:19:10.0 -0500
+++ pypandoc-1.7.2+ds0/debian/changelog	2022-02-28 10:12:41.0 -0500
@@ -1,3 +1,11 @@
+pypandoc (1.7.2+ds0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add dependency on lmodern for runtime to fix autopkgtests.
+Closes: #1005778
+
+ -- Nick Black   Mon, 28 Feb 2022 10:12:41 -0500
+
 pypandoc (1.7.2+ds0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru pypandoc-1.7.2+ds0/debian/control pypandoc-1.7.2+ds0/debian/control
--- pypandoc-1.7.2+ds0/debian/control	2021-12-29 05:19:10.0 -0500
+++ pypandoc-1.7.2+ds0/debian/control	2022-02-28 10:10:24.0 -0500
@@ -27,6 +27,7 @@
 Package: python3-pypandoc
 Architecture: all
 Depends:
+ lmodern,
  pandoc,
  ${misc:Depends},
  ${python3:Depends}


Bug#1006139: libdeflate on armhf

2022-02-21 Thread nick black
hi, notcurses maintainer here. if you're going to proceed with this, the thing 
to do is mark notcurses as depending on zlib instead of libdeflate on this 
architecture, and build with `-DUSE_LIBDEFLATE=off`. the only differences ought 
be performance-related.



Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

2022-02-05 Thread nick black
ahh, rereading your original ITP, i see you know all about the
fdo situation. good deal =]. i just killed my fork, and am going
to submit a PR to Aetf's fork.


signature.asc
Description: PGP signature


Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

2022-02-05 Thread nick black
also, there is a kmscon repo under the auspices of the
freedesktop.org organization. i talked to the original author
about removing that if he wasn't going to be taking the project
forward, but it didn't go anywhere. if someone's really picking
kmscon up, they might want to go talk to the fdo people.


signature.asc
Description: PGP signature


Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

2022-02-05 Thread nick black
indeed, the cursor location report fix is only on a branch. i'll
go ahead and submit it to this other fork, and rebase mine off
of theirs. thank you likewise for bringing this to my attention!
i'm glad to see kmscon getting some love.

i'm the maintainer and upstream author of Notcurses, and kmscon
is very much a target of mine. if you'd like to integrate any
Notcurses stuff into your testing, just hit me up; i'd be happy
to help!


signature.asc
Description: PGP signature


Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

2022-02-04 Thread nick black
Victor Westerhuis left as an exercise for the reader:
> Package: wnpp
> Severity: wishlist
> Owner: Victor Westerhuis 
> X-Debbugs-Cc: debian-de...@lists.debian.org

i've also forked this, and have been working on it a bit over
the past year:

 https://github.com/dankamongmen/kmscon

if the other fork is more active, i'm happy to fold my changes
into it, but they definitely ought go in there. the most
important thing i recall doing was fixing the cursor location
report to use the proper order for coordinates.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature


Bug#1004473: mutrace -d fails to load missing _sch_istable symbol

2022-01-28 Thread Nick Black (Public gmail account)
Package: mutrace
Version: 0.2.0-3.4+b2
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Trying to use mutrace with the -d option fails:

[schwarzgerat](1) $ mutrace -d ls
ls: symbol lookup error: /usr/lib/mutrace/libmutrace-backtrace-symbols.so: 
undefined symbol: _sch_istable
[schwarzgerat](127) $

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.1nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mutrace depends on:
ii  libc6  2.33-5

mutrace recommends no packages.

mutrace suggests no packages.

-- no debconf information



Bug#1004100: stterm: new upstream release 0.8.5 fixes OSC4 failure

2022-01-20 Thread Nick Black (Public gmail account)
Package: stterm
Version: 0.8.4-1
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I'm the developer of Notcurses, a TUI library. I ran into a bug with st
on Debian Unstable, where the OSC4 palette query resulted in a
diagnostic and emitted garbage characters:

  https://github.com/dankamongmen/notcurses/issues/2561

It turned out the upstream doesn't have this problem, and that it has
been fixed in the 0.8.5 release from two weeks ago. Please consider
updating the package. Thanks!

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages stterm depends on:
ii  libc6   2.33-3
ii  libfontconfig1  2.13.1-4.2
ii  libx11-62:1.7.2-2+b1
ii  libxft2 2.3.2-2
ii  ncurses-term6.3-2

stterm recommends no packages.

stterm suggests no packages.

-- no debconf information



Bug#997845: Info received (Bug#997845: growlight: autopkgtest regression: log repeats until it times out)

2022-01-10 Thread nick black
notcurses 3.0.4+dfsg.1-1 ought be migrating to testing soon, and
if there is any love in this world, it will resolve the
continued failures. the most recent i see is from today, still
using notcurses 3.0.3.

i added several similar unit tests to the notcurses suite, and
managed to reproduce the lockup in at least one of its
incarnations. we'll see.



Bug#997845: bug 997845

2022-01-04 Thread nick black
exciting results! i wrapped up a similar invocation and threw it
into my notcurses drone CI, and there i fail exactly as i do
within the debian CI (i.e. we never terminate, though we don't
soak the CPU).

https://drone.dsscaw.com:4443/dankamongmen/notcurses/10240/1/2

i ought now be able to resolve this quickly, as i finally seem
able to reproduce it locally =].


signature.asc
Description: PGP signature


Bug#997845: bug 997845

2022-01-04 Thread nick black
alright, i might have found the root cause. when we declare EOF,
we're not necessarily setting the input poll fd high. as a
result, if the EOF comes at the end of an input burst, and we
rely on such notifications, we miss it.

https://github.com/dankamongmen/notcurses/issues/2521 has more
details.

i need to rerun the autopkgtests with NOTCURSES_LOGLEVEL=7 to
confirm this. Paul, is that possible to do without uploading a
new growlight package?

i think i've got this just about all figured out, and would
appreciate another week or so to get it resolved, if that's
doable.



Bug#997845: Info received (Bug#997845: growlight: autopkgtest regression: log repeats until it times out)

2022-01-03 Thread nick black
wait, i just might have reproduced a failure. it doesn't look
like our failure in autopkgtests, but this is an assert()
blowing up, and i'm not certain we build with those. if not,
maybe we're hitting a case that locks up. let's hope so!

this would once again presumably be a notcurses fix.

the breakage doesn't happen all the time, but it can be provoked
without too much trouble:

No ZFS support in this build.
Couldn't read link at /sys/class/block/securityfs (No such file or directory)
Couldn't read link at /sys/class/block/cgroup2 (No such file or directory)
Couldn't read link at /sys/class/block/pstore (No such file or directory)
Couldn't read link at /sys/class/block/efivarfs (No such file or directory)
Couldn't read link at /sys/class/block/none (No such file or directory)
Couldn't read link at /sys/class/block/systemd-1 (No such file or directory)
Couldn't read link at /sys/class/block/hugetlbfs (No such file or directory)
Couldn't read link at /sys/class/block/mqueue (No such file or directory)
Couldn't read link at /sys/class/block/tracefs (No such file or directory)
Couldn't read link at /sys/class/block/configfs (No such file or directory)
Couldn't read link at /sys/class/block/none (No such file or directory)
Couldn't read link at /sys/class/block/zhomez (No such file or directory)
Couldn't read link at /sys/class/block/chungus (No such file or directory)
Couldn't read link at /sys/class/block/tracefs (No such file or directory)
growlight-readline: ./src/lib/in.c:1852: process_escape: Assertion 
`ictx->amata.used < buflen' failed.
;147;rgb:afaf/afaf/^[\^[]4;148;rgb:afaf/d7d7/^[\^[]4;149;rgb:afaf/d7d7/5f5f^[\^[]4;150;rgb:afaf/d7d7/8787^[\^[]4;151;rgb:afaf/d7d7/afaf^[\^[]4;152;rgb:afaf/d7d7/d7d7^[\^[]4;153;rgb:afaf/d7d7/^[\^[]4;154;rgb:afaf//^[\^[]4;155;rgb:afaf//5f5f^[\^[]4;156;rgb:afaf//8787^[\^[]4;157;rgb:afaf//afaf^[\^[]4;158;rgb:afaf//d7d7^[\^[]4;159;rgb:afaf//^[\^[]4;160;rgb:d7d7//^[\^[]4;161;rgb:d7d7//5f5f^[\^[]4;162;rgb:d7d7//8787^[\^[]4;163;rgb:d7d7//afaf^[\^[]4;164;rgb:d7d7//d7d7^[\^[]4;165;rgb:d7d7//^[\^[]4;166;rgb:d7d7/5f5f/^[\^[]4;167;rgb:d7d7/5f5f/5f5f^[\^[]4;168;rgb:d7d7/5f5f/8787^[\^[]4;169;rgb:d7d7/5f5f/afaf^[\^[]4;170;rgb:d7d7/5f5f/d7d7^[\^[]4;171;rgb:d7d7/5f5f/^[\^[]4;172;rgb:d7d7/8787/^[\^[]4;173;rgb:d7d7/8787/5f5f^[\^[]4;174;rgb:d7d7/8787/8787^[\^[]4;175;rgb:d7d7/8787/afaf^[\^[]4;176;rgb:d7d7/8787/d7d7^[\^[]4;177;rgb:d7d7/8787/^[\^[]4;178;rgb:d7d7/afaf/^[\^[]4;179;rgb:d7d7/afaf/5f5f^[\^[]4;180;rgb:d7d7/afaf/8787^[\^[]4;181;rgb:d7d7/afaf/afaf^[\^[]4;182;rgb:d7d7/afaf/d7d7^[\^[]4;183;rgb:d7d7/afaf/^[\^[]4;184;rgb:d7d7/d7d7/^[\^[]4;185;rgb:d7d7/d7d7/5f5f^[\^[]4;186;rgb:d7d7/d7d7/8787^[\^[]4;187;rgb:d7d7/d7d7/afaf^[\^[]4;188;rgb:d7d7/d7d7/d7d7^[\^[]4;189;rgb:d7d7/d7d7/^[\^[]4;190;rgb:d7d7//^[\^[]4;191;rgb:d7d7//5f5f^[\^[]4;192;rgb:d7d7//8787^[\^[]4;193;rgb:d7d7//afaf^[\^[]4;194;rgb:d7d7//d7d7^[\^[]4;195;rgb:d7d7//^[\^[]4;196;rgb://^[\^[]4;197;rgb://5f5f^[\^[]4;198;rgb://8787^[\^[]4;199;rgb://afaf^[\^[]4;200;rgb://d7d7^[\^[]4;201;rgb://^[\^[]4;202;rgb:/5f5f/^[\^[]4;203;rgb:/5f5f/5f5f^[\^[]4;204;rgb:/5f5f/8787^[\^[]4;205;rgb:/5f5f/afaf^[\^[]4;206;rgb:/5f5f/d7d7^[\^[]4;207;rgb:/5f5f/^[\^[]4;208;rgb:/8787/^[\^[]4;209;rgb:/8787/5f5f^[\^[]4;210;rgb:/8787/8787^[\^[]4;211;rgb:/8787/afaf^[\^[]4;212;rgb:/8787/d7d7^[\^[]4;213;rgb:/8787/^[\^[]4;214;rgb:/afaf/^[\^[]4;215;rgb:/afaf/5f5f^[\^[]4;216;rgb:/afaf/8787^[\^[]4;217;rgb:/afaf/afaf^[\^[]4;218;rgb:/afaf/d7d7^[\^[]4;219;rgb:/afaf/^[\^[]4;220;rgb:/d7d7/^[\^[]4;221;rgb:/d7d7/5f5f^[\^[]4;222;rgb:/d7d7/8787^[\^[]4;223;rgb:/d7d7/afaf^[\^[]4;224;rgb:/d7d7/d7d7^[\^[]4;225;rgb:/d7d7/^[\^[]4;226;rgb://^[\^[]4;227;rgb://5f5f^[\^[]4;228;rgb://8787^[\^[]4;229;rgb://afaf^[\^[]4;230;rgb://d7d7^[\^[]4;231;rgb://^[\^[]4;232;rgb:0808/0808/0808^[\^[]4;233;rgb:1212/1212/1212^[\^[]4;234;rgb:1c1c/1c1c/1c1c^[\^[]4;235;rgb:2626/2626/2626^[\^[]4;236;rgb:3030/3030/3030^[\^[]4;237;rgb:3a3a/3a3a/3a3a^[\^[]4;238;rgb://^[\^[]4;239;rgb:4e4e/4e4e/4e4e^[\^[]4;240;rgb:5858/5858/5858^[\^[]4;241;rgb:6262/6262/6262^[\^[]4;242;rgb:6c6c/6c6c/6c6c^[\^[]4;243;rgb:7676/7676/7676^[\^[]4;244;rgb:8080/8080/8080^[\^[]4;245;rgb:8a8a/8a8a/8a8a^[\^[]4;246;rgb:9494/9494/9494^[\^[]4;247;rgb:9e9e/9e9e/9e9e^[\^[]4;248;rgb:a8a8/a8a8/a8a8^[\^[]4;249;rgb:b2b2/b2b2/b2b2^[\^[]4;250;rgb:bcbc/bcbc/bcbc^[\^[]4;251;rgb:c6c6/c6c6/c6c6^[\^[]4;252;rgb:d0d0/d0d0/d0d0^[\^[]4;253;rgb:dada/dada/dada^[\^[]4;254;rgb:e4e4/e4e4/e4e4^[\^[]4;255;rgb://^[\^[]10;rgb://^[\^[]11;rgb:0808/0808/0808^[\^[[?11u^[[?2026;2$y^[_Gi=1;EINVAL:Zero
 width/height not allowed^[\^[[4;1035;1584t^[[8;45;132t^[[?62;cAborted

Bug#997845: Info received (Bug#997845: growlight: autopkgtest regression: log repeats until it times out)

2022-01-03 Thread nick black
further investigation: i uploaded -4 with a change to simply
redirect input from /dev/null, rather than echoing 'blockdev -v'
into the process. the result was pretty much the exact same: we
don't see the input show up, and we get a time out. of course,
attempting to reproduce this locally leads to the test
immediately exiting on EOF as expected =\.

i notice the command to run the test is rather complicated:

su -s /bin/bash root -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 
2>&1 || true;  . ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.glluyzfl/downtmp/build.A7s/src"; mkdir -p -m 
1777 -- "/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-artifacts"; export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-artifacts";
 export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.glluyzfl/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.glluyzfl/downtmp/autopkgtest_tmp"; export 
ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export 
LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=160; unset LANGUAGE LC_CTYPE 
LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME 
LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f 
/tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set 
+C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd 
"$buildtree"; export AUTOPKGTEST_NORMAL_USER=debci; export 
ADT_NORMAL_USER=debci; touch 
/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stdout 
/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stderr; bash -ec 
'TERM=xterm-256color growlight-readline -v < /dev/null' 2> >(tee -a 
/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stderr >&2) > >(tee -a 
/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stdout);"

maybe our answer lives in this setup? it seems we're redirecting
both stdout and stderr (makes sense)...what else here is
different from our setup? LANG is defined to C.UTF-8. we're
defining TERM ourselves. Notcurses is getting sensibly
initialized. we're just never receiving input, nor an indication
that input is exhausted...



Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere

2022-01-02 Thread nick black
this is addressed in more detail at
https://github.com/dankamongmen/notcurses/issues/2519.
i expect to have this fixed within the hour. sorry for the
annoyance.



Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere

2022-01-02 Thread nick black
reopen 1003009

i added -DBUILD_FFI_LIBRARY=off with the intention of no longer
building these three shared objects. looking at it now, however,
this CMake variable doesn't actually seem to guard their
building and installation, and thus it will not have the desired
effect. i'm fixing this upstream, and will build a -3 with the
necessary patch. sigh.



Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere

2022-01-02 Thread nick black
thanks, this ought be fixed in an hour or two.



Bug#1001815: transition: notcurses

2022-01-01 Thread Nick Black (Public gmail account)
> No, only in unstable [1]. Testing should still work.

hrmm, i'm a bit confused about how this works then. i can only
upload into unstable, and it then needs to pass autopkgtests to
get into testing. oh, i guess those autopkgtests are being run
in the "testing" context? if so, that makes sense.

anyway, uploading 1.2.38-3 to unstable now in the hope of
getting some useful debugging information.


signature.asc
Description: PGP signature


Bug#1001815: transition: notcurses

2021-12-31 Thread Nick Black (Public gmail account)
I see that growlight's autopkgtests are disabled in testing
right now due to the timeout. Can we please remove that, so I
can try something? 

I noticed just now in the growlight testing logs that we have
output of the form e.g.:

xvda14 -> ../../devices/vbd-51712/block/xvda/xvda14
Partition 14 at xvda14
Partition 1 at xvda1
Partition 15 at xvda15
Logical sector size: 512B Physical sector size: 512B

but this isn't "blockdev -v" output; it's just general startup
diagnostics due to calling "growlight-readline -v". we then see
a prompt in the logs:

[growlight](0)> 

that never seems to get any input. i.e. the "echo blockdev -v"
is never hitting it, and that's why it's not shutting down.

success should look like:

^[[64;1H^A^[[0;35m^B[^A^[[0;36m^Bgrowlight^A^[[0;35m^B]^A^[[1;32m^B(0)> 
^A^[[1;37m^B^[[64;1H^[[Kb^[[64;2H^[[64;1H^[[Kbl^[[64;3H^[[64;1H^[[Kblo^[[64;4H^[[64;1H^[[Kbloc^[[64;5H^[[64;1H^[[Kblock^[[64;6H^[[64;1H^[[Kblockd^[[64;7H^[[64;1H^[[Kblockde^[[64;8H^[[64;1H^[[Kblockdev^[[64;9H^[[64;1H^[[Kblockdev
 ^[[64;10H^[[64;1H^[[Kblockdev -^[[64;11H^[[64;1H^[[Kblockdev 
-v^[[64;12H^[[64;1H^[[Kblockdev -v ^[[64;13H
^[[1m^[[38;2;255;255;255mDevice Model Rev   Bytes PSect Flags 
Table WWN  PHY
^[[22m^[[38;2;249;241;165msdjST16000NM000J-2T SN02  16.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . none  5000c500c94d9fd7 SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:31251759104 (14.55Ti)
^[[38;2;249;241;165msdlST12000NM0007-2A SN02  12.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . gpt   5000c500b49867e5 SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:2047 (1Mi)
^[[1m^[[38;2;59;120;255msdl1   53316a63-ce0b-644f-b0de-586da7e95a07  12.00T 
Oth zfs-7f5ed1aa1ce6dbc4
^[[38;2;19;161;14m^[[38;2;59;120;255msdl9   
703b1cea-95bf-a840-8bb8-4336b78ba231   8.39M Oth n/a
^[[38;2;19;161;14m^[[22mUnused sectors 23437768704:23437770752 (1.00Mi)
^[[38;2;249;241;165msdhST12000NM0007-2A SN03  12.00T 4096B M-bM-^XM- 
OWM-bM-^ZM- . gpt   5000c500a5c0e61d SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:2047 (1Mi)
^[[1m^[[38;2;59;120;255msdh1   091bbc74-d66a-3849-af41-42ec40116171  12.00T 
Oth zfs-d60b954b8cc5eae0
^[[38;2;19;161;14m^[[38;2;59;120;255msdh9   
4bcb8333-fb23-d244-8d70-34e9378155d9   8.39M Oth n/a
^[[38;2;19;161;14m^[[22mUnused sectors 23437768704:23437770752 (1.00Mi)
^[[38;2;249;241;165msdkST18000NM000J-2T SN02  18.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . none  5000c500dbd49a2a SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:35156656128 (16.37Ti)
^[[38;2;249;241;165msdiST16000NM000J-2T SN02  16.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . none  5000c500db183d56 SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:31251759104 (14.55Ti)
^[[38;2;249;241;165msdbST12000NM0007-2A SN02  12.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . gpt   5000c500b4104bf5 SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:2047 (1Mi)

or, with the control sequences stripped:

blockdev -v
Device Model Rev   Bytes PSect Flags Table WWN  PHY
sdjST16000NM000J-2T SN02  16.00T 4096B ✔OW⚠. none  5000c500c94d9fd7 SAT3
Unused sectors 0:31251759104 (14.55Ti)
sdlST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b49867e5 SAT3
Unused sectors 0:2047 (1Mi)
sdl1   53316a63-ce0b-644f-b0de-586da7e95a07  12.00T Oth zfs-7f5ed1aa1ce6dbc4
sdl9   703b1cea-95bf-a840-8bb8-4336b78ba231   8.39M Oth n/a
Unused sectors 23437768704:23437770752 (1.00Mi)
sdhST12000NM0007-2A SN03  12.00T 4096B ☠OW⚠. gpt   5000c500a5c0e61d SAT3
Unused sectors 0:2047 (1Mi)
sdh1   091bbc74-d66a-3849-af41-42ec40116171  12.00T Oth zfs-d60b954b8cc5eae0
sdh9   4bcb8333-fb23-d244-8d70-34e9378155d9   8.39M Oth n/a
Unused sectors 23437768704:23437770752 (1.00Mi)
sdkST18000NM000J-2T SN02  18.00T 4096B ✔OW⚠. none  5000c500dbd49a2a SAT3
Unused sectors 0:35156656128 (16.37Ti)
sdiST16000NM000J-2T SN02  16.00T 4096B ✔OW⚠. none  5000c500db183d56 SAT3
Unused sectors 0:31251759104 (14.55Ti)
sdbST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b4104bf5 SAT3
Unused sectors 0:2047 (1Mi)

so i've changed up the autopkgtests to try something.


signature.asc
Description: PGP signature


Bug#1002724: ITP: openfec -- Forward Error Correction codes

2021-12-28 Thread Nick Black (Public gmail account)
Package: wnpp
Severity: wishlist
Owner: "Nick Black (Public gmail account)" 
X-Debbugs-Cc: debian-de...@lists.debian.org, dankamong...@gmail.com

  Package name: openfec
  Version : 1.4.2.4
  Upstream Author : Victor Gaydov  et al
  URL : http://www.example.org/
  License : CeCILL-C
  Programming Lang: C
  Description : Forward Error Correction codes

Application-Level Forward Error Correction codes add
redundancy in order to be able to recover from erasures.

this library is required by the Roc Project, whose PipeWire
modules are currently disabled. With the addition of this
dependency, we will be able to build roc-toolkit, and thus
enable the PipeWire Roc sink and source. indeed, this active
fork of the original OpenFEC is maintained by Roc.

It uses a CeCILL-C license; see [0] for discussion on debian-legal.
In addition, small parts come under Radford Neal's LDPC simulator
license and Luigi Rizzo's Reed-Solomon license ([1]); I have
reviewed both, and they seem trivially compatible with the DFSG.

As a lowly DM, I'll be uploading this through a Sponsor, Dylan Aïssi
from the Utopia team.

[0] https://lists.debian.org/debian-legal/2017/03/msg00019.html
[1] http://openfec.org/patents.html


Bug#1002630: pipewire: enable roc module

2021-12-27 Thread nick black
awesome. i've got one now, but it needs some prettification.
expect it soon.



Bug#997845: growlight: autopkgtest regression: log repeats until it times out

2021-12-26 Thread nick black
i can happily report that notcurses 3.0.2+dfsg.1-3 is passing
autopkgtests, after resolving the issue at

https://github.com/dankamongmen/notcurses/issues/2505


signature.asc
Description: PGP signature


Bug#1002630: pipewire: enable roc module

2021-12-25 Thread Nick Black (Public gmail account)
Package: pipewire
Version: 0.3.42-1
Severity: wishlist
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I see in the changelog "disble roc module, at least for now", but I was
hoping to use this module for synchronized audio.

Ahh, I see libroc isn't yet packaged in Debian. Were I to package it,
would you have any interest in Sponsoring the upload (I'm only a DM
at the moment, not yet a DD)? I built it from source, and was able
to build pipewire 0.3 with ROC support.

Kernel: Linux 5.15.9nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pipewire depends on:
ii  init-system-helpers  1.61
ii  libpipewire-0.3-modules  0.3.42-1
ii  pipewire-bin 0.3.42-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information



Bug#1001661: Info received (Bug#1001661: notcurses: flaky autopkgtests on armhf)

2021-12-25 Thread nick black
well, we don't yet know whether this "took", since 3.0.2 shows
regressions across the board in autopkgtests.

i've set up the upstream bug to track this, and am on it:

 https://github.com/dankamongmen/notcurses/issues/2505

thus far i've been able to run down that it's the "box" demo
that's failing in the "demo" autopkgtest. i expect to have it
resolved tonight. i'll either cut a new debian package with the
necessary patch, or cut a 3.0.3, we'll see.



Bug#1001122: Processed: Re: Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression

2021-12-21 Thread nick black
well, as i noted above, this use case certainly isn't the
standard way growlight will be used (although it's a valid one,
and one worth fixing -- this was a valuable exercise, and i
appreciate autopkgtests spotting this regression!). so it's not
very important to users...but at the same time, it was
considered important enough to drop the package from testing =].
so i guess i'm getting a bit of a mixed message here.

the way i read it, this was critical to fix for the
autopkgtests/transition regime, and relatively unimportant for
most users. so i agree, we can do without the versioned dep.
thanks for walking me through your thinking.


signature.asc
Description: PGP signature


Bug#1001122: Processed: Re: Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression

2021-12-21 Thread nick black
if i don't need the versioned dep, there is -- so far as i can
tell -- no reason to upload a new growlight at all, unless i
need do so to retrigger the autopkgtests and allow a transition
to testing.

(sorry for my ignorance--i'm still applying for DD)


signature.asc
Description: PGP signature


Bug#1001122: Processed: Re: Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression

2021-12-21 Thread nick black
> I don't think you need the versioned depends really. Or did I miss
> something?

well, if you have an older version of notcurses, you're going to
run into this growlight problem, so "solving" this problem for
Debian would seem to me to require the versioned dep? i'm sure
you're much more knowledgeable though, so please do explain.


signature.asc
Description: PGP signature


Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

2021-12-20 Thread nick black
not that i expect you to have run extensive benchmarks or
anything, but how do you feel this compares to libdeflate? the
few comparisons i've seen suggest that they are (or at least
were) pretty much a wash, performance-wise.



Bug#997845: Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression

2021-12-19 Thread nick black
Control: reopen -1

oh no! =[ well, at least this can be my primary focus now that
notcurses iii is out. i believe i've already provided
https://github.com/dankamongmen/growlight/issues/153, but that's
the tracking issue upstream.

attempts to reproduce this locally have thus far been less than
successful -- piping "blockdev -v" into "[sudo] growlight -v" as
the tests do runs to successful termination as expected. let me
try running it disconnected from a terminal/daemonized. the logs
i'm seeing don't show anything obvious; we seem to look up all
devices as expected, but then we just don't exit. that has
smelled to me like something wrong with the input system, but
perhaps it's in the growlight logics. if i can reproduce it, i'm
sure the fix will come easily.

anyway, this is my #1 open source priority now; sorry for the
unwarranted optimism!


signature.asc
Description: PGP signature


Bug#1001815: transition: notcurses

2021-12-16 Thread Nick Black (Public gmail account)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: dankamong...@gmail.com

Hello transition team!

Notcurses has bumped the SOVERSION from 2 to 3 as of its 3.0.0 release,
reflecting a changed ABI and API both.

The only reverse-dep of notcurses is growlight. I am the upstream author
of both. The 1.2.38 release of Growlight is necessary and sufficient
to compile against Notcurses 3. I have already packaged it, and am
simply waiting on the entry of libnotcurses3 into unstable.

Ben file:

title = "notcurses";
is_affected = .depends ~ "libnotcurses2" | .depends ~ "libnotcurses++2" | 
.depends ~ "libnotcurses-core2" | .depends ~ "libnotcurses3" | .depends ~ 
"libnotcurses++3" | .depends ~ "libnotcurses-core3";
is_good = .depends ~ "libnotcurses3" | .depends ~ "libnotcurses++3" | .depends 
~ "libnotcurses-core3";
is_bad = .depends ~ "libnotcurses2" | .depends ~ "libnotcurses++2" | .depends ~ 
"libnotcurses-core2";



Bug#997845: Your mail

2021-12-15 Thread nick black
i can happily report that the FTPmasters accepted notcurses
3.0.0 into experimental today, and thus the transition bringing
it into unstable ought begin. once that hits, i'll be landing on
this with both feet.


signature.asc
Description: PGP signature


Bug#997845: Your mail

2021-12-14 Thread nick black
ought i upload a -4 with a changelog entry marking the bug
closed? i didn't mark it closed in the changelog because i
explicitly wanted the bug left open.

sorry for any confusion -- i'm certainly not trying to work
around this issue in the long term by reducing testing =]. i
just know that it's not going to be fixed until growlight 1.2.38
moves to unstable from experimental, which requires notcurses3,
which is in the NEW queue awaiting FTPteam approval.

at that point, i'll be reenabling the test. so i don't consider
1.2.37-3 as having "closed" the bug whatsoever. but it ought be
closed shortly after notcurses3 hits unstable =].



Bug#997845: Your mail

2021-12-14 Thread nick black
you are correct in all of your assumptions =].


signature.asc
Description: PGP signature


Bug#1001661: notcurses: flaky autopkgtests on armhf

2021-12-13 Thread nick black
Thanks for the heads-up. I believe/hope that this is the same issue that 
affected our ARM MacOS builds and Alpine i686/ARMHF builds through the 3.0.0 
release, and which has been fixed in the 3.0.1 release:

 https://github.com/dankamongmen/notcurses/issues/2420

3.0.0 is currently in the NEW queue, uploaded to experimental, pending approval 
from the FTPteam (new SONAME -> libnotcurses3). Once it is approved, I will 
upload 3.0.1 (or a newer release, if one exists) to unstable, and I expect that 
this will address this problem.

In the meantime, since the fix is small and precise, I could easily prepare a 
patch for 2.4.9. I think I will go ahead and do so, both to support/disabuse 
the notion that this is the same issue, and since FTPteam + TransitionTeam 
could take significant time.


signature.asc
Description: PGP signature


Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression

2021-12-06 Thread nick black
i went ahead and uploaded growlight 1.2.38 to experimental last
evening. it doesn't build now, of course, due to a dep on
missing libnotcurses3. i've asked my Application Manager (i'm
currently applying for DD status) to sponsor an upload of the
latter to experimental+NEW, so that i can begin the transition.
at the end of this process, i expect us to have a 1.2.38
uploaded to unstable which will remedy this annoyance.

also, just for the record, let me point out that the autopkgtest
regression is due in part to the way it's being run in the
autopkgtest environment--this is usually an interactive program.
i fully agree that it's important to get it resolved, but it's
not something that ought affect the majority of users.

in any case, things will be in much better shape when 1.2.38
hits unstable.


signature.asc
Description: PGP signature


Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression

2021-12-04 Thread nick black
Thanks. I actually just cut growlight 1.2.38 literally forty
minutes ago, and have prepared it for upload. Unfortunately,
it's dependent on the new libnotcurses3, which needs to get
through NEW. I'm not yet a DD, so I'm hoping my Application
Manager will be willing to sponsor an upload of notcurses 3.0.0
to NEW. Once it gets there, I'll upload the new growlight as
part of the library transition.

I think this all ought happen within 30 days, but feel free to
ping.


signature.asc
Description: PGP signature


Bug#939540: libgpm-dev: Does not provide .pc file

2021-10-31 Thread Nick Black (Public gmail account)
> Wouldn't really be happy about an NMU. A patch is clearly preferred.
> But feel free to submit that patch as a Merge Request on Salsa
> including an appropriate debian/changelog entry in the same commit.
> (Please also post the link to the MR in this bug report. TIA!)
> I'll include it then in the next upload.

I totally understand, and agree that this is the way to go. So
long as sramacher is good with it, I'm more than happy to
proceed this way.



Bug#939540: libgpm-dev: Does not provide .pc file

2021-10-30 Thread Nick Black (Public gmail account)
Package: libgpm-dev
Version: 1.20.7-9
Followup-For: Bug #939540
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I'm going to go ahead and prepare a suitable pkg-config file for libgpm,
and submit it to you. This is part of my DD application (AM: sramacher),
so performing an NMU is also desirable, if that's amenable to you.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.15nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgpm-dev depends on:
ii  libc6-dev [libc-dev]  2.32-4
ii  libgpm2   1.20.7-9

libgpm-dev recommends no packages.

libgpm-dev suggests no packages.

-- no debconf information



Bug#997845: (no subject)

2021-10-25 Thread nick black
i'm not sure whether the "forwarded" tag applies in this case,
but i've created an upstream bug (i am the upstream author) at
https://github.com/dankamongmen/growlight/issues/153.


signature.asc
Description: PGP signature


Bug#997845: (no subject)

2021-10-25 Thread nick black
Package: growlight
Version: 1.2.37-2
Tags: upstream

Yep, I'm looking into it. For whatever reason, it's not exiting
despite input having ended. I've tried reproducing this failure
locally, but have not yet been able. I hope to fix it for
1.2.38.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.



Bug#990798: Switch to fork?

2021-09-25 Thread Nick Black (Public gmail account)
Source: libsixel
Version: 1.8.6-2
Followup-For: Bug #990798
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Hi. I'm the maintainer of the new fork of libsixel at libsixel/libsixel on
GitHub. I've been maintaining it for several months now.

I see you merged my PR on salsa:

  https://salsa.debian.org/debian/libsixel/-/merge_requests/2

We just need a new release now to switch to the new fork, with its
many security fixes (it would close several outstanding Important
bugs on this package). With that said, you might as well pull down
the newest version, 1.10.2, just released tonight. You can go
ahead and drop `libbsd-dev` from the Build-Dependencies when you
do so, as it is no longer used.

Please make a new release.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.13.18nlbschwarzgerat (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash



Bug#989923: Tests fail when server is running 24x80 terminal

2021-08-15 Thread nick black
I've made the recommended change. We were still seeing
intermittent, unrelated failures after doing so, and thus I
removed the test back in July. I can no longer reproduce these
failures, so I've just uploaded 2.3.13+dfsg.1-2 with the
offending test enabled anew. Let's see how it goes.

The upstream Notcurses bug is 
https://github.com/dankamongmen/notcurses/issues/1784.

Ubuntu current has 2.3.13+dfsg.1-1, so things have been
progressing there naturally for the duration of the Debian
Bullseye freeze.



Bug#989525: kbd: resizecons.8 references obsolete disalloc.8

2021-06-06 Thread Nick Black (Public gmail account)
Package: kbd
Version: 2.3.0-3
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

The resizecons.8 man page refers to disalloc.8, which no longer exists. It
ought reference deallocvt.8. I've created a merge request at
https://salsa.debian.org/debian/kbd/-/merge_requests/3 with the correction.

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.12.9nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kbd depends on:
ii  libc6  2.31-12

Versions of packages kbd recommends:
ii  console-setup  1.203

kbd suggests no packages.



Bug#974902: (no subject)

2021-02-23 Thread nick black
hey there achim! i was wondering if you'd had any chance to
retry with a newer growlight, ideally the 1.2.31 currently in
unstable. i'd love to get this knocked out before bullseye. if
you have the time, could you give it another try?

if it fails again, valgrind output would be a true boon. i can
help you collect this output if necessary.

it would also be nice to know if growlight-readline fails the
same way. thanks so much for your time!



Bug#982786: growlight: autopkgtest regression

2021-02-16 Thread nick black
hurrah, it would appear that 1.2.31 is running successfully on
the autopkgtest servers (all show as passed save ppc64el, which
shows as passed here: 
https://ci.debian.net/packages/g/growlight/testing/ppc64el/).



Bug#982786: growlight: autopkgtest regression

2021-02-16 Thread Nick Black
ok, the good news is that with 1.2.30, we're no longer seeing
the segfault. the bad news is that we error out due to an
inability to load up notcurses without a TERM variable.

the proper fix for this is to avoid using notcurses in any case
where we're not connected to a tty. i can get this done today,
but it will be a slightly more invasive patch (~20 lines, i
would guess). it'll still be tightly targeted at this problem.

once again, this is a use case that doesn't really reflect how
the tool would be used, and while it's a real regression, it is
being highlit primarily due to how the autopkgtests are run. i
don't want to disable the autopkgtests, but i also don't want to
get bounced from the release due to this.

my plan is to address this today, cut it as 1.2.31, and upload
it to unstable. sorry for the churn during soft freeze. =[



Bug#982786: growlight: autopkgtest regression

2021-02-15 Thread Nick Black
alright, with 1.2.30 (1.2.29 was never released), we pass the
autopkgtests, huzzah.



Bug#982786: growlight: autopkgtest regression

2021-02-15 Thread Nick Black
not so fast! while this does indeed fix the segfault when run
without TERM, i still get an autopkgtest failure, this one
tracked down to stdout being redirected =[. so i'm gonna address
that as well. how embarrassing.



Bug#982786: growlight: autopkgtest regression

2021-02-15 Thread Nick Black
Here's the upstream bug: https://github.com/dankamongmen/growlight/issues/139
Here's the (obvious, trivial) fix:
https://github.com/dankamongmen/growlight/commit/297f487a8be84441ff75a22b5fa63305931cae70

A real brown-bagger =[.

I'm going to cut 1.2.29 and upload it to unstable. If I ought
prepare this patch as a debian patch for testing, as said, I can
do that as well. Otherwise, I'm perfectly content to let this
flow through unstable->testing.



Bug#982786: growlight: autopkgtest regression

2021-02-15 Thread Nick Black
Alright, I've got it locked down to the absence of a TERM
environment variable in the autopkgtest environment. If I run
the same command outside of autopkgtest, after running
`unset TERM`, i get the exact same failure.

So, this failure is IMHO definitely worth fixing, and I intend
to do so now, but this is also a very atypical configuration.
Users will generally have a TERM environment variable. I.e., I
do not think this would have been reported as a bug were it not
for the test. So hopefully this won't be a problem despite soft
freeze. I'm preparing the fix now.

Thanks to Antonio Terceiro and Daniel Leidert for their
assistance on debian-devel in working with autopkgtest/debci!
I really appreciate it.



Bug#982786: growlight: autopkgtest regression

2021-02-15 Thread Nick Black
I can now reproduce this locally, and expect to have a fix this
evening. I've looked over the rules for the Soft Freeze, and
understand that it'll be acceptable to cut a new upstream
release (I'm the upstream author) with this fix only (there have
been no other changes since this release), upload that to
unstable, and let it proceed (possibly slowly) to testing.

If I instead need to make a debian-specific patch against
1.2.28-1, and release it as 1.2.28-2, that's also fine.



Bug#982786: growlight: autopkgtest regression

2021-02-14 Thread Nick Black
Thanks for the heads-up; glad I've got those autopkgtests. Looking into this 
now with the hope of fixing it ASAP.



Bug#968843: RFH: asciio -- dynamically create ASCII charts and graphs with GTK+2

2021-02-11 Thread Nick Black
ok, i took a closer look at things, and realize you don't need a
new *backend*, but a new *gui frontend*. alas, my suggestion
would be of no help in this case. good luck finding a new
upstream author! =]



Bug#982087: ITP: timg -- terminal image and video viewer

2021-02-06 Thread Nick Black
Tobias Frost left as an exercise for the reader:
> Package: wnpp
> Severity: wishlist
> Owner: Tobias Frost 
> X-Debbugs-Cc: debian-de...@lists.debian.org

Hey there Tobias. Might I recommend to you "ncplayer" from the
"notcurses-bin" package? I think you'll find that it is both
faster and higher quality than timg--if your experiments
contradict mine, please do let me know (as the upstream author
of Notcurses)!

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.



Bug#977691: fixed in glibc 2.31-7

2021-01-03 Thread Nick Black
I can confirm that glibc 2.31-7 returns correct values from wcwidth() for
Unicode 13 sextants.

Thanks a lot!


Bug#977922: iproute2 should probably only Suggest libatm1

2020-12-25 Thread nick black
> The PR downgrades also the dependency on libxtables, which is
> definitely not something we want. And even for libatm1, what is the
> issue exactly? It's just one library, why is it a problem if, with
> recommends enabled, it gets installed?
> TC loses functionality without it.

the only loss is q_atm.so, no? i've never needed libatm1
installed to use tc. if you'd like to keep it at Recommends,
please feel free to close this bug. i've just been installing
iproute2 via aptitude for a long time, and always have libatm1
recommended to me, and have never been sure why.

thanks for taking the time to answer my bug. if you close this
issue without further action, i'll kill the outstanding MR on
salsa.



Bug#977922: iproute2 should probably only Suggest libatm1

2020-12-22 Thread Nick Black (Public gmail account)
Package: iproute2
Version: 5.10.0-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

[ A patch has been provided for this bug at
  https://salsa.debian.org/debian/iproute2/-/merge_requests/4 ]

Recommends "should list packages that would be found together with this one in
all but unusual installations." That might have been true ten years ago, but
surely in 2020 iproute2 installations vastly outnumber the number making active
use of ATM hardware or the q_atm.so module.

I've provided a MR in Salsa, linked above. Please apply if you agree.



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.1nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libbsd00.10.0-1
ii  libc6  2.31-6
ii  libcap21:2.44-1
ii  libcap2-bin1:2.44-1
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libelf10.182-1
ii  libmnl01.0.4-3
ii  libselinux13.1-2+b2
ii  libxtables12   1.8.6-1

Versions of packages iproute2 recommends:
pn  libatm1  

Versions of packages iproute2 suggests:
pn  iproute2-doc  

-- debconf information:
* iproute2/setcaps: false



Bug#977691: libc6: would be great to have 2.32's Unicode 13 support in bullseye

2020-12-18 Thread Nick Black (Public gmail account)
Package: libc6
Version: 2.31-6
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Unstable currently contains GNU libc 2.31. I assume that this is the version
expected to go into Bullseye. If 2.32 is intended, please ignore this bug.

2.32 added Unicode 13 support, including wcwidth() tables for the new Unicode
13 characters, introduced in March 2020. 2.31 wcwidth() returns -1 for these
characters. GNU libc's wcwidth() implementation is table-driven, and generated
from Unicode data files. It is thus pretty well self-contained.

If Bullseye will be shipping 2.31, it would be very desirable to include the
Unicode 13 support from 2.32. At the very least, the updated wcwidth() tables
would be a boon. I'd be happy to prepare a backport in the form of a patch, but
wanted to submit this bug and get feedback from the glibc maintainers before
doing so.

Would such a patch be welcome, assuming I could get it done by some date?
Alternatively, are there plans to ship 2.32 in Bullseye?

Thanks!



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.1nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.17-1
ii  libgcc-s1  10.2.1-1

Versions of packages libc6 recommends:
ii  libidn2-0   2.3.0-4
ii  libnss-nis  3.1-4
ii  libnss-nisplus  1.3-4

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.74
ii  glibc-doc  2.31-6
ii  libc-l10n  2.31-6
ii  locales2.31-6

-- debconf information:
  glibc/restart-failed:
* glibc/disable-screensaver:
* libraries/restart-without-asking: true
  glibc/kernel-not-supported:
  glibc/kernel-too-old:
  glibc/restart-services:
  glibc/upgrade: true



Bug#975432: growlight: autopkgtest failures

2020-12-08 Thread Nick Black

it looks like 1.2.24-1 has fixed at least the amd64
autopkgtests. i'm waiting on the other architectures, but it
looks like we'll be able to close this.


signature.asc
Description: PGP signature


Bug#975432: 975...@bugs.debian.org

2020-12-07 Thread Nick Black
I believe this to be fixed by the 1.2.24 package I uploaded
earlier today. The problem came down to lack of swap support on
the machine(s) on which the tests were running. /proc/swaps
doesn't exist on such a machine, and growlight thus aborted in
startup. Growlight is now resistant to this class of issues. I
expect 1.2.24 to fix this, but won't be sure until it runs.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.



Bug#974888: growlight: Reproducibly segfaults on pressing F1

2020-11-29 Thread Nick Black
I've found one problem that would lead to a SIGABRT on shutdown,
which might or might not include a message about an assertion
failure. This was an issue in the underlying Notcurses library,
which will be fixed in 2.0.9 and 2.1.0. I think there's at least
one other kind of failure on shutdown, though.



Bug#974888: growlight: Reproducibly segfaults on pressing F1

2020-11-29 Thread Nick Black
retitle 974888 segfaults sometimes on shutdown

OK Axel, I've done some significant work on growlight this past
week, and we're up to 1.2.22-1 in unstable. I've unearthed a
disturbing number of bugs during that time, and fixed a solid
dozen.

I can reproduce the segfault when shutting down on about 20% of
my runs. The key to getting a coredump with a sudo process is
to make sure /proc/sys/fs/suid_dumpable is 1, and run

`ulimit -c unlimited`

*in the sudo context*. but i'm going to go ahead and do this
locally, since i seem to be able to reproduce the failure even
with 1.2.22-1 =].

i can't reproduce this segfault on other function keys at all.
are you still seeing it with 1.2.22-1?



Bug#975432: growlight: autopkgtest failures

2020-11-28 Thread Nick Black
With 1.2.22-1, we've got e.g.:

Processing triggers for libc-bin (2.31-4) ...
(Reading database ... 14094 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [06:16:57]: test blockdev-nonroot: echo "blockdev -v" |
growlight-readline --notroot
autopkgtest [06:16:57]: test blockdev-nonroot: [---
bash: line 1: growlight-readline: command not found
autopkgtest [06:16:57]: test blockdev-nonroot: ---]
autopkgtest [06:16:58]: test blockdev-nonroot:  - - - - - - - - - - results
- - - - - - - - - -
blockdev-nonroot FAIL non-zero exit status 127
autopkgtest [06:16:58]:  summary
blockdev-nonroot FAIL non-zero exit status 127

the prior test is blockdev (note the lack of -nonroot), which apparently
succeeds. does the non-root user
(i.e. the user the tests run as in the absence of the "needs-root"
restriction) possibly lack /usr/sbin in its
PATH? that would explain this failure. i'll look into it and hopefully have
this resolved shortly.


Bug#975082: [PATCH] patch for snd-20.9 for notcurses 2.0.7

2020-11-24 Thread Nick Black
As requested, here's a patch that gets snd-20.9 as packaged in
Debian's snd_20.9-1 to compile with Notcurses 2.0.7. Since
there's no version less than 2.0.7 in Debian, there's no need to
do the fine-grained comparisons the upstream author is doing.
The next release from upstream will have a native solution to
this, at which point this patch can be dropped. I'm sorry for
the inconvenience!

[schwarzgerat](0) $ cat notcurses2.diff 
diff -ur snd-20.9-a/notcurses_s7.c snd-20.9-b/notcurses_s7.c
--- snd-20.9-a/notcurses_s7.c   2020-11-22 05:02:25.0 -0500
+++ snd-20.9-b/notcurses_s7.c   2020-11-24 04:58:19.984208602 -0500
@@ -1014,7 +1014,7 @@
   return(s7_car(args));
 }
 
-#if NOTCURSES_2_0_5
+#if NOTCURSES_2
 static s7_pointer g_ncplane_options_x(s7_scheme *sc, s7_pointer args) 
 {
   return(s7_make_integer(sc, ((ncplane_options *)s7_c_pointer_with_type(sc, 
s7_car(args), ncplane_options_symbol, __func__, 1))->x));
@@ -1635,7 +1635,7 @@
   {
ncplane_options nopts = {
  .y = yoff,
-#if NOTCURSES_2_0_5
+#if NOTCURSES_2
  .x = xoff,
 #else
  .horiz = {
[schwarzgerat](0) $ 

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
diff -ur snd-20.9-a/notcurses_s7.c snd-20.9-b/notcurses_s7.c
--- snd-20.9-a/notcurses_s7.c	2020-11-22 05:02:25.0 -0500
+++ snd-20.9-b/notcurses_s7.c	2020-11-24 04:58:19.984208602 -0500
@@ -1014,7 +1014,7 @@
   return(s7_car(args));
 }
 
-#if NOTCURSES_2_0_5
+#if NOTCURSES_2
 static s7_pointer g_ncplane_options_x(s7_scheme *sc, s7_pointer args) 
 {
   return(s7_make_integer(sc, ((ncplane_options *)s7_c_pointer_with_type(sc, s7_car(args), ncplane_options_symbol, __func__, 1))->x));
@@ -1635,7 +1635,7 @@
   {
ncplane_options nopts = {
  .y = yoff,
-#if NOTCURSES_2_0_5
+#if NOTCURSES_2
  .x = xoff,
 #else
  .horiz = {


Bug#975029: transition: notcurses

2020-11-24 Thread Nick Black
I have replied to #975082 with the patch, as requested.


signature.asc
Description: PGP signature


Bug#975029: transition: notcurses

2020-11-22 Thread Nick Black
I'll send the patch to #975082 as soon as I successfully pbuild
with it, thanks Sebastian.


signature.asc
Description: PGP signature


Bug#975029: transition: notcurses

2020-11-22 Thread Nick Black
> i've sent off a patch to the snd author; how would you feel
> about me providing you with that same patch? it's quite trivial,
> and fewer than a dozen lines.

Alternatively, I can patch the change out of
notcurses-2.0.7+dfsg.1 and cut a new debian release that will
support an unchanged snd. I think this is a much worse option,
but I'm willing to take the hit if it makes things easier for
you -- I've caused you enough problems :(.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature


Bug#975029: transition: notcurses

2020-11-22 Thread Nick Black
first off, sorry about that. it was in the NEWS, but it really
did come at an inconvenient time, and probably wasn't the best
call. this is an API change but *not* an ABI change[0].

* 2.0.7 (2020-11-21)
  * The `horiz` union of `ncplane_options` has been discarded; the `int x`
within has been promoted. This union brought no actual type safety, and
was annoying for callers to deal with otherwise. Sorry for the
inconvenience.

i've sent off a patch to the snd author; how would you feel
about me providing you with that same patch? it's quite trivial,
and fewer than a dozen lines.

i appreciate your patience and willingness to work with me as i
learn the transition process, sebastian. you've been very
helpful.

[0] the difference is in a struct's definition; while it changes
the API, it *does not* change the ABI (it replaces a union over
enum+int with the int) AFAICT.


signature.asc
Description: PGP signature


Bug#975432: growlight: autopkgtest failures

2020-11-22 Thread Nick Black
Thanks for the report. I was aware of the autopkgtest failures,
but didn't realize that a failure there prevented migration. This
failure seems a property of the autopkgtest environment, and
has thus proved difficult to debug without a release. The
upcoming 1.2.21 release has added diagnostics to help
investigate this issue; I'll go ahead and cut that release.

I don't see any means by which a test can be marked ignore/flakey
in the autopkgtest syntax, which seems unfortunate (right now,
I'm trying to debug this failure in the specific autopkgtest environment;
the test works fine on my setup and any other installed setup I
can find). Do you have any suggestions? I could put a || true on
Test-Command, but I'd rather use an idiom that we can search
for etc.


Bug#975029: transition: notcurses

2020-11-21 Thread Nick Black
On Sat, 21 Nov 2020 09:10:37 +0100 Sebastian Ramacher 
wrote:
> Control: tags -1 + confirmed

Nevermind, I see that the "confirmed" tag is a sufficient litmus. Thanks!
Uploading now =].


Bug#975029: transition: notcurses

2020-11-21 Thread Nick Black
On Sat, 21 Nov 2020 09:10:37 +0100 Sebastian Ramacher 
wrote:
> With that fixed, please go ahead with the upload to unstable.

Thanks Sebastian! May I assume you're speaking on behalf of Release Team?
If so, I will proceed with the upload directly.


Bug#975029:

2020-11-19 Thread Nick Black
I will get with upstream and submit a patch to bring them up to speed with
the 2.0 api. At that point, the package ought be buildable in unstable
against libnotcurses1, and will also build from libnotcurses2. Thanks for
the heads-up!

-- 
nick black 
to make an apple pie from scratch, one need first invent a universe.


Bug#974902: growlight: segfault during startup

2020-11-18 Thread Nick Black
thank you so much for the report! i resolved several issues in
the 1.2.19 release that hit Unstable today, though i'm not sure
that this is one of them -- i'll be able to do a closer analysis
this evening. it is also possible that this is related to
DBTS #974888. sorry for the annoyance and breakage, but you can
expect to see this fixed very soon.



Bug#975029: transition: notcurses

2020-11-17 Thread Nick Black
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: dankamong...@gmail.com, pk...@debian.org

I am the upstream author and Debian Maintainer of notcurses. The 2.0.0 release
included an soname bump to 2, though there were actually no ABI changes in this
release. Rather, the soname bump was to indicate that Notcurses was finally
shipping a stable API, as it had changed pretty wildly during 1.x development.
Notcurses will commit to backwards compatibility through the 2.x cycle.

As I am only a DM (as opposed to a full DD), I couldn't upload to experimental
myself. Due to some communication breakdowns, Debian had an out-of-date
notcurses for more time than I was comfortable with; eventually (shortly after
the 2.0.4 release), I added a patch to fix the soname at 1, and successfully
uploaded notcurses-2.0.4+dfsg.1-1 to unstable.

Philipp Kern was then kind enough to step in and sponsor the libnotcurses2
upload, which is now in experimental as 2.0.4+dfsg.1-3. Any reverse dep running
successfully with libnotcurses1 2.0.4+dfsg.1-1 ought work exactly the same when
rebuilt against libnotcurses2 2.0.4+dfsg.1-3 (without changes).

There are only two reverse-deps:

 * growlight 1.2.19, which I maintain
 * snd 20.8-2, maintained by the Debian Multimedia Team. I've contacted them to
let them know about the upcoming transition. I expect no problems with the
package.

A transition tracker entry has been automatically created at
https://release.debian.org/transitions/html/auto-notcurses.html.

Ben file:

title = "notcurses";
is_affected = .depends ~ "libnotcurses1" | .depends ~ "libnotcurses++1" |
.depends ~ "libnotcurses2" | .depends ~ "libnotcurses++2";
is_good = .depends ~ "libnotcurses2" | .depends ~ "libnotcurses++2";
is_bad = .depends ~ "libnotcurses1" | .depends ~ "libnotcurses++1";



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.8nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#974918: libnotcurses2,libnotcurses++2: missing Breaks+Replaces: libnotcurses1/libnotcurses++1 (>= 2)

2020-11-17 Thread Nick Black
> That would have been sufficient for the file conflict, but I assumed
> that the forgotten soname bump makes lib*1 (>= 2) not neccessarily
> broken, but at least undesired versions.

makes sense. thanks for the explanation, and thanks once again
for the bug report and your well-known vigilance!



Bug#974888: growlight: Reproducibly segfaults on pressing F1

2020-11-16 Thread Nick Black
The segfault at shutdown has been resolved.

See: https://github.com/dankamongmen/growlight/issues/106

This fix will be in 1.2.19, which I am about to cut.



Bug#974918: libnotcurses2,libnotcurses++2: missing Breaks+Replaces: libnotcurses1/libnotcurses++1 (>= 2)

2020-11-16 Thread Nick Black
I've just uploaded 2.0.4+dfsg.1-3, which I believe fixes this
issue. It ought be available within a few hours. I believe that
the version constraints could have been tightened to (>= 2.0.4),
but I didn't see this as adding particularly much value. Thanks
as always for filing these bugs, Andreas! You're the real MVP.



  1   2   3   >