Bug#1072809: mk-build-deps: When --host-arch is specified, build dependencies with the "all" arch don't work

[Allen Ding]

Package: devscripts
Version: 2.23.4+deb12u1
Severity: normal
X-Debbugs-Cc: al...@ading.dev

When --host-arch is passed into mk-build-deps, the generated package's
dependencies always use the specified architecture. However, this behavior
causes issues when a build dependency has the "all" architecture, since mk-
build-deps will try to install that package for an architecture which doesn't
exist.

To reproduce:
$ git clone --depth=1 https://salsa.debian.org/xorg-team/lib/mesa-amber.git
$ cd mesa-amber
$ mk-build-deps --host-arch arm64
$ apt-get install -y ./*.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'mesa-amber-cross-build-deps:arm64' instead of './mesa-amber-
cross-build-deps_21.3.9-1_arm64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mesa-amber-cross-build-deps:arm64 : Depends: python3:arm64 but it is not going
to be installed
 Depends: python3-mako:arm64 but it is not
installable

In this example, mk-build-deps tries to install python3-mako:arm64, which
doens't exist. The correct package would be python3-mako:all.


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.22
ii  fakeroot  1.31-1.2
ii  file  1:5.44-3
ii  gnupg 2.2.40-1.1
ii  gnupg22.2.40-1.1
ii  gpgv  2.2.40-1.1
ii  libc6 2.36-9+deb12u7
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.68-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7+deb12u1
ii  python3   3.11.2-1+b1
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.6.1
ii  curl7.88.1-10+deb12u5
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.12.24
ii  dput1.1.3
ii  equivs  2.3.1
ii  libdistro-info-perl 1.5+deb12u1
ii  libdpkg-perl1.21.22
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.26-3
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-3
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
ii  licensecheck3.3.5-1
ii  lintian 2.116.3
ii  man-db  2.11.2-2
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.6.0
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  6.1-0.1
ii  unzip   6.0-28
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.2

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
ii  autopkgtest  5.28
pn  bls-standalone   
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.11.4
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-3
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-3
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
ii  

Bug#1066018: kakoune: Installs README outside /usr/share/doc/kakoune/

[Timothy Allen]

Package: kakoune
Version: 2022.10.31-2
Severity: minor

Dear Maintainer,

I was looking at where the Kakoune package installs its documentation:

dpkg-query -L kakoune |
sed -e 's@/[^/]*$@@' |
sort -u |
grep doc

...expecting to find three directories:

/usr/share/doc  (because it creates a package directory inside here)
/usr/share/doc/kakoune/ (Debian package changelog, README, etc.)
/usr/share/kak/doc/ (Kakoune's online documentation)

Instead, I found an additional fourth directory, /usr/share/doc/kak

Apparently the Kakoune README is installed to /usr/share/doc/kak, while all the
other package documentation (package changelog, licence, etc.) is installed to
/usr/share/doc/kakoune.

I think the README should be installed in the directory named after the package,
as it is with other Debian packages.

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 kakoune depends on:
ii  libc6   2.37-15
ii  libgcc-s1   14-20240201-3
ii  libstdc++6  14-20240201-3

kakoune recommends no packages.

kakoune suggests no packages.

-- no debconf information

Bug#1065138: fwupd: "failed to load BOS descriptor" disables my mouse

[Timothy Allen]

Package: fwupd
Version: 1.9.14-1
Severity: important

Dear Maintainer,

I have a Kensington Expert Mouse (trackball) connected by USB. Today I
installed the update to fwupd 1.9.14 that `apt upgrade` offered me. Soon
afterwards, my trackball stopped working. I was able to re-enable it by
disconnecting and reconnecting it, but this proved short-lived - it eventually
cut out again. I reconnected it and it worked for a little longer, then I had
to reconnect it again, and eventually reconnecting it did nothing - it stayed
non-functional.

I started checking the logs, and eventually I noticed this error message
appearing shortly before the messages recording the trackball's reconnection:

fwupd[1106287]: 01:23:55.952 FuUsbDevice  failed to load BOS descriptor
from USB device: USB error on device 047d:1020 : Operation timed out [-7]

I can confirm that 047d:1020 identifies my trackball:

$ for name in
/sys/bus/usb/devices/1-1.6/{idVendor,idProduct,manufacturer,product}; do printf
"%s\t%s" "$(basename "$name")"; cat "$name"; done
idVendor047d
idProduct   1020
manufacturerKensington
product Kensington Expert Mouse

I ran "systemctl stop fwupd", reconnected my trackball, and then it worked
fine.

Investigating further, I discovered that I can disable my trackball on-demand
by running "sudo fwupdtool get-devices". It prints the following output:

Loading… [***]05:01:05.132
FuUsbDevice  failed to load BOS descriptor from USB device: USB error
on device 047d:1020 : Operation timed out [-7]
Loading… [** ]

...and then my trackball stops working until I reconnect it.

It seems that fwupd 1.19.14's changelog mentions "Fix DS-20 descriptors by
opening the GUsbDevice earlier", and apparently "DS-20 descriptor" is a
specific kind of "BOS descriptor".


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

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

Versions of packages fwupd depends on:
ii  adduser3.137
ii  libarchive13   3.7.2-1
ii  libc6  2.37-15
ii  libcbor0.100.10.2-1.1
ii  libcurl3-gnutls8.5.0-2
ii  libflashrom1   1.3.0-2.1+b1
ii  libfwupd2  1.9.14-1
ii  libglib2.0-0   2.78.4-1
ii  libgnutls303.8.3-1
ii  libgudev-1.0-0 238-3
ii  libgusb2   0.4.8-1
ii  libjcat1   0.2.0-2
ii  libjson-glib-1.0-0 1.8.0-2
ii  liblzma5   5.4.5-0.3
ii  libmbim-glib4  1.30.0-1
ii  libmbim-proxy  1.30.0-1
ii  libmm-glib01.22.0-3
ii  libpolkit-gobject-1-0  124-1
ii  libprotobuf-c1 1.4.1-1+b1
ii  libqmi-glib5   1.34.0-2
ii  libqmi-proxy   1.34.0-2
ii  libsqlite3-0   3.45.1-1
ii  libsystemd0255.3-2
ii  libtss2-esys-3.0.2-0   4.0.1-7
ii  libxmlb2   0.3.15-1
ii  shared-mime-info   2.4-1
ii  zlib1g 1:1.3.dfsg-3+b1

Versions of packages fwupd recommends:
ii  bolt   0.9.6-2
ii  dbus   1.14.10-4
ii  fwupd-amd64-signed [fwupd-signed]  1:1.4+1
ii  jq 1.7.1-2
ii  python33.11.6-1
pn  secureboot-db  
ii  udisks22.10.1-5

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- Configuration Files:
/etc/fwupd/fwupd.conf [Errno 13] Permission denied: '/etc/fwupd/fwupd.conf'

-- no debconf information

Bug#1061265: rst2pdf: Uses deprecated/to be removed pypdf2

[Rob Allen]

Hi,

I’m the one of the leads on rst2pdf itself.

Is there anything you want me to do related to this?

Regards,

Rob

> On 21 Jan 2024, at 18:19, Scott Kitterman  wrote:
> 
> Source: rst2pdf
> Version: 0.99-1
> Severity: wishlist
> 
> rst2pdf declares a requirement for python3-pypdf2 in
> Build-Depends-Indep.
> 
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in 
> response to an RFA for both packages.  As these are somewhat security 
> sensitive packages (among my first acts after adopting the packages was to 
> upload proposed updates for both to address minor security issues in Bookworm 
> in the next point release - same bug in both), I do not think we should 
> release pypdf2 in Trixie and have filed an RC bug to that effect.
> 
> It looks like the current upstream release has already been ported to
> use python3-pypdf (which is really pypdf3).  Please update your package.
> 
> Scott K
> 

Bug#1060297: acmetool's systemd timer is stopped when the package is upgraded

[Timothy Allen]

Package: acmetool
Version: 0.2.2-2+b1
Severity: normal

Dear Maintainer,

I installed acmetool a while ago, with the systemd timer unit to keep my
certificates refreshed, and I've generally been very happy with it.
However, sometimes Let's Encrypt emails me that my certificates are
about to expire, and when I check, the systemd timer unit is stopped,
and I have been unable to figure out why.

Today there was an updated acmetool package, and I caught it in the act.

Before I ran "apt upgrade", acmetool was scheduled:

```
$ sudo systemctl list-timers --all
NEXT LEFT LAST  PASSED UNIT
   --- 
--
Tue 2024-01-09 12:27:46 AEDT 1h 18min Tue 2024-01-09 00:21:01 AEDT 10h ago 
acmetool.timer
```

I then ran "apt upgrade", which completed successfully without errors or
warnings. Suddenly, the timer unit had been deactivated:

```
$ sudo systemctl list-timers --all
NEXT   LEFT LAST  PASSED UNIT
 --  --- --
- - Tue 2024-01-09 00:21:01 AEDT 10h ago acmetool.timer
```

And sure enough, although the unit was still loaded and "enabled" (which
I understand means "automatically activated") it was now inactive:

```
$ sudo systemctl status acmetool.timer
○ acmetool.timer - Reconcile Let's Encrypt certificates twice daily
 Loaded: loaded (/usr/lib/systemd/system/acmetool.timer; enabled; preset: 
enabled)
 Active: inactive (dead) since Tue 2024-01-09 11:09:26 AEDT; 1min 59s ago
   Duration: 3d 22h 57min 44.320s
Trigger: n/a
   Triggers: ● acmetool.service

Jan 05 12:11:41 boombah systemd[1]: Started acmetool.timer - Reconcile Let's 
Encrypt certificates twice daily.
Jan 09 11:09:26 boombah systemd[1]: acmetool.timer: Deactivated successfully.
Jan 09 11:09:26 boombah systemd[1]: Stopped acmetool.timer - Reconcile Let's 
Encrypt certificates twice daily.
```

I'm open to the possibility that I have somehow misconfigured systemd in
a way that causes this unit (and no others) to be deactivated, but I did
follow the instructions in the README.Debian.gz file to set it up.

Thank you for packaging such a useful tool!

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 acmetool depends on:
ii  libc62.37-13
ii  libcap2  1:2.66-4+b2

Versions of packages acmetool recommends:
ii  dialog  1.3-20231002-1

acmetool suggests no packages.

-- no debconf information

Bug#1048463: rst2pdf: Fails to build source after successful build

[Rob Allen]

Hi,

I’m a maintainer of rst2pdf and an not sure if I can help?

Looking at:

> dpkg-source: info: local changes detected, the modified files are:
> rst2pdf-0.99/doc/output/html/manual.html
> rst2pdf-0.99/doc/output/rst2pdf.1


It seems that you are running the docs/gen_docs.sh script which creates the 
documentation files and this causes an error because the files are created?

Regards,

Rob


> On 13 Aug 2023, at 20:21, Lucas Nussbaum  wrote:
> 
> Source: rst2pdf
> Version: 0.99-1
> Severity: minor
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-sab-20230813 ftbfs-source-after-build
> User: debian...@lists.debian.org
> Usertags: qa-doublebuild
> 
> Hi,
> 
> This package fails to build a source package after a successful build
> (dpkg-buildpackage ; dpkg-buildpackage -S).
> 
> This is probably a clear violation of Debian Policy section 4.9 (clean 
> target),
> but this is filed as severity:minor for now, because a discussion on
> debian-devel showed that we might want to revisit the requirement of a working
> 'clean' target.
> 
> More information about this class of issues, included common problems and
> solutions, is available at
> https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild
> 
> Relevant part of the build log:
>> cd /<> && runuser -u user42 -- dpkg-buildpackage --sanitize-env 
>> -us -uc -rfakeroot -S
>> 
>> 
>> dpkg-buildpackage: info: source package rst2pdf
>> dpkg-buildpackage: info: source version 0.99-1
>> dpkg-buildpackage: info: source distribution unstable
>> dpkg-buildpackage: info: source changed by Sandro Tosi 
>> dpkg-source --before-build .
>> fakeroot debian/rules clean
>> dh clean --with python3 --buildsystem=pybuild
>>   debian/rules override_dh_auto_clean
>> make[1]: Entering directory '/<>'
>> dh_auto_clean
>> I: pybuild base:275: python3.11 setup.py clean 
>> running clean
>> removing '/<>/.pybuild/cpython3_3.11_rst2pdf/build' (and 
>> everything under it)
>> 'build/bdist.linux-x86_64' does not exist -- can't clean it
>> 'build/scripts-3.11' does not exist -- can't clean it
>> rm -rf .pybuild/ rst2pdf.egg-info/
>> make[1]: Leaving directory '/<>'
>>   dh_autoreconf_clean -O--buildsystem=pybuild
>>   dh_clean -O--buildsystem=pybuild
>> dpkg-source -b .
>> dpkg-source: info: using source format '3.0 (quilt)'
>> dpkg-source: info: building rst2pdf using existing ./rst2pdf_0.99.orig.tar.xz
>> dpkg-source: info: using patch list from debian/patches/series
>> dpkg-source: info: local changes detected, the modified files are:
>> rst2pdf-0.99/doc/output/html/manual.html
>> rst2pdf-0.99/doc/output/rst2pdf.1
>> dpkg-source: error: aborting due to unexpected upstream changes, see 
>> /tmp/rst2pdf_0.99-1.diff.e4q0D2
>> dpkg-source: info: Hint: make sure the version in debian/changelog matches 
>> the unpacked source tree
>> dpkg-source: info: you can integrate the local changes with dpkg-source 
>> --commit
>> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
>> 
>> E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage 
>> --sanitize-env -us -uc -rfakeroot -S' failed to run.
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2023/08/13/rst2pdf_0.99-1_unstable.log
> 
> If you reassign this bug to another package, please mark it as 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.
> 

Bug#1041295: smartd.conf.5: some remarks and editorial fixes for the manual

[Bruce Allen]

This makes sense -- thanks for the clarification!

On 21.07.23 02:47, Bjarni Ingi Gislason wrote:

On Mon, Jul 17, 2023 at 09:45:17AM +0200, Bruce Allen wrote:

Dear Bjarni,

thanks very much for the corrections/patches to the man pages.

I reviewed the diff and it looks good.  Something I was wondering: why are
you inserting the zero width characters '\&' in various places?  I thought
that there were only needed to avoid an input sequence being misinterpreted
as a control character.  But in many places where you have inserted it, I
did not realize that this was a possibility.


   '\&' is, with the current layout of the source text, unnecessary,
but the position of the words can later change.
   So using '\&' is just a measure in advance.

   My explanation was:

Protect a period (.) or a apostrophe (') with '\&' from becoming a
control character, if it could end up at the start of a line
(by splitting the line into more lines).

   Can you suggest a better explanation?

   Maybe I should add after the sentence in parentheses:

"by reflowing, reorganising, reformatting the source text."

Extreme case: each word in a textual line is put in a separate line.


--
----
Bruce Allen, Adjunct Professor of Physics
Leonard E. Parker Center for Gravitation, Cosmology and Astrophysics
Physics Department
University of Wisconsin - Milwaukee
3135 N Maryland Ave
Milwaukee, 53211 USA

Tel: +1 414-229-4474
Fax: +1 414-229-5589
bal...@uwm.edu

Bug#1041295: smartd.conf.5: some remarks and editorial fixes for the manual

[Bruce Allen]

Dear Bjarni,

thanks very much for the corrections/patches to the man pages.

I reviewed the diff and it looks good.  Something I was wondering: why 
are you inserting the zero width characters '\&' in various places?  I 
thought that there were only needed to avoid an input sequence being 
misinterpreted as a control character.  But in many places where you 
have inserted it, I did not realize that this was a possibility.


Cheers,
 Bruce



On 17.07.23 04:46, Bjarni Ingi Gislason wrote:

Package: smartmontools
Version: 7.3-1+b1
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes for the man page.

Patch is in the attachment.

-.-.

The difference between the formatted outputs can be seen with:

   nroff -man  > 
   nroff -man  > 
   diff -u  

and for groff, using

"groff -man -Z" instead of "nroff -man"

   Add the option "-t", if the file contains a table.

   Read the output of "diff -u" with "less -R" or similar.

-.-.

   If "man" (man-db) is used to check the manual, the following
must be set:

   The option "-warnings=w"

   The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

   or

   (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint smartd.conf.5":

mandoc: smartd.conf.5:250:2: WARNING: line scope broken: SH breaks TP
mandoc: smartd.conf.5:600:81: STYLE: input text line longer than 80 bytes: It 
may also be used ...
mandoc: smartd.conf.5:1080:84: STYLE: input text line longer than 80 bytes: If 
\*(Aq@ALL\*(Aq is...

-.-.

Change '-' (\-) to '\(en' (en-dash) for a numeric range.
GNU gnulib has recently (2023-06-18) updated its
"build_aux/update-copyright" to recognize "\(en" in man pages.

smartd.conf.5:2:Copyright (C) 2002-10 Bruce Allen
smartd.conf.5:3:Copyright (C) 2004-21 Christian Franke
smartd.conf.5:122:# Start short self\-tests daily between 1\-2, 2\-3, and
smartd.conf.5:123:# 3\-4 am.
smartd.conf.5:142:# Start short self\-tests daily between 1\-2, 2\-3, and
smartd.conf.5:143:# 3\-4 am.
smartd.conf.5:152:# 1 am and 2\-3 am
smartd.conf.5:173:# Start short self\-tests daily between 1\-2, 2\-3, and
smartd.conf.5:174:# 3\-4 am.
smartd.conf.5:192:# between midnight and 1 am and 2\-3 am.
smartd.conf.5:225:# Start short self\-tests daily between 1\-2, 2\-3, and
smartd.conf.5:226:# 3\-4 am.
smartd.conf.5:964:  smartctl \-t select,0\- /dev/sda
smartd.conf.5:969:\fB \-s n/../../[1\-5]/12\fP

-.-.

Wrong distance between sentences.

   Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

   The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Seach for two words are easier, when they belong to the same line, and
the same phrase.

   The amount of space between sentences in the output can then be
controlled with the ".ss" request.

167:# uses the cciss driver. Start long tests on Sunday nights and short
248:then the corresponding block device (/dev/sd?) must be listed,
371:then the corresponding SCSI (/dev/sd?) or character device (/dev/twe?,
372:/dev/twa?, /dev/twl? or /dev/tws?) must be listed, along with the
379:then the corresponding device (SCSI /dev/sg? on Linux or /dev/arcmsr0 on

-.-.

Protect a period (.) or a apostrophe (') with '\&' from becoming a
control character, if it could end up at the start of a line
(by splitting the line into more lines).

115:# flagged with the '\-d sat' option.  This situation
648:\fBsmartd\fP checks it.  This is the default behavior if the '\-n'
786:Appending ',ns' (no standby) to this directive is not implemented \"#
801:Appending ',ns' (no standby) to this directive is not implemented \"#
934:0, ... hours, use:
938:To enable staggered tests with delays 0, 1, 2, ..., 9, 10, 0, ... hours,

-.-.

Split a punctuation from a single argument, if a two-font macro is meant

64:.B /etc/smartd.conf.

-.-.

Use \(en for a dash (en-dash) between space characters and at the
beginning of a line, not a minus (\-) or a hyphen (-), except in the
NAME section.

smartd.conf.5:394:\- attempt to guess the device type from the device name or 
from
[... and more]
smartd.conf.5:1644:\- show the presets that are available for all drives and 
then exit.

-.-.

[ "test-groff" is a developmental version of "groff" ]

Input file is ./smartd.conf.5

Output from "test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w -z ":

troff: backtrace: fil

Bug#1038440: debian-cd: debian-12.0.0-amd64-netinst.iso is too big for a CD

[Claude Heiland-Allen]

Source: debian-cd
Severity: normal
Tags: d-i
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I downloaded the "small" debian-12.0.0-amd64-netinst.iso (738 MiB)

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

I tried to burn it to a CD-RW disc:

sudo wodim blank=all
sudo wodim -dao debian-12.0.0-amd64-netinst.iso

   * What was the outcome of this action?

wodim: WARNING: Data may not fit on current disk.
wodim: Notice: Use -overburn option to write more than the official disk 
capacity.
wodim: Notice: Most CD-writers do overburning only on SAO or RAW mode.

   * What outcome did you expect instead?

The ISO to be small enough to fit on an 80-minute CD (703 MiB).


I'm not sure if I will actually need a CD,
(refurbishing someone's old laptop,
I don't know yet if it will boot from USB stick or not),
but if it can only boot from CD I will have to
install Bullseye (whose netinst does fit on a CD)
and then upgrade, which is not ideal.


Thanks,


Claude

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

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

Bug#1035933: linux-image-6.1.0-8-amd64-unsigned: fails to build (llvm-strip not found, missing dependency?)

[Claude Heiland-Allen]

 kernel is compiled with GCC:

https://buildd.debian.org/status/fetch.php?pkg=linux=amd64=6.1.27-1=1683630698=0

and compiles just fine.

To compile the kernel with llvm you either need to set CC or LLVM 
variables:


https://www.kernel.org/doc/html/latest/kbuild/llvm.html

Can you send the output of `export` to check what is set in your 
environment?


Given that you don't use the default compiler and that the default
toolchain is provided by the build-essential package, I don't think
this is a dependency issue and I would close this bug.

Cheers Jochen

* Claude Heiland-Allen  [2023-05-11 12:57]:

Package: linux-image-6.1.0-8-amd64-unsigned
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in 
the past)

X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

  * What led up to the situation?

I wanted to patch the kernel source to see if it would help an issue I 
was having,

so I followed my usual steps when changing a Debian package locally:

sudo apt build-dep linux-image-6.1.0-8-amd64-unsigned
mkdir linux
cd linux
apt source linux-image-6.1.0-8-amd64-unsigned
cd linux-6.1.25
# make changes to the source code
# specfically some warning prints in devices/usb/host/xhci-ring.c
debuild -i -us -uc -b

  * What was the outcome of this action?

The build failed after some time with:

...
llvm-strip -g 
/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/profiler.bpf.o

make[4]: llvm-strip: No such file or directory
make[4]: *** [Makefile:187: 
/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/profiler.bpf.o] 
Error 127

make[4]: *** Waiting for unfinished jobs
llvm-strip -g 
/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/pid_iter.bpf.o

make[4]: llvm-strip: No such file or directory
make[4]: *** [Makefile:187: 
/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/pid_iter.bpf.o] 
Error 127
make[4]: Leaving directory 
'/home/claude/linux/linux-6.1.25/tools/bpf/bpftool'
make[3]: *** 
[/home/claude/linux/linux-6.1.25/debian/rules.d/tools/bpf/bpftool/Makefile:15: 
all] Error 2
make[3]: Leaving directory 
'/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool'

make[2]: *** [debian/rules.real:538: build_bpftool] Error 2
make[2]: Leaving directory '/home/claude/linux/linux-6.1.25'
make[1]: *** [debian/rules.gen:1494: build-arch_amd64_real_bpftool] 
Error 2

make[1]: Leaving directory '/home/claude/linux/linux-6.1.25'
make: *** [debian/rules:39: build-arch] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -b failed

  * What outcome did you expect instead?

I expected apt to have fetched all the build-time dependencies of the 
package,

and the build to have succeeded.

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

After

sudo apt install llvm

then

debuild -i -us -uc -b

worked as expected.


Thanks for your work on this package,


Claude


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

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

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

Versions of packages linux-image-6.1.0-8-amd64-unsigned depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.1.0-8-amd64-unsigned recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-8-amd64-unsigned suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-efi-amd64  2.06-12
pn  linux-doc-6.1   


--
https://mathr.co.uk

Bug#1035941: linux-image-amd64: too much space needed to build

[Claude Heiland-Allen]

Package: linux-image-amd64
Severity: normal
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I tried to build locally-patched kernel debs:

sudo apt build-dep linux-image-6.1.0-8-amd64-unsigned
apt source linux-image-6.1.0-8-amd64-unsigned
cd linux-6.1.25
# make changes to source code
debuild -i -us -uc -b

   * What was the outcome of this action?

I ran out of disk space.

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

I freed up more space, but even with 53GB available it ran out.

   * What outcome did you expect instead?

The build process to use a reasonable amount of space,
perhaps by cleaning up artifacts after each output deb
before starting to build the next output deb.

Documentation of the required amount of disk space would be nice.

Thanks for your work on this package,


Claude


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

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

Versions of packages linux-image-amd64 depends on:
pn  linux-image-6.1.0-8-amd64  

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

Bug#1035939: linux-image-6.1.0-8-amd64: dmesg flood xhci_hcd 0000:03:00.0: WARN: bandwidth overrun event for slot 6 ep 4 on endpoint

[Claude Heiland-Allen]

Package: linux-image-6.1.0-8-amd64
Severity: normal
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I noticed a flood of messages (1000 per second!) in dmesg (mirrored in /var/log)
after it filled my drive (16GB of logs total, over a couple of weeks).

The message was:

xhci_hcd :03:00.0: WARN: bandwidth overrun event for slot 6 ep 4 on endpoint

or

xhci_hcd :03:00.0: WARN: bandwidth overrun event for slot 11 ep 4 on 
endpoint

(it reoccurred after rebooting, but does not seem predictable).

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

I unplugged my USB soundcard from my USB hub, and the message flood stopped.

When plugging in the USB soundcard, dmesg reports similar to:

usb 1-12.1.3: new full-speed USB device number 12 using xhci_hcd
usb 1-12.1.3: New USB device found, idVendor=0582, idProduct=0074, bcdDevice= 
1.07
usb 1-12.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-12.1.3: Product: EDIROL UA-25
usb 1-12.1.3: Manufacturer: Roland

   * What outcome did you expect instead?

I expect potentially rapidly repeated kernel messages to be rate-limited to a 
sensible amount.

I tried:

cd linux-6.1.25/drivers/usb/host
sed -i "s/xhci_warn/xhci_warn_ratelimited/g" xhci-ring.c
sed -i "s/xhci_warn_ratelimited_ratelimited/xhci_warn_ratelimited/g" xhci-ring.c

and rebuilt the kernel.

I have not yet rebooted to test if it fixes my problem.


Thanks for your work on this package,


Claude


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

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

Versions of packages linux-image-6.1.0-8-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.1.0-8-amd64 recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-8-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-efi-amd64  2.06-12
pn  linux-doc-6.1   

Bug#1035933: linux-image-6.1.0-8-amd64-unsigned: fails to build (llvm-strip not found, missing dependency?)

[Claude Heiland-Allen]

Package: linux-image-6.1.0-8-amd64-unsigned
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I wanted to patch the kernel source to see if it would help an issue I was 
having,
so I followed my usual steps when changing a Debian package locally:

sudo apt build-dep linux-image-6.1.0-8-amd64-unsigned
mkdir linux
cd linux
apt source linux-image-6.1.0-8-amd64-unsigned
cd linux-6.1.25
# make changes to the source code
# specfically some warning prints in devices/usb/host/xhci-ring.c
debuild -i -us -uc -b

   * What was the outcome of this action?

The build failed after some time with:

...
llvm-strip -g 
/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/profiler.bpf.o
make[4]: llvm-strip: No such file or directory
make[4]: *** [Makefile:187: 
/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/profiler.bpf.o]
 Error 127
make[4]: *** Waiting for unfinished jobs
llvm-strip -g 
/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/pid_iter.bpf.o
make[4]: llvm-strip: No such file or directory
make[4]: *** [Makefile:187: 
/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/pid_iter.bpf.o]
 Error 127
make[4]: Leaving directory '/home/claude/linux/linux-6.1.25/tools/bpf/bpftool'
make[3]: *** 
[/home/claude/linux/linux-6.1.25/debian/rules.d/tools/bpf/bpftool/Makefile:15: 
all] Error 2
make[3]: Leaving directory 
'/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool'
make[2]: *** [debian/rules.real:538: build_bpftool] Error 2
make[2]: Leaving directory '/home/claude/linux/linux-6.1.25'
make[1]: *** [debian/rules.gen:1494: build-arch_amd64_real_bpftool] Error 2
make[1]: Leaving directory '/home/claude/linux/linux-6.1.25'
make: *** [debian/rules:39: build-arch] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -b failed

   * What outcome did you expect instead?

I expected apt to have fetched all the build-time dependencies of the package,
and the build to have succeeded.

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

After

sudo apt install llvm

then

debuild -i -us -uc -b

worked as expected.


Thanks for your work on this package,


Claude


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

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

Versions of packages linux-image-6.1.0-8-amd64-unsigned depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.1.0-8-amd64-unsigned recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-8-amd64-unsigned suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-efi-amd64  2.06-12
pn  linux-doc-6.1   

Bug#1030231: hugs: toInteger (minBound :: Int) incorrect on 64bit

[Claude Heiland-Allen]

Package: hugs
Version: 98.200609.21-6
Severity: normal
Tags: patch
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I evaluated:

> (minBound :: Int, toInteger (minBound :: Int))

   * What was the outcome of this action?

Two different numbers were output.

   * What outcome did you expect instead?

Two identical numbers to be output.


The consequences of this bug include
broken bitwise operations for Integer
(arithmetic overflow exceptions).


The problem is in src/bignums.c, because -INT_MIN == INT_MIN.

Attached patch fixes the problem for me on aarch64 and x86_64.


Regards,


Claude

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads)
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 hugs depends on:
ii  libc6  2.31-13+deb11u5
ii  libhugs-base-bundled [libhugs-base]98.200609.21-6
ii  libhugs-haskell98-bundled [libhugs-haskell98]  98.200609.21-6
ii  libreadline8   8.1-1

Versions of packages hugs recommends:
ii  libhugs-alut-bundled [libhugs-alut]98.200609.21-6
ii  libhugs-cabal-bundled [libhugs-cabal]  98.200609.21-6
ii  libhugs-fgl-bundled [libhugs-fgl]  98.200609.21-6
ii  libhugs-glut-bundled [libhugs-glut]98.200609.21-6
ii  libhugs-haskell-src-bundled [libhugs-haskell-src]  98.200609.21-6
ii  libhugs-haxml-bundled [libhugs-haxml]  98.200609.21-6
ii  libhugs-hgl-bundled [libhugs-hgl]  98.200609.21-6
ii  libhugs-hunit-bundled [libhugs-hunit]  98.200609.21-6
ii  libhugs-mtl-bundled [libhugs-mtl]  98.200609.21-6
ii  libhugs-network-bundled [libhugs-network]  98.200609.21-6
ii  libhugs-openal-bundled [libhugs-openal]98.200609.21-6
ii  libhugs-opengl-bundled [libhugs-opengl]98.200609.21-6
ii  libhugs-parsec-bundled [libhugs-parsec]98.200609.21-6
ii  libhugs-quickcheck-bundled [libhugs-quickcheck]98.200609.21-6
ii  libhugs-stm-bundled [libhugs-stm]  98.200609.21-6
ii  libhugs-time-bundled [libhugs-time]98.200609.21-6
ii  libhugs-unix-bundled [libhugs-unix]98.200609.21-6
ii  libhugs-x11-bundled [libhugs-x11]  98.200609.21-6
ii  libhugs-xhtml-bundled [libhugs-xhtml]  98.200609.21-6

Versions of packages hugs suggests:
pn  cpphs 
pn  haskell-doc   
pn  haskell-mode  

-- no debconf information
diff -wur old/hugs98-98.200609.21/src/bignums.c 
new/hugs98-98.200609.21/src/bignums.c
--- old/hugs98-98.200609.21/src/bignums.c   2004-10-29 13:43:09.0 
+0100
+++ new/hugs98-98.200609.21/src/bignums.c   2023-02-01 11:15:18.575315477 
+
@@ -117,7 +117,7 @@
unsigned long no;
Cell nx;
if (n<0) {
-   no = (unsigned long)(-n);
+   no = (unsigned long)(-(signed long)(n));
bn = pair(NEGNUM,NIL);
}
else {

Bug#1012612: texinfo: Info documentation links to missing "pod2texi" manual

[Tim Allen]

On Mon, Jan 09, 2023 at 07:45:04AM +0100, Hilmar Preuße wrote:
> I've uploaded texinfo 7.0.1-3 to Debian experimental. Could you install
> it and check if it solves the issue? Thanks!

I downloaded the texinfo and texinfo-lib packages from the experimental
repository and installed them. The issue is not solved:

  - /usr/share/info/dir still mentions "(pod2texi)Invoking pod2texi."
  - /usr/share/info/texinfo.info.gz still includes that link in its
START-INFO-DIR-ENTRY section.
  - There's still no /usr/share/info/pod2texi.info(.gz) file

Thank you for your packaging work!

Tim.

Bug#1025003: pocl-opencl-icd: segfault (llvm version confusion) with mesa-opencl-icd

[Claude Heiland-Allen]

Package: pocl-opencl-icd
Version: 3.0-7
Severity: normal
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I have a program that uses OpenCL,
including simultaneous use of multiple platforms and devices.

When mesa-opencl-icd (Clover) is installed,
usage of pocl-opencl-icd (PoCL) segfaults.

The backtrace reveals
PoCL calls LLVM 13,
but somehow things get confused inside and
LLVM 13 calls LLVM 15
which causes a crash.
LLVM 15 is linked by mesa-opencl-icd.

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

Workaround to get functioning OpenCL:

Either uninstall mesa-opencl-icd,
and use pocl-opencl-icd for OpenCL,
or uninstall pocl-opencl-icd and libpocl2,
and use mesa-opencl-icd for OpenCL.

   * What outcome did you expect instead?

It would be great if pocl-opencl-icd could be used
at the same time as mesa-opencl-icd.

I don't know how the dynamic library linking works,
but maybe upgrading to LLVM 15 as used by mesa-opencl-icd
would mask the issue?


GDB Backtrace:

---8<---
(gdb) run
...
Thread 55 "fraktaler-3.gcc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffab7fe6c0 (LWP 68040)]
0x7fffed0d1528 in 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) () from /lib/x86_64-linux-gnu/libLLVM-15.so.1
(gdb) bt
#0  0x7fffed0d1528 in 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) () from /lib/x86_64-linux-gnu/libLLVM-15.so.1
#1  0x7fffed0d13ca in 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) () from /lib/x86_64-linux-gnu/libLLVM-15.so.1
#2  0x7fffee2749b6 in llvm::AAManager::run(llvm::Function&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-15.so.1
#3  0x7fffee52242b in ?? () from /lib/x86_64-linux-gnu/libLLVM-15.so.1
#4  0x7fff8375aba1 in 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) () from /lib/x86_64-linux-gnu/libLLVM-13.so.1
#5  0x7fff841710e1 in llvm::InstCombinePass::run(llvm::Function&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-13.so.1
#6  0x7fff85cd3a9d in ?? () from /lib/x86_64-linux-gnu/libLLVM-13.so.1
#7  0x7fff8375841e in llvm::PassManager>::run(llvm::Function&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-13.so.1
#8  0x7fff8507e74d in ?? () from /lib/x86_64-linux-gnu/libLLVM-13.so.1
#9  0x7fff8375bf7a in llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-13.so.1
#10 0x7fff8507e58d in ?? () from /lib/x86_64-linux-gnu/libLLVM-13.so.1
#11 0x7fff8375717e in llvm::PassManager>::run(llvm::Module&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-13.so.1
#12 0x7fff8a18270f in ?? () from /lib/x86_64-linux-gnu/libclang-cpp.so.13
#13 0x7fff8a17cf40 in clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, 
llvm::Module*, clang::BackendAction, std::unique_ptr >) () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#14 0x7fff8a43fefe in ?? () from /lib/x86_64-linux-gnu/libclang-cpp.so.13
#15 0x7fff8941e794 in clang::ParseAST(clang::Sema&, bool, bool) () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#16 0x7fff8a43c6d1 in clang::CodeGenAction::ExecuteAction() () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#17 0x7fff8ac854a6 in clang::FrontendAction::Execute() () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#18 0x7fff8abfeca6 in 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#19 0x7fffa97acf86 in ?? () from /lib/x86_64-linux-gnu/libpocl.so.2.9.0
#20 0x7fffa973ed40 in ?? () from /lib/x86_64-linux-gnu/libpocl.so.2.9.0
#21 0x7fffa973d88c in ?? () from /lib/x86_64-linux-gnu/libpocl.so.2.9.0
#22 0x5563d383 in opencl_get_kernel 
(context=context@entry=0x7fffac001070, nt=nt@entry=nt_double, par=...) at 
src/opencl.cc:319
#23 0x5564bfd6 in render_device (queue=..., nt=nt_double, device=..., 
par=..., h=, ref_recalculated=, 
bla_recalculated=true, running=0x5578e9a6 ) at src/render.cc:137
#24 0x5564e58c in operator() (device=, 
__closure=0x7fffc5a9c630) at src/render.cc:293
#25 operator() (__closure=0x7fffb8000cd8) at src/parallel.h:149
#26 std::__invoke_impl >(int, coord_t, 
coord_t, coord_t, bool volatile*, render(const wlookup&, const param&, hooks*, 
bool, progress_t*, bool volatile*)::):: > (__f=...) 
at /usr/include/c++/12/bits/invoke.h:61
#27 std::__invoke >(int, coord_t, coord_t, 
coord_t, bool volatile*, render(const wlookup&, const param&, hooks*, bool, 
progress_t*, bool volatile*)::):: > (__fn=...) at 
/usr/include/c++/12/bits/invoke.h:96
#28 std::thread::_Invoker >(int, 
coord_t, coord_t, coord_t, bool volatile*, render(const wlookup&, const 

Bug#170850: opportunity

[Allen S]

Hello,

I lead family investment vehicles who want to invest a proportion of their 
funds with a trust party .

Please if you are interested in discussing investment in your sector?

Please email, or simply write to me here. I value promptness and will make 
every attempt to respond within a short time.

Thank you.
Allen S.

Bug#277964: opportunity

[Allen S]

Hello,

I lead family investment vehicles who want to invest a proportion of their 
funds with a trust party .

Please if you are interested in discussing investment in your sector?

Please email, or simply write to me here. I value promptness and will make 
every attempt to respond within a short time.

Thank you.
Allen S.

Bug#1005721: [Pkg-samba-maint] Bug#1005721: samba: Intermittent segfault+coredump when volume_label calls strlen

[Richard Allen]

Thanks Andrew,

I've done so, resulting in https://bugzilla.samba.org/show_bug.cgi?id=14978 .

https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1914420 seems to
have the same backtrace as well.

-Richard

Bug#998837: gnome-flashback: GNOME Flashback segfaults at login

[Timothy Allen]

Package: gnome-flashback
Version: 3.42.0-1
Severity: important

Dear Maintainer,

After updating gnome-flashback today, I am unable to login to the "GNOME
Flashback (Metacity)" sesson - I immediately get the "Oh no, an error occured,
please log out" screen.

Poking around in `journalctl --user` I discovered the following entry at the
time of my login attempt:

gnome-flashback.service: Main process exited, code=killed, status=11/SEGV

After installing systemd-coredump, I managed to extract a backtrace:

#0  gf_logical_monitor_configs_have_monitor
(logical_monitor_configs=logical_monitor_configs@entry=0x55ec78aeb020 =
{...}, monitor_spec=monitor_spec@entry=0x55ec78ad1f50)
at ./backends/gf-logical-monitor-config.c:56
#1  0x55ec77c8bd48 in gf_monitors_config_new
(monitor_manager=monitor_manager@entry=0x7fa438003d70,
logical_monitor_configs=logical_monitor_configs@entry=0x55ec78aeb020 = {...},
layout_mode=layout_mode@entry=GF_LOGICAL_MONITOR_LAYOUT_MODE_PHYSICAL,
flags=flags@entry=GF_MONITORS_CONFIG_FLAG_NONE) at ./backends/gf-monitors-
config.c:179
#2  0x55ec77c934a6 in create_monitors_config
(match_rule=, positioning=MONITOR_POSITIONING_LINEAR,
config_flags=GF_MONITORS_CONFIG_FLAG_NONE, config_manager=,
config_manager=) at ./backends/gf-monitor-config-manager.c:603
#3  0x55ec77c8643b in gf_monitor_manager_ensure_configured
(manager=manager@entry=0x7fa438003d70) at ./backends/gf-monitor-manager.c:2786
#4  0x55ec77c98d79 in gf_monitor_manager_xrandr_ensure_initial_config
(manager=0x7fa438003d70) at ./backends/gf-monitor-manager-xrandr.c:699
#5  0x55ec77c85ce7 in gf_monitor_manager_setup (manager=0x7fa438003d70) at
./backends/gf-monitor-manager.c:2477
#6  0x55ec77c841c3 in gf_backend_new
(type=type@entry=GF_BACKEND_TYPE_X11_CM) at ./backends/gf-backend.c:377
#7  0x55ec77c823e0 in gf_application_init (application=0x55ec78ae4550) at
./gnome-flashback/gf-application.c:328

Looking at the code of gf_logical_monitor_configs_have_monitor(), it takes a
list of GfLogicalMonitorConfig, and the first one in the list looks like:

(gdb) print *((GfLogicalMonitorConfig *)l->data)
$5 = {layout = {x = 3, y = 0, width = 0, height = 0},
  monitor_configs = 0xe0001 = {

...which seems very suspicious to me. The second one in the list looks like:

(gdb) print *((GfLogicalMonitorConfig *)logical_monitor_configs->next->data)
$9 = {layout = {x = 0, y = 0, width = 1920, height = 1080},
  monitor_configs = 0x55ec78b1ac60 = {0x55ec78b1f020},
  transform = GF_MONITOR_TRANSFORM_NORMAL, scale = 1, is_primary = 1,
  is_presentation = 0}

...which seems to exactly match the monitor I'm using. There is no third item
in the list.

I walked up the stack to create_monitors_config() where this data structure is
created, and it looks like the `logical_monitor_configs` variable is created,
and then appended to, but never initialised. I don't know if that's actually
the problem, but it's consistent with the symptoms I'm seeing.


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

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-flashback depends on:
ii  gnome-flashback-common   3.42.0-1
ii  libasound2   1.2.5.1-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo21.16.0-5
ii  libcanberra-gtk3-0   0.30-8
ii  libcanberra0 0.30-8
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libgdm1  41.0-3
ii  libglib2.0-0 2.70.0-3
ii  libgnome-bluetooth13 3.34.5-4
ii  libgnome-desktop-3-1941.0-1
ii  libgnome-panel0  3.42.0-1
ii  libgtk-3-0   3.24.30-3
ii  libibus-1.0-51.5.25-2
ii  libpam0g 1.4.0-10
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1
ii  libpolkit-agent-1-0  0.105-31
ii  libpolkit-gobject-1-00.105-31
ii  libpulse-mainloop-glib0  15.0+dfsg1-2
ii  libpulse015.0+dfsg1-2
ii  libsystemd0  249.5-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-randr01.14-3
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.8-1
ii  libxkbfile1  1:1.1.0-1
ii  libxrandr2   2:1.5.2-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  nautilus 41.1-1

Versions of packages gnome-flashback recommends:
ii  dbus   1.12.20-3
ii  gnome-settings-daemon  41.0-2
ii  libpam-gnome-keyring   40.0-3

Versions of 

Bug#997665: projectm-pulseaudio should depend on projectm-data

[Timothy Allen]

Package: projectm-pulseaudio
Version: 3.1.12-1
Severity: normal

Dear Maintainer,

Today I heard about ProjectM for the first time, so I looked at the list of
packages and decided projectm-pulseaudio would be the most useful variant for
me. I installed it:

$ sudo apt install projectm-pulseaudio
The following NEW packages will be installed:
  projectm-pulseaudio
0 upgraded, 1 newly installed, 0 to remove and 22 not upgraded.
Need to get 428 kB of archives.
After this operation, 1,349 kB of additional disk space will be used.

...but when I tried to run it, it failed:

$ projectM-pulseaudio
Default config: /usr/share/projectM/config.inp
trying to create /home/st/.projectM/config.inp
Cannot find projectM default config, using implementation defaults
Aborted

`apt-file` tells me that `/usr/share/projectM/config.inp` comes from the
package projectm-data, and sure enough if I install that, projectM-pulseaudio
starts correctly.


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

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages projectm-pulseaudio depends on:
ii  libc6   2.32-4
ii  libgcc-s1   11.2.0-9
ii  libgl1  1.3.4-2+b1
ii  libpulse0   15.0+dfsg1-2
ii  libqt5core5a5.15.2+dfsg-12
ii  libqt5gui5  5.15.2+dfsg-12
ii  libqt5opengl5   5.15.2+dfsg-12
ii  libqt5widgets5  5.15.2+dfsg-12
ii  libstdc++6  11.2.0-9
ii  pulseaudio  15.0+dfsg1-2

projectm-pulseaudio recommends no packages.

projectm-pulseaudio suggests no packages.

-- no debconf information

Bug#993608: xfce4: blank screen after login after changing resolution

[Claude Heiland-Allen]

On 03/09/2021 17:01, Claude Heiland-Allen wrote:

...
-vga virtio -display gtk,gl=on,show-cursor=on \
...


I found[1] a workaround: switch to a console with qemu monitor "sendkey 
ctrl-alt-f1" then login and run


|xfconf-query -c xfwm4 -p /general/vblank_mode -s xpresent||
sudo service lightdm restart
||
[1] https://gitlab.com/postmarketOS/pmaports/-/issues/368

|||

Bug#993608: xfce4: blank screen after login after changing resolution

[Claude Heiland-Allen]

More information:

I am starting QEMU like this:

qemu-system-x86_64 \
-m 8G -hda hda.img -cpu host -accel kvm -smp 8 \
-vga virtio -display gtk,gl=on,show-cursor=on \
-usb -device usb-tablet \
-audiodev id=pa,driver=pa,in.frequency=44100,out.frequency=44100 \
-device intel-hda -device hda-duplex,audiodev=pa

The host is running Bullseye (previously testing), configured with 
amdgpu (OpenGL 4.6) and PipeWire.

Bug#993608: xfce4: blank screen after login after changing resolution

[Claude Heiland-Allen]

Package: xfce4
Version: 4.16
Severity: normal
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I installed Debian 11.0 amd64 netinst in a QEMU virtual machine.
I deselected GNOME and selected XFCE4.

On first boot, after login, I changed screen resolution to 1440x900
using XFCE4 display settings user interface.

The display was fine at the new resolution until the next time I started
the virtual machine, at which point after LightDM login the screen went
black (at the 1440x900 size).

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

I created a new user which allowed me to log in graphically, but the
default video resolution is tiny and unsuitable for what I need the VM for.

   * What outcome did you expect instead?

I expected the desktop still to work after a reboot.


Thanks for any help,


Claude


-- 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/8 CPU threads)
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 xfce4 depends on:
ii  libxfce4ui-utils 4.16.0-1
ii  thunar   4.16.8-1
ii  xfce4-appfinder  4.16.1-1
ii  xfce4-panel  4.16.2-1
ii  xfce4-pulseaudio-plugin  0.4.3-1
ii  xfce4-session4.16.0-1
ii  xfce4-settings   4.16.0-1
ii  xfconf   4.16.0-2
ii  xfdesktop4   4.16.0-1
ii  xfwm44.16.1-1

Versions of packages xfce4 recommends:
ii  desktop-base  11.0.3
ii  tango-icon-theme  0.8.90-8
ii  thunar-volman 4.16.0-1
ii  xfce4-notifyd 0.6.2-1
ii  xorg  1:7.7+22

Versions of packages xfce4 suggests:
ii  xfce4-goodies4.14.0
ii  xfce4-power-manager  4.16.0-1

-- no debconf information
Xsession: X session started for claude at Fri  3 Sep 16:31:42 BST 2021
WARNING: tempfile is deprecated; consider using mktemp instead.
dbus-update-activation-environment: setting 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting XAUTHORITY=/home/claude/.Xauthority
localuser:claude being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
/usr/bin/x-session-manager: X server already running on display :0
/usr/bin/iceauth:  creating new authority file /run/user/1000/ICEauthority
xfce4-session-Message: 16:31:43.041: SSH authentication agent is already running
gpg-agent: a gpg-agent is already running - not starting a new one

** (xfce4-power-manager:802): WARNING **: 16:31:43.791: Failed to get name 
owner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get 
owner of name 'org.xfce.PowerManager': no such name


** (xfce4-power-manager:802): WARNING **: 16:31:43.791: Failed to get name 
owner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get 
owner of name 'org.freedesktop.PowerManagement': no such name

Xfce power manager is not running
Xfce Power Manager: Another power manager is already running

(xfce4-power-manager:802): GLib-GObject-WARNING **: 16:31:43.898: 
../../../gobject/gsignal.c:2614: signal 'Changed' is invalid for instance 
'0x55f61b3bb0b0' of type 'GDBusProxy'
Another notification daemon is running, exiting

(xfce4-power-manager:802): xfce4-power-manager-WARNING **: 16:31:43.910: could 
not map keysym 1008ffa8 to keycode


** (xfce4-power-manager:802): WARNING **: 16:31:43.914: No outputs have 
backlight property

(xfce4-power-manager:802): xfce4-power-manager-WARNING **: 16:31:43.919: Failed 
to get keyboard max brightness level : 
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 
“org.freedesktop.UPower.KbdBacklight” on object at path 
/org/freedesktop/UPower/KbdBacklight

(xfce4-panel:790): garcon-CRITICAL **: 16:31:44.082: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:790): garcon-CRITICAL **: 16:31:44.107: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:790): garcon-CRITICAL **: 16:31:44.135: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:790): garcon-CRITICAL **: 16:31:44.161: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

** (wrapper-2.0:852): WARNING **: 16:31:44.252: No outputs have backlight 
property

(wrapper-2.0:853): GLib-GIO-CRITICAL **: 16:31:44.287: g_file_new_for_path: 
assertion 'path != NULL' failed

(wrapper-2.0:853): GLib-GIO-CRITICAL **: 16:31:44.287: g_file_monitor_file: 
assertion 'G_IS_FILE (file)' failed

(wrapper-2.0:853): GLib-GObject-WARNING 

Bug#989287: libcivetweb1: build with websockets support

[Claude Heiland-Allen]

Hi Andreas,

On 02/06/2021 07:16, Andreas Tille wrote:

Hi Claude,

On Mon, May 31, 2021 at 09:51:33AM +0100, Claude Heiland-Allen wrote:

I managed to rebuild the package locally with websockets support by adding
-DCIVETWEB_ENABLE_WEBSOCKETS=ON to CMAKE_EXTRA_FLAGS in debian/rules, adding
extra lines to debian/libcivetweb1.symbols like
  mg_websocket_client_write@Base 1.13+dfsg-5
  mg_websocket_write@Base 1.13+dfsg-5

Thank you for the bug report.  It seems to be easy to accomplish.
However, due to the current freeze policy we can not upload to unstable
and thus I prefer to leave this bug open until after the freeze.

Sure that's perfectly fine for me.

It would be great if you could meanwhile post a complete patch (by
for instance using debdiff) to save us the work to do what you just
have done.
I could not get debdiff to work for me (I couldn't figure out how to 
create a new .dsc file, I'm very out of practice with Debian packaging), 
so I attach a regular diff between two directories.  I hope it's not too 
inconvenient.


Thanks,


Claude

diff -ruw civetweb-1.13+dfsg.old/debian/changelog civetweb-1.13+dfsg.new/debian/changelog
--- civetweb-1.13+dfsg.old/debian/changelog	2021-01-21 14:30:38.0 +
+++ civetweb-1.13+dfsg.new/debian/changelog	2021-06-02 09:34:33.738622818 +0100
@@ -1,3 +1,10 @@
+civetweb (1.13+dfsg-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Enable websockets support.
+
+ -- Claude Heiland-Allen   Wed, 02 Jun 2021 09:34:18 +0100
+
 civetweb (1.13+dfsg-5) unstable; urgency=medium
 
   * Team Upload.
diff -ruw civetweb-1.13+dfsg.old/debian/libcivetweb1.symbols civetweb-1.13+dfsg.new/debian/libcivetweb1.symbols
--- civetweb-1.13+dfsg.old/debian/libcivetweb1.symbols	2021-01-21 14:14:50.0 +
+++ civetweb-1.13+dfsg.new/debian/libcivetweb1.symbols	2021-06-02 09:32:55.214672544 +0100
@@ -144,4 +144,6 @@
  mg_url_decode@Base 1
  mg_url_encode@Base 1
  mg_version@Base 1
+ mg_websocket_client_write@Base 1.13+dfsg-5
+ mg_websocket_write@Base 1.13+dfsg-5
  mg_write@Base 1
diff -ruw civetweb-1.13+dfsg.old/debian/rules civetweb-1.13+dfsg.new/debian/rules
--- civetweb-1.13+dfsg.old/debian/rules	2021-01-21 14:29:18.0 +
+++ civetweb-1.13+dfsg.new/debian/rules	2021-06-02 09:31:08.019109852 +0100
@@ -12,6 +12,7 @@
 -DCIVETWEB_BUILD_TESTING=OFF \
 -DCIVETWEB_SOVERSION=1 \
 	-DCIVETWEB_ENABLE_CXX=ON \
+	-DCIVETWEB_ENABLE_WEBSOCKETS=ON \
 -DBUILD_SHARED_LIBS=ON
 
 %:

Bug#989287: libcivetweb1: build with websockets support

[Claude Heiland-Allen]

Package: libcivetweb1
Version: 1.13+dfsg-5
Severity: wishlist
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I wanted to write a websocket server using civetweb packaged in Debian.

   * What was the outcome of this action?

Debian civetweb is not built with websockets support.


I managed to rebuild the package locally with websockets support by adding
-DCIVETWEB_ENABLE_WEBSOCKETS=ON to CMAKE_EXTRA_FLAGS in debian/rules, adding
extra lines to debian/libcivetweb1.symbols like
 mg_websocket_client_write@Base 1.13+dfsg-5
 mg_websocket_write@Base 1.13+dfsg-5

I'm not sure if other changes need to be made (e.g. library version bump for
changed ABI?).


Thanks for your consideration,


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libcivetweb1 depends on:
ii  libc6   2.31-12
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6

libcivetweb1 recommends no packages.

libcivetweb1 suggests no packages.

-- no debconf information

Bug#920667:

[Ronald Allen]

Bug#982885: apt: refuses to update, citing certificate that won't be valid for several hours

[allen]

Package: apt
Version: 2.1.15
Severity: important
X-Debbugs-Cc: phuckthis...@gmail.com

Dear Maintainer,

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

   * What led up to the situation? I am pretty sure that I have a hacker on our
network
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I have tried to change the configurations based on what I
have found online and have been unable to.
   * What was the outcome of this action? nothing has happened
   * What outcome did you expect instead? I would  like someone to help me
figure out what I can't get this a-hole off my network



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-.*-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-.*-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^postgresql.*-13";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w 
/var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then 
/usr/lib/cnf-update-db > /dev/null; fi";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || 
true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";

Bug#974598: libflint-arb-dev: missing dependency on libflint-dev

[Claude Heiland-Allen]

Package: libflint-arb-dev
Version: 1:2.18.1-3
Severity: normal
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I installed libflint-arb-dev and tried to compile my program,
compilation failed with:

/usr/include/mag.h:23:10: fatal error: flint/flint.h: No such file or directory
   23 | #include "flint/flint.h"
  |  ^~~

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

After installing libflint-dev compilation succeeded.

   * What outcome did you expect instead?

That installing libflint-arb-dev should allow programs using
arb to be compiled without needing to install extra packages
by hand.

Thanks for your work,


Claude


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

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

Versions of packages libflint-arb-dev depends on:
ii  libflint-arb2  1:2.18.1-3

libflint-arb-dev recommends no packages.

libflint-arb-dev suggests no packages.

-- no debconf information

Bug#974186: /usr/bin/gnome-software: gnome-software uses way too much memory

[Timothy Allen]

Package: gnome-software
Version: 3.38.0-2
Severity: important
File: /usr/bin/gnome-software

Dear Maintainer,

Thank you for working on keeping GNOME packages up-to-date in Debian, and thank
you in particular for packaging GNOME Software, which makes it easy to keep on
top of package updates, especially for Testing where they happen regularly.

I have a low-end laptop with 2GB of RAM, and I usually run GNOME 3 because it's
highly polished and light-weight enough that I can still run a browser and a
few terminals to get work done. The one exception is gnome-software, which
frequently claims 15% or more of my RAM whenever it checks for updates. Right
now, it's sitting at ~18%, or 335MB resident — that may not be much on other
computers, but for my little laptop it's often enough to get my browser OOM-
killed while I'm in the middle of something.

Is there some way I can make GNOME Software stop checking for updates, or at
least stop holding (presumably) the entire package list in memory after the
update-check is complete?

From GNOME Software's hamburger menu, I picked "Update Preferences" and
disabled "Automatic Updates" and "Automatic Update Notifications", but that
doesn't seem to stop it from checking for updates (what seems like) every time
I wake my laptop up.

I also went into the "Software & Updates" application, and set "Automatically
check for updates" to "Never". Still no change.

Previously, I've just sent the gnome-software process a SIGTERM and that
cleaned it up until the next time I logged in, but more recently it's been
automatically restarted.



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

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

Versions of packages gnome-software depends on:
ii  appstream0.12.11-1
ii  apt-config-icons 0.12.11-1
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  gnome-software-common3.38.0-2
ii  gsettings-desktop-schemas3.38.0-2
ii  libappstream-glib8   0.7.17-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-4
ii  libcairo21.16.0-4
ii  libfwupd21.4.6-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.66.2-1
ii  libgspell-1-21.8.4-1
ii  libgtk-3-0   3.24.23-2
ii  libgtk3-perl 0.037-1
ii  libgudev-1.0-0   234-1
ii  libjson-glib-1.0-0   1.6.0-1
ii  libmalcontent-0-00.9.0-2
ii  libpackagekit-glib2-18   1.2.1-1
ii  libpolkit-gobject-1-00.105-29
ii  libsoup2.4-1 2.72.0-2
ii  libxmlb1 0.1.15-2
ii  packagekit   1.2.1-1
ii  software-properties-gtk  0.96.20.2-2.1

Versions of packages gnome-software recommends:
ii  fwupd  1.4.6-2

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#969890: cmake: segfaults in dl-lookup.c:158 check_match() "UI_set_result"

[Claude Heiland-Allen]

I resolved these problems with
sudo apt install --reinstall libssl1.1
no clue why/how it was damaged
sorry for the noise

Bug#969890: cmake: segfaults in dl-lookup.c:158 check_match() "UI_set_result"

[Claude Heiland-Allen]

On 08/09/2020 12:44, Claude Heiland-Allen wrote:

Package: cmake

Sorry, I think it might actually a bug in some other package (perhaps 
even libc6?), because other programs fail with near identical backtraces 
(eg: chromium --debug)...


excerpts from dmesg:
[ 4340.264256] chromium[7373]: segfault at d696914 ip 7fea99094056 
sp 7ffcffcad1f8 error 4 in ld-2.31.so[7fea99079000+2]
[ 4340.264264] Code: c7 5d 41 5c e9 3b 3d 00 00 5a 31 c0 5d 41 5c c3 0f 
1f 40 00 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 
3a <66> 0f 12 0f 66 0f 12 16 66 0f 16 4f 08 66 0f 16 56 08 66 0f ef c0
[ 5066.782306] cmake[7544]: segfault at 9691970 ip 7f7998cdb0d0 sp 
7fffe254f7c8 error 4 in ld-2.31.so[7f7998cc+2]
[ 5066.782315] Code: 39 c1 74 26 77 07 41 89 d0 91 48 87 f7 4c 8d 48 0f 
49 29 c9 4c 8d 15 67 5e 00 00 4f 63 0c 8a 4f 8d 14 0a 41 ff e2 0f 1f 40 
00 <66> 0f 6f 0e 66 0f ef c0 66 0f 74 c1 66 0f 74 0f 66 0f f8 c8 66 44

Bug#969890: cmake: segfaults in dl-lookup.c:158 check_match() "UI_set_result"

[Claude Heiland-Allen]

Package: cmake
Version: 3.18.2-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

I tried to run cmake from bullseye/testing without arguments, it segfaulted 
immediately.
Upgrading to latest from sid/unstable did not fix it.


$ valgrind cmake
==6021== Memcheck, a memory error detector
==6021== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6021== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==6021== Command: cmake
==6021== 
==6021== Invalid read of size 1
==6021==at 0x401C040: strcmp (strcmp.S:144)
==6021==by 0x4009F9B: check_match (dl-lookup.c:122)
==6021==by 0x400A3A3: do_lookup_x (dl-lookup.c:436)
==6021==by 0x400ACE0: _dl_lookup_symbol_x (dl-lookup.c:861)
==6021==by 0x400C843: elf_machine_rela (dl-machine.h:308)
==6021==by 0x400C843: elf_dynamic_do_Rela (do-rel.h:137)
==6021==by 0x400C843: _dl_relocate_object (dl-reloc.c:274)
==6021==by 0x40049A7: dl_main (rtld.c:2310)
==6021==by 0x401998E: _dl_sysdep_start (dl-sysdep.c:252)
==6021==by 0x4002033: _dl_start_final (rtld.c:485)
==6021==by 0x4002033: _dl_start (rtld.c:575)
==6021==by 0x4001097: ??? (in /lib/x86_64-linux-gnu/ld-2.31.so)
==6021==  Address 0x9691974 is not stack'd, malloc'd or (recently) free'd
==6021== 
==6021== 
==6021== Process terminating with default action of signal 11 (SIGSEGV)
==6021==  Access not within mapped region at address 0x9691974
==6021==at 0x401C040: strcmp (strcmp.S:144)
==6021==by 0x4009F9B: check_match (dl-lookup.c:122)
==6021==by 0x400A3A3: do_lookup_x (dl-lookup.c:436)
==6021==by 0x400ACE0: _dl_lookup_symbol_x (dl-lookup.c:861)
==6021==by 0x400C843: elf_machine_rela (dl-machine.h:308)
==6021==by 0x400C843: elf_dynamic_do_Rela (do-rel.h:137)
==6021==by 0x400C843: _dl_relocate_object (dl-reloc.c:274)
==6021==by 0x40049A7: dl_main (rtld.c:2310)
==6021==by 0x401998E: _dl_sysdep_start (dl-sysdep.c:252)
==6021==by 0x4002033: _dl_start_final (rtld.c:485)
==6021==by 0x4002033: _dl_start (rtld.c:575)
==6021==by 0x4001097: ??? (in /lib/x86_64-linux-gnu/ld-2.31.so)
==6021==  If you believe this happened as a result of a stack
==6021==  overflow in your program's main thread (unlikely but
==6021==  possible), you can try to increase the size of the
==6021==  main thread stack using the --main-stacksize= flag.
==6021==  The main thread stack size used in this run was 8388608.
==6021== Jump to the invalid address stated on the next line
==6021==at 0x1036: ???
==6021==by 0x4009F9B: check_match (dl-lookup.c:122)
==6021==by 0x400A3A3: do_lookup_x (dl-lookup.c:436)
==6021==by 0x400ACE0: _dl_lookup_symbol_x (dl-lookup.c:861)
==6021==by 0x400C843: elf_machine_rela (dl-machine.h:308)
==6021==by 0x400C843: elf_dynamic_do_Rela (do-rel.h:137)
==6021==by 0x400C843: _dl_relocate_object (dl-reloc.c:274)
==6021==by 0x40049A7: dl_main (rtld.c:2310)
==6021==by 0x401998E: _dl_sysdep_start (dl-sysdep.c:252)
==6021==by 0x4002033: _dl_start_final (rtld.c:485)
==6021==by 0x4002033: _dl_start (rtld.c:575)
==6021==by 0x4001097: ??? (in /lib/x86_64-linux-gnu/ld-2.31.so)
==6021==  Address 0x1036 is not stack'd, malloc'd or (recently) free'd
==6021== 
==6021== 
==6021== Process terminating with default action of signal 11 (SIGSEGV)
==6021==  Bad permissions for mapped region at address 0x1036
==6021==at 0x1036: ???
==6021==by 0x4009F9B: check_match (dl-lookup.c:122)
==6021==by 0x400A3A3: do_lookup_x (dl-lookup.c:436)
==6021==by 0x400ACE0: _dl_lookup_symbol_x (dl-lookup.c:861)
==6021==by 0x400C843: elf_machine_rela (dl-machine.h:308)
==6021==by 0x400C843: elf_dynamic_do_Rela (do-rel.h:137)
==6021==by 0x400C843: _dl_relocate_object (dl-reloc.c:274)
==6021==by 0x40049A7: dl_main (rtld.c:2310)
==6021==by 0x401998E: _dl_sysdep_start (dl-sysdep.c:252)
==6021==by 0x4002033: _dl_start_final (rtld.c:485)
==6021==by 0x4002033: _dl_start (rtld.c:575)
==6021==by 0x4001097: ??? (in /lib/x86_64-linux-gnu/ld-2.31.so)
==6021== 
==6021== HEAP SUMMARY:
==6021== in use at exit: 0 bytes in 0 blocks
==6021==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==6021== 
==6021== All heap blocks were freed -- no leaks are possible
==6021== 
==6021== For lists of detected and suppressed errors, rerun with: -s
==6021== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault


$ gdb cmake
GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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:
.

Bug#962651: Version 0.98 released

[Rob Allen]

Upstream has now released version 0.98 of rst2pdf which removes the pdfrw 
dependency.

* https://github.com/rst2pdf/rst2pdf/releases/tag/0.98 
<https://github.com/rst2pdf/rst2pdf/releases/tag/0.98>
* https://pypi.org/project/rst2pdf/0.98/ <https://pypi.org/project/rst2pdf/>


Regards,

Rob
-- 
Rob Allen
rst2pdf Project Lead
https://rst2pdf.org <https://rst2pdf.org/>

Bug#968908: linux-image-5.7.0-2-amd64: amdgpu regression fails to load firmware for RX580

[Claude Heiland-Allen]

On 23/08/2020 22:28, Salvatore Bonaccorso wrote:

On Sun, Aug 23, 2020 at 08:25:02PM +0100, Claude Heiland-Allen wrote:

On 23/08/2020 17:33, Claude Heiland-Allen wrote:

Booting with the previous kernel successfully gets to the desktop:
linux-image-5.7.0-1-amd64

Upstream Linux 5.7.17 built from source works also: $ uname -a
Linux eiskaffee 5.7.17 #1 SMP Sun Aug 23 19:59:44 BST 2020 x86_64 GNU/Linux

5.7.17-1 for unstable was uploaded today. Once the built packages are
available, can you check with that version?

Just tried linux-image-5.7.0-3-amd64, seems to work fine again:

$ uname -a
Linux eiskaffee 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23) x86_64 
GNU/Linux

Bug#968908: linux-image-5.7.0-2-amd64: amdgpu regression fails to load firmware for RX580

[Claude Heiland-Allen]

On 23/08/2020 17:33, Claude Heiland-Allen wrote:

Booting with the previous kernel successfully gets to the desktop:
linux-image-5.7.0-1-amd64


Upstream Linux 5.7.17 built from source works also: $ uname -a
Linux eiskaffee 5.7.17 #1 SMP Sun Aug 23 19:59:44 BST 2020 x86_64 GNU/Linux

dmesg attached.

[0.00] Linux version 5.7.17 (claude@eiskaffee) (gcc version 10.1.0 (Debian 10.1.0-6), GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Sun Aug 23 19:59:44 BST 2020
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.7.17 root=UUID=65fa0822-69e0-4c98-86fa-d674dd12936f ro amdgpu.dc=1 hugepagesz=1GB default_hugepagesz=1GB hugepages=4
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x000a-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x09d7] usable
[0.00] BIOS-e820: [mem 0x09d8-0x09ff] reserved
[0.00] BIOS-e820: [mem 0x0a00-0x0a1f] usable
[0.00] BIOS-e820: [mem 0x0a20-0x0a209fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x0a20a000-0x0aff] usable
[0.00] BIOS-e820: [mem 0x0b00-0x0b01] reserved
[0.00] BIOS-e820: [mem 0x0b02-0xdd00afff] usable
[0.00] BIOS-e820: [mem 0xdd00b000-0xdd173fff] reserved
[0.00] BIOS-e820: [mem 0xdd174000-0xdd2f5fff] usable
[0.00] BIOS-e820: [mem 0xdd2f6000-0xdd709fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdd70a000-0xde5b7fff] reserved
[0.00] BIOS-e820: [mem 0xde5b8000-0xde661fff] type 20
[0.00] BIOS-e820: [mem 0xde662000-0xdeff] usable
[0.00] BIOS-e820: [mem 0xdf00-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfd10-0xfdff] reserved
[0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved
[0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfec3-0xfec30fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] reserved
[0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00081f37] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.70 by American Megatrends
[0.00] efi:  ACPI 2.0=0xdd689000  ACPI=0xdd689000  SMBIOS=0xde482000  MEMATTR=0xd926e018  ESRT=0xd9272f98 
[0.00] SMBIOS 2.8 present.
[0.00] DMI: Micro-Star International Co., Ltd. MS-7B79/X470 GAMING PLUS (MS-7B79), BIOS A.60 12/27/2018
[0.00] tsc: Fast TSC calibration failed
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] last_pfn = 0x81f380 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B write-through
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 base 8000 mask C000 write-back
[0.00]   2 base C000 mask E000 write-back
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00082000 aka 33280M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: update [mem 0xe000-0x] usable ==> reserved
[0.00] last_pfn = 0xdf000 max_arch_pfn = 0x4
[0.00] esrt: Reserving ESRT space from 0xd9

Bug#962651: Reported yesterday

[Rob Allen]

This issue was reported to upstream on 11 August 2020 
(https://github.com/rst2pdf/rst2pdf/issues/895) and is being addressed.

-- 
Rob Allen
rst2pdf Project Lead
https://rst2pdf.org

Bug#826908: python3 support

[Rob Allen]

On Wed, 24 Jul 2019 10:57:55 +0200 Elena ``of Valhalla''  
wrote:
> I've updated the forwarded-to-address (hopefully :) ) to the new
> upstream ticket, which is closed as implemented.
> 
> the setup.py and readme, however, are still claiming that rst2pdf is
> still python2 only, so I guess that running under py3 is still not
> officially supported (but may work, by patching the setup.py and
> possibly some other file).


To round this out, rst2pdf now only supported on Python 3 and our documentation 
reflects this.

-- 
Rob Allen
rst2pdf Project Lead
https://rst2pdf.org

Bug#964561: libx11-6: [xcb] Extra reply data still left in queue

[Claude Heiland-Allen]

Package: libx11-6
Version: 2:1.6.9-2+b1
Severity: important

Dear Maintainer,

   * What led up to the situation?

xfce4-panel crashed.  sometime later firefox crashed.  The message in both 
cases was similar:

[xcb] Extra reply data still left in queue
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
xfce4-panel: ../../src/xcb_io.c:580: _XReply: Assertion 
`!xcb_xlib_extra_reply_data_left' failed.

[xcb] Extra reply data still left in queue
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
firefox: ../../src/xcb_io.c:580: _XReply: Assertion 
`!xcb_xlib_extra_reply_data_left' failed.

Now firefox and firefox-esr crash immediately on launch.
I did manage to restart xfce4-panel successfully.

I have not tried restarting my X session, as I have long-running jobs running.
I did try updating to the latest (apt upgrade), but no change in symptoms.

Reporting against libx11 as that is where the xcb_io.c source file is located.

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

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

Versions of packages libx11-6 depends on:
ii  libc62.30-4
ii  libx11-data  2:1.6.9-2
ii  libxcb1  1.14-2

libx11-6 recommends no packages.

libx11-6 suggests no packages.

-- no debconf information

Bug#963877: [Android-tools-devel] Bug#963877: apksigner: cannot execute binary file: Exec format error

[Claude Heiland-Allen]

Hi Hans-Christoph!

I have binfmt-support installed, but the kernel module is a problem as I 
don't have root on the Android device underneath the UserLAnd Debian 
install. I'll use the java -jar method, perhaps with a shell alias.  Thanks,



Claude

Bug#963877: apksigner: cannot execute binary file: Exec format error

[Claude Heiland-Allen]

On 2020-06-28 14:57, Claude Heiland-Allen wrote:

Package: apksigner
Version: 0.9-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

running Debian in UserLAnd from Fdroid on Android 7.

tried to run apksigner from bash, got error
cannot execute binary file: Exec format error

from sh invoked by make the error was more confusing, as if the jar
was interpreted as a shell script.


hello-world-debian-android$ make
apksigner sign --ks keystore.jks --ks-key-alias androidkey --ks-pass 
pass:android --key-pass pass:android --out helloworld.apk 
helloworld.aligned.apk

/usr/bin/apksigner: 1: PK��O: not found
/usr/bin/apksigner: 2: �0��@�!�7�š��Aߚ[�6MJ�: not found
/usr/bin/apksigner: 2: {c�v8���Bg�: not found
/usr/bin/apksigner: 3:K��Ocom/PK: not found
/usr/bin/apksigner: 4:K��O
  com/android/PK: not found
/usr/bin/apksigner: 5: Syntax error: ")" unexpected
make: *** [Makefile:12: helloworld.apk] Error 2





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

java -jar /usr/bin/apksigner
worked



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

Kernel: Linux 3.18.35 (SMP w/3 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 
TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C 
(charmap=UTF-8)

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

Versions of packages apksigner depends on:
ii  default-jre-headless [java8-runtime-headless] 2:1.11-72
ii  jarwrapper0.72.12
ii  openjdk-11-jre-headless [java8-runtime-headless]  11.0.7+9-1

apksigner recommends no packages.

apksigner suggests no packages.

-- no debconf information


--
https://mathr.co.uk

Bug#963877: apksigner: cannot execute binary file: Exec format error

[Claude Heiland-Allen]

Package: apksigner
Version: 0.9-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

running Debian in UserLAnd from Fdroid on Android 7.

tried to run apksigner from bash, got error
cannot execute binary file: Exec format error

from sh invoked by make the error was more confusing, as if the jar was 
interpreted as a shell script.


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

java -jar /usr/bin/apksigner
worked



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

Kernel: Linux 3.18.35 (SMP w/3 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages apksigner depends on:
ii  default-jre-headless [java8-runtime-headless] 2:1.11-72
ii  jarwrapper0.72.12
ii  openjdk-11-jre-headless [java8-runtime-headless]  11.0.7+9-1

apksigner recommends no packages.

apksigner suggests no packages.

-- no debconf information

Bug#961332: Fwd: Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear

[Timothy Allen]

On 5/6/20 21:02, Alberts Muktupāvels wrote:
> I do know that gnome-flashback is used with i3, but it is not really
> supported. Doesn't i3 have its own indicators or something like that?

i3 has a "bar" which is a bit like GNOME's mini-commander applet - it
displays output of a command (that by default shows things like battery
charge and system load), but it doesn't have any interactive bits other
than a system tray. In particular, it doesn't include a volume control,
so I really appreciated the one from gnome-flashback.

> If someone really wants the same indicators that were provided by
> gnome-flashback then it should not be hard to create them as separate
> applications with one exception - input sources. It would need to use
> the D-Bus interface provided by gnome-flashback.

I don't actually use the input-sources indicator, but I can imagine that
being important to some people.

> How do you install / configure your session? Do you use something like
> Regolith?

No, I studied the files installed by Debian's gnome-flashback package,
and figured out what I needed to modify.


Tim.

Bug#961332: Fwd: Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear

[Timothy Allen]

On 24/5/20 7:46 pm, Alberts Muktupāvels wrote:
> Mentioned things where turned into gnome-panel applet - System Indicators.

Ah, I see - and if I look in Debian's "NEWS" file, I see version 3.35.2
includes "New system indicators applet for gnome-panel". It wasn't clear
to me that "system indicators" included things like the volume control,
or that "new applet" implied that the old indicator icons were removed.

I feel like this change could have been announced a more loudly, but
thank you for explaining - I've switched from i3's built-in status-bar
to gnome-panel, and now I've got my volume slider back.

Thank you again for all the hard work you do maintaining gnome-flashback!

Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear

[Timothy Allen]

Package: gnome-flashback
Version: 3.36.3-1
Severity: normal

Dear Maintainer,

First, thank you for packaging and maintaining gnome-flashback!
It's really helped my older laptop stay useful and pleasant
to use, even as the full GNOME 3 stack is optimised for
higher-end hardware.

Recently (and I'm afraid I don't have an exact date, although
I'm pretty user it was the 3.34 → 3.36 upgrade) gnome-flashback's
standard system indicators (the volume control, Bluetooth,
the battery charging indicator, etc.) have stopped appearing in the
notification area. Other indicators (VLC, Network Manager) appear
just fine, but the system indicators are missing. This is still
true after logging out and back in, and after rebooting.

Full disclosure: I normally use gnome-flashback with the i3
window manager rather than Metacity, according to the instructions in
https://zork.net/~st/jottings/gnome-i3.html - although the only
difference between gnome-flashback's stock `gnome-flashback-metacity.session`
file and mine is that I've swapped `metacity` for
`i3` and removed `gnome-panel`. Nevertheless, the missing system
indicators are still missing if I log into a standard "GNOME Flashback
(Metacity)" session rather than my custom one.



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

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

Versions of packages gnome-flashback depends on:
ii  gnome-flashback-common   3.36.3-1
ii  libasound2   1.2.2-2.1
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libgdm1  3.34.1-3
ii  libglib2.0-0 2.64.2-1
ii  libgnome-bluetooth13 3.34.1-1
ii  libgnome-desktop-3-193.36.2-1
ii  libgnome-panel0  3.36.1-1+b1
ii  libgtk-3-0   3.24.20-1
ii  libibus-1.0-51.5.22-5
ii  libpam0g 1.3.1-5
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpolkit-agent-1-0  0.105-26
ii  libpolkit-gobject-1-00.105-26
ii  libpulse-mainloop-glib0  13.0-5
ii  libpulse013.0-5
ii  libsystemd0  245.5-3
ii  libupower-glib3  0.99.11-2
ii  libx11-6 2:1.6.9-2+b1
ii  libx11-xcb1  2:1.6.9-2+b1
ii  libxcb-randr01.14-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.9-1
ii  libxkbfile1  1:1.1.0-1
ii  libxrandr2   2:1.5.1-1
ii  libxxf86vm1  1:1.1.4-1+b2

Versions of packages gnome-flashback recommends:
ii  dbus   1.12.16-2
ii  gnome-settings-daemon  3.36.1-1
ii  libpam-gnome-keyring   3.36.0-1

Versions of packages gnome-flashback suggests:
ii  gnome-power-manager  3.32.0-2

-- no debconf information

Bug#960164: xterm: forceBoxChars mode + cjkWidth mode renders oddly

[Timothy Allen]

Package: xterm
Version: 356-1
Severity: minor

Steps to reproduce:

  - Launch xterm in "CJK width" mode, forcing xterm to render
box-drawing characters itself:

xterm -cjk_width +fbx

  - Run the following command to print some box-drawing characters:

python3 -c 'print("a\u2500\u2500\u2500b\na\u2550\u2550\u2550b\n")'

Expected results:

In non-CJK-width mode, all the printed characters are one character-cell
wide, so the output looks like this (assuming the browser/email client
you're using also uses non-CJK-width mode):

a───b
a═══b

However, the box-drawing characters are "East-Asian Width: Ambiguous"
in Unicode, so in CJK-width mode they should occupy 2 character cells,
looking something like this:

a──b
a══b

Actual results:

a───   b
a═ ═ ═ b

For the second line, I guess xterm doesn't actually treat those box-drawing
characters specially, so it just pads them out, which is fair enough.

For the first line, though, xterm understands the box-drawing characters
should be wide, and it leaves room for them to be wide, but it draws them
narrow. At the very least, if it's going to draw them narrow it should pad
them out like the second line, but if it's going to draw them it might as
well draw them the correct width to begin with.



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

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

Versions of packages xterm depends on:
ii  libc6   2.30-4
ii  libfontconfig1  2.13.1-4
ii  libfreetype62.10.1-2
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.2-1
ii  libutempter01.1.6-6
ii  libx11-62:1.6.9-2+b1
ii  libxaw7 2:1.0.13-1+b2
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+5

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#882768: gargoyle-free: please add %U to gargoyle.desktop

[Timothy Allen]

Rather than adding %U (which according to the spec means "a list of
URLs"), it would be better to use "%f" ("A single file name") since
according to the manpage Gargoyle can only load one file at a time, and
does not support URLs.

Bug#939559: x86_64-w64-mingw32-g++-win32: program compiled with -march=native crashes on same CPU

[Claude Heiland-Allen]

Hi Bernhard, Stephen,

Thanks for the links to the upstream bug reports.  Seems a long-standing 
problem.


On 08/09/2019 00:00, Bernhard Übelacker wrote:

Not considering any side effects and maybe other
instructions with alignment requirements.
I used the attached patch which is a bit more brutal (replaces more vmov 
variants, just in case) and now my real program is crash free. Inspired by
https://stackoverflow.com/questions/5983389/how-to-align-stack-at-32-byte-boundary-in-gcc#answer-6025561 
.



Maybe at least better than disabling AVX2 entirely?

Yes.  Thanks again,


Claude

diff -ru src.old/gcc/config/i386/i386.md src.new/gcc/config/i386/i386.md
--- src.old/gcc/config/i386/i386.md	2019-01-08 09:56:36.0 +
+++ src.new/gcc/config/i386/i386.md	2019-09-08 09:01:02.558639937 +0100
@@ -2055,7 +2055,7 @@
 	  || misaligned_operand (operands[1], XImode))
 	return "vmovdqu32\t{%1, %0|%0, %1}";
   else
-	return "vmovdqa32\t{%1, %0|%0, %1}";
+	return "vmovdqu32\t{%1, %0|%0, %1}";
 
 default:
   gcc_unreachable ();
@@ -2091,11 +2091,11 @@
   else
 	{
 	  if (get_attr_mode (insn) == MODE_V8SF)
-	return "vmovaps\t{%1, %0|%0, %1}";
+	return "vmovups\t{%1, %0|%0, %1}";
 	  else if (get_attr_mode (insn) == MODE_XI)
-	return "vmovdqa32\t{%1, %0|%0, %1}";
+	return "vmovdqu32\t{%1, %0|%0, %1}";
 	  else
-	return "vmovdqa\t{%1, %0|%0, %1}";
+	return "vmovdqu\t{%1, %0|%0, %1}";
 	}
 
 default:
@@ -2153,11 +2153,11 @@
   else
 	{
 	  if (get_attr_mode (insn) == MODE_V4SF)
-	return "%vmovaps\t{%1, %0|%0, %1}";
+	return "%vmovups\t{%1, %0|%0, %1}";
 	  else if (get_attr_mode (insn) == MODE_XI)
-	return "vmovdqa32\t{%1, %0|%0, %1}";
+	return "vmovdqu32\t{%1, %0|%0, %1}";
 	  else
-	return "%vmovdqa\t{%1, %0|%0, %1}";
+	return "%vmovdqu\t{%1, %0|%0, %1}";
 	}
 
 default:
@@ -2263,14 +2263,14 @@
 	  /* Handle AVX512 registers set.  */
 	  if (EXT_REX_SSE_REG_P (operands[0])
 	  || EXT_REX_SSE_REG_P (operands[1]))
-	return "vmovdqa64\t{%1, %0|%0, %1}";
-	  return "%vmovdqa\t{%1, %0|%0, %1}";
+	return "vmovdqu64\t{%1, %0|%0, %1}";
+	  return "%vmovdqu\t{%1, %0|%0, %1}";
 
 	case MODE_V2SF:
 	  gcc_assert (!TARGET_AVX);
 	  return "movlps\t{%1, %0|%0, %1}";
 	case MODE_V4SF:
-	  return "%vmovaps\t{%1, %0|%0, %1}";
+	  return "%vmovups\t{%1, %0|%0, %1}";
 
 	default:
 	  gcc_unreachable ();
@@ -2471,12 +2471,12 @@
 	case MODE_SI:
   return "%vmovd\t{%1, %0|%0, %1}";
 	case MODE_TI:
-	  return "%vmovdqa\t{%1, %0|%0, %1}";
+	  return "%vmovdqu\t{%1, %0|%0, %1}";
 	case MODE_XI:
-	  return "vmovdqa32\t{%g1, %g0|%g0, %g1}";
+	  return "vmovdqu32\t{%g1, %g0|%g0, %g1}";
 
 	case MODE_V4SF:
-	  return "%vmovaps\t{%1, %0|%0, %1}";
+	  return "%vmovups\t{%1, %0|%0, %1}";
 
 	case MODE_SF:
 	  gcc_assert (!TARGET_AVX);
@@ -3351,13 +3351,13 @@
   else
 	{
 	  if (get_attr_mode (insn) == MODE_V4SF)
-	return "%vmovaps\t{%1, %0|%0, %1}";
+	return "%vmovups\t{%1, %0|%0, %1}";
 	  else if (TARGET_AVX512VL
 		   && (EXT_REX_SSE_REG_P (operands[0])
 		   || EXT_REX_SSE_REG_P (operands[1])))
-	return "vmovdqa64\t{%1, %0|%0, %1}";
+	return "vmovdqu64\t{%1, %0|%0, %1}";
 	  else
-	return "%vmovdqa\t{%1, %0|%0, %1}";
+	return "%vmovdqu\t{%1, %0|%0, %1}";
 	}
 
 case TYPE_MULTI:
@@ -3519,11 +3519,11 @@
 	  return "%vmovsd\t{%1, %0|%0, %1}";
 
 	case MODE_V4SF:
-	  return "%vmovaps\t{%1, %0|%0, %1}";
+	  return "%vmovups\t{%1, %0|%0, %1}";
 	case MODE_V8DF:
-	  return "vmovapd\t{%g1, %g0|%g0, %g1}";
+	  return "vmovupd\t{%g1, %g0|%g0, %g1}";
 	case MODE_V2DF:
-	  return "%vmovapd\t{%1, %0|%0, %1}";
+	  return "%vmovupd\t{%1, %0|%0, %1}";
 
 	case MODE_V2SF:
 	  gcc_assert (!TARGET_AVX);
@@ -3713,9 +3713,9 @@
 	  return "%vmovss\t{%1, %0|%0, %1}";
 
 	case MODE_V16SF:
-	  return "vmovaps\t{%g1, %g0|%g0, %g1}";
+	  return "vmovups\t{%g1, %g0|%g0, %g1}";
 	case MODE_V4SF:
-	  return "%vmovaps\t{%1, %0|%0, %1}";
+	  return "%vmovups\t{%1, %0|%0, %1}";
 
 	case MODE_SI:
 	  return "%vmovd\t{%1, %0|%0, %1}";
diff -ru src.old/gcc/config/i386/mmx.md src.new/gcc/config/i386/mmx.md
--- src.old/gcc/config/i386/mmx.md	2018-01-03 10:03:58.0 +
+++ src.new/gcc/config/i386/mmx.md	2019-09-08 09:00:47.482620221 +0100
@@ -124,16 +124,16 @@
 	return "%vmovd\t{%1, %0|%0, %1}";
 	  return "%vmovq\t{%1, %0|%0, %1}";
 	case MODE_TI:
-	  return "%vmovdqa\t{%1, %0|%0, %1}";
+	  return "%vmovdqu\t{%1, %0|%0, %1}";
 	case MODE_XI:
-	  return "vmovdqa64\t{%g1, %g0|%g0, %g1}";
+	  return "vmovdqu64\t{%g1, %g0|%g0, %g1}";
 
 	case MODE_V2SF:
 	  if (TARGET_AVX && REG_P (operands[0]))
 	return "vmovlps\t{%1, %0, %0|%0, %0, %1}";
 	  return "%vmovlps\t{%1, %0|%0, %1}";
 	case MODE_V4SF:
-	  return "%vmovaps\t{%1, %0|%0, %1}";
+	  return "%vmovups\t{%1, %0|%0, %1}";
 
 	default:
 	  gcc_unreachable ();
diff -ru src.old/gcc/config/i386/sse.md src.new/gcc/config/i386/sse.md
--- src.old/gcc/config/i386/sse.md	2019-06-20 

Bug#939559: x86_64-w64-mingw32-g++-win32: program compiled with -march=native crashes on same CPU

[Claude Heiland-Allen]

Package: g++-mingw-w64-x86-64
Version: 8.3.0-19+21.4
Severity: normal
File: /usr/bin/x86_64-w64-mingw32-g++-win32

Dear Maintainer,

I wrote this C++ source code and saved it in `bug.cpp`:

    #include 
    #include 
    #include 

    typedef int64_t int2  __attribute__ ((vector_size (16)));
    typedef int64_t int4  __attribute__ ((vector_size (32)));
    typedef int64_t int8  __attribute__ ((vector_size (64)));
    typedef int64_t int16 __attribute__ ((vector_size (128)));

    __attribute__ ((noinline))
    bool any(const int64_t ) {
  return i;
    }

    __attribute__ ((noinline))
    bool any(const int2 ) {
  return (((i[0] || i[1])));
    }

    __attribute__ ((noinline))
    bool any(const int4 ) {
  return (((i[0] || i[1]) || (i[2] || i[3])));
    }

    __attribute__ ((noinline))
    bool any(const int8 ) {
  return (((i[0] || i[1]) || (i[2] || i[3])) ||
 ((i[4] || i[5]) || (i[6] || i[7])));
    }

    __attribute__ ((noinline))
    bool any(const int16 ) {
  return (((i[0] || i[1]) || (i[2] || i[3])) ||
 ((i[4] || i[5]) || (i[6] || i[7]))) ||
 (((i[8] || i[9]) || (i[10] || i[11])) ||
 ((i[12] || i[13]) || (i[14] || i[15])));
    }

    typedef double double2  __attribute__ ((vector_size (16)));
    typedef double double4  __attribute__ ((vector_size (32)));
    typedef double double8  __attribute__ ((vector_size (64)));
    typedef double double16 __attribute__ ((vector_size (128)));

    template 
    __attribute__ ((noinline))
    R broadcast(T x) { return R(x); }

    template <>
    __attribute__ ((noinline))
    double2  broadcast(double x) { double2 r = { x, x 
}; return r; }

    template <>
    __attribute__ ((noinline))
    double4  broadcast(double x) { double4 r = { x, x, 
x, x }; return r; }

    template <>
    __attribute__ ((noinline))
    double8  broadcast(double x) { double8 r = { x, x, 
x, x, x, x, x, x }; return r; }

    template <>
    __attribute__ ((noinline))
    double16 broadcast(double x) { double16 r = { x, 
x, x, x, x, x, x, x, x, x, x, x, x, x, x, x }; return r; }


    int main(int argc, char **argv)
    {
  if (argc > 1)
  {
    int N = atoi(argv[1]);
    switch (N)
    {
  case 1:  { double   x = broadcast(1.0); 
return any(x != 1.0); }
  case 2:  { double2  x = broadcast(1.0); 
return any(x != 1.0); }
  case 4:  { double4  x = broadcast(1.0); 
return any(x != 1.0); }
  case 8:  { double8  x = broadcast(1.0); 
return any(x != 1.0); }
  case 16: { double16 x = broadcast(1.0); 
return any(x != 1.0); }

    }
  }
  return 1;
    }

I compiled it like this:

    $ x86_64-w64-mingw32-g++ bug.cpp -march=native -O3
    bug.cpp: In function ‘R broadcast(T) [with R = __vector(8) double; 
T = double]’:
    bug.cpp:56:45: warning: AVX512F vector return without AVX512F 
enabled changes the ABI [-Wpsabi]
 double8  broadcast(double x) { double8  r = { x, 
x, x, x, x, x, x, x }; return r; }

 ^

I ran it on the same host like this, and it crashed:

    $ ./a.exe 4
    wine: Unhandled page fault on read access to 0x at 
address 0x4016a8 (thread 002a), starting debugger...

    002c:fixme:dbghelp:elf_search_auxv can't find symbol in module
    002c:fixme:dbghelp:elf_search_auxv can't find symbol in module
    002c:fixme:dbghelp:elf_search_auxv can't find symbol in module
    002c:fixme:dbghelp:elf_search_auxv can't find symbol in module
    002c:fixme:dbghelp:elf_search_auxv can't find symbol in module
    Unhandled exception: page fault on read access to 
0x in 64-bit code (0x004016a8).

    002c:fixme:dbghelp:elf_search_auxv can't find symbol in module
    002c:fixme:dbghelp:interpret_function_table_entry PUSH_MACHFRAME 6
    Register dump:
 rip:004016a8 rsp:0032f928 rbp:004619e0 
eflags:00010203 (  R- --  I   - - -C)
 rax:0032fa10 rbx:0032fa80 rcx:0032fa10 
rdx:00405000
 rsi:0002 rdi:004619e0 r8:ffd0  
r9: r10:0002
 r11:00461a68 r12:0018 r13:0010 
r14: r15:

    Stack dump:
    0x0032f928:  004031e8 
    0x0032f938:   
    0x0032f948:   00202020
    0x0032f958:  2000 00ff
    0x0032f968:  00ff 00202020
    0x0032f978:   
    0x0032f988:   
    0x0032f998:   
    0x0032f9a8:   
    0x0032f9b8:   
    0x0032f9c8:   
    0x0032f9d8:   

Bug#931802: evolution: Text gets permanently deleted while composing an email reply

[Timothy Allen]

Package: evolution
Version: 3.32.2-1
Severity: important

Forwarded-To: https://gitlab.gnome.org/GNOME/evolution/issues/531

**Steps to reproduce:**

- I sent myself a plain text email containing a single line of text:

  abc

- When I received the email, I hit Ctrl-R to reply
- As per my configuration, Evolution opens a new plain-text compose window with
the email content quoted:

  On (time and date), Screwtapello wrote:
  > abc

- I select the text `abc` with my mouse
- I press the Delete key on my keyboard to delete it
- The "Undo" button on the toolbar becomes enabled, since an editing action has
been performed
- I click the "Undo" button on the toolbar to bring it back

**Actual results:**

- The "Undo" button becomes disabled, as though there's nothing to undo
- The deleted text does not reappear

**Expected results:**

- The deleted text reappears
- The "Undo" button becomes disabled, since there's nothing left to undo



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages evolution depends on:
ii  dbus   1.12.16-1
ii  evolution-common   3.32.2-1
ii  evolution-data-server  3.32.2-2
ii  libc6  2.28-10
ii  libcamel-1.2-623.32.2-2
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-1.2-19 3.32.2-2
ii  libedataserver-1.2-24  3.32.2-2
ii  libevolution   3.32.2-1
ii  libglib2.0-0   2.58.3-2
ii  libgtk-3-0 3.24.5-1
ii  libical3   3.0.4-3
ii  libnotify4 0.7.7-4
ii  libsoup2.4-1   2.64.2-2
ii  libwebkit2gtk-4.0-37   2.24.2-1
ii  libxml22.9.4+dfsg1-7+b3
ii  psmisc 23.2-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.32.2-1
ii  evolution-plugin-pstimport   3.32.2-1
ii  evolution-plugins3.32.2-1
ii  yelp 3.31.90-1

Versions of packages evolution suggests:
pn  evolution-ews   
ii  evolution-plugins-experimental  3.32.2-1
ii  gnupg   2.2.12-1
ii  network-manager 1.14.6-2

-- debconf information:
  evolution/needs_shutdown:
  evolution/kill_processes:

Bug#923309: cacti-spine_1.1.37-2~bpo9+1 fails to run under non-root user

[Paul Allen]

Sorry for the late reply, work became insane after this.

I upgraded to the new cacti-spine again and ran the setcap command and
it is working for the non-root user now. Thanks for the assistance on
this. The bug can now be closed.

Paul Allen

Inetz Sr. Systems Administrator
801-415-2562

On 3/14/19 5:03 AM, Paul Gevers wrote:
> Control: tags -1 moreinfo
>
> Hi Paul
>
> On 27-02-2019 21:53, Sven Hartge wrote:
>> On 27.02.19 21:35, Paul Gevers wrote:
>>
>>> @Paul, Thanks for reporting this issue. Please check the existing
>>> comments in bug 904332
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904332
>>>
>>> @Sven can you please help us and maybe explain how Paul should be using
>>> the cacti-spine binary with these Linux capabilities enabled that we
>>> added in that version by your patch. I guess he needs to install
>>> libcap2-bin and run $(chmod u-s /usr/sbin/spine)
>> Yes, but one additional step:
>>
>> You also need to set the capabilities:
>>
>>setcap cap_net_raw+ep /usr/sbin/spine
>>
>> After that, everything should be back in working order.
>>
>> If not, then the bug is at a different place. Also the missing setuid
>> bit and the missing capabilities only prevent the use of the
>> ICMP-Checker for Host Liveliness Checking, but not the failure to run at
>> all.
>>
>> Without those two bits in place, SNMP gathering will still work.
> Did the reply from Sven help? I.e. do you think this bug can be closed?
>
> Paul
>

Bug#923309: cacti-spine_1.1.37-2~bpo9+1 fails to run under non-root user

[Paul Allen]

Package: cacti-spine
Version: 1.1.37-1~bpo9+1
Severity: normal

Dear Maintainer,


   * What led up to the situation?
Upgrading from cacti-spine_1.1.37-1~bpo9+1 to 
cacti-spine_1.1.37-2~bpo9+1 caused execution of cacti-spine for non-root users 
to break, even with setuid bits set for either just user or all.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Attempted to set setuid bits on /usr/sbin/spine to permit execution by 
non-root users (eg, cacti). Attempted to debug by running "/usr/sbnin/spine 
-H=180 -R -S -V=5" and "/usr/sbin/spine -h" as both root and cacti users.
   * What was the outcome of this action?
/usr/sbin/spine would fail silently when executed by cacti user but 
would run successfully when executed by root user. Example: 
cacti@mon1:~# /usr/sbin/spine -H=180 -R -S -V=5
cacti@mon1:~#
cacti@mon1:~# /usr/sbin/spine -h
cacti@mon1:~#

   * What outcome did you expect instead?
Expected spine to execute successfully for non-root cacti user once 
setuid bit(s) were set.

Re-installing cacti-spine_1.1.37-2~bpo9+1 had no effect, Removing and re-adding 
setuid bits had no effect. Once I rolled the package back to 
cacti-spine_1.1.37-1~bpo9+1 and set the setuid bit for the user it started 
executing successfully again for the no-root cacti user with no other changes 
necessary.



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

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

Versions of packages cacti-spine depends on:
ii  cacti  1.1.38+ds1-1~bpo9+1
ii  dbconfig-no-thanks 2.0.11~bpo9+1
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u4
ii  libmariadbclient18 10.1.37-0+deb9u1
ii  libsnmp30  5.7.3+dfsg-1.7+deb9u1
ii  ucf3.0036

cacti-spine recommends no packages.

Versions of packages cacti-spine suggests:
ii  snmp-mibs-downloader  1.1+nmu1

-- no debconf information

Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer

[Tim Allen]

I've done some more research, and come up with more details.

As I understand it, the original X-COM for DOS was released as version
1.0, then had a bunch of fixes up to version 1.4. Later, a "collector's
edition" was released which ported the game to Windows and included even
more fixes.

PCGamingWiki says[1] that the GOG build is straight up version 1.4,
bundled with DOSBox to make it run on modern OSs. It also says that the
Steam build uses the 1.4 engine for DOS, but with some Collector's
Edition data files.

[1]: https://pcgamingwiki.com/wiki/X-COM:_UFO_Defense#Availability

I found some details on the files that shipped with the Collector's
Edition, so together with the official patches I acquired earlier, I
believe I can trace all these variations.

Going back to the original list of missing files...

# assets not in setup_xcom_ufo_defense_2.0.0.4.exe:
#   group_members: |
# 44288 6a2b1ec8182f5025ee505c6949356925 GEODATA/BIGLETS.DAT
# 12456 5ae490e16959e1961071f0172c793c94 GEODATA/SMALLSET.DAT

These files come from the Collector's Edition. Compared to the 1.4
versions, they add extra characters that weren't in the original DOS
character set[2][3]. I imagine the DOS engine doesn't actually use them,
but OpenXCOM might.

[2]: https://www.ufopaedia.org/index.php/BIGLETS.DAT
[3]: https://www.ufopaedia.org/index.php/SMALLSET.DAT

# 46601 1770cf9f3a18350c7afa54b0e271c359 GEODATA/ENGLISH.DAT
# 52672 eacbbca8d2de655cda7aa403702bec46 GEODATA/FRENCH.DAT
# 53587 1cd8dd5069970d0f2a6983339057a34b GEODATA/GERMAN.DAT

These files come from the Collector's Edition. Comparing them to the
1.4 versions, the only differences are that the message "Quit to DOS"
(or its translated equivalent) has been changed to "Quit" (or
translated etc.).

# 93853 7194c1480e6ce2d3e188133ece4fdefb SOUND/ROLAND.CAT

As discussed previously, this file comes from the 1.4 patch.

Looking at the original list of obsolete files:

# obsolete:
#   group_members: |
# 32768 9f20ed66008a2fbc055c10db74c44307 GEODATA/BIGLETS.DAT?orig
# 9216  3943027ebeab34adfa3d31c04adc886d GEODATA/SMALLSET.DAT?orig

These are the versions from the GOG release, and since they doesn't
appear in any other patches, presumably from the original 1.0 release.

# 46608 a28031075f0e531d5896ffca8125d7bc GEODATA/ENGLISH.DAT?orig
# 52679 1538fc2f7d85aa81d06b4bff319d9902 GEODATA/FRENCH.DAT?orig
# 53594 342570230da352242219d6fea289d8b1 GEODATA/GERMAN.DAT?orig

These are the versions from the 1.2 and 1.3 patches.

Lastly, the mysterious extra ROLAND.CAT. As I understand it:

  - 1.0 through 1.3 came with music data for AdLib (in ADLIB.CAT) and
Roland CM-32 (in ROLAND.CAT) devices.
  - 1.4 switched to a different music engine[4], which used different
formats. ADLIB.CAT was updated to use the new format, and a new
GM.CAT was supplied to support General MIDI devices, but ROLAND.CAT
was left untouched.
  - Therefore, if you tried to use Roland CM-32 support in 1.4, the game
would hang[5] as the new music engine tried to interpret the
ROLAND.CAT file in the old format.
  - A fan reverse-enginered the old and new file-formats and repackaged
the Roland music data from 1.3 in the format 1.4 expects[6],
which is the version bundled with the GOG release.
  - However, OpenXCOM does not use or care about ROLAND.CAT, only
GM.CAT, so there's no point packaging it at all.

[4]: https://www.ufopaedia.org/index.php/SOUND
[5]: 
https://pcgamingwiki.com/wiki/X-COM:_UFO_Defense#Game_hang_when_attempting_to_use_the_MT-32_in_version_1.4_.28DOS.29
[6]: https://www.vogons.org/viewtopic.php?t=21542l=32

On Sat, Feb 02, 2019 at 11:06:29AM +, Simon McVittie wrote:
> On Sat, 02 Feb 2019 at 20:17:38 +1100, Tim Allen wrote:
> > I found a site[1] claiming to host the official 1.1, 1.2, 1.3 and 1.4
> > patches, alongside a bunch of other unofficial patches. It turns out
> > that the ROLAND.CAT that game-data-packager was looking for (MD5:
> > 7194c14...) is part of the UFO 1.4 update. The site says[2]:
> > 
> > # This patch fixes many stability issues, some game stopping research
> > # bugs And removed the startup copy protection. However it also replaces
> > # the sounds with ones that are not as good as the originals.
> 
> Should we be preferring to package the unpatched ROLAND.CAT (143866 bytes, as
> shipped by GOG) rather than the v1.4 ROLAND.CAT (93853 bytes, as shipped by
> Steam) if we can see both, then? The YAML syntax lets us prefer one version
> over others.

Now that I know OpenXCOM doesn't use it, there's probably no point
packaging it at all. Perhaps OpenXCOM might use it at some point in the
future, but that seems very unlikely given that GM.CAT is almost exactly
the same thing, and ADLIB.CAT is probably the one people care about for
nostalgic reasons.

> > The B

Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer

[Tim Allen]

On Thu, Jan 31, 2019 at 09:38:51AM +, Simon McVittie wrote:
> On Wed, 19 Dec 2018 at 13:47:54 +1100, Timothy Allen wrote:
> > I extracted the installer with innoextract, and manually copied the
> > directories listed for Nightly builds in the OpenXcom documentation[1]
> > to the place where OpenXcom looks, and successfully began a new game
> > and played a mission. I don't know how exhaustively OpenXcom checks its
> > datafiles at startup, but it seemed good to me.
> 
> Thanks. It looks as though the GOG package contains different
> (original/unpatched?) versions of ROLAND.CAT and the five GEODATA files in the
> "obsolete" group. I don't know of anywhere that we can download
> replacement/patched/updated copies of those files, but if the ones shipped by
> GOG work in practice, presumably they're good enough?

I found a site[1] claiming to host the official 1.1, 1.2, 1.3 and 1.4
patches, alongside a bunch of other unofficial patches. It turns out
that the ROLAND.CAT that game-data-packager was looking for (MD5:
7194c14...) is part of the UFO 1.4 update. The site says[2]:

# This patch fixes many stability issues, some game stopping research
# bugs And removed the startup copy protection. However it also replaces
# the sounds with ones that are not as good as the originals.

The BIGLETS.DAT and SMALLSET.DAT files don't appear in any
patch, official or unofficial, expected hash or otherwise, so I have no
idea where they came from, or why the Steam and GOG releases differ.

The "obsolete" ENGLISH.DAT, FRENCH.DAT and GERMAN.DAT that the GOG
release includes come from the 1.2 and 1.3 official patches. The
versions that game-data-packager expected aren't present.


I mention this all just for completeness; thank you for updating the
game-data-packager package!


[1]: http://www.strategycore.co.uk/files/ufo-enemy-unknown/patches/
[2]: http://www.strategycore.co.uk/files/ufo-1.4/

Bug#920158: stterm: Crash when displaying emoji

[Timothy Allen]

On Tue, 2019-01-29 at 23:56 +0100, Paride Legovini wrote:
> I will report it there, unless you want to report it
> yourself (see https://suckless.org/community/).

Please, go ahead!

Bug#920158: stterm: Crash when displaying emoji

[Timothy Allen]

On Thu, 2019-01-24 at 13:17 +0100, Paride Legovini wrote:
> Thanks for your report. Unfortunately I can't reproduce the crash (I
> actually get an octagonal sign with that printf), so it is difficult
> for
> me to debug the issue or forward the bug upstream.

Thanks for looking into it!

Out of curiosity, what fonts do you have installed? When I search for
fonts on my system that provide OCTAGONAL SIGN, I only get one match:

$ fc-list :charset=0x1F6D1
/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf: Noto Color 
Emoji:style=Regular

(from the fonts-noto-color-emoji package)

It looks like st does glyph-scavenging so it can display glyphs that
aren't in the selected font; perhaps it's not prepared to handle fonts
that provide colour bitmaps.

(I notice xterm added glyph-scavenging support in version 338 on 2018-
12-09, and subsequent versions have added various checks and safeguards
to avoid colour bitmap fonts rather than support them)

Bug#920158: stterm: Crash when displaying emoji

[Timothy Allen]

Package: stterm
Version: 0.8.1-2
Severity: important

Steps to reproduce:

 1. Launch st with the DejaVu Sans Mono font:

st -f "DejaVu Sans Mono-10"

 2. Run the following command:

printf '\xf0\x9f\x9b\x91\n'

Expected result:

  - st displays U+1F6D1 OCTAGONAL SIGN, or some kind of unknown character
glyph, or maybe even just a blank space.

Actual result:

  - st crashes, printing an error:

X Error of failed request:  BadLength (poly request too large or internal 
Xlib length error)
  Major opcode of failed request:  139 (RENDER)
  Minor opcode of failed request:  20 (RenderAddGlyphs)
  Serial number of failed request:  949
  Current serial number in output stream:  985

Note that with st's compiled-in default font, whatever it is, it displays a
blank space of the appropriate size instead of crashing. I discovered this
crash with Noto Sans Mono from the fonts-noto-core package, but I was able
to reproduce it with the much more widely available DejaVu Sans Mono.

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

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

Versions of packages stterm depends on:
ii  libc6   2.28-5
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3
ii  libx11-62:1.6.7-1
ii  libxft2 2.3.2-2
ii  ncurses-term6.1+20181013-1

stterm recommends no packages.

stterm suggests no packages.

-- no debconf information

Bug#919543: apt: when installing with deb file, prerm maintainer script doesn't pass new-package-name before it's replaced due to conflict

[Allen]

Package: apt
Version: 1.2.19
Severity: normal

Dear Maintainer,


I am creating a deb packages which will replace another package. And before the
old package are removed, I want to check whether the package is remove due to
**replace** operation or a simple **uninstall** operation.

In man page of `deb-prerm`, I found that when a package is replaced due to
conflict, the prerm script of old package can be called in the following way:
`prerm remove in-favour new-package new-version`.

Therefore, I add some script in prerm of old package and opreate with the shell
script variables. If I use `dpkg` to install these .deb packages, it will work
perfectly. However, it does not pass any new package information if I use `apt`
to install these packages.

Is it an existing bug? I have searched for a while and have not found any
relevant content.


Many thanks,
Allen Yang



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^linux-image-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^linux-headers-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^linux-headers-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^gnumach-image-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^gnumach-image-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^.*-modules-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^.*-modules-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^.*-kernel-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^.*-kernel-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.15\.0-43-generic$";
APT::NeverAutoRemove:: "^linux-tools-4\.15\.0-42-generic$";
APT::NeverAutoRemove:: "^linux-tools-4\.15\.0-43-generic$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "1";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "touch 
/var/lib/apt/periodic/update-success-stamp 2>/dev/null || true";
AP

Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer

[Timothy Allen]

On Sat, 2018-12-15 at 11:37 +, Simon McVittie wrote:
> On Sat, 15 Dec 2018 at 15:22:18 +1100, Timothy Allen wrote:
> > I discovered the "game-data-packager make-template" command;
> > attached
> > is the output from:
> > 
> > game-data-packager make-template --base xcom-ufo \
> > setup_xcom_ufo_defense_2.0.0.4.exe
> 
> Does openxcom work if you have the SOUND/ROLAND.CAT from
> setup_xcom_ufo_defense_2.0.0.4.exe instead of the (much smaller) one
> from the current file list, and if you don't have the other files
> listed in "assets not in setup_xcom_ufo_defense_2.0.0.4.exe"?

I extracted the installer with innoextract, and manually copied the
directories listed for Nightly builds in the OpenXcom documentation[1]
to the place where OpenXcom looks, and successfully began a new game
and played a mission. I don't know how exhaustively OpenXcom checks its
datafiles at startup, but it seemed good to me.

I'm not sure how to interpret the "assets not in
setup_xcom_ufo_defense_2.0.0.4.exe" section. For example, it starts off
looking for a file named "GEODATA/BIGLETS.DAT" with an MD5 of 6a2b1...
and it's correct that such a file doesn't exist. The setup file's
BIGLETS.DAT has an MD5 of 9f20e... and the generated manifest maps that
MD5sum to the name "GEODATA/BIGLETS.DAT?orig". In fact, all the "assets
not in setup..." other than ROLAND.CAT are all in the "obsolete" group
with the "?orig" suffix.

[1]: https://www.ufopaedia.org/index.php?title=Installing_(OpenXcom)

> Are any of the other files listed in "remaining contents of
> setup_xcom_ufo_defense_2.0.0.4.exe" required?

If I delete the SOUND/* files and UFOINTRO/* files listed in "remaining
contents..." (other than SOUND/ROLAND.CAT) then OpenXcom still works,
so I guess they're not required.

None of the other "remaining contents..." are mentioned in the OpenXcom
docs, so I guess they're irrelevant.

Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer

[Timothy Allen]

Package: game-data-packager
Version: 61
Severity: normal

Dear Maintainer,

I bought X-Com: UFO Defense from GOG.com, and downloaded it with
"lgogdownloader" (packaged by Debian), producing a file named
setup_xcom_ufo_defense_2.0.0.4.exe, with MD5sum
2bf8035e375a2510807dcc27499d5f99.

I ran "game-data-packager xcom-ufo
/path/to/setup_xcom_ufo_defense_2.0.0.4.exe", the installer files were
extracted, and it printed a whole lot of "identifying..." lines, then spat out
some errors:

[...]
identifying
/tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/SMALLSET.DAT
identifying
/tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/BIGLETS.DAT
identifying
/tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/GERMAN.DAT
identifying
/tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/ENGLISH.DAT
identifying
/tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/FRENCH.DAT
[...]
WARNING:game_data_packager.build:found possible "sound/roland.cat" but it is
not one of the expected versions:
file:
/tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/SOUND/ROLAND.CAT
size:   143866 bytes
md5:8421cdcbe91b1b3e4818d470f32ca859
sha1:   14a236be4e16b7040367dea87e25549d6ff290ba
sha256: 6d98825b620eedb563f664161f86a391d60a0102c811400382ff1d9685913836
expected:
  SOUND/ROLAND.CAT:
size:   93853 bytes
md5:7194c1480e6ce2d3e188133ece4fdefb
sha1:   None
sha256: None

ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows
Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided
GEODATA/BIGLETS.DAT but did not
ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows
Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided
GEODATA/ENGLISH.DAT but did not
ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows
Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided
GEODATA/FRENCH.DAT but did not
ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows
Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided
GEODATA/GERMAN.DAT but did not
ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows
Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided
GEODATA/SMALLSET.DAT but did not
ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows
Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided
SOUND/ROLAND.CAT but did not
ERROR:game_data_packager.build:Unable to complete any packages.

I suspect that the GOG installer might already have the OpenXCOM data patch[1]
installed, although I can't find any specific statements for or against it.

[1]: https://openxcom.org/downloads-extras/



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

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

Versions of packages game-data-packager depends on:
ii  dpkg1.19.2
ii  fakeroot1.23-1
ii  python3 3.6.7-1
ii  python3-debian  0.1.33
ii  python3-yaml3.13-1

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  61

Versions of packages game-data-packager suggests:
pn  arj
ii  binutils   2.31.1-10
ii  cabextract 1.9-1
pn  cdparanoia 
pn  dynamite   
ii  gcc4:8.2.0-2
ii  gdebi  0.9.5.7+nmu2
ii  gir1.2-gdkpixbuf-2.0   2.38.0+dfsg-6
ii  innoextract1.7-2+b1
pn  lgc-pg 
ii  lgogdownloader 3.4-1+b1
pn  lhasa | jlha-utils | lzh-archiver  
ii  make   4.2.1-1.2
ii  p7zip-full 16.02+dfsg-6
ii  python3-gi 3.30.2-1
ii  steam  1.0.0.56-1
pn  steamcmd   
pn  unace-nonfree  
ii  unar   1.10.1-2+b3
pn  unrar  
pn  unshield   
ii  unzip  6.0-21
ii  vorbis-tools   1.4.0-10.1
pn  xdelta 
ii  xdelta33.0.11-dfsg-1+b1

-- no debconf information

Bug#895578: kakoune: Please update to official release v2018.04.13

[Timothy Allen]

Kakoune has just had another official release, v2018.09.04.

I'm really looking forward to having those new features without having
to build it myself from source. ;)

Bug#905732: kernel-package: fails to create debian directory (/bin/sh: 1: [: -lt: unexpected operator)

[Claude Heiland-Allen]

On 11/08/18 18:43, Claude Heiland-Allen wrote:

Worked (albeit slowly) without  -j 32.  To be precise, this worked:


I think this is an issue with using an old .config and not updating it 
properly with new variables defined in the new kernel.


Seems if I go through the make oldconfig stuff (invoked by make-kpkg) 
once successfully, with the build failing after that with the can't 
crate debian directory, then subsequently trying make-kpkg again does 
work with -j 32

Bug#905732: kernel-package: fails to create debian directory (/bin/sh: 1: [: -lt: unexpected operator)

[Claude Heiland-Allen]

On 08/08/18 19:37, Claude Heiland-Allen wrote:

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

.../linux-4.18-rc8$ make-kpkg --rootcmd=fakeroot -j 32 --initrd kernel_image 
--verbose

* What was the outcome of this action?

The build failed after a couple of seconds, with errors from /bin/sh along the 
way.



Worked (albeit slowly) without  -j 32.  To be precise, this worked:

.../linux-4.18-rc8$ make-kpkg --rootcmd=fakeroot --initrd kernel_image

Bug#905732: kernel-package: fails to create debian directory (/bin/sh: 1: [: -lt: unexpected operator)

[Claude Heiland-Allen]

With /bin/sh -> dash:

On 08/08/18 19:37, Claude Heiland-Allen wrote:

/bin/sh: 1: [: -lt: unexpected operator
/bin/sh: 1: [: -gt: unexpected operator
/bin/sh: 1: [: -lt: unexpected operator

With /bin/sh -> bash:

--8<--
/bin/sh: line 0: [: -lt: unary operator expected
/bin/sh: line 0: [: -gt: unary operator expected
/bin/sh: line 0: [: -lt: unary operator expected
--8<--

So it isn't a simple bashism.

Bug#905732: kernel-package: fails to create debian directory (/bin/sh: 1: [: -lt: unexpected operator)

[Claude Heiland-Allen]

Package: kernel-package
Version: 13.018+nmu1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I tried to make-kpkg with the latest linux-4.18-rc8

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

.../linux-4.18-rc8$ make-kpkg --rootcmd=fakeroot -j 32 --initrd kernel_image 
--verbose

   * What was the outcome of this action?

The build failed after a couple of seconds, with errors from /bin/sh along the 
way.

   * What outcome did you expect instead?

The .deb kernel package to have been built.

Full log:

8<
claude@eiskaffee:~/opt/src/linux/linux-4.18-rc8$ make-kpkg --rootcmd=fakeroot 
-j 32 --initrd kernel_image --verbose
exec make kpkg_version=13.018+nmu1 -f 
/usr/share/kernel-package/ruleset/minimal.mk debian V=1  INITRD=YES  
ROOT_CMD=fakeroot 
/bin/sh: 1: [: -lt: unexpected operator
/bin/sh: 1: [: -gt: unexpected operator
/bin/sh: 1: [: -lt: unexpected operator
== making target debian/stamp/conf/minimal_debian [new prereqs: ]==
This is kernel package version 13.018+nmu1.
test -d debian || mkdir debian
test ! -e stamp-building || rm -f stamp-building
install -p -m 755 /usr/share/kernel-package/rules debian/rules
for file in ChangeLog  Control  Control.bin86 config templates.in rules; do 
 \
cp -f  /usr/share/kernel-package/$file ./debian/;   
\
done
cp: cannot stat '/usr/share/kernel-package/ChangeLog': No such file or directory
for dir  in Config docs examples ruleset scripts pkg po;  do
  \
  cp -af /usr/share/kernel-package/$dir  ./debian/; 
\
done
test -f debian/control || sed -e 's/=V/../g'  \
-e 's/=D/..-10.00.Custom/g' -e 's/=A/amd64/g'  \
-e 's/=SA//g'  \
-e 's/=I//g'\
-e 's/=CV/./g'  \
-e 's/=M/Unknown Kernel Package Maintainer 
/g' \
-e 's/=ST/linux/g'  -e 's/=B/x86_64/g'\
-e 's/=R/initramfs-tools | linux-initramfs-tool,/g'
/usr/share/kernel-package/Control > debian/control
test -f debian/changelog ||  sed -e 's/=V/../g'   \
-e 's/=D/..-10.00.Custom/g'-e 's/=A/amd64/g'   \
-e 's/=ST/linux/g' -e 's/=B/x86_64/g' \
-e 's/=M/Unknown Kernel Package Maintainer 
/g'\
 /usr/share/kernel-package/changelog > debian/changelog
chmod 0644 debian/control debian/changelog
test -d ./debian/stamp || mkdir debian/stamp
make -f debian/rules debian/stamp/conf/kernel-conf
make[1]: Entering directory '/home/claude/opt/src/linux/linux-4.18-rc8'
dpkg-parsechangelog: warning: debian/changelog(l1): version 
'..-10.00.Custom' is invalid: version number does not start with digit
LINE: linux-source-.. (..-10.00.Custom) unstable; urgency=low
dpkg-parsechangelog: warning: debian/changelog(l1): version 
'..-10.00.Custom' is invalid: version number does not start with digit
LINE: linux-source-.. (..-10.00.Custom) unstable; urgency=low
dpkg-parsechangelog: warning: debian/changelog(l1): version 
'..-10.00.Custom' is invalid: version number does not start with digit
LINE: linux-source-.. (..-10.00.Custom) unstable; urgency=low
dpkg-parsechangelog: warning: debian/changelog(l1): version 
'..-10.00.Custom' is invalid: version number does not start with digit
LINE: linux-source-.. (..-10.00.Custom) unstable; urgency=low
dpkg-parsechangelog: warning: debian/changelog(l1): version 
'..-10.00.Custom' is invalid: version number does not start with digit
LINE: linux-source-.. (..-10.00.Custom) unstable; urgency=low
/bin/sh: 1: [: -lt: unexpected operator
/bin/sh: 1: [: -gt: unexpected operator
/bin/sh: 1: [: -lt: unexpected operator
/bin/sh: 1: [: -lt: unexpected operator
/bin/sh: 1: [: -eq: unexpected operator
/bin/sh: 1: [: -eq: unexpected operator
/bin/sh: 1: [: -lt: unexpected operator
/bin/sh: 1: [: -eq: unexpected operator
/bin/sh: 1: [: -eq: unexpected operator
/bin/sh: 1: [: -gt: unexpected operator
/bin/sh: 1: [: -ge: unexpected operator
/bin/sh: 1: [: -lt: unexpected operator
/bin/sh: 1: [: -eq: unexpected operator
/bin/sh: 1: [: -eq: unexpected operator
== making target debian/stamp/conf/kernel-conf [new prereqs: ]==
makeARCH=x86_64 \
oldconfig;
make[2]: Entering directory '/home/claude/opt/src/linux/linux-4.18-rc8'
make[2]: *** No rule to make target 'oldconfig'.  Stop.
make[2]: Leaving directory '/home/claude/opt/src/linux/linux-4.18-rc8'
make[1]: *** [debian/ruleset/targets/common.mk:199: 
debian/stamp/conf/kernel-conf] Error 2
make[1]: Leaving directory '/home/claude/opt/src/linux/linux-4.18-rc8'
make: *** [/usr/share/kernel-package/ruleset/minimal.mk:106: 
debian/stamp/conf/minimal_debian] Error 2
Failed to create a ./debian directory:  at 

Bug#904609: mandelbulber2: Fractal ui file can't be loaded

[Claude Heiland-Allen]

Hi,

On 31/07/18 14:14, Giovanni Mascellani wrote:

tags 904609 + unreproducible moreinfo
thanks

Hi,

thanks for the report. Unfortunately I cannot reproduce it.


Thanks for your reply!

I found the problem.  It was user error on my part.  I had a 
self-compiled ~/opt/bin/mandelbulber2 earlier in my PATH (I guess it is 
a separate upstream bug that it tries to access files outside of its 
installed prefix).  Using /usr/bin/mandelbulber2 (or modifying PATH to 
remove ~/opt/bin) works correctly.  Sorry for wasting your time!



Il 25/07/2018 18:32, Claude Heiland-Allen ha scritto:

Error message:

Fractal ui file can't be loaded
/usr/share/mandelbulber2/formula/ui/amazing_surf_mod2.ui

* What outcome did you expect instead?

For it to load the UI from
/usr/share/mandelbulber2/formula/ui/fractal_amazing_surf_mod2.ui

Or for the latter file to be in the initial location.

I see not error messages and the Amazing Surf Mod2 formula loads
correctly. Could you please provide a settings file that fails loading?

Also, could you try to remove or rename the directories "mandelbulber"
and ".mandelbulber" in your home directory and try again? Maybe there
was some leftover from past versions.

Giovanni.


Claude

Bug#904609: mandelbulber2: Fractal ui file can't be loaded

[Claude Heiland-Allen]

Package: mandelbulber2
Version: 2.13.2-4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Launched mandelbulber2, tried to hybrid with Amazing Surf Mod2.

   * What was the outcome of this action?

Error message:

Fractal ui file can't be loaded
/usr/share/mandelbulber2/formula/ui/amazing_surf_mod2.ui

   * What outcome did you expect instead?

For it to load the UI from
/usr/share/mandelbulber2/formula/ui/fractal_amazing_surf_mod2.ui

Or for the latter file to be in the initial location.



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

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

Versions of packages mandelbulber2 depends on:
ii  libc62.27-5
ii  libgcc1  1:8.1.0-10
ii  libgl1   1.0.0+git20180308-3
ii  libgomp1 8.1.0-10
ii  libgsl23 2.5+dfsg-4
ii  libgslcblas0 2.5+dfsg-4
ii  liblzo2-22.10-0.1
ii  libpng16-16  1.6.34-2
ii  libqt5core5a 5.10.1+dfsg-7
ii  libqt5gui5   5.10.1+dfsg-7
ii  libqt5multimedia55.10.1-2
ii  libqt5network5   5.10.1+dfsg-7
ii  libqt5test5  5.10.1+dfsg-7
ii  libqt5widgets5   5.10.1+dfsg-7
ii  libstdc++6   8.1.0-10
ii  mandelbulber2-data   2.13.2-4
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-1

mandelbulber2 recommends no packages.

mandelbulber2 suggests no packages.

-- no debconf information

Bug#897568: zfs-dkms 0.7.6 fails to build on 4.16.0-1-amd64

[John Allen]

According to the release notes (
https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.7.8), the latest
version (0.7.8) is needed to build on the 4.16 kernel.

The latest version in Debian is still 0.7.6 (in testing since 7 March
2018).

John

Bug#895578: kakoune: Please update to official release v2018.04.13

[Timothy Allen]

Package: kakoune
Version: 0~2016.12.20.1.3a6167ae-1
Severity: wishlist

After many years of continuous, undifferentiated development, Kakoune
has started tagging particular snapshots as stable releases. It would
be great to have a more up-to-date version of Kakoune in Debian!

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

Kernel: Linux 4.14.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages kakoune depends on:
ii  libboost-regex1.62.0  1.62.0+dfsg-5
ii  libc6 2.27-3
ii  libgcc1   1:8-20180402-1
ii  libncursesw5  6.1-1
ii  libstdc++68-20180402-1
ii  libtinfo5 6.1-1

kakoune recommends no packages.

kakoune suggests no packages.

-- no debconf information

Bug#882600: Notice for Allen 1P2G

[Allen D]

Stop

On Fri, Nov 24, 2017 at 10:57 AM final notice 
wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#800824:

[Chloe Allen]

Bug#839155: bash: $HOME/.local/bin missing from $PATH again

[Timothy Allen]

Adding some context: bug #820856 was marked fixed in bash-4.3-15, but
that version doesn't appear in /usr/share/doc/bash/changelog.Debian.gz
for current versions: it skips straight from 4.3-14 to 4.4~beta-1. I presume 
the -15 release came from some kind of maintenance branch, and the change 
wasn't merged onto the master branch.

Bug#863658: pd-flite: pd can't find help patch for flite

[Claude Heiland-Allen]

Package: pd-flite
Version: 0.02.3-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I selected help from the right-click context menu of a [flite] object in Pd.

   * What was the outcome of this action?

tried /usr/lib/pd/extra/flite/flite-help.pd and failed
tried /usr/lib/puredata/doc/5.reference/flite-help.pd and failed
tried /home/claude/.local/lib/pd/extra/flite-help.pd and failed
tried /home/claude/pd-externals/flite-help.pd and failed
tried /usr/local/lib/pd-externals/flite-help.pd and failed
tried /usr/lib/puredata/extra/flite-help.pd and failed
tried /usr/lib/pd/extra/flite-help.pd and failed
tried /usr/lib/pd/extra/flite/help-flite.pd and failed
tried /usr/lib/puredata/doc/5.reference/help-flite.pd and failed
tried /home/claude/.local/lib/pd/extra/help-flite.pd and failed
tried /home/claude/pd-externals/help-flite.pd and failed
tried /usr/local/lib/pd-externals/help-flite.pd and failed
tried /usr/lib/puredata/extra/help-flite.pd and failed
tried /usr/lib/pd/extra/help-flite.pd and failed
sorry, couldn't find help patch for "flite.pd"

   * What outcome did you expect instead?

The help patch to be opened.  It seems to have been installed in
/usr/lib/pd/doc/5.reference/


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

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

Versions of packages pd-flite depends on:
ii  libc6   2.24-10
ii  libflite1   2.0.0-release-3+b1
ii  puredata-core [pd]  0.47.1-3

pd-flite recommends no packages.

pd-flite suggests no packages.

-- no debconf information

Bug#860355:

[Richard Allen]

Thanks Paul. I will do so.

Bug#860355: general: archive.debian.org certificate expired

[Richard Allen]

Package: general
Severity: normal

Dear Maintainer,

   * What led up to the situation? - Attempting to access
https://archive.debian.net/etch/libc6
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Attempted to access https://archive.debian.net/etch/libc6
using Chrome 57 on Debian Stretch
   * What was the outcome of this action? - Browser rejected out of date
certificate
   * What outcome did you expect instead? - Browser properly establishes chain
of trust.



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

Kernel: Linux 4.8.0-2-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)

Bug#856629: scid: pgnscid is not installed

[Charles Allen]

Package: scid
Version: 1:4.6.4+dfsg1-2
Severity: normal

Dear Maintainer,


   * What led up to the situation?

Noticed that the pgnscid executable was no longer installed
(it certainly used to be, and is mentioned in "apt info
scid").

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

It was present up to 2016-07-23 (at least).

Did a reinstall via "apt-get --reinstall install scid".

   * What was the outcome of this action?

No change.

   * What outcome did you expect instead?

To have the pgnscid executable present.



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

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

Versions of packages scid depends on:
ii  libc6   2.24-9
ii  libstdc++6  6.3.0-6
ii  libtcl8.6   8.6.6+dfsg-1+b1
ii  python  2.7.13-2
ii  scid-data   1:4.6.4+dfsg1-2
ii  tcl 8.6.0+9
ii  tk  8.6.0+9
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages scid recommends:
ii  libtk-img  1:1.4.6+dfsg-1
ii  tcl-snack [libsnack2]  2.2.10.20090623-dfsg-6
ii  tcllib 1.18-dfsg-3
ii  tdom   0.8.3-1
ii  texlive-games  2016.20170123-3

Versions of packages scid suggests:
ii  crafty  23.4-7
pn  glaurung
pn  phalanx 
pn  scid-spell-data | scid-rating-data  
ii  stockfish   8-3
ii  toga2   3.0.0.1SE1-2

-- no debconf information

Bug#855462: Update [Wrong Subject] (bleachbit: Starting as SUDO, Password Not Accepted)

[Stephen Allen]

Ugh I'm not starting it as sudo, starting it the usual way, but password not 
accepted when I enter my sudo password. Therefore to launch it, either have to 
use a terminal via sudo or gksudo. I'm assuming this error is because there 
isn't a root user account?

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

> Thanks for confirming that the last revision is not working as expected.
> Now we are back at the beginning. Could you apply this patch [1] and
> report back if it resolves your issue please?

Yes!  That fixed it for us.

Sorry again for the run around.

Allen

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

> Let's recapitulate: You are currently running +deb7u4 from April 2016
> which is the last good version for you and you see 400 errors when you
> use +deb7u5 or any later version up to +deb7u10, correct? Then this is a
> different issue because Samuel reported that the 400 errors occurred
> when he upgraded from 7.0.56-3+deb8u7 to 7.0.56-3+deb8u8 in Jessie

I just ran through the various 7.0.28-4+deb7 versions from u4 through u10 
(it's a 
quick test to run so I just went through them sequentially). 

The only one that fails is 7.0.28-4+deb7u10.  All other builds work for 
us.

So at least Samuel's and my results are consistent (+deb8u8 and +deb7u10 
both
include the "infinite loop patch").

Allen

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

First off, thanks for your patience.  The thing I was missing was that the 
build procedure for Debian includes applying patches to the code.  I was 
following the build instructions from the BUILDING.txt file, which doesn't 
include the Debian-specific instructions.  That completely explains what I 
was seeing with inconsistent JAR file contents.

I will test each version from +deb7u5 until the problem occurs again and 
report my results.

Thanks!

Allen

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

> That is strange. You have mentioned in your previous email that you
> downgraded tomcat7 in Wheezy to version 7.0.28-4+deb7u4. Are you sure
> that you are not comparing this version with 7.0.28-4+deb7u10? Why
> didn't you downgrade to 7.0.28-4+deb7u9 in the first place? This would
> explain the diff output because we had to make some bigger changes to
> the http parser classes in one of the previous security updates before
> +deb7u9 in Wheezy.

We downgraded to +deb7u4 because it was the last known good version on
the system where we first noticed the problem.  +deb8u9 is not available
on the security update server:

http://security.debian.org/pool/updates/main/t/tomcat7/

I guess we can distill my last email down a little.  Let's focus on 
PermissionCheck.class.  It is definitely in the +deb7u10 package.  You 
can use the following steps to confirm:

First, confirm that the system has +deb7u10:

$ dpkg-query -W -f '${Version}\n' libtomcat7-java
7.0.28-4+deb7u10

Next, confirm that the PermissionCheck.class file is in the 
tomcat-coyote.jar 
file:

$ unzip -t /usr/share/tomcat7/lib/tomcat-coyote.jar | grep 
PermissionCheck
testing: org/apache/tomcat/util/security/PermissionCheck.class OK

So I would expect the corresponding java file to be in the source repo
at that tag, but it is not:

$ git clone https://anonscm.debian.org/git/pkg-java/tomcat7.git
   ...
   $ cd tomcat7
   $ git checkout debian/7.0.28-4+deb7u10
   ...
   $ find . -name PermissionCheck.java

The find command finds shows nothing, but the official package contains
the class file.  Can you explain why?

Now, if you checkout the "master" branch:

$ git checkout master
   ...

And see if the PermissionCheck.java file exists:

   $ find . -name PermissionCheck.*
./java/org/apache/tomcat/util/security/PermissionCheck.java

So the file exists on the master branch for tomcat7, but not at the
debian/7.0.28-4+deb7u10 tag.

As I see it, these are the possibilities:

a) The build was done from a tag other than debian/7.0.28-4+deb7u10.
b) It was done from that tag, but there were other .class files
present in the output directory (i.e. it wasn't a clean build).

Any thoughts?

Thanks!

Allen

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

The plot thickens!  I created a local build from git using the 
7.0.28-4+deb7u10 tag.  Interestingly when I did that I was unable to 
reproduce the problem.  Originally I suspected that there was something 
wrong with my build.  But after some digging, I'm starting to suspect the 
official build.  Here's why...

Note that I have 7.0.28-4+deb7u10 installed on my system:

$ dpkg-query -W -f '${Version}\n' libtomcat7-java
7.0.28-4+deb7u10

Also that tomcat-coyote.jar is from that package:

$ dpkg-query -L libtomcat7-java | grep tomcat-coyote.jar
/usr/share/java/tomcat-coyote.jar
/usr/share/tomcat7/lib/tomcat-coyote.jar

(The first one is a symlink to the second one.)

I have attached two files, dist-tomcat-coyote-contents.txt and 
built-tomcat-coyote-contents.txt.  These files just contain the output of 
"unzip -t tomcat-coyote.jar".  Note that I chose that file because it 
contains the AbstractInputBuffer class.  I expected there to be no 
differences.  However, a diff of those files shows this:

$ diff dist-tomcat-coyote-contents.txt built-tomcat-coyote-contents.txt
1c1
< Archive:  /usr/share/tomcat7/lib/tomcat-coyote.jar
---
> Archive:  built-tomcat7-7.0.28-4+deb7u10/tomcat-coyote.jar
18,20d17
< testing: org/apache/tomcat/util/codec/   OK
< testing: org/apache/tomcat/util/codec/binary/   OK
< testing: org/apache/tomcat/util/collections/   OK
37d33
< testing: org/apache/tomcat/util/security/   OK
122d117
< testing: org/apache/coyote/http11/filters/LocalStrings.properties OK
270,280d264
< testing: org/apache/tomcat/util/codec/BinaryDecoder.class   OK
< testing: org/apache/tomcat/util/codec/BinaryEncoder.class   OK
< testing: org/apache/tomcat/util/codec/Decoder.class   OK
< testing: org/apache/tomcat/util/codec/DecoderException.class   OK
< testing: org/apache/tomcat/util/codec/Encoder.class   OK
< testing: org/apache/tomcat/util/codec/EncoderException.class   OK
< testing: org/apache/tomcat/util/codec/binary/Base64.class   OK
< testing: 
org/apache/tomcat/util/codec/binary/BaseNCodec$Context.class   OK
< testing: org/apache/tomcat/util/codec/binary/BaseNCodec.class   OK
< testing: org/apache/tomcat/util/codec/binary/StringUtils.class   OK
< testing: org/apache/tomcat/util/collections/ConcurrentCache.class OK
381c365,370
< testing: 
org/apache/tomcat/util/http/parser/HttpParser$SkipConstantResult.class OK
---
> testing: org/apache/tomcat/util/http/parser/AstAttribute.class   OK
> testing: org/apache/tomcat/util/http/parser/AstMediaType.class   OK
> testing: org/apache/tomcat/util/http/parser/AstParameter.class   OK
> testing: org/apache/tomcat/util/http/parser/AstSubType.class   OK
> testing: org/apache/tomcat/util/http/parser/AstType.class   OK
> testing: org/apache/tomcat/util/http/parser/AstValue.class   OK
383,384c372,381
< testing: org/apache/tomcat/util/http/parser/MediaType.class   OK
< testing: org/apache/tomcat/util/http/parser/MediaTypeCache.class OK
---
> testing: 
org/apache/tomcat/util/http/parser/HttpParserConstants.class   OK
> testing: 
org/apache/tomcat/util/http/parser/HttpParserTokenManager.class   OK
> testing: 
org/apache/tomcat/util/http/parser/HttpParserTreeConstants.class   OK
> testing: org/apache/tomcat/util/http/parser/JJTHttpParserState.class 
  OK
> testing: org/apache/tomcat/util/http/parser/Node.class   OK
> testing: org/apache/tomcat/util/http/parser/ParseException.class OK
> testing: org/apache/tomcat/util/http/parser/SimpleCharStream.class 
OK
> testing: org/apache/tomcat/util/http/parser/SimpleNode.class   OK
> testing: org/apache/tomcat/util/http/parser/Token.class   OK
> testing: org/apache/tomcat/util/http/parser/TokenMgrError.class   OK
482,484d478
< testing: org/apache/tomcat/util/security/PermissionCheck.class   OK
< testing: org/apache/tomcat/util/security/PrivilegedGetTccl.class OK
< testing: org/apache/tomcat/util/security/PrivilegedSetTccl.class OK
498c492
< No errors detected in compressed data of 
/usr/share/tomcat7/lib/tomcat-coyote.jar.
---
> No errors detected in compressed data of 
built-tomcat7-7.0.28-4+deb7u10/tomcat-coyote.jar.

The interesting thing about this to me is that some of those class files 
are supposed to be only in Tomcat 8 and not in Tomcat 7 (or only in Tomcat 
7 and not in Tomcat 8).

Is it possible that the build wasn't "clean" in that it contained some 
Tomcat 8 class files?  It certainly smells like that.

Thanks,
Allen




Archive:  /usr/share/tomcat7/lib/tomcat-coyote.jar
testing: META-INF/OK
testing: META-INF/MANIFEST.MF OK
testing: org/ OK
testing: org/apache/  OK
testing: org/apache/coyote/   OK
testing: org/apache/coyote/ajp/   OK
testing: org/apache/c

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

We are seeing the same thing that Samuel Wolf described, but from our web 
UI and with 7.0.28-4+deb7u10.  We get seemingly random 400 HTTP returns.

We downgraded to 7.0.28-4+deb7u4 and that problem went away.

Unfortunately in our environment the Tomcat-side Java exception is not 
being logged, so we have some more digging to do.  We do see the 400 error 
in the access log though.

Bug#851930: desktop-base: Include size 3840x2160 (4k) wallpaper and lockscreen

[Dave Allen Barker Jr]

Package: desktop-base
Version: 9.0.0
Severity: wishlist

Dear Maintainer,

I'm sorry I don't know how to provide a patch, but here are the simple
things you can do to provide crisp backgrounds for 4k (3840x2160)
high resolution displays:

  1. For each of the themes
1.1. In thier "image" directories
  1.1.1 Copy a 16:9 aspect ratio ".svg" file to "3840x2160.svg"
  1.1.2 Edit the "3840x2160.svg" "svg" header "width" and "height"
  attributes to "3840" and "2160" respectively
1.2. In their "gnome-background.xml"s, add an entry for the
"3840x2160.svg"

Thank you!


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

Kernel: Linux 4.8.0-2-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 desktop-base depends on:
ii  dpkg 1.18.18
ii  librsvg2-common  2.40.16-1

desktop-base recommends no packages.

Versions of packages desktop-base suggests:
pn  gnome | kde-standard | xfce4 | wmaker  

-- no debconf information

Bug#849994: [Pkg-roundcube-maintainers] Bug#849994: roundcube-core: install fails; Class 'Patchwork\Utf8\Bootup' not found

[Claude Heiland-Allen]

Hi Guilhem,

On 03/01/17 13:13, Guilhem Moulin wrote:
> On Tue, 03 Jan 2017 at 11:29:33 +, Claude Heiland-Allen wrote:
>> $ php --version
>> PHP 7.0.14-2 (cli) ( NTS )
> 
> php7.0 is not in jessie-backports, right?  There is no guaranty for
> systems mixing packages for testing/unstable and backports.

I don't know, but the php7.0 we have is indeed from testing.  Should
roundcube installation script explicitly be depending on /usr/bin/php5
binary if it doesn't support php7.0 yet?  Or is this out of scope for
backports?

> Anyway, the php maintainers have split php7; I believe encode_utf8 is in
> php7.0-xml.  Does installing this package makes roundcube upgradable?

It helps yes, passes the error in the subject, but also need php7.0-pspell:

# aptitude install php7.0-xml
...
# update-alternatives --set php /usr/bin/php7.0
update-alternatives: using /usr/bin/php7.0 to provide /usr/bin/php (php)
in manual mode
# aptitude reinstall roundcube-core
...
WARNING: Dependency check failed!
(Some of your configuration settings require other options to be
configured or additional PHP modules to be installed)
- spellcheck_engine: This requires the pspell extension which
could not be loaded.
...
# aptitude install php7.0-pspell
...
# aptitude reinstall roundcube-core
...
This instance of Roundcube is up-to-date.
Have fun!
...
#


Thanks,


Claude

Bug#849994: [Pkg-roundcube-maintainers] Bug#849994: roundcube-core: install fails; Class 'Patchwork\Utf8\Bootup' not found

[Claude Heiland-Allen]

Hi Guilhem,

On 03/01/17 09:13, Guilhem Moulin wrote:
> Hi Claude,
> 
> On Mon, 02 Jan 2017 at 23:32:01 +0100, Claude Heiland-Allen wrote:
>> Package: roundcube
>> Version: 1.1.5+dfsg.1-1~bpo8+2
>> Severity: grave
>> Justification: renders package unusable
> 
> I believe this was fixed upstream in 1.2.0
> 
> 
> https://github.com/roundcube/roundcubemail/commit/8447bae77c19a2350bd48b0f0c5b3a56a35c7af9#diff-6678ea2316550af087f1ae7115a3398eL71
> 
> If that's indeed the case, we should lower the severity as if this bug
> doesn't apply to 1.2.3+dfsg.1-1 it shouldn't prevent its inclusion in
> Stretch.
> 
>> Regular maintainance aptitude safe-upgrade pulled a new version of roundcube
>> from jessie-backports which failed to install.  Here is the log:
> 
> Upgrading from which version?  1.1.5+dfsg.1-1~bpo8+2 differs from
> 1.1.5+dfsg.1-1~bpo8+1 (the previous version found in jessie-backports)
> only by the fix to CVE-2016-9920.

yes, I still have that previous version in /var/cache/apt/archives, and
trying to install it with dpkg also fails with the same error.

>> PHP Fatal error:  Uncaught Error: Class 'Patchwork\Utf8\Bootup' not
>> found in /usr/share/roundcube/program/include/iniset.php:81
>> Stack trace:
>> #0 /usr/share/roundcube/program/include/clisetup.php(26): require_once()
>> #1 /usr/share/roundcube/bin/update.sh(31):
>> require_once('/usr/share/roun...')
>> #2 {main}
>>  thrown in /usr/share/roundcube/program/include/iniset.php on line 81
> 
> This line is only run when the function ‘utf8_encode’ doesn't exist, but
> oddly enough it seems to belong to core.  Does the following command
> outputs anything on your machine?
> 
> php -r 'if (!function_exists("utf8_encode")) { die("no such function\n"); 
> }'

yes.

$ php -r 'if (!function_exists("utf8_encode")) { die("no such
function\n"); }'
no such function
$

but:

$ php --version
PHP 7.0.14-2 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.14-2, Copyright (c) 1999-2016, by Zend
Technologies
$

and:

$ php5 -r 'if (!function_exists("utf8_encode")) { die("no such
function\n"); }'
$

(no output)

roundcube-core depends on php5, so it seems the php version 7 from
testing is to blame.  Indeed:

# update-alternatives --set php /usr/bin/php5
update-alternatives: using /usr/bin/php5 to provide /usr/bin/php (php)
in manual mode
# aptitude safe-upgrade
...
Setting up roundcube-core (1.1.5+dfsg.1-1~bpo8+2) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/roundcube.conf
dbconfig-common: flushing administrative password
This instance of Roundcube is up-to-date.
Have fun!
apache2_invoke roundcube.conf: already enabled
Setting up roundcube (1.1.5+dfsg.1-1~bpo8+2) ...
Setting up roundcube-plugins (1.1.5+dfsg.1-1~bpo8+2) ...
...
#

and everything is fine again.

Thanks,


Claude

Bug#849994: roundcube-core: install fails; Class 'Patchwork\Utf8\Bootup' not found

[Claude Heiland-Allen]

Package: roundcube
Version: 1.1.5+dfsg.1-1~bpo8+2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Regular maintainance aptitude safe-upgrade pulled a new version of roundcube
from jessie-backports which failed to install.  Here is the log:

$ sudo aptitude safe-upgrade
Resolving dependencies...
The following partially installed packages will be configured:
  roundcube roundcube-core roundcube-plugins
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up roundcube-core (1.1.5+dfsg.1-1~bpo8+2) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/roundcube.conf
dbconfig-common: flushing administrative password
PHP Fatal error:  Uncaught Error: Class 'Patchwork\Utf8\Bootup' not
found in /usr/share/roundcube/program/include/iniset.php:81
Stack trace:
#0 /usr/share/roundcube/program/include/clisetup.php(26): require_once()
#1 /usr/share/roundcube/bin/update.sh(31):
require_once('/usr/share/roun...')
#2 {main}
  thrown in /usr/share/roundcube/program/include/iniset.php on line 81
dpkg: error processing package roundcube-core (--configure):
 subprocess installed post-installation script returned error exit
status 255
dpkg: dependency problems prevent configuration of roundcube:
 roundcube depends on roundcube-core (= 1.1.5+dfsg.1-1~bpo8+2); however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of roundcube-plugins:
 roundcube-plugins depends on roundcube-core (= 1.1.5+dfsg.1-1~bpo8+2);
however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube-plugins (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 roundcube-core
 roundcube
 roundcube-plugins
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up roundcube-core (1.1.5+dfsg.1-1~bpo8+2) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/roundcube.conf
dbconfig-common: flushing administrative password
PHP Fatal error:  Uncaught Error: Class 'Patchwork\Utf8\Bootup' not
found in /usr/share/roundcube/program/include/iniset.php:81
Stack trace:
#0 /usr/share/roundcube/program/include/clisetup.php(26): require_once()
#1 /usr/share/roundcube/bin/update.sh(31):
require_once('/usr/share/roun...')
#2 {main}
  thrown in /usr/share/roundcube/program/include/iniset.php on line 81
dpkg: error processing package roundcube-core (--configure):
 subprocess installed post-installation script returned error exit
status 255
dpkg: dependency problems prevent configuration of roundcube-plugins:
 roundcube-plugins depends on roundcube-core (= 1.1.5+dfsg.1-1~bpo8+2);
however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube-plugins (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of roundcube:
 roundcube depends on roundcube-core (= 1.1.5+dfsg.1-1~bpo8+2); however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 roundcube-core
 roundcube-plugins
 roundcube

$


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

I installed php-patchwork-utf8 from testing but that did not resolve
the issue.


Thanks,

Claude


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (900, 'stable'), (800, 'testing'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-0.bpo.1-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 roundcube-core depends on:
ii  dbconfig-common2.0.6~bpo8+1
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  libapache2-mod-php55.6.29+dfsg-0+deb8u1
ii  libmagic1  1:5.22+15-2+deb8u2
ii  php-auth-sasl  1.0.6-1+deb8u1
ii  php-mail-mime  1.8.9-1+deb8u1
ii  php-net-sieve  1.3.2-4
ii  php-net-smtp   1.6.2-2
ii  php-net-socket 1.0.14-1
ii  php-patchwork-utf8 1.3.1-1
ii  php-pear   5.6.29+dfsg-0+deb8u1
ii  php5   5.6.29+dfsg-0+deb8u1
ii  php5-cli   5.6.29+dfsg-0+deb8u1
ii  php5-common5.6.29+dfsg-0+deb8u1
ii  php5-intl  5.6.29+dfsg-0+deb8u1
ii  php5-json  1.3.6-1
ii  php5-mcrypt

Bug#849359: Flent missing package dependency

[Richard Allen]

Package: flent
Version: 0.15.0-3

I believe there is a missing dependency for flent. I also installed
python-setuptools, but that did not fix it.

Error:

rsaxvc@rsaxvc:~$ flent
Traceback (most recent call last):
  File "/usr/bin/flent", line 6, in 
from pkg_resources import load_entry_point
ImportError: No module named 'pkg_resources'
rsaxvc@rsaxvc:~$

Incorrect behaviour: program fails due to missing dependency

Kernel: Linux rsaxvc 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02)
x86_64 GNU/Linux

Pythons:
rsaxvc@rsaxvc:~$ python --version
Python 2.7.13rc1
rsaxvc@rsaxvc:~$ python3 --version
Python 3.5.2+

Libc: Version: 2.24-8

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/24 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 flent depends on:
pn  python3:any  

Versions of packages flent recommends:
ii  iputils-ping [ping]  3:20161105-1
ii  python3-matplotlib   1.5.3-1
ii  python3-pyqt44.11.4+dfsg-2

Versions of packages flent suggests:
pn  netperf  

-- no debconf information
rsaxvc@rsaxvc:~$

Bug#844470: bash-completion: make completion breaks VAR=/path

[Brian Allen Vanderburg II]

Package: bash-completion
Version: 1:2.1-4
Severity: normal

Dear Maintainer,

I Recently updated various packages on Debian Jessie.  Before the update, I was
able to execute make in the following fashion:

make backup TARGET=/path/to/backup

And make would auto-complete the path as I typed it out.  After the updates,
the completion of the path is broken.  To verify that it was not my user
account, I signed in as root to test as well (as root has no environment
customizations) and get the same issue.

Without bash completion loaded, I can type

make backup TARGET=/path/to/backup

and filename completion occurs while I am tabbing out the path.  However,
completion of make targets/etc does not occur.  When bash completion is loaded,
completion of most make targets works, but not the path.

When I attempt to complete the path, before pressing tab I get:

make backup TARGET=/path/to/ba

When I press tab, the entire line is replaced with:

make backup /path/to/backup


I'm not sure what is causing the issue.  I seem to be able to confirm that
"prev" and "cur" are being set to "TARGET=" and "/path/to/ba" before calling
"_filedir" in the "completions/make" script.  However, afterward, the entire
word "TARGET=/path/to/ba" is being replaced instead of just the path portion.
Also, once this is replaced, completion of the path no longer works since it
does not contain "VAR=" syntax anymore.



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

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/6 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 bash-completion depends on:
ii  bash  4.3-11+b1
ii  dpkg  1.17.27

bash-completion recommends no packages.

bash-completion suggests no packages.

-- no debconf information

Bug#841251: gdm3: Both Nautilas & Nemo Want to Manage Desktop

[Stephen Allen]

On Sun, Oct 23, 2016 at 12:18:11PM +, Margarita Manterola wrote:
> Hi!
> 
> Maxy and I have been trying to reproduce this problem using nemo and nautilus
> both from unstable and stable and we have not been able to reproduce this.
> 
> The nemo-autostart.desktop file is only installed in /usr/share/applications.
> In cinnamon, it's started as part of cinnamon session, but given that it's 
> not part
> of /etc/xdg/autostart, it shouldn't get autostarted by default.
> 
> Stephen, could it be that you had nemo-autostart as part of 
> /etc/xdg/autostart?
> Or that you had added it to your local ~/.config/autostart directory?

Don't think so Marga, see attached screengrab. This started happening
only recently.

Bug#841251: gdm3: Both Nautilas & Nemo Want to Manage Desktop

[Stephen Allen]

On Wed, Oct 19, 2016 at 06:20:07PM +0200, Michael Biebl wrote:
> >>>> Am 19.10.2016 um 01:52 schrieb Stephen Allen:
> 
> >>>>> I have both Gnome 3.22.x and Cinnamon installed. When logging in using
> >>>>> GDM3 with Gnome specifically enabled, both Nautilas and Nemo are
> >>>>> activated to manage my desktop, resulting in double overlapping icons.
> >>>>> Once I forcequit Nemo, all is well.
> 
> 
> Btw, are you sure you were starting a GNOME session?
> GNOME by default does no longer draw any icons on the desktop.

Correct, I enabled icons via Gnome-Tweak-Tool. Thank-you for reassigning
to the Cinnamon Team.

So, yes I'm sure Yours Truly is running Gnome. :-)

Bug#841318: (liferea: Internal Browser Shows File System)

[Stephen Allen]

Further to this issue I attach screengrab of the issue.

Bug#841318: liferea: Internal Browser Shows File System

[Stephen Allen]

Package: liferea
Version: 1.12~rc1-6
Severity: normal

Dear Maintainer,

Became alarmed this morning when using the Liferea internal browser to
view a page from it's feed. When on the webpage, I clicked on an image
included in the page to enlarge it. When finished, I clicked the back
arrow in Liferea viewing area to go back to main page, and was taken
to the root of my file system, allowing me to view each file/directory as a 
hyperlink.
The desired outcome would be to take me to the original webpage, after
viewing enlarged thumbnail from said webpage.



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

Kernel: Linux 4.7.0-1-amd64 (SMP w/6 CPU cores)
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 liferea depends on:
ii  dbus-x11 [dbus-session-bus]  1.10.12-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gir1.2-freedesktop   1.50.0-1
ii  gir1.2-gtk-3.0   3.22.1-1
ii  gir1.2-peas-1.0  1.20.0-1
ii  libc62.24-5
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgirepository-1.0-11.50.0-1
ii  libglib2.0-0 2.50.1-1
ii  libgtk-3-0   3.22.1-1
ii  libjson-glib-1.0-0   1.2.2-1
ii  libpango-1.0-0   1.40.3-2
ii  libpeas-1.0-01.20.0-1
ii  libsoup2.4-1 2.56.0-1
ii  libsqlite3-0 3.15.0-1
ii  libwebkit2gtk-4.0-37 2.14.1-1
ii  libxml2  2.9.4+dfsg1-2
ii  libxslt1.1   1.1.29-1
ii  liferea-data 1.12~rc1-6
ii  python3-cairo1.10.0+dfsg-5+b1
ii  python3-gi   3.22.0-1
ii  python3-notify2  0.3-3
ii  python3.53.5.2-6+b1
pn  python3:any  

Versions of packages liferea recommends:
ii  gir1.2-gnomekeyring-1.0  3.12.0-1+b1
ii  gir1.2-gstreamer-1.0 1.8.3-1
ii  gnome-keyring3.20.0-3

Versions of packages liferea suggests:
pn  kget 
ii  network-manager  1.4.2-2

-- no debconf information

Bug#841251: gdm3: Both Nautilas & Nemo Want to Manage Desktop

[Stephen Allen]

Package: gdm3
Version: 3.22.1-1
Severity: important

Dear Maintainer,

Hello.

I have both Gnome 3.22.x and Cinnamon installed. When logging in using
GDM3 with Gnome specifically enabled, both Nautilas and Nemo are
activated to manage my desktop, resulting in double overlapping icons.
Once I forcequit Nemo, all is well.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/6 CPU cores)
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 gdm3 depends on:
ii  accountsservice  0.6.40-3
ii  adduser  3.115
ii  cinnamon [x-window-manager]  3.0.7-2
ii  cinnamon-session [x-session-manager] 3.0.1-2
ii  dconf-cli0.26.0-2
ii  dconf-gsettings-backend  0.26.0-2
ii  debconf [debconf-2.0]1.5.59
ii  e17 [x-window-manager]   0.17.6-1.1
ii  gir1.2-gdm-1.0   3.22.1-1
ii  gnome-session [x-session-manager]3.22.1-1
ii  gnome-session-bin3.22.1-1
ii  gnome-session-flashback [x-session-manager]  3.22.0-2
ii  gnome-settings-daemon3.22.1-1
ii  gnome-shell  3.22.1-1
ii  gnome-terminal [x-terminal-emulator] 3.22.0-3
ii  gsettings-desktop-schemas3.22.0-1
ii  libaccountsservice0  0.6.40-3
ii  libaudit11:2.6.7-1
ii  libc62.24-4
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgdm1  3.22.1-1
ii  libglib2.0-0 2.50.1-1
ii  libglib2.0-bin   2.50.1-1
ii  libgtk-3-0   3.22.1-1
ii  libkeyutils1 1.5.9-9
ii  libpam-modules   1.1.8-3.3
ii  libpam-runtime   1.1.8-3.3
ii  libpam-systemd   231-9
ii  libpam0g 1.1.8-3.3
ii  librsvg2-common  2.40.16-1
ii  libselinux1  2.5-3
ii  libsystemd0  231-9
ii  libwrap0 7.6.q-25
ii  libx11-6 2:1.6.3-1
ii  libxau6  1:1.0.8-1
ii  libxdmcp61:1.1.2-1.1
ii  lsb-base 9.20161016
ii  metacity [x-window-manager]  1:3.22.0-1
ii  muffin [x-window-manager]3.0.5-2
ii  mutter [x-window-manager]3.22.1-2
ii  policykit-1  0.105-16
ii  ucf  3.0036
ii  x11-common   1:7.7+16
ii  x11-xserver-utils7.7+7
ii  xterm [x-terminal-emulator]  327-1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.22.0-1
ii  desktop-base8.0.2
ii  x11-xkb-utils   7.7+3
ii  xserver-xephyr  2:1.18.4-2
ii  xserver-xorg1:7.7+16
ii  zenity  3.22.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.22.1-1
ii  libpam-gnome-keyring  3.20.0-3

-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#834458: uml-utilities: Location of tunctl changed from /usr/sbin to /usr/bin

[Allen Chan]

Package: uml-utilities
Version: 20070815.1-1
Severity: important

Dear Maintainer,

The location of tunctl has changed from /usr/sbin/tunctl to /usr/bin/tunctl.
However, the script at /etc/network/if-pre-up.d/uml-utilities still refers to 
/usr/sbin/tunctl.
This breaks existing commands in /etc/network/interfaces to create tap 
interfaces.

Thank you.



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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages uml-utilities depends on:
ii  adduser   3.115
ii  libc6 2.23-4
ii  libfuse2  2.9.7-1
ii  libreadline6  6.3-8+b4
ii  lsb-base  9.20160629

uml-utilities recommends no packages.

Versions of packages uml-utilities suggests:
pn  user-mode-linux  

-- no debconf information

Bug#829144: simple-scan: no keyboard shortcuts are working

[Allen James]

Package: simple-scan
Version: 3.20.0-1
Severity: important

Dear Maintainer,

For the past year or two the keyboard shortcuts in Simple Scan have not worked.
I've encountered this bug while using KDE (both KDE4 and KDE5). I mark this as
"important" because during large scans (sometimes over a hundred pages, scanned
individually) the use of such shortcuts as Ctrl+1 for scan, < and > for rotate
scan, and [ and ] for move scan left and right, save lots of time and effort.
Using the mouse becomes very tedious (especially finding the rotate and move
functions by right-clicking, naviating the menu, then clicking again each time.
It would be really appreciated if this could be resolved. Thank you.

-- Package-specific info:

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

Kernel: Linux 4.6.0-1-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 simple-scan depends on:
ii  adwaita-icon-theme   3.20-3
ii  dbus-x11 1.10.8-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-11
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcolord2   1.3.2-1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgtk-3-0   3.20.6-1
ii  libgusb2 0.2.9-1
ii  libpackagekit-glib2-18   1.1.1-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libsane  1.0.25-2+b1
ii  libsqlite3-0 3.13.0-1
ii  libusb-1.0-0 2:1.0.20-1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

simple-scan recommends no packages.

simple-scan suggests no packages.

-- no debconf information

Bug#819684: Uurgent

[Allen adam]

How is your day going?

On Sat, Jun 11, 2016, 8:40 PM Tax_Defender  wrote:

> Smile George
>
> Solve Your Tax__Problems Now
>

Bug#826227: Acknowledgement (gnome-session: Mouse Acts Strange After Awhile)

[Stephen Allen]

Further investigation has lead me to believe that this is a hardware
issue. Think replacing the mouse is in order.

So, AFAIC this bug report may be closed. Excuse the noise.

Bug#826227: Acknowledgement (gnome-session: Mouse Acts Strange After Awhile)

[Stephen Allen]

Forgot to mention that I'm using left handed mouse, so in Gnome Control
Centre that option has been set for left handed use.

Bug#750586: website design

[allen thomas]

Good day
I'm Thomas Allen,am hearing impaired.i would love to know if you can handle
website design for a new company and also if you do, you accept credit
cards? kindly get back to me ASAP so i can send you the job details.
Regards