Bug#1057080: ibus-mozc: Automatically enables itself on non-Japanese systems

[Will Thompson]

On Sat, 22 Jun 2024 at 09:16, Osamu Aoki  wrote:

> For now, Endless OS should create its customization package which used
> dpkg-divert to disable ibus-mozc's autostart script and provides its own
> per-user input method setting script (or use gnome-initial-setup?).
>

Thanks for the dpkg-divert suggestion. Currently we patch this package to
remove this problematic autostart file but we could avoid that with
dpkg-divert. GNOME Initial Setup is used at first boot to configure the
system language and input method.


> After all, the act of installing all the language support packages is a
> non-typical use case.
>

As noted in this thread, Debian live media does the same – I don't think
this is so non-typical!


> I do understand what ibus-mozc is doing may not be the best technical
> solution but is a reasonable **DE independent solution**.
>
> If you can come up with a new **DE independent** per-user IM setting
> package
>

I don't think such a thing is possible or desirable. Each DE already has
its own way to configure input methods per-user (and system-wide).

Limiting the auto-enabling behaviour to Japanese locales would be an
improvement but consider the case where the system has two different input
methods installed, both of which have this script. Which one should win?

– Will

>

Bug#1057080:

[Will Thompson]

I noticed today that the Live GNOME ISO for bookworm has the same
behaviour. The live user ends up with ibus-mozc as the default input
method, albeit defaulting to direct input of Latin characters, with us
english as the second input method.

This seems weird. None of the other ibus input methods included with the
live ISO have this behaviour.

Bug#1067680: [RFP]: floorp -- powerful firefox fork with more customization and features

[Justin Thompson]

Package: wnpp
Severity: wishlist
Information about package: Described as "A Browser build for keeping the
Open, Private and Sustainable Web alive. Based on Mozilla Firefox; "Floorp
is built on Firefox and was built in Japan and is a new browser with
excellent privacy & flexibility." Software is affilated only with Ablaze
organization.
Available from: https://github.com/Floorp-Projects/Floorp (Github and
official website both point Debian and derivative users to get the PPA. A
tarball is available on the Github Releases page as well)
License: Uses Mozilla Public License, v. 2.0. Further information about the
software's license can be seen on
https://github.com/Floorp-Projects/Floorp/blob/3ac256fb89a13234104fc5bf0fab31447c5973c3/toolkit/content/license.html

Bug#1064461: gnome-settings-daemon: Xft.dpi not set correctly for 4K monitor at 200% scale

[Daniel Thompson]

On Thu, Feb 29, 2024 at 10:25:19AM +, Daniel Thompson wrote:
> On Thu, Feb 22, 2024 at 04:11:18PM +, Simon McVittie wrote:
> > On Thu, 22 Feb 2024 at 14:21:38 +, Daniel Thompson wrote:
> > > I assume this is a version skew problem caused by gnome-settings-daemon
> > > updating to GNOME 46 before other components
> >
> > If you upgrade both gnome-settings-daemon and gsettings-desktop-schemas
> > to their versions from unstable, does that resolve this?
>
> It does... and given gnome-settings-daemon is no present in trixie
> the bug should not longer be present in any Debian version.

s/no/not/
s/not/no/

Oops... and Cc:ing -done.


Daniel.

Bug#1064461: gnome-settings-daemon: Xft.dpi not set correctly for 4K monitor at 200% scale

[Daniel Thompson]

On Thu, Feb 22, 2024 at 04:11:18PM +, Simon McVittie wrote:
> On Thu, 22 Feb 2024 at 14:21:38 +, Daniel Thompson wrote:
> > I assume this is a version skew problem caused by gnome-settings-daemon
> > updating to GNOME 46 before other components
>
> If you upgrade both gnome-settings-daemon and gsettings-desktop-schemas
> to their versions from unstable, does that resolve this?

It does... and given gnome-settings-daemon is no present in trixie
the bug should not longer be present in any Debian version.


Daniel.

Bug#1064461: gnome-settings-daemon: Xft.dpi not set correctly for 4K monitor at 200% scale

[Daniel Thompson]

Package: gnome-settings-daemon
Version: 46~beta-1
Severity: normal
X-Debbugs-Cc: debianb...@redfelineninja.org.uk

Dear Maintainer,

After a relatively routine `apt upgrade` on Debian Trixie I had problems with
all my X11 apps failing to scale correctly.

I'm running gnome-shell/wayland with a 4K monitor at 200% scale. Wayland apps
scale fine but X11 apps (chromium, gvim, etc) and their window decorations are
drawn at 100% scale instead. This appears to be a problem setting up the DPI
configuration for Xwayland.

A simple workaround for most apps is to manually set Xft.dpi:
~~~sh
echo Xft.dpi: 192 | xrdb -merge -
~~~

This will cause X11 application to scale themselves correctly but window
decorations and (some) mouse cursors remain at 100%. I'm not currently aware of
any workaround that will correctly handle the window decorations.

Why is this filed against gnome-settings-daemon?

I reviewed /var/log/apt/history.log carefully and gnome-settings-daemon was
pretty much teh only possibly culprit. I confirmed this by rolling back to
gnome-settings-daemon-45.1-1 and the problem is resolved (and is also why the
system info below shows 45.1-1).

I assume this is a version skew problem caused by gnome-settings-daemon
updating to GNOME 46 before other components and it is possible this problem
will self-correct as other components adopt GNOME 46. However I thought a bug
report would be useful to document the workaround (or rollback) needed for
Debian Trixie at present!


Daniel.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: amd64

Kernel: Linux 6.8.0-rc5-00074-gb84349d0e58e (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
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 gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  45.1-1
ii  gsettings-desktop-schemas 45.0-2
ii  libasound21.2.10-3
ii  libc6 2.37-15
ii  libcairo2 1.18.0-1+b1
ii  libcanberra-gtk3-00.30-11
ii  libcanberra0  0.30-11
ii  libcolord21.4.7-1
ii  libcups2  2.4.7-1+b1
ii  libfontconfig12.14.2-6+b1
ii  libgck-1-03.41.1-4
ii  libgcr-base-3-1   3.41.1-4
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3+b1
ii  libgeoclue-2-02.7.1-2
ii  libgeocode-glib-2-0   3.26.3-6+b1
ii  libglib2.0-0  2.78.4-1
ii  libgnome-desktop-3-20 44.0-2+b1
ii  libgtk-3-03.24.41-1
ii  libgudev-1.0-0238-3
ii  libgweather-4-0   4.4.0-1
ii  libmm-glib0   1.22.0-3
ii  libnm01.44.2-7
ii  libnotify40.8.3-1
ii  libp11-kit0   0.25.3-4
ii  libpam-systemd [logind]   255.3-2
ii  libpango-1.0-01.51.0+ds-4
ii  libpangocairo-1.0-0   1.51.0+ds-4
ii  libpolkit-gobject-1-0 124-1
ii  libpulse-mainloop-glib0   16.1+dfsg1-3
ii  libpulse0 16.1+dfsg1-3
ii  libspa-0.2-bluetooth  1.0.3-1
ii  libupower-glib3   1.90.2-8
ii  libwacom9 2.9.0-2
ii  libwayland-client01.22.0-2.1+b1
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8.1-1
ii  pipewire-audio1.0.3-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy   3.5-1+b1
ii  pipewire-audio 1.0.3-1
ii  pkexec 124-1
ii  x11-xserver-utils  7.7+10

Versions of packages gnome-settings-daemon suggests:
pn  usbguard  

-- debconf-show failed

Bug#1062654: openjdk-17-jre-headless: Segfault in jspawnhelper

[Will Thompson]

Package: openjdk-17-jre-headless
Version: 17.0.10+7-1~deb12u1
Severity: important

In 17.0.10+7-1~deb12u1 from bookworm-security, jspawnhelper segfaults 
on startup.


$ /usr/lib/jvm/java-17-openjdk-amd64/lib/jspawnhelper
Segmentation fault

In real applications, this manifests as a failure to spawn subprocesses.

With 17.0.9+9-1~deb12u1 from bookworm, jspawnhelper shows an 
informational message when run directly.


$ /usr/lib/jvm/java-17-openjdk-amd64/lib/jspawnhelper
This command is not for general use and should only be run as the 
result of a call to

ProcessBuilder.start() or Runtime.exec() in a java application


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

Kernel: Linux 6.1.0-17-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openjdk-17-jdk-headless depends on:
ii  libc62.36-9+deb12u4
ii  openjdk-17-jre-headless  17.0.10+7-1~deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

openjdk-17-jdk-headless recommends no packages.

Versions of packages openjdk-17-jdk-headless suggests:
pn  openjdk-17-demo
pn  openjdk-17-source  

Bug#1059530: mate-desktop: Pyside6 combobox inside a groupbox doesn't render selected option but does whilst window is resizing

[Peter Thompson]

Package: mate-desktop
Version: 1.26.2-1
Severity: important
X-Debbugs-Cc: theoneando...@gmx.us

Dear Maintainer,

Creating Qt GUI in python for a project and discovered the problem. 

Minimum python code below. I've tested in KDE and it works as expected.

Python 3.11

```
from PySide6.QtWidgets import QApplication, QFrame, QGroupBox, QComboBox, 
QWidget, QVBoxLayout
import sys

class MyWidget(QWidget):
def __init__(self):
super().__init__()

groupbox = QGroupBox(self)
groupbox_layout = QVBoxLayout(groupbox)

combo = QComboBox(groupbox)
combo.addItems(["Option 1", "Option 2", "Option 3"])
groupbox_layout.addWidget(combo)

layout = QVBoxLayout(self)
layout.addWidget(groupbox)

app = QApplication(sys.argv)
window = MyWidget()
window.show()
sys.exit(app.exec())
```

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

Kernel: Linux 6.6.8-amd64 (SMP w/8 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 mate-desktop depends on:
ii  hicolor-icon-theme0.17-2
ii  libc6 2.37-13
ii  libglib2.0-0  2.78.3-1
ii  libgtk-3-03.24.39-1
ii  libmate-desktop-2-17  1.26.2-1
ii  mate-desktop-common   1.26.2-1

Versions of packages mate-desktop recommends:
ii  mate-user-guide  1.26.2-1

Versions of packages mate-desktop suggests:
ii  mate-desktop-environment  1.26.0+1

-- no debconf information

Bug#1057080: ibus-mozc: Automatically enables itself on non-Japanese systems

[Will Thompson]

Package: ibus-mozc
Version: 2.28.4715.102+dfsg-2.2
Severity: normal

ibus-mozc contains an xdg autostart script for GNOME sessions which 
checks whether any ibus input methods are already configured for the 
user session and, if not, prepends the mozc-jp input method to the list.


From reading #983623 I believe the intention is to remove the need for 
manual setup after the package is installed. However, this also means 
that if the package happens to be installed on the system, the input 
method will be enabled even if the user has no interest in Japanese 
text input. I believe the xdg-autostart script is the wrong way to 
handle this. GNOME Initial Setup selects an appropriate input method 
for the configured locale. On Debian systems, for Japanese, this is 
ibus-mozc (if installed) or ibus-anthy (if mozc is not installed but 
anthy is). It is true that, if you install ibus-mozc after configuring 
your desktop session, it will not be enabled; but 
task-japanese-gnome-desktop recommends ibus-mozc so I would expect that 
mozc would typically be installed.


The current approach causes a particular problem on image-based 
systems. Endless OS is a Debian-based distribution which is distributed 
as an immutable snapshot, using libostree. End-users do not have the 
ability to add or remove Debian packages from the system. This means 
that we must bundle a reasonable input method for every language our 
users may wish to use. By including ibus-mozc in the immutable image, 
mozc gets automatically enabled on (for example) my UK English system. 
So at present we have to either patch the mozc package (the current 
approach) or remove support for Japanese text input from our OS. (We 
previously had the same problem with ibus-anthy, see #992753, but since 
gnome-desktop 43.2-2 switched to preferring mozc, we have followed this 
switch.)


Please consider removing the XDG autostart script in both packages.

Regards,

– Will

-- System Information:
Distributor ID:Endless
Description:Endless OS 5.2.0
Release:5.2.0
Codename:n/a
Architecture: x86_64

Kernel: Linux 6.5.0-10-generic (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages ibus-mozc depends on:
ii  ibus 1.5.27-5
ii  libabsl20220623  20220623.1-1
ii  libc62.36-9+deb12u3
ii  libgcc-s112.2.0-14
ii  libglib2.0-0 2.74.6-2
ii  libibus-1.0-51.5.27-5
ii  libprotobuf323.21.12-3
ii  libstdc++6   12.2.0-14
ii  libxcb-xfixes0   1.15-1
ii  libxcb1  1.15-1
ii  mozc-data2.28.4715.102+dfsg-2.2
ii  mozc-server  2.28.4715.102+dfsg-2.2

Versions of packages ibus-mozc recommends:
ii  mozc-utils-gui  2.28.4715.102+dfsg-2.2

ibus-mozc suggests no packages.

-- no debconf information

Bug#858039: lintian: Graph (SVG) files on https://lintian.debian.org/ lack tag name

[Brian Thompson]

I've submitted a PR to get this change in as proposed by Axel:

https://salsa.debian.org/lintian/lintian/-/merge_requests/455
-- 
Sincerely,

Brian


signature.asc
Description: This is a digitally signed message part


publickey - brianrobt@proton.me - 688c834d.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#1007922: false positive spelling: substract and subtract is both correct

[Brian Thompson]

I like the idea of keeping the spelling correction in place.  I've never seen 
"substract" being used.  Keeping the correction reduces ambiguity and keeps 
language consistent.

Motion to close.

Sincerely,

Brian

publickey - brianrobt@pm.me - 0xC8F2EC48.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#695188: 2017 patch review

[Brian Thompson]

Does anyone have time to review the patch that was submitted back in 2017?

2017 patch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=695188;filename=0001-Fix-695188-intelligent-add-of-Bug-XX.patch;msg=60

-- 
Brian Thompson 


signature.asc
Description: This is a digitally signed message part

Bug#1030151: vim-runtime: Undefined variable s:settings_no_doc when running :TOhtml (2html.vim)

[Daniel Thompson]

Package: vim-runtime
Version: 2:9.0.1000-4
Severity: normal
Tags: patch
X-Debbugs-Cc: debianb...@redfelineninja.org.uk

Dear Maintainer,

Running :TOhtml results in:
~~~
Error detected while processing function tohtml#Convert2HTML[11]..script
/usr/sh
are/vim/vim90/syntax/2html.vim:
line 1884:
E121: Undefined variable: s:settings_no_doc
~~~

This is due to a typo on 2html.vim which I was able to correct locally using
the following patch:
~~~
Index: vim/vim90/syntax/2html.vim
===
--- vim.orig/vim90/syntax/2html.vim
+++ vim/vim90/syntax/2html.vim
@@ -1881,7 +1881,7 @@ if s:settings.use_css && !s:settings.no_
   endif
 endif

-if !s:settings.use_css && !s:settings_no_doc
+if !s:settings.use_css && !s:settings.no_doc
   " For Netscape 4, set  attributes too, though, strictly speaking, it's
   " incorrect.
   execute '%s:]*\):\rhttps://github.com/vim/vim/commit/f1dcd14fc5d4370476cd82895a4479ca2d252e54#diff-0fd732992c6f1a9b27a162d1fbb5e849b7fa49965a8f83779e5bb4a57ac121be


Daniel.


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

Kernel: Linux 6.2.0-rc6-00129-g5d60edecd444 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim 2:9.0.1000-4
ii  vim-gtk3 [vim]  2:9.0.1000-4
ii  vim-tiny2:9.0.1000-4

vim-runtime suggests no packages.

-- no debconf information

Bug#979699: block 979699 with 979846

[Lance Thompson]

Date: Mon, 11 Jan 2021 18:03:12 -0500
>From: Olek Wojnar 
>-
>Body: ur-type{header

Bug#979699: block 979699 with 979846

[Lance Thompson]

Date: Mon, 11 Jan 2021 18:03:12 -0500
>From: Olek Wojnar 
>-
>Body: ur-type{header

Bug#1008587: installation-reports: dist-upgrade to sid works but autoremove takes out most of the Mate DE

[Mike Thompson]

Package: installation-reports
Severity: important
X-Debbugs-Cc: kneedragon1...@gmail.com

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: netinstall-virtualmachine
Image version: debian-11.3.0-amd64-netinst.iso
Date: 

Machine: i7-6700-non-k
Partitions: 


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

Initial boot:   [ ]
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:

https://www.debian.org/Bugs/Reporting.en.html
.. and I don't know that it is appropriate.
Allow me to explain.
I have a copy of Debian in a virtualbox, on a machine running Mint as the host.
I have converted to sid, so my sources.list looks like ~
--
deb http://ftp.us.debian.org/debian/ sid main
deb-src http://ftp.us.debian.org/debian/ sid main
---
~ I then go sudo apt dist-upgrade, and I get sid, and roughly 1 GB of left-over 
files, and apt encourages me to remove them by ~
sudo apt autoremove
~ all perfectly normal.
What happens next is I can't reboot, I get a TTY.
I can force a startx, but many of my Mate packages are gone.
So an effort to manually reinstall mate, results in a dependency error, the 
version of mate to be installed requires an earlier version of python and you 
can't install that...
I have made a clone of that install before I ran the autoremove and tried 
various fixes but so far I have been stumped.
As long as I don't run the autoremove I have a perfectly functional sid + Mate, 
but there's about a GB of stuff I should be able to autoremove, and I can't...

Sorry this doesn't comply with your format request, but in the circumstances, I 
think an effort to make it fit would simply confuse the problem.

Yours respectfully, Mike Thompson.
.>


Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u3"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC 
[Natoma] [8086:1237] (rev 02)
lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA 
[Natoma/Triton II] [8086:7000]
lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 
IDE [8086:7111] (rev 01)
lspci -knn: Kernel driver in use: ata_piix
lspci -knn: Kernel modules: ata_piix, ata_generic
lspci -knn: 00:02.0 VGA compatible controller [0300]: InnoTek Systemberatung 
GmbH VirtualBox Graphics Adapter [80ee:beef]
lspci -knn: Subsystem: VMware Device [15ad:0405]
lspci -knn: 00:03.0 Ethernet controller [0200]: Intel Corporation 82540EM 
Gigabit Ethernet Controller [8086:100e] (rev 02)
lspci -knn: Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter 
[8086:001e]
lspci -knn: Kernel driver in use: e1000
lspci -knn: Kernel modules: e1000
lspci -knn: 00:04.0 System peripheral [0880]: InnoTek Systemberatung GmbH 
VirtualBox Guest Service [80ee:cafe]
lspci -knn: 00:05.0 Multimedia audio controller [0401]: Intel Corporation 
82801AA AC'97 Audio Controller [8086:2415] (rev 01)
lspci -knn: Subsystem: Dell Device [1028:0177]
lspci -knn: Kernel driver in use: snd_intel8x0
lspci -knn: Kernel modules: snd_intel8x0
lspci -knn: 00:06.0 USB controller [0c03]: Apple Inc. KeyLargo/Intrepid USB 
[106b:003f]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: Kernel modules: ohci_pci
lspci -knn: 00:07.0 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI 
[8086:7113] (rev 08)
lspci -knn: 00:0d.0 SATA controller [0106]: Intel Corporation 82801HM/HEM 
(ICH8M/ICH8M-E) SATA Controller [AHCI mode] [8086:2829] (rev 02)
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
usb-list: 
usb-list: Bus 01 Device 01: OHCI PCI host controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.10.0-13-amd64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 02: USB Tablet [80ee:0021]
usb-list:Level 01 P

Bug#998846: gnome-remote-desktop: crashes if fusermount3 is not installed

[Will Thompson]

Package: gnome-remote-desktop
Version: 41.0-1
Severity: normal

When I attempt to connect to gnome-remote-desktop over RDP on a system
which has 'fuse' not 'fuse3' installed, it crashes. The journal output
ends with:

fuse: failed to exec fusermount3: No such file or directory
[FUSE Clipboard] Failed to mount FUSE filesystem

Inspecting the source[0] shows that fuse_session_mount() failing
triggers a call to g_error(), which aborts the process, with the second
message above.

I am not familiar enough with the details of fuse to be sure, but
gnome-remote-desktop links to libfuse3-3, and I infer that libfuse3-3
must assume that fusermount3 (from 'fuse3', not fusermount from 'fuse')
is installed. Perhaps the gnome-remote-desktop package should depend on
'fuse3'.

[0] 
https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/blob/f895c2b28b3341af54cb2ce24ce76af8f3e1513d/src/grd-rdp-fuse-clipboard.c#L1319-1321

(I am reporting this bug not from the WSL2 container I was trying to run
this in, but from another machine. Please forgive me for not configuring
reportbug in WSL2.)

Bug#995777: podman: Cannot (effectively) use containers with glibc 2.33.9000 or newer

[Will Thompson]

Yes, after installing podman_3.0.1+dfsg1-4_amd64.deb and
golang-github-containers-common_0.33.4+ds1-2_all.deb from that page, the
Fedora 35 examples work as expected.

– Will


On Sat, 9 Oct 2021 at 23:14, Reinhard Tartler  wrote:

> Control: fixed -1 3.3.1+ds2-1
> Control: tags -1 bullseye
>
> Thank you for your bugreport.
>
> On Tue, Oct 5, 2021 at 10:51 AM Will Thompson  wrote:
>
>> Package: podman
>> Version: 3.0.1+dfsg1-3+b2
>> Severity: important
>>
>> podman embeds a default seccomp policy, which based on my research is
>> identical to that used by docker. The policy embedded in the bullseye
>> version of podman is buggy when used to run a container whose glibc is
>> 2.33.9000 or newer, due to that version's use of the clone3 syscall. The
>> lengthy commit message at
>>
>> https://github.com/moby/moby/commit/9f6b562dd12ef7b1f9e2f8e6f2ab6477790a6594
>> explains the issue in considerable detail.
>>
>
> I believe this should be fixed with the changes I'm prepareing in the
> context of #994451
>
> Would you mind trying the packages at
> https://people.debian.org/~siretart/bug.994451/ and let me know if they
> fix this issue as well? I'm fairly confident that it does.
>
> Thank you.
>
>
> --
> regards,
> Reinhard
>

Bug#995777: podman: Cannot (effectively) use containers with glibc 2.33.9000 or newer

[Will Thompson]

Package: podman
Version: 3.0.1+dfsg1-3+b2
Severity: important

podman embeds a default seccomp policy, which based on my research is
identical to that used by docker. The policy embedded in the bullseye
version of podman is buggy when used to run a container whose glibc is
2.33.9000 or newer, due to that version's use of the clone3 syscall. The
lengthy commit message at
https://github.com/moby/moby/commit/9f6b562dd12ef7b1f9e2f8e6f2ab6477790a6594
explains the issue in considerable detail.

As a result, processes in such containers cannot spawn new threads, and
are practically unusable:

$ podman run --rm -it registry.fedoraproject.org/fedora:35 curl 
http://example.com
curl: (6) getaddrinfo() thread failed to start
$ podman run --rm -it registry.fedoraproject.org/fedora:35 dnf update
Errors during downloading metadata for repository 'fedora':
  - Curl error (6): Couldn't resolve host name for 
https://mirrors.fedoraproject.org/metalink?repo=fedora-35=x86_64 
[getaddrinfo() thread failed to start]
Error: Failed to download metadata for repo 'fedora': Cannot prepare 
internal mirrorlist: Curl error (6): Couldn't resolve host name for 
https://mirrors.fedoraproject.org/metalink?repo=fedora-35=x86_64 
[getaddrinfo() thread failed to start]

(I am just using Fedora 35 as an example. Over the lifetime of Bullseye
we can expect other distributions to adopt newer glibc, too.)

While it is possible to work around this issue by supplying a newer
policy to podman with:

$ podman run --security-opt seccomp=/path/to/default.json ...

and this issue is probably fixed in bookworm's podman, it may be worth
considering updating the built-in policy in bullseye's podman.

NB. I'm reporting this bug from Endless OS, which is (nowadays) built
directly against the Bullseye repos, with a handful of packages overlaid
from our own repos. But podman and related packages are all drawn
directly from Bullseye, and I have reproduced this issue in a vanilla
Bullseye VM too.

-- System Information:
Distributor ID: Endless
Description:Endless 5.0.0
Release:5.0.0
Codename:   bullseye
Architecture: x86_64

Kernel: Linux 5.11.0-35-generic (SMP w/8 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: unable to detect

Versions of packages podman depends on:
ii  conmon   2.0.25+ds1-1.1
ii  containernetworking-plugins  0.9.0-1+b6
ii  crun 0.17+dfsg-1
ii  golang-github-containers-common  0.33.4+ds1-1
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-13
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libgpgme11   1.14.0-1+b2
ii  libseccomp2  2.5.1-1

Versions of packages podman recommends:
ii  buildah   1.19.6+dfsg1-1+b6
ii  catatonit 0.1.5-2
ii  fuse-overlayfs1.4.0-1
ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b7
ii  slirp4netns   1.0.1-2
ii  uidmap1:4.8.1-1

Versions of packages podman suggests:
pn  containers-storage  
pn  docker-compose  

-- no debconf information

Bug#993690: goban-ss: Goban-ss binary in incorrect location

[Bill Thompson]

Package: goban-ss
Version: 1.1-6
Severity: important
Tags: a11y

Dear Maintainer,

On a new installation of Debian 11, the goban-ss package installs the binary 
file for the screensaver into the directory /usr/lib/xscreensaver/goban. The 
xscreensaver package sets the default directory for binaries as 
/usr/libexec/xscreensaver/goban. When the goban-ss package in installed the 
xscreensaver progam show the module as "Not Installed". I was able to correct 
this by creating a simlink to put the goban-ss binary in the correct location 
(sudo ln -s /usr/lib/xscreensaver/goban /usr/libexec/xscreensaver/goban).


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
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 goban-ss depends on:
ii  libc6 2.31-13
ii  libx11-6  2:1.7.2-1

Versions of packages goban-ss recommends:
ii  goban-original-games  1.1-6
ii  xscreensaver  5.45+dfsg1-2

goban-ss suggests no packages.

-- no debconf information

Bug#951374: RFP: gh -- the GitHub CLI

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2021-08-16 at 21:27 -0600, Anthony Fok wrote:
>  NEW queueOn Sun, Aug 15, 2021 at 10:45 PM Brian Thompson
>  wrote:
> > 
> > Since there is already a package that uses that binary name, who should
> > change it? Do we follow a first-come first-serve binary name reservation
> > strategy? I don't think it's a big deal to change the name.
> > 
> > I'm not sure what to rename it to. I don't like binaries with long,
> > descriptive names, but I don't know what we could use that is short. I
> > will raise awareness about this issue with the upstream developers.
> 
> Hi Brian,
> 
> First of all, thank you for volunteering to help with the packaging of
> GitHub CLI.
> 

Anthony,

Thank you for being intimate with the details. 

> Here is my understanding:
> 
> Now, you might run into a problem when actually trying to name the
> package "github-cli" (or even "gh") because dh-make-golang 0.4.0 does
> not allow for overriding the package name.  For example:
> 
> dh-make-golang -type p -pristine-tar github.com/cli/cli
> 
> would name the package "cli"... I am working on packaging the latest
> dh-make-golang and will try to add a flag to allow overriding the
> package name, to be uploaded as dh-make-golang 0.4.1 or 0.5.0.

It sounds like this functionality is required for what we are trying to achieve.
I am not very familiar with the golang family and its surrounding infrastructure
regarding Debian. Perhaps I am not best-equipped to package the github-cli tool,
but I am always willing to learn.

> Then there are the yet-to-be-packaged dependencies.  Just so that you
> know, the following packages that github-cli depends on have already
> been packaged but currently sitting in the
> https://ftp-master.debian.org/new.html NEW queue:
> 
>  * golang-github-yuin-goldmark-emoji 1.0.1-1
>  * golang-github-muesli-reflow 0.3.0-1
>  * golang-github-shurcool-graphql 0.0~git20200928.18c5c31-1
>  * golang-github-shurcool-githubv4 0.0~git20210725.83ba7b4-1
> 
> I'll report back here if I were to package and upload more of these
> dependencies so as to avoid duplication of work.
> 

It sounds like we should pause the github-cli technical packaging work until
dependent features and packages are added to the ecosystem. Would you agree with
that? I'm not seeing any BTS tags specific to RFPs (or bugs in general) for
marking it as "blocked", as we would say in the corporate world. Although I am
not sure that is even necessary.
- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEbQYcTHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfaNpEACgqGGp/BsUjnGpALGzNbMtqY2P4b3d
EqhxUmQdEzDPKw7g4ajyYkFiDm9Djgvz2g3R6jgYcjuOlcjeI3YOZNtJMmriUw7p
CM4jgaaXn/YvKFQxqNWD7GTsWlJnej4mCmebiRTseG3MX8BEHb4Ukndiy3pR2vXx
nhHVq+JJZsti8goTcROgToG8a0lH+rUj8yc0uN/e2JQcLCHOjXZdgUDQQzUVW+3C
iVMJ1tp88vrTpXn04TxMdHIyGbWh8SMFv9Q3+F4HyWBc9UiYq4kmOw1US/0YL8PQ
rwiGXzNxS6BoYZ9W0EtRwy27asBJDpfRsGOFzqzVK+fSGk7teThL3sS8SoxR1XjQ
Z7sebgTsY+A0b8+YYR8UOZb1Ei616cmD/m2bKntHQHzTMQw1rmWJgKxeoh9ARv91
b1PUbZndsSDbOukj+nt+gD+NayAwJDceTYZ3hm5FnE4tADPWCkeSixQVBafNM1i5
ZY02qCqtP0Z37lRsAOj53jTweOmSm4Fv5sJG/FtqHEAnd/fNd17KT5ggii6uPEhD
vdyBdtlB5K8ZboT7f2HtHuoOkAHcLPKU6rq0kAI+43Dt0nw4XTSWoB3AH2dNW4ii
wKqxgOKo4j+mxc6TZckn4xNbRXrB1dGEwu7/HuRg//+EsdqNW0PWNEqpNxIRNHgz
NhR8XUSX3KW71Q==
=Bui2
-END PGP SIGNATURE-

Bug#754831: [apt-listchanges] Program Crashes On Konsole Sessions

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Which pager are you using, or does this occur for all pagers in KDE
Konsole?

- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEZ7d8THGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfeUwD/9VG1VdWeT/oW07i3R5HLYddBX34Igk
9YbB9IzXNt+RqG1IR1Qz6ZtJkwokykknO+GOEOIqIfjiVn8Y0DO1FQhqxG1K/z5z
XKCuX/+A8HD751Syhf+wa+2TuVY6zaNsO+8HAK4vOyMWrUN9UTP9YNEEYvv1YF89
EjlCVrWvqaiAlbVae6h78Wmm37cfcTgSb1daGNQEdh/VNKgqWJ2X8zOW7kFsG1ch
WSjvj2Ysd1+w70fPCQug+C670JYamILGEAOyrwogBqwqXXGvCGY9ofjTGsz09ayh
Q5IHEi1BdakcMwMdMKeHsxNKFMMEcvKLV5YMp2RF+o+E8PrK5ZmFTkGIs1H0N4qX
Cf9LQ4qFDIhlh1j0UL6wBgZOnZt2V+8Nolau4wJZxhP2m4UAHTWM61d53qP/y7Dk
ONiMMiP4d6Bn4DEVpRbcv1XMw6Dre2Pn0fMEZFee1HkPs7dCBIext1DYaQ5aP4iF
jn5zqszXOGimuacDdAXOwQK270hdcM7W3u4JK12VWtxAXJmeMoELkZmG+OTcsxWD
FxfzGPEGmU1wPvoS4ou2tgCaxELcEXZGJHWvkpSRjOWLIlIDyeHbywHK/1s8cdAL
2AZvIuWyXuc5akUbMyXueMjMQ5yLJE/RA7lcMo7wB+LDEDmysjWZpOaRFF2LSHtM
drFWZhcF+8hH2A==
=lejN
-END PGP SIGNATURE-

Bug#951374: RFP: gh -- the GitHub CLI

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 14 Aug 2021 14:18:34 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= <
anar...@orangeseeds.org> wrote:
> 
> It's not on the package name, but there's already a clash on the
binary
> name, which we should be mindful of:
>  gitsome provides direct integration with GitHub and GitHub Enterprise
in
>  a terminal.
> 
> Since it's a git (and github, even!) related tool, we might even want
to
> Conflict with it directly...

Since there is already a package that uses that binary name, who should
change it? Do we follow a first-come first-serve binary name reservation
strategy? I don't think it's a big deal to change the name.

I'm not sure what to rename it to. I don't like binaries with long,
descriptive names, but I don't know what we could use that is short. I
will raise awareness about this issue with the upstream developers.
- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEZ7NQTHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfeX5EAChFZ4pCKTj1uvCuyAxCzr12dfdfIqC
U27Bc1UwT5DAKs9T2EjihTkhstinwN3ZKLmOOznH1+lnmbdlXccYRtV4BZvu3diD
iyzP4t+5voLnxViYzO8WjHcxSlA7qNUY1/16nmOuTvrNmpaxS/54gjOyFXjdOWVc
CGCHUm2TG3aMTaW+OfOizBG+T+ThNNrkRg/8cKStgcR2vB8gwa/gJdT4qccsLCHv
ufrxVg3p7VzjVvBD7W4Z5uczqwnYR7/3FK3M65FH1TKZTCxDIv3BYGKIIEM0nXnJ
sLzFCucItVVi/Cc7CJf/sH9T49BzVfL+GTGFbDhue70+NpfOa++z7p22qq211Zvd
5E2vRXSLpQVmMY8QZy8+xDgBvi1CP1hBx98XbSE1RquV902naHowsFxTa4nkAPiK
nYU81R8TbLGwdPUXO/SgnSLQ9IlA7IotwfXmEhPAge8rYIR+2TtE0Da6ROeT8Tj4
lDiH9p6RS78Y49wihatMkpxKNkypQdUwq5AZb8p3b2j/h7hFz6l9m0TcAxxkggjZ
HPFDt0n0hGr6KzAtemFMP04OyqurMVCEtwn84ySmUI3Sy9i42uT36c2M7+TOd2iu
C2R/kXr7ZJ9fWxwpAkyv4/4rPqu2AwSeCluzUPRLTxR/8zqlTIwGK3tDlNQH3bQD
aTB5+YZvyIHIeg==
=YHqO
-END PGP SIGNATURE-

Bug#514865: apt-listchanges: GTK+ window should not steal focus, and only appear if there is anything to show

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 11 Feb 2009 11:11:57 -0200 Gustavo Noronha Silva  wrote:
> Package: apt-listchanges
> Version: 2.83
> Severity: important
> 
> The GTK+ frontend has a very bad behavior: it will display a window
> and quickly close it if there is nothing to show. When the window is
> displayed (either because it has stuff to show or not), the window
> simply pops up in front of anything you are doing.
> 
> It should instead show in the background requesting attention (so that
> its taskbar button will pulse no matter in what virtual desktop you
> are). And should, of course, only display the window if there is
> something to show.
> 

There have been a lot of changes to apt-listchanges since 2009. Can you
confirm if this is still an issue for you?

- --
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEYUUATHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfTzVD/9oIRRiWVy7OtLrrj4i4GmYH/4HHf03
ncC/j1U2TxFYmWVpuP4AW1Ifv8tKsGormHOOJNVAhzkiDSvPdaWE0xZbHHNllAyx
k8XHmzF24xkyOm42k+j7v7xB6VUM8WPBDZQhfyRIPG/lBnsVLyW0+2JtlwaJuH2e
YNnEOGMVasK9LyZKQytCl2OEbFx7KJdbzShxwv6iELJ/uAxJdhpoeuRKMSBQ4aG4
u6/aRXPgSNlZ2jfwbuFVqYhakjrq0sCVPNu2joIQCwPHtY6Bw7JaHR9A15MWxKtJ
pC6T9Xrs1mLF4rSGaBpj2E1nYo1jWyUwTbm0cJv+B0YnCBs0OAwsIagjYNO87YRK
SocnBT7BrfnoO24gdFkdBkgWLGLcFMPYsjr7CUmmGWi69d+3U/8mp/KSXrh5L0u8
+RIvcqn8N6GvReJ6PudMaPCS/QavbaI/ljGOkJ66yspU7Si10UkfQCw8whir0GLm
U8bl/JI+94poMdCs4J2mMaaITpfISIr7T9WiJMbIhucEyKyS04opKjvGD6jPaKcr
MsQsHZeeUHmfViH02Ds3Aor9MLaEHEQpdppM5wfy3xw8fRq7FWEZQIYb6gaGvFLX
h315bJptP+Zc0IkKe6N2cEyMFZnDZylmcxUbW37buX0XgV/ycEWV7BzjWwNRbb4s
yOVj2Wa3SpszFQ==
=0HIg
-END PGP SIGNATURE-

Bug#951374: RFP: gh -- the GitHub CLI

[Brian Thompson]

On 0814, Paul Wise wrote:
>
>Could also add a Provides: gh so it is installable with the short name.
>
>I would definitely like to have this in Debian, but can't help with it.
>

This would be ideal. Is there any benefit of renaming the package to
something other than "gh"?  I can help with this during the next week.

-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#111013: apt-listchanges fixes

[Brian Thompson]

On Mon, 12 Nov 2001 22:34:27 -0500 Matt Zimmerman  wrote:
> I must have completely overlooked the documentation fixes in your bug
> report; I thought you were just adding documentation for the option you
> added in your patch.  I've applied them in CVS now, thanks.
> 
> -- 
>  - mdz
> 
> 

Bug#111013: apt-listchanges fixes

[Brian Thompson]

On Mon, 12 Nov 2001 22:34:27 -0500 Matt Zimmerman  wrote:
> I must have completely overlooked the documentation fixes in your bug
> report; I thought you were just adding documentation for the option you
> added in your patch.  I've applied them in CVS now, thanks.
> 
> -- 
>  - mdz
> 
> 

Bug#111013: Cannot reproduce

[Brian Thompson]

I am unable to reproduce the fix that was mentioned in this bug.  I
tried with less and running `export LESS="-r $LESS" and
`export LESS="-R $LESS"`.

Marking as unreproducible for now.
-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#76500: Tagging as wontfix

[Brian Thompson]

There's two separate wishlist items in this bug, split them up into two
separate bugs if you still want this (or anyone for that matter) so that
each one is easier to track.  I'm keeping this bug open for the original
request.

I'm going to tag this as wontfix for now.
-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#434986: Tagging wontfix

[Brian Thompson]

Since this OP has found another apt cron package to serve his needs,
I've tagged this bug as wontfix.
-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#951374: RFP: gh -- the GitHub CLI

[Brian Thompson]

> I personally find that "gh" is quite short name for a package that
> will go into a general purpose software catalog like Debian repository. Would
> you mind choosing something like "github-cli" as source and binary
> package name and mentioning the sortcut "gh" in a package description?
> So anyone could find the program by means of `apt-cache search`.
> Acronyms gh and gn (which stands for Google's Generate Ninja) are
> visually similar, and I'm afraid they are easily confused.
>
> What do you make of this proposal?

I like that proposal and think it makes a lot of sense. `gh` does seem
too short, and while easy to identify for current gh users, maybe it
will be more difficult to find in apt for new users. Also, as you
mentioned, a namespace clash in the future seems like an uncommon
occurence.
-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#802370: ITA: docbook-xsl

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

retitle -1 ITA: docbook-xsl -- stylesheets for processing DocBook XML
- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEPClETHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2Gfd7RD/9qIBu3K1iq1mjZ5YibRc85HonHrOJb
UlHlQ7dRHPlFjYvbXsYKVZpdzQTtz3LkZvgFvldFC0LxYtWBNQzxn4X3SgGbNNRB
b/P0cMRCgHCV0EG6B6q0NhM05+t0sPyscnu4VbjwlHlEFNrr3OP0uJJh/MbSjuST
1MG1k10Ihu+B6dOFK4Mq5Fl6LqNgUoSqXcKOib72W8vgXxkwKWmoBvbc0qRGMgGn
vYcMnwaISsHLIfwmFNQaQ+0HVhX3sTrvI1273K5fdi9hAjd/nA5i74UigQwpvb1l
gvzOjfFykK7E0aKtsEGdC3NHLd9lm17JP50iJYAZZz+JH79sj+M0TCORo8SG/lOv
6p3gRrzgX5RAZPDWXDBdJwE8rNDZQCeYIBSnsui9SpyRsjH/7dasSU1aoSigOB+U
oJcof1Q4hbXA4Viam0DHvm1EzIF97R5ZBFgGPQFnD9qpRk4pckMGD0/tnBDHcCAZ
u9oSNQCmCZ02gLSW4CiYbQ+LiGWWw6LEUoPRjhK188KqjTm6A1sPs7cK1Ibe9r/z
giT6tCVa3LTyFG0hO/FMiq73owLVzOJ9UwWzq7+NRceCQIENkZkNmQ9g2Lf6Fol2
Ul2jQDjJ755MrhspW9zO1crLsjs14meKWAAExleYmmOnpSK2cB6wSjS/VTrwdZAO
KgX+FOqMhwK9FA==
=lfHp
-END PGP SIGNATURE-

Bug#802368: ITA: docbook-xml

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

retitle -1 ITA: docbook-xml -- standard XML documentation system

- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEPCekTHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2Gfe8VEACrpLu2smZo7oiQs2uhRyDAzj+iaScg
9C3kmOcnit9VVhuPD+VXi8+nkL5lsRvmgHuLuI9aKfHXRVgie/yswrpZIQsUA/v/
kLLcEcCUCnEfQs15fru56TT3zby2Yyzrcpy7f16aVo8urZcu6izwgJDyawzrEz/L
CpX1oFa2dIJVO1kJX72z1QGCLnQkXuy+MyvmM3wvRfNcH5DSU3PYKOqGAKT5zStz
fyuinvS8akOiTrm8AhXQmDGp1shet3jP5N5IOPqHcoUu/wNmUs2BYDY91NtIXNFq
b8sYNTM5zEBDlf2MwgcyCyIzF1Zcf/GRUW0JgxMqrUsOjgaVVvGamgzyhil6hOL3
Fd4PAa2u4NhVlq/lRumCSGA9fW7O2iRZ/rj4vO1c8YaiGKD3wqaXJWeLFILvngQk
F3nvxi4qaz0oMXlYW5Jjy4lX3q/WgVUBLpXayS7DuV7o7JDhC6Y8NHrTuruR8ckn
F4Lrvj7lBJNlaTI/2uWy7o7RPuOOE7zGJWQyAeyYKQh9KlTwAy1H9d/QRh5sLv3g
/1uVu/ZNzm1Rtt3xYcHEDfkgVuvuZCmiH0WNsxbyA46quyjGDmEP15MkThrzESFv
VPWem7Lrp/I2MRb6Drwr8c3nlkPerRkbVyZS8bFDe64n/3+F+Orp2YD7WnseKd04
9ui1uOttuJXhFQ==
=CjbS
-END PGP SIGNATURE-

Bug#991290: RFS: apt-listchanges/3.25 [ITA] -- package change history notification tool

[Thompson, Brian]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "apt-listchanges":

 * Package name: apt-listchanges
   Version : 3.25
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/apt-listchanges/
   Section : utils

It builds those binary packages:

  apt-listchanges - package change history notification tool

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/apt-listchanges/

Alternatively, one can download the package with dget using this 
command:


  dget -x 
https://mentors.debian.net/debian/pool/main/a/apt-listchanges/apt-listchanges_3.25.dsc


Changes since the last upload:

 apt-listchanges (3.25) experimental; urgency=medium
 .
   [ Debian Janitor ]
   * Remove constraints unnecessary since stretch.
 .
   [ Brian Thompson ]
   * Change maintainer to myself (closes: #981890).
   * Fix uninitialized variable.
   * Add debconf as build-dep.
   * Automated po update.

Regards,

BT

Bug#990508: New RFS: 3.25 (includes NMU update and maintainer update)

[Brian Thompson]

New version proposed for sponsorship at:
https://mentors.debian.net/package/apt-listchanges/

This is a new release of apt-listchanges where I incorporated an NMU commit into
the new version.  I didn't think I would need to release this as an NMU version
since I also updated the maintainer.  I thought that was a good enough reason to
skip straight to the 3.25 version instead of 3.24+nmu1.

I suppose it could be split into two separate releases, one for 3.24+nmu1
(first) and a later one for the 3.25 version (my changes).

In other news I have been triaging bugs in my spare time.
-- 
Best regards,

Brian


signature.asc
Description: This is a digitally signed message part

Bug#989496: Tagging wontfix

[Brian Thompson]

Since this is expected behavior, I am tagging as "wontfix".

I don't think it's a good idea to suppress the error message.
apt-listchanges gives an "Aborting" message prior to throwing the error.

-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)


signature.asc
Description: PGP signature

Bug#869748: Cloned and assigned to aptitude

[Brian Thompson]

I cloned this bug and assigned it to the aptitude maintainers.

The bug number is #990747.

-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)
  Minor Stasitics
  Minor Chemistry
  Minor Mathematics


signature.asc
Description: PGP signature

Bug#990508: RFS: apt-listchanges/3.24.1 [ITA] -- Proposed changes

[Brian Thompson]

David,

I'm thinking about the first line in debian/apt.conf to:

```
DPkg::Pre-Install-Pkgs { "/usr/bin/apt-listchanges --apt || test $? -lt
  10 >/dev/null 2&>1"; };$
```

adding the ">/dev/null 2&>1" in order to suppress dpkg errors in
apt-listchanges during the Pre-Install-Pkgs hook.  By doing this, the
original functionality will be preserved while at the same time piping
the misleading dpkg error message to /dev/null.  apt-listchanges will
still preserve its error message--"Aborting".

What do you think about this approach?

The alternative is to close out this bug since it is intended
functionality and leave it as-is.

-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)
  Minor Stasitics
  Minor Chemistry
  Minor Mathematics


signature.asc
Description: PGP signature

Bug#990508: RFS: apt-listchanges/3.24.1 [ITA] -- Show new changelog entries from Debian package archives

[Brian Thompson]

+Tia, the bug reporter for #989496.
-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)
  Minor Stasitics
  Minor Chemistry
  Minor Mathematics


signature.asc
Description: PGP signature

Bug#989496: Looking to change the subject

[Brian Thompson]

It was brought to my attention by David K. (thank you, David), that the
what you are seeing is intended functionality.  I proposed in the email
thread with David that we could improve the error message, since right
now it may be confusing to users that it is actually expected behavior.
A cleaner, clearer error message should resolve any confusion.

I will CC you Tia.

-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)
  Minor Stasitics
  Minor Chemistry
  Minor Mathematics


signature.asc
Description: PGP signature

Bug#990508: RFS: apt-listchanges/3.24.1 [ITA] -- Show new changelog entries from Debian package archives

[Brian Thompson]

On Sat, Jul 03, 2021 at 12:50:17PM +0200, David Kalnischkies wrote:
>Hi,
>
>On Wed, Jun 30, 2021 at 06:13:14PM -0500, Brian Thompson wrote:
>>   * Fix error message being thrown when choosing not to proceed on
>> confirmation (closes: #989496).
>
>If I understand your fix correctly, you have broken the "no"
>functionality as the Pre-Install-Pkgs hook has to fail for apt to
>actually stop… if they are successful apt will continue with what it was
>initially told to do, which seems not inline with what "no" was supposed
>to accomplish… could you clarify?

I didn't realize that the error message I essentially got rid of was
intended functionality.  I did some rudimentary testing of the change,
and if "no" was selected then any packages with a changelog entry aren't
updated, but everything else is.  Still, in hindsight, that could break
the existing package if dependencies are updated and the source package
is held back (that's definitely not what I intended).  I should have
tested more thoroughly, but I can revert the change.

I think the bug that was referenced by that fix shows that [at least]
some users were confused by the error message, and didn't realize it was
intended functionality.  Perhaps cleaning up the error message a bit so
users aren't confused by it (which may lead to erroneous bug reports) is
a good idea.

>(I don't know apt-listchanges code nor do I use the confirmation
> functionality of it, so I could easily be entirely wrong)

I'm pretty new to it as well.  I've only read through the code one time.

>(That seems more like we should have a way for the hooks to tell apt to
> gracefully wind down, but that doesn't exist so far)

That would be ideal.

>Could I interest you in joining the apt-team and maintain listchanges as
>part of it? I am personally not much help than it comes to python, but
>Julian might. Mailing list is de...@lists.debian.org and/or you can join
>our IRC channel #debian-apt.

I would be interested in joining the apt-team, and I think that makes
more sense than making "rogue" contributions outside of the team's view.

>I also note that your changelog targets unstable, which might be fine if
>you want to fix the mentioned bug and consider it RC (I am not so sure),
>but the churn in the package (= reflow of the pt.po and pot file) will
>make the release team unhappy.

That's good to know.  Thanks for pointing that out.  This is my first
contribution.

>Looking at your git history, all this should not be in one single commit
>either – individual commits with proper titles and metadata will help
>you even: You wrote the changelog by hand, git-buildpackage can do this
>for you...
>
>As a bonus, a week later looking at the history you will still know at
>a glance what happened without remembering (or looking up) cryptic
>bugreport numbers first – not to mention others. With the data in place
>you could then also add a hook to salsa which automatically sets
>bugreports to pending after a push of the related commit and many more
>fun stuff.
>
>(It is of course not required, even many upstream projects use "fix #42"
> as commit message and are happy and successful. So if that works for
> you fine, I am just trying to nudge you to try an alternative which
> works better for me, many others and perhaps also you)

Also good stuff to know.  I will take your advice and follow in others'
footsteps.

+++
In the meantime, I will take a closer look at the bug reports to see if
there are any quick wins there.  That way I can proceed with the
adoption of the package.

Lastly, I'll join the IRC channel and look to join the apt-team, as you
suggested.

Thanks, David!

-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#939287: Add urgency level separators

[Brian Thompson]

On Tue, 03 Sep 2019 03:37:58 +0800 =?utf-8?B?56mN5Li55bC8?= Dan
Jacobson  wrote:
> Man page says 'The groups are sorted by the urgency of the most urgent
> change, and than by the package name.'
> 
> Alas, that looks like
> 
> A
> B
> C
> A
> B
> A
> B
> 
> to the user. So perhaps add
> 
> --urgency=high:
> A
> B
> C
> --urgency=medium:
> A
> B
> --urgency=low:
> A
> B
> 
> separators, so it would all make sense.

I like the change you proposed.  I don't think that would be too hard to
do given that the changes are already sorted in order.  This would
definitely improve readability IMO.
-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#986840: apt-listchanges fails to parse status files with ^M characters; should use apt_pkg.TagFile, not write its own parser

[Brian Thompson]

Julian,

I didn't see that you cloned this bug and assigned it to dpkg and that
the bug is no longer in apt-listchanges.  I still think that your
original proposal for apt-listchanges is relevant and is a change worth
making.
-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#986840: apt-listchanges fails to parse status files with ^M characters; should use apt_pkg.TagFile, not write its own parser

[Brian Thompson]

> As reported in
> https://bugs.launchpad.net/ubuntu/+source/apt-listchanges/+bug/1854772,
> apt-listchanges
> fails to parse status files that contain carriage return characters, as
> Python normalizes the line endings.

I'm tracking the downstream bug in Ubuntu as well as this one.

> Instead of writing its own ad-hoc parser, apt-listchanges should use
> apt_pkg.TagFile instead.

I did a little bit of digging into how to rewrite the parser with your
suggested changes.  I agree that apt-listchanges should not be using its
own parser, especially since a standardized one exists in apt_pkg.

Preliminarily, I have these changes in mind for
apt_listchanges.ControlParser.readfile() (spacing adjusted for brevity):

```python
...
try:
  with apt_pkg.TagFile(file) as tagfile:
for section in tagfile:
  self.stanzas += [ControlStanza(x) for x in section]
except: ...  
```

There also, at the very least, may need a change to be made to
apt_listchanges.DebianFiles.ControlParser.readdeb() as well.  I'm hoping 
that we can avoid rewriting some of the classes in
apt_listchanges.DebianFiles, namely ControlParser and ControlStanza.

If you have suggestions on how the change would look, please let me
know.

-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#990508: RFS: apt-listchanges/3.24.1 [ITA] -- Show new changelog entries from Debian package archives

[Brian Thompson]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a package I made a fix for,
"apt-listchanges":

* Package name: apt-listchanges
  Version : 3.24.1
  Upstream Author : Brian Thompson 
* URL : https://salsa.debian.org/briant/apt-listchanges
* License : GPL-2+
* Vcs : https://salsa.debian.org/debian/apt-listchanges
  Section : utils

It builds those binary packages:

  apt-listchanges - package change history notification tool

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/apt-listchanges/

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/apt-listchanges/apt-listchanges_3.24.1.dsc

Changes since the last upload:

  * Fix error message being thrown when choosing not to proceed on
confirmation (closes: #989496).
  * Update maintainer to myself (closes: #981890).

Best regards,
--
  Brian Thompson

Bug#989496: apt-listchanges: Error output if choosing to not continue after reading list of changes

[Brian Thompson]

Tia,

Thank you for reporting this bug.  I can confirm that this is an issue:

apt-listchanges: Do you want to continue? [Y/n] n
apt-listchanges: Aborting
E: Sub-process /usr/bin/apt-listchanges --apt || test $? -lt 10 returned an
error code (1)
E: Failure running script /usr/bin/apt-listchanges --apt || test $? -lt 10

I believe I have found the issue and have a fix ready to go.  I'll
set the status to pending.

-- 
Best regards,

Brian

Bug#990427: apt-listchanges: Invalid format text for mutt

[Brian Thompson]

Package: apt-listchanges
Version: 3.24
Severity: normal

Dear Maintainer,

After performing an installation of a previously uninstalled package,
apt-listchanges reported an error:

"Invalid format text for mutt"

The package still installed, but no changelog or NEWS was shown or
emailed out.

The expected behavior is that no error is thrown since the email_format
is set correctly, or if there is an error in my configuration (aside
from the email_format field), then that be pointed out instead.

-- Package-specific info:
==> /etc/apt/listchanges.conf <==
[apt]
frontend=pager
which=both
email_address=br...@hashvault.io
email_format=text
confirm=false
headers=true
reverse=false
titled=true
save_seen=/var/lib/apt/listchanges.db
no_network=false

[cmdline]
frontend=pager
email_address=br...@hashvault.io
email_format=text
which=both

[custom]
frontend=browser
browser=chromium


-- 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/8 CPU threads)
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 apt-listchanges depends on:
ii  apt2.2.4
ii  debconf [debconf-2.0]  1.5.75
ii  python33.9.2-3
ii  python3-apt2.2.0
ii  python3-debconf1.5.75
ii  sensible-utils 0.0.14
ii  ucf3.0043

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  chromium [www-browser]90.0.4430.212-1
ii  edbrowse [www-browser]3.7.7-2
ii  firefox-esr [www-browser] 78.11.0esr-1
ii  kitty [x-terminal-emulator]   0.19.3-1
ii  links [www-browser]   2.21-1+b1
ii  lynx [www-browser]2.9.0dev.6-2
ii  mlterm [x-terminal-emulator]  3.9.0-1
ii  palemoon [www-browser]29.2.0-1.gtk2
ii  postfix [mail-transport-agent]3.5.6-1+b1
ii  python3-gi3.38.0-2
ii  xfce4-terminal [x-terminal-emulator]  0.8.10-1
ii  xiterm+thai [x-terminal-emulator] 1.10-2+b2
ii  xterm [x-terminal-emulator]   366-1

-- debconf information:
* apt-listchanges/email-format: text
* apt-listchanges/confirm: false
* apt-listchanges/save-seen: true
* apt-listchanges/reverse: false
* apt-listchanges/email-address: br...@hashvault.io
* apt-listchanges/no-network: false
* apt-listchanges/which: both
* apt-listchanges/headers: true
* apt-listchanges/frontend: pager

Bug#926175: tag moreinfo 926175

[Brian Thompson]

tags 926175 moreinfo
thanks
-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#926175: apt-listchanges: only a single changelog is shown when multiple packages are updated

[Brian Thompson]

Every unexpected behavior is a potential bug. We shouldn't close this bug
yet.  Nicholas, are you still seeing this behavior?

-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#990024: libxrandr2: xrandr shows HDMI-connected display as DP

[Brian Thompson]

Package: libxrandr2
Version: 2:1.5.1-1
Severity: normal
Tags: d-i

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

-- 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/8 CPU threads)
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 libxrandr2 depends on:
ii  libc62.31-12
ii  libx11-6 2:1.7.1-1
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1

libxrandr2 recommends no packages.

libxrandr2 suggests no packages.

-- no debconf information
-
I used the Debian Bullseye non-free xfce-firmware installer.  After
completing the installation, I plugged in my external 144Hz monitor into
an HDMI port, but xrandr shows it as being connected to DP-1 instead of
HDMI-1.  Additionally, the refresh rate for the default resolution
(2560x1440) is set at 59.98Hz instead of 144.00Hz, with no option to set 
a higher refresh rate.

This is more about reporting that xrandr shows my HDMI-connected monitor
being connected with a DP adapter.
-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#951374: gh cli -- Getting it ready

[Brian Thompson]

Is anyone getting the gh CLI tool ready for packaging?  If not,
I can adopt it.  I use it quite heavily and am fairly familiar
with its development team if I have any questions.
-- 
Best regards,

Brian

Bug#907576: . dream -- A Software Digital Radio Mondiale Receiver

[Brian Thompson]

Garie,

TL;DR Use an IDE or text editor on your machine.

Local IDEs/text editors are used to develop the vast, vast majority of
software.  Most developers develop on their own machines instead of in
the browser.  It doesn't make sense to develop in a browser-based IDE
(at least not yet) since they are missing vital functionality.  Whole
OSes can't be replicated in the browser, whereby the browser greatly
limits access to common development tools.

Best regards,

Brian

On June 15, 2021, GMiller  wrote:
> Hello Christoph
> >Re: GMiller > For  the subject project, I have encountered a
> roadblock while attempting to use the 'Salsa Web Terminal'. I filed
> Gitlab Issue 233 (see attachments) seeking information to prepare a
> 'gitlab-webide.yml' file (I searched but could find no documentation
> on it). The response to 233 >says "To upload designs, you'll need to
> enable LFS and have an admin enable hashed storage". 
>  >>Sorry, I can help you with packaging hamradio software, but please
> use a normal editor like everyone else. There is no need to bother
> with funky web stuff, especially if it doesn't work out of the box.
> Christoph
>
> I am not sure I understand your comment. Are you saying in effect,
> don't use a Salsa IDE to build/test the project? Instead use an IDE on
> my local machine to build/test and develop any code changes? Is that
> how most Salsa projects are doing it?
> Thanks for your patience
> Garie Miller wb9awa
> Sent with ProtonMail  Secure Email.

Bug#985669: Happy to help

[Brian Thompson]

> While I would love to package this myself, I do not work with
> JavaScript regularally (in part due to ecosystem problems like
> NPM's love of duplication).

I have some experience packaging JavaScript projects and could help you
out here.



signature.asc
Description: PGP signature

Bug#365427: [O: apt-build] Is this package worth adopting or has it been replaced?

[Brian Thompson]

On Sat, 17 Apr 2021 05:48:48 +0200 Axel Beckert  wrote:
> Hi,
> 
> No Body wrote:
> > Is this package worth adopting or has it been replaced by something
> > else?
> 
> There's nothing like it so far AFAIK. apt-src is close, but has a
> different focus (modification instead of compile-time optimization).
> 
> > I read the entire bug message history and saw that in 2016 there was some
> > development going on to replace the package.
> 
> I don't see which message you mean. In 2016, there were only control
> messages and spam in this bug report.
> 
>   Regards, Axel
> -- 
>  ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
> 
> 

Axel, switched my email address to one that I actually use. Going to start 
looking into this package more.
-- 
Best regards,

Brian

Bug#987467: autopkgtest library fails with: FAIL stderr: pkill: killing pid 1764 failed: Operation not permitted

[Brian Thompson]

On Sat, Apr 24, 2021 at 01:06:04PM +0200, Chris Hofstaedtler wrote:
> Source: mosquitto
> Version: 2.0.10-4
> Severity: serious
> 
> Dear Maintainer,
> 
> your autopkgtest appears to fail:
> 
> autopkgtest [21:45:54]: test library: [---
> pkill: killing pid 1764 failed: Operation not permitted
> make: Entering directory 
> '/tmp/autopkgtest-lxc.zrj4yodu/downtmp/build.er2/src/test/lib'
> [..]
> autopkgtest [21:46:36]: test library: ---]
> autopkgtest [21:46:36]: test library:  - - - - - - - - - - results - - - - - 
> - - - - -
> library  FAIL stderr: pkill: killing pid 1764 failed: Operation 
> not permitted
> autopkgtest [21:46:36]: test library:  - - - - - - - - - - stderr - - - - - - 
> - - - -
> pkill: killing pid 1764 failed: Operation not permitted
> 
> I do not quite understand what the pkill -x mosquitto is good for in
> the tests, but certainly it does not work.
> 
> Filing as serious, as this prevents migration to testing.
> 
> Chris
> 

I'm not a maintainer, but I see that in the code the command does what
it intends to do, checks out with the man pages although I haven't read
it myself:

# Tell Mosquitto to reload certificates and configuration
pkill -HUP -x mosquitto

Additionally, this code looks like it should work:

# Set ownership to Mosquitto
chown mosquitto: /etc/mosquitto/certs/server.pem \
/etc/mosquitto/certs/server.key

# Ensure permissions are restrictive
chmod 0600 \
/etc/mosquitto/certs/server.pem \
/etc/mosquitto/certs/server.key

But I think this is more accurate (omitting the ":"):

chown mosquitto /etc/mosquitto/certs/server.pem \
/etc/mosquitto/certs/server.key

Best regards,

Brian


signature.asc
Description: PGP signature

Bug#984736:

[Brian Thompson]

>Ideally a maintainer willing to help cron move forward would support the next>major task to be done: moving the Debian-specific patches into cronie and >providing an updated package for cronie replacement that can eventually>replace cron. I’d like to help out here if no one else has responded.  I can read repositories on Salsa but don’t have an account there yet since I’m not officially a part of the Debian org. >Please contact the current maintainer if you can help in maintaining and>improving cron. @Javier, I cc’ed you and I think what is Christian’s email which I pulled from the cron git history. Best regards, Brian 

Bug#365427: Autotests for apt-build utility

[Brian Thompson]

On Thu, 15 Nov 2018 23:40:07 +0300 =?UTF-8?B?0JrQvtC70Y8g0JPRg9GA0YzQtdCy?=  wrote:> I intend to do some refactoring of apt-build, but first I'd like to> write autopkgtests for the package. I have two versions of a simple test> case for install command, and I still can't decide what language use for> tests. In attachment you'll find two identical scripts in Bash and Perl.> Comments are welcome!> > It'd be good to write full tests before new year and buster freeze.> > To be clear: I'm not going to adopt the package yet, because I'm unsure> that I have enough time for this work.>  @Axel Beckert This is the message I was referring to from “2016”. I would like to adopt this package if no one else has. Best regards, Brian Thompson 

Bug#986456: chromium: Could not unzip extension on armhf

[Daniel Thompson]

Package: chromium
Version: 89.0.4389.114-1
Severity: normal
X-Debbugs-Cc: daniel.thomp...@linaro.org

Dear Maintainer,

I am unable to install extensions using the latest chromium package for
armhf. Normally this affects me because I run chromium/armhf on a
multilib system that is predominantly arm64. However I have confirmed
that the problem also exists on a "pure" armhf userspace (although still
with an arm64 kernel) and a fully clean install.

To reproduce from a clean install (e.g. brand new home directory, no
old config files or extensions):

1. Install chromium
2. Navigate to https://chrome.google.com/webstore
3. Try to install an extension (I tested primarily with bitwarden
   but I also checked a couple of "random" ones from the suggestions
   list (Zoom, Dark Mode, Visor and saw the same results).
4. Chromium reports "An error has occured: Could not unzip extension".

This doesn't appear to be related to the recent changes to Google
Sync: I am still able to install bitwarden successfully on chromium/arm64.

In fact chromium/arm64 does offer a workaround (of sorts). On arm64 hardware.
I can install the extensions I require and then `apt install chromium:armhf`
to switch back to 32-bit chromium and the extensions continune to function!

Note that the report below is from the system I used to test with a "pure"
armhf userspace and resulted in my running with a custom kernel. On other
systems I have observed the same problem with a Debian kernel kernel
(5.10.0-5-arm64).

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (aarch64)
Foreign Architectures: arm64

Kernel: Linux 5.7.0-2-pinebookpro-arm64 (SMP w/6 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)

Versions of packages chromium depends on:
ii  chromium-common  89.0.4389.114-1
ii  libasound2   1.2.4-1.1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatomic1   10.2.1-6
ii  libatspi2.0-02.38.0-2
ii  libavcodec58 7:4.3.2-0+deb11u1
ii  libavformat587:4.3.2-0+deb11u1
ii  libavutil56  7:4.3.2-0+deb11u1
ii  libc62.31-11
ii  libcairo21.16.0-5
ii  libcups2 2.3.3op2-3
ii  libdbus-1-3  1.12.20-2
ii  libdrm2  2.4.104-1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat12.2.10-2
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgbm1  20.3.5-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  libharfbuzz0b2.7.4-1
ii  libicu67 67.1-6
ii  libjpeg62-turbo  1:2.0.6-4
ii  libjsoncpp24 1.9.4-4
ii  liblcms2-2   2.12~rc1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.63-1
ii  libopenjp2-7 2.4.0-3
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpulse014.2-2
ii  libre2-9 20210201+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.7.0-2
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxrandr2   2:1.5.1-1
ii  libxshmfence11.3-1
ii  libxslt1.1   1.1.34-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  89.0.4389.114-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6   2.31-11
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.0-2
ii  libxext62:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox   89.0.4389.114-1
ii  fonts-liberation   1:1.07.4-11
ii  gnome-shell [notification-daemon]  3.38.4-1
ii  libgl1-mesa-dri20.3.5-1
ii  libu2f-udev1.1.10-3
ii  notification-daemon3.20.0-4
ii  system-config-printer  1.5.14-1
ii  upower 0.99.11-2

Versions of packages chromium-sandbox depends on:
ii  libc6  2.31-11
ii  libgcc-s1  10.2.1-6

-- no debconf information

Bug#941513: marked as done (c-graph: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended)

[Adrienne G. Thompson]

Greetings:

Steve, Debian:

I am completely immersed in the matter of seeking funds to support GNU
C-Graph, and accordingly am unable to address the build problem indicated.
Please note that I know absolutely nothing about packaging and would have
to budget the time to learn how to do it. Paul Hardy, who built the current
package, is no longer part of the team.

I am unable to find Debian packagers willing to work on C-Graph. C-Graph is
under attack by the Professors associated with the University of Aberdeen
responsible for stealing the underlying work. My BSc. computer program was
given to a white Scot for his PhD in the University's practice of
apartheid. Everyone seems to be happy to participate in the cover-up of the
crime - the racist professors have even recruited Uncle Toms from MIT and
the University of the West Indies. GNU C-Graph, they claim "could not have
been written in the Third World". Translation - "could not have been
written by a black person".

I will not be able to begin to address Debian packaging until I have
completed the paperwork necessary for submitting the current grant
application (this includes a business plan) and I have finished coding the
next release - which requires learning a new language, Python.  Burnout
from the events surrounding the removal of RMS from the board of the FSF
followed by the current covid crisis have pretty much demolished my
timetable.

GNU C-Graph has an estimated user base of 30 million worldwide. C-Graph is
the first software package to be conceived and coded solo by a woman. So
much for diversity and inclusion. Just about everyone seems to be singing
this meaningless song.

Regards
Adrienne
  --
Freedom - no pane, all gaiGN!

GNU C-Graph - http://www.gnu.org/software/c-graph
Code Art Now - http://codeartnow.com
Abertheid Campaign - http://www.abertheid.info
Follow me on Twitter @AdrienneGT @GNUcgraph
Let's Link Up at https://www.linkedin.com/in/adriennegt/


On Sat, May 2, 2020 at 4:01 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sat, 02 May 2020 20:59:31 +
> with message-id 
> and subject line Bug#959372: Removed package(s) from unstable
> has caused the Debian Bug report #941513,
> regarding c-graph: build-depend on texlive-plain-generic, not obsolete
> texlive-generic-recommended
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 941513: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941513
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Steve Langasek 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Tue, 01 Oct 2019 11:56:51 -0700
> Subject: c-graph: build-depend on texlive-plain-generic, not obsolete
> texlive-generic-recommended
> Package: c-graph
> Version: 2.0.1-3.1
> Severity: serious
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu eoan ubuntu-patch
>
> Hi Adrienne,
>
> The texlive-generic-recommended transitional package has been dropped from
> texlive-base in sid.  Please update your build-dependency to
> texlive-plain-generic instead.
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 941513-d...@bugs.debian.org
> Cc: c-gr...@packages.debian.org
> Bcc:
> Date: Sat, 02 May 2020 20:59:31 +
> Subject: Bug#959372: Removed package(s) from unstable
> Version: 2.0.1-3.1+rm
>
> Dear submitter,
>
> as the package c-graph has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.
>
> For details on the removal, please see https://bugs.debian.org/959372
>
> The version of this package that was in Debian prior to this removal
> can still be found using http://snapshot.debian.org/.
>
> Please note that the changes have been done on the master archive and
> will not propagate to any mirrors until the next dinstall run at the
> earliest.
>
> This message was generated automatically; if you believe that there is
> a problem with it please contact the archive administrators by mailing
> ftpmas...@ftp-master.debian.org.
>
> Debian distribution maintenance software
> pp.
> Scott Kitterman (the ftpmaster behind the curtain)

Bug#949385: cacti: Cacti fails under PHP-FPM

[Adam Thompson]

The reason we’re running php-7.4 is because I screwed up; I enabled the entire 
backports repo instead of selecting individual packages from it.
Given that this is the Nth time I’ve done this or seen it done, I suspect it’s 
a reasonably common scenario/mistake.
-Adam

Bug#949910: Same failure mode continues to exist in 5.3 kernel package.

[Adam Thompson]

Same failure mode continues to exist in 5.3 kernel package.
How best to upload 5000+ lines of dmesg here?

Bug#949910: linux-image-4.19.0-6-amd64: bnx2x driver fails in DMAE, renders server unusable

[Adam Thompson]

Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: critical
Tags: upstream
Justification: breaks the whole system

Dear Maintainer,

   * What led up to the situation?
Upgraded Debian from 9 to 10.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Have tried various module options, also have tried not using bonding.

   * What was the outcome of this action?
Driver soft-lockup, causing overall system instability and unusability.

   * What outcome did you expect instead?
Driver should work with existing harware.

Actual failure looks like this in dmesg:
syslog:Jan 26 15:49:50 muug kernel: [734667.232433] bnx2x: 
[bnx2x_write_dmae:597(enp3s0f1)]DMAE returned failure -1
syslog:Jan 26 15:49:50 muug kernel: [734667.432133] bnx2x: 
[bnx2x_issue_dmae_with_comp:549(enp3s0f1)]DMAE timeout!
syslog:Jan 26 15:49:50 muug kernel: [734667.432525] bnx2x: 
[bnx2x_write_dmae:597(enp3s0f1)]DMAE returned failure -1
syslog:Jan 26 15:49:50 muug kernel: [734667.632114] bnx2x: 
[bnx2x_issue_dmae_with_comp:549(enp3s0f1)]DMAE timeout!
syslog:Jan 26 15:51:52 muug kernel: [1.358268] bnx2x: QLogic 5771x/578xx 
10/20-Gigabit Ethernet Driver bnx2x 1.712.30-0 (2014/02/10)
syslog:Jan 26 15:51:52 muug kernel: [1.358322] bnx2x :03:00.0: msix 
capability found
syslog:Jan 26 15:51:52 muug kernel: [1.358541] bnx2x :03:00.0: part 
number 394D4342-34383735-30345430-473030
syslog:Jan 26 15:51:52 muug kernel: [1.459205] bnx2x :03:00.0: 31.504 
Gb/s available PCIe bandwidth, limited by 8 GT/s x4 link at :00:01.2 
(capable of 63.008 Gb/s with 8 GT/s x8 link)
syslog:Jan 26 15:51:52 muug kernel: [1.459303] bnx2x :03:00.1: msix 
capability found
syslog:Jan 26 15:51:52 muug kernel: [1.459477] bnx2x :03:00.1: part 
number 394D4342-34383735-30345430-473030
syslog:Jan 26 15:51:52 muug kernel: [1.502898] bnx2x :03:00.1: 31.504 
Gb/s available PCIe bandwidth, limited by 8 GT/s x4 link at :00:01.2 
(capable of 63.008 Gb/s with 8 GT/s x8 link)
syslog:Jan 26 15:51:52 muug kernel: [1.503800] bnx2x :03:00.1 enp3s0f1: 
renamed from eth1
syslog:Jan 26 15:51:52 muug kernel: [1.554228] bnx2x :03:00.0 enp3s0f0: 
renamed from eth0

except that there are thousands of bnx2x error messages. Those interfaces 
cannot pass traffic.  The interrupt storm or dmesg flood or something also 
renders the system unusable even through unaffected interfaces.
These interfaces worked fine in Debian 9 mid-way through its lifecycle, but the 
current packages failed.  I opted to try upgrading to 10, but this still fails 
in Debian 10.  (I don't know the version of the last unaffected kernel, sorry - 
we were way behind by accident, and jumped a year+ in kernel versions.)
I've found multiple issues around the 'net relating to this, all noting 
essentially the same behaviour.
A regular "reboot" is inadequate to reboot (within 24hrs, anyway), I have to 
issue a "reboot -f".

-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64 
root=UUID=3142d5ea-ae76-4a19-b49d-5e5b16c796e6 ro quiet

** Tainted: POE (12289)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   12.859416] RPC: Registered tcp transport module.
[   12.859417] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   12.898428] EXT4-fs (md1): re-mounted. Opts: 
discard,user_xattr,errors=remount-ro
[   12.961213] systemd-journald[428]: Received request to flush runtime journal 
from PID 1
[   12.998981] IPMI System Interface driver.
[   12.999000] ipmi_si dmi-ipmi-si.0: ipmi_platform: probing via SMBIOS
[   12.999002] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0
[   12.999003] ipmi_si: Adding SMBIOS-specified kcs state machine
[   12.999022] ipmi_si IPI0001:00: ipmi_platform: probing via ACPI
[   12.999044] ipmi_si IPI0001:00: [io  0x0ca2] regsize 1 spacing 1 irq 0
[   12.999045] ipmi_si dmi-ipmi-si.0: Removing SMBIOS-specified kcs state 
machine in favor of ACPI
[   12.999046] ipmi_si: Adding ACPI-specified kcs state machine
[   12.999081] ipmi_si: Trying ACPI-specified kcs state machine at i/o address 
0xca2, slave address 0x20, irq 0
[   13.042949] usbcore: registered new interface driver usbserial_generic
[   13.042958] usbserial: USB Serial support registered for generic
[   13.045760] EDAC MC0: Giving out device to module ie31200_edac controller 
IE31200: DEV :00:00.0 (POLLED)
[   13.045971] iTCO_vendor_support: vendor-support=0
[   13.046155] usbcore: registered new interface driver cp210x
[   13.046164] usbserial: USB Serial support registered for cp210x
[   13.046179] cp210x 1-10:1.0: cp210x converter detected
[   13.047862] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   13.047915] iTCO_wdt: Found a Lynx Point TCO device 

Bug#949385: cacti: Cacti fails under PHP-FPM

[Adam Thompson]

Package: cacti
Version: 1.2.2+ds1-2+deb10u2
Severity: grave
Tags: upstream newcomer
Justification: renders package unusable

Dear Maintainer,


   * What led up to the situation?
Switching from Apache2 to Nginx, which mandated switching from mod_php to 
PHP-FPM.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Setting this line in nginx.conf:
fastcgi_catch_stderr "AAABBBCCCDDDEEEFFF"; # try to always pass the crap 
through, never detect an error
   * What was the outcome of this action?
Cacti at least loads now, but generates a nearly endless series of 
non-understandable error messages.
   * What outcome did you expect instead?
Cacti to just... work.

The exact error is:
[20-Jan-2020 08:19:02] WARNING: [pool www] child 18496 said into stderr: 
"NOTICE: PHP message: PHP Notice:  Trying to access array offset on value of 
type null in /usr/share/cacti/site/lib/functions.php on line 4431"

This looks a lot like https://github.com/Cacti/cacti/issues/3127, I think?
Supposedly this is fixed in 1.2.7 somehow, but even though 1.2.8 is available 
in testing, I'm still on Buster, and I've seen the package maintainer's 
comments that installing -testing's version on -stable isn't likel to work at 
all, so I haven't tried completely breaking my server in that way yet.

Once I convince nginx to pass through error details instead of just dumping me 
at a "502 bad gateway" error, Cacti looks like it sorta kinda works... but it 
doesn't actually work.  Every page load gets me a popup with "Sorry, we could 
not process your last action.  Error: 200  Reason: The response to the last 
action was unexpeced." and in the logs, another corresponding entry about 
functions.php:4431.

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

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

Versions of packages cacti depends on:
ii  dbconfig-common 2.0.11+deb10u1
ii  dbconfig-mysql  2.0.11+deb10u1
ii  debconf [debconf-2.0]   1.5.71
ii  fonts-dejavu-core   2.37-1
ii  fonts-dejavu-extra  2.37-1
ii  fonts-fork-awesome  1.1.5+ds1-2
ii  javascript-common   11
ii  libapache2-mod-php  2:7.4+71+0~20191219.19+debian10~1.gbpefc769
ii  libapache2-mod-php7.4 [libapac  7.4.1-1+0~20191218.8+debian10~1.gbp21c50e
ii  libjs-c30.4.11+dfsg-2
ii  libjs-chart.js  2.7.3+dfsg-5
ii  libjs-d33.5.17-2
ii  libjs-jquery3.3.1~dfsg-3
ii  libjs-jquery-colorpicker1.2.17-1
ii  libjs-jquery-cookie 12-1.1
ii  libjs-jquery-hotkeys0~20130707+git2d51e3a9+dfsg-2
ii  libjs-jquery-jstree 3.3.7+dfsg1-1
ii  libjs-jquery-metadata   12-1.1
ii  libjs-jquery-tablesorter1:2.31.1+dfsg1-1
ii  libjs-jquery-timepicker 1.2-1
ii  libjs-jquery-ui 1.12.1+dfsg-5
ii  libjs-jquery-ui-theme-smoothne  1.12.1+dfsg-1
ii  libjs-jquery-ui-theme-south-st  1.12.1+dfsg-1
ii  libjs-jquery-ui-theme-ui-darkn  1.12.1+dfsg-1
ii  libjs-jquery-ui-touch-punch 0.0~git20141218.2.4bc0091+dfsg1-2
ii  libphp-phpmailer6.0.6-0.1
ii  perl5.28.1-6
ii  php-gd  2:7.4+71+0~20191219.19+debian10~1.gbpefc769
ii  php-gmp 2:7.4+71+0~20191219.19+debian10~1.gbpefc769
ii  php-ldap2:7.4+71+0~20191219.19+debian10~1.gbpefc769
ii  php-mbstring2:7.4+71+0~20191219.19+debian10~1.gbpefc769
ii  php-mysql   2:7.4+71+0~20191219.19+debian10~1.gbpefc769
ii  php-php-gettext 1.0.12-0.1
ii  php-phpseclib   2.0.14-1
ii  php-snmp2:7.4+71+0~20191219.19+debian10~1.gbpefc769
ii  php-twig2.6.2-2
ii  php-xml 2:7.4+71+0~20191219.19+debian10~1.gbpefc769
ii  php7.4-cli [php-cli]7.4.1-1+0~20191218.8+debian10~1.gbp21c50e
ii  php7.4-gd [php-gd]  7.4.1-1+0~20191218.8+debian10~1.gbp21c50e
ii  php7.4-gmp [php-gmp]7.4.1-1+0~20191218.8+debian10~1.gbp21c50e
ii  php7.4-json [php-json]  7.4.1-1+0~20191218.8+debian10~1.gbp21c50e
ii  php7.4-ldap [php-ldap]  7.4.1-1+0~20191218.8+debian10~1.gbp21c50e
ii  php7.4-mbstring [php-mbstring]  7.4.1-1+0~20191218.8+debian10~1.gbp21c50e
ii  php7.4-snmp [php-snmp]  7.4.1-1+0~20191218.8+debian10~1.gbp21c50e
ii  php7.4-xml [php-xml]7.4.1-1+0~20191218.8+debian10~1.gbp21c50e
ii  rrdtool 1.7.1-2
ii  snmp

Bug#946950: Will use wrong root= parameter if commented out line exists in fstab

[Daniel Thompson]

Package: u-boot-menu
Version: 4.0.1
Followup-For: Bug #946950

When installed on my system the comment test is using single square
brackets rather than double square brackets. This is causing 
regressions, specifically if you have two or more files whose filenames 
start with a # in the current working directory then the code to parse
/etc/fstab fails completely.

The test should either use [[ ]] or, if double square brackets, must be
avoided for some reason then it cannot use a wildcard and needs
something like [ "${_FS_TYPE}" == "${_FS_TYPE###}" ].


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

Kernel: Linux 5.4.2-2-pinebookpro-arm64 (SMP w/6 CPU cores; PREEMPT)
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 u-boot-menu depends on:
ii  linux-base  4.6

u-boot-menu recommends no packages.

Versions of packages u-boot-menu suggests:
pn  flash-kernel  

-- Configuration Files:
/etc/default/u-boot changed [not included]

-- no debconf information

Bug#941513: c-graph: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended

[Adrienne G. Thompson]

Hi Steve:

I've been tied up with dealing with the ongoing attacks against RMS and the
GNU project. I'll deal with the build dependency problem over the next few
days.

Cheers
Adrienne

On Tue, Oct 1, 2019 at 2:00 PM Steve Langasek 
wrote:

> Package: c-graph
> Version: 2.0.1-3.1
> Severity: serious
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu eoan ubuntu-patch
>
> Hi Adrienne,
>
> The texlive-generic-recommended transitional package has been dropped from
> texlive-base in sid.  Please update your build-dependency to
> texlive-plain-generic instead.
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>


-- 
Freedom - no pane, all gaiGN!

GNU C-Graph - http://www.gnu.org/software/c-graph
Code Art Now - http://codeartnow.com
Abertheid Campaign - http://www.abertheid.info
Follow me on Twitter @AdrienneGT @GNUcgraph

Bug#942755: /usr/sbin/pppd: pppol2tp plugin segfaults when "dump" option specified

[Jamie Thompson]

Package: ppp
Version: 2.4.7-2+4.1
Severity: normal
File: /usr/sbin/pppd

Dear Maintainer,

I've just been setting up a l2tp vpn and found that pppd segfaulted whenever I 
tried to connect. Digging into things, I found this Ubuntu bug report:
 https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1410675

...and I can confirm that removing the option resolved the issue for me. I 
cannot comment on the analysis offered on the bug report.

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

Kernel: Linux 4.19.0-5-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ppp depends on:
ii  libc6   2.28-10
ii  libpam-modules  1.1.8-3
ii  libpam-runtime  1.1.3-9
ii  libpam0g1.1.8-3.8
ii  libpcap0.8  1.6.2-1
ii  libssl1.1   1.1.1-2
ii  lsb-base9.20170808
ii  procps  2:3.3.12-2

ppp recommends no packages.

ppp suggests no packages.

-- Configuration Files:
/etc/ppp/options changed [not included]

-- no debconf information

Bug#941513: c-graph: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended

[Adrienne G. Thompson]

Hi Steve:

Thanks for flagging the problem. I've forwarded the issue to my packaging
team.

Sincerely
Adrienne
-- 
Freedom - no pane, all gaiGN!

GNU C-Graph - http://www.gnu.org/software/c-graph
Code Art Now - http://codeartnow.com
Abertheid Campaign - http://www.abertheid.info
Follow me on Twitter @AdrienneGT @GNUcgraph


On Tue, Oct 1, 2019 at 2:00 PM Steve Langasek 
wrote:

> Package: c-graph
> Version: 2.0.1-3.1
> Severity: serious
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu eoan ubuntu-patch
>
> Hi Adrienne,
>
> The texlive-generic-recommended transitional package has been dropped from
> texlive-base in sid.  Please update your build-dependency to
> texlive-plain-generic instead.
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>

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#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#842943: signap-desktop now built with electron

[Christopher Thompson]

I would like just voice my support for Debian going ahead with packaging
this project, if someone still has the interest (I do not have the
know-how myself).

An issue has been open since August 3 and continues to garner attention
from the community which is a bug preventing old-stable (and downstream
distros) from working AT ALL with current AND past Signal clients (as
the old versions have been blocked). It is my understanding this issue
is eminently addressable by packaging. There has so far been no response
from Signal maintainers, despite being directly addressed in the issue
multiple times. Additionally, arguments made by the Signal developers
not to have external packaging have now been proven incorrect, in large
part due to the existence/lack of attention to this issue.

I managed to get it working fine with the workaround by "scarf" - so, it
can be made to work by performing one of the suggested build or library
substitution procedures. In summary: no version available via packaging
works, or has worked for as much as three months now (I don't know how
recently the old versions stopped working).

Please see:
https://github.com/signalapp/Signal-Desktop/issues/2604

Thank you,
Chris

Bug#905373: Consider using u2f-hidraw-policy to discover U2F devices?

[Will Thompson]

Package: libu2f-udev
Version: 1.1.6-1

Hi,

libu2f-udev makes U2F devices accessible to users by matching hidraw
devices against a list of vendor/product pairs. This means that any
newly-released device will not work until libu2f-host is updated to add it
to this list.

I noticed that Fedora takes a different approach: u2f-hidraw-policy[0] uses
the discovery mechanism defined in the U2F HID spec[1] to determine whether
a hidraw device supports U2F, and if so sets ID_U2F_TOKEN=1 and
ID_SECURITY_TOKEN=1 on it. systemd ships a rule[2] which matches
ID_SECURITY_TOKEN=1 and applies the "uaccess" tag, just as the rules
shipped by libu2f-udev do. This has the nice property that newly-released
devices work immediately, rather than needing an update to libu2f-host.

Is there some reason to prefer the libu2f-udev approach? While looking into
making U2F tokens work out of the box on Endless OS, I put together some
packaging for u2f-hidraw-policy[3]. It seems to work fine, and the approach
seems cleaner than the list-of-devices approach. However, we generally
prefer to follow Debian where possible, so I'm wondering if there's any
interest in Debian adopting this mechanism!

Thanks,

– Will

[0] https://github.com/amluto/u2f-hidraw-policy/
[1]
https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-hid-protocol-ps-20141009.html#hid-report-descriptor-and-device-discovery
[2]
https://salsa.debian.org/systemd-team/systemd/blob/master/src/login/70-uaccess.rules#L53-54
[3] https://salsa.debian.org/wjt-guest/u2f-hidraw-policy

Bug#883615: Who is this

[Cherie Thompson]

What did I buy

Bug#882159: Who are you?

[Brandi Thompson]

Why are you using my email to do illegal activity? I have many random money
based incoming emails that I have no clue what or why they are being sent.
And it's because of you

Bug#882051: Info received (Welcome To Amazon..jndu)

[Kimberly Thompson]

I didn't send any messages

On Nov 19, 2017 11:51 AM, "Debian Bug Tracking System" <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Release Team 
>
> If you wish to submit further information on this problem, please
> send it to 882...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 882051: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882051
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#882051: Welcome To Amazon..jndu

[Kimberly Thompson]

Hello, what is this? Kimberly Thompson, kathompson4...@gmail.com

On Nov 19, 2017 11:45 AM, "final notice" <p...@debian.org> wrote:

important information

<http://shineslim.com/cl/r-S5K5SI2NHJPS13I2CS1E3O5SE3NS0S0S0S15S2SBSCCS21FS21OSA>

<http://shineslim.com/cl/ua-S5K5SI2NHJPS13I2CS1E3O5SE3NS0S0S0S15S2SBSCCS21FS21OSA>

<http://shineslim.com/cl/op-S5K5SI2NHJPS13I2CS1E3O5SE3NS0S0S0S15S2SBSCCS21FS21OSA>
















































































Package: release.debian.org Severity: normal User:
release.debian@packages.debian.org Usertags: binnmu debhelper 10.10.7
fixed a regression in debhelper 10.10.6 that prevented dbgsym packages from
being generated. There are probably several packages affected but I am not
aware of any easy mechanism to determine which packages were built against
debhelper 10.10.6 so I've just included a binNMU request for the two
packages I'm aware of that were definitely affected by this. debhelper
(10.10.7) unstable; urgency=medium * dh_strip: Fix a regression that caused
debug symbols for executables to be discarded instead of included into
debug packages. nmu xdg-desktop-portal_0.8-3 . amd64 arm64 i386 mips64el
mips powerpc ppc64el s390x . unstable . -m "Rebuild to include dbgsym
packages after debhelper 10.10.7 fix" nmu xdg-desktop-portal-gtk_0.7-3 .
amd64 arm64 i386 mips64el mips powerpc ppc64el s390x . unstable . -m
"Rebuild to include dbgsym packages after debhelper 10.10.7 fix" -- bye,
pabs https://wiki.debian.org/PaulWise

Bug#862702: patch

[David A Thompson]

This should might serve as a starting point for addressing the issue.

--- /usr/bin/2vcard 2015-12-13 03:10:38.0 -0800
+++ /home/thomp/computing/mail-email/clients/mutt/2vcard/2vcard-0.6/src/2vcard  
2017-05-15 11:54:52.0 -0700
@@ -369,8 +369,39 @@
 
endVcard();
 
+   } elsif (m/^alias\s+(.*)\s+(.*@.*)/) {
+   # alias nick email@address
+   print STDERR "Now we're getting somewhere...:\n";
+
+   # take a stab at what might be a reasonable name... maybe 
warn that we don't have anything reliable for a name?
+   my @name = ($1);
+   my $x;
+   
+   beginVcard($1);
+   
+   foreach $x (reverse @name) {
+   print WRITE "$x;";
+   }
+   print WRITE "\n";
+   
+   $x = $2;
+   if ($x =~ m/(.*,.*)/) {
+   my @emails = split /,/, $2;
+   foreach $x (@emails) {
+   $x =~ s/[<>]//g;
+   writeEmail($x);
+   }
+   } else {
+   $x =~ s/[<>]//g;
+   writeEmail($x);
+   }
+   
+   endVcard();
+
+
+   
} else {
-   warnFormat($_);
+   warnFormat($_);
}
}
 }

Bug#862702: 2vcard: fails to handle mutt aliases with only nickname and email

[David A Thompson]

Package: 2vcard
Version: 0.6-1
Severity: normal

Dear Maintainer,

I recently used 2vcard with a file with a number of lines of the form

alias joejoe a...@glurpies.com

Given that alias commands of this form are documented 
(https://dev.mutt.org/trac/wiki/MuttGuide/Aliases includes a simple example 
with the 'mumon' alias), I had expected 2vcard to handle the lines readily (as 
mutt does), but instead 2vcard sent a bunch of 'Skipping ill-formatted line...' 
warnings to the console. 

The underlying issue is that neither regex expression in parseMutt matches 
alias lines of this form so 2vcard calls warnFormat.


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

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

Versions of packages 2vcard depends on:
ii  perl  5.20.2-3+deb8u6

2vcard recommends no packages.

2vcard suggests no packages.

-- no debconf information

Bug#862381: xfce4: Kisok mode not working

[Bill Thompson]

Package: xfce4
Version: 4.12.3
Severity: normal

Dear Maintainer,
 I have installed a new build of Debian testng (Strech) to be used as a public 
computer. I have used XFCE4 in kiosk mode in previous Debian systems. In the 
current testing build, the file at /etc/xdg/xfce4/kiosk/kioskrc appearsto have 
no effect on the system. No matter how this file is configured, user accounts 
are able to modify the desktop, menus, and panels. 

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce3.2.0-2
ii  libxfce4ui-utils 4.12.1-2
ii  orage4.12.1-3
ii  thunar   1.6.11-1
ii  xfce4-appfinder  4.12.0-2
ii  xfce4-panel  4.12.1-2
ii  xfce4-pulseaudio-plugin  0.2.4-1
ii  xfce4-session4.12.1-5
ii  xfce4-settings   4.12.1-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.3-3
ii  xfwm44.12.4-1

Versions of packages xfce4 recommends:
ii  desktop-base  9.0.2
ii  tango-icon-theme  0.8.90-6
ii  thunar-volman 0.8.1-2
ii  xfce4-notifyd 0.3.4-1
ii  xorg  1:7.7+19

Versions of packages xfce4 suggests:
pn  gtk3-engines-xfce
ii  xfce4-goodies4.12.3
ii  xfce4-power-manager  1.4.4-4

-- no debconf information

Bug#855224: autojump: README specifies autojump.sh for zsh

[David A Thompson]

Package: autojump
Version: 21.7.1-1
Severity: minor

Dear Maintainer,

   * What led up to the situation?

I decided I wanted to use autojump with zsh.

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

Ineffective: follow the README and added, to ~/.zshrc,
.. /usr/share/autojump/autojump.sh

Doing this results in

/usr/share/autojump/autojump.bash:13: command not found: complete
/usr/share/autojump/autojump.bash:52: = not found

Effective: added, to ~/.zshrc,
.. /usr/share/autojump/autojump.zsh

This allowed autojump to work fine in zsh.



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

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

Versions of packages autojump depends on:
ii  python3  3.4.2-2

autojump recommends no packages.

autojump suggests no packages.

-- no debconf information

Bug#809611: d-i fails to boot on HP mv2120

[Mike Thompson]

OK Martin, that image worked.  I did a full install of Debian Stretch from
it.  Below is the output at the tail end of bootup and login.


Debian GNU/Linux stretch/sid backup ttyS0

backup login: root
Password:
Linux backup 4.6.0-1-marvell #1 Debian 4.6.4-1 (2016-07-18) armv5tel


The 0x60 change also still continues to boot my existing Debian Jessie
install.

Thanks for the work you do to keep these old pieces of NAS hardware working.

Mike

On Sat, Aug 6, 2016 at 12:37 PM, Martin Michlmayr <t...@cyrius.com> wrote:

> Hi Mike,
>
> * Mike Thompson <mpthomp...@gmail.com> [2016-08-05 20:23]:
> > The good news is that given the load address change from 0x40 to
> > 0x60 allowed the MV2120 to boot into the ssh based installer.
>
> Great!
>
> > The bad news is the installed failed from what looked like some sort of
> > segmentation faults in the installer from the looks of the logs which I
> > included below.
>
> I wonder if this is the same as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833599
>
> Can you please test this image:
> http://ftp.nl.debian.org/debian/dists/testing/main/
> installer-armel/current/images/orion5x/network-
> console/hp/mv2120/netboot.img
>
> --
> Martin Michlmayr
> http://www.cyrius.com/
>

Bug#809611: d-i fails to boot on HP mv2120

[Mike Thompson]

1:50:27 netcfg[1396]: DEBUG: Success!
Aug  6 21:50:28 main-menu[989]: (process:1395): udhcpc (v1.22.1) started
Aug  6 21:50:28 main-menu[989]: (process:1395): Sending discover...
Aug  6 21:50:28 main-menu[989]: (process:1395): Sending select for
192.168.0.8...
Aug  6 21:50:28 main-menu[989]: (process:1395): Lease of 192.168.0.8
obtained, lease time 3600
Aug  6 21:50:28 main-menu[989]: DEBUG: resolver (libgcc1): package doesn't
exist (ignored)
Aug  6 21:50:28 main-menu[989]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:50:28 main-menu[989]: INFO: Menu item 'network-console' selected
Aug  6 21:50:49 sshd[1498]: Server listening on 0.0.0.0 port 22.
Aug  6 21:50:49 apt-install: Queueing package openssh-server for later
installation
Aug  6 21:50:55 sshd[1516]: WARNING: /etc/ssh/moduli does not exist, using
fixed modulus
Aug  6 21:51:05 sshd[1516]: Accepted password for installer from
192.168.0.160 port 56579 ssh2
Aug  6 21:51:05 sshd[1518]: lastlog_openseek: Couldn't stat
/var/log/lastlog: No such file or directory
Aug  6 21:51:05 sshd[1518]: lastlog_openseek: Couldn't stat
/var/log/lastlog: No such file or directory
Aug  6 21:51:07 debconf: Setting debconf/language to en
Aug  6 21:51:11 debconf: Setting debconf/priority to low
Aug  6 21:51:11 debconf: Setting debconf/language to en
Aug  6 21:51:11 main-menu[1531]: DEBUG: resolver (libgcc1): package doesn't
exist (ignored)
Aug  6 21:51:11 main-menu[1531]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:51:11 main-menu[1531]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:51:13 main-menu[1531]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:51:13 main-menu[1531]: INFO: Menu item 'choose-mirror' selected
Aug  6 21:51:13 main-menu[1531]: WARNING **: Unable to set title for
choose-mirror.
Aug  6 21:51:14 anna-install: Queueing udeb apt-mirror-setup for later
installation
Aug  6 21:51:14 main-menu[1531]: (process:1557): Segmentation fault
Aug  6 21:51:14 main-menu[1531]: WARNING **: Configuring 'choose-mirror'
failed with error code 139
Aug  6 21:51:14 main-menu[1531]: WARNING **: Menu item 'choose-mirror'
failed.
Aug  6 21:51:14 main-menu[1531]: WARNING **: Unable to set title for
choose-mirror.
Aug  6 21:51:14 main-menu[1531]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:51:28 main-menu[989]: DEBUG: resolver (libgcc1): package doesn't
exist (ignored)
Aug  6 21:51:28 main-menu[989]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:51:28 main-menu[989]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:51:28 main-menu[989]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:51:28 main-menu[989]: INFO: Menu item 'choose-mirror' selected
Aug  6 21:51:28 main-menu[989]: WARNING **: Unable to set title for
choose-mirror.
Aug  6 21:51:28 main-menu[989]: (process:1587): Segmentation fault
Aug  6 21:51:28 main-menu[989]: WARNING **: Configuring 'choose-mirror'
failed with error code 139
Aug  6 21:51:28 main-menu[989]: WARNING **: Menu item 'choose-mirror'
failed.
Aug  6 21:51:28 main-menu[989]: WARNING **: Unable to set title for
choose-mirror.
Aug  6 21:51:28 main-menu[989]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:52:22 main-menu[989]: INFO: Modifying debconf priority limit from
'high' to 'medium'
Aug  6 21:52:22 debconf: Setting debconf/priority to medium
Aug  6 21:52:22 main-menu[989]: DEBUG: resolver (libgcc1): package doesn't
exist (ignored)
Aug  6 21:52:23 main-menu[989]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:52:23 main-menu[989]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:52:34 main-menu[989]: INFO: Falling back to the package
description for choose-mirror
Aug  6 21:52:34 main-menu[989]: INFO: Menu item 'save-logs' selected
Aug  6 21:53:08 kernel: [  218.089782] TCP: request_sock_TCP: Possible SYN
flooding on port 80. Sending cookies.  Check SNMP counters.
Aug  6 21:53:25 kernel: [  234.906280] TCP: request_sock_TCP: Possible SYN
flooding on port 80. Sending cookies.  Check SNMP counters.
-


On Sat, Jul 30, 2016 at 7:23 PM, Martin Michlmayr <t...@cyrius.com> wrote:

> Mike, can you please give these instructions a go?  This is what I
> intend to post to the mv2120 list.
>
> --
>
> Mike Thompson reported that Debian stretch (the upcoming Debian 9)
> doesn't boot on the HP mv2120 anymore.  I don't know how many Debian
> users are left who run Debian on their mv2120.  I gave away my device
> several years ago.  Recently I bought an mv2120 from eBay in order to
> debug this issue.
>
> While I found a solution, it requires users to change a setting on their
> device.  Please make sure to make this change, otherwise your device
> will no longer b

Bug#831529: libavcodec57: broken option parsing with LANGs with decimal mark different from .

[Mark Thompson]

This is now fixed with the same patch from Carl in ffmpeg master 

 and the 3.1 release branch 
.
  3.1.2 should be released soon.

Thank you for the report, and apologies for the breakage.

- Mark

PS:  It is probably worth noting that there may be other issues (though less 
fatal than this one) when lav* is used with a non-C locale, due to use of 
strtod() and related locale-dependent functions.  Making use of different 
properties of a non-C locale (such as a non-'.' decimal_point in LC_NUMERIC) 
should probably be considered an unsupported configuration with ffmpeg (the 
utility) at least, and there may be steps taken in future to make the behaviour 
more consistent.

Bug#809611: d-i fails to boot on HP mv2120

[Mike Thompson]

Hi Martin,

Sure.  It may take me a few days to get some time, but I'll give it a try
and let you know how it goes.

Mike

On Sat, Jul 30, 2016 at 7:23 PM, Martin Michlmayr <t...@cyrius.com> wrote:

> Mike, can you please give these instructions a go?  This is what I
> intend to post to the mv2120 list.
>
> --
>
> Mike Thompson reported that Debian stretch (the upcoming Debian 9)
> doesn't boot on the HP mv2120 anymore.  I don't know how many Debian
> users are left who run Debian on their mv2120.  I gave away my device
> several years ago.  Recently I bought an mv2120 from eBay in order to
> debug this issue.
>
> While I found a solution, it requires users to change a setting on their
> device.  Please make sure to make this change, otherwise your device
> will no longer boot when you upgrade to Debian 9.
>
> The new settings are compatible with Debian 8 (jessie) and Debian 9
> (stretch), so I suggest you make the changes now.
>
> If you have serial console access to the mv2120, you can run some
> commands in u-boot.  Simply interrupt the boot process by pressing a key
> and type the following:
>
> setenv loadAddr 0x060
> setenv bootcmd 'bootext2 0,1:1,2 0x060 /boot/uImage /dev/sda
> /dev/sdb'
> saveenv
>
> If you don't have a serial console, you can make the changes from within
> Debian.  Run the following commands:
>
> cat >/etc/fw_env.config < /dev/mtd0   0x0 0x1000 0x2
> EOF
>
> fw_setenv loadAddr 0x060
> fw_setenv bootcmd "bootext2 0,1:1,2 0x060 /boot/uImage /dev/sda
> /dev/sdb"
>
> This will create a config file so you can modify the u-boot environment
> and use fw_setenv to update two boot variables.
>
> Once you made the changes, upgrades to Debian 9 should work fine and you
> can also use the Debian installer if you want to perform a new
> installation.
>
> Please note that Debian 9 will be the last release to support the HP
> mv2120.
>
> --
>
> Note that the installer from
>
> https://d-i.debian.org/daily-images/armel/daily/orion5x/network-console/hp/mv2120/netboot.img
> will not boot right now with these settings.  However, you can change the
> loadAddr to 0x050 and it should work.  I just commited a fix in Git so
> it should work in a day or so with 0x060.
>
> --
> Martin Michlmayr
> http://www.cyrius.com/
>

Bug#824082: r-cran-tm: missing dependencies on r-cran-nlp and r-cran-slam

[Evan Thompson]

Package: r-cran-tm
Version: 0.6-2-2
Severity: serious
Justification: Policy 3.5

Dear Maintainer,

When attempting to load tm in R:

> library(tm)
Error: package ‘NLP’ required by ‘tm’ could not be found

Installing r-cran-nlp solves this first issue, but then:

> library(tm)
Loading required package: NLP
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
  there is no package called ‘slam’
Error: package or namespace load failed for ‘tm’

Installing r-cran-slam solves the second issue.

Regards,
-- Evan Thompson



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5-3.dmz.2-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages r-cran-tm depends on:
ii  libc6  2.22-7
ii  r-base-core [r-api-3]  3.3.0-1

r-cran-tm recommends no packages.

r-cran-tm suggests no packages.

-- no debconf information

Bug#822865: wmii: Fails to load xft fonts unless libxft-dev is installed

[Corey Thompson]

Package: wmii
Version: 3.10~20120413+hg2813-8
Severity: Minor

1. $ apt-get install wmii
2. (launch wmii)
3. $ wmiir xwrite /ctl "font xft:DejaVu Sans Mono:size=10"
wmiir: fatal: cannot write file '/ctl': can't load font

4. $ apt-get install libxft-dev
5. (restart wmii)
6. $ wmiir xwrite /ctl "font xft:DejaVu Sans Mono:size=10"
(success)

On further investigation, it turns out that wmii calls
dlopen("libXft.so", RTLD_LAZY).  I guess that either this should be
patched to find the correct libXft.so.x.y.z, or libxft-dev should be
added as a recommended package of wmii.

Bug#820409: r-cran-dplyr: missing dependency on r-cran-assertthat

[Evan Thompson]

Package: r-cran-dplyr
Version: 0.4.3-1
Severity: serious
Justification: Policy 3.5

Dear Maintainer,

When attempting to load dplyr in R:

> library(dplyr)
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
  there is no package called ‘assertthat’
Error: package or namespace load failed for ‘dplyr’

Installing r-cran-assertthat solves the issue.

Regards,
-- Evan Thompson



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4-6.dmz.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages r-cran-dplyr depends on:
ii  libc6  2.22-5
ii  libgcc11:5.3.1-13
ii  libstdc++6 5.3.1-13
ii  r-base-core [r-api-3]  3.2.4.20160406-1
ii  r-cran-dbi 0.3.1-1
ii  r-cran-magrittr1.5-1

r-cran-dplyr recommends no packages.

r-cran-dplyr suggests no packages.

-- no debconf information

Bug#809480: Typo in CVS document for "suck" command.

[Keith Thompson]

Package: cvs
Version: 1.12.13+real-12

The "info" documentation for the "cvs suck" command contains the following:

   Locates the file module/path,v or module/pa/Attic/th,v and
downloads it raw as RCS comma-v file.

The string "/Attic/" appears to have been inserted in the wrong place.

The correct text is:

   Locates the file module/path,v or module/Attic/path,v and downloads
it raw as RCS comma-v file.

The "suck" command is apparently a Debian-specific addition to CVS; it
does not appear in CVS 1.12.13.

-- 
Keith Thompson <keith.s.thomp...@gmail.com>

Bug#780773: Please backport EDAC_IE31200 to Linux 3.16.x

[Adam Thompson]

As far as I can tell, this is still outstanding - I have a newer server that 
does not yet have any access to ECC counters, status or alerts, under Debian 8.

IIRC, I had verified that with a newer kernel, it “just worked” once I loaded 
the appropriate EDAC modules… I think I used RHEL6 with an updated kernel to 
verify that, not sure now.






-- 
-Adam Thompson
 athom...@athompso.net






From: Adam D. Barratt
Sent: ‎Thursday‎, ‎June‎ ‎11‎, ‎2015 ‎06‎:‎04
To: Ben Hutchings
Cc: Debian release team, 780...@bugs.debian.org





On 2015-04-07 0:17, Ben Hutchings wrote:
 Bug #780773 requests backporting a new EDAC (Error Detection And
 Correction) driver that is wanted on some Intel-based servers.  It 
 seems
 to be simple to backport to 3.16, but I'm not sure whether it meets the
 release criteria.
 
 EDAC drivers are not needed for hardware enablement, but they are 
 needed
 for logging of correctable ECC errors and detailed information about
 uncorrectable ECC errors, which is important for highly reliable
 systems.
 
 Please can I have an ack or nak from the release team?

Assuming that this request is still current and wasn't just pre-release, 
this sounds like something I'd be happy to defer to your judgement on.

Regards,

Adam

-- 
To unsubscribe, send mail to 780773-unsubscr...@bugs.debian.org.

Bug#780773: (no subject)

[Adam Thompson]

+1 for getting this module backported to Jessie.  We're replacing 
existing servers with E3-v3 based chips, and didn't realize we needed a 
bleeding-edge kernel to monitor ECC faults.  As it stands, I have no 
idea whether the XFS kernel panics are because of bad memory or because 
of bad code.

-Adam


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

Bug#670112: DBus support

[Jamie Thompson]

I've just spent a few hours troubleshooting this for a friend of mine. 
This really needs to get sorted - as-is Jack2 does not work in headless 
environments, purely because of this.


I switched him back to Jack1 to let him move on, but an alternative 
solution I've found suggests:

eval |dbus-launch --auto-syntax|
export DBUS_SESSION_BUS_PID DBUS_SESSION_BUS_ADDRESS
prior to using jack_control. This will initialize dbus session and 
make jack happy

...but I can't comment as I've not tried that.

This 'important' bug has been open nearly 3 years...

Bug#768637: shotwell: Video thumbnails stopped working

[John Thompson]

Package: shotwell
Version: 0.20.1-1
Severity: normal

Hi,

After the upgrade from shotwell 0.18.1-2 to 0.20.1-1, video thumbnails
stopped working. When I first started shotwell after upgrading to
0.20.1-1 all the video thumbnails gradually changed to a default
image, and they've stayed that way.

I discovered that if I run /usr/lib/shotwell-video-thumbnailer
manually against one of my video files it segfaults.

I gathered some gdb output after looking at
https://wiki.debian.org/HowToGetABacktrace, which can be found below.

I'm not very familiar with gdb though so I don't know if the backtrace
is useful. You can download a short video that exhibits the problem
for me at http://waste.org/~jello/00087.MTS also if that's helpful.

Please let me know if there's anything else I can do to help with this.

Thanks much

Backtrace:

$ gdb /usr/lib/shotwell-video-thumbnailer
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from /usr/lib/shotwell-video-thumbnailer...Reading
symbols from 
/usr/lib/debug/.build-id/55/fedee4a9aeb3deb3a69556bae9977ac06e9970.debug...done.
done.
(gdb) set pagination 0
(gdb) run 00087.MTS
Starting program: /usr/lib/shotwell-video-thumbnailer 00087.MTS
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New Thread 0x7fffedc3b700 (LWP 29166)]
[New Thread 0x7fffecb98700 (LWP 29167)]
[New Thread 0x7fffe7fff700 (LWP 29168)]
[New Thread 0x7fffe77fe700 (LWP 29169)]
[New Thread 0x7fffd930a700 (LWP 29170)]
[New Thread 0x7fffd8b09700 (LWP 29171)]
[New Thread 0x7fffd3fff700 (LWP 29172)]
[New Thread 0x7fffd37fe700 (LWP 29173)]
[New Thread 0x7fffd2ffd700 (LWP 29174)]
[New Thread 0x7fffd27fc700 (LWP 29175)]
[New Thread 0x7fffd1ffb700 (LWP 29176)]
[New Thread 0x7fffd17fa700 (LWP 29177)]

Program received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36
36  ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file
or directory.
(gdb) thread apply all bt full

Thread 13 (Thread 0x7fffd17fa700 (LWP 29177)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x7fffe5c7a1dd in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.56
No symbol table info available.
#2  0x74c380a4 in start_thread (arg=0x7fffd17fa700) at
pthread_create.c:309
__res = optimized out
pd = 0x7fffd17fa700
now = optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736708192000,
1047605950388036713, 1, 140737354125408, 140736884846912,
140736708192000, -1047514689946852247, -1047595400016632727},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev
= 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = optimized out
pagesize_m1 = optimized out
sp = optimized out
freesize = optimized out
__PRETTY_FUNCTION__ = start_thread
#3  0x7496ccbd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

Thread 12 (Thread 0x7fffd1ffb700 (LWP 29176)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x7fffe5c7a1dd in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.56
No symbol table info available.
#2  0x74c380a4 in start_thread (arg=0x7fffd1ffb700) at
pthread_create.c:309
__res = optimized out
pd = 0x7fffd1ffb700
now = optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736716584704,
1047605950388036713, 1, 140737354125408, 140736884846912,
140736716584704, -1047513588824611735, -1047595400016632727},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev
= 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = optimized out
pagesize_m1 = optimized out
sp = optimized out
freesize = optimized out
__PRETTY_FUNCTION__ = start_thread
#3  0x7496ccbd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

Thread 11 (Thread 0x7fffd27fc700 (LWP 29175)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x7fffe5c7a1dd in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.56
No 

Bug#748714: Unpaper: allow negative border margins, add sheet-size option

[Evan Thompson]

Package: gscan2pdf
Version: 1.2.5-1
Severity: wishlist
Tags: patch

In the Unpaper module, please (a) allow for negative border margins to be set
and (b) add support for the '--sheet-size' option.  The combination of these
two features allows for completely clean (no residual borders, pages properly
sized and aligned) output from my ScanSnap S1300 from within gscan2pdf.

The attached patch (poorly) implements the above request.



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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gscan2pdf depends on:
ii  imagemagick  8:6.7.7.10+dfsg-2
ii  libconfig-general-perl   2.56-1
ii  libgoo-canvas-perl   0.06-2
ii  libgtk2-ex-simple-list-perl  0.50-2
ii  libgtk2-imageview-perl   0.05-2
ii  libhtml-parser-perl  3.71-1+b1
ii  liblist-moreutils-perl   0.33-2
ii  liblocale-gettext-perl   1.05-8
ii  liblog-log4perl-perl 1.43-1
ii  libpdf-api2-perl 2.021-1
ii  libproc-processtable-perl0.50-1
ii  libreadonly-perl 1.04-1
ii  librsvg2-common  2.40.2-1
ii  libsane-perl 0.05-2+b1
ii  libset-intspan-perl  1.19-1
ii  libtiff-tools4.0.3-8
ii  libtry-tiny-perl 0.22-1
ii  perlmagick   8:6.7.7.10+dfsg-2
ii  sane-utils   1.0.24-1.1+b1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin  3.5.25.4-4
ii  libgtk2-ex-podviewer-perl  0.18-1
ii  sane   1.0.14-9
ii  tesseract-ocr  3.03.03-1
ii  unpaper0.4.2-1
ii  xdg-utils  1.1.0~rc1+git20111210-7.1

gscan2pdf suggests no packages.
--- Unpaper.pm.diverted	2014-05-17 06:52:22.0 -0500
+++ Unpaper.pm	2014-05-19 15:43:33.251895510 -0500
@@ -59,6 +59,25 @@
},
default = 'single',
   },
+  'sheet-size' = {
+   type= 'ComboBox',
+   string  = $d-get('Sheet size'),
+   options = {
+none = {
+ string = $d-get('(none)'),
+ tooltip = $d-get(''),
+},
+letter = {
+ string = $d-get('Letter'),
+ tooltip = $d-get(''),
+},
+legal = {
+ string  = $d-get('Legal'),
+ tooltip = $d-get(''),
+},
+   },
+   default = 'none',
+  },
   'output-pages' = {
type= 'SpinButton',
string  = $d-get('# Output pages'),
@@ -184,10 +203,11 @@
  tooltip = $d-get(
 'Vertical distance to keep from the sheet edge when aligning a border area.'
  ),
- min   = 0,
- max   = 1000,
- step  = 1,
- order = 0,
+ min = -1000,
+ max = 1000,
+ step= 1,
+ order   = 0,
+ default = 0,
 },
 horizontal = {
  type= 'SpinButton',
@@ -195,10 +215,11 @@
  tooltip = $d-get(
 'Horizontal distance to keep from the sheet edge when aligning a border area.'
  ),
- min   = 0,
- max   = 1000,
- step  = 1,
- order = 1,
+ min = -1000,
+ max = 1000,
+ step= 1,
+ order   = 1,
+ default = 0,
 },
},
   },
@@ -234,6 +255,7 @@
 
  # Layout ComboBox
  my $combobl  = $self-add_widget( $vbox, $options, 'layout' );
+ my $combobs  = $self-add_widget( $vbox, $options, 'sheet-size' );
  my $outpages = $self-add_widget( $vbox, $options, 'output-pages' );
  $combobl-signal_connect(
   changed = sub {
@@ -541,7 +563,9 @@
   }
   else {
if ( defined $default-{$option} ) {
-push @items, --$option $default-{$option};
+if ( not $default-{$option} eq 'none' ) {
+ push @items, --$option $default-{$option};
+}
}
   }
  }

Bug#745903: pymsnt: Package unable to start after upgrades. Dependencies need upating perhaps?

[Jamie Thompson]

Package: pymsnt
Version: 0.11.3+hg224-1
Severity: normal

Dear Maintainer,

Just noticed my jabberd log filling up my log partition due to pymsnt not 
running, and when
I tried to start it I got this:

 Starting MSN transport for Jabber: Traceback (most recent call last):
   File /usr/share/pymsnt/PyMSNt.py, line 14, in module
 main.main()
   File /usr/share/pymsnt/src/main.py, line 401, in main
 app = App()
   File /usr/share/pymsnt/src/main.py, line 333, in __init__
 twistd.daemonize(reactor, os)
 AttributeError: 'module' object has no attribute 'daemonize'
 invoke-rc.d: initscript pymsnt, action restart failed.

...so I suspect my recent Python upgrades broke the API and the dependecies 
need revisiting.

-- System Information:
Debian Release: jessie/sid
Architecture: i386 (i686)

Kernel: Linux 3.10-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pymsnt depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.18
ii  python-crypto2.6.1-4
ii  python-openssl   0.13.1-2
ii  python-twisted   13.2.0-1
pn  python:any   none

Versions of packages pymsnt recommends:
ii  python-imaging  2.3.0-2

Versions of packages pymsnt suggests:
pn  ejabberd | jabberd2  none

-- Configuration Files:
/etc/pymsnt.conf.xml changed [not included]

-- no debconf information


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

Bug#745903: Acknowledgement (pymsnt: Package unable to start after upgrades. Dependencies need upating perhaps?)

[Jamie Thompson]

I'm no Python coder, but according to some other info I've found, 
Twisted 13.2 removed twistd.daemonize, which would explain the issue. :)



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

Bug#745770: pptpd needs recompiling against latest version of ppp

[Jamie Thompson]

Package: pptpd
Version: 1.4.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

As reported here: https://bugs.archlinux.org/task/39112, I can no longer connect
to my pptp server since upgrading ppp to 2.4.6 a few days ago.

The error in my logs is fairly clear as to why:
 Apr 24 22:46:07 srv pptpd[29775]: CTRL: Client w.x.y.z control connection 
 started
 Apr 24 22:46:07 srv pptpd[29775]: CTRL: Starting call (launching pppd, 
 opening GRE)
 Apr 24 22:46:07 srv pppd[29776]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so is 
 for pppd version 2.4.5, this is 2.4.6
 Apr 24 22:46:07 srv pptpd[29775]: GRE: read(fd=6,buffer=b776e480,len=8196) 
 from PTY failed: status = -1 error = Input/output error, usually caused by 
 unexpected termination of pppd, check option syntax and pppd logs
 Apr 24 22:46:07 srv pptpd[29775]: CTRL: PTY read or GRE write failed 
 (pty,gre)=(6,7)
 Apr 24 22:46:07 srv pptpd[29775]: CTRL: Reaping child PPP[29776]
 Apr 24 22:46:07 srv pptpd[29775]: CTRL: Client w.x.y.z control connection 
 finished



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

Kernel: Linux 3.10-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pptpd depends on:
ii  bcrelay   1.4.0-1
ii  libc6 2.18-4
ii  libwrap0  7.6.q-24
ii  netbase   5.2
ii  ppp   2.4.6-2

pptpd recommends no packages.

pptpd suggests no packages.

-- Configuration Files:
/etc/ppp/pptpd-options changed [not included]
/etc/pptpd.conf changed [not included]

-- no debconf information


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

Bug#728330: Fails to read /etc/network/interfaces with source-directory

[William Thompson]

Package: augeas-lenses
Version: 1.0.0-1.1
Severity: normal

When /etc/network/interfaces contains a line source-directory, it failes.

Here's the output of augtool ls /files/etc/network/interfaces when the line
is commented out:

$ augtool ls /files/etc/network/interfaces
#comment[1] = interfaces(5) file used by ifup(8) and ifdown(8)
#comment[2] = Include files from /etc/network/interfaces.d:
#comment[3] = source-directory /etc/network/interfaces.d
auto[1]/ = (none)
iface[1]/ = lo
auto[2]/ = (none)
iface[2]/ = br0
auto[3]/ = (none)
remaining removed
$

Here's the same thing with the line is not commented.
$ augtool ls /files/etc/network/interfaces
$ 

Shows nothing.  Same goes for augtool ls /files/etc/network

I found this because virt-manager wouldn't show my network bridges (virsh
iface-list returned an error)

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

Kernel: Linux 3.11.6 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

augeas-lenses depends on no packages.

augeas-lenses recommends no packages.

Versions of packages augeas-lenses suggests:
pn  augeas-doc  none

-- no debconf information


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

Bug#701136: Needed module cli.py appears to be deliberately excluded

[Ryan C. Thompson]

In the changelog for the latest release, we have: Move cli.py from 
smbios-utils to python-smbios/examples, and in debian/rules, we have:


 $(RM) -v debian/smbios-utils/usr/share/smbios-utils/cli.pyc
 $(RM) -v debian/smbios-utils/usr/share/smbios-utils/cli.pyo
 $(RM) -v debian/smbios-utils/usr/share/smbios-utils/cli.py

Thus it appears that the cli.py module was deliberately excluded from 
the latest package version. Could re revert these changes, since this 
breaks all the command-line tools in the package?



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

Bug#709099: %S substitution no longer works for default service.

[William Thompson]

Package: samba
Version: 2:3.6.15-1
Severity: normal

I copied the smb.conf from the old machine had 3.5.15 and worked fine.

Here's the snippit from my config

[global]
default service = defcdserv

[defcdserv]
writeable = no
browseable = no
locking = no
path = /cdserv/mount/%S
public = yes
preexec = /usr/local/sbin/mount-cdserv.sh %S
postexec = /usr/local/sbin/umount-cdserv.sh %S

Before, %S would get replaced by the service that the user typed in.  Now, %S
is always replaced by defcdserv.  This essentially breaks the use of
default service

Seems someone has reported this same issue to samba's bug track.
https://bugzilla.samba.org/show_bug.cgi?id=8935

-- System Information:
Debian Release: wheezy/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.3.6 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages samba depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.45
ii  dpkg   1.16.10
ii  libacl12.2.51-8
ii  libattr1   1:2.4.46-8
ii  libc6  2.17-1
ii  libcap21:2.22-1.1
ii  libcomerr2 1.42.5-1.1
ii  libcups2   1.5.3-5
ii  libgssapi-krb5-2   1.10.1+dfsg-5
ii  libk5crypto3   1.10.1+dfsg-5
ii  libkrb5-3  1.10.1+dfsg-5
ii  libldap-2.4-2  2.4.31-1
ii  libpam-modules 1.1.3-7.1
ii  libpam-runtime 1.1.3-7.1
ii  libpam0g   1.1.3-7.1
ii  libpopt0   1.16-7
ii  libtalloc2 2.0.8-0.1
ii  libtdb11.2.10-2
ii  libwbclient0   2:3.6.15-1
ii  lsb-base   4.1+Debian7
ii  procps 1:3.3.3-2
ii  samba-common   2:3.6.15-1
ii  update-inetd   4.43
ii  zlib1g 1:1.2.8.dfsg-1

Versions of packages samba recommends:
ii  logrotate  3.8.1-4
pn  tdb-tools  none

Versions of packages samba suggests:
pn  ctdb  none
pn  ldb-tools none
pn  openbsd-inetd | inet-superserver  none
pn  smbldap-tools none
pn  winbind   none

-- debconf information excluded


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

Bug#700273: nvidia-glx-legacy-173xx: cant configure dual screens or run nvidia-settings

[josh thompson]

Package: nvidia-glx-legacy-173xx
Severity: normal

nvidia 173 dont work with nvidia settings (i have dual screens and cant config
if 173 dont recognize settings mannager



-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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