Bug#990397: What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)

[Alan W. Irwin]

mplement.

* It "would be nice" to update our fork to the latest version of nn-c.
  The reason I suggest this as a worthwhile goal is I assume that
  Pavel's fairly constant development of nn-c since 2003 has found and
  fixed more bugs in the nn-c code than we have found and fixed in our
  fork of that code.  As a short-cut to make this development topic
  easier, our fork could continue to ignore everything in nn-c that is
  not relevant to the problem of interpolating from non-gridded sample
  points to gridded sample points, but see the next item below.  I haven't
  looked at what would be required by this development topic, but my
  guess is it could be implemented by simply replacing the
  csironn routines with the corresponding nn-c routines while keeping
  just the part of of the csironn routines that set up and call
  the libqhull routines and/or fix bugs in the nn-c version of these
  routines that are already in csironn and which have not already
  been fixed by Pavel.  So it might all end up as a glorious git conflict
  resolution.  :-)

* The above "would be nice" development topic should be done first,
  but in addition it "would be nice" to not strip nn-c at all. My
  guess is what was stripped was pretty minor stuff since the csironn
  ability to interpolate from non-gridded to gridded sample points
  captures all the essential functionality of nn-c.  But regardless of
  that question, the result should be that csironn should have all the
  functionality of modern nn-c (i.e., it passes all nn-c tests) with
  the only changes being conversion of *all* triangle library calls to
  the equivalent libqhull calls.

  I hasten to add I don't want to discuss this "vapour ware" with
  Pavel until it turns into "real ware".  However, if we accomplish
  that goal (i.e., if the updated csironn library passes all nn-c
  testing) I bet Pavel (who is a really approachable guy) would be
  willing to adopt our changes right into nn-c (likely as an option),
  and that would clear the way for that useful library to be packaged
  by Debian as "free" rather than "contrib" and would also allow us to
  abandon our fork (since it would have been merged back into
  mainstream nn-c development) which I think would be a highly desired
  outcome.

I have stated on this list before (but you may have missed that), I
work most efficiently on just one development topic at a time.  And my
current primary development topic is getting the next release of
FreeEOS out the door and my two topics following that are (i) getting
the next libLASi release out the door using recent PLplot to
comprehensively test it, and (ii) getting the PLplot release out the
door.

In sum, because of these other development commitments I don't plan
for now to contribute much toward any of the above three "would be
nice" development topics for libcsironn other than discussing them.
But if you or anyone else here that was interested in libcsironn were
inspired by this discussion to create a patch to implement any of
those topics (or any other libcsironn development topic that
interested you), I would be happy to comprehensively test that patch
in a timely manner and (assuming that was a success) push that commit
to make sure your work gets into the next release of PLplot.

Best wishes,

Alan
__
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#837809: Interesting venture

[ALAN ANDRES GUAJARDO CARO]

-



I have a lucrative business venture to discuss with you.



If interested, please get back via email: aa1...@mtazzo.com



Regards!

P A

Bug#976621: mutt: segfaults when REPLYTO environment variable is set

[Alan D. Salewski]

fixed 976621 mutt/2.0.5-1
thanks

On 2021-01-04 18:42:28, "Alan D. Salewski"  spake thus:
[...]

The fix is in mutt-2.0.3, which was released on 2020-12-04, so we should get
the fix whenever that version makes it into Debian.


I just confirmed that this bug is fixed in the '2.0.5-1' version of the 'mutt' 
package currently in Debian testing ("bullseye"):


$ mutt -v | head -n 1
Mutt 2.0.5 (2021-01-21)

Mutt no longer segfaults when started with the 'REPLYTO' environment variable 
set.


Many thanks to the Debian Mutt maintainers and upstream,
-Al

--
a l a n   d.   s a l e w s k i
ads@salewski.email
salew...@att.net
https://github.com/salewski

Bug#976621: mutt: segfaults when REPLYTO environment variable is set

[Alan D. Salewski]

I tripped over this issue today while upgrading from mutt 1.x to 2.x

The upstream issue for this bug is:

  * "Mutt 2.0.2 - macOS 10.15.7 - segmentation fault"
https://gitlab.com/muttmua/mutt/-/issues/310

The issue was fixed upstream in this commit:

commit cfdcfa7ffee69ecdf7a56a6b9c541d1f71496601
Author: Kevin McCarthy 
Date:   Sun Nov 29 13:44:30 2020 -0800

Fix REPLY_TO environment variable handling.

Commit 4e153adf changed this code to reuse the function buffer
variable, but forgot to rewind the buffer for parsing in
parse_my_hdr().

Additionally commit e5a32a61 removed an extra "null termination"
mutt_buffer_addch() at the end of mutt_extract_token().  This caused a
NULL value to be passed to the strpbrk() in parse_my_hdr(), causing a
segv.  Change to use a buffer pool token parameter instead.

I actually think, like with the previous IMAP mailbox handling, this
method of adding a my_hdr is dangerous.  I'll look into refactoring it
in master instead.

Thanks to Paul Nevai for reporting the problem and tracking down the
backtrace.


The fix is in mutt-2.0.3, which was released on 2020-12-04, so we should get
the fix whenever that version makes it into Debian.

-- 
-
a l a n   d.   s a l e w s k i   salew...@att.net
   ads@salewski.email
  https://github.com/salewski
-

Bug#284002: default for mdoc's volume-operating-system

[Alan D. Salewski]

On 2005-10-14 21:42:16, Robert Bihlmeyer  spake thus:
> I also support to put "Debian" into volume-operating-system. As
> upstream does not seem to like it, I guess the best option for Debian
> is to put
> 
> .ds volume-operating-system Debian
> 
> into the shipped version of /etc/groff/mdoc.local.
> 
> Rationale:
> 
> The intention of the titlebar is not really clear. Given a program
> "foo" written by an author neither affiliated with *BSD or Debian,
> should the output of "man 1 foo" pretend that the manpage is part of
> the "FreeBSD General Commands Manual" when run on FreeBSD and the
> "Debian General Commands Manual" when run on Debian? Or some other,
> constant value, because its actually the same program regardless of the
> distribution/OS?
> 
> My gut says the former, namely that the manpage, by virtue of it being
> included in the Debian distribution, becomes part of the mythical
> "Debian General Commands Manual", regardless of whether the GCM of
> some other distributions/OSes may include the same page.
> 
> The current situation, that the manpage is shown to be part of the
> "BSD General Commands Manual" even when we are on Debian GNU/Linux
> certainly is wrong. Even unsetting the variable would be better.
> 
> -- 
> Robbe
> 

Hi Folks,

I tripped over this issue today and found my way to this bug
report. The mdoc manpage for a tool I was working on rendered with
with the following headers and footer:


FOO(1)  BSD General Commands Manual FOO(1)

NAME
foo - Foobricate quuxels

SYNOPSIS
...
BSD October 14, 2020   BSD


I love the BSDs as much as the next person, but that labeling is not
what I expected to see when rendering the page on my Debian
GNU/Linux host  ;-)

I have read Werner LEMBERG's comments[0] over on related issue
#176575, and agree that the upstream GNU Groff source is not the
right location for Debian labeling. But I also read the statement:

"I think you should provide correct default values in mdoc.local --"

as confirmation that mdoc.local /is/ the right place for such
labeling. The attached patch (which I'm running on my main system
right now) provides that with the addition (in essence) of the
following lines:

.ds doc-volume-operating-system Debian
.ds doc-default-operating-system Debian\~GNU/Linux

The first affects the heading in an mdoc manpage, the second the
footer.

For completeness, I read the follow-up statement:

"any man page which is specific to a certain operating system should
 say that by using .Os properly."

as meaning that authors of components that truly are specific to a
given operating system should explicitly name that OS as the
argument to the mdoc '.Os' macro:

.Os Foonix

So this change is not overriding anything that is not intended to be
overridden by the distribution.

The attached patch (against groff-1.22.4) takes a hint from the
'base-files' package and adapts the labeling appropriate for build
host, using the $NAME value from the /etc/os-release file. On my
Debian GNU/Linux host, the header and footer are now rendered like
this:

FOO(1)Debian General Commands ManualFOO(1)
...
Debian GNU/Linux October 14, 2020 Debian GNU/Linux

On Debian GNU/Hurd or GNU/kFreeBSD would presumably render with the
relative appropriately adapted labels (I didn't test them).

Please consider applying this patch or something like it to the
groff package.

Thanks,
-Al


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=176575#10

-- 
-
a l a n   d.   s a l e w s k i ads@salewski.email
     salew...@att.net
-
# Description: Add Debian labelling for mdoc manpages (mdoc.local)
# Author: "Alan D. Salewski" 
# Bug-Debian: https://bugs.debian.org/284002
# Forwarded: not-needed
# Last-Update: 2020-10-14
diff -r -u groff-1.22.4-orig/debian/mandoc.local groff-1.22.4-chng/debian/mandoc.local
--- groff-1.22.4-orig/debian/mandoc.local	2020-05-06 04:24:11.0 -0400
+++ groff-1.22.4-chng/debian/mandoc.local	2020-10-14 18:45:16.102920887 -0400
@@ -27,3 +27,16 @@
 .  char \- \N'45'
 .  \}
 .\}
+
+.\" When rendering an mdoc manpage that has an empty .Os macro, the
+.\" 'doc-volume-operating-system' string is rendered in the center
+.\" heading at the top of the manpage.
+.\"
+.\" The 'doc-default-operating-system' string is rendered on both
+.\" the left and right at the bottom of the manpage.
+.\"
+.\" Yields .e.g, "Debian General Commands Manual"
+.ds doc-volume-operating-system Debian
+.\"
+.\" 

Bug#970267: iptables: iptables-nft complains table is incompatible when ctstate rule is added via nft

[Alan Tu]

Package: iptables
Version: 1.8.5-3
Severity: normal

Steps: 
# nft flush ruleset
# iptables-nft -L
# iptables-nft -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# iptables-nft -L
Result: as expected

# nft flush ruleset
# iptables-nft -L
# nft add rule ip filter INPUT ct state related,established counter accept
# iptables-nft -L
Output: iptables v1.8.5 (nf_tables): table 'filter' is incompatible, use 'nft' 
tool.

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_CRAP, 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 iptables depends on:
ii  libc62.31-3
ii  libip4tc21.8.5-3
ii  libip6tc21.8.5-3
ii  libmnl0  1.0.4-3
ii  libnetfilter-conntrack3  1.0.8-1
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl11   1.1.7-1
ii  libxtables12 1.8.5-3
ii  netbase  6.1

Versions of packages iptables recommends:
ii  nftables  0.9.6-1

Versions of packages iptables suggests:
pn  firewalld  
ii  kmod   27+20200310-2

-- no debconf information

Bug#963093: samtools: recommended dependencies are unnecessary

[Alan Hoyle]

Package: samtools
Version: 1.10-4
Severity: minor

Dear Maintainer,


Samtools includes recommended installation of python and cwltool.

python is completely unnecessary now.

cwltool should be a "suggests" at most for samtools, though I would make 
samtools a "recommends" for cwltool, as many workflows that use cwltool
do use samtools.  

I discovered this because I was creating Docker images for processing 
sequencing data and I noticed that python and cwltool were being
installed unless I included --no-install-recommends on the apt-get
command line.  

The disadvantage to leaving this is that some Debian images will be
larger even when they don't need cwltool or python.  

I have been emailing with Andreas Tille outside of this bug report and I
think he has addressed this issue in the following two git commits:

https://salsa.debian.org/med-team/samtools/-/commit/e8c62ffa10f390937a225fb4188fa9c31510379a

https://salsa.debian.org/med-team/samtools/-/commit/81ac71e9ddacb88279c35a913c81ba8f5118720a

Thanks,

Alan

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

Kernel: Linux 4.19.76-linuxkit (SMP w/8 CPU cores)
Kernel taint flags: TAINT_RANDSTRUCT
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 samtools depends on:
ii  libc62.28-10
ii  libhts2  1.9-11
ii  libncurses6  6.1+20181013-2+deb10u2
ii  libtinfo66.1+20181013-2+deb10u2
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages samtools recommends:
pn  cwltool  
pn  python   

samtools suggests no packages.

-- no debconf information

Bug#962658: libwayland-cursor0: Cursor image left on screen after cursor moved on. Can only be removed by logging out.

[Alan Chandler]

Package: libwayland-cursor0
Version: 1.18.0-1
Severity: normal

Dear Maintainer,


I was editing some code in vscode, when, randomly, I though the cursor had
frozen.  However I soon realised that it was elsewhere on the screen and what I
was seeing was a frozen image of it.

Despite closing vscode and switching to different workspaces on my (gnome)
desktop, the cursor remained in the same place on the screen. It seemed to
always be in the foreground - ie opening a new window over the top of where it
was would still show the cursor image, it was not displaced by the new pixels
from the overlaying window.

In the end the only way I was able to get it to disappear was to log out and
then log back in.  The frozen image was removed from the screen on logout.

My computer is running a AMD graphics card (I think its a RX580) and I need to
load Linux Non Free Firmware to have a working system at all. I presume that
could be part of the issue.



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

Kernel: Linux 5.6.0-2-amd64 (SMP w/12 CPU cores)
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 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libwayland-cursor0 depends on:
ii  libc6   2.30-8
ii  libwayland-client0  1.18.0-1

libwayland-cursor0 recommends no packages.

libwayland-cursor0 suggests no packages.

-- no debconf information

Bug#962593: gnome-shell: Gnome shell totally freezes except mouse which is still able to move

[Alan]

Package: gnome-shell
Version: 3.30.2-11~deb10u1
Severity: important

Dear Maintainer,

during Covid-19 isolation process, I often used Xournal and Kazam to record
myself when commentint and annotating documents.

Too often have I lost my whole work since Gnome Shell completely freezes. I'm
thus unable to record the Xournal file, and to recover Kazam temporary files.
It happened twice today ! I'm on Buster x64, fully up to date (apt update &&
apt dist-upgrade).

I'm only able, in this situation, to move the mouse (or the stylus, I use a
Lenovo Thinkpad Yoga 12 S1 unit). I can still write, but not record, undo,
erase... Super key is unresponsive, Alt-Tab and Alt-F2 too, I cannot hit the
upper left  corner, and so on.

I can only do Crrl+Alt+F3, log in on the TTY, and I can partially recover my
system executing :
DISPLAY=:0 gnome-shell --replace &

But the Window Manager is mostly out of order, and if I can record Xournal
files, Kazam records are lost (mp4fixer is useless, I don't know why).

I can provide logs but I cannot figure out those that will be useful.

Thanks in advance for reading.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-4~deb10u1
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4+deb10u1
ii  gir1.2-mutter-3  3.30.2-9~deb10u1
ii  gir1.2-nm-1.01.14.6-2+deb10u1
ii  gir1.2-nma-1.0   1.8.20-1.1
ii  gir1.2-pango-1.0 1.42.4-8~deb10u1
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-2.1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-11~deb10u1
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1
ii  libedataserver-1.2-233.30.5-1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libglib2.0-bin   2.58.3-2+deb10u2
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-9~deb10u1
ii  libnm0   1.14.6-2+deb10u1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4+deb10u1
ii  libpulse012.2-4+deb10u1
ii  libsecret-1-0   

Bug#962405: /proc/sys/kernel/random/boot_id DENIED

[Alan Sermons]

Package: apparmor
Version: 2.13.4-1+b1
Followup-For: Bug #962405

Dear Maintainer,

Complete apparmor novice here, so I'm not the best person to troubleshoot
things (but I'm willing to learn)...

Although I have a previous version of the package, I have had similar issues. I
had a look at the Ubuntu bug listed and had a look at the upstream files. There
is a reference to the abstractions/nameservice file at
https://gitlab.com/apparmor/apparmor/-/blob/apparmor-2.13/profiles/apparmor.d/abstractions/nameservice#L35
(included below). I found that adding the last of the three rules, listed in
that block, into local/usr.sbin.cupsd solved the recurring messages.

I hadn't realised, but I was having similar problems with freshclam, so when I
put the first and last of the rules into local/usr.bin.freshclam it fixed the
problem. However, the variable declaration wasn't working (I had to modify it
to put in /run specifically).

The cups issue has also been reported as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=954953 against cups-daemon, but the freshclam one doesn't
appear that I can see.

If you need any other information, I can see what I can do.

Many thanks.

>From upstream abstractions/nameservice
(https://gitlab.com/apparmor/apparmor/-/blob/apparmor-2.13/profiles/apparmor.d/abstractions/nameservice#L35)

  # NSS records from systemd-userdbd.service
  @{run}/systemd/userdb/ r,
@{run}/systemd/userdb/io.systemd.{NameServiceSwitch,Multiplexer,DynamicUser,Home}
r,
  @{PROC}/sys/kernel/random/boot_id r,




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

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

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.30-8
ii  lsb-base   11.1.0
ii  python33.8.2-3

apparmor recommends no packages.

Versions of packages apparmor suggests:
pn  apparmor-profiles-extra  
ii  apparmor-utils   2.13.4-1+b1

-- debconf information:
  apparmor/homedirs:

Bug#958881: debian-installer: ext4 with no journal is misinterpreted as ext2

[Alan Chandler]

Package: debian-installer
Severity: normal
Tags: d-i

Dear Maintainer,

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

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

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

After a corrupted nvme drive which included my root filesystem as btrfs which
wouldn't repair, I had to re-install (I was on Buster, but have taken the
opportunity to upgrade to Bulleye).

This drive contains a partition which I had formatted as ext4 with no journal
(it is the data directory for a docker install of sql server, so was set that
way as btrds cow settings not appropriate for a database), although I had
forgotten it was ext4 with no journal, and could afford to recreate from
scratch.

So during installation it is reported by partman as ext2, but just failed to
mount.  I assumed it was corrupted as was the rest of the ssd, so I told the
installer to reformat it.

I have a virtual box machine on another SSD, and that too was reported as ext2
but failed to mount.  This drive is more important (it contains a windows 10
installation maintained over a large number of years) and so I just told the
installer to forget it.

Now I have a working system and come to mount it, I had incorrectly added it to
/etc/fstab as ext2 and it was failing to mount.  However a manual mount without
specifying the file system type (sudo mount /dev/sdb1 /home/alan/vbox ) made it
work

But now I could examine the failure message and realise its an ext4 without
journal and that is why its not mounting /etc/fstab.




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

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

Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Alan Modra]

The binutils and gdb projects do not even pretend to a stable ABI or
API for libbfd and libopcodes.  Particularly not ABI, that gets broken
on almost every week.  perf and other projects that want to use libbfd
or libopcodes are of course welcome to do so, but they then need to
deal with the changing API.  Complaints that Nick, Alan, or H.J. Lu
have broken perf or similar *will be ignored*, except possibly to tell
you that you may as well stop complaining.

I've said before that the most obvious way to deal with the unstable
API is to import a snapshot of the libbfd and libopcodes code into
those projects and merge from upstream as new upstream support becomes
desirable.  That's not hard to do!

-- 
Alan Modra
Australia Development Lab, IBM

Bug#932582: anbox: ignores mouse input

[Alan MacLeod]

Thanks for continuing to look at this.

anbox check-features
Your computer does meet all requirements to run Anbox

When I check /proc/cpuinfo, the flags are

flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx 
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt aes lahf_lm pti 
ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid dtherm ida 
arat flush_l1d


Which lists SSE4_1 and _2.

What I do know the integrated GPU is missing is OpenGL 3 - this has 
prevented me running a few newer apps in WINE, again, I don't know if 
that is relevant to the issue.


Thanks

Alan

On 17/01/2020 10.06, Shengjing Zhu wrote:

On Thu, Jan 16, 2020 at 4:29 AM Alan MacLeod  wrote:
[...]

version: 4
snap-revision: 186
cpu:
   arch:  x86
   brand: Intel(R) Core(TM) i5 CPU   M 540  @ 2.53GHz
   features:
 - aes

Hmm, just aes? I thought the snap version should refuse to install...
IIRC, anbox needs sse4 to work...

What does `anbox check-features` say?

Bug#932582: anbox: ignores mouse input

[Alan MacLeod]

On 15/01/2020 14.15, Shengjing Zhu wrote:

The snap version includes a software render feature. Maybe you're using this?
This could be slow.
I'm not sure how to verify this, but it makes sense that hardware 
acceleration is not being used.

The Debian package must use hardware render. Intel ARK doesn't show
much information about your CPU's graphic[1].
Maybe this CPU is too old? (run `anbox system-info` will give your some info)

version: 4
snap-revision: 186
cpu:
  arch:  x86
  brand: Intel(R) Core(TM) i5 CPU   M 540  @ 2.53GHz
  features:
    - aes
os:
  name: Debian GNU/Linux
  version:
  snap-based: true
kernel:
  version: Linux version 5.4.0-2-amd64 (debian-ker...@lists.debian.org) 
(gcc version 9.2.1 20200104 (Debian 9.2.1-22)) #1 SMP Debian 5.4.8-1 
(2020-01-05)

  binder: true
  ashmem: true
graphics:
  egl:
    vendor: Mesa Project
    version: 1.4 (DRI2)
    extensions:
  - EGL_ANDROID_native_fence_sync
  - EGL_CHROMIUM_sync_control
  - EGL_EXT_buffer_age
  - EGL_EXT_image_dma_buf_import
  - EGL_EXT_image_dma_buf_import_modifiers
  - EGL_KHR_config_attribs
  - EGL_KHR_create_context
  - EGL_KHR_create_context_no_error
  - EGL_KHR_fence_sync
  - EGL_KHR_get_all_proc_addresses
  - EGL_KHR_gl_colorspace
  - EGL_KHR_gl_renderbuffer_image
  - EGL_KHR_gl_texture_2D_image
  - EGL_KHR_gl_texture_3D_image
  - EGL_KHR_gl_texture_cubemap_image
  - EGL_KHR_image
  - EGL_KHR_image_base
  - EGL_KHR_image_pixmap
  - EGL_KHR_no_config_context
  - EGL_KHR_reusable_sync
  - EGL_KHR_surfaceless_context
  - EGL_EXT_pixel_format_float
  - EGL_KHR_wait_sync
  - EGL_MESA_configless_context
  - EGL_MESA_drm_image
  - EGL_MESA_image_dma_buf_export
  - EGL_NOK_texture_from_pixmap
  - EGL_WL_bind_wayland_display
  gles2:
    vendor: Intel Open Source Technology Center
    vendor: OpenGL ES 2.0 Mesa 18.0.5
    extensions:
  - GL_ANGLE_texture_compression_dxt3
  - GL_ANGLE_texture_compression_dxt5
  - GL_APPLE_texture_max_level
  - GL_EXT_blend_minmax
  - GL_EXT_compressed_ETC1_RGB8_sub_texture
  - GL_EXT_discard_framebuffer
  - GL_EXT_draw_buffers
  - GL_EXT_draw_elements_base_vertex
  - GL_EXT_frag_depth
  - GL_EXT_map_buffer_range
  - GL_EXT_multi_draw_arrays
  - GL_EXT_occlusion_query_boolean
  - GL_EXT_polygon_offset_clamp
  - GL_EXT_read_format_bgra
  - GL_EXT_robustness
  - GL_EXT_separate_shader_objects
  - GL_EXT_texture_border_clamp
  - GL_EXT_texture_compression_dxt1
  - GL_EXT_texture_filter_anisotropic
  - GL_EXT_texture_format_BGRA
  - GL_EXT_texture_rg
  - GL_EXT_texture_type_2_10_10_10_REV
  - GL_EXT_unpack_subimage
  - GL_KHR_blend_equation_advanced
  - GL_KHR_context_flush_control
  - GL_KHR_debug
  - GL_KHR_no_error
  - GL_KHR_robustness
  - GL_NV_draw_buffers
  - GL_NV_fbo_color_attachments
  - GL_NV_read_buffer
  - GL_NV_read_depth
  - GL_NV_read_depth_stencil
  - GL_NV_read_stencil
  - GL_OES_EGL_image
  - GL_OES_EGL_image_external
  - GL_OES_EGL_sync
  - GL_OES_compressed_ETC1_RGB8_texture
  - GL_OES_depth24
  - GL_OES_depth_texture
  - GL_OES_draw_elements_base_vertex
  - GL_OES_element_index_uint
  - GL_OES_fbo_render_mipmap
  - GL_OES_get_program_binary
  - GL_OES_mapbuffer
  - GL_OES_packed_depth_stencil
  - GL_OES_required_internalformat
  - GL_OES_rgb8_rgba8
  - GL_OES_standard_derivatives
  - GL_OES_stencil8
  - GL_OES_surfaceless_context
  - GL_OES_texture_3D
  - GL_OES_texture_border_clamp
  - GL_OES_texture_float
  - GL_OES_texture_float_linear
  - GL_OES_texture_half_float
  - GL_OES_texture_half_float_linear
  - GL_OES_texture_npot
  - GL_OES_vertex_array_object
  - GL_OES_vertex_half_float


Not sure if that provides any insight to help solve why the 
mouse/keyboard won't work with packaged version. I'm comfortable that 
its plausible the CPU is too old, albeit, the PC is circa 2010, so old, 
but not that old.



And I'm not sure if anyone tests anbox with XFCE, the integration with
XFCE may also be a problem.

[1] 
https://ark.intel.com/content/www/us/en/ark/products/43544/intel-core-i5-540m-processor-3m-cache-2-53-ghz.html

Bug#932582: anbox: ignores mouse input

[Alan MacLeod]

Hi,

I've tried both the Snap and packaged versions: the Snap version works 
fully, but is very slow, and the packaged version appears quicker, but I 
cannot interact with the applications - OP's description is exactly what 
I am experiencing: everything opens, I can resize the windows and close 
them, but I cannot interact with the application with mouse or keyboard.


I'm using:
Debian Testing
kernel 5.4.0.2-amd64
XFCE 4.14
HP 8440p laptop - Intel core i5 540, 8 GB RAM

apt policy anbox
anbox:
  Installed: (none)
  Candidate: 0.0~git20191115-1
  Version table:
 0.0~git20191115-1 990
    990 https://deb.debian.org/debian testing/contrib amd64 Packages
    500 https://deb.debian.org/debian unstable/contrib amd64 Packages
    100 /var/lib/dpkg/status
 0.0~git20190124-1 500
    500 https://deb.debian.org/debian stable/contrib amd64 Packages

snap list anbox
Name   Version    Rev  Tracking  Publisher  Notes
anbox  4-56c25f1  186  beta  morphis    devmode

What other info can I provide? I'm currently running the Snap version.

Thanks

Alan

Bug#928375: Announce - swig-4.0.0

[Alan Woodland]

On Mon, 2 Sep 2019 23:02:32 +0200 Torsten Landschoff <
tors...@landschoff.net> wrote:
> On 5/3/19 10:37 AM, Mathieu Malaterre wrote:
> > Would be super nice to have swig 4 in Debian.
> 
> absolutely. And I did not notice for months. I'll have a go - maybe
this
> weekend, but no guarantees!

How did it go? Is there anything you'd like some extra effort from
another person on? I'm pretty invested in SWIG these days, so it'd be
great to see this release in Debian.

Alan

Bug#945235: calamares: Could not set ESP flag in manual partitionning.

[Alan Cole]

Package: calamares
Version: 3.2.16-1
Severity: minor

Dear Maintainer,

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

   * When trying to manual installation could not create an ESP flag
   to the new fat32 partition.

Thanks



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

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

Versions of packages calamares depends on:
pn  kpackagetool5  
pn  libboost-python1.67.0  
ii  libc6  2.29-3
ii  libgcc11:9.2.1-19
pn  libkf5configcore5  
pn  libkf5coreaddons5  
pn  libkf5package5 
pn  libkf5parts5   
pn  libkf5service-bin  
pn  libkf5service5 
pn  libkpmcore8
ii  libparted2 3.3-1
ii  libpwquality1  1.4.2-1
ii  libpython3.7   3.7.5-2
ii  libqt5core5a   5.12.5+dfsg-2
ii  libqt5dbus55.12.5+dfsg-2
ii  libqt5gui5 5.12.5+dfsg-2
ii  libqt5network5 5.12.5+dfsg-2
ii  libqt5qml5 5.12.5-3
ii  libqt5quick5   5.12.5-3
pn  libqt5quickwidgets5
ii  libqt5svg5 5.12.5-2
pn  libqt5webkit5  
ii  libqt5widgets5 5.12.5+dfsg-2
ii  libqt5xml5 5.12.5+dfsg-2
ii  libstdc++6 9.2.1-19
pn  libyaml-cpp0.6 
ii  os-prober  1.77

Versions of packages calamares recommends:
ii  btrfs-progs 5.3.1-1
ii  squashfs-tools  1:4.4-1

calamares suggests no packages.

Bug#942676: mate-menu: Can't add MATE Advanced Menu to panel

[Alan McDonald]

Package: mate-menu
Version: 19.10.2-1
Severity: minor

Dear Maintainer,

I believe the problem is an unexpressed dependency in version 19.10.2-1.

This version of mate-menu requires package: python3-gi-cairo

Manual installation of that package resolved this issue for me on multiple 
physical and virtual machines.

Bug#709161: Help Desk

[LEVINE ALAN]

You have received this message because you have reached your mailbox Quota
limit. Incoming messages will therefore bounce or return to sender.
Reset your quota using this link Click on (*GATEWAY
*)
  to avoid losing incoming messages.

Thanks,
Webmail IT Help Desk

Bug#709161: Help Desk

[LEVINE ALAN]

You have received this message because you have reached your mailbox Quota
limit. Incoming messages will therefore bounce or return to sender.
Reset your quota using this link Click on (*GATEWAY
*)
  to avoid losing incoming messages.

Thanks,
Webmail IT Help Desk

Bug#939119: closed by Yavor Doganov (Bug#939119: fixed in gnustep-base 1.26.0-5)

[Alan Jenkins]

On 19/09/2019 13:09, Yavor Doganov wrote:

Control: reopen -1
Control: found -1 1.26.0-5

Alan Jenkins wrote:

But now I can see the code laid out, I'm not sure the newly added
preinst is doing anything.

You are right that it does nothing :-(

Oddly enough, I've been investigating this on a buster machine
(upgraded from stretch) where all symlinks were K.  It is quite
possible that I've disabled it manually with update-rc.d and I just
don't remember.  However, on a stretch machine not yet upgraded to
buster:

yavor@bogdana:~$ find /etc/rc?.d -name \*gdomap
/etc/rc0.d/K01gdomap
/etc/rc1.d/K01gdomap
/etc/rc2.d/S18gdomap
/etc/rc3.d/S18gdomap
/etc/rc4.d/S18gdomap
/etc/rc5.d/S18gdomap
/etc/rc6.d/K01gdomap
yavor@bogdana:~$ grep ^ENABLED /etc/default/gdomap
ENABLED=no


We only reset the symlinks - i.e. disable the init script - when the
[S]tart symlink does not exist - i.e. the init script is already
disabled?

Stupid me.


You weren't the first person to suggest testing /etc/rc2.d/S??gdomap 
:-). I always think this stuff is confusing.  The important thing is to 
ask for people to test it :-).





If we don't have an ENABLED= line, because we already hit this bug,
then I think we just don't have the information.  We have to make the
choice.

Right.  And the default choice should be to disable the daemon.


Either preserve the current enabled status, as I do above. Or
check we don't have ENABLED=yes, then guess the user was in the
"99.5%", and force the service to be disabled.

I prefer the latter.


1. My hopes had been raised to see something for this issue in Debian 
10.x.  Even if it was basically limited to documentation in NEWS and the 
release notes.  This would raise the question, would you use this 
approach for a backport for 10.x?  Or would that require something 
different?


umm, and if we do disable in 10.x, I have a bonus question.  Would we 
need some code to make sure we didn't disable a second time on upgrade 
to 11.x?



2. For my sake, I am very happy to see gdomap disabled on the next 
upgrade :-).


Our defaults already mean that if you rely on gdomap, you need to know 
that, and enable it. (And if you want network features, change 
GDOMAP_ARGS.  In a way, I think the docs make that sound like more 
hassle than it is).


My only caveat is if you backported this approach to 10.x, I don't know 
enough to guess exactly how many people will be annoyed.


I had another look regarding a clever automatic check we could use in 
the preinst script.  But I didn't come up with anything



3. Disclosure: I think this argument is not very strong:


IOW, if the user wants the daemon running, chances are that he has
already changed the default to ENABLED=yes and although it does
nothing from the buster version onwards, it seems likely that he has
preserved his modification to the /etc/default/gdomap file.


If you choose to see a three-way diff, and see the package wants to 
remove ENABLED=, I think it's just as plausible you would have let the 
package do that.


There might be a way to be really clever, although I do not advocate it 
at all. Provide an upgrade prompt, that checks ENABLED= but otherwise 
defaults to disabling gdomap.  If a gdomap user tends to do upgrades 
Fedora/PackageKit style, i.e. accept all the default prompts, that means 
they will likely have preserved the ENABLED=yes :-).  Non-gdomap users 
will get it disabled again.  At the cost of inflicting one more upgrade 
prompt on a lot of people.



4. The implementation might be improved.


How about this:

if [ "$1" = "upgrade" ]; then
 if dpkg --compare-versions "$2" lt 1.26.0-6; then
 if [ -f /etc/default/gdomap ]; then
 . /etc/default/gdomap
 if [ "$ENABLED" != "yes" ]; then
 find /etc/rc?.d -name "*gdomap" -delete
 fi
 fi
 fi
fi


I guess you did not prefer my super-cautious approach, sourcing the 
config file inside brackets so it uses a sub-shell, and does not import 
arbitrary variables from the file e.g. LD_PRELOAD= :-).


Anyway, in this more aggressive policy, I think it should remove the 
links even if /etc/default/gdomap does not exist.  I think that makes it -


if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-6; then
ENABLED=no
    if [ -f /etc/default/gdomap ]; then
   ENABLED="$( . /etc/default/gdomap && echo "$ENABLED")"
fi
    if [ "$ENABLED" != "yes" ]; then
   find /etc/rc?.d -name "*gdomap" -delete
fi
fi
fi

# or without using a subshell

if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-6; then
ENABLED=no
    if [ -f /etc/default/gdomap ]; then
   . /etc/default/gdomap
fi
    if [ "$ENABLED" != "yes" ]; then
   find /etc/rc?.d -name "*gdomap" -delete
fi
fi
fi


Thanks again for your hard work
Alan

Bug#939119: closed by Yavor Doganov (Bug#939119: fixed in gnustep-base 1.26.0-5)

[Alan Jenkins]

On 18/09/2019 22:21, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the gnustep-base-runtime package:

#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap 
network service to become enabled


It has been closed by Yavor Doganov .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Yavor Doganov 
 by

replying to this email.


[resend: try to fix non-html formatting]

Thanks Yavor, and everyone else. But now I can see the code laid out, 
I'm not sure the newly added preinst is doing anything.


# Upgrades from stretch to buster have made the gdomap daemon enabled
# by default which is undesirable. Explicitly delete the symlinks and
# let update-rc.d recreate them in postinst. See #939119.
# Remove after bullseye is released.
if [ "$1" = "upgrade" ]; then
    if dpkg --compare-versions "$2" lt 1.26.0-5; then
        if [ ! -h /etc/rc2.d/S*gdomap ]; then
            find /etc/rc?.d -name "*gdomap" -delete
        fi
    fi
fi


We only reset the symlinks - i.e. disable the init script - when the 
[S]tart symlink does not exist - i.e. the init script is already disabled?


Shouldn't it look like the below? (I've bumped the package version here :)

if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-6; then
if [ -f /etc/default/gdomap ]; then
if ( . /etc/default/gdomap; [ "$ENABLED" = "no" ]); then
 find /etc/rc?.d -name "*gdomap" -delete
fi
 fi
fi
fi


If we don't have an ENABLED= line, because we already hit this bug, then 
I think we just don't have the information.  We have to make the 
choice.  Either preserve the current enabled status, as I do above. Or 
check we don't have ENABLED=yes, then guess the user was in the "99.5%", 
and force the service to be disabled.


Warm regards
Alan

Bug#939119: closed by Yavor Doganov (Bug#939119: fixed in gnustep-base 1.26.0-5)

[Alan Jenkins]

On 18/09/2019 22:21, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the gnustep-base-runtime package:

#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network 
service to become enabled

It has been closed by Yavor Doganov .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Yavor Doganov 
 by
replying to this email.


Thanks Yavor, and everyone else. But now I can see the code laid out, 
I'm not sure the newly added preinst is doing anything.


# Upgrades from stretch to buster have made the gdomap daemon enabled
# by default which is undesirable. Explicitly delete the symlinks and
# let update-rc.d recreate them in postinst. See #939119.
# Remove after bullseye is released.
if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-5; then
if [ ! -h /etc/rc2.d/S*gdomap ]; then
find /etc/rc?.d -name "*gdomap" -delete
fi
fi
fi


We only reset the symlinks - i.e. disable the init script - when the 
[S]tart symlink does not exist - i.e. the init script is already disabled?


Shouldn't it look like the below? (I've bumped the package version here :)

if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-6; thenif [ -f 
/etc/default/gdomap ]; then if ( . /etc/default/gdomap; [ "$ENABLED" = 
"no" ]); then find /etc/rc?.d -name "*gdomap" -delete fi fi fi


If we don't have an ENABLED= line, because we already hit this bug, then 
I think we just don't have the information.  We have to make the 
choice.  Either preserve the current enabled status, as I do above. Or 
check we don't have ENABLED=yes, then guess the user was in the "99.5%", 
and force the service to be disabled.


Warm regards
Alan

Bug#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network service to become enabled

[Alan Jenkins]

On 01/09/2019 12:52, Michael Biebl wrote:

On 01.09.19 13:24, Alan Jenkins wrote:

Package: gnustep-base-runtime
Version: 1.26.0-4
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

I had "gnustep-base-runtime" installed on my system, probably as a
dependency of "unar".

When I upgrade from Debian 9 to Debian 10 (and reboot), there is a
network server "gdomap".  I did not see this server on Debian 9.
"gdomap" is not wanted.  It is supposed to be disabled by default
since 2013, i.e. in Debian 8.[1]

[1] #717773 "/usr/bin/gdomap: please split out gdomap or disable it by default"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717773

The problem is due to this code change:

"Disable gdomap via defaults-disabled as per Policy 9.3.3.1."
https://salsa.debian.org/gnustep-team/gnustep-base/commit/e0da63fa9e341a38a9a493a615c2c36b8f9d418f

Salvatore Bonaccorso analyzed this for me:


Install a fresh stretch installation and install gnustep-base-runtime
in it. gdomap is not started by default, because gdomap init honours
the ENABLED=no setting in /etc/default/gdomap. Now update the host to
buster.

During this update /etc/default/gdomap is updated according to the
above. Unless the admin has modified it, where then it will be
noticed and admin asked for a decision. As formerly the init was
enabled, and the code to handle the ENABLED setting is removed this
might be the problem. The postinst calls update-rc.d gdomap
defaults-disabled [...]

"update-rc.d" does not do anything in this case.  The man page says


If any files named /etc/rcrunlevel.d/[SK]??name already exist then
update-rc.d does nothing.  The program was written this way so that
it will never change an existing configuration, which may have been
customized by the system administrator.  The program will only
install links if none are present, i.e., if it appears that the
service has never been installed before.

I guess gnustep-base-runtime explicitly needs to remove the existing
/etc/rc?.d/???gdomap symlinks on upgrades in preinst (possibly guarded
by a check which reads the old /etc/default/gdomap and tests if
ENABLED=NO) so they can be properly re-created (and disabled) by
"update-rc.d defaults-disabled"

That said, I find the severity vastly exagerated, but that's just me.


Thanks.  In general I don't know what to do with the severity field 
:-).  I maybe used it once before, and that's it.


IMO this bug is release-relevant.  Then it should be "serious" or above.

#717773 points out that "unar" was installed by default, e.g. in Debian 
7 Desktop. "unar" is not removed on upgrade, even after "apt 
autoremove".  Because "file-roller" still has "Suggests: unar".


#717773 was tagged "security", but the severity was "normal".  The 
current issue is slightly different to #717773, in the sense that it is 
a regression.


The above is post-hoc.  At the time, I just noticed that "reportbug 
--mode=standard" didn't offer me the "security" tag if I filed at 
severity "normal".  And gdomap doesn't run as root, so it's not a root 
bug ("critical").


Alan

Bug#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network service to become enabled

[Alan Jenkins]

Package: gnustep-base-runtime
Version: 1.26.0-4
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

I had "gnustep-base-runtime" installed on my system, probably as a
dependency of "unar".

When I upgrade from Debian 9 to Debian 10 (and reboot), there is a
network server "gdomap".  I did not see this server on Debian 9.
"gdomap" is not wanted.  It is supposed to be disabled by default
since 2013, i.e. in Debian 8.[1]

[1] #717773 "/usr/bin/gdomap: please split out gdomap or disable it by default"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717773

The problem is due to this code change:

"Disable gdomap via defaults-disabled as per Policy 9.3.3.1."
https://salsa.debian.org/gnustep-team/gnustep-base/commit/e0da63fa9e341a38a9a493a615c2c36b8f9d418f

Salvatore Bonaccorso analyzed this for me:

> Install a fresh stretch installation and install gnustep-base-runtime
> in it. gdomap is not started by default, because gdomap init honours
> the ENABLED=no setting in /etc/default/gdomap. Now update the host to
> buster.
>
> During this update /etc/default/gdomap is updated according to the
> above. Unless the admin has modified it, where then it will be
> noticed and admin asked for a decision. As formerly the init was
> enabled, and the code to handle the ENABLED setting is removed this
> might be the problem. The postinst calls update-rc.d gdomap
> defaults-disabled [...]

"update-rc.d" does not do anything in this case.  The man page says

> If any files named /etc/rcrunlevel.d/[SK]??name already exist then
> update-rc.d does nothing.  The program was written this way so that
> it will never change an existing configuration, which may have been
> customized by the system administrator.  The program will only  
> install links if none are present, i.e., if it appears that the 
> service has never been installed before.

It is unfortunate that "Policy 9.3.3.1" does not have an explicit
warning about this potential security problem.

So this is a problem with upgrades.  It does not happen on a fresh
install of Debian 10.

Salvatore also suggested

> I think it's best handled though in a bugreport accordngly, and once
> fixed in unstable, to schedule a fix as well via a buster point
> release.

$ sudo netstat -l -p
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
...
udp0  0 0.0.0.0:gdomap  0.0.0.0:*   
57/gdomap

$ ps aux | grep gdomap
nobody  57  0.0  0.0   2736  2052 ?Ss   11:16   0:00 
/usr/bin/gdomap -I /var/run/gdomap.pid -p -j /var/run/gdomap

$ dpkg-query -S gdomap
gnustep-base-runtime: /usr/share/man/man8/gdomap.8.gz
gnustep-base-runtime: /etc/default/gdomap
gnustep-base-runtime: /usr/bin/gdomap
gnustep-base-runtime: /etc/init.d/gdomap


[Report sent from a systemd-nspawn container, which I used to reproduce the 
issue]

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

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

Versions of packages gnustep-base-runtime depends on:
ii  gnustep-base-common  1.26.0-4
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgnustep-base1.26  1.26.0-4
ii  libobjc4 8.3.0-6
ii  lsb-base 10.2019051400

gnustep-base-runtime recommends no packages.

gnustep-base-runtime suggests no packages.

-- no debconf information

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

On 2019-08-29 11:29+0200 Moritz Mühlenhoff wrote:


I'm seeing the same [instabilities] with RX 570 (which according to Wikipedia 
should
be the same architecture as your RX 550) and the stable Buster release,
both with the standard 4.19 kernel and the 5.2 kernel from buster-backports.


The short story is after a BIOS upgrade my box has been stable for 27 days and 
counting.

For the longer story read on

I am now of the opinion that this whole mess is due to
incompatibilities between real AMD Motherboard and graphics chip sets
*as sold with initial BIOS* to unsuspecting Linux users in the last
couple of years and the AMD documentation of those chip sets (which
Linux kernel developers must rely on).  So the net result of these
initially buggy BIOS's is general Linux-AMD instability.  (Do a google
search for the terms (without quotes) "amd linux instability" and you
will find many sorry tales.)

Up to a month ago, I had solved virtually all the night-time almost
completely idle lockups by using the kernel parameters idle=nomwait
rcu_nocbs=0-15 (where the 15 corresponds to one less than the 16
hardware threads I have on my Ryzen 7 1700 system).  But the rcu_nocbs
parameter requires a special kernel build with a different
configuration (CONFIG_RCU_NOCB_CPU=y) than what Debian supplies.  With
that custom kernel (4.18.10-custom) the idle lockups dropped to just
one for a large number of months, but the active (as opposed to idle)
instability issues still caused lockups with up times between them
that ranged from 0.5 days to 24 days with an average up time of a week
or so.

Soon after I reported this box instability to kernel developers I got
the advice from them to try a BIOS update.  But I put that off for
more than a year because such upgrades are considered to be a last
resort.  The reason for that is they can turn your motherboard into a
brick with low but still non zero probability due to a number of
different causes (such as AMD/Motherboard vendor screw ups with the
BIOS upgrade, internet download errors with the BIOS, power outages
during the BIOS upgrade, etc.)  Also, there was huge churn in the BIOS
upgrades with ASUS (my motherboard vendor) putting out 10 (!) of them
since the BIOS I received when I bought the box.  So I decided to wait
until that churn had settled down, i.e., ASUS had gotten
asymptotically closer to the definitive BIOS for my box.  And
meanwhile the above average up time of ~1 week was livable.

The upshot was that 27 days ago I finally arranged for some
professionals to do the BIOS upgrade.  That made the AMD CBS Power
Supply Idle Control option available for the first time, and I set
that control from "auto" to "Typical Current Idle" (which apparently is an
alternative to setting the custom kernel parameter rcu_nocbs=0-15 for
dealing with idle instability issues).  The net result of this update
is the current up time (still with the same 4.18.10-custom kernel and
kernel parameters) is 27 days and counting which is a new record.  So
I am beginning to hope that this BIOS upgrade has solved the active
lockup issues not covered by rcu_nocbs=0-15, and might even (with
Power Supply Idle Control set to "Typical Current Idle") solve the
idle lockup issues if I drop rcu_nocbs=0-15.

Therefore, if the current up time experiment with kernel 4.18.10 custom is
able to continue for another month or so, my plan is to try a similar
experiment with stock Debian kernel (i.e. without the custom kernel
parameter rcu_nocbs=0-15), and if I get, say ~60 days up time with that
kernel, I will likely conclude this problem has been completely solved,
and I will close this bug report.

Meanwhile, I hope if you decide as a last resort to try updating your
own BIOS (after careful consideration of the known risks), that will
completely solve this issue for you.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#403331: IT Service Desk

[LEVINE ALAN]

*IT Service Desk  upgrade your  Web Mail 2019 Click on (GATEWAY
) and login to Access the new staff
directory. Everyone is advise to migrate immediately to the new update . *

*Admin Help Desk*

*©All Web mail rights reserved.  2019.*

Bug#932388: pure-ftpd-postgresql: Postgresql-based auth fails without error after buster upgrade

[Alan Moore]

Package: pure-ftpd-postgresql
Version: 1.0.43-3
Severity: important

Dear Maintainer,

In stretch I had a working pure-ftpd system with postgresql-based 
authentication.  Passwords were encrypted with crypt.

After buster upgrade, authentication fails with no errors in the logs (logs 
only show authentication failure, even with double verbose flags).  
Downgrading pure-ftpd-common and pure-ftpd-postgresql to versions in stretch 
fixes the issue.

Various facts:

- Postgresql cluster was upgraded to v11 and reindexed.  
- Queries in postgresql.conf can be manually run on the database without issue.
- Postgresql trace shows that all configured queries are successfully running 
and returning results.
- Packages from stretch work fine even with the upgraded Postgresql
- Changing the encryption type makes no difference

** contents of /etc/pure-ftpd/db/postgresql.conf:
PGSQLServer localhost
PGSQLPort   5432 
PGSQLUser   (redacted)  
PGSQLPassword   (redacted)
PGSQLDatabase   (redacted)
PGSQLCrypt  crypt
PGSQLGetPW  SELECT "passwd" FROM users WHERE "userid"='\L' and not disabled
PGSQLGetUID SELECT "uid" FROM users WHERE "userid"='\L'
PGSQLGetGID SELECT "gid" FROM users WHERE "userid"='\L'
PGSQLGetDir UPDATE users SET last_login=NOW() WHERE userid='\L' RETURNING 
"homedir";
** End of /etc/pure-ftpd/db/postgresql.conf


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages pure-ftpd-postgresql depends on:
ii  libc6 2.28-10
ii  libcap2   1:2.25-2
ii  libpam0g  1.3.1-5
ii  libpq511.4-1
ii  libssl1.1 1.1.1c-1
ii  lsb-base  10.2019051400
ii  openbsd-inetd [inet-superserver]  0.20160825-4
ii  pure-ftpd-common  1.0.43-3
ii  zlib1g1:1.2.11.dfsg-1

pure-ftpd-postgresql recommends no packages.

pure-ftpd-postgresql suggests no packages.

-- Configuration Files:
/etc/pure-ftpd/db/postgresql.conf [Errno 13] Permission denied: 
'/etc/pure-ftpd/db/postgresql.conf'

-- no debconf information

Bug#930476: exim4 is no longer installed by default

[Alan Jenkins]

Package: installation-guide
Version: 20170614

> 8.5.1. Default E-Mail Configuration
>
> [...] For this reason the packages exim4 and mutt will be installed 
by default (provided you did not unselect the “standard” task during the 
installation).


I have been told by several people, exim4 is no longer installed by 
default :-).


In Debian 9 and above, exim4-daemon-light has been downgraded from 
"Priority: standard" to "optional".


Thanks
Alan

Bug#926353: python3-pyocr: unknown Tesseract cmdline argument

[Alan Krempler]

With version 4, tesseract switched to double-dashed command-line parameters, 
so it is now --psm instead of -psm.
Upstream addressed the issue in https://gitlab.gnome.org/World/OpenPaperwork/
pyocr/commit/c136838b46cf49f06ac1dc5f2f9bc16232c11213
Until a newer version is packaged, you can get your stuff going by replacing "-
psm" with "--psm" in /usr/lib/python*/dist-packages/pyocr/
{tesseract,builder}.py

Cheers
Alan

Bug#929466: FreeRADIUS opinion of this issue

[Alan DeKok]

  Here's what we sent CVE.  In short, there is no actual "exploit".

---
We disagree with this CVE.  In the GitHub report [1], the RedHat
reporter claims:

> we are aware of a way to exploit this,

No description of this alleged exploit has been shared with us.

Our security contact is "secur...@freeradius.org", which has been
active for almost 20 years.  This address and security instructions
are available on our web site at:

https://freeradius.org/security/

It is not clear why RedHat would refuse to share information about
this issue, as is normal practice.

In the GitHub report, RedHat further claims that exploitation

>  ... requires the attacker to already have "high privileges" (that is, he 
> needs to have access to the radiusd user)

Which demonstrates that this issue is largely nonsense.  A full explanation 
follows.

While the FreeRADIUS server runs as user/group "radiusd/radiusd", that
account has no login shell, no home directory, and no default
password.  The account is used solely to run the FreeRADIUS server,
and to control ownership of configuration files and log files.  These
files are typically administered solely by the "root" user.

As such, the CVE can be better stated as "if the root user
misconfigures FreeRADIUS, then the RADIUS server can later elevate
privileges to root".

We have to ask why the "root" user would need to leverage a
less-privileged account in order to gain "root" permissions.

Further, anyone who can operate as the RADIUS server can perform all
RADIUS authentication and authorization.  i.e. authenticating all
users on the network, including unknown and malicious users.

There is at this time no known exploit which would let malicious users
gain access to the "radiusd" user.  Therefore as discussed here, there
is simply no way for anyone to *gain* privileges through this alleged
issue.

In addition, there also appears to be disagreement within RedHat about
the severity and scope of this issue.  The original reporter [2]
states:

> The su directive to logrotate ensures that log rotation happens under the
> owner of the logs. Otherwise, logrotate runs as root:root, potentially
> enabling privilege escalation if a RCE is discovered against the
> FreeRADIUS daemon.
>
> This attack avenue seems quite unlikely to me.

We agree.  We take great care in securing FreeRADIUS.  We use multiple
source code analyzers and fuzzing tests.

Even the most charitable interpretation of this issue shows that the
vulnerability is theoretical in nature, and is not currently
exploitable.

As such, we disagree with the issuance of this CVE.  We also express
dismay at the process by which this CVE was issued.  We recommend that
security "experts" follow best practices in discussing issues with
authors prior to requesting spurious CVEs.


[1] 
https://github.com/FreeRADIUS/freeradius-server/pull/2666#issuecomment-495511510
[2] https://github.com/FreeRADIUS/freeradius-server/pull/2666#issue-276755666

---


signature.asc
Description: Message signed with OpenPGP

Bug#928888: On debian 9, /etc/init.d/hostapd shows [ ok ], when actually hostapd failed to start

[Alan Jenkins]

Package: hostapd
Version: 2.4-1+deb9u3

https://salsa.debian.org/debian/wpa/blob/debian/2%252.4-1+deb9u2/debian/hostapd.init

log_daemon_msg "Starting $DESC" "$NAME"
start-stop-daemon --start --oknodo --quiet --exec "$DAEMON_SBIN" \
--pidfile "$PIDFILE" -- $DAEMON_OPTS >/dev/null
log_end_msg "$?"

I.e. it fails to pass on the exit status from start-stop-daemon.  As a
result, *** when this specific version of hostapd is used with systemd
*** , "[ ok ]" is shown even if hostapd failed :

> # /etc/init.d/hostapd start
> [ ok ] Starting hostapd (via systemctl): hostapd.service.
> ...
> The error in journalctl -b -u hostapd is:
> Starting advanced IEEE 802.11 management: hostapd failed!

The above is taken from the user report / support request at
https://unix.stackexchange.com/questions/518466/hostapd-hotspot-not-running

In Debian buster, this problem with systemd will be entirely solved,
because we now have hostapd.service, a native systemd service.  Yay!

However there is still this bug in the init script.  Other init
systems are available. These may rely on the old-style init.d scripts,
and may or may not give similarly confusing results.  So it would
still be nice to fix this bug.

I searched for a standard template for a Debian init script.  It turns
out /etc/init.d/skeleton went away, because simple scripts should now
be written using `init-d-script` .  There is a man page for it.  The
current man page is missing a lot of critical information, e.g.
forgets to mention how to pass arguments to the daemon :-( .  The
answers are in the source code, e.g. you can set DAEMON_ARGS.

The hack with "sleep 8" should be easy to re-create if necessary by
defining do_restart_override() and do_force_reload_override() .  I
guess that you are still finding it necessary, seeing as you have
defined RestartSec=2 in the systemd service.

source code link:
https://salsa.debian.org/debian/sysvinit/commit/fbf700964e86953d2c573229c39482db0b9e1eb7

---

There's a similar example showing how this init script incorrectly
shows "active" instead of "failed" in "systemctl status" :
https://github.com/raspberrypi/firmware/issues/1117 :

# service hostapd status
hostapd.service - LSB: Advanced IEEE 802.11 management daemon
   Loaded: loaded (/etc/init.d/hostapd; generated; vendor preset: enabled)
   Active: active (exited) since Wed 2019-02-27 21:05:29 UTC; 3s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 2177 ExecStop=/etc/init.d/hostapd stop (code=exited,
status=0/SUCCESS)
  Process: 2212 ExecStart=/etc/init.d/hostapd start (code=exited,
status=0/SUCCESS)

Feb 27 21:05:29  systemd[1]: Starting LSB: Advanced IEEE
802.11 management daemon...
Feb 27 21:05:29  hostapd[2212]: Starting advanced IEEE
802.11 management: hostapd failed!
Feb 27 21:05:29  systemd[1]: Started LSB: Advanced IEEE
802.11 management daemon.

Bug#928658: bilibop-lockfs: Mounting /boot fails, mount.lockfs is broken

[Alan]

Package: bilibop-lockfs
Version: 0.5.5
Severity: important

Hello,

The system fails to boot after installing bilibop-lockfs and activating it on a 
freshly installed Debian (Buster/testing).

Please note that this was tested on a encrypted LVM created during Debian 
installation.

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

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

Versions of packages bilibop-lockfs depends on:
ii  bilibop-common   0.5.5
ii  initramfs-tools  0.133
ii  udev 241-3

Versions of packages bilibop-lockfs recommends:
ii  cryptsetup  2:2.1.0-3

Versions of packages bilibop-lockfs suggests:
pn  aufs-dkms  
pn  bilibop-device-policy  
pn  gnome-icon-theme   
ii  libnotify-bin  0.7.7-4
ii  plymouth   0.9.4-1.1

-- no debconf information

Bug#928270: PFilePattern change needed for Fedora 29 and 30

[Alan Jenkins]

Package: apt-cacher-ng
Version: 2-2

Hi

I have to use the following extra pattern for Fedora 29 and 30.
Something told me I should send this in.

PfilePatternEx:
[a-f0-9]+-modules.yaml.gz|[a-f0-9]+-(primary|filelists|comps-[^.]*.[^.]*|updateinfo|prestodelta).xml(|.gz|.xz|.zck)

To be honest I started using the modules.yaml pattern a while ago for
Fedora 29.  I think I looked at submitting a patch to
acfg_defaults.cc, but then I got too scared or bored by it.

The second pattern is needed for the shiny new "zchunk"
compression/sync format, that Fedora started using just now.

Thanks for many years saving my bandwidth :-)
Alan

Bug#926453: Patch for Bug#926453: gnome-shell: Using On-screen keyboard "flag" key closes the keyboard)

[Alan]

Please find a patch at:

https://salsa.debian.org/tails-team/gnome-shell/commit/79232a3be0151917d90c583782164c7939be2f16

Cheers

Bug#926452: Patch for Bug#926452: On-screen keyboard lacks several french layouts)

[Alan]

Please find a patch at:

https://salsa.debian.org/tails-team/gnome-shell/commit/50a803f66840f72aba2b7d1ddf3c1d8174db0bab

Cheers

Bug#926453: gnome-shell: Using On-screen keyboard "flag" key closes the keyboard

[Alan T.]

Package: gnome-shell
Version: 3.30.2-3.2
Severity: normal
Tags: upstream l10n a11y

Dear Maintainer,

On the Gnome On-Screen Keyboard there is a "flag" key that show a menu listing
the available layouts. But moving the pointer over this menu closes the
keyboard.

This is reported upstream at https://gitlab.gnome.org/GNOME/gnome-
shell/issues/171 and solved by https://gitlab.gnome.org/GNOME/gnome-
shell/merge_requests/401. The patch are easy to backport to 3.30.2 and fix the
issue.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-3
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-1
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4
ii  gir1.2-mutter-3  3.30.2-6
ii  gir1.2-nm-1.01.14.6-2
ii  gir1.2-nma-1.0   1.8.20-1
ii  gir1.2-pango-1.0 1.42.4-6
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-3.2
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-8
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1
ii  libedataserver-1.2-233.30.5-1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-1
ii  libglib2.0-bin   2.58.3-1
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-6
ii  libnm0   1.14.6-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4
ii  libpulse012.2-4
ii  libsecret-1-00.18.7-1
ii  libstartup-notification0 0.12-6
ii  libsystemd0  241-1
ii  libx11-6 2:1.6.7-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.30.2-6
ii  python3  3.7.2-1

Versions of packages gnome-shell recommends:
ii  bolt  0.7-2
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.30.2-3
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.30.3-1
ii  gnome-user-docs   3.30.2-1
ii  iio-sensor-proxy  2.4-2
ii  switcheroo-control1.2-2
ii  unzip 6.0-22

Versions of packages gnome-shell suggests:
pn  gir1.2-telepathyglib-0.12   
pn  gir1.2-telepathylogger-0.2  

-- debconf-show failed

Bug#926452: gnome-shell: On-screen keyboard lacks several french layouts

[Alan T.]

Package: gnome-shell
Version: 3.30.2-3.2
Severity: normal
Tags: upstream l10n a11y

Dear Maintainer,

On buster, the gnome On-screen keyboard, that can be triggered from Settings >
Universal Access > Typing > Screen Keyboard does not have french layout. This
is especially annoying as it prevents entering french accented letters.

This bug is solved upstream at https://gitlab.gnome.org/GNOME/gnome-
shell/issues/997 and solved by https://gitlab.gnome.org/GNOME/gnome-
shell/commit/859aef78c4d2472b2545ce9ecc889c00b9893494. The patches applies to
3.30.2 and fixes the issue.



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

Kernel: Linux 4.19.0-4-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1554474138 WARNING 
torsocks[2499]: [syscall] Unsupported syscall number 217. Denying the call (in 
tsocks_syscall() at syscall.c:568)
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1554474138 WARNING torsocks[2501]: 
[syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() 
at syscall.c:568)
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-3
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-1
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4
ii  gir1.2-mutter-3  3.30.2-6
ii  gir1.2-nm-1.01.14.6-2
ii  gir1.2-nma-1.0   1.8.20-1
ii  gir1.2-pango-1.0 1.42.4-6
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-3.2
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-8
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1
ii  libedataserver-1.2-233.30.5-1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-1
ii  libglib2.0-bin   2.58.3-1
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-6
ii  libnm0   1.14.6-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4
ii  libpulse012.2-4
ii  libsecret-1-00.18.7-1
ii  libstartup-notification0 0.12-6
ii  libsystemd0  241-1
ii  libx11-6 2:1.6.7-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.30.2-6
ii  python3  3.7.2-1

Versions of packages gnome-shell recommends:
ii  bolt  0.7-2
ii  chrome-gnome-shell10.1-5
ii  gdm3  

Bug#726962: Bug #726962

[Alan Coopersmith]

The '..' macro was removed upstream in the xinit 1.4.0 release:
https://gitlab.freedesktop.org/xorg/app/xinit/commit/52689362

The hair spaces between dashes recommended in this bug were added upstream
in the xinit 1.4.1 release:
https://gitlab.freedesktop.org/xorg/app/xinit/commit/752ef176

The issue in the previous comment about the Debian text accidentally
inserted in the #ifdef __SCOMAN__ section appears have to been resolved
by reworking that patch for the 1.4.0 release after the __SCOMAN__
ifdef was removed upstream.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

Bug#712953: sysvinit: System Restarts Instead of Powering Off

[Alan Chandler]

On 09/03/2019 2:41 am, Ben Hutchings wrote:

Control: tag -1 moreinfo

On Fri, 21 Jun 2013 09:13:19 +0100 "Alan Chandler" <
a...@chandlerfamily.org.uk> wrote:

Package: sysvinit
Version: 2.88dsf-41
Severity: normal

Dear Maintainer,

When I attempt to power off the machine (either logging out of gnome3, or via 
shutdown now typed in at a terminal)
the system goes through the shutdown sequence (it does seem to pause after 
telling all processes to terminate and
then reports that some processes are still running). It finally reports it is 
about to power off.

But the computer then restarts and reboots.

If I load up Debian Wheezy and shut that down, the computer powers off properly.

Sorry this report took so long to get assigned properly.  Is this still
happening in a current Debian version?

Ben.
  


This was 6 years ago.  I don't have the problem now.

--
Alan Chandler
http://www.chandlerfamily.org.uk

Bug#923034: FreeRADIUS status

[Alan DeKok]

  We've been looking for a new Debian maintainer for a while.

  What, exactly, is in "bad shape" about this package?  If there are issues, we 
can work towards fixing them.

  The software is widely used by many tens of thousands of sites.  I hope it's 
not going to be removed from Debian.

  I'll note that Debian also packages "livingston-radius", which hasn't had any 
source changes in 20 years.  There's no mailing list, no support, and it 
doesn't implement any of the modern RADIUS standards.

  Including that package does a disservice to people who install it, and then 
realize it's next to useless.

Bug#648158: Fix applied upstream

[Alan Coopersmith]

https://gitlab.freedesktop.org/xorg/app/xcompmgr/commit/9c86c0f21b9d34c0ae491327482415a946102c4f

Bug#921599: python-mysqldb: always connects to localhost ignoring host entry in option file

[Alan Krempler]

Package: python-mysqldb
Version: 1.3.10-2
Severity: normal

When connecting like this:
connection = MySQLdb.connect(read_default_file=dbconfig)
lines in the option file specifying a remote host are ignored.
Whatever host is specified in the option file, python-mysqldb always attempts a
connection to localhost.

Named host parameters to MySQLdb.connect() are handled correctly.

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

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

Versions of packages python-mysqldb depends on:
ii  libc62.28-5
ii  libmariadb3  1:10.3.12-2
ii  libssl1.11.1.1a-1
ii  python   2.7.15-4
ii  zlib1g   1:1.2.11.dfsg-1

python-mysqldb recommends no packages.

Versions of packages python-mysqldb suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.12-2
pn  python-egenix-mxdatetime
pn  python-mysqldb-dbg  

-- no debconf information

Bug#918774: This bug now fixed upstream

[Alan W. Irwin]

With a substantial effort (learning much more about pango and freetype
than I wanted to) I have now fixed this (and several other) upstream
bugs in libLASi and made a bugfix release 1.1.3 containing these
improvements that has been well tested on Debian Buster.  See
<https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/>
for the details concerning that release.

So packaging libLASi-1.1.3 (which should be straightforward since the
libLASi build system has not changed that much from earlier versions)
as requested at
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921139> should
automatically address this current bug report as well.

Alan
______
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#921139: lasi: is two important bug fix releases behind upstream

[Alan W. Irwin]

Source: lasi
Version: 1.1.0-2
Severity: important

Dear Maintainer,

As primary maintainer of upstream libLASi I note that lasi version
1.1.0 was released in 2008-02-08 and has been superseded since by
three important bug fix releases, 1.1.1, 1.1.2, and most recently (see
<https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/>
1.1.3.  Throughout this series of bug fixes the libLASi CMake-based
build system has remained mostly the same so it should be entirely
straightforward to update your current packaging of 1.1.0 to 1.1.3.

Making these bug fixes available to Debian (and derivative
distribution) users will greatly improve their experience with this
library.  For example, the recent release of 1.1.3 includes a fix for
the important issue reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918774.  So as soon
as you package 1.1.3 to address the current important bug, that
important bug gets automatically fixed as well.

Alan

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

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

Bug#918774: Simple method of verifying this bug

[Alan W. Irwin]

In fact, it turned out that the libLASi-1.1.0 version of MissingGlyphExample.cpp
did not verify this bug.  So I looked more carefully at the PLplot results, and
the first problem of this kind occurred for Unicode U+2648 = ♈.

So I tried that glyph in MissingGlyphExample.cpp using the following patch:

---8x--
--- MissingGlyphExample_original.cpp2008-02-08 17:27:56.0 -0800
+++ MissingGlyphExample.cpp 2019-01-09 11:47:55.134114211 -0800
@@ -22,7 +22,7 @@
 //
 doc.osBody() << setFont("Arial") << setFontSize(18) << endl;
 //char testString[]={0xe2,0xab,0xb4,0x00};
-const char *testString="Unicode U+2AF4 — U+2AF8 glyphs are : ⫴⫵⫶⫷⫸.";
+const char *testString="Unicode U+2648 glyph is : ♈";
 //
 // Show the string:
 //
---8x--

and after configuring and building libLASi-1.1.0 with the above patch applied 
using

cmake 

I got the following result that is a simple (non-PLplot) verification
of the issue.

irwin@merlin> make; examples/example0 >| test.ps ; echo "return code = $?"
[ 15%] Built target documentation
[ 53%] Built target LASi
[ 69%] Built target example1
Scanning dependencies of target example0
[ 76%] Building CXX object 
examples/CMakeFiles/example0.dir/MissingGlyphExample.o
[ 84%] Linking CXX executable example0
[ 84%] Built target example0
[100%] Built target example2
Error returned from FT_Load_Glyph
return code = 1

Both of libLASi and gucharmap depend on similar subsets of the GTK+ suite of 
libraries.

Therefore, I looked up U+2648 using gucharmap, and for that GUI, that glyph 
renders properly
without issues.  With gucharmap you can specify a particular font preference 
which fontconfig
processes to come up with the actual font used to render the glyph which you 
can discover
by right-clicking on the glyph.  When I did that, the actual font used for the 
gucharmap rendering
of this glyph was the Noto Color Emoji font from the fonts-noto-color-emoji 
package.

So I temporarily removed that font package, and all was well with the
above examples/example0 test *and* PLplot testing of our psttf device
driver as well.

So it appears that GTK+ applications such as gucharmap can render
glyphs from Noto Color Emoji with ease, but libLASi currently throws
an error on those.  So that is an upstream bug in libLASi which I
likely cannot fix without expert help.  I will attempt to get that
help from the upstream libLASi developers who I was associated with in
the past, and if I get that help I can certainly make another libLASi
bugfix release that deals with this issue.  But just in case I cannot
find them at all please let me know if you have some ideas about how
to fix this libLASi bug.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#918774: liblasi0: response to missing system glyphs no longer works correctly

[Alan W. Irwin]

Package: liblasi0
Version: 1.1.0-2
Severity: important

Dear Maintainer,

Since one of my recent Debian Buster upgrades I have been getting the
following run-time errors with libLASi when a missing system glyph is
encountered:

terminate called after throwing an instance of 'std::runtime_error'
  what():  Error returned from FT_Load_Glyph
Aborted

You definitely don't want libLASi to throw errors and abort when
encountering missing system glyphs because that situation is fairly
common.  Therefore, I have rated the severity level of this bug as
important.

The relevant libLASi code that attempts to do something responsible
when encountering missing system glyphs is the following code in
libLASi-1.1.0 (and also libLASi-1.1.2).

FT_Error error = FT_Load_Glyph(face,glyph_index,FT_LOAD_NO_BITMAP);
if(error){
   //
   //DEBUG:
   //
   //std::cerr << "PANGO is returning a glyph index of " << std::hex << 
glyph_index << std::endl;
   //std::cerr << "but PANGO_GLYPH_UNKNOWN_FLAG is supposed to be: " << 
0x1000 << std::endl;
   //std::cerr << "and PANGO_GLYPH_EMPTYis supposed to be: " << 
0x0FFF << std::endl;
   
   //
   // Substitute something that works: All fonts are supposed
   // to handle glyph_index 0 as the default replacement glyph:
   //
   
evalReturnCode(FT_Load_Glyph(face,0,FT_LOAD_NO_BITMAP),"FT_Load_Glyph"); 
}else{
   evalReturnCode(FT_Load_Glyph(face, glyph_index,FT_LOAD_NO_BITMAP), 
"FT_Load_Glyph");
}

where evalReturnCode is the following inline routine (in both 1.1.0 and 1.1.2):

/** Converts a freetype return code into an exception.
 */
inline void evalReturnCode(const int errCode, const char* funcName) throw 
(std::runtime_error) {
  if (errCode)
throw std::runtime_error(std::string("Error returned from ") + funcName);
}

So the obvious purpose of the above code is whenever there is some
issue with FT_Load_Glyph for a give glyph_index it tries again with
glyph_index = 0 which according to the above notes should always "just work" 
without
throwing an error.

In any case this technique for avoiding throwing errors on missing glyphs worked
perfectly over the years, and I can see no
reason why it has suddenly started throwing errors now.  But since my
recent Debian Buster upgrades did not involve libLASi, this bug should
likely be reported against one of the many dependencies of libLASi,
but I don't know which one so I have started the process by reporting
the bug here.

I haven't tried this myself yet, but I am virtually positive you can
easily verify this issue by building and running
libLASi-1.1.0/examples/MissingGlyphExample.cpp.

Instead of performing that direct test of libLASi, I have been
indirectly testing libLASi over many years via regular PLplot testing
since PLplot includes the psttf device which links to libLASi.  The
examples we test do include missing glyphs, and my recent PLplot tests
have recently started erroring out with the above abort for our psttf
device driver which is the motivation for this bug report.

FYI, I am far from expert with libLASi and C++, but I do have some
familiarity with the libLASi code because I have helped some upstream
with its build system and bug releases over the years (because of my
PLplot interest).

So if there are some further tests you would like me to try because
you are having trouble verifying this bug with
MissingGlyphExample.cpp, please let me know.

Alan

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

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

Versions of packages liblasi0 depends on:
ii  libc6  2.28-2
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3
ii  libgcc11:8.2.0-13
ii  libglib2.0-0   2.58.2-3
ii  libpango-1.0-0 1.42.4-6
ii  libpangoft2-1.0-0  1.42.4-6
ii  libstdc++6 8.2.0-13

liblasi0 recommends no packages.

liblasi0 suggests no packages.

-- no debconf information

Bug#916457: grub2-common: Grub refuses to re-enable IPv6 traffic

[Alan Reding]

Hello Colin

Thanks for your response.

Following your reply, I did a test which consisted of the following steps:

1. I ran sudo gedit /etc/default/grub, deleted/removed 
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet", ran sudo update-grub and 
rebooted my machine.

2. Immediately after the reboot, I issued the command nano /proc/cmdline and 
below is the result:

BOOT_IMAGE=/boot/vmlinuz-4.18.0-0.bpo.1-amd64 root=UUID=[string of alphanumeric 
characters] ro ipv6.disable=1 quiet

3. Next, I ran the command sudo grep -RF ipv6.disable /etc and below is the 
result:

/etc/default/grub.ucf-old:#GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet"
/etc/default/grub:GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet"

I am puzzled why ipv6.disable=1 quiet appears in the above results of (2) and 
(3) despite the fact that I had deleted/removed 
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet" from /etc/default/grub.

Regards.

Alan Reding



On Fri, 12/14/18, Colin Watson  wrote:

 Subject: Re: Bug#916457: grub2-common: Grub refuses to re-enable IPv6 traffic
 To: "Alan Reding" , 916...@bugs.debian.org
 Date: Friday, December 14, 2018, 10:56 PM
 
 On Fri, Dec 14, 2018 at 05:23:35PM +, Alan Reding
 wrote:
 > To block IPv6 traffic, I do the following:
 > 
 > 1. Add the following line to /etc/default/grub
 > 
 > GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet"
 > 
 > 2. Run update-grub
 > 
 > 3. In /etc/hosts, add # in front of all lines that
 mention IPv6 hosts
 > 
 > 3. Reboot machine
 > 
 > To re-enable IPv6 traffic, I do the following:
 [...]
 
 GRUB just passes the stuff in GRUB_CMDLINE_LINUX_DEFAULT
 straight
 through to the kernel; it has no other involvement in how
 the operating
 system's networking stack is set up.  This could only
 possibly be a GRUB
 bug if you're finding that update-grub isn't correctly
 transferring
 GRUB_CMDLINE_LINUX_DEFAULT into /boot/grub/grub.cfg, or if
 the kernel
 parameters are somehow not actually being passed to the
 kernel (which
 you can check after boot by looking in /proc/cmdline). 
 Otherwise, this
 cannot possibly be a GRUB bug, and I'd appreciate it if you
 could either
 close it or figure out some other suitable package to
 reassign it to, as
 appropriate.
 
 > Method A
 > 
 > 4. Add # in front of the line that contains
 > GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet" as in
 below:
 > 
 > #GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet"
 > 
 > 5. Run update-grub
 > 
 > 6. In /etc/hosts, remove # from all lines that mention
 IPv6 hosts
 > 
 > 7. Reboot machine
 > 
 > Result: IPv6 traffic is still blocked
 > 
 > Method B
 > 
 > 8. In /etc/default/grub, I delete the line
 > GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet"
 > 
 > 9. Run update-grub
 > 
 > 10. In /etc/hosts, I ensure that # does not appear in
 front of lines that
 > mention IPv6 hosts
 > 
 > 11. Reboot machine
 > 
 > Result: IPv6 traffic is still blocked
 > 
 > Method C
 > 
 > 12. In /etc/default/grub, I change the value of
 ipv6.disable=0 as in:
 > 
 > GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=0 quiet"
 > 
 > 13. Run update-grub
 > 
 > 14. In /etc/hosts, I ensure that # does not appear in
 front of lines that
 > mention IPv6 hosts
 > 
 > 15. Reboot machine
 > 
 > Result: IPv6 traffic is NOT blocked. IPv6 traffic is
 re-enabled
 
 These symptoms indicate to me that the equivalent of
 ipv6.disable=1 is
 being set somewhere else *as well*, which causes things to
 only work
 properly if you explicitly pass the kernel argument
 ipv6.disable=0.  I'd
 suggest looking around in /etc/, perhaps /etc/modprobe.d/.
 
 -- 
 Colin Watson             
                
          [cjwat...@debian.org]
 
 -Inline Attachment Follows-
 
 

Bug#916474: emacs-gtk: does not render certain UTF-8 symbols that other applications (both GTK and Qt based) render without problems

[Alan W. Irwin]

 for X.Org fonts
ii  xfonts-scalable   1:1.0.3-1.1  
all  scalable fonts for X
ii  xfonts-utils  1:7.7+6  
amd64X Window System font utility programs

Alan

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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common   1:25.2+1-11
ii  emacs-common   1:25.2+1-11
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.7-1+b1
ii  libatk1.0-02.30.0-1
ii  libc6  2.27-8
ii  libcairo-gobject2  1.16.0-1
ii  libcairo2  1.16.0-1
ii  libdbus-1-31.12.10-1
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3
ii  libgdk-pixbuf2.0-0 2.38.0+dfsg-6
ii  libgif75.1.4-3
ii  libglib2.0-0   2.58.1-2
ii  libgnutls303.5.19-1+b1
ii  libgomp1   8.2.0-9
ii  libgpm21.20.7-5
ii  libgtk-3-0 3.24.1-2
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libm17n-0  1.8.0-2
ii  libmagickcore-6.q16-6  8:6.9.10.14+dfsg-7
ii  libmagickwand-6.q16-6  8:6.9.10.14+dfsg-7
ii  libotf00.9.13-4
ii  libpango-1.0-0 1.42.4-4
ii  libpangocairo-1.0-01.42.4-4
ii  libpng16-161.6.34-2
ii  librsvg2-2 2.44.9-1
ii  libselinux12.8-1+b1
ii  libsm6 2:1.2.2-1+b3
ii  libtiff5   4.0.10-3
ii  libtinfo6  6.1+20181013-1
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb11.13.1-1
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-2
ii  libxinerama1   2:1.1.4-1
ii  libxml22.9.4+dfsg1-7+b2
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-1

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
pn  emacs-common-non-dfsg  

-- no debconf information

Bug#916459: macchanger fails to work on backported kernel of Debian 9.6

[Alan Reding]

Package: macchanger
Version: 1.7.0-5.3+b1
Severity: grave
Tags: upstream
Justification: renders package unusable

Hi

As the subject line says, running

sudo macchanger eth0

does not result in a different MAC address



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

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 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 macchanger depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  dpkg   1.18.25
ii  libc6  2.24-11+deb9u3

macchanger recommends no packages.

macchanger suggests no packages.

-- debconf-show failed

Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it

[Alan DeKok]

On Dec 12, 2018, at 3:48 PM, Andrej Shadura  
wrote:
> 
> On 05/12/2018 09:52, Andrej Shadura wrote:
>> On 05/12/2018 00:09, Jouni Malinen wrote:
>> Right, so what would you recommend for me to do in the meanwhile?
>> Hardcode a minimal version just for wpa-supplicant to TLSv1.0? What
>> about ciphers? Anything else?
> 
> I would really appreciate some opinion from Jouni or other people on
> this list.

  My $0.02 is to have an "allow TLSv1.0" configuration option, but have it 
disabled by default.  It's what we do in FreeRADIUS.

  It's arguably bad in minor ways to allow TLSv1.0.  But preventing people from 
getting online is likely worse.

  Alan DeKok.

Bug#915420: shutter: not responding

[Alan Christopher Gormley]

Package: shutter
Version: 0.88.3-1
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

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

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



-- System Information:
Debian Release: 7.11
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages shutter depends on:
ii  imagemagick  8:6.7.7.10-5+deb7u4
ii  libfile-basedir-perl 0.03-1
ii  libfile-copy-recursive-perl  0.38-1
ii  libfile-which-perl   1.09-1
ii  libglib-perl 3:1.260-1
ii  libgnome2-canvas-perl1.002-2+b2
ii  libgnome2-gconf-perl 1.044-4
ii  libgnome2-perl   1.042-2+b2
ii  libgnome2-vfs-perl   1.081-3+b1
ii  libgnome2-wnck-perl  0.16-2+b2
ii  libgtk2-imageview-perl   0.05-1+b2
ii  libgtk2-perl 2:1.244-1+deb7u1
ii  libgtk2-unique-perl  0.05-1+b2
ii  libjson-perl 2.53-1
ii  libjson-xs-perl  2.320-1+b1
ii  liblocale-gettext-perl   1.05-7+b1
ii  libnet-dbus-perl 1.0.0-1+b1
ii  libnet-dropbox-api-perl  1.8-1
ii  libpath-class-perl   0.26-1
ii  libproc-processtable-perl0.45-6
ii  libproc-simple-perl  1.30-1
ii  librsvg2-common  2.36.1-2+deb7u1
ii  libsort-naturally-perl   1.02-1
ii  libwww-mechanize-perl1.71-1
ii  libwww-perl  6.04-1
ii  libx11-protocol-perl 0.56-4
ii  libxml-simple-perl   2.20-1
ii  perlmagick   8:6.7.7.10-5+deb7u4
ii  procps   1:3.3.3-3
ii  xdg-utils1.1.0~rc1+git20111210-6+deb7u3

Versions of packages shutter recommends:
ii  libgoo-canvas-perl  0.06-1+b2

Versions of packages shutter suggests:
pn  gnome-web-photo 
pn  libimage-exiftool-perl  
pn  libnet-dbus-glib-perl   
pn  nautilus-sendto 

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Alan Corey]

Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
compile your program?  Supply both libraries?  ES gives an enormous
performance boost to little machines that need it, desktop OpenGL is
more pretty pictures.

On 11/26/18, Lisandro Damián Nicanor Pérez Meyer  wrote:
> El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
>> Hello Lisandro,
>>
>> TLDR: thank you for starting this discussion, it was required as it's not
>> an easy decision to take as there is no realistic perfect solution,
>
> Our (team-wide) pleasure. This is something we have been digging since
> 2015.
>
>> but I
>> believe you took the wrong decision. Please consider deferring the
>> decision to the technical committe by seeking his advice (point 6.1.3
>> of the constitution
>> https://www.debian.org/devel/constitution.en.html#item-6).
>
> Will "kind of" do. Read below.
>
>
>> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
>> > It seems now clear that the general consensus seems to expect:
>> > = Qt available for both Desktop and ES OpenGL flavours
>> > = If no change is possible, keep arm64 with Desktop OpenGL support
>>
>> I'm not pleased with how this discussion was handled. First of all,
>> you did not leave enough time for all stakeholders to participate in
>> the discussion (started on November 22th, closed November 25th, 3 days,
>> that's not a reasonable timeframe in particular when 2 of the 3 days
>> were in the week-end).
>
> My most sincere apologies if our timeframe do not fit yours.
>
> Now, wrt the decision: clearly the situation is very complex, involving many
>
> different kinds of arm64 devices, drivers, libraries et all. People involved
>
> have different opinions. We so far have been the proxy between them, be it
> on
> bugs, IRC or whatever other channels our users have to contact us. We prefer
>
> not to be this proxy anymore (again, read below).
>
> Besides we (Qt's team) have just learned that the Desktop/ES support is not
>
> tied to the hardware but to the driver. That's a particularly interesting
> point.
>
> So:
>
> To quote my original mail, the "Qt available for both Desktop and ES OpenGL
>
> flavours" point remains unchanged: if someone wants to make it happen [s]he
>
> must join the team and support it from the inside. Remember there are little
>
> chances for this to happen in time for Buster.
>
> For the second point, "If no change is possible, keep arm64 with Desktop
> OpenGL support", we have this position: we will keep the status quo,
> deferring
> users who want GLES support to Ubuntu.
>
> *But* we are open to change this for any arch (read it: support either one
> or
> the other technology) as long as the decision is taken by the technical
> committee. As I wrote before, we will keep the status quo, so if anyone is
> interested in any change feel free to contact the TC.
>
> Regards, Lisandro.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Bug#913947: shutter: freezing

[Alan Christopher Gormley]

Package: shutter
Version: 0.88.3-1
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

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

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



-- System Information:
Debian Release: 7.11
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages shutter depends on:
ii  imagemagick  8:6.7.7.10-5+deb7u4
ii  libfile-basedir-perl 0.03-1
ii  libfile-copy-recursive-perl  0.38-1
ii  libfile-which-perl   1.09-1
ii  libglib-perl 3:1.260-1
ii  libgnome2-canvas-perl1.002-2+b2
ii  libgnome2-gconf-perl 1.044-4
ii  libgnome2-perl   1.042-2+b2
ii  libgnome2-vfs-perl   1.081-3+b1
ii  libgnome2-wnck-perl  0.16-2+b2
ii  libgtk2-imageview-perl   0.05-1+b2
ii  libgtk2-perl 2:1.244-1+deb7u1
ii  libgtk2-unique-perl  0.05-1+b2
ii  libjson-perl 2.53-1
ii  libjson-xs-perl  2.320-1+b1
ii  liblocale-gettext-perl   1.05-7+b1
ii  libnet-dbus-perl 1.0.0-1+b1
ii  libnet-dropbox-api-perl  1.8-1
ii  libpath-class-perl   0.26-1
ii  libproc-processtable-perl0.45-6
ii  libproc-simple-perl  1.30-1
ii  librsvg2-common  2.36.1-2+deb7u1
ii  libsort-naturally-perl   1.02-1
ii  libwww-mechanize-perl1.71-1
ii  libwww-perl  6.04-1
ii  libx11-protocol-perl 0.56-4
ii  libxml-simple-perl   2.20-1
ii  perlmagick   8:6.7.7.10-5+deb7u4
ii  procps   1:3.3.3-3
ii  xdg-utils1.1.0~rc1+git20111210-6+deb7u3

Versions of packages shutter recommends:
ii  libgoo-canvas-perl  0.06-1+b2

Versions of packages shutter suggests:
pn  gnome-web-photo 
pn  libimage-exiftool-perl  
pn  libnet-dbus-glib-perl   
pn  nautilus-sendto 

-- no debconf information

Bug#913682: quilt: fails to document QUILT_PC environment variable

[Alan W. Irwin]

Package: quilt
Version: 0.65-2
Severity: minor

Dear Maintainer,

Sometimes quilt users must be able to switch between completely
different patch series.  For example, I ran into this issue when
dealing with applying an extra patch in debian/patches (to configure
both RCU_EXPERT and RCU_NOCB_CPU to default to "yes" to deal with
random Ryzen lockups) which turned out to conflict with a patch in
debian/patches-rt that "also" patched RCU_EXPERT default from "no" to
something else where apt-src applies the former set of patches when installing
and applies the latter set of patches on top of the former set when
building just (I think) the rt set of binary packages for the linux kernel.

I guess it could be claimed that the Debian Linux kernel should be
reorganized to use just one patch series, but currently that is not
the case (probably because that reorganization would be difficult),
and that is likely true of some other packages as well.  In sum,
multiple patch series are an unfortunate fact of life.

The only way to manage multiple patch series with quilt that I am
aware of (and it took a difficult google search to find this
information) is to specify both the QUILT_PATCHES and QUILT_PC
environment variables where the former points to the directory where
the series file is located (either debian/patches or
debian/patches-rt) and the latter is necessary to change between the
normal .pc location to somewhere else (I used .pc-rt for the above
specific case), I guess it could be argued that it is a rare case when
you attempt to manage with quilt two distinct patch series so QUILT_PC
is normally unnecessary.  But when you need it (as in the above case)
it is a lifesaver so I think it is worth documenting this environment
variable in the man page in the same section where QUILT_PATCHES and
several other environment variables are already documented.

You may also want to change the documentation of QUILT_SERIES there
that claims the search order for series can be prempted by an absolute
pathname for the series file, but that didn't work, and QUILT_PC did
the trick instead with QUILT_SERIES=series (which is the same as the
default value).

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

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

Versions of packages quilt depends on:
ii  bsdmainutils  11.1.2+b1
ii  bzip2 1.0.6-9
ii  diffstat  1.61-1+b1
ii  gettext   0.19.8.1-8
ii  patch 2.7.6-3
ii  perl  5.28.0-3

Versions of packages quilt recommends:
ii  less  487-0.1+b1

Versions of packages quilt suggests:
ii  graphviz2.40.1-5+b1
ii  postfix [mail-transport-agent]  3.3.0-1+b1
ii  procmail3.22-26

-- no debconf information

Bug#911496: linux-image-4.18.0-2-amd64: e1000e module locks up the system for Intel 82574L ethernet controller

[Alan W. Irwin]

Package: src:linux
Version: 4.18.10-2
Severity: normal

Dear Maintainer,

The uptimes I can achieve with kernel 4.18.x and my particular hardware box 
(Ryzen 7 1700, with 8 cores and 64GB with Intel 82574L ethernet controller and 
AMDGPU RX 550 expansion cards attached) range from several hours to a maximum 
of two weeks before a lockup occurs.  Recently I have noticed that the e1000e 
module has been mentioned
prominently in connection with NMI messages in the log files.  For example, 
syslog reports the following
for the latest kernel lockup:

Oct 20 08:59:34 merlin kernel: [240718.639309] INFO: rcu_sched detected stalls 
on CPUs/tasks:
Oct 20 08:59:34 merlin kernel: [240718.639317]  2-...!: (30 GPs behind) 
idle=bd8/0/0 softirq=4122069/4122069 fqs=0 
Oct 20 08:59:34 merlin kernel: [240718.639320]  3-...!: (0 ticks this GP) 
idle=f40/0/0 softirq=2443640/2443640 fqs=0 
Oct 20 08:59:34 merlin kernel: [240718.639323]  4-...!: (1 GPs behind) 
idle=308/0/0 softirq=4256346/4256347 fqs=0 
Oct 20 08:59:34 merlin kernel: [240718.639326]  5-...!: (8 GPs behind) 
idle=5b0/0/0 softirq=3016342/3016342 fqs=0 
Oct 20 08:59:34 merlin kernel: [240718.639330]  10-...!: (10 GPs behind) 
idle=d34/0/0 softirq=7181283/7181283 fqs=0 
Oct 20 08:59:34 merlin kernel: [240718.639333]  11-...!: (1 GPs behind) 
idle=310/0/0 softirq=3705498/3705499 fqs=0 
Oct 20 08:59:34 merlin kernel: [240718.639336]  12-...!: (0 ticks this GP) 
idle=7b8/0/0 softirq=4696972/4696972 fqs=0 
Oct 20 08:59:34 merlin kernel: [240718.639339]  13-...!: (2 GPs behind) 
idle=5e8/0/0 softirq=1804907/1804907 fqs=0 
Oct 20 08:59:34 merlin kernel: [240718.639340]  (detected by 0, t=5282 jiffies, 
g=6136854, c=6136853, q=145)
Oct 20 08:59:34 merlin kernel: [240718.639345] Sending NMI from CPU 0 to CPUs 2:
Oct 20 08:59:34 merlin kernel: [240718.639381] NMI backtrace for cpu 2 skipped: 
idling at acpi_idle_do_entry+0x15/0x30
Oct 20 08:59:34 merlin kernel: [240718.640343] Sending NMI from CPU 0 to CPUs 3:
Oct 20 08:59:34 merlin kernel: [240718.640375] NMI backtrace for cpu 3 skipped: 
idling at acpi_idle_do_entry+0x15/0x30
Oct 20 08:59:34 merlin kernel: [240718.641338] Sending NMI from CPU 0 to CPUs 4:
Oct 20 08:59:34 merlin kernel: [240728.566901] Sending NMI from CPU 0 to CPUs 5:
Oct 20 08:59:34 merlin kernel: [240738.492464] Sending NMI from CPU 0 to CPUs 
10:
Oct 20 08:59:34 merlin kernel: [240748.418028] Sending NMI from CPU 0 to CPUs 
11:
Oct 20 08:59:34 merlin kernel: [240758.343593] Sending NMI from CPU 0 to CPUs 
12:
Oct 20 08:59:34 merlin kernel: [240762.907740] [ cut here 
]
Oct 20 08:59:34 merlin kernel: [240762.907748] NETDEV WATCHDOG: enp9s0 
(e1000e): transmit queue 0 timed out

I plan to follow up with a tarball attachment containing all the relevant log 
files so these kernel
lockup messages can be seen in context.

Please let me know if there is any additional information I can provide or any 
experiments (kernel parameters, network controller configuration) you would 
like me to try.

But for now I am trying the experiment of drastically reducing use of
this particular network card (by shutting down an external X-terminal
computer that is connected to the present computer with a crossover
cable and this Intel 82574L ethernet controller) in the hopes that
shutdown (and subsequent reboot of the current system) will make the
current system more reliable.  Of course, the user that is currently
using that second computer as an X terminal will now need to share my
computer so this configuration is far from ideal.  But if I achieve
uptimes of say a couple of months with this configuration, then that
implies all the recent kernel 4.18.x (and kernel 4.17.x before that)
instability is likely entirely due to the Intel 82574L ethernet
controller and/or the e1000e kernel module that drives that hardware.

-- Package-specific info:
** Version:
Linux version 4.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.10-2 (2018-10-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.18.0-2-amd64 
root=UUID=1e45a1ee-a5d6-4327-9a7b-2663ffc0b157 ro rootwait quiet idle=nomwait

** Not tainted

** Kernel log:
[3.102710] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[3.102711] [TTM] Initializing pool allocator
[3.102720] [TTM] Initializing DMA pool allocator
[3.102788] [drm] amdgpu: 4096M of VRAM memory ready
[3.102791] [drm] amdgpu: 4096M of GTT memory ready.
[3.102808] [drm] GART: num cpu pages 65536, num gpu pages 65536
[3.102922] [drm] PCIE GART of 256M enabled (table at 0x00F40030).
[3.103359] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_pfp_2.bin
[3.103549] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_me_2.bin
[3.103782] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_ce_2.bin
[3.103785] [drm] Chained IB support enabled!
[3.103904] amdgpu 

Bug#910482: libmagickcore-6.q16-6-extra: SVG error messages and/or rendering errors if inkscape not installed

[Alan W. Irwin]

Package: libmagickcore-6.q16-6-extra
Version: 8:6.9.10.8+dfsg-1
Severity: normal

Dear Maintainer,

With libmagickcore-6.q16-6-extra installed, "display" (symlinked to
display-im6.q16) renders validated SVG files incorrectly or not at all
(exited with

"display-im6.q16: non-conforming drawing primitive definition `path' @ 
error/draw.c/DrawImage/4216."

) if inkscape is not installed.  Therefore, since inkscape is so
essential for processing SVG files I suggest that inkscape be promoted from 
"Suggests:"
to "Recommends:" for libmagickcore-6.q16-6-extra or else the package 
description should
mention that inkscape is essential to SVG success.

Alan

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
compare:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
convert:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
composite:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
conjure:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
display:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
identify:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
import:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
mogrify:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
montage:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
stream:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org

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

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

Versions of packages libmagickcore-6.q16-6-extra depends on:
ii  libc6  2.27-6
ii  libcairo2  1.15.12-1
ii  libdjvulibre21 3.5.27.1-9
ii  libglib2.0-0   2.58.1-2
ii  libmagickcore-6.q16-6  8:6.9.10.8+dfsg-1
ii  libmagickwand-6.q16-6  8:6.9.10.8+dfsg-1
ii  libopenexr23   2.2.1-4
ii  libpango-1.0-0 1.42.4-3
ii  libpangocairo-1.0-01.42.4-3
ii  libwmf0.2-70.2.8.4-12
ii  libxml22.9.4+dfsg1-7+b1

Versions of packages libmagickcore-6.q16-6-extra recommends:
ii  libjxr-tools  1.1-6+b1

Versions of packages libmagickcore-6.q16-6-extra suggests:
ii  inkscape  0.92.3-3

-- no debconf information

Bug#807418: This bug applies to the Debian Buster firefox-esr package as well

[Alan W. Irwin]

I independently discovered this bug for firefox-esr (Version:
52.9.0esr-1 from Debian Buster) when comparing rsync results with and
without the --checksum option.

irwin@merlin> ls -l /usr/share/firefox-esr/browser/defaults/preferences
total 100
-rw-r--r-- 1 root root 16101 Dec 31  2009 devtools.js
-rw-r--r-- 1 root root  1738 Dec 31  2009 firefox-branding.js
-rw-r--r-- 1 root root 72676 Dec 31  2009 firefox.js
-rw-r--r-- 1 root root   238 Jun 26 15:29 vendor.js
-rw-r--r-- 1 root root  2053 Dec 31  2009 webide-prefs.js

And as previously explained the combination of those bad Dec 31 2009 dates on 
those files plus
updates on three of them that only involve version numbers (so the length of 
the file is unchanged)
is probablematic for rsync without the --checksum option.  And most people 
avoid the --checksum
option because it takes so much longer than running rsync without that option.

Anyhow, I hope the availability of the "touch" fix that has been
suggested before inspires someone from the team of maintainers for
this package to fix this bug since giving the highest priority to all
the easy bugs like this one should considerably simplify the list of
outstanding bugs for firefox-esr.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#909773: alsa-utils: alsamixer Master configured improperly for line-in of Realtek ALC887-VD

[Alan W. Irwin]

Package: alsa-utils
Version: 1.1.6-1
Severity: normal

Dear Maintainer,

To give some background I have a TV card whose line-out is connected
to sound card line-in.  As far as I can tell for Debian Testing =
Buster line-in for this sound chip (and possibly all others although I
can find no documentation of this) only gets connected to *sound card*
line-out and therefore to my computer speakers if alsamixer the
Loopback item for this sound chip is enabled.  (This is the only way I
have been able to hear the audio channel of the TV card.) In my prior
experience with Debian Oldstable = Jessie, I don't recall
there was an alsamixer Loopback item to be enabled, but the net effect
for that version of Debian was sound card line-in
was automatically connected to sound card line-out.  And in that
Oldstable case the volume of TV audio results could be controlled from
both Line and Master.

The issue for the present Debian Buster case is the volume of the TV
results can only be controlled by Line which means generic volume
controls (e.g., from the pulseaudio "sound card" that alsamixer sees)
whose Master item interacts with the Master item of the Realtek
ALC887-VD sound card have no effect on the volume of the TV results.
Which in turn means that tvtime, for example, cannot control the
volume of the TV any more.  I don't have a clear picture about how the
Master item controls the overall volume associated with most alsamixer
items for the Realtek ALC887-VD, but the fix for the current bug
should be that Master control is also extended to the alsamixer Line
item for that sound card.

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

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

Versions of packages alsa-utils depends on:
ii  kmod  25-1
ii  libasound21.1.6-1
ii  libc6 2.27-6
ii  libfftw3-single3  3.3.8-2
ii  libncursesw6  6.1+20180714-1
ii  libsamplerate00.1.9-2
ii  libtinfo6 6.1+20180714-1
ii  lsb-base  9.20170808
ii  whiptail  0.52.20-7

alsa-utils recommends no packages.

alsa-utils suggests no packages.

-- no debconf information

Bug#902238: lua5.3: arithemetic operations fail to give correct results if too many arrays are initialized

[Alan W. Irwin]

Further investigation shows that

/home/software/lua/install-5.3.3/bin/lua test.lua

gives the bad result while

/home/software/lua/install-5.3.5/bin/lua test.lua

gives the correct result where these are locally built
versions 5.3.3 and 5.3.5 of lua.  I have also confirmed that the
locally built 5.3.5 version also solves the run-time issue with
PLplot that started me on this bug hunt.

So clearly this is an upstream bug for 5.3.3 that has been fixed by
upstream 5.3.5, and the Debian solution for this bug should be simply
to package 5.3.5.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#902238: lua5.3: arithemetic operations fail to give correct results if too many arrays are initialized

[Alan W. Irwin]

Thanks, Orion, for that comparison with the Fedora Lua 5.3.5 result.

Yes, that is the correct result that I also get for Debian Buster Lua-5.2.4, 
but for Debian Buster
Lua-5.3.3 I get the following:

irwin@merlin> /usr/bin/lua5.3 test.lua
nxcells[page] = 12, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00

@Maintainer:
Please update the Debian package from 5.3.3 to 5.3.5 to see whether
that fixes the issue demonstrated by the script.

Alan


__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#907777: crashing: crashed browser

[Alan Christopher Gormley]

Package: crashing
Version: iceweasel
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

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

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



-- System Information:
Debian Release: 7.11
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: i386 (i686)

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

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

I avoided trying early kernel-4.17.x versions, but yesterday I updated
from kernel-4.16.x to kernel 4.17.17-1, but frankly that change has
not helped this lockup problem at all.  For example, after trying
direct use (with a KDE desktop if that makes any difference) for the
first time with that kernel, the kernel only lasted a half an hour
before I got a lockup which could only be solved by hitting the reset
button!  And roughly 8 hours later after that reset I got another
lockup which also required a reset to regain control.

So it appears the substantial number of AMD graphics fixes in
kernel-4.17.x are not sufficient to stabilize use of this AMD RX 550
graphics card that should no longer be considered cutting-edge hardware
(i.e. it was first offered for sale at least 16 months ago).

Because of these on-going issues with direct use of this card, I am
going back to using the X-terminal method with this kernel which
experience with kernel-4.16.x shows is much more stable since it
avoids using this graphics card completely (except for the direct
display of the Linux console login prompt).

I will try again to use this card directly when kernel-4.18.x is
promoted to Buster.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#907506: kinit: "Add to panel (Widget)" does not work

[Alan W. Irwin]

Package: kinit
Version: 5.47.0-1
Severity: normal

Dear Maintainer,

With the latest version of the KDE desktop available for Debian Buster
it appears to be impossible to launch multiple instances of
applications from the panel.  For example, if I explore klauncher ->
applications -> internet I find two web browsers (Firefox ESR and
konqueror) and if explore klauncher -> applications -> system I find
konsole.  If I right click on any of those applications two of the
options are "Pin to task manager" and "Add to panel (Widget)".  The
first of those works, but only allows you to launch a single instance
of the application at a given time from the task manager which is not
useful to me since I need to launch multiple instances (especially for
konsole but sometimes for the browsers as well as other KDE
applications).

According to web sources "Add to panel (Widget)" should give me what I
want which is a separate panel launcher for each application that I
use a lot such as Firefox ESR, konqueror, and konsole, but this
functionality does not work (i.e., no launchers appear on the panel
for any of these applications).  I routinely configured such
individual launchers on the panel (by a method which I cannot remember
exactly, but I think it was drag and drop from klauncher to panel)
when I was running a KDE desktop for Debian Buster a couple months ago
so I am pretty sure one of the KDE desktop upgrades in the last month
or so clobbered this long-standing and important individual
application launcher capability for the panel.

N.B. It is possible klauncher is fine, and instead the updated panel
is screwing up this capability.  However, I have chosen to report this
bug for kinit because I know klauncher belongs to that package while I
have been unable to discover what application runs the panel so I
cannot figure out which package the panel belongs to.  But I encourage you
to shift this bug report to the package containing the panel if that
is where the fault lies.

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

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

Versions of packages kinit depends on:
ii  kio  5.47.0-1
ii  libc62.27-5
ii  libcap2  1:2.25-1.2
ii  libcap2-bin  1:2.25-1.2
ii  libkf5configcore55.47.0-1
ii  libkf5coreaddons55.47.0-1
ii  libkf5crash5 5.47.0-1
ii  libkf5i18n5  5.47.0-1
ii  libkf5kiocore5   5.47.0-1
ii  libkf5kiowidgets55.47.0-1
ii  libkf5service-bin5.47.0-1
ii  libkf5service5   5.47.0-1
ii  libkf5windowsystem5  5.47.0-1
ii  libqt5core5a 5.11.1+dfsg-6
ii  libqt5dbus5  5.11.1+dfsg-6
ii  libqt5gui5   5.11.1+dfsg-6
ii  libstdc++6   8.2.0-4
ii  libx11-6 2:1.6.6-1
ii  libxcb1  1.13-3

kinit recommends no packages.

kinit suggests no packages.

-- no debconf information

Bug#907504: kinit: "type to search" has quit working

[Alan W. Irwin]

Package: kinit
Version: 5.47.0-1
Severity: normal

Dear Maintainer,

For the KDE launcher (klauncher) that is available on the panel, if
you search for an application by typing its name a search bar comes up
as per usual, but that search bar no longer finds any applications no
matter what you type for the search.  This functionality (which I use
a lot whenever I run a KDE desktop) worked when I was running a KDE
desktop for Debian Buster a couple months ago so I am pretty sure one
of the kinit upgrades in the last month or so clobbered this important
search functionality for klauncher.

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

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

Versions of packages kinit depends on:
ii  kio  5.47.0-1
ii  libc62.27-5
ii  libcap2  1:2.25-1.2
ii  libcap2-bin  1:2.25-1.2
ii  libkf5configcore55.47.0-1
ii  libkf5coreaddons55.47.0-1
ii  libkf5crash5 5.47.0-1
ii  libkf5i18n5  5.47.0-1
ii  libkf5kiocore5   5.47.0-1
ii  libkf5kiowidgets55.47.0-1
ii  libkf5service-bin5.47.0-1
ii  libkf5service5   5.47.0-1
ii  libkf5windowsystem5  5.47.0-1
ii  libqt5core5a 5.11.1+dfsg-6
ii  libqt5dbus5  5.11.1+dfsg-6
ii  libqt5gui5   5.11.1+dfsg-6
ii  libstdc++6   8.2.0-4
ii  libx11-6 2:1.6.6-1
ii  libxcb1  1.13-3

kinit recommends no packages.

kinit suggests no packages.

-- no debconf information

Bug#906538: Possibly still not fixed

[Alan W. Irwin]

For those (like me, it is a long story) who want to delay doing a full
system update of Buster, I confirm that

apt-get install --reinstall libappstream4

fixed this severe problem in Debian Buster for me.

I am surprised this issue migrated from Debian unstable to Buster at
all.  According to <https://tracker.debian.org/pkg/appstream>,
0.12.2-1 (the version with this severe bug that affects all apt-get
updates) was accepted into unstable on 2018-08-04 and only migrated to
Buster on 2018-08-15.  So there were 11 days when any user that ran
"apt-get update" for unstable would have seen the effects of this
severe bug.  But apparently no report of the issue occurred which
means that the whole point of Debian unstable (to winnow out the
showstopper bugs before they hit Debian testing = Buster) broke down
in this particular case.

That said, kudos to Matthias Klumpp for quickly fixing this severe bug once
a Debian Buster user had reported it.

Alan
______
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#855918: connection refused after reboot

[Alan Lay]

Hi. I was able to solve this by renaming /etc/init.d/smbd to 
/etc/init.d/smbd.orig. I still don't understand the root cause, but I believe 
that something other than the unit file smbd.service was starting smbd early 
and not waiting for the interface to be configured. Maybe 
systemd-sysv-generator is creating a service unit inappropriately, even though 
a service unit of the same name already exits in /lib/systemd/system.

Alan

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

On 2018-06-02 10:07-0700 Alan W. Irwin wrote:


The propagation of kernel 4.16.12 from Sid to Buster has greatly
improved this situation, i.e., no lock ups so far (uptime approaching
3 days since I switched to 4.16.12 from 4.16.5) and may have
completely solved it. [...]


Well, further experience showed lockups occurred roughly as often for
4.16.12 as for 4.16.5.  So currently I am only able to use this
computer in a reliable way using an X-terminal (an alternate computer
with a different X server that runs "X -query "
to control and display remote desktop results that are running on this
computer).

Therefore I plan to wait for kernel 4.17.x (which apparently has many
graphics fixes for modern AMD cards such as the RX 550) to propagate
to Buster before I try this computer again with a local X server,
i.e., direct use rather than X-terminal use.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#902238: lua5.3: arithmetic operations fail to give correct results if too many arrays are initialized

[Alan W. Irwin]

Attached script demonstrates the bug.

__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__--[[
Displays Greek letters and mathematically interesting Unicode ranges

Copyright (C) 2009  Werner Smekal

This file is part of PLplot.

PLplot is free software you can redistribute it and/or modify
it under the terms of the GNU Library General Public License as published
by the Free Software Foundation either version 2 of the License, or
(at your option) any later version.

PLplot is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU Library General Public License for more details.

You should have received a copy of the GNU Library General Public License
along with PLplot if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
--]]

-- initialise Lua bindings for PLplot examples.
--dofile("plplot_examples.lua")


-- main
--
-- Displays Greek letters and mathematically interesting Unicode ranges


Greek = {
  "#gA","#gB","#gG","#gD","#gE","#gZ","#gY","#gH","#gI","#gK","#gL","#gM",
  "#gN","#gC","#gO","#gP","#gR","#gS","#gT","#gU","#gF","#gX","#gQ","#gW",
  "#ga","#gb","#gg","#gd","#ge","#gz","#gy","#gh","#gi","#gk","#gl","#gm",
  "#gn","#gc","#go","#gp","#gr","#gs","#gt","#gu","#gf","#gx","#gq","#gw"
}

Type1 = {
  32, 33, 35, 37, 38,
  40, 41, 43, 44, 46,
  47, 48, 49, 50, 51,
  52, 53, 54, 55, 56,
  57, 58, 59, 60, 61,
  62, 63, 91, 93, 95,
  123, 124, 125, 169, 172,
  174, 176, 177, 215, 247,
  402, 913, 914, 915, 916,
  917, 918, 919, 920, 921,
  922, 923, 924, 925, 926,
  927, 928, 929, 931, 932,
  933, 934, 935, 936, 937,
  945, 946, 947, 948, 949,
  950, 951, 952, 953, 954,
  955, 956, 957, 958, 959,
  960, 961, 962, 963, 964,
  965, 966, 967, 968, 969,
  977, 978, 981, 982, 8226,
  8230, 8242, 8243, 8254, 8260,
  8465, 8472, 8476, 8482, 8486,
  8501, 8592, 8593, 8594, 8595,
  8596, 8629, 8656, 8657, 8658,
  8659, 8660, 8704, 8706, 8707,
  8709, 8710, 8711, 8712, 8713,
  8715, 8719, 8721, 8722, 8725,
  8727, 8730, 8733, 8734, 8736,
  8743, 8744, 8745, 8746, 8747,
  8756, 8764, 8773, 8776, 8800,
  8801, 8804, 8805, 8834, 8835,
  8836, 8838, 8839, 8853, 8855,
  8869, 8901, 8992, 8993, 9001,
  9002, 9674, 9824, 9827, 9829,
  9830
}

title = {
  "#<0x10>PLplot Example 23 - Greek Letters",
  "#<0x10>PLplot Example 23 - Type 1 Symbol Font Glyphs by Unicode (a)",
  "#<0x10>PLplot Example 23 - Type 1 Symbol Font Glyphs by Unicode (b)",
  "#<0x10>PLplot Example 23 - Type 1 Symbol Font Glyphs by Unicode (c)",
  "#<0x10>PLplot Example 23 - Number Forms Unicode Block",
  "#<0x10>PLplot Example 23 - Arrows Unicode Block (a)",
  "#<0x10>PLplot Example 23 - Arrows Unicode Block (b)",
  "#<0x10>PLplot Example 23 - Mathematical Operators Unicode Block (a)",
  "#<0x10>PLplot Example 23 - Mathematical Operators Unicode Block (b)",
  "#<0x10>PLplot Example 23 - Mathematical Operators Unicode Block (c)",
  "#<0x10>PLplot Example 23 - Mathematical Operators Unicode Block (d)"
}

lo = {
  0,
  0,
  64,
  128,
  8531,
  8592,
  8656,
  8704,
  8768,
  8832,
  8896
}

hi = {
  48,
  64,
  128,
  166,
  8580,
  8656,
  8704,
  8768,
  8832,
  8896,
  8960
}

nxcells = {
  12,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8
}

nycells = {
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8
}

family = {
  "sans-serif",
  "serif",
  "monospace",
  "script",
  "symbol"
}

xstyle = {
  "upright",
  "italic",
  "oblique"
}

for page=1, 8 do
  deltax = 1.0/nxcells[page]
  deltay = 1.0/nycells[page]
  print(string.format("nxcells[page] = %d, deltax = %e", nxcells[page], deltax))
  print(string.format("nycells[page] = %d, deltay = %e", nycells[page], deltay))
end

Bug#902238: lua5.3: arithemetic operations fail to give correct results if too many arrays are initialized

[Alan W. Irwin]

Package: lua5.3
Version: 5.3.3-1
Severity: important

Based on a more complex script that was generating incorrect numerical
results, I have created a fairly simple example lua script (which I will 
subsequently
attach to this bug report) which demonstrates the bug.

In this script I initialize 9 different arrays of
various sizes, and then calculate the numerical inverses of elements
of two of those arrays.  The inverses are not calculated properly (the
result just prints out as 1.0) if 9 arrays are initialized, but if I
remove any one of the array initializations that are not relevant to
the inverse calculation, the correct inverse result is printed.  For
the (incorrect) nine-array case, the printout shows the array value
that is inverted is correct so it is lua's ability to divide that gets
clobbered by the intialization of 9 arrays in this example,
and not the array value itself that is being inverted.

This bug makes lua5.3 largely unusable for any complex task that involves
arrays so I have set the Severity level to important.

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

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

Versions of packages lua5.3 depends on:
ii  libc6 2.27-3
ii  libreadline7  7.0-5

lua5.3 recommends no packages.

lua5.3 suggests no packages.

-- no debconf information

Bug#902148: xfce4: interferes with XKB interpretation of the PageUp key

[Alan W. Irwin]

placed at the end by

bash --login startkde

The xkbcomp boilerplate that I use in both cases was set up a long time
ago so that xjed and jed work properly under xterm.  The only two
files in $HOME/.xkb have the following contents.

cat .xkb/symbols/xmodmap_replace
partial alphanumeric_keys
  xkb_symbols "redefine_keypad" {
replace key  { [ KP_F1 ] };
replace key  { [ KP_F2 ] };
replace key  { [ KP_F3 ] };
replace key  { [ KP_F4 ] };
replace key  { [ KP_7 ] };
replace key  { [ KP_8 ] };
replace key  { [ KP_9 ] };
replace key  { [ KP_Separator ] };
replace key  { [ KP_4 ] };
replace key  { [ KP_5 ] };
replace key  { [ KP_6 ] };
replace key  { [ KP_1 ] };
replace key  { [ KP_2 ] };
replace key  { [ KP_3 ] };
replace key  { [ KP_Enter ] };
replace key  { [ KP_0 ] };
replace key  { [ KP_Decimal ] };
  };

partial modifier_keys
  xkb_symbols "no_numlock_modifier" {
replace key  { [ VoidSymbol ] };
  };


cat .xkb/keymap/xmodmap_replace
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat{ include "complete" };
xkb_symbols   { include 
"pc+us+inet(evdev)+terminate(ctrl_alt_bksp)+xmodmap_replace(no_numlock_modifier)+xmodmap_replace(redefine_keypad)"
 };
xkb_geometry  { include "pc(pc105)" };
};

So that first file explains why the keypad "/" key is identified as
KP_F2 by xev for both the KDE and XFCE desktops.  But there is no
mention of the PageUp key in either of these two files so I doubt my
above personal XKB configuration is the reason why the PageUp key is
incorrectly interpreted as identical to the keypad "/" key for the
XFCE desktop.

I used

dpkg --list |grep -i xfce |sed -e 's?  *? ?g' |cut --delimiter=" " --fields=2 
|sort

to determine which XFCE-related packages I had installed on this fast
box.  Those results are the following:

gtk2-engines-xfce
libexo-1-0:amd64
libexo-2-0:amd64
libgarcon-1-0
libxfce4panel-2.0-4
libxfce4ui-1-0:amd64
libxfce4ui-2-0:amd64
libxfce4ui-common
libxfce4ui-utils
libxfce4util7:amd64
libxfce4util-bin
libxfce4util-common
libxfconf-0-2
mousepad
orage
ristretto
thunar
xfburn
xfce4
xfce4-appfinder
xfce4-battery-plugin
xfce4-clipman
xfce4-clipman-plugin
xfce4-cpufreq-plugin
xfce4-cpugraph-plugin
xfce4-datetime-plugin
xfce4-dict
xfce4-diskperf-plugin
xfce4-fsguard-plugin
xfce4-genmon-plugin
xfce4-mailwatch-plugin
xfce4-mount-plugin
xfce4-netload-plugin
xfce4-notes
xfce4-notes-plugin
xfce4-notifyd
xfce4-panel
xfce4-places-plugin
xfce4-power-manager
xfce4-power-manager-data
xfce4-power-manager-plugins
xfce4-pulseaudio-plugin:amd64
xfce4-screenshooter
xfce4-sensors-plugin
xfce4-session
xfce4-settings
xfce4-smartbookmark-plugin
xfce4-systemload-plugin
xfce4-taskmanager
xfce4-terminal
xfce4-timer-plugin
xfce4-verve-plugin
xfce4-wavelan-plugin
xfce4-weather-plugin
xfce4-whiskermenu-plugin
xfconf
xfdesktop4
xfdesktop4-data
xfwm4

Presumably it is one of those packages that is interfering with the XKB 
interpretation
of the PageUp key, but I don't know which one so I have reported this XFCE bug 
against
the xfce4 package.  Let me know if there is any further test or modified version
of one of the above XFCE-related packages that you would like me to try.

Alan

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

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

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce3.2.0-3
ii  libxfce4ui-utils 4.12.1-3
ii  orage4.12.1-4
ii  thunar   1.6.15-1
ii  xfce4-appfinder  4.12.0-2
ii  xfce4-panel  4.12.2-1
ii  xfce4-pulseaudio-plugin  0.4.1-1
ii  xfce4-session4.12.1-6
ii  xfce4-settings   4.12.3-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.4-1
ii  xfwm44.12.4-1

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

Versions of packages xfce4 suggests:
pn  gtk3-engines-xfce
pn  xfce4-goodies
ii  xfce4-power-manager  1.6.1-1

-- no debconf information

Bug#902050: kde-plasma-desktop: has severe keyboard latency when displaying remote KDE desktop

[Alan W. Irwin]

Package: kde-plasma-desktop
Version: 5:102
Severity: normal

Dear Maintainer,

Because of <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900087>
I currently cannot run this fast box (Ryzen 7 1700, 8 cores, 64GB)
very long with direct X display before it locks up.  So until that bug
is fixed (likely when kernel 4.17 propagates to Debian Buster) I run
various desktops (e.g., xfce, KDE) on this fast box with xdm installed
and configured in such a way that I can actively manage and display
those desktop results on a slow box (connected to the fast box via a
1Gb/s LAN implemented with approprate ethernet hardware on both ends
plus a crossover cable) where I execute "X -query " to
start the X server on the slow "X-terminal" box.

I typically run many instances of konsole and konqueror for my desktop
and for my previous (Jessie) version of Debian, the above X-terminal
method worked so well that it was impossible to tell from latency or
speed issues whether you were running the fast box desktop directly on
the fast box or remotely from the X-terminal.  But that has all
changed for Debian Buster of KDE where if you run, say, 5 idle
instances of konsole, the keyboard on the X terminal starts showing
severe latency issues for the active konsole (where it might take a
half second or so to get a response to an individual key stroke).

I hasten to add this is not an issue that is specific to the konsole
example I gave since similar keyboard latency issues occur for
anything having to do with the keyboard such as typing in a URL in the
location bar of konqueror, editing files, etc.  In constrast, there
appears to not be any obvious KDE desktop latency issues associated
with the mouse or display.  I have also tried running many instances
of konqueror and konsole using an XFCE desktop, and this keyboard
latency issue completely disappears for that case.  In sum, the
network neutrality you expect from X works fine for all of keyboard,
mouse, and display for many konqueror and konsole instances running on
an XFCE desktop, and *just* the keyboard part of those good
network-neutral results fails (i.e., shows severe latency issues) if
running the same number of konqueror and konsole instances on the KDE
desktop running on this fast box.

Because of this annoying KDE desktop issue with keyboard latency for
an X-terminal configuration I must necessarily use for a while, I
currently do all my work using the XFCE desktop.  But I would be happy
to try the KDE desktop remotely in an X terminal environment again if
you have some additional test you would like me to run or if there is
some newer KDE desktop version you would like me to try.

Alan

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

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

Versions of packages kde-plasma-desktop depends on:
ii  kde-baseapps  4:17.08.3+5.102
ii  plasma-desktop4:5.12.5-1
ii  plasma-workspace  4:5.12.5-1
ii  udisks2   2.7.6-3
ii  upower0.99.7-2

Versions of packages kde-plasma-desktop recommends:
ii  kwin-x11  4:5.12.5-1
pn  sddm  
ii  xserver-xorg  1:7.7+19

Versions of packages kde-plasma-desktop suggests:
pn  kdeconnect  

-- no debconf information

Bug#901777: security-tracker: When i open Facebook All my other pages Crash at Once. They All Shut down.

[Alan Christopher Gormley]

Package: security-tracker
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

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

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



-- System Information:
Debian Release: 7.11
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

The propagation of kernel 4.16.12 from Sid to Buster has greatly
improved this situation, i.e., no lock ups so far (uptime approaching
3 days since I switched to 4.16.12 from 4.16.5) and may have
completely solved it.  For further details see
<https://bugs.freedesktop.org/show_bug.cgi?id=106671>.

I would like to see what sort of maximum uptime I can now achieve with
this card without lock ups and report that here for the benefit of
other Debian users of AMD RX 550 graphics cards so please leave this
bug open for at least several more months.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#875311: Bug #875311: gedit: CVE-2017-14108: CPU consumption via crafted file

[Alan Coopersmith]

Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=791037

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

So far my experiment to bypass the RX 550 by displaying on another
computer has been a success, i.e., no lock up issues have been
encountered under this mode of operation.  So it is a rather short
(roughly one day) test so far but still consistent with the hypothesis
that the lock ups are likely caused by an issue with
xserver-xorg-video-amdgpu itself or the kernel functions that are used
by that device driver.

Also, assuming I have now found a stable mode of operation for this
new computer that is not subject to lock ups, I would like to test the
RX 550 for latest kernel and X to see if the lock ups (for direct
display) go away.  Can you advise on the best way to build the latest
kernel and X so those choices are easy to use with Debian Buster
without compromising the Debian Buster versions of kernel and X?  (I
am experienced at software builds, but it has been many years since I
built the Linux kernel, and I have no experience building X, yet.)

I have also reported this bug upstream at
<https://bugs.freedesktop.org/show_bug.cgi?id=106671> in case the X
developers have helpful advice about working around the problem or
want me to perform some specific tests.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

 load for 
amdgpu/polaris12_ce_2.bin failed with error -2
[   31.640918] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_ce.bin
[   31.641031] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_rlc.bin
[   31.641046] amdgpu :0a:00.0: firmware: failed to load 
amdgpu/polaris12_mec_2.bin (-2)
[   31.641051] amdgpu :0a:00.0: Direct firmware load for 
amdgpu/polaris12_mec_2.bin failed with error -2
[   31.641415] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_mec.bin
[   31.641428] amdgpu :0a:00.0: firmware: failed to load 
amdgpu/polaris12_mec2_2.bin (-2)
[   31.641432] amdgpu :0a:00.0: Direct firmware load for 
amdgpu/polaris12_mec2_2.bin failed with error -2
[   31.641804] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_mec2.bin
[   31.642905] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_sdma.bin
[   31.643031] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_sdma1.bin
[   31.643541] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_uvd.bin
[   31.643545] [drm] Found UVD firmware Version: 1.79 Family ID: 16
[   31.643559] [drm] UVD ENC is disabled
[   31.644175] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_vce.bin
[   31.644178] [drm] Found VCE firmware Version: 52.4 Binary ID: 3
[   31.644691] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_smc.bin
[   31.646382] input: HD-Audio Generic Front Mic as 
/devices/pci:00/:00:08.1/:0c:00.3/sound/card1/input10
[   31.646659] input: HD-Audio Generic Rear Mic as 
/devices/pci:00/:00:08.1/:0c:00.3/sound/card1/input11
[   31.646913] input: HD-Audio Generic Line as 
/devices/pci:00/:00:08.1/:0c:00.3/sound/card1/input12

Are any of those failures to load firmware a concern or are those
just generic failure messages that should be ignored?

Please let me know any other tests you would like me to run to help figure
out the source of these lock ups.

Alan

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
0a:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Lexa PRO [Radeon RX 550] [1002:699f] (rev c7)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1910 May 17 10:30 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Use defaults for most things, but configure the exceptions to
# defaults that I like.

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
# Use automatic evdev detection of mouse and keyboard
# so no InputDevice commands here.
EndSection

# As recommended by http://pkg-xorg.alioth.debian.org/howto/configure-input.html
# Note there is no keyboard equivalent because that is configured using
# /etc/default/keyboard and following the udevadmin command given in man 
keyboard
# (or reboot the system) to make those options visible to X.

Section "InputClass"
Identifier   "evdev-pointer"
MatchIsPointer "on"
Driver "evdev"
# Disable mouse wheel if it exists (found in evdev man page)
Option "ButtonMapping" "1 2 3 0 0"
EndSection

Section "Monitor"
Identifier   "Monitor0"
DisplaySize   410   260 # mm
VendorName   "ACI"
ModelName"ASUS VH198"
 ### Comment all HorizSync and VertRefresh values to use DDC:
 #HorizSync30.0 - 80.0
 HorizSync30.0 - 67.6
 VertRefresh  55.0 - 75.0
 Option  "DPMS"
EndSection


#Section "Module"
#   Load  "modesetting"
#EndSection

# This section inferred from the Jessie "Card0" identifier and general
# "Device" section syntax, the appropriate "amdgpu" name of the
# driver for the Radeon RX 550 graphics card with Polaris 12 chipset,
# AND the following lspci result on Buster merlin:

# 0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Lexa PRO [Radeon RX 550] (rev c7)

# where the 0a:00 must be converted from hexadecimal to decimal to help 
determine the BusID value
Section "Device"
Identifier  "Card0"
Driver  "amdgpu"
#BusID   "PCI:10:0:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection

/etc

Bug#895866: Bug 895866

[Alan Orth]

Dear Emmanuel, Tomcat 8.5.31 was released a few weeks ago. Have you had time to 
look at this since then? It seems there are quite a few people watching this 
bug now. Thanks.
-- 
Alan Orth
ao...@mjanja.ch
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch

> On May 21, 2018, at 7:59 PM, Mirko Raner <mi...@raner.ws> wrote:
> 
> I'm a little surprised at the nonchalance here. In my mind, this is a pretty 
> serious bug that will cause many people a good amount of headaches, myself 
> included.
> Tomcat 8.5 does not intrinsically require Java 9, so, introducing a 
> dependency by compiling it with Java 9 seems the wrong choice to begin with. 
> And having a package declare a dependency on Java 8 when it really depends on 
> Java 9 is a major bug; the package will install without errors but will not 
> actually work.
> 
> Personally, I would like to see a higher priority on this bug. And I'm sure I 
> will not be the only one who will appreciate this problem being fixed.

Bug#899086: xserver-xorg-video-amdgpu: completely fails to detect AMD RX 550 (which uses the Polaris 12 chipset) unless firmware-amd-graphics package installed

[Alan W. Irwin]

Package: xserver-xorg-video-amdgpu
Version: 18.0.1-1
Severity: normal

Dear Maintainer,

I recently performed a successful text install of Debian Buster using
a snapshot from
<https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso>.
That install was minimal, i.e., there were no extra packages installed
beyond those absolutely required by the text installer.  I then
followed up by using that minimal Debian system to install
xserver-xorg-video-amdgpu (generally recommended for new chipsets like
the Polaris 12) and other X-related packages.  But I specifically
excluded firmware-amd-graphics because that was only a suggestion
(i.e., not a dependency of xserver-xorg-video-amdgpu), and I try to
avoid using firmware blobs as far as possible for all the obvious
practical as well as free software reasons.  However, all subsequent
attempts to configure X for my AMD RX 550 (Polaris 12) card, failed at
or near the detection stage with messages similar to the following:

[180858.109] (II) AMDGPU: Driver for AMD Radeon:
All GPUs supported by the amdgpu kernel driver
[180858.109] (II) [KMS] drm report modesetting isn't supported.
[180858.109] (EE) Screen 0 deleted because of no matching config section.
[180858.109] (II) UnloadModule: "amdgpu"
[180858.109] (EE) Device(s) detected, but none match those in the config file.

That is a ambiguous error message because no details are given here or
elsewhere in the error log.  Also, no issues were reported by
/var/log/messages and /var/log/syslog.  However, dmesg did have an
drm-related error message concerning firmware (sorry, lost the
details) which eventually lead me to reluctantly install what turns
out to be the absolutely essential (at least for the RX 550)
firmware-amd-graphics package.  At first that installation made no
difference until I realized you also had to reboot for the firmware
to take effect.  After that (text) reboot, I issued the

startx

command, X recognized this graphics card, and X came up without an
issue.  I suspect to reproduce the bad behaviour above with this model
of graphics cards (and likely other modern AMD GPU's as well) all you
will have to do is to purge the firmware-amd-graphics package, perform
a text reboot, and then issue "startx".

In sum, the issues are

1. Ambiguous error messages (at least within this log file) for the
situation when firmware-amd-graphics is not installed for at least this RX 550
Polaris 12 chipset.

2. You cannot even get started with X configuration with this hardware
unless the firmware-amd-graphics is installed.  This is, of course,
consistent with the statement "Some [AMD] GPUs may require firmware to
operate the X Window System" at
<https://wiki.debian.org/AtiHowTo#Firmware>, but at least a table of
which AMD chipsets (such as my Polaris 12) where this is an issue
would be extremely useful at that website since it would reduce a lot
of hair-pulling by Debian users like me who try to avoid firmware whenever
that is possible.

Thanks for your packaging efforts that have made it possible for me
to use this card (albeit with firmware) and best wishes,

Alan

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
0a:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Lexa PRO [Radeon RX 550] [1002:699f] (rev c7)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1910 May 17 10:30 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Use defaults for most things, but configure the exceptions to
# defaults that I like.

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
# Use automatic evdev detection of mouse and keyboard
# so no InputDevice commands here.
EndSection

# As recommended by http://pkg-xorg.alioth.debian.org/howto/configure-input.html
# Note there is no keyboard equivalent because that is configured using
# /etc/default/keyboard and following the udevadmin command given in man 
keyboard
# (or reboot the system) to make those options visible to X.

Section "InputClass"
Identifier   "evdev-pointer"
MatchIsPointer "on"
Driver "evdev"
# Disable mouse wheel if it exists (found in evdev man page)
Option "ButtonMapping" "1 2 3 0 0"
EndSection

Section "Monitor"
Identifier   "Monitor0"
DisplaySize   410   260 # mm
VendorName   "ACI"
ModelName"ASUS VH198"
 ### Comment all HorizSync and VertRefresh values to use DDC:
 #HorizSync30.0 - 80.0
 HorizSync30.0 - 67.6
 VertRefresh

Bug#895866: tomcat8: Errors thrown when connecting to default HTTP connector (localhost:8080)

[Alan Orth]

I can definitely wait (our application won’t even run on Java >= 8 yet). I just 
wanted to make sure the bug was being tracked. Thanks!

> On Apr 30, 2018, at 3:15 PM, Emmanuel Bourg <ebo...@apache.org> wrote:
> 
> Le 29/04/2018 à 19:07, Alan Orth a écrit :
>> Ubuntu imported tomcat8/8.5.31 just before the 18.04 release and Tomcat will 
>> not run with OpenJDK 8 there either. Will you be waiting for a new Tomcat 
>> release before re-compiling tomcat8 to work with OpenJDK 8, or can we 
>> schedule something sooner?
> 
> Tomcat 8.5.31 hasn't been released yet, but should be by the end of the
> week if the ongoing vote passes upstream. I'll take this opportunity to
> upload a fixed tomcat8 package. The actual fix is in the ant package and
> will be uploaded before.
> 
> The Java ecosystem in Ubuntu 18.04 isn't going to be very stable until
> the end of the year and the final switch to Java 11. Canonical is
> working hard to make the transition as smooth as possible, but if you
> aren't in a hurry to upgrade I think it's safer to wait a bit.
> 
> Emmanuel Bourg
> 
> -- 
> To unsubscribe, send mail to 895866-unsubscr...@bugs.debian.org.

Bug#895866: tomcat8: Errors thrown when connecting to default HTTP connector (localhost:8080)

[Alan Orth]

Ubuntu imported tomcat8/8.5.31 just before the 18.04 release and Tomcat will 
not run with OpenJDK 8 there either. Will you be waiting for a new Tomcat 
release before re-compiling tomcat8 to work with OpenJDK 8, or can we schedule 
something sooner?

Bug#753567: Message David inbox

[David Alan Soletski]

 [image: Inline image 1]

Bug#768376: libvirt-daemon-system requires systemd

[Alan J. Greenberger]

Package: libvirt-daemon-system
Version: 3.0.0-4+deb9u1
Followup-For: Bug #768376

Dear Maintainer,

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 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 libvirt-daemon-system depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  gettext-base   0.19.8.1-2
ii  init-system-helpers1.48
ii  iptables   1.6.0+snapshot20161117-6
ii  libapparmor1   2.11.0-3
ii  libaudit1  1:2.6.7-2
ii  libblkid1  2.29.2-1
ii  libc6  2.24-11+deb9u1
ii  libcap-ng0 0.7.7-3+b1
ii  libdbus-1-31.10.24-0+deb9u1
ii  libdevmapper1.02.1 2:1.02.137-2
ii  libnl-3-2003.2.27-2
ii  libnl-route-3-200  3.2.27-2
ii  libnuma1   2.0.11-2.1
ii  librados2  10.2.5-7.2
ii  librbd110.2.5-7.2
ii  libselinux12.6-3+b3
ii  libvirt-clients3.0.0-4+deb9u1
ii  libvirt-daemon 3.0.0-4+deb9u1
ii  libvirt0   3.0.0-4+deb9u1
ii  libxml22.9.4+dfsg1-2.2+deb9u1
ii  libyajl2   2.1.0-2+b3
ii  logrotate  3.11.0-0.1
ii  lsb-base   9.20161125
ii  policykit-10.105-18

Versions of packages libvirt-daemon-system recommends:
ii  bridge-utils  1.5-13+deb9u1
ii  dmidecode 3.0-4
ii  dnsmasq-base  2.76-5+deb9u1
ii  ebtables  2.0.10.4-3.5+b1
ii  iproute2  4.9.0-1+deb9u1
ii  parted3.2-17

Versions of packages libvirt-daemon-system suggests:
pn  apparmor
pn  auditd  
ii  nfs-common  1:1.3.4-2.1
pn  pm-utils
pn  radvd   
ii  systemd 232-25+deb9u1
pn  systemtap   
pn  zfsutils

-- Configuration Files:
bunch of Permission denied:

-- debconf-show failed

I did a new install of stretch using the init system openrc.  After that I
discovered (as I see mentioned in the 4 Apr 2017 message) that I could not
install a working virtual kvm machine.

libvirt-daemon-system
 (which provides /etc/init.d/libvirtd which launches /usr/sbin/libvirtd)
says:
 Suggests: systemd
This is incorrect!  It
 Depends: policykit-1 which
  Depends: libpam-systemd which
   Depends: systemd

Please change the dependencies so that a kvm can be run on a system using an
init system other than systemd.

Bug#731656: Please disable securetty by default

[Alan Jenkins]

On Thu, 19 Jan 2017 18:20:17 +0100 Balint Reczey 
<bal...@balintreczey.hu> wrote:

> Control: tags -1 confirmed
>
> Hi Josh,
>
> On Sat, 07 Dec 2013 15:13:28 -0800 Josh Triplett <j...@joshtriplett.org>
> wrote:
> > Package: login
> > Version: 1:4.1.5.1-1
> > Severity: wishlist
> >
> > securetty dates back to the days when people still logged into systems
> > via telnet and rlogin. These days, remote access occurs via SSH, which
> > has its own configuration mechanism to determine whether to allow root
> > logins (including more flexible approaches such as disallowing root
> > logins by password but allowing them by key). And any local TTY should
> > be considered a securetty by definition. Thus, I don't think securetty
> > has any value anymore as part of the default configuration of login. I
> > would suggest removing it by default.
>
> I will look into that in the Buster cycle, this change would be too
> intrusive now.
>
> Cheers,
> Balint

Hi

I recently ran a stretch->unstable upgrade, and noticed some 
modification to securetty (conffile conflict v.s. my deletion of 
/etc/securetty).


Can I ask if we've missed the boat for Buster, or is it still a 
possibility to get securetty removed from the pam config?


I understand making any change to PAM configs can be pretty 
nerve-wracking :).


Thanks
Alan

Bug#885435: cryptsetup: The file named debian/rules may be incorrect for 2:2.0.0~rc1-1

[Alan Fung]

Package: cryptsetup
Version: 2:2.0.0-1
Severity: normal

Dear Maintainer,

I used the debian/rules file to build deb files for installation.

I found that the link "/usr/lib/x86_64-linux-gnu/libcryptsetup.so" was pointed 
to a wrong location (/lib/x86_64-linux-gnu/), whlie it should point to 
/usr/lib/x86_64-linux-gnu/libcryptsetup.so.

The problem comes form the line in debian/rules:

dh_link -plibcryptsetup-dev lib/$(DEB_HOST_MULTIARCH)/$$(basename $$(readlink 
debian/libcryptsetup12/lib/$(DEB_HOST_MULTIARCH)/libcryptsetup.so.4)) 
usr/lib/$(DEB_HOST_MULTIARCH)/libcryptsetup.so

In which, "libcryptsetup.so.4" should be changed to "libcryptsetup.so.12", 
because after cryptsetup 2.0, the library changed from libcryptsetup.so.4 to 
libcryptsetup.so.12.

After updating the debian/rules script by myself, the installation worked 
without any error.


-- Package-specific info:

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

Kernel: Linux 4.9.72-intel (SMP w/40 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 cryptsetup depends on:
ii  cryptsetup-bin 2:2.0.0-1
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  dmsetup2:1.02.90-2.2+deb8u1
ii  libc6  2.19-18+deb8u10

Versions of packages cryptsetup recommends:
ii  busybox 1:1.22.0-9+deb8u1
ii  console-setup   1.123
ii  initramfs-tools [linux-initramfs-tool]  0.120+deb8u3
ii  kbd 1.15.5-2

Versions of packages cryptsetup suggests:
ii  dosfstools  3.0.27-1
pn  keyutils
ii  liblocale-gettext-perl  1.05-8+b1

-- Configuration Files:
/etc/bash_completion.d/cryptdisks 758d5cfcd9df55c82a7bb094728114b5 [Errno 2] No 
such file or directory: u'/etc/bash_completion.d/cryptdisks 
758d5cfcd9df55c82a7bb094728114b5'
/etc/init/cryptdisks-udev.conf ed789690d1770e3f3a2682c11e359bb6 [Errno 2] No 
such file or directory: u'/etc/init/cryptdisks-udev.conf 
ed789690d1770e3f3a2682c11e359bb6'
/etc/init/cryptdisks.conf e5527ceb5c020174a6464b81126bb5f7 [Errno 2] No such 
file or directory: u'/etc/init/cryptdisks.conf e5527ceb5c020174a6464b81126bb5f7'

-- debconf information excluded

Bug#880627: polyml: FTBFS on hppa - error linking poly

[Alan Modra]

Source: polyml
Version: 5.7
Severity: normal

On Thu, Nov 02, 2017 at 08:47:30AM -0400, John David Anglin wrote:
> On 2017-11-02, at 3:59 AM, Alan Modra wrote:
> > Even when this has been worked around by the binutils change, polyml
> > still fails to build.
> > 
> > echo "use \"/home/amodra/src/polyml/modules/IntInfAsInt/ROOT.sml\";" |
> > ../../poly -q -error-exit
> > Segmentation fault
> 
> I'm not seeing this fault.  I just redid a polyml build with virgin source 
> and I didn't see the segmentation fault.
> 
> gcc version 7.2.1 20171025 (Debian 7.2.0-12) 
> 
> dave@mx3210:~/debian/polyml/polyml-5.7$ as --version
> GNU assembler (GNU Binutils) 2.29.51.20171031
> 
> Binutils was trunk with your elf32-hppa.c patch.

Yes, but that patch hasn't been committed yet.  What's more,
binutils-2.28 and binutils-2.29 both fail with a segfault (after
working around the OS/ABI problem).  I suspect older binutils will
show the same thing.

In one of my earlier emails to you Dave, I misdiagnosed the segfault
as being due to binutils commit d336fa6d82.  That wasn't true.

> > Some debugging shows this is due to a NULL function pointer, traceable
> > back to this relocation in polyexport.o
> > 
> > 0134  1301 R_PARISC_DIR32   PolyProcessEnvGeneral + 0
> > 
> > That's also an ABI violation.  Function pointers on hppa32 require
> > plabel relocations.
> 
> No, that's not correct.  Calls using function pointers are done using 
> $$dyncall or equivalent.  It checks
> the plabel bit to determine whether or not the call is direct or via an 
> function descriptor.  Direct calls
> work when a new PIC register value isn't needed.

I'll defer to you on whether it is an ABI violation.  It's been quite
a while since I've done any serious parisc work..  The fact remains
that this part of the ABI isn't currently supported by any released
binutils as far as I know.

-- 
Alan Modra
Australia Development Lab, IBM

Bug#880023: polyml: FTBFS on hppa - error linking poly

[Alan Modra]

On Sat, 28 Oct 2017 10:51:01 -0400 John David Anglin <dave.ang...@bell.net> 
wrote:
> Source: polyml
> Version: 5.7
> Severity: normal
> 
> Dear Maintainer,
> 
> Build fails here:
> 
> Making STRUCT_CONVERSIONALS
> Created functor STRUCT_CONVERSIONALS
> Created structure StructConversionals
> Created structure CInterface
> /bin/bash ./libtool  --tag=CC   --mode=link gcc   -Wall -fno-strict-aliasing 
> -g -O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
>   -Wl,--as-needed -o poly  polyexport.o  libpolymain/libpolymain.la 
> libpolyml/libpolyml.la  -lpthread -lffi -lm -ldl -lstdc++ -lgcc_s -lgcc 
> libtool: link: gcc -Wall -fno-strict-aliasing -g -O2 
> -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
> -Wl,--as-needed -o .libs/poly polyexport.o  libpolymain/.libs/libpolymain.a 
> libpolyml/.libs/libpolyml.so -lpthread -lffi -lm -ldl -lstdc++ -lgcc_s -lgcc
> /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.1 internal error, aborting at 
> ../../bfd/elf32-hppa.c:4054 in elf32_hppa_relocate_section
> 
> /usr/bin/ld: Please report this bug.
> 
> collect2: error: ld returned 1 exit status
> Makefile:588: recipe for target 'poly' failed
> 
> Full build log is here:
> https://buildd.debian.org/status/fetch.php?pkg=polyml=hppa=5.7-2=1507223380=0
> 
> The error was reported to binutils:
> https://sourceware.org/bugzilla/show_bug.cgi?id=22300
> 
> See "bug 1: polyimport, the producer of polyexport.o is using the wrong 
> os/abi for hppa-linux." in comment 4.
> 
> The binutils part of this bug should now be fixed by commit 
> c0e331c794d6bd75d9be9bea6145513074c33f39.

Even when this has been worked around by the binutils change, polyml
still fails to build.

echo "use \"/home/amodra/src/polyml/modules/IntInfAsInt/ROOT.sml\";" |
../../poly -q -error-exit
Segmentation fault

Some debugging shows this is due to a NULL function pointer, traceable
back to this relocation in polyexport.o

0134  1301 R_PARISC_DIR32   PolyProcessEnvGeneral + 0

That's also an ABI violation.  Function pointers on hppa32 require
plabel relocations.

$ cat funcp.c
extern void foo(void);
void (*fp)(void) = foo;
$ hppa-linux-gcc -O -c -save-temps funcp.c
$ cat funcp.s
.LEVEL 1.1
.globl fp
.section.data.rel,"aw",@progbits
.align 4
.type   fp, @object
.size   fp, 4
fp:
.word   P%foo
.ident  "GCC: (GNU) 8.0.0 20171018 (experimental)"
.section.note.GNU-stack,"",@progbits
$ readelf -r funcp.o

Relocation section '.rela.data.rel' at offset 0xfc contains 1 entries:
 Offset InfoTypeSym.Value  Sym. Name + Addend
  0841 R_PARISC_PLABEL32    foo + 0


-- 
Alan Modra
Australia Development Lab, IBM

Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

On 16/10/17 16:44, Michael Biebl wrote:

Am 16.10.2017 um 12:40 schrieb Alan Jenkins:


I suspect this would end up with Debian carrying the patch to the
systemd generator.  But all it needs to do is test for
`/var/lib/update-rc.d/${script}.removed` and then skip ${script}.

Alan

I'm not very enthusiastic of keeping and maintaining (yet another) state
directory/file which could potentially get out-of-sync .

A much simpler idea could be, to remove the -x bit from the SysV init
script on remove (and reapply it on re-install). Afair, the
sysv-generator already ignores such init scripts. So nothing would have
to change on the systemd side.

dh_installinit (shipped by debhelper) would have to be updated to
generate maintainer scripts code to remove and (re)add the executable bit.

Still, we'd have to consider that we have upgraded systems which have
not been rebuilt with the new debhelper so we can't just remove the
current logic which masks uninstalled-but-not-purged init scripts.

Maybe in two or three releases we could revisit that.

Removing the -x bit of removed-but-not-purged init scripts would have
the nice side effect, that those are also not executed under
sysvinit/startpar.

Are you interested in working on a patch for debhelper?


Sorry.  I thought I should report my annoyance once I'd found the root 
cause for it.  But I don't think I can commit to writing patch(es) now.


Maybe you have the right idea about clobbering the executable bit. I 
didn't like it because the reason for this annoyance was just such a 
clobbering (v.s. systemctl mask).


It was already frustrating to prevent a Debian network service starting 
before you'd configured it.[1]  `systemctl mask` provides a way to do 
it.  For sysvinit, presumably assigning -x with `dpkg-statoverride` 
would be an equivalent.  Perhaps not a well-documented one.  Such 
procedures could be silently defeated if the install script applies +x.


[1] 
https://unix.stackexchange.com/questions/321621/configuring-my-sshd-securely-with-automation/321622


> we can't just remove the current logic which masks 
uninstalled-but-not-purged init scripts


Ouch, I'd forgotten about the transition issue.  Yep, I guess wait for 
long enough and then explain it in a release note.   (Or write an even 
more magic package script to apply the mask to residual conffiles in 
/etc/rc.d).


Alan

Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

On 14/10/17 13:27, Michael Biebl wrote:

On Fri, 4 Aug 2017 22:12:08 +0100 Alan Jenkins
<alan.christopher.jenk...@gmail.com> wrote:
Can you please explain how #714903 can be fixed differently so masking
is not needed?


> There were two reasons `mask` was used here.
>
> 1. Removing a package naturally deletes most of its files, including 
deleting the systemd service unit. However the system V init script is 
preserved, because it might include user changes. This can work OK under 
system V init, but systemd also picks up the initscript, and will show 
it as a started service in messages, logs, `systemctl list-units` etc.


I believe the solution (which may or not be politically practical) is:

Implement an equivalent feature to masking for system V init scripts, 
which is dedicated to handle removed packages only.


This only strictly needs to be respected by the systemd generator, which 
converts init scripts to systemd services.


Probably the init scripts want to include the same feature themselves.  
(Around the same point where they decide whether to dispatch to 
`systemctl start` instead).  I think that would also allow removing some 
less regular weirdness from init scripts. Debian would no longer have a 
special requirement that init scripts silently succeed if the daemon 
binary does not exist.  And I think the dnsmasq package (as opposed to 
dnsmasq-core?) has even more special handling, which could go away.


I suspect this would end up with Debian carrying the patch to the 
systemd generator.  But all it needs to do is test for 
`/var/lib/update-rc.d/${script}.removed` and then skip ${script}.


Alan

Bug#876908: Is blcr completely useless?

[Alan Woodland]

On 26 September 2017 at 20:28, Adrian Bunk <b...@debian.org> wrote:
>
> Source: blcr
> Version: 0.8.5-2.1
> Severity: serious
> Tags: buster sid
>
> As far as I can see:
> 1. blcr is dead upstream since 2013.
> 2. blcr requires both userspace and kernel parts.
> 3. The -dkms package is removed in unstable.
> 4. The beta version in experimental has an RC bug against
>the -dkms package that the module does not build
>with the jessie (sic) kernel.
>
> mpich is linked with the userspace library,
> but does that make any sense without the kernel part?

There was some activity in 2014 - 0.8.6 beta4, but the last I heard it
still had some issues with PPC64 that meant it wasn't worth uploading
to experimental and my plan was to hold out. Since there haven't been
any new versions released since then I'm inclined to agree. That'll
need a patch to the MPI build config though to stop linking against
and requiring the blcr userspace libraries as a precursor to actually
removing BLCR from sid.

In theory people could still be running old kernels to keep support
alive and if that's the case then we should try to avoid breaking
things, but certainly I've not actively been using BLCR in my work for
quite some time now.

Alan

Bug#865001: Some analysis

[Dr. David Alan Gilbert]

I've done a little digging; firstly I think it's the same as:

   https://bugs.kde.org/show_bug.cgi?id=368494   (to which I commented
  although it's closed because it went away when the reporter updated
  their X server)
and
   https://bugzilla.redhat.com/show_bug.cgi?id=1477592
and possibly
   https://bugzilla.redhat.com/show_bug.cgi?id=1406752

I added a little debug to libkf5screen
#0  XRandRScreen::toKScreenScreen (this=0x559dd8b68980) at 
./backends/xrandr/xrandrscreen.cpp:68
screenResources = {d = 0x0}
kscreenScreen = {value = 0x559dd8b78a70, d = 0x559dd8b78b90}
#1  0x7fe0e9b18aba in XRandRConfig::toKScreenConfig (this=) 
at ./backends/xrandr/xrandrconfig.cpp:117
config = {value = 0x559dd8b7ea80, d = 0x559dd8b7eb30}
features = {i = 3}
kscreenOutputs = {d = 0x559dd8b74bb0}
#2  0x7fe0e9b14c14 in XRandR::config (this=) at 
./backends/xrandr/xrandr.cpp:205
No locals.
#3  0x559dd6d7fac6 in BackendDBusWrapper::setConfig (this=0x559dd8b69c10, 
configMap=...)
at ./src/backendlauncher/backenddbuswrapper.cpp:87
config = {value = 0x559dd8b778c0, d = 0x559dd8b77be0}
obj = {d = 0x559dd8b7ea80, o = 0x559dd8b7eb30}
#4  0x559dd6d815ef in BackendAdaptor::setConfig (in0=..., this=)
at ./obj-x86_64-linux-gnu/src/backendlauncher/backendadaptor.cpp:51
No locals.

and:
KScreen::ScreenPtr XRandRScreen::toKScreenScreen() const
{
KScreen::ScreenPtr kscreenScreen(new KScreen::Screen);
kscreenScreen->setId(m_id);
kscreenScreen->setMaxSize(m_maxSize);
kscreenScreen->setMinSize(m_minSize);
kscreenScreen->setCurrentSize(m_currentSize);

XCB::ScopedPointer 
screenResources(XRandR::screenResources());
kscreenScreen->setMaxActiveOutputsCount(screenResources->num_crtcs);

return kscreenScreen;
}

the problem is the screenResources.d is NULL
I don't know the sctructure of the KDE code to know where the right place
is to fix this.

Dave

-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Bug#876616: apt: a workaround to archived bug 807049

[Alan Corey]

Package: apt
Version: 1.4.7
Severity: normal
Tags: patch

Dear Maintainer,

I know this has been archived but I found a workaround with help from iam_TJ 
at raspberrypi.  Install apt-transport-tor then change the sources.list files 
to 
use the urls as tor+http instead of http.  I just fixed 2 Jessie machines and 
1 Stretch machine that way.  The thread at raspberrypi: 
https://www.raspberrypi.org/forums/posting.php?mode=reply=28=193531

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "armhf";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.41-v7\+$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.41-v7\+$";
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::Architectures "";
APT::Architectures:: "armhf";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
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 "";

Bug#874527: live-build: Live installer creates duplicate sources: sources.list and sources.list.d/base.list

[Alan Jenkins]

On 07/09/2017, Michael . <keltoi...@gmail.com> wrote:
> Did you use the official Debian Live iso image or did you make your own?
> The reason I ask is if you used the official image it would have been built
> with Live-Wrapper not Live-Build.

Thanks!  I used the official image.

> On 7 September 2017 at 08:06, Alan Jenkins <
> alan.christopher.jenk...@gmail.com> wrote:
>
>> Package: live-build
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> I just installed Debian from the Live image for 9.1.0.
>> I ended up with duplicate sources, which show up when apt-get downloads.
>> I'm not familiar with the live-build chain, hopefully this is a sensible
>> place
>> to report it.

Bug#874527: live-build: Live installer creates duplicate sources: sources.list and sources.list.d/base.list

[Alan Jenkins]

Package: live-build
Severity: normal

Dear Maintainer,

I just installed Debian from the Live image for 9.1.0.
I ended up with duplicate sources, which show up when apt-get downloads.
I'm not familiar with the live-build chain, hopefully this is a sensible place
to report it.

I believe base.list is created by vmdebootstrap.

I very much like having the deb.debian.org line on the running live image.
But maybe it needs to be moved to /etc/apt/sources.list, so debian-installer
will overwrite it and avoid annoying duplicates?  Maybe it's not so simple
though, I dunno.

Thanks
Alan


$ sudo apt-get update
Ign:1 http://ftp.uk.debian.org/debian stretch InRelease
Ign:2 http://deb.debian.org/debian stretch InRelease
...

$ cat /etc/orig.apt/sources.list.d/base.list
deb http://deb.debian.org/debian/ stretch main
#deb-src http://deb.debian.org/debian/ stretch main

$ cat /etc/orig.apt/sources.list
#

# deb cdrom:[Official Debian GNU/Linux Live 9.1.0 gnome 2017-07-23T01:42]/
stretch main

#deb cdrom:[Official Debian GNU/Linux Live 9.1.0 gnome 2017-07-23T01:42]/
stretch main

deb http://ftp.uk.debian.org/debian/ stretch main
deb-src http://ftp.uk.debian.org/debian/ stretch main

deb http://security.debian.org/debian-security stretch/updates main
deb-src http://security.debian.org/debian-security stretch/updates main

# stretch-updates, previously known as 'volatile'
deb http://ftp.uk.debian.org/debian/ stretch-updates main
deb-src http://ftp.uk.debian.org/debian/ stretch-updates main



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

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

Versions of packages live-build depends on:
pn  debootstrap  

Versions of packages live-build recommends:
ii  apt-utils   1.4.7
ii  cpio2.11+dfsg-6
pn  live-boot-doc   
pn  live-config-doc 
pn  live-manual-html | live-manual  
ii  wget1.18-5

live-build suggests no packages.

Bug#874525: vmdebootstrap: Please update Vcs-Git / Vcs-Browser links

[Alan Jenkins]

Package: vmdebootstrap
Version: 1.7-1
Severity: normal

Hi Maintainers.

I noticed the Git link onhttps://packages.qa.debian.org/v/vmdebootstrap.html
points to a tree which doesn't have the current version 1.7-1.


debian/control

-Vcs-Git:https://anonscm.debian.org/git/vmdebootstrap/vmdebootstrap.git
-Vcs-Browser:https://anonscm.debian.org/cgit/vmdebootstrap/vmdebootstrap.git/
+Vcs-Git:http://git.liw.fi/vmdebootstrap
+Vcs-Browser:http://git.liw.fi/vmdebootstrap/


Though if Lars wants to look at Let's Encrypt and switch the URL back to HTTPS,
that would be really good too :-P.

Regards
Alan


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

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

Versions of packages vmdebootstrap depends on:
pn  debootstrap 
pn  kpartx  
pn  libjs-sphinxdoc 
ii  parted  3.2-17
ii  python  2.7.13-2
pn  python-cliapp   
pn  python-distro-info  
ii  python2.7   2.7.13-2
pn  qemu-utils  

Versions of packages vmdebootstrap recommends:
ii  dosfstools4.1-1
pn  extlinux  
ii  grub2-common  2.02~beta3-5
pn  python-guestfs
pn  qemu-system   
pn  qemu-user-static  
pn  squashfs-tools

Versions of packages vmdebootstrap suggests:
pn  cmdtest  
pn  mbr  
pn  pandoc   
pn  u-boot   

Bug#729812: Bug #729812, [libx11-doc] incorrect description of XkbGetNamedIndicator in man pages

[Alan Coopersmith]

Fixed upstream:
https://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=c6dadd4cebd994aafb37a58b3adbaa82507c2d18

-- 
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

On 04/08/17 20:52, Michael Biebl wrote:

On Fri, 09 Jun 2017 17:48:59 +0100 Alan Jenkins

There were two reasons `mask` was used here.

1. #722521.  Removing a package naturally deletes most of its files, including
deleting the systemd service unit.  However the system V init script is
preserved, because it might include user changes.  This can work OK under
system V init, but systemd also picks up the initscript, and will show it
as a started service in messages, logs, `systemctl list-units` etc.

#722521 seems perfectly possible to resolve, without resorting to masking.

How?



You snipped my point 2, which also referred to #722521.  Sadly this was 
a typo. Point _2_ is the easy one to resolve.  Point 1 should have 
referred to #714903; I think it is the more fundamental issue.


Sorry!
Alan

Bug#869735: libjson-c2 static library (libjson-c.a) is created using the wrong object files.

[Alan Amaral]

Package: libjson-c2
Source: libjson-c2
Version: 0.11-4ubuntu2

I'm working on a cross platform project that is using libjson-c2 and I wanted 
to try to statically
link the library to see if I could avoid shipping multiple deb packages for, 
for example, 16.04 and
17.04, where the libraries are different (libjson-c2 vs libjson-c3).  What I 
found was that I couldn't
link with the static library libjson-c.a.  When I tried I got the following 
error:

cc   -pie -fPIE -z relro -z now -o myapp myapp.o -static -ljson-c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/crtbeginT.o: relocation 
R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; 
recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/5/crtbeginT.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:89: recipe for target 'myapp' failed

I downloaded the package sources and found that the .c files are being compiled 
twice, once without
-fPIC, with the resultant .o files in the top level directory, and once with 
-fPIC, with the resultant
.o files deposited in the .libs directory, which is where the .a is created. 
However, the .a is NOT
created with the .libs/*.o files, but the top level .o files, which are NOT 
created with -fPIC.
See the following lines from the build log:

libtool: link: (cd ".libs" && rm -f "libjson-c.so.2" && ln -s 
"libjson-c.so.2.0.0" "libjson-c.so.2")
libtool: link: (cd ".libs" && rm -f "libjson-c.so" && ln -s 
"libjson-c.so.2.0.0" "libjson-c.so")
libtool: link: ar cru .libs/libjson-c.a  arraylist.o debug.o json_c_version.o 
json_object.o json_object_iterator.o json_tokener.o json_util.o linkhash.o 
printbuf.o random_seed.o
libtool: link: ranlib .libs/libjson-c.a

Note that the library is .libs/libjson-c.a but the .o files don't have the 
.libs prefix.  If I cd into
the .libs directory and execute these commands:

ar cru libjson-c.a  arraylist.o debug.o json_c_version.o json_object.o 
json_object_iterator.o json_tokener.o json_util.o linkhash.o printbuf.o 
random_seed.o
ranlib libjson-c.a

and then link with the resultant library everything works.  I haven't been able 
to figure out exactly
what the fix for this problem is.

The following is the information for both the installed package and the source 
package that I've been
working with.

$ dpkg --status libjson-c2
Package: libjson-c2
Status: install ok installed
Priority: extra
Section: libs
Installed-Size: 67
Maintainer: Ubuntu Developers 
>
Architecture: amd64
Multi-Arch: same
Source: json-c
Version: 0.11-4ubuntu2
Depends: libc6 (>= 2.14)
Description: JSON manipulation library - shared library
 This library allows you to easily construct JSON objects in C,
 output them as JSON formatted strings and parse JSON formatted
 strings back into the C representation of JSON objects.
Homepage: https://github.com/json-c/json-c/wiki
Original-Maintainer: fabien boucher 
>



Source package info:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 3.0 (quilt)
Source: json-c
Binary: libjson-c2, libjson-c-dev, libjson-c2-dbg, libjson-c-doc, libjson0-dev, 
libjson0
Architecture: any all
Version: 0.11-4ubuntu2
Maintainer: Ubuntu Developers 
>
Uploaders: Ond�~Yej Surý >
Homepage: https://github.com/json-c/json-c/wiki
Standards-Version: 3.9.3.0
Vcs-Browser: http://anonscm.debian.org/?p=collab-maint/json-c.git;a=summary
Vcs-Git: git://anonscm.debian.org/git/collab-maint/json-c
Build-Depends: debhelper (>= 9), dh-exec, dh-autoreconf
Package-List:
 libjson-c-dev deb libdevel extra arch=any
 libjson-c-doc deb doc extra arch=all
 libjson-c2 deb libs extra arch=any
 libjson-c2-dbg deb debug extra arch=any
 libjson0 deb oldlibs extra arch=any
 libjson0-dev deb oldlibs extra arch=any
Checksums-Sha1:
 5d0377d2cc4a1af324d5aeb5b63032d1d026aacd 557263 json-c_0.11.orig.tar.gz
 c93b8000bc69549bf708de0073f0fcae0648c7af 273884 
json-c_0.11-4ubuntu2.debian.tar.xz
Checksums-Sha256:
 28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c 557263 
json-c_0.11.orig.tar.gz
 96cce11fbf46e57c5b2674922344738c6f2ea1fa0af6e91b3576eb9f1dbd51d0 273884 
json-c_0.11-4ubuntu2.debian.tar.xz
Files:
 aa02367d2f7a830bf1e3376f77881e98 557263 json-c_0.11.orig.tar.gz
 f88770f98c00242150f189695af295a4 273884 json-c_0.11-4ubuntu2.debian.tar.xz
Original-Maintainer: fabien boucher 
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlSz8/4ACgkQDTAwc5ER+zVkygCfdx9sPn9kvEB5p2Iagg4JSAx4
dRgAoICbAWoQ6td7VAn7oN/OAVqyt9xR
=OtuB
-END PGP SIGNATURE-

uname -a
Linux desktop 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux

Bug#867997: jessie->stretch, all apt clients break with /var/lib/dpkg/status realpath error

[Alan Schwartz]

Quoting Niels Thykier (ni...@thykier.net):


FTR; I don't think that "apt-get check" is supposed to work as non-root.


  - If it fails, please attempt to figure out where the permission
fails (e.g. [dir-test])


# ls -ld / /var /var/lib /var/lib/dpkg /var/lib/dpkg/status
drwxr-xr-x 21 root root1024 Jul 10 11:21 /
drwxr-xr-x 13 root root4096 May  7  2013 /var
drwxr-xr-x 74 root root4096 Jul  7 16:01 /var/lib
drwxr-xr-x  8 root root4096 Jul 11 08:48 /var/lib/dpkg
-rw-r--r--  1 root root 1961225 Jul 11 08:48 /var/lib/dpkg/status

As you can see, none of these are writable by _apt; however, these are
the same permissions I see on the other (working)


Indeed, and _apt does not need write access to the status file.

Does it work if you disable the sandbox user, e.g. by using:
 apt-get -o APT::Sandbox::User=root update


No, same error:

# apt-get -o APT::Sandbox::User=root update
Get:1 http://security.debian.org stretch/updates InRelease [62.9 kB]
Get:2 http://ftp.us.debian.org/debian stretch-updates InRelease [88.5 kB]
Ign:3 http://ftp.debian.org/debian stretch InRelease
Hit:4 http://ftp.debian.org/debian stretch Release
Fetched 151 kB in 1s (81.1 kB/s)
Reading package lists... Error!
E: flAbsPath on /var/lib/dpkg/status failed - realpath (22: Invalid argument)
E: Could not open file  - open (2: No such file or directory)
E: Problem opening
E: The package lists or status file could not be parsed or opened.


--
Alan Schwartz
The Michael Reese Endowed Professor of Medical Education
Associate Head, UIC Department of Medical Education
Research Professor, UIC Department of Pediatrics
ala...@uic.edu  |  http://ulan.mede.uic.edu/alansz  |  PGP: 0x062556CF

Bug#867997: jessie->stretch, all apt clients break with /var/lib/dpkg/status realpath error

[Alan Schwartz]

Sorry to hear you had issues with the upgrade.

The problem you describe appears to be related to the release notes item
[5.3.2] (5.3.2.1 actually, but I cannot find the direct link to that).
The exact case with /var/lib/dpkg/status is not mentioned, but it could
be that there are some permissions on your system that forbit "_apt" to
access /var/lib/dpkg/status.

* Could you please try to login in as the _apt user and check that it
  can read /var/lib/dpkg/status?


Due to the /nonexistent home directory and /bin/false login shell,
it does not appear to be possible to log in as _apt:

# su - _apt
No directory, logging in with HOME=/

If I change _apt's HOME to /tmp and login shell to /bin/bash:

# su - _apt
_apt$ apt-get check
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?


  - If it fails, please attempt to figure out where the permission
fails (e.g. [dir-test])


# ls -ld / /var /var/lib /var/lib/dpkg /var/lib/dpkg/status
drwxr-xr-x 21 root root1024 Jul 10 11:21 /
drwxr-xr-x 13 root root4096 May  7  2013 /var
drwxr-xr-x 74 root root4096 Jul  7 16:01 /var/lib
drwxr-xr-x  8 root root4096 Jul 11 08:48 /var/lib/dpkg
-rw-r--r--  1 root root 1961225 Jul 11 08:48 /var/lib/dpkg/status

As you can see, none of these are writable by _apt; however, 
these are the same permissions I see on the other (working)

Debian 9 system. lsattr shows no attributes on any /var/lib/dpkg/status
files.



* If you have any policy framework enabled (SELinux or AppArmor),
  please check if any of these are forbidding the access.


Neither of those are enabled.

--
Alan Schwartz
The Michael Reese Endowed Professor of Medical Education
Associate Head, UIC Department of Medical Education
Research Professor, UIC Department of Pediatrics
ala...@uic.edu  |  http://ulan.mede.uic.edu/alansz  |  PGP: 0x062556CF