Bug#1072233: mosh: use wtmpdb to write wtmp entries

[Keith Winstein]

I think Mosh would be happy to support this transition, but Mosh doesn't
write to utmp/wtmp itself or with a PAM module; Mosh uses libutempter for
this. If libutempter is going to be updated to use wtmpdb, I don't think
Mosh itself has to change.

Sincerely,
Keith

On Thu, May 30, 2024 at 11:49 AM Chris Hofstaedtler  wrote:

> Source: mosh
> Severity: important
>
> Per the discussion on debian-devel, Debian will switch to wtmpdb for
> Y2038-safe wtmp recording. If your package writes wtmp entries,
> please switch to libwtmpdb.
>
> https://lists.debian.org/debian-devel/2024/04/msg00406.html
>
> Chris
>

Bug#1052674: ITS: mu-editor

[Keith Packard]

Package: mu-editor
Version: 1.2.1-1
Severity: important
X-Debbugs-Cc: ni...@debian.org

I'd like to get an updated version of this application into the archive; it's
been a year since the last upload and upstream has moved from version 1.0 to
version 1.2 with significant improvements and bug fixes.

I've got a new version ready for upload in my salsa repo here:
https://salsa.debian.org/keithp/mu-editor

I'm happy to either adopt this package or become a co-maintainer, whichever
works for the team.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN
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)
LSM: AppArmor: enabled

Versions of packages mu-editor depends on:
ii  black   23.7.0-1
ii  fonts-inconsolata   001.010-6
ii  libjs-skeleton  2.0.4-2
ii  node-normalize.css  8.0.1-5
ii  python3 3.11.4-5+b1
ii  python3-click   8.1.6-1
ii  python3-flake8  5.0.4-4
ii  python3-guizero 1.4.0+dfsg-1
ii  python3-ipykernel   6.24.0-3
ii  python3-ipython-genutils0.2.0-5
ii  python3-jupyter-client  7.4.9-2
ii  python3-matplotlib  3.6.3-1+b1
ii  python3-nudatus 0.0.5-2
ii  python3-pil 10.0.0-1
ii  python3-platformdirs3.10.0-1
ii  python3-pyqt5   5.15.9+dfsg-2
ii  python3-pyqt5.qsci  2.14.1+dfsg-1
ii  python3-pyqt5.qtchart   5.15.6+dfsg-1
ii  python3-pyqt5.qtserialport  5.15.9+dfsg-2
ii  python3-qtconsole   5.4.3-2
ii  python3-requests2.31.0+dfsg-1
ii  python3-semver  2.10.2-3
ii  python3-serial  3.5-1.1
ii  python3-uflash  1.2.4+dfsg-10

mu-editor recommends no packages.

Versions of packages mu-editor suggests:
ii  mu-editor-doc 1.2.0-1
ii  python3-gpiozero  1.6.2-1+b1
ii  python3-pigpio1.78-1

-- no debconf information

Bug#815539: typecatcher: Still the same in Bookworm

[Keith Edmunds]

Package: typecatcher
Version: 0.3-1.2
Followup-For: Bug #815539

The package in Bookworm has exactly the same problem. Disappointing that this 
bug remains seven years after being reported.

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 typecatcher depends on:
ii  gir1.2-glib-2.0 1.74.0-3
ii  gir1.2-gtk-3.0  3.24.37-2
ii  gir1.2-webkit2-4.0  2.40.1-1
ii  python3 3.11.2-1+b1
ii  python3-gi  3.42.2-3+b1

Versions of packages typecatcher recommends:
ii  yelp  42.2-1

typecatcher suggests no packages.

-- no debconf information

Bug#1034041: Should firmware-amd-graphics be automatically installed?

[Keith Proctor]

I must have sent 1/2 a dozen requests to unscript to this email address.

debian-boot-requ...@lists.debian.org 


This address was in the email headers.

Why am I not being removed?

> On May 22, 2023, at 12:57 PM, Ferenc Wágner  wrote:
> 
> Cyril Brulebois mailto:k...@debian.org>> writes:
> 
>> Ferenc Wágner mailto:wf...@niif.hu>> (2023-05-22):
>> 
>>> I had a similar experience with a desktop system containing a Radeon
>>> RX470 graphics card.  The text-based installation went all right and
>>> then even the Gnome desktop opened after reboot, but it ran in a
>>> low-resolution mode until I manually installed firmware-amd-graphics
>>> (the non-free-firmware archive component was already enabled).
>>> 
>>> Is this the intended behaviour?
>> 
>> Which installer did you use?
> 
> Its lsb-release says:
> 
> DISTRIB_ID=Debian
> DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
> DISTRIB_RELEASE="12 (bookworm) - installer build 20230401"
> X_INSTALLATION_MEDIUM=netboot
> 
> so it must have been bookworm RC 1.  The date was 22nd of April.  I
> started the kernel+initrd.gz from GRUB.
> -- 
> Feri.

Bug#1036446: Please enable udhcpc6

[Keith Proctor]

How do I get off this list?

Regards,
Keith

> On May 20, 2023, at 7:11 PM, Ben Hutchings  wrote:
> 
> Package: udhcpc
> Version: 1:1.35.0-4+b2
> Severity: wishlist
> Tags: ipv6
> 
> Busybox has a DHCPv6 client (udhcpc6) but this is not included
> in the Debian packages.
> 
> Please enable CONFIG_UDHCPC6 and the dependent features.
> 
> Ben.
> 
> -- System Information:
> Debian Release: 12.0
>  APT prefers unstable-debug
>  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
> 'stable'), (500, 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
> 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 busybox depends on:
> ii  libc6  2.36-8
> 
> busybox recommends no packages.
> 
> busybox suggests no packages.
> 
> -- debconf-show failed

Bug#1035014: installation-reports: Graphical installer has Xorg "no screens found" error

[Keith Toh]

Package: installation-reports
Severity: important

Boot method: CD
Image version: 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso
 (2023-04-24 23:09)

Machine: UTM QEMU VM


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

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

Comments/Problems:

When booting the installer in Graphical install mode, Xorg repeatedly
errors saying "no screens found". Based on the Xorg log, it is failing
to load the modesetting driver, as the file
/usr/lib/xorg/modules/drivers/modesetting_drv.so appears to have been
dropped from xerver-xorg-core-udeb between bullseye and bookworm.

>From kibi on #debian-boot (https://paste.debian.net/1278647/):
xserver-xorg-core-udeb_1.20.11-1+deb11u3_amd64.udeb YES
xserver-xorg-core-udeb_1.20.11-1+deb11u4_amd64.udeb YES
xserver-xorg-core-udeb_1.20.11-1+deb11u5_amd64.udeb YES
xserver-xorg-core-udeb_1.20.11-1+deb11u6_amd64.udeb YES
xserver-xorg-core-udeb_1.20.13-1_amd64.udeb YES
xserver-xorg-core-udeb_1.20.13-2_amd64.udeb YES
xserver-xorg-core-udeb_1.20.13-3_amd64.udeb YES
xserver-xorg-core-udeb_1.20.14-1_amd64.udeb YES
xserver-xorg-core-udeb_21.1.1-1_amd64.udeb NO
xserver-xorg-core-udeb_21.1.1-2_amd64.udeb NO
xserver-xorg-core-udeb_21.1.3-1_amd64.udeb NO
xserver-xorg-core-udeb_21.1.3-2+b1_amd64.udeb NO
xserver-xorg-core-udeb_21.1.3-2_amd64.udeb NO
xserver-xorg-core-udeb_21.1.4-1_amd64.udeb NO
xserver-xorg-core-udeb_21.1.4-2_amd64.udeb NO
xserver-xorg-core-udeb_21.1.4-3_amd64.udeb NO
xserver-xorg-core-udeb_21.1.5-1_amd64.udeb NO
xserver-xorg-core-udeb_21.1.6-1_amd64.udeb NO
xserver-xorg-core-udeb_21.1.7-1_amd64.udeb NO
xserver-xorg-core-udeb_21.1.7-2_amd64.udeb NO


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230423-02:07:34"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 6.1.0-7-arm64 #1 SMP Debian 6.1.20-2 (2023-04-08) 
aarch64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Red Hat, Inc. QEMU PCIe Host bridge 
[1b36:0008]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:1100]
lspci -knn: 00:01.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network 
device [1af4:1000]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0001]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:02.0 Display controller [0380]: Red Hat, Inc. Virtio GPU 
[1af4:1050] (rev 01)
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:1100]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation 
82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller 
[8086:2668] (rev 01)
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: 00:04.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 
Host Controller [1033:0194] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:05.0 USB controller [0c03]: Red Hat, Inc. QEMU XHCI Host 
Controller [1b36:000d] (rev 01)
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:1100]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:06.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio block 
device [1af4:1001]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0002]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:07.0 Communication controller [0780]: Red Hat, Inc. Virtio 
console [1af4:1003]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0003]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:08.0 Unclassified device [00ff]: Red Hat, Inc. Virtio RNG 
[1af4:1005]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0004]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
usb-list: 
usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 6.1.0-7-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) 

Bug#1034401: clementine: No tray icon under bookworm + Cinnamon

[Keith Edmunds]

Package: clementine
Version: 1.4.0~rc1+git867-g9ef681b0e+dfsg-1
Severity: minor

Dear Maintainer,

After upgrade to bookworm, Cinnamon DE, the Clementine icon no longer appears 
in the system tray (it is enabled in Preferences, Behaviour).

This may be related to bug #1029650 - it's not clear from that bug report if 
this is the same thing.

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 clementine depends on:
ii  gstreamer1.0-plugins-base   1.22.0-3
ii  gstreamer1.0-plugins-good   1.22.0-5
ii  gstreamer1.0-plugins-ugly   1.22.0-2
ii  libasound2  1.2.8-1+b1
ii  libc6   2.36-8
ii  libcdio19   1:2.1.0-dmo3
ii  libchromaprint1 1:1.5.0-dmo1
ii  libfftw3-double33.3.10-1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-1
ii  libgpod40.8.3-17+b1
ii  libgstreamer-plugins-base1.0-0  1.22.0-3
ii  libgstreamer1.0-0   1.22.0-2
ii  liblastfm5-11.1.0-5
ii  libmtp9 1.1.20-1
ii  libmygpo-qt5-1  1.1.0-4
ii  libprotobuf32   3.21.12-1+b2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libqt5concurrent5   5.15.8+dfsg-3
ii  libqt5core5a5.15.8+dfsg-3
ii  libqt5dbus5 5.15.8+dfsg-3
ii  libqt5gui5  5.15.8+dfsg-3
ii  libqt5network5  5.15.8+dfsg-3
ii  libqt5sql5  5.15.8+dfsg-3
ii  libqt5sql5-sqlite   5.15.8+dfsg-3
ii  libqt5widgets5  5.15.8+dfsg-3
ii  libqt5x11extras55.15.8-2
ii  libsqlite3-03.40.1-2
ii  libstdc++6  12.2.0-14
ii  libtag1v5   1.13-2
ii  libx11-62:1.8.4-2
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages clementine recommends:
ii  gstreamer1.0-alsa1.22.0-3
ii  gstreamer1.0-pulseaudio  1.22.0-5

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.22.0-4

-- no debconf information

Bug#1034339: libpam-mount: 'sudo -i' gives 'HXproc_run_async: pmvarrun: No such file or directory'

[Keith Edmunds]

Package: libpam-mount
Version: 2.19-1
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

Running 'sudo -i' causes 'HXproc_run_async: pmvarrun: No such file or 
directory' to be printed. The sudo call works without problem.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

sudo -i

   * What was the outcome of this action?

'HXproc_run_async: pmvarrun: No such file or directory' was printed

   * What outcome did you expect instead?

Not to see that message

Fix (but I don't know whether this is the best or correct fix):

--- /tmp/pam_mount.conf.xml.original2023-04-13 09:23:42.587754765 +0100
+++ /etc/security/pam_mount.conf.xml2023-04-13 09:16:31.053801290 +0100
@@ -38,4 +38,7 @@
 
 
 
+
+/usr/sbin/pmvarrun -u %(USER)
+
 


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 libpam-mount depends on:
ii  libc62.36-8
ii  libcryptsetup12  2:2.6.1-3~deb12u1
ii  libhx32  4.10-1
ii  libmount12.38.1-5+b1
ii  libpam-runtime   1.5.2-6
ii  libpam0g 1.5.2-6
ii  libpcre2-8-0 10.42-1
ii  libssl3  3.0.8-1
ii  libxml2  2.9.14+dfsg-1.1+b3

Versions of packages libpam-mount recommends:
ii  libpam-mount-bin  2.19-1

Versions of packages libpam-mount suggests:
ii  cifs-utils2:7.0-2
pn  davfs2
ii  fuse3 [fuse]  3.14.0-3
pn  hxtools   
ii  lsof  4.95.0-1
ii  openssl   3.0.8-1
ii  psmisc23.6-1
ii  sshfs 3.7.3-1.1
ii  xfsprogs  6.1.0-1

-- Configuration Files:
/etc/security/pam_mount.conf.xml changed:


















/usr/sbin/pmvarrun -u %(USER)



-- no debconf information

Bug#1023020: cmark-gfm: FTBFS on s390x

[Keith Packard]

Scott Talbert  writes:

> On Wed, 30 Nov 2022, Keith Packard wrote:
>
>> Scott Talbert  writes:
>>
>>> @Keith, do you have time to upload this patch?  Unfortunately, this is
>>> blocking a large number of packages from migrating to testing.
>>> Alternatively, any objections to an NMU?
>>
>> Thanks for the NMU! Did you happen to create a git repo with this
>> change? I just noticed that the salsa repo is in my private space.
>>
>>g...@salsa.debian.org:keithp/cmark-gfm.git
>
> No, I didn't, since I wasn't aware you were using a Vcs for packaging (no 
> Vcs listed in d/control).
>
> I can send you a merge request with the changes, if you'd like?

That would be great. I'll see about moving this out of my personal salsa
area and do a new upload with control pointing at the vcs.

-- 
-keith


signature.asc
Description: PGP signature

Bug#1023020: cmark-gfm: FTBFS on s390x

[Keith Packard]

Scott Talbert  writes:

> @Keith, do you have time to upload this patch?  Unfortunately, this is 
> blocking a large number of packages from migrating to testing. 
> Alternatively, any objections to an NMU?

Thanks for the NMU! Did you happen to create a git repo with this
change? I just noticed that the salsa repo is in my private space.

g...@salsa.debian.org:keithp/cmark-gfm.git

-- 
-keith


signature.asc
Description: PGP signature

Bug#1023020: cmark-gfm: FTBFS on s390x

[Keith Packard]

Scott Talbert  writes:

> @Keith, do you have time to upload this patch?  Unfortunately, this is 
> blocking a large number of packages from migrating to testing. 
> Alternatively, any objections to an NMU?

I didn't get to this today, and might not until thursday or
friday. Happy for your to NMU if you like. 

-- 
-keith


signature.asc
Description: PGP signature

Bug#1021193:

[Keith Packard]

I looked for exactly this bug as I fixed the same issue in
binutils-riscv-unknown-elf today, but somehow I missed it.

This should be fixed in version 18 by using dpkg-query instead of
hand-hacked shell bits:

upstream_version := $(shell dpkg-query -W -f="\$${source:Upstream-Version}\n" 
binutils-source)

-- 
-keith


signature.asc
Description: PGP signature

Bug#1014619: libstdc++-arm-none-eabi: dpkg-buildflags leak into target build

[Keith Packard]

> One way to solve this would be to set DEB_BUILD_OPTIONS=optimize=-lto, to
> exclude the LTO flags specifically so that they don't leak into the target
> builds.  Another thought I had was to use the dpkg-buildflags for armhf as a
> target architecture, since there could be other per-arch flags in the future
> that cause further problems.  I've tried the latter approach in the attached
> patch, which fixes the problem of lto being incorrectly used for the
> arm-none-eabi target.  I've verified that the resulting libstdc++ is usable
> again with this change.

Yeah, neither of these is really appropriate; we're not building Debian
code here. As 'rules' already sets the complete CFLAGS and CXXFLAGS
values save the necessary flags for a reproducible build, how about I
just add `-ffile-prefix-map=$(TOP_DIR)=.` manually and stop using
/usr/share/dpkg/buildflags.mk?

@@ -10,7 +10,6 @@ MULTILIB_LIST="--with-multilib-list=rmprofile"
 GCC_PACKAGE=gcc-arm-none-eabi
 
 include /usr/share/dpkg/pkg-info.mk
-include /usr/share/dpkg/buildflags.mk
 
 SVERSION := $(shell dpkg-query -W -f="\$${Version}\n" $(GCC_PACKAGE)-source)
 DVERSION := $(SVERSION)+$(DEB_VERSION)
@@ -29,6 +28,9 @@ 
BUILD_PICOLIBC_RELEASE_DIR=$(TOP_DIR)/build_picolibc_release/libstdc++
 PNEWLIB=libstdc\+\+-arm-none-eabi-newlib
 PPICOLIBC=libstdc\+\+-arm-none-eabi-picolibc
 
+CFLAGS := -ffile-prefix-map=$(TOP_DIR)=. -Wformat -Werror=format-security
+CXXFLAGS := $(CFLAGS)
+
 BUILDFLAGS=CFLAGS="$(CFLAGS) -g -O2 -ffunction-sections -fdata-sections" 
CXXFLAGS="$(CXXFLAGS) -g -O2 -ffunction-sections -fdata-sections" 
LDFLAGS="$(LDFLAGS)"
 BUILDFLAGS_NANO=CFLAGS="$(CFLAGS) -g -Os -ffunction-sections -fdata-sections 
-fno-exceptions" CXXFLAGS="$(CXXFLAGS) -g -Os -ffunction-sections 
-fdata-sections -fno-exceptions" LDFLAGS="$(LDFLAGS)"
 BUILDFLAGS_PICOLIBC=CFLAGS="--specs=picolibc.specs $(CFLAGS) -g -Os 
-ffunction-sections -fdata-sections" CXXFLAGS="--specs=picolibcpp.specs 
$(CXXFLAGS) -g -Os -ffunction-sections -fdata-sections" 
LDFLAGS="--specs=picolibc.specs $(LDFLAGS)"


-- 
-keith


signature.asc
Description: PGP signature

Bug#1010368: Maybe marshal nondeterminism?

[Keith Amling]

>From skimming some of cpython's "marshal" code [1] my best guess is that
first difference is between it thinking the `_m` string might have
another reference to it (and thus adding 0x80, or FLAG_REF to it) or
not.  This seems driven by whether or not python's object for the string
has other references (it calls Py_REFCNT(v) to decide, see line 302).

I assume the difference is whether or not python has bothered to collect
some other reference to the string or not.  Type "Z" is an interned
string type, TYPE_SHORT_ASCII_INTERNED, which therefore makes sense that
it might be shared with who knows what else.  I'm assuming this stops
reproducing when you change it to a unique name since no one else will
share the reference and you'll just deterministically get no FLAG_REF.

Just my best guesses.

Keith

[1] https://github.com/python/cpython/blob/main/Python/marshal.c

Bug#1010175: ITP: ruby-prawn-templates -- Prawn::Templates allows using PDFs as templates in Prawn

[Keith Packard]

Package: wnpp
Severity: wishlist
Owner: Keith Packard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Ruby Extras Maintainers 


* Package name: ruby-prawn-templates
  Version : 0.1.2
  Upstream Author : Gregory Brown 
* URL : https://github.com/prawnpdf/prawn-templates
* License : Ruby or GPL-2 or GPL-3
  Programming Lang: Ruby
  Description : Prawn::Templates allows using PDFs as templates in Prawn

A extension to prawn that allows one to include other pdfs either as
background to write upon or to combine several pdf documents into
one.

This package is required to implement pdf import in ruby-asciidoctor-pdf which
was left out because of a bug in pdf-core. There is a patch for the pdf-core
bug
which is upstream and will be released eventually; it would be good to have
this package ready in debian for when the pdf-core bug is fixed so that a new
version of ruby-asciidoctor-pdf can be released that enables this feature.

Bug#1007178: Incorrect dependency from libghc-curl-dev?

[Keith A. Bare II]

Package: libghc-curl-dev
Version: 1.3.8-12+b1

I'm attempting to build a system for CMU Computer Club users that will
provide development environments and some common libraries for several
programming languages.  This ran into problems due to conflicts between
libcurl4-gnutls-dev and libcurl4-openssl-dev.

Haskell seemed to be the only language with curl bindings depending on the
OpenSSL variant, so I figured I might need to drop it.

But when I looked at the dependencies more carefully, I noticed:

(bullseye)kbare@builds:~$ apt-cache show libghc-curl-dev
Package: libghc-curl-dev
Source: haskell-curl (1.3.8-12)
Version: 1.3.8-12+b1
Installed-Size: 3035
Maintainer: Debian Haskell Group <
pkg-haskell-maintain...@lists.alioth.debian.org>
Architecture: amd64
Provides: libghc-curl-dev-1.3.8-5dcc8
Depends: libcurl4-openssl-dev, libghc-base-dev-4.13.0.0-2f220,
libghc-bytestring-dev-0.10.10.1-c40ee, libghc-containers-dev-0.6.2.1-ab1cf,
libc6 (>= 2.2.5), libcurl3-gnutls (>= 7.16.2), libgmp10

So libghc-curl-dev says it depends on the curl OpenSSL development package
but the curl GNUTLS runtime shared library.  Looking closer at the source
package, I see the Build-Dependency is actually against the GNUTLS flavor
of libcurl, so it seems like the dependency on libcurl4-openssl-dev may be
in error.

Found this working with Debian 11/bullseye.

--Keith

Bug#1005718: mosh: FTBFS with OpenSSL 3.0

[Keith Winstein]

forwarded 1005718 https://github.com/mobile-shell/mosh/issues/1174
thankyou


On Sun, Feb 13, 2022 at 1:03 PM Sebastian Andrzej Siewior
 wrote:
>
> Source: mosh
> Version: 1.3.2-2.1
> Severity: important
> Tags: bookworm sid
> User: pkg-openssl-de...@lists.alioth.debian.org
> Usertags: ftbfs-3.0
>
> Your package is failing to build using OpenSSL 3.0 with the
> following error:
>
> | c++ -DHAVE_CONFIG_H -I. -I../..  -I./../util  -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wall -Werror -Wextra -pedantic -Wno-long-long -Weffc++ 
> -Wmissing-declarations -fno-strict-overflow -D_FORTIFY_SOURCE=2 
> -fstack-protector-all -Wstack-protector --param ssp-buffer-size=1 -fPIE 
> -fno-default-inline -pipe -g -O2 -ffile-prefix-map=/<>=. 
> -Wformat -Werror=format-security -c -o ocb.o ocb.cc
> | ocb.cc: In function ‘void AES_ecb_encrypt_blks(block*, unsigned int, 
> AES_KEY*)’:
> | ocb.cc:360:80: error: ‘void AES_encrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   360 |   AES_encrypt((unsigned char *)(blks+nblks), (unsigned char 
> *)(blks+nblks), key);
> |   | 
>^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:57:6: note: declared here
> |57 | void AES_encrypt(const unsigned char *in, unsigned char *out,
> |   |  ^~~
> | ocb.cc: In function ‘void AES_ecb_decrypt_blks(block*, unsigned int, 
> AES_KEY*)’:
> | ocb.cc:367:80: error: ‘void AES_decrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   367 |   AES_decrypt((unsigned char *)(blks+nblks), (unsigned char 
> *)(blks+nblks), key);
> |   | 
>^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:60:6: note: declared here
> |60 | void AES_decrypt(const unsigned char *in, unsigned char *out,
> |   |  ^~~
> | ocb.cc: In function ‘int ae_init(ae_ctx*, const void*, int, int, int)’:
> | ocb.cc:804:75: error: ‘int AES_set_encrypt_key(const unsigned char*, int, 
> AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   804 | AES_set_encrypt_key((unsigned char *)key, key_len*8, 
> >encrypt_key);
> |   | 
>   ^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:51:5: note: declared here
> |51 | int AES_set_encrypt_key(const unsigned char *userKey, const int 
> bits,
> |   | ^~~
> | ocb.cc:808:82: error: ‘int AES_set_decrypt_key(const unsigned char*, int, 
> AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   808 | AES_set_decrypt_key((unsigned char *)key, (int)(key_len*8), 
> >decrypt_key);
> |   | 
>  ^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:54:5: note: declared here
> |54 | int AES_set_decrypt_key(const unsigned char *userKey, const int 
> bits,
> |   | ^~~
> | ocb.cc:817:76: error: ‘void AES_encrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   817 | (unsigned char *)>Lstar, 
> >encrypt_key);
> |   | 
>^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:57:6: note: declared here
> |57 | void AES_encrypt(const unsigned char *in, unsigned char *out,
> |   |  ^~~
> | ocb.cc: In function ‘block gen_offset_from_nonce(ae_ctx*, const void*)’:
> | ocb.cc:854:72: error: ‘void AES_encrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   854 |   AES_encrypt(tmp.u8, (unsigned char *)>KtopStr, 
> >encrypt_key);
> |   | 
>^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:57:6: note: declared here
> |57 | void AES_encrypt(const unsigned char *in, unsigned char *out,
> |   |  ^~~
> | ocb.cc: In function ‘int ae_decrypt(ae_ctx*, const void*, const void*, 
> int, const void*, int, void*, const void*, int)’:
> | ocb.cc:1338:68: error: ‘void AES_encrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |  1338 | AES_encrypt((unsigned char *), tmp.u8, 
> >encrypt_key);
> |   |^
> | In file included from ocb.cc:354:
> | 

Bug#1004440: libgtk-3-0: File selection dialog filters incorrectly on NFS mounted directories

[Keith Edmunds]

Package: libgtk-3-0
Version: 3.24.24-4
Severity: normal

Dear Maintainer,

When using the GTK file selection dialog - for example, from mouse pad - it's 
possible to start typing a filename and the dialog progressively filters out 
files that don't match. That works fine on a locally mounted directoy.

When viewing an NFS mounted directory, the filtered results show momentarily 
(for maybe half a second), and are then hidden and "No Results Found" is 
displayed. Despite that, if one continues to type more characters, the 
momentarily-appearing list is clearly being filtered by what is typed, then 
it's hidden.

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.38.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-3+deb11u1
ii  libepoxy01.5.5-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-common  3.24.24-4
ii  libharfbuzz0b2.7.4-1
ii  libjson-glib-1.0-0   1.6.2-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  librest-0.7-00.8.1-1.1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-egl1  1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon01.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 2.0-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin 3.24.24-4
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs  1.46.2-1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
ii  ibus-gtk3 1.5.23-2
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-7
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#1004058: RM: libnewlib-nano -- ROM; Obsoleted by picolibc. Has numerous open security and RC issues.

[Keith Packard]

Package: ftp.debian.org
Severity: normal

Bug#989103: Fix

[Keith Edmunds]

Downgrading the deb-multimedia package libasound2-plugins from 1.2.2-dmo2
to 1.2.2-2 fixed this for me.

See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991337#30

Bug#989103: pulseaudio crashes on startup

[Keith Edmunds]

Caution: naivety ahead.

I'm seeing similar behaviour, but I'm not sure it's identical. I don't
have "load-module module-alsa-sink" uncommented in /etc/pulse/default.pa.
I've also rebuild pulseaudio with the patches but my problem persists.

With no USB audio devices connected, pulseaudio works fine. Connecting
either my (USB) Yamaha AG06 mixer or my Behringer UMC204HD cause
pulseaudio to segfault.

I built a debug version of pulseaudio. Here's the backtrace when it
segfaults:

(gdb) bt
#0  0x729bd0d7 in snd_async_del_handler () at
/lib/x86_64-linux-gnu/libasound.so.2

#1  0x729d7549 in snd_pcm_close () at
/lib/x86_64-linux-gnu/libasound.so.2 

#2 0x729ea559 in  () at /lib/x86_64-linux-gnu/libasound.so.2

#3 0x729d756d in snd_pcm_close () at
/lib/x86_64-linux-gnu/libasound.so.2 

#4  0x72adeeae in _snd_pcm_a52_open () at
/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_a52.so

#5 0x729d3c45 in  () at /lib/x86_64-linux-gnu/libasound.so.2

#6 0x729d42a7 in  () at /lib/x86_64-linux-gnu/libasound.so.2 

#7 0x729d71e8 in snd_pcm_open () at
/lib/x86_64-linux-gnu/libasound.so.2

#8  0x7292f1b3 in pa_alsa_open_by_device_string
(device=0x55971270 "a52:3", dev=0x0, ss=0x7fffdb74,
map=0x7fffdb80, mode=0, period_size=0x7fffdb58,
buffer_size=0x7fffdb60, tsched_size=0, use_mmap=0x0, use_tsched=0x0,
require_exact_channel_number=true) at modules/alsa/alsa-util.c:702

The code at line 702:

if ((err = snd_pcm_open(_handle, d, mode,
SND_PCM_NONBLOCK|
SND_PCM_NO_AUTO_RESAMPLE|
SND_PCM_NO_AUTO_CHANNELS|
(reformat ? 0 : SND_PCM_NO_AUTO_FORMAT))) < 0) {

Is this likely to be the same bug?
If so, should the patch have fixed it?
What more information can I provide to help?

Bug#990733: xfwm4: Resolution drops from 3840x2160 to 2560x1440 on power save

[Keith Edmunds]

Package: xfwm4
Version: 4.16.1-1
Severity: normal

Dear Maintainer,

Occasionally - maybe once a week - after re-waking a sleeping monitor, the 
screen resolution changes as per subject. Settings, Display then shows a 
maximum available resolution of 2560x1440. Logging out and in keeps the lower 
resolution, but Settings, Display now allows it to be changed back to 2840x2160.

Monitor is Dell P2715Q; graphics card is NVIDIA Corporation GP107GL [Quadro 
P620] (rev a1).

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 xfwm4 depends on:
ii  libc6 2.31-12
ii  libcairo2 1.16.0-5
ii  libepoxy0 1.5.5-1
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libstartup-notification0  0.12-6+b1
ii  libwnck-3-0   3.36.0-1
ii  libx11-6  2:1.7.1-1
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1.1
ii  libxfce4ui-2-04.16.0-1
ii  libxfce4util7 4.16.0-1
ii  libxfconf-0-3 4.16.0-2
ii  libxfixes31:5.0.3-2
ii  libxinerama1  2:1.1.4-2
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxres1  2:1.2.0-4

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages xfwm4 suggests:
ii  xfce4  4.16

-- no debconf information

Bug#989548: light-locker: Username field has focus when unlocking

[Keith Edmunds]

> Did you maybe change something in the default lightdm configuration (like
> having the userlist displayed?).  

No, the lightdm config is out of the box unmodifed.

> Is accountsservice installed on your box?  

No. Should it be?
-- 
Great music, chat and even some wit.
Join me every Friday evening at 8pm for
Keith's Music Box:
https://www.mixcloud.com/live/KeithsMusicBox/


pgpjWvocY4TFG.pgp
Description: OpenPGP digital signature

Bug#989548: light-locker: Username field has focus when unlocking

[Keith Edmunds]

Package: light-locker
Version: 1.8.0-3
Severity: normal

Dear Maintainer,

New installation of Bullseye with XFCE and light-locker. When the screen is 
locked,
the username is not populated and it also has focus. Previous versions of 
light-locker
would fill in the username and put the focus on the password field.

If one is used to the previous behaviour and starts typing the password, it 
appears in
clear text in the username field.

The username field should be populated with the logged-in user as that is by 
far the most
likely user to be unlocking the system.

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libsystemd0  247.3-5
ii  libx11-6 2:1.7.1-1
ii  libxext6 2:1.3.3-1.1
ii  libxss1  1:1.2.3-1
ii  lightdm  1.26.0-7

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information

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

[Keith Packard]

Joel Stanley  writes:

> Package: gcc-riscv64-unknown-elf
> Version: 8.3.0.2019.08+dfsg-1
> Severity: normal
>
> Dear Maintainer,
>
> I am trying to use the riscv toolchain to build a bare metal
> application. It appears to have a broken stdint.h:

You might try using picolibc instead of newlib; that's the library I
maintain. It's a fork of newlib with changes for embedded systems.

$ sudo apt install picolibc-riscv64-unknown-elf
$ riscv64-unknown-elf-gcc -specs=picolibc.specs -march=rv32i -mabi=ilp32  -c 
test.c

-- 
-keith


signature.asc
Description: PGP signature

Bug#981220: gcc-xtensa-lx106: libgcc doesn't contain soft float functions

[Keith Packard]

Package: gcc-xtensa-lx106
Version: 10.2.1-3+8
Severity: normal
X-Debbugs-Cc: kei...@keithp.com

It seems that libgcc built for this toolchain is missing the soft float
emulation functions?

This program fails to link:

cat > test.c << EOF
#include 
#include 
#include 

int main(void)
{
char foo[50];
double q;
strcpy(foo, "3.1415");
sscanf(foo, "%lf", );
return (int) (sin(q) * 100);
}
EOF
xtensa-lx106-elf-gcc --specs=picolibc.specs test.c -lm





-- System Information:
Debian Release: bullseye/sid
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-xtensa-lx106 depends on:
ii  binutils-xtensa-lx106  2.35.1-7+3+b1
ii  libc6  2.31-9
ii  libgcc-s1  10.2.1-6
ii  libgmp10   2:6.2.1+dfsg-1
ii  libmpc31.2.0-1
ii  libmpfr6   4.1.0-3
ii  libstdc++6 10.2.1-6
ii  zlib1g 1:1.2.11.dfsg-2

gcc-xtensa-lx106 recommends no packages.

gcc-xtensa-lx106 suggests no packages.

-- no debconf information

Bug#978636: move to merged-usr-only?

[Keith Packard]

Simon McVittie  writes:

> Should we be more specific than this in what we vote on, to avoid
> later having to adjudicate between developers who say that a particular
> implementation is or isn't merged-usr?

I think that and a transition plan are both key to this project. I
recently installed Debian from scratch on my HiFive unmatched board and
it got merged / and /usr. When I built packages on this device, they
created invalid packages as the shared library dependencies all listed
/lib instead of /usr/lib. That seems like a non-starter to me.

Any plan where a transitioning system cannot be used for ongoing Debian
development seems unworkable to me -- it leaves all active Debian
developers working on un-transitioned systems, which greatly reduces
test coverage from people in the best position to help fix things.

I do use a separate cowbuilder when creating packages to upload, and
that could be configured in un-transitioned mode, but I also regularly
debug packages on my native system as that offers much faster
development times.

> Guillem considers layout 1 to be broken and a mess. I don't agree,
> but I'm not a dpkg maintainer. We should be aware that mandating this
> implementation is likely to require some overruling.

From an architectural purity perspective, layout 1 'looks nicer'. As
that also matches what other distros are doing, it would make us more
consistent across the Linux ecosystem (I believe that's a good thing).

However, I believe only layout 2a would make it possible to build Debian
packages on transitioned systems. That seems necessary to me. We could,
in future, then transition from layout 2a to layout 1 once /lib (and
/bin?)  were no longer in the default search paths to cause invalid
packages to be created.

I don't understand the value of 2b; it's functionally similar to layout
1, but makes for additional work to create the shadow links, along with
consuming space for them. It also doesn't resolve the problem of
building packages.

> Sorry to derail this but I think we should be clear about what we're
> resolving.

I think you've added helpful clarification to the conversation, thanks!

-- 
-keith


signature.asc
Description: PGP signature

Bug#980086: broken autopkg test, no aarch64 cross targets on armhf.

[Keith Packard]

Matthias Klose  writes:

> This blocks migration of gcc-defaults, there is no aarch64 cross
> target on armhf.

Suggestions on how to work around this welcome; I really don't know what
to do. I want to continue providing the generated binaries on all
architectures, but we appear to need to restrict which architectures
are allowed to attempt to build them.

Is there some reason the aarch64 cross compiler is *not* available on
armhf?

-- 
-keith


signature.asc
Description: PGP signature

Bug#974011: xmille: Incorrect license/copyright for xmille

[Keith Packard]

Adrian Bunk  writes:

> I am just a normal user enjoying the game, and looking at the number of 
> uploads in the past decade two maintainers might be sufficient to handle
> the load.  ;-)

I've uploaded 'kgames' to the new queue :-)

Thanks for playing.

-- 
-keith


signature.asc
Description: PGP signature

Bug#978412: src:picolibc: fails to migrate to testing for too long: maintainer built arch:all binaries

[Keith Packard]

Paul Gevers  writes:

> Your package is only blocked because the arch:all binary package(s)
> aren't built on a buildd. Unfortunately the Debian infrastructure
> doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
> shortly do a no-changes source-only upload to DELAYED/15, closing this
> bug. Please let me know if I should delay or cancel that upload.

Oh, thanks so much for doing this upload -- I totally spaced doing a
source upload after 1.4.7 required a binary upload to go through the new
queue again for the added aarch64 binary package.

-- 
-keith


signature.asc
Description: PGP signature

Bug#974011: xmille: Incorrect license/copyright for xmille

[Keith Packard]

Steven Robbins  writes:

> On Saturday, December 26, 2020 12:50:58 A.M. CST Keith Packard wrote:
>
>> I've tagged version '1.0' of this repository and created some (not
>> finished) debian packaging for it. This version has imported the mille
>> sources from 'upstream' which include copyright information for the
>> BSD-sourced files.
>> 
>> How would you like to go about getting these 'xmille' bits into the
>> archive as a replacement for the ancient bits now living there? 
>
> Personally speaking: if you're already working on debian packaging, my 
> preference is to just step aside and let you carry on.  If you're willing, 
> then I think it mainly becomes a problem of what to name the source package 
> as 
> the new sources are more than just xmille.

The upstream name is 'games', which is a bit generic, I suspect. I've
tentatively named the package 'kgames'.

> I don't mind co-maintaining but, realistically, I won't be much help.

Would be good to have more than one person able to upload, just in case.

> If you are NOT interested in maintaining the package, then I can continue.  
> Unless Adrian wants to do it?  ;-)

I'm easy; three is even better than two?

I've packaged everything in one bundle, even though there are 14 games
and a shared library. There are few man pages; not even the rules for
each game. I do have text for that from my palm pilot 'patience'
application; I can see about putting that into a man page for each game.

Just so you know, I've got my original 1990 edition of the 'X Window
System Toolkit' book sitting on my desk at present. It's getting
surprisingly yellowed with age, but the technical content remains as
accurate as ever. Talk about 'legacy software' :-)

-- 
-keith


signature.asc
Description: PGP signature

Bug#974011: xmille: Incorrect license/copyright for xmille

[Keith Packard]

Keith Packard  writes:

> This package includes a bunch of games using a shared widget library,
> including a raft of solitaire, another (not terribly good) reversi
> implementation and even a version of dominoes. Having this build only
> xmille would be fairly easy. If that seems like a reasonable way
> forward, I'll go ahead and create a release of that package.

I've tagged version '1.0' of this repository and created some (not
finished) debian packaging for it. This version has imported the mille
sources from 'upstream' which include copyright information for the
BSD-sourced files.

How would you like to go about getting these 'xmille' bits into the
archive as a replacement for the ancient bits now living there? It's not
a direct replacement as it includes a bunch of additional
applications. They're all 'classic' X apps, although now 'modernized'
(if code circa 1990 can be considered 'modern') as they're Xt/Xaw based,
instead of being raw X based. And the colors now work too, plus fewer
crashes.

-- 
-keith


signature.asc
Description: PGP signature

Bug#977958: dbus: Some ir-keytable remote control buttons don't work unless dbus is restarted

[Keith Edmunds]

Package: dbus
Version: 1.12.20-0+deb10u1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate
***

   * What led up to the situation?

Configuring an IR remote control (for MythTV) and noticing some keys
don't work. Example: the "play" button, which is mapped via a keymap
file from KEY_PLAY to KEY_P (ie, the keyboard 'p' charcter). Other keys
(eg, KEY_OK mapped to KEY_ENTER, or KEY_UP, not remapped) work OK.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

After much experimentation, I found that restarting dbus ("systemctl
restart dbus") fixed the problem. It is a consistent fix: those keys
always fail before restarting dbus, and never fail after restarting dbus.

My workaround: add "systemctl restart dbus" to the end of /etc/rc.local.

Hypothesis: the systemd startup order/dependencies may be incorrect,
but I don't know enough about it to know whether that's likely.


-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dbus depends on:
ii  adduser   3.118
ii  libapparmor1  2.13.2-10
ii  libaudit1 1:2.8.4-3
ii  libc6 2.28-10
ii  libcap-ng00.7.9-2
ii  libdbus-1-3   1.12.20-0+deb10u1
ii  libexpat1 2.2.6-2+deb10u1
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-7~deb10u5

dbus recommends no packages.

Versions of packages dbus suggests:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-0+deb10u1
ii  dbus-x11 [dbus-session-bus]   1.12.20-0+deb10u1

Versions of packages dbus is related to:
ii  dbus-x11  1.12.20-0+deb10u1
ii  systemd   241-7~deb10u5
ii  systemd-sysv  241-7~deb10u5

-- no debconf information

Bug#974011: xmille: Incorrect license/copyright for xmille

[Keith Packard]

Adrian Bunk  writes:

> On Mon, Dec 07, 2020 at 09:12:23AM -0800, Keith Packard wrote:
>> Adrian Bunk  writes:
>> >
>> > Keith, do you remember the copyright history of this code?
>> 
>> I may have copied the underlying mille sources *before* copyrights were
>> added to each file; I started work on the X10 version of xmille around
>> 1985 or 1986. I guess I could have mistakenly removed them? Thanks for
>> discovering this error; I can fix these "upstream" and publish a new
>> version?
>
> I am just a user who would like to see this package also in bullseye.
>
> A new upstream version would be good, but it is not obvious to me 
> whether you or Steve M. Robbins or anyone else is considered upstream
> or should become upstream (again).

It looks like the version in the archive is *very* old (I mean, "new"
xmille is still old, but there is a more modern port that uses Xt at
least). I've got the newer version working, even on 64-bit systems, and
have applied suitable copyright messages.

https://keithp.com/cgit/games.git/

This package includes a bunch of games using a shared widget library,
including a raft of solitaire, another (not terribly good) reversi
implementation and even a version of dominoes. Having this build only
xmille would be fairly easy. If that seems like a reasonable way
forward, I'll go ahead and create a release of that package.

-- 
-keith


signature.asc
Description: PGP signature

Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

[Keith Winstein]

Hi, sorry, I should have clarified that I am also the upstream maintainer,
and I keep the "debian" directory in the same source repository as
everything else. That's what I meant about submitting a pull request on
GitHub. It would still be a modification to debian/rules.

The backstory here is that because those mahimahi programs (mm-link,
mm-delay, mm-onoff, mm-loss, mm-webrecord, mm-webreplay) run setuid root,
we are paranoid about using PATH at runtime. So we try to resolve these
absolute pathnames at build-time. If Debian wants to hardcode the
locations, fine with me.

I am curious -- why is it important that builds be identical between
usrmerge systems and non-usrmerge systems? It's not like we try to have
builds be identical between systems with different versions of the
compiler, etc. Still, though, if this is the notion of reproducibility that
Debian wants its packages to have, I'm happy to comply and have no quibbles
with your patch.

Cheers,
Keith



On Fri, Dec 18, 2020 at 3:24 PM Vagrant Cascadian <
vagr...@reproducible-builds.org> wrote:

> On 2020-12-18, Keith Winstein wrote:
> > Thank you for tracking this down! Happy to take the patch -- would you
> mind
> > filing this as an upstream pull request at
> > https://github.com/ravinet/mahimahi ? That way we will have this in one
> > place when we next have cycles to upload a new mahimahi package.
>
> I'm not sure an "upstream" patch would make sense in this specific case;
> in Debian, the most compatible path should be in /bin and /sbin, but
> this would not necessarily be the case with all distros, and relying on
> the path detection might actually be appropriate in some cases.
>
> So the patch I submitted only modifies debian/rules, not any of the
> upstream code.
>
>
> An upstream fix *might* be to not embed the full paths at all, and rely
> a working system PATH, though there may be cases where this does not
> work... but I am not familiar enough with mahimahi to know if that would
> be workable. The upstream code that triggers this is the use of
> AC_PATH_PROG in configure.ac.
>
> For what it's worth, it also embeds the path to other binaries through
> AC_PATH_PROG, but many of those don't change on a Debian usrmerge
> system.
>
>
> Happy to dialog a little further to sort this out, and thanks for the
> quick response!
>
>
> live well,
>   vagrant
>

Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

[Keith Winstein]

Thank you for tracking this down! Happy to take the patch -- would you mind
filing this as an upstream pull request at
https://github.com/ravinet/mahimahi ? That way we will have this in one
place when we next have cycles to upload a new mahimahi package.

Sincerely,
Keith

On Fri, Dec 18, 2020 at 12:45 PM Vagrant Cascadian <
vagr...@reproducible-builds.org> wrote:

> Source: mahimahi
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: usrmerge
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> The paths to "iptables" and "ip" may vary when built on a usrmerge and
> non-usrmerge system, and get embedded in /usr/bin/mm-link and possibly
> other binaries:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/mahimahi.html
>
> It's a little hard to notice, but I caught these differences in mm-link:
>
>   /sbin/ipH
>   vs.
>   /usr/sbiH
>
>
> The attached patch fixes this by passing IPTABLES and IP to configure in
> debian/rules. With this patch applied, it should build reproducibly in
> our test infrastructure.
>
>
> Thanks for maintaining mahimahi!
>
>
> live well,
>   vagrant
>

Bug#974011: xmille: Incorrect license/copyright for xmille

[Keith Packard]

Ryan Armstrong  writes:

> I just did a bit of digging, since I previously had a 2.11 BSD VM set up 
> in SIMH (fun!). It looks like the version of mille in that release was 
> indeed from about the 1985/1986 time frame, and the copyright headers 
> were not yet added. So that makes much more sense then removing them.
>
> I guess the question becomes, would they still require a change in 
> copyright status, or is the previous status correct?
>
> Also, should a credit for Ken Arnold be added?

I'm about half way through updating the code by copying the mille code
into xmille, along with copyrights. This has the advantage of fixing a
number of crashes on 64- bit architectures. When I finish, I'll create a
new upstream version, at which point we can package that for debian and
resolve the copyright and license issues.

-- 
-keith


signature.asc
Description: PGP signature

Bug#974011: xmille: Incorrect license/copyright for xmille

[Keith Packard]

Adrian Bunk  writes:

> On Sun, Nov 08, 2020 at 07:06:52PM -0500, Ryan Armstrong wrote:
>>...
>> I have been researching old terminal and X games recently, and realized
>> that much of the code from 'xmille' orignated from the terminal game
>> 'mille', which is part of bsdgames.
>> 
>> Specifically, the following files are notably similar between the two
>> games:
>> comp.c
>> end.c
>> extern.c
>> init.c
>> mille.c & mille.h
>> misc.c
>> move.c
>> types.h
>> varpush.c
>> 
>> Many of these even contain telltale BSD version/date comments, even a
>> few not listed above that are common but extensively re-written.
>> However, all of the original source files contain the 3-term BSD
>> license, as follows:
>>...
>> This has been stripped out of all code in the xmille distribution.
>> Also, none of the included materials give credit to the original author,
>> Ken Arnold.
>> 
>> I'm not sure what the best solution is, exactly. Extensively patch the
>> source until it complies with the BSD license again?
>> 
>> Presumably, the copyright file needs to change at the very least.
>>...
>
> Keith, do you remember the copyright history of this code?

I may have copied the underlying mille sources *before* copyrights were
added to each file; I started work on the X10 version of xmille around
1985 or 1986. I guess I could have mistakenly removed them? Thanks for
discovering this error; I can fix these "upstream" and publish a new
version?

-- 
-keith


signature.asc
Description: PGP signature

Bug#976405: Bug#976535: Bug#976495: also happens on amd64, should be worked around by 1.8.20-5 but the real fix will come with 1.8.20-6

[Keith Packard]

Lucas Nussbaum  writes:

> There was a texlive update in the meantime. Here are the versions of
> packages that differ.

I explored this a bit today -- there's something quite amiss with the
docbook toolchain. I'm seeing a lot of this error:

! Undefined control sequence.
\close@pdflink ->\Hy@endcolorlink 
  \Hy@VerboseLinkStop \pdfendlink 
l.585 ...-mode}}History\endNode{}\endSeq{}\endLink
  {}\Seq%

The result is that pdfjadetex exits with status 1 and the resulting PDF
has a lot of artifacts in the TOC. Each TOC label and page number are
prefixed with 'black'.

I'd be happy to help fix things, but I'm afraid I'm way out of my
docbook depth here.

-- 
-keith


signature.asc
Description: PGP signature

Bug#969436: Fixing wrong changelog entry

[Keith Max]

Hi guys, This small mess has been existing couple of days now. Is it possible to fix this package please? There are a bunch of packages stuck in unstable because of this situation this package is in. If I'm correct, the changelog of -2 closed the wrong bug number. Then the wrong changelog entry was fixed on the source repo, but no new upload was made to unstable with the actual corrected changelog. So based on the previous upload inlcuding the wrong changelog the BTS has determined that this serious bug is still applicable to current upload. Is it possible to do a corrected upload please to correct the changelog also in the actual package, not just in the source repo? Thanks,Keith

Bug#958110: nickle: please make the build reproducible

[Keith Packard]

"Chris Lamb"  writes:

> Dear Maintainer,
>
>> Source: nickle
>> Version: 2.77-1
>> Tags: patch
>
> There hasn't seem to be any update on this bug in 135 days, in which
> time the Reproducible Builds effort has come on a long way.
>
> Would you consider applying this patch and uploading?

So sorry -- I had applied the fixes but hadn't uploaded. Vagrant caught
me on IRC and encouraged me to finish the next release.

-- 
-keith


signature.asc
Description: PGP signature

Bug#956253: mu-editor 1.0.3 packaged (with bonus features)

[Keith Packard]

Nick Morrott  writes:

> There is a bug report asking for 1.1.alpha to be packaged [1], so I
> think a sensible plan might be to get a mildly-patched 1.0.3 into
> unstable and then consider uploading the current alpha into
> experimental?

I had packaged 1.1.alpha, which has a number of useful additions
(including built-in reformatting), but then went and looked at the
Debian packaging and noticed that you had fixed a number of DFSG
issues. It would probably be easier to merge changes from upstream to a
1.1.alpha experimental release than on top of 1.0.3, so it might make
sense to publish a 'pure' 1.0.3 to unstable and then add a fancy
1.1.alpha to experimental.

Are you keeping a patch-queue branch anywhere to help with evaluating
which fixes to include? I've pushed my branch to

https://salsa.debian.org/keithp/mu-editor/-/tree/patch-queue/debian/master

That's got the three additions I'm using in class:

 1. add snek mode (needed for my snek-based class)
 2. close repl/plotter when serial port disappears (helps when unplugging USB)
 3. scale button bar icons (helps on small screens)

I had to back-port these to 1.0.3, so they haven't had as much review or
testing in this version.

> I wonder if there are there any other standalone commits post 1.0.3
> that might also be worthwhile patching in? Let me look into this this
> week.

Thanks.

-- 
-keith


signature.asc
Description: PGP signature

Bug#960866: libnewlib-nano FTBFS with meson 0.54.2-1

[Keith Packard]

Adrian Bunk  writes:

> Source: libnewlib-nano
> Version: 2.11.2-1
> Severity: serious
> Tags: ftbfs bullseye sid
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libnewlib-nano.html

The correct fix is to get picolibc out of the new queue so I can finish
removing this package from the archive. Picolibc is just a rename of
this library to avoid conflicting with existing uses of the name
'newlib-nano'.

-- 
-keith


signature.asc
Description: PGP signature

Bug#952637: Close bug 952637

[Keith Packard]

Pirate Praveen  writes:

> On Mon, 09 Mar 2020 12:41:41 -0700 kei...@keithp.com ("Keith Packard") wrote:
>> 
>> Source: ruby-asciidoctor-pdf
>> Version: 1.5.3-1
>> 
>> Updated gemspec dependency on concurrent-ruby to ~> 1.1.0 which matches 1.1.6
>
> ~> 1.1 should be enough, see
> https://github.com/asciidoctor/asciidoctor-pdf/pull/1601

Thanks. I'll update the patch here and expect to delete it when
asciidoctor-pdf gets a new release.

-- 
-keith


signature.asc
Description: PGP signature

Bug#951306: snek: unsatisfiable b-d on picolibc-arm-none-eabi

[Keith Packard]

Ralf Treinen  writes:

> snek build-depends on picolibc-arm-none-eabi which does not exist (yet)
> in sid.

Yup. It's been stuck in the 'new' queue for several months now.

-- 
-keith


signature.asc
Description: PGP signature

Bug#951068: xinetd: daytime service gives incorrect format

[Keith Blow]

Package: xinetd
Version: 1:2.3.15.3-1
Severity: normal

Dear Maintainer,

I am using the internal daytime service, the daytime conf file says:
# description: An internal xinetd service which gets the current system time
# then prints it out in a format like this: "Wed Nov 13 22:30:27 EST 2002".
but the actual format is like this:
10 FEB 2020 15:17:02 GMT

It would be good if it gave the format specified in the conf file.
I have a workaround which is to create my own service which just executes
/bin/date
as this gives the (for me) right format.

This is not all that new, it was the same on jessie.
The report below says that the daytime file has been changed but this is
untrue as I submitted this report immediately after doing a reinstall of
xinetd.


-- System Information:
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Architecture: armv6l

Kernel: Linux 4.19.97+
Kernel taint flags: TAINT_CRAP
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)

Versions of packages xinetd depends on:
ii  libc62.28-10+rpi1
ii  libselinux1  2.8-1+b1
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400+rpi1
ii  netbase  5.6

Versions of packages xinetd recommends:
ii  logrotate3.14.0-4
ii  rsyslog [system-log-daemon]  8.1901.0-1
ii  update-inetd 4.49

xinetd suggests no packages.

-- Configuration Files:
/etc/xinetd.d/daytime changed [not included]

-- no debconf information

-- 
Keith Blow

Bug#930764: Still present in 3.0.13-1

[Keith Max]

Control: retitle -1 Fails to configure package due to "unknown type of DB: 
BACKUP" on upgrade-db
Control: severity -1 grave
Control: tags -1 patch
Control: found -1 3.0.13-1

Hi again,

This very annoying bug is still present in 3.0.13-1. The upgrade of this 
package breaks with every new version, rendering it unusable. Since this 
package regularly gets upstream upgrades and is (going to be) part of several 
transitions, more broken packages are expected if this is not fixed. Is it 
possible to incorporate the supplied patch?

Regards,
Keith

Bug#946419: samba-vfs-modules: Resource forks are truncated when written to fruit-enabled share

[Keith Kaisershot]

Package: samba-vfs-modules
Version: 2:4.11.1+dfsg-3
Severity: important

I use vfs_fruit with a Samba share serving various older versions of Mac OS X, 
from 10.6 up through 10.11, archiving classic Mac files dating back to the mid 
80s. With the latest Samba 4.11.1 in Debian testing, writing one of these older 
files with a resource fork larger than 64K results in the resource fork portion 
getting truncated to 65454 bytes on the server end. This corrupts old Mac files 
with resource forks larger than 64K-- executables are the most affected by 
this, but graphic files such as PICT are too.

Looks like this is a regression, as this issue does not occur in 4.9.5 from 
Debian stable.

Repro steps:
1) Copy a classic 68K Mac OS application > 65K from a Mac OS X 10.11 client to 
a Samba 4.9.5 host. (I used ircle 1.5.6 as a test case here.)
2) Get Info on the newly-copied file on the 4.9.5 server and observe that the 
application's size matches that of the original file on the client.
 - Screenshot here: 
https://blitter.net/etc/rsrc_bug/Screen%20Shot%202019-12-08%20at%2012.13.23%20PM.png
3) Observe the same in Finder.
 - Screenshot here: 
https://blitter.net/etc/rsrc_bug/Screen%20Shot%202019-12-08%20at%2012.12.15%20PM.png
4) Copy the same application from the same Mac OS X 10.11 client to a Samba 
4.11.1 host.
5) Get Info on the newly-copied file on the 4.11.1 server and observe that the 
application's size has been truncated.
 - Screenshot here: 
https://blitter.net/etc/rsrc_bug/Screen%20Shot%202019-12-08%20at%2012.13.26%20PM.png
6) Observe the same in Finder.
 - Screenshot here: 
https://blitter.net/etc/rsrc_bug/Screen%20Shot%202019-12-08%20at%2012.12.35%20PM.png

My smb.conf from testparm (identical on both test hosts above except for the 
name of the share which should reflect the Samba version)-- /srv/test is 0777 
on both host filesystems (ext4):

# Global parameters
[global]
log file = /var/log/samba/log.%m
logging = file
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n 
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
server role = standalone server
unix password sync = Yes
usershare allow guests = Yes
idmap config * : backend = tdb
vfs objects = catia fruit streams_xattr


[4.11.1]
guest ok = Yes
path = /srv/test
read only = No


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages samba-vfs-modules depends on:
ii  libbsd0   0.10.0-1
ii  libc6 2.29-2
ii  libgnutls30   3.6.10-4
ii  libtalloc22.3.0-2
ii  libtdb1   1.4.2-2
ii  libtevent00.10.1-3
ii  libwbclient0  2:4.11.1+dfsg-3
ii  samba-libs2:4.11.1+dfsg-3

Versions of packages samba-vfs-modules recommends:
ii  libcephfs2   12.2.11+dfsg1-2.1+b2
ii  libdbus-1-3  1.12.16-2
ii  libgfapi07.0-1

samba-vfs-modules suggests no packages.

-- no debconf information

Bug#930764: cyrus-common 3.0.8-6 fails to configure package due to "unknown type of DB: BACKUP" on upgrade-db

[Keith Max]

severity -1 grave
tags -1 patch
found -1 3.0.11-1
thanks

Hi,
 
We're also affected by this bug. It is still present in 3.0.11-1. The upgrade 
of this package breaks with every new version, rendering it unusable. Since 
this package is (going to be) part of several transitions, more broken packages 
are expected if this is not fixed. Is it possible to incorporate the supplied 
patch?
 
Regards,
Keith

Bug#933057: csh: bsd-csh eval command always dies with segmentation fault

[Keith Thompson]

Yes, that's one possible fix.

But if you grab a newer version from upstream, pointer_deref_comparison.patch
isn't necessary at all. The change from '\0' to NULL was already made 2018-09-19
as I described above in message #5 on this report.

I suppose grabbing the newer version make sense in the long term,
but fixing pointer_deref_comparison.patch makes sense as a quick
fix for current releases.

(Sorry if I'm stating the obvious.)


On Fri, Sep 20, 2019 at 6:51 PM Graham Inggs  wrote:
>
> Modifying pointer_deref_comparison.patch as follows works for me.
>
>
> --- a/debian/patches/pointer_deref_comparison.patch
> +++ b/debian/patches/pointer_deref_comparison.patch
> @@ -5,7 +5,7 @@
>   }
>   if (alvec) {
>  -if ((alvecp = *alvec) != '\0') {
> -+if (*(alvecp = *alvec) != '\0') {
> ++if ((alvecp = *alvec) != NULL) {
>   alvec++;
>   goto top;
>   }
> @@ -14,7 +14,7 @@
>   reset();
>   }
>  -if ((evalp = *evalvec) != '\0') {
> -+if (*(evalp = *evalvec) != '\0') {
> ++if ((evalp = *evalvec) != NULL) {
>   evalvec++;
>   goto top;
>   }
>
> --
> To unsubscribe, send mail to 933057-unsubscr...@bugs.debian.org.

Bug#675299: Hello,

[Campion keith]

I sent this letter to you a month ago, but I'm not sure if you got it,
I did not hear from you, and this is the reason I repeat it.

Can we talk now please?

Thanks,
Campion Keith.

Bug#933057: Reproducing the bug

[Keith Thompson]

To reproduce the bug:

$ bsd-csh -f -c 'eval date'
Segmentation fault
$

Bug#933057: csh: bsd-csh eval command always dies with segmentation fault

[Keith Thompson]

Package: csh
Version: 20110502-4
Severity: important
Tags: upstream



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

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

Versions of packages csh depends on:
ii  libbsd0  0.9.1-2
ii  libc62.28-10

csh recommends no packages.

csh suggests no packages.

-- no debconf information

This bug was previously reported against Ubuntu.

Details, including a suggested fix, are available at
https://bugs.launchpad.net/ubuntu/+source/csh/+bug/1739505

The problem was introduced by
debian/patches/pointer_deref_comparison.patch
which silenced a compiler warning but broke csh's "eval" command
with a null pointer dereference.  That patch should be backed out,
and the csh sources from OpenBSD should be updated to include
the correct fix.

The correct fix is commit bdb0dae4088 in https://github.com/openbsd/src
applied on 2018-09-19.

I'll add a comment to the bug report on launchpad.net pointing to
this one.

Bug#929515: smokeping: CSS and js files not found

[Keith Edmunds]

Package: smokeping
Version: 2.7.3-2
Severity: important

System was upgraded from Stretch to Buster, with smokeping working on Stretch.

After the upgrade, it's evident from the display that there is a CSS problem.

Chrome devtools reports:

GET http://ws.midnighthax.com/cgi-bin/css/smokeping-screen.css net::ERR_ABORTED 
404 (Not Found)

...and more, similar.

The file exists:

$ ls -l $(locate smokeping-screen.css)
-rw-r--r-- 1 root root 4596 Feb 24 00:54 
/usr/share/smokeping/www/css/smokeping-screen.css

So, this appears to be some kind of path issue.

Keith

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing')
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:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages smokeping depends on:
ii  adduser3.118
ii  debianutils4.8.6.1
ii  exim4-daemon-light [mail-transport-agent]  4.92-7
ii  fping  4.2-1
ii  libcgi-fast-perl   1:2.13-1
ii  libconfig-grammar-perl 1.12-2
ii  libdigest-hmac-perl1.03+dfsg-2
ii  libjs-cropper  1.2.2-1
ii  libjs-prototype1.7.1-3
ii  libjs-scriptaculous1.9.0-2
ii  librrds-perl   1.7.1-1
ii  libsnmp-session-perl   1.14~git20130523.186a005-4
ii  liburi-perl1.76-1
ii  libwww-perl6.36-2
ii  lsb-base   10.2019031300
ii  perl   5.28.1-6
ii  ucf3.0038+nmu1

Versions of packages smokeping recommends:
ii  apache2 [httpd-cgi]  2.4.38-3
ii  dnsutils 1:9.11.5.P4+dfsg-5
ii  echoping 6.0.2-10
ii  libsocket6-perl  0.29-1+b1

Versions of packages smokeping suggests:
ii  curl   7.64.0-3
pn  libauthen-radius-perl  
ii  libio-socket-ssl-perl  2.060-3
ii  libnet-dns-perl1.19-1
pn  libnet-ldap-perl   
pn  libnet-telnet-perl 
ii  openssh-client 1:7.9p1-10

-- Configuration Files:
/etc/smokeping/config.d/Alerts changed:
*** Alerts ***
to = k...@midnighthax.com
from = r...@midnighthax.com
+someloss
type = loss
pattern = >0%,*12*,>0%,*12*,>0%
comment = loss 3 times  in a row

/etc/smokeping/config.d/General changed:
*** General ***
owner    = Keith Edmunds
contact  = k...@midnighthax.com
mailhost = 10.0.0.1
cgiurl   = http://ws.midnighthax.com/cgi-bin/smokeping.cgi
syslogfacility = local0
@include /etc/smokeping/config.d/pathnames

/etc/smokeping/config.d/Targets changed:
*** Targets ***
probe = FPing
menu = Top
title = Network Latency Grapher
remark = Welcome to the SmokePing website of The Cage
+ Local
menu = Local
title = Local Network
++ LocalMachine
title = ws.midnighthax.com
host = localhost
++ Firewall
title = Firewall
host = 10.0.0.2
alerts = someloss
++ Woodlands
title = Woodlands
host = 10.0.0.1
alerts = someloss
++ ddwrt
title = ddwrt   
host = 10.0.0.43
alerts = someloss
+ Remote
menu = Remote Systems
title = Remote Systems
++ Google
title = Google
host = google.com
++ Eden
title = Icinga Monitor
host = eden.tiger-computing.co.uk
alerts = someloss
++ BBC
title = BBC
host = bbc.co.uk
alerts = someloss

/etc/smokeping/smokeping_secrets [Errno 13] Permission denied: 
'/etc/smokeping/smokeping_secrets'

-- no debconf information

Bug#925202: Keep calypso out of testing/buster

[Keith Packard]

Ivo De Decker  writes:

> I added a removal hint to get it out of testing.

I saw that after I uploaded 2.0-1... I'd been meaning to get back to
calypso for quite a while but got stuck because the various Python2
dependencies were no longer supported and yet some were not yet
available for Python3. With everything now available in Python3, it was
a fairly simple matter to transition the rest of the code over to the
newer version, which should make it far more maintainable going forward.

In addition, Python 3.7 has ThreadingHTTPServer, which means a
long-standing issue of supporting only one connection at a time has been
resolved. With that, Calypso can start to become a more complete caldav
solution, although there are still many little things to work on.

I'd be fine with having 1.5-5 not shipped in testing; it's certainly not
going to be supportable for the length of the next stable release.

> However, please note that there was a new upload in unstable. The history for
> that version doesn't include the history for 1.5-1 to 1.5-5. I don't know if
> that was intentional. I updated the metadata for this bug to make sure it
> affects both. I might be good to consolidate the history of the
> package.

Agreed; there are several useful patches on the agx debian branch but
I'd lost track of that as the package hadn't been transitioned over to
salsa. I've created a salsa project now and anyone should be able to
make changes there.

Please feel free to hack on the code if you like. For instance, getting
Guido's autopkgtest bits re-integrated would be awesome. There are also
a couple of bug reports against 1.5 and it would be good to check and
see if they're still valid against 2.0.

-- 
-keith


signature.asc
Description: PGP signature

Bug#836691: Note#836690: ryan

[Ryan Keith]

K

On Sep 4, 2016 6:21 PM, "#WalPromos"  wrote:

> CongratsThis __is your__1,OOO.OO_Walmart___GiftCard
> 

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Alexander Larsson  writes:

> Yeah, assuming there is no global default salt that messes this up.

It sounds like having 'salt' values in dir and remap-dir elements is what
we want then -- no need for separate salt elements.

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Alexander Larsson  writes:

> We don't want a global salt for everything in the container.

I guess I wonder why not? Salt + dir inside the container will always be
unique. The place where you want to have different salt is for
directories mapped from the host; I think those will always be in
remap-dir clauses, if we have salt there, that should work?

> In
> reality things are more complicated than that. For example, an app may
> bundle fonts, which will be in like /app/share/fonts, in addition to
> the runtime fonts in /usr/share/fonts. These come from different
> places and may individually be different in a different (or updated)
> app, so the directories need to have different salts.

If building the flatpak generates the font caches, then per-flatpak salt
would make those correct.

> Also, it is quite possible that some host font directory is *not*
> remapped, but still visible to the app. For example /opt/fonts for an
> app that has filesystem access. If for whatever reason fontconfig
> looks at this directory it should not apply any salt for it.

Oh, so some host directories may be visible unmapped and unknown to the
flatpak? In that case, we'll need to enumerate all flatpak visible font
directories separately.

I think we need a complete enumeration of the cases; I keep seeing more
options...

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Alexander Larsson  writes:

> As I said in an earlier email, it needs to be in the individual dir
> elements, because a global salt is not right.

Do you want it in the  elements directly? That would be more
straightforward in many ways and could avoid troubles with separate salt
declarations that take effect more broadly than one directory.

So, one file (generated at flatpak creation time) with

/usr/share/fonts
/run/host/fonts

and another (generated at runtime) with

/run/host/fonts

Presumably you will mask all host configured font paths somehow? Maybe
you need to be able to inherit the 'salt' value from the host (if set)?
If so, we could have:

/run/host/fonts

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Akira TAGOH  writes:

> Yep, that looks good to me.

I don't time this week to hack on the code, and it looks like you're
doing great anyways; let me know if you need help in any way with the
implementation work.

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Akira TAGOH  writes:

> Hm, to deal with more complicated cases, I guess we may need to have
> one global salt to affect everything and a path-specific salt for
> remapped path.

Or, more likely, no salt at all for the outermost layer as it doesn't
really add anything here.

> for flatpak case, they want to have a global salt to
> change a salt in sandbox (for /usr/share/fonts in sandbox etc) and set
> salt from host in 'remap-dir' to build cache filenames on host (for
> /run/host/fonts and so on).

We may want a command line tool that extracts data from the config
for use by flatpak in building the dynamic configuration, including
things like salt values per directory. Yeah, that might be made to
work with flatpak essentially manually overriding the salt configuration
so that it uses the flatpak-relative names.

> This would avoid collision between one and origins. and assuming that
> flatpaks can load config from host too, we could have:
>
> 10-salt.conf (from host):
> 

I'd leave this out and not have salt in the host.

> 50-flatpak.conf (sandbox specific):
> /run/host/fonts
> 
> /usr/share/fonts

The salt here would need to have CDATA for the target directories, and I
think flatpack wants to split the dynamic from static config bits.

Dynamic (built at runtime):

 /run/host/fonts
 
Static (built in the flatpak):

 /usr/share/fonts



>
> First salt element affects to 'remap-dir' and second one overrides it
> for paths and change a salt in sandbox.

I think we can put that into the remap-dir element as both of those 
are built at runtime?

> To make things easier, we may also want to export all of dir elements
> from fonts.conf to the separate file. flatpak can replace it with
> 50-flatpak.conf in this case. or the file operation isn't desirable,
> let's implement dir-reset element or something like that.

I think a dir-reset makes a lot of sense so that the flatpak can control
the set of font paths used. Building a command-line tool that flatpak
can use to discover the relevant fontconfig information seems like a
useful improvement; as I recall, flatpak is currently assuming
/usr/share/fonts and ~/.fonts are used on the host.

-- 
-keith


signature.asc
Description: PGP signature

Bug#920956: ITP: fonts-recommended -- set of recommended fonts

[Keith Packard]

Adam Borowski  writes:

> Fonts people: as the first stab, I'll upload my picks with Fabian's input,
> then let's have a flamewar.

Can you point us at the proposed list?

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Akira TAGOH  writes:

> Hi,
>
> We are still missing a piece of a salt to deal with a directory name
> separately where possibly have different fonts in sandbox etc. my tree
> based on Keith's previous implementation works and passed test cases
> except this salt thing:
>
> https://gitlab.freedesktop.org/tagoh/fontconfig/commits/flatpak-rework

Awesome, thanks for getting this going. I'm digging out from being away
from the office for a week...

> So have we got a consensus on letting flatpak provide a separate
> config file contained a salt?

Yes, that was the plan. Alexander suggested the following syntax:

 /usr/share/fonts

I think this will work, although it seems a bit fragile. In particular,
if the host has salt for some directories, those will be defined
relative to the host paths, not the flatpak paths.

Do we need to process the 'salt' elements and 'remap-dir' elements in
order and remap old salt elements as remap-dir elements get loaded? That
also seems fragile to me.

Perhaps some command that the flatpak could run to generate host salt
values so that it could remap them into new salt elements using the
mapped paths?

Alternatively, we could just assume that only flatpak will use the salt
mechanism and leave this for a future enhancement?

-- 
-keith


signature.asc
Description: PGP signature

Bug#920698: mosh-server not found

[Keith Winstein]

Hello -- unfortunately mosh-server does need to be installed on the server
(it is sort of like ssh in this respect). You can either install it from a
package (which probably requires root -- you would need to ask the
sysadmin), or you can compile it from source, install it in your own home
directory, and give the location when starting mosh (e.g. "mosh
--server=/home/kaction/bin/mosh-server"). There are some instructions at
https://mosh.org you may find helpful.

Best regards,
Keith

On Mon, Jan 28, 2019 at 4:39 AM Dmitry Bogatov  wrote:

>
> Package: mosh
> Version: 1.3.2-2.1+b1
> Severity: wishlist
>
> Dear Maintainer,
>
> maybe I am doing it wrong, but I fail to make mosh do anything. Any
> attempt to connect host results in:
>
> $ mosh kact...@people.debian.org
> bash: mosh-server: Komando ne trovita
> Connection to people.debian.org closed.
> /usr/bin/mosh: Did not find mosh server startup message. (Have you
> installed mosh on
> your server?)
>
> Isn't it the idea, that mosh-server gets installed automatically?
> Obliviously, I do not have permission to do `apt-get install mosh' on
> remote host.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500,
> 'testing'), (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: runit (via /run/runit.stopit)
>
> Versions of packages mosh depends on:
> ii  dpkg1.19.2
> ii  libc6   2.28-5
> ii  libgcc1 1:8.2.0-14
> ii  libprotobuf17   3.6.1.3-1
> ii  libssl1.1   1.1.1a-1
> ii  libstdc++6  8.2.0-14
> ii  libtinfo6   6.1+20181013-1
> ii  libutempter01.1.6-3
> ii  openssh-client  1:7.9p1-5
> ii  zlib1g  1:1.2.11.dfsg-1
>
> Versions of packages mosh recommends:
> pn  libio-socket-ip-perl  
>
> mosh suggests no packages.
>
> -- no debconf information
>

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Akira TAGOH  writes:

> Sure. I started to implement it based on Keith's branch.

Awesome. I'll be back home "tomorrow" and able to spend some time on
this next week.

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Alexander Larsson  writes:

$ cat /run/host/font-dirs.xml
> 
> 
> 
> /run/host/fonts
> /run/host/user-fonts
> 
>
> Is this format acceptable? Its mostly about naming the nodes and the
> attributes, so its basically trivial. If you want i can rename things
> or change orders, but I'd really just like an Ack on something.

Format looks OK.

I think we might bike-shed on the names here a bit -- 'real-path' is
pretty ambiguous as both paths are 'real', one is just the file system
path and the other is the cache path. I like using the file system path
as the contents of the element and the cache path as the property, but
perhaps the property name could be 'cache-path' instead?

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Akira TAGOH  writes:

> Keith,
>
> I'm fine with it. do you have a time to work on it? or already started 
> working?
> If not, please let me know.

I've been at a conference all week, but hope to have time next
week. Would be happy to see others get this started, or collaborate in
any way. If I do get started, I'll be pushing stuff frequently and
posting mail so I don't block others.

Would be awesome to get this done in the next couple of weeks...

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Alexander Larsson  writes:

> Ugh. Sorry about that!

Thanks. Bugs happen, fortunately I was able to track this one down and
fix it (we all love free software!)

> Yes:ish. It should not *normally* happen. But you may run into it in
> uncommon situations like e.g. chrome using a statically linked version
> of fontconfig that has a different fontconfig cache format.

Hrm. I don't get the sense that we've got a solution to this problem
yet. Given that the contents of the flatpak cannot change on the fly,
would it be sufficient to generate a new 'salt' value for the flatpak
each time it is changed? It might be sufficient to use the name of the
flatpak including a version as this salt (that has the advantage of
making the flatpak reproducible, which you probably want to encourage).

> I agree with this, but the point was that we can't just modify the
> fontconfig to be dynamic always. We need to design it such that
> whatever flatpak generates is optional for the runtime to pick up when
> it is able to handle it.

Sounds like being able to handle an arbitrary host fonts directory
mounted as /run/host/fonts will really help avoid future issues. And
that needs to be in the fontconfig used inside the flatpak, which means
we can't wait for a system which has fonts in a different place and plan
on fixing it in the host.

> Yeah, there will be two files. One static in the runtime
> (/etc/fonts/conf.d/50-flatpak.xml), and one generated by flatpak
> (/run/host/fontconf.xml).

Sounds like we've got a plan for this part -- fix my mapping code to use
config bits separate from the  elements, then add a 'salt'
mechanism in the config bits that stirs in some random data when
generating the cache keys for specific directory trees.

Let's figure out how we should handle the stale flatpak fonts cache
issue. Once we've settled that, we can go implement the whole mess and
get a new fontconfig release made in time for debian freeze.

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

ing it into the existing  elements.

> However, the /etc/fonts/uuids file would still not be reproducible, so
> i'm not sure this is better than using uuids for the sandboxed dirs
> only, and then mapping the paths for picking up the host caches.

Right, the 'host' installation cannot include any UUID values to
ensure that builds are reproducible. That doesn't invalidate this
approach though; we can add UUID values for any directories within the
sandbox and those will not collide with the host entries.

> Currently the runtime contains a static conf.d snippet that says:
> /run/host/fonts
> /run/host/user-fonts
>
> We would have to turn that into a dynamic snippet. But that would be a
> problem for pre-existing flatpak binaries which doesn't do this.

Any existing flatpaks will presumably include an existing fontconfig
which will not use font caches for the host which will not have .uuid
files in each directory anyways. As long as those existing flatpaks
"work" by re-generating the cache at first start, that seems fine to
me. Re-create those flatpaks with new fontconfig bits and things will
work better.

> Flatpak generates at startup a file like this in /run/host/fontconf.xml
>
> /run/host/fonts>
> /run/host/user-fonts>
>
> In the runtime we create at build-time a /etc/fonts/conf.d/ file:
>
> /usr/share/fonts
> # Duplicate this with static versions for old flatpak versions
> /run/host/fonts>
> # This will (if it exists) override the above with the live values
> /run/host/fontconf.xml

I think you'll want two separate files -- the salt is "constant" for the
flatpak, while the cache-as values depend on the host
environment. Otherwise, this looks good to me.

If we can convince you to mount the host font paths inside the runtime
where they had been in the host, then we don't even need that part. But
I can easily see where you'd end up with a pile of magic conditionals to
avoid having some critical part of the flatpak file system smashed by
fonts. Plus, we've already got that part of the solution mostly
implemented, and we all know how horrible it is to throw away code (just
kidding).

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

ific-font which is in the app but not the
> host..

This is not an entirely theoretical issue -- I've run into the
ruby-prawn-icon package in the last week. That ships a selection of
fonts and accesses them via hard-coded paths. "Fortunately", the default
location for those is not within /usr/share/fonts, but I could be
convinced that these fonts should be installed in /usr/share/fonts to
match distribution policy/conventions.

I know -- 'union mounts' to the rescue! (not a serious suggestion)

> Also, we'll be guaranteeing that caches for /usr/share/fonts and
> /usr/share/fonts-minimal don't conflict, but there is no guarantee
> that different versions of /usr/share/fonts-minimal don't conflict.

I don't understand this -- the cache for /usr/share/fonts-minimalive inside the 
flatpak environment, and should be per-flatpak?

> Here is my proposal:
>
> Make the uuid *generation* optional and manual. Then, when we create
> the flatpak runtime we run fc-cache --make-uuid (or something) to
> generate the uuid files. Then fontconfig would never confuse the
> sandboxed /usr/share/fonts with any other, and since we would get a
> new uuid each time we regenerated the runtime it would correctly pick
> up stale caches when we update the runtime (even with no mtime
> change).

Hrm. This is a tempting solution -- normal users would never see .uuid
files at all.

However, it means that new directories created within the flatpak while
the system is running would not get .uuid files and might then have
cache names which collide with the outer system.

How about making it a font configuration per-'dir' option instead? This
way, uuid files would be automatically added to all 'internal'
directories and never to external ones.

And users could add this when adding references to external font
repositories.

> This would make the default installation of fontconfig reproducible,
> and it would solve the first problem (don't mix up sandboxed and host
> font dirs). It would also let you opt-in to the uuid in other cases
> where it makes sense. For instance, you could have a uuid file on a
> NFS share or USB drive font dir, so that any caches for it will always
> be the same no matter how it happens to be mounted.

It sounds like a good direction for discussion at least.

> We still wouldn't have a way to reuse host caches which were mounted
> in a different way, but if we assume all conflicting directories use
> uuids (like they would in the flatpak case), then we could solve this
> in a pretty simple way by a config file saying "treat all instances of
> /run/host/fonts as /usr/share/fonts", and I could make flatpak
> generate such a file.

I've already got a patch series which solves this problem -- you can map
paths to cache keys on a per-'dir' element basis.

Here's an alternative proposal:

Add a per 'dir' element 'salt' value, which is stirred into the
path name when generating the cache key. You'd generate this
randomly when the flatpak was created so that all cache keys
would not collide with entries using a different (or absent)
salt value.

With this, and my path->key mapping series, we would be able to access
the existing cache files for external fonts (via the mapping mechanism), as
well as avoid collisions between internal and external font paths within
the cache. And we wouldn't have .uuid files (see above).

I still don't understand how UUID files help with the missing mtime
issue though; if you could explain that in a bit more detail, that would
help me, and perhaps expose a weakness with my alternative proposal.

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Akira TAGOH  writes:

> Indeed, that would be able to accomplish both with the minimal efforts
> for us at least. though they might came up with this but they didn't
> do it that way. so there might be some reason why they didn't do so.
> packaging issue perhaps?

flatpak appears to change many pathnames used to access host files. I
don't know if there are other subsystems affected by these changes,
perhaps we'll see more in the future though.

> I can't figure out completely but, fontconfig may needs to deal with
> different namespaces in a cache filename to avoid a collision between
> host and sandboxes. dunno if we may see different state in the future
> but it might be represented as a depth in a filename to make it
> different like 0:-le64.cache- for host and
> 1:-le64.cache- for a sandbox.
>
> we could increase a depth
> for a child in sandbox as needed, anyway.
> We can mix up caches that is located at the same place then. the last
> missing piece would be to map them to the right place. flatpaks should
> knows where they mounted directories to. they can create a map table
> with proper parent depth and current depth I think.

That would require customizing the contents of a flatpak on install, or
perhaps this could be done when the flatpak was run?

> I may be missing something so this might not work though...

This seems to extend the change I proposed; which provides an
indirection between the actual filename and the font config cache
database key. Instead of just mapping sandbox names to external names
(which results in collisions), we also add some 'salt' to the sandbox
names to perturb the generated key for internal paths.

Let's look at some examples:

sandbox prefix  cache prefix
--  --
/run/host/fonts /usr/share/fonts
/run/host/user-fonts/home/keithp/.fonts
/   sandbox-depth-1/

'sandbox-depth-1' is the "salt" added to the cache keys for paths within
the sandbox to ensure they do not collide with cache keys for paths
outside of the sandbox.

You'd add all mounted file systems to this list so that fonts found
anywhere outside the sandbox would generate cache keys using the names
from outside the sandbox. If you ran another sandbox *inside* this
sandbox, you'd have another level of indirection:

/run/host/fonts sandbox-depth-1/usr/share/fonts
/   sandbox-depth-1/

(assuming that the sandbox didn't manage to mount the "real" system
fonts inside the sandbox somewhere).

This configuration file would be generated by flatpak at runtime.

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Akira TAGOH  writes:

> As of the discussion on the list, Keith's changes doesn't address the
> original purpose - allow sharing caches on bind-mounts in flatpaks.
> particularly for the case where flatpaks uses same location in
> sandbox.

I'm probably forgetting a bunch of context here, but I think the problem
was that flatpaks have /run/host/fonts pointing to the "real"
/usr/share/fonts and then a separate /usr/share/fonts of their own with
a small set of fonts, and so you end up with collisions in the cache
file namespace as both directories end up generating the same cache file
name.

> this is the reason why it can't be merged into master.  So just
> reverting the change that removes .uuid file only when a directory has
> empty is done in master so far. if you have .uuid file prior to run
> fc-cache, your issue could be worked around at this moment. for more
> details, you can check what Alex Larsson said on this list.

Making the build reproducible means having all content generated
deterministically based only on the source package and toolchain. The
current UUID files are generated randomly making them
non-deterministic.

For the font cache, making it reproducible requires that the keys
mapping directories to cache filenames be the same each time the cache
is built. This means we cannot use the current randomly generated UUID
values and also have a reproducible system.

I considered whether we might provide a mechanism to generate UUID
values deterministically for purposes of packaging. However, this would
mean that we couldn't use these same packages when creating a flatpak as
the deterministic UUID values would collide if those same packages were
used in the outer system.

Without deterministic UUID values, I'm left with the feeling that
our only available solutions involve changing how flatpaks reference
fonts.

If we agree that a solution to this involves changing the flatpak
mechanism, I'd like to suggest that the most straightforward fix for the
overall system would be to expose the external fonts using the external
path names -- bind mounting the external /usr/share/fonts as
/usr/share/fonts within the flatpak, and creating a new
/usr/share/fonts-minimal (or whatever) to hold the fonts provided by the
flatpak itself. With this change, we can simply delete the UUID code
from fontconfig and go back to using global font paths as keys to the
font cache database.

I'd love to hear about alternative ideas which might lead to solutions
that make builds involving fontconfig reproducible. I'd be happy to take
even vague hints at this point; all I've got at this point are a
collection of dead ends.

(Also, if I've missed or forgotten something relevant, please let me
know; I've re-read a lot of stuff while writing this, but surely
something escaped my notice).

-- 
-keith


signature.asc
Description: PGP signature

Bug#855025: I'm also seeing the reported issue

[Keith A. Bare II]

I believe I also ran across this issue tonight, working on building a dev
VM for a project.

>From .xsession-errors / the VNC server log:

...
** Message: main.vala:102: Session is LXDE
** Message: main.vala:103: DE is LXDE
** Message: main.vala:134: log directory:
/scratch/kbare/.cache/lxsession/LXDE
** Message: main.vala:135: log path:
/scratch/kbare/.cache/lxsession/LXDE/run.log

And then the LXDE/run.log:

...
** Message: app.vala:130: lxpanel exit with this type of exit: 139
** Message: app.vala:148: Exit not normal, try to reload
** Message: app.vala:76: Launching lxpanel
process 19874: arguments to dbus_message_new_method_call() were incorrect,
assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line
1367.
This is normally a bug in some application using the D-Bus library.
** Message: x-terminal-emulator has very limited support, consider choose
another terminal

** (light-locker:19874): WARNING **: screensaver already running in this
session
** Message: app.vala:130: lxpanel exit with this type of exit: 139
** Message: app.vala:148: Exit not normal, try to reload
...
** Message: app.vala:130: lxpanel exit with this type of exit: 139
** Message: app.vala:148: Exit not normal, try to reload
** Message: app.vala:156: Application crashed too much, stop reloading

Collected core files, and the crashing thread's backtrace matches:

(gdb) bt
#0  0x55d7311c8c90 in task_button_window_focus_changed
(button=0x55d7321901b0 [TaskButton], win=0x0) at task-button.c:1668
#1  0x7fab4ecf1d15 in panel_icon_grid_forall (container=, include_internals=, callback=0x55d7311c8c60
, callback_data=0x0) at icon-grid.c:1081
#2  0x55d7311c4e0d in taskbar_net_active_window (tb=0x55d7321fe640,
widget=) at launchtaskbar.c:2284
#3  0x55d7311c5403 in taskbar_net_active_window (tb=0x55d7321fe640,
widget=0x0) at launchtaskbar.c:2279
#4  0x55d7311c5403 in launchtaskbar_constructor_task
(ltbp=ltbp@entry=0x55d7321fe640)
at launchtaskbar.c:1059
#5  0x55d7311c5605 in _launchtaskbar_constructor (panel=0x55d7320b14a0
[PanelToplevel], settings=0x55d732154f40, mode=) at
launchtaskbar.c:1159
#6  0x7fab4ecf9275 in lxpanel_add_plugin (p=p@entry=0x55d7320b14a0
[PanelToplevel], name=0x55d732154240 "taskbar", cfg=cfg@entry=0x55d732154e40,
at=at@entry=-1) at plugin.c:542
#7  0x7fab4ecf6bc2 in panel_parse_plugin (cfg=0x55d732154e40,
p=0x55d7320b14a0 [PanelToplevel]) at panel.c:1593
#8  0x7fab4ecf6bc2 in panel_start_gui (panel=panel@entry=0x55d7320b14a0
[PanelToplevel], list=list@entry=0x7fab3c003f80) at panel.c:1691
#9  0x7fab4ecf75fb in panel_start (p=0x55d7320b14a0 [PanelToplevel]) at
panel.c:1992
#10 0x7fab4ecf75fb in panel_new (config_file=,
config_name=) at panel.c:2014
#11 0x55d7311bfc1b in _start_panels_from_dir (panel_dir=0x55d7321493c0
"/etc/xdg/lxpanel/LXDE/panels") at main.c:415
#12 0x55d7311bdd16 in start_all_panels () at main.c:440
#13 0x55d7311bdd16 in main (argc=, argv=,
env=0x7ffcb135ace8) at main.c:568

Trying to figure out what might be going on, I did a Google search for
"taskbar_net_active_window", and found this discussion of window manager
hints.

https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472702304

> The window ID of the currently active window or None if no window has
the focus.

I'm guessing maybe the problem is, since no VNC client has connected,
there's no active Window, i.e., the None case, and lxpanel isn't handling
that properly.

One thing that I've noticed that's kind of weird, is I do get the lxpanel
the first time after I delete all of the .cache .config and .local
directories.  I think it's because clipit makes a pop-up asking if I want
to save the clipboard to a file--which creates and activates a window,
making the win parameter non-NULL.

Another tricky thing is if you connect to the VNC server fast enough, while
the session is still doing its reload attempts, you also end up getting the
panel.

In any case, I'll try Sebastian's patch.

--Keith Bare

Bug#911120: espeakup fails to install

[Keith Barrett]

On 15/10/18 22:02, Samuel Thibault wrote:

Hello,

Keith Barrett, le dim. 14 oct. 2018 16:50:08 +0100, a ecrit:

I removed the package with a view to reinstalling but

invoke-rc.d: initscript espeakup, action "start" failed.


Mmm, perhaps you just need to have the speakup_soft module loaded?

I.e. just run modprobe speakup_soft before this.

Right, no joy, unfortunately.

sudo modprobe speakup_soft
No error message.

sudo apt-get install espeakup
Reading package lists...
Building dependency tree...
Reading state information...
espeakup is already the newest version (1:0.80-10).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Setting up espeakup (1:0.80-10) ...
update-rc.d: warning: start and stop actions are no longer supported; 
falling back to defaults
Job for espeakup.service failed because the control process exited with 
error code.

See "systemctl status espeakup.service" and "journalctl -xe" for details.
invoke-rc.d: initscript espeakup, action "start" failed.
● espeakup.service - Software speech output for Speakup
   Loaded: loaded 
(#]8;;file://debian/lib/systemd/system/espeakup.service#/lib/systemd/system/espeakup.service#]8;;#; 
enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 
2018-10-15 23:15:52 BST; 17ms ago

 Docs: #]8;;man:espeakup(8)#man:espeakup(8)#]8;;#
  Process: 3089 ExecStart=/usr/bin/espeakup -V ${VOICE} 
#[0;1;31m(code=exited, status=2)#[0m

dpkg: error processing package espeakup (--configure):
 installed espeakup package post-installation script subprocess 
returned error exit status 1

Errors were encountered while processing:
 espeakup
E: Sub-process /usr/bin/dpkg returned an error code (1)
espeakup -d
Unable to open the softsynth device no such file or directory








I'll make espeakup to just load the module itself to avoid that issue.


If that's not the issue, you can try to run espeakup by hand to see
which error shows up:

espeakup -d

Samuel

Bug#911120: espeakup: Does not fully install

[Keith Barrett]

Package: espeakup
Version: 1:0.80-10
Severity: grave
Tags: a11y
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Frequent loss of speech in the console, particularly when switching to another 
console or from the desktop.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Removed the package with a view to reinstalling.

   * What was the outcome of this action?
Package failed to install
   * What outcome did you expect instead?
Package to fully install and work.
*** End of the template - remove these template lines ***


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.18.0-2-686-pae (SMP w/2 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages espeakup depends on:
ii  espeak 1.48.04+dfsg-6
ii  libc6  2.27-6
ii  libespeak-ng1  1.49.2+dfsg-4
ii  lsb-base   9.20170808

espeakup recommends no packages.

espeakup suggests no packages.

-- no debconf information

Bug#908545: postfix: upgrade queries about replacing /etc/postfix/makedefs.out, when it really should always do so

[Keith Zubot-Gephart]

Package: postfix
Version: 3.3.0-1ubuntu0.1
Severity: minor

As you can tell from the version, I'm actually encountering this problem
on Ubuntu, but this is merely a packaging matter so filing this upstream
seemed valid!

When upgrading Postfix, I was surprised to be asked

Configuration file '/etc/postfix/makedefs.out'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** makedefs.out (Y/I/N/O/D/Z) [default=N] ?

This would appear to have been added with version 3.1.4-1, specifically:

  * Install /etc/postfix/makedefs.out so users can see how the package was 
built

which is a laudable and understandable goal. However, it seems quite 
unequivocal that the package-provided version of this file should always be 
used when installing the package, since the file itself opens with the 
following line:

  # Do not edit -- this file documents how Postfix was built for your machine.

There does not seem to be a valid reason for a user to have a version of that 
file that differs at all from the package-provided version, then; any 
divergence, in fact, would be misleading.

Presumably then this file should be included in a way that does not require 
user intervention to update the makedefs.out file (ex. the /etc/ copy could 
just be a symlink to a copy in /usr/share/postfix/, or perhaps there's some 
packaging magic that could be done?).

(I suppose I should probably have filed this bug upstream with Debian, but I 
don't actually have any Debian systems running Postfix at the moment, only 
Ubuntu Server ones.)

Bug#908453: Also checked 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10

[Keith Bare]

In my initial bug submission, I indicated I saw the problem in version
4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9, as that was what my system was
running when I first noticed Xen ignoring type = 'pvh'.

I saw there was an update: 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10.  Since
it looks like it's using a newer upstream version, I wanted to check whether
it also ignores type = 'pvh'.  I could imagine maybe some of the comet
changes were merged in...

But, even with the deb9u10 package, I'm still seeing that DomUs will boot in
PV mode when their configuration specifies type = 'pvh'.

--Keith Bare

Bug#908453: xen-utils-common: README.comet seems to no longer apply to the current Xen packages

[Keith Bare]

Package: xen-utils-common
Version: 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
Severity: important

Dear Maintainer,

   * What led up to the situation?

I needed to build a new Xen DomU.  Since I had seen that Debian had picked
up the 4.8 "comet" changes and pvshim, I wanted to experiment with Xen's PVH
mode and have the DomU run the Linux 4.17 kernel in stretch-backports, which
should be new enough to support PVH.

It seemed like this should work, given instructions in
/usr/share/doc/xen-utils-common/README.comet
 
* Converting a PV config to a PVH config

If you have a kernel capable of booting PVH, then PVH mode is both
faster and more secure than PV or PVH-shim mode.

- Remove any reference to 'builder' (e.g., `builder="generic"`)
- Add the following line:
  type="pvh"



   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I ran xen-create-image (from the xen-tools package) with --dist=stretch to
build the DomU and its configuration.  I also used --pygrub so Xen would
boot the kernel installed in the DomU's filesystem.

I temporarily edited the DomU's Xen/xl configuration to use the pvshim, per
the instructions in README.comet (type = 'pvh' / pvshim = 1), started the
DomU, added the stretch-backports repository, and installed
linux-image-amd64 from backports.  I then shut down the DomU, edited the
DomU's configuration to remove the pvshim = 1 line, and re-started the DomU.


   * What was the outcome of this action?

It appeared the DomU was running in PV mode, despite my having added type =
'pvh' to its Xen/xl configuration.

It was difficult to tell, but I believed the DomU was running in PV mode as
its kernel printed:

 - [0.00] Hypervisor detected: Xen PV
 - [0.00] Kernel/User page tables isolation: disabled on XEN PV.

Some Internet searching also seemed to indicate that "xl list -l "
should mention "pvh" if the DomU is running in PVH mode.  However, I only
saw:

 - "type": "pv",

There was no mention of "pvh" in the output.


   * What outcome did you expect instead?

I expected the DomU to run in PVH mode.  I wasn't sure what this was
supposed to look like, but I did some experiments (installed the old
4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 packages and worked around
bootloader being broken for PVH) and saw that in fact, with that version of
the Xen packages, the DomU kernel prints:

 - [0.00] Hypervisor detected: Xen HVM
 - [0.00] Booting paravirtualized kernel on Xen PVH
 - [0.00] Kernel/User page tables isolation: enabled

And xl list -l  shows:

 - "type": "pvh",


   * More thoughts/discussion.

It looks like the Debian packages lost support for booting DomUs in PVH mode
with version 4.8.3+xsa262+shim4.10.0+comet3-1+deb9u6.  Probably because:

Update to new upstream version 4.8.3+xsa262+shim4.10.0+comet3.
(This is the upstream staging-4.8 branch, which is ahead of the
upstream CI-tested stable-4.8 branch by precisely the three
most recent XSA fixes.  We are switching away from the special
upstream 4.8 comet branch.)

And maybe that's fine... if the mitigation comet and the pvshim provided is
also effectively provided by XPTI changes that were present in the
stable-4.8 branch, then I guess it isn't really necessary for anybody to use
(and thus PVH-mode boot) the shim anymore.  However, if that's the case,
then it probably doesn't make sense to include README.comet and continue
packaging the shim in the Debian packages anymore.

The thing that's nefarious (and could be grounds for increasing the bug
severity), is that anybody that followed the README.comet instructions and
configured DomUs to boot a PVH-capable kernel without the shim is now,
probably to their surprise, running their DomU in PV mode.  This means
they've lost Linux's KPTI protections from Meltdown within their DomU.  The
underlying issue is that the xl command seems to silently ignore
configuration directives it doesn't understand--which, without the 4.8
comet2 changes, includes 'type'!

This isn't a huge deal for me and my deployment (at the CMU Computer Club).
Our Xen infrastructure was running jessie/Xen 4.4 at best when the
Meltdown/Spectre news broke.  So our initial mitigation was to switch
everything to run in HVM mode (and we've continued doing so since then).  I
was interested in exploring PVH mode though, since it looked like it was
more similar to PV mode in some ways that would make it work better with
various tooling (e.g., xen-tools).  The fact it didn't work with the Debian
packages the way I thought it would was surprising, and I figured it might
be surprising for other people too.

--Keith Bare


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-7-amd64 (SMP w/16 CPU cores)
Locale:

Bug#906785: version warping patch is overly aggressive

[Keith Packard]

Markus Koschany  writes:

> I'm waiting for Emmanuel to chime in now. Maybe I missed something
> important. Otherwise I think we can resolve this issue rather quickly.
> Since Ant isn't the only build system for Java, we probably should
> change this for Maven too. We haven't implemented the same for Gradle
> yet. [1]

We only discovered that ant was the source of trouble by comparing the
output of a project built using that and another project build using a
simple Makefile.

If you're going to stop supporting older API versions, I'd suggest that
the tool should exit with an error status rather than silently
corrupting the build process. We spent a couple of days tracking down
this issue, which would have been obvious had the package build simply
failed when it used -target 1.4.

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: fontconfig: please make the cache files reproducible

[Keith Packard]

Chris Lamb  writes:

> Chris Lamb wrote:
>
>> This was merged into the upstream Git repository - would it be
>> possible to make another Debian release with this change? :)
>
> Gentle ping on this? :) Would love to see this Tails-related work
> in Debian!

I was stalling for an upstream release with this patch; it looks like
that shouldn't be more than a month or two from now. Any particular
reason for urgency here?

-- 
-keith


signature.asc
Description: PGP signature

Bug#882444: xrandr doesn't select DoubleScan modes by name without refresh rate

["Keith Packard"]

This bug is caused by a change made in 2009 where xrandr ignores
DoubleScan modes unless the user has specified a refresh rate. I don't
know what this wanted to fix, so I'm hesitant to fix it. However, a
reasonable workaround for the user is to simply specify a non-zero
refresh rate.

-- 
-keith


signature.asc
Description: PGP signature

Bug#899300: mosh: apt-get install error in jessie-backports

[Keith Winstein]

Thank you for the bug report. I believe this is a duplicate of bug 803253,
which was fixed in mosh 1.2.5-1.1.

2018-05-22 1:08 GMT-07:00 ikar.us :

> Package: mosh
> Version: 1.2.5-1~bpo8+1
> Severity: important
>
>
> root@:~# apt-get -t jessie-backports install mosh
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.
> Statusinformationen werden eingelesen Fertig
> Die folgenden Pakete wurden automatisch installiert und werden nicht mehr
> benötigt:
>   libevent-2.0-5 libnfsidmap2 libtirpc1 php5-sqlite
> Verwenden Sie »apt-get autoremove«, um sie zu entfernen.
> Die folgenden zusätzlichen Pakete werden installiert:
>   libprotobuf9 libutempter0
> Die folgenden NEUEN Pakete werden installiert:
>   libprotobuf9 libutempter0 mosh
> 0 aktualisiert, 3 neu installiert, 0 zu entfernen und 44 nicht
> aktualisiert.
> Es müssen 580 kB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 2.287 kB Plattenplatz zusätzlich benutzt.
> Möchten Sie fortfahren? [J/n] J
> Holen: 1 http://ftp.de.debian.org/debian/ jessie/main libprotobuf9 amd64
> 2.6.1-1 [361 kB]
> Holen: 2 http://ftp.de.debian.org/debian/ jessie/main libutempter0 amd64
> 1.1.5-4 [8.020 B]
> Holen: 3 http://ftp.de.debian.org/debian/ jessie-backports/main mosh
> amd64 1.2.5-1~bpo8+1 [211 kB]
> Es wurden 580 kB in 0 s geholt (2.867 kB/s).
> Vormals nicht ausgewähltes Paket libprotobuf9:amd64 wird gewählt.
> (Lese Datenbank ... 37354 Dateien und Verzeichnisse sind derzeit
> installiert.)
> Vorbereitung zum Entpacken von .../libprotobuf9_2.6.1-1_amd64.deb ...
> Entpacken von libprotobuf9:amd64 (2.6.1-1) ...
> Vormals nicht ausgewähltes Paket libutempter0 wird gewählt.
> Vorbereitung zum Entpacken von .../libutempter0_1.1.5-4_amd64.deb ...
> Entpacken von libutempter0 (1.1.5-4) ...
> Vormals nicht ausgewähltes Paket mosh wird gewählt.
> Vorbereitung zum Entpacken von .../mosh_1.2.5-1~bpo8+1_amd64.deb ...
> dpkg: Fehler: --compare-versions akzeptiert drei Argumente: 
>  
>
> Nutzen Sie dpkg --help für Hilfe zur Installation und Deinst. von Paketen
> [*];
> Benutzen Sie »apt« oder »aptitude« für benutzerfreundliches
> Paketmanagement;
> Nutzen Sie dpkg -Dhelp für eine Liste von Debug-Flags von dpkg;
> Nutzen Sie dpkg --force-help für eine Liste von Optionen zum Erzwingen;
> Nutzen Sie dpkg-deb --help für Hilfe zum Manipulieren von *.deb-Dateien;
>
> Optionen mit [*] geben viel aus - schicken Sie es durch »less« oder »more«!
> Entpacken von mosh (1.2.5-1~bpo8+1) ...
> Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
> libprotobuf9:amd64 (2.6.1-1) wird eingerichtet ...
> libutempter0 (1.1.5-4) wird eingerichtet ...
> Creating utempter group...
> mosh (1.2.5-1~bpo8+1) wird eingerichtet ...
> Trigger für libc-bin (2.19-18+deb8u10) werden verarbeitet ...
> root@:~#
>
>
>
> -- System Information:
> Debian Release: 8.10
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-5-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mosh depends on:
> ii  dpkg1.17.27
> ii  libc6   2.19-18+deb8u10
> ii  libgcc1 1:4.9.2-10+deb8u1
> ii  libprotobuf92.6.1-1
> ii  libssl1.0.0 1.0.1t-1+deb8u8
> ii  libstdc++6  4.9.2-10+deb8u1
> ii  libtinfo5   5.9+20140913-1+deb8u2
> ii  libutempter01.1.5-4
> ii  openssh-client  1:6.7p1-5+deb8u4
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> Versions of packages mosh recommends:
> ii  libio-socket-ip-perl  0.32-1
> ii  perl-base [libio-socket-ip-perl]  5.20.2-3+deb8u10
>
> mosh suggests no packages.
>
> -- no debconf information
>

Bug#864082: fontconfig: please make the cache files reproducible

[Keith Packard]

Chris Lamb <la...@debian.org> writes:

> Hi Keith,
>
>> > +source_date_epoch = getenv("SOURCE_DATE_EPOCH");
>> 
>> Could this work as a build-time value in the library instead of a
>> run-time environment variable?
>
> Unfortunately not. Imagine the situation where we are installing
> font packages in a chroot that will eventually end up as, for
> example, an .ISO: in this case, we are running fc-cache at runtime
> (in Debian's case, via the dpkg trigger).

Thanks for the explanation.

I think it would be useful for me to understand when and where the cache
files end up being part of a build product and then figuring out what
the right solution is in each case, rather than an environment variable
kludge of this nature.

For instance, in the case described above, the ISO is read-only in use,
and so the cache file contents *cannot* be out of date, and should
always be used with no need to even check the timestamps on
directories. I can imagine a special flag to fc-cache that would
mark the cache files for this use. I feel that this would solve the
problem in a better way.

-- 
-keith


signature.asc
Description: PGP signature

Bug#864082: fontconfig: please make the cache files reproducible

[Keith Packard]

Chris Lamb <la...@debian.org> writes:


> +source_date_epoch = getenv("SOURCE_DATE_EPOCH");

Could this work as a build-time value in the library instead of a
run-time environment variable?

-- 
-keith


signature.asc
Description: PGP signature

Bug#894271: ITP: cmark-gfm -- GitHub enhanced version of cmark, the common markdown parser

[Keith Packard]

Package: wnpp
Severity: wishlist
Owner: Keith Packard <kei...@debian.org>

* Package name: cmark-gfm
  Version : 0.28.3.gfm.12
  Upstream Author : John MacFarlane <j...@berkeley.edu>
* URL : https://ithub.com/github/cmark
* License : BSD, MIT/X
  Programming Lang: C
  Description : GitHub enhanced version of cmark, the common markdown
parser

Common Markdown provides a useful standardized language for building formatted
documents. The 'cmark' parser, already in Debian, provides a basic parser
implementing the core Common Markdown standard. People involved in the GitHub
system have forked 'cmark' in a way which leaves the core language unchanged
but extends the system to add table and other additional formatting methods.

This extended version of Common Markdown is used within the github system for
formatting .md files in project repositories and, as such, is becoming widely
used within that environment.

I've got preliminary packaging working here:

https://anonscm.debian.org/cgit/users/keithp/cmark-gfm.git/

I'm packaging this so I can use it to replace asciidoc in the altos package as
asciidoc is being deprecated.

Bug#892929: gambas3: Crashes upon start. [20] Bad Argument. Settings.WriteWindow.388

[Keith Brown]

Package: gambas3
Version: 3.9.2-2
Severity: important

Dear Maintainer,

Upon starting Gambas3, a message window immediately pops up claiming "[20] Bad 
Argument. Settings.WriteWindow.388", with only an ok button to acknowledge. 
Upon acknowledgement, the application closes. At this point in time, Gambas3 is 
unusable.


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

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

Versions of packages gambas3 depends on:
ii  gambas3-gb-args 3.9.2-2
ii  gambas3-gb-cairo3.9.2-2+b3
ii  gambas3-gb-chart3.9.2-2
ii  gambas3-gb-clipper  3.9.2-2+b3
ii  gambas3-gb-complex  3.9.2-2+b3
ii  gambas3-gb-compress-bzlib2  3.9.2-2+b3
ii  gambas3-gb-compress-zlib3.9.2-2+b3
ii  gambas3-gb-crypt3.9.2-2+b3
ii  gambas3-gb-data 3.9.2-2+b3
ii  gambas3-gb-db-form  3.9.2-2
ii  gambas3-gb-db-mysql 3.9.2-2+b3
ii  gambas3-gb-db-odbc  3.9.2-2+b3
ii  gambas3-gb-db-postgresql3.9.2-2+b3
ii  gambas3-gb-db-sqlite3   3.9.2-2+b3
ii  gambas3-gb-dbus 3.9.2-2+b3
ii  gambas3-gb-desktop  3.9.2-2+b3
ii  gambas3-gb-desktop-gnome3.9.2-2
ii  gambas3-gb-desktop-x11  3.9.2-2+b3
ii  gambas3-gb-form-dialog  3.9.2-2
ii  gambas3-gb-form-mdi 3.9.2-2
ii  gambas3-gb-form-stock   3.9.2-2
ii  gambas3-gb-form-terminal3.9.2-2
ii  gambas3-gb-gmp  3.9.2-2+b3
ii  gambas3-gb-gsl  3.9.2-2+b3
ii  gambas3-gb-gui-opengl   3.9.2-2+b3
ii  gambas3-gb-gui-qt   3.9.2-2+b3
ii  gambas3-gb-gui-qt-webkit3.9.2-2+b3
ii  gambas3-gb-httpd3.9.2-2+b3
ii  gambas3-gb-image-effect 3.9.2-2+b3
ii  gambas3-gb-image-imlib  3.9.2-2+b3
ii  gambas3-gb-image-io 3.9.2-2+b3
ii  gambas3-gb-inotify  3.9.2-2+b3
ii  gambas3-gb-libxml   3.9.2-2+b3
ii  gambas3-gb-logging  3.9.2-2
ii  gambas3-gb-map  3.9.2-2
ii  gambas3-gb-markdown 3.9.2-2+b3
ii  gambas3-gb-media3.9.2-2+b3
ii  gambas3-gb-memcached3.9.2-2
ii  gambas3-gb-mime 3.9.2-2+b3
ii  gambas3-gb-mysql3.9.2-2+b3
ii  gambas3-gb-ncurses  3.9.2-2+b3
ii  gambas3-gb-net-curl 3.9.2-2+b3
ii  gambas3-gb-net-pop3 3.9.2-2+b3
ii  gambas3-gb-net-smtp 3.9.2-2+b3
ii  gambas3-gb-openal   3.9.2-2+b3
ii  gambas3-gb-opengl-glsl  3.9.2-2+b3
ii  gambas3-gb-opengl-glu   3.9.2-2+b3
ii  gambas3-gb-opengl-sge   3.9.2-2+b3
ii  gambas3-gb-openssl  3.9.2-2+b3
ii  gambas3-gb-option   3.9.2-2+b3
ii  gambas3-gb-pcre 3.9.2-2+b3
ii  gambas3-gb-pdf  3.9.2-2+b3
ii  gambas3-gb-qt5  3.9.2-2+b3
ii  gambas3-gb-qt5-ext  3.9.2-2+b3
ii  gambas3-gb-qt5-webkit   3.9.2-2+b3
ii  gambas3-gb-report   3.9.2-2
ii  gambas3-gb-report2  3.9.2-2
ii  gambas3-gb-scanner  3.9.2-2+b3
ii  gambas3-gb-sdl-sound3.9.2-2+b3
ii  gambas3-gb-sdl2 3.9.2-2+b3
ii  gambas3-gb-sdl2-audio   3.9.2-2+b3
ii  gambas3-gb-settings 3.9.2-2
ii  gambas3-gb-util 3.9.2-2+b3
ii  gambas3-gb-util-web 3.9.2-2+b3
ii  gambas3-gb-v4l  3.9.2-2+b3
ii  gambas3-gb-vb   3.9.2-2+b3
ii  gambas3-gb-web  3.9.2-2
ii  gambas3-gb-xml-html 3.9.2-2+b3
ii  gambas3-gb-xml-rpc  3.9.2-2
ii  gambas3-gb-xml-xslt 3.9.2-2+b3
ii  gambas3-ide 3.9.2-2
ii  gambas3-templates   3.9.2-2+b3

gambas3 recommends no packages.

gambas3 suggests no packages.

-- no debconf information

Bug#890973: ITP: xorgproto -- X11 extension protocols and auxiliary headers

[Keith Packard]

Timo Aaltonen <tjaal...@debian.org> writes:

> Package: wnpp
> Severity: wishlist
> Owner: Timo Aaltonen <debia...@lists.debian.org>
>
> * Package name: xorgproto
>   Version : 2018.3
>   Upstream Author : X.Org
> * URL : http://www.x.org/
> * License : MIT/X
>   Programming Lang: C
>   Description : X11 extension protocols and auxiliary headers
>
> This package provides development headers describing the wire protocol
> for the X11 core and extension protocols, and also provides a number of
> utility headers, used to abstract OS-specific functions.

Just as a note to the curious; we're merging all of the protocol headers
into a single repository to reduce our development work. Future changes
to any of these headers will only be released in this combined format;
the separate repositories will be frozen.

-- 
-keith


signature.asc
Description: PGP signature

Bug#880014: #880014: Call for Votes for new TC member

[Keith Packard]

Didier 'OdyX' Raboud <o...@debian.org> writes:

> ===BEGIN
> The Technical Committee recommends that Gunnar Wolf <gw...@debian.org> be
> appointed by the Debian Project Leader to the Technical Committee.
>
> G: Recommend to Appoint Gunnar Wolf <gw...@debian.org>
> F: Further Discussion
> ===END

I vote G > F

-- 
-keith


signature.asc
Description: PGP signature

Bug#873523: i sent to you on 10/06/2017 ?

[campion keith]

Please confirm if you really got the mail which i sent to you on 10/06/2017
?

How is your entire family and you too?

Regards,

Campion.

Bug#851670: i sent to you on 03/06/2017?

[campion keith]

Please confirm if you really got the mail which i sent to you on 03/06/2017?

How is your entire family and you too?

Regards.
Campion.

Bug#877024: Modemmanager probing of unknown Devices

[Keith Packard]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> I intend to carry on and try to help do the Debian part of this, with
> NMUs as seem appropriate.  My earlier email suggesting an upload to
> experimental is part of that.  If the modemmanager maintainers would
> like to step in then that would be great of course.  Just let me know.

This seems fine to me; I think the TC as a body is happiest when
maintainers work things out collaboratively, using the NMU process
gently to help make the distribution better.

(Thanks for driving this; it's been a personal annoyance for years, just
not enough to get me to actually work on it)

-- 
-keith


signature.asc
Description: PGP signature

Bug#878324: directfb: Linux-specific libraries like *_fbdev.so are not included in libdirectfb-bin arm builds

[Keith Kyzivat]

Source: directfb
Version: 1.2.10.0-8
Severity: important
Tags: patch

Dear Maintainer,

When installing the Debian Stretch directfb package on an embedded
armhf platform that has no X-Windows, I encountered both my
application, and the dfbinfo application failing because it failed to 
find the systems/libdirectfb_fbdev.so systems library, and was instead
falling back and attempting to load the X11 systems library. This
failed because I do not have (nor desire to have) X11 configured on
this system.

So, in short, the problem is that
/usr/lib/arm-linux-gnueabihf/directfb-1.2.9/systems/libdirectfb_fbdev.so
is not installed, and thus using DirectFB with a framebuffer does not function,
despite the support being built into DirectFB.

I expect that 
/usr/lib/arm-linux-gnueabihf/directfb-1.2.9/systems/libdirectfb_fbdev.so
should be installed.

I investigated, and found sid's version of the directfb package
includes systems/libdirectfb_fbdev.so - and found the commit that
fixed the issue there - this is essentially a backport of that fix:
https://anonscm.debian.org/cgit/pkg-multimedia/directfb.git/commit/debian/libdirectfb-1.7-7.install?h=debian/1.7.7-6=d8c1e58e5e9ec745781f50d4f7b1ce2cc19c

I dug around the commits from the directfb Stretch release and found
related commits that introduced the breakage (fixing non-linux installs):
https://anonscm.debian.org/cgit/pkg-multimedia/directfb.git/commit/?h=debian/1.2.10.0-8=699a54bed0cceb20b70a8e674493e110e13b9949
https://anonscm.debian.org/cgit/pkg-multimedia/directfb.git/diff/debian/libdirectfb-1.2-9.install?h=debian/1.2.10.0-8=c99b82a0575a1e8af7c6b4d32520eee90ae03ade

The fix for this is to modify the lines in the installation file
debian/libdirectfb-1.2-9.install changing the '[linux]' prefixed lines
to '[linux-any]'. This directs the build tools to package the matching
files when building for any Linux platforms. I'm not sure what [linux]
without the -any part actually means.

I have a patch file I have tested that fixes this.


-- System Information:
Debian Release: 9.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.4.0-xilinx-dirty (SMP w/1 CPU core; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru directfb-1.2.10.0/debian/changelog directfb-1.2.10.0/debian/changelog
--- directfb-1.2.10.0/debian/changelog  2017-01-01 07:58:58.0 -0500
+++ directfb-1.2.10.0/debian/changelog  2017-10-12 13:50:41.0 -0500
@@ -1,3 +1,10 @@
+directfb (1.2.10.0-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install linux specific files for any linux builds [linux-any]
+
+ -- Sebastian Ramacher   Thu, 12 Oct 2017 13:50:41 -0500
+
 directfb (1.2.10.0-8) unstable; urgency=medium
 
   * debian/*.install: Also install davinci_c64x on armhf.
diff -Nru directfb-1.2.10.0/debian/libdirectfb-1.2-9.install 
directfb-1.2.10.0/debian/libdirectfb-1.2-9.install
--- directfb-1.2.10.0/debian/libdirectfb-1.2-9.install  2017-01-01 
07:54:27.0 -0500
+++ directfb-1.2.10.0/debian/libdirectfb-1.2-9.install  2017-10-12 
13:50:41.0 -0500
@@ -1,13 +1,13 @@
 #! /usr/bin/dh-exec
-[linux] usr/lib/*/directfb-*/*drivers/*.so
+[linux-any] usr/lib/*/directfb-*/*drivers/*.so
 usr/lib/*/directfb-*/interfaces/IDirectFBFont/libidirectfbfont_default.so
 usr/lib/*/directfb-*/interfaces/IDirectFBFont/libidirectfbfont_dgiff.so
 
usr/lib/*/directfb-*/interfaces/IDirectFBImageProvider/libidirectfbimageprovider_dfiff.so
 
usr/lib/*/directfb-*/interfaces/IDirectFBImageProvider/libidirectfbimageprovider_gif.so
 
usr/lib/*/directfb-*/interfaces/IDirectFBVideoProvider/libidirectfbvideoprovider_gif.so
-[linux] 
usr/lib/*/directfb-*/interfaces/IDirectFBVideoProvider/libidirectfbvideoprovider_v4l.so
+[linux-any] 
usr/lib/*/directfb-*/interfaces/IDirectFBVideoProvider/libidirectfbvideoprovider_v4l.so
 usr/lib/*/directfb-*/systems/libdirectfb_devmem.so
-[linux] usr/lib/*/directfb-*/systems/libdirectfb_fbdev.so
+[linux-any] usr/lib/*/directfb-*/systems/libdirectfb_fbdev.so
 usr/lib/*/directfb-*/wm/libdirectfbwm_default.so
 usr/lib/*/directfb-*/wm/libdirectfbwm_unique.so
 usr/lib/*/libdirectfb-*.so.*

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Sam Hartman <hartm...@debian.org> writes:

> Have I got that right?

Yes, I think you have summarized the issue accurately.

> However, for Debian and for the Technical committee, we need to consider
> what experience we want to give all our users and as a result value
> damage caused by false positives more highly than the upstream project
> might.

This does seem reasonable, but I haven't seen a concrete technical
proposal that would meet this goal.

Ian suggests asking the user, which seems like a fine goal, but I don't
think there's any plan for how to make this work in practice?

I made a suggestion (without my TC hat on) to not install modemmanager
by default. This is obviously easy to implement, however it also clearly
breaks the user experience for anyone who needs to use a modem to
download additional packages (e.g. modemmanager).

What I'd love to see is a patch that makes modemmanger behave better for
our users while remaining installed and operational. If it's useful
enough, it should be acceptable upstream as Debian is not the only
community affected by this particular problem.

(If only the USB standard had a class definition for 'serial device' that
was separate from 'modem device'.)

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> This has gone far enough.  I would like to remind you of Constitution
> 6.3(5)

Here's what I prefaced my first remark with:

 (speaking as a Debian user, not as a TC member)

Perhaps I should have added this to each message I sent?

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> But I should be able to use the same laptop to (1) control my machine
> tools or talk to my rpi or whatever (2) go online with a usb mobile
> modem when I'm out of the house.  Possibly even simultaneously.

That requires fixing the package instead of just getting it out of the
way, a significantly harder thing to manage.

I'm not saying your wrong. The simpler fix would make things better for
some people (those who use no USB modems, but do use other USB serial
devices), worse for others (those who use USB modems but not other USB
serial devices), and the same for a few (those who use both). The
question is whether the simpler fix would be a net positive for Debian
users, or a net negative.

Obviously, a "real" fix that asked the user whether a particular
device was actually a modem would be best for the third class of
people.

Of course, the simpler fix has the side effect of not installing
software or running I don't ever need and which serves only to annoy me.
So, for me, the simpler fix is even better...

> And, people shouldn't have to install support software to get their
> internet to work.

It's all a question of what support we install by default; there are
certainly plenty of network configurations which are not supported in a
default install. Are modems still common enough that supporting them by
default is worth the cost of wasting space and power on the remaining
machines which will never use one?

If it were just software that got installed and sat idle, I'd complain a
lot less. As it is, modemmanager does "stuff" by default, even if I
haven't asked it to. Software which runs on every machine by default
should be held to a higher standard than software which users explicitly
request. So, if we didn't install it by default, I'd be happy for it to
continue to suck.

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> Also, AIUI modemmanager contains code to do things with the new-style
> MBIM dongles (which can also be done with the cli tools in
> mbim-utils).  But I definitely wouldn't suggest disabling its ability
> to work with AT-command modems, as they are still being sold.[1]

Yeah, I was just thinking that it would be easier to stop installing
support for modems by default than to actually fix modemmanager to
behave itself. It's certainly how I work -- apt remove modemmanager
solves a world of problems for me.

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

(speaking as a Debian user, not as a TC member)

> I'm afraid don't really want to do the work of writing a better UI.
> But I have provided a simple patch which at least makes the behaviour
> safe.

Would it be sufficient to simply stop installing this largely-useless
package at this point? In what environments do users typically have
modems which work with AT-style commands?

It would be far safer to not install this package than try to hack it up
to keep it from breaking systems. Simply removing it from 'depends' on
the handful of packages which currently list it would 'fix' this problem
with a minimum of fuss.

-- 
-keith


signature.asc
Description: PGP signature

Bug#870202: mosh-server failing to start with a missing symbol

[Keith Winstein]

Thank you for this report. Is it possible you have a different version of
libprotobuf in your LD_LIBRARY_PATH, or a different version of mosh-server
in your PATH?

(Do you have anything related to libprotobuf in /usr/local ?)

On Sun, Jul 30, 2017 at 2:40 PM, Ivan Vucica  wrote:

> Package: mosh
> Version: 1.2.6-1+b2
> Severity: important
>
> Dear Maintainer,
>
> Yesterday I updated almost all of my system to stretch / stable.
> (Stragglers
> include things like php which might break some of my projects.)
>
> Today I am no longer able to connect to my server with mosh. Running
> mosh-server manually results in:
>
>   mosh-server: symbol lookup error: mosh-server: undefined symbol: _
> ZNK6google8protobuf11MessageLite25InitializationErrorStringB5cxx11Ev
>
> Perhaps there is some incompatibility with libprotobuf?
>
> Could we please patch stretch / stable?
>
> -- System Information:
> Debian Release: 9.1
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=en_US:en
> (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mosh depends on:
> ii  dpkg1.18.24
> ii  libc6   2.24-11+deb9u1
> ii  libgcc1 1:6.3.0-18
> ii  libprotobuf10   3.0.0-9
> ii  libssl1.1   1.1.0f-3
> ii  libstdc++6  6.3.0-18
> ii  libtinfo5   6.0+20161126-1
> ii  libutempter01.1.6-3
> ii  openssh-client  1:7.4p1-10+deb9u1
> ii  zlib1g  1:1.2.8.dfsg-5
>
> Versions of packages mosh recommends:
> ii  perl-base [libio-socket-ip-perl]  5.24.1-3+deb9u1
>
> mosh suggests no packages.
>
> -- no debconf information
>

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Keith Packard]

Tollef Fog Heen <tfh...@debian.org> writes:

> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

I vote R > F

-- 
-keith


signature.asc
Description: PGP signature

Bug#865485: Voting for TC Chair

[Keith Packard]

Didier 'OdyX' Raboud <o...@debian.org> writes:

> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A: Keith Packard 
> B: Didier Raboud 
> C: Tollef Fog Heen 
> D: Sam Hartman 
> E: Phil Hands 
> F: Margarita Manterola 
> G: David Bremner 
> H: Niko Tyni 
> ===END===

I vote:

B > A = C = D = E = F = G > H

-- 
-keith


signature.asc
Description: PGP signature