Bug#1070664: emacs: ELPA key needs update in Debian 12

[Stefan Monnier]

> Just to confirm that this bug is distracting (especially for new users…):
>
> - if we install GNU Emacs on Debian 12,
> - assuming ~/.emacs and ~/.emacs.d are empty,
> - running emacs and `M-x package-refresh-contents` just raises the error:
>   
> "Failed to download ‘nongnu’ archive."
>
> Failed to verify signature archive-contents.sig:
> No public key for 645357D2883A0966 created at 2024-05-31T23:05:08+0200 
> using EDDSA
> Command output:
> gpg: Signature made ven. 31 mai 2024 23:05:08 CEST
> gpg:using EDDSA key 
> 0327BE68D64D9A1A66859F15645357D2883A0966
> gpg: Can't check signature: No public key

Thanks Erik, indeed the problem is that the GPG keys distributed with
Emacs-28 are expired, so it would be great to release a new stable
version of the `emacs` package, still built from Emacs-28 except using
Emacs-29's `etc/package-keyring.gpg`.


Stefan

Bug#1063932: firefox-esr: "Gah. Your tab just crashed" on *some* pages

[Stefan Monnier]

Package: firefox-esr
Version: 115.7.0esr-1
Severity: normal

Dear Maintainer,

For some reason my `firefox-esr` is refusing to show me some pages.
Most pages work fine, but some give me the dreaded "Gah. Your tab just
crashed".

Two example URLs which suffer this fate are:

https://diro.umontreal.ca/accueil/
https://www.nserc-crsng.gc.ca/students-etudiants/ug-pc/usra-brpc_eng.asp

in both cases, if I `firefox-esr --safe-mode ` it starts up and (after
confirming that I understand what "safe-mode" means), it gives me the "gah..."
instead of showing me the page.  On stdout/stderr I see:

[Parent 18669, IPC I/O Parent] WARNING: process 18781 exited on signal 15:
file ./ipc/chromium/src/base/process_util_posix.cc:264

I tried `aptitude reinstall firefox-esr` but that made no difference.

I downloaded Mozilla's own `firefox-esr` and this one does *not* exhibit the
problem.
I also tried to `aptitude reinstall libnss3:i386 libnspr4:i386` which are
apparently the other packages containing the `.so` libs included in Mozilla's
own tarball, but that did not help.

I tried running `firefox-esr` under GDB but the error is apparently caught
internally because GDB did not show me anything beside loads of creation (and
exit) of threads and the same IPC I/O error message as quoted above.

I don't know how to track this down further :-(


Stefan


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 firefox-esr depends on:
ii  debianutils  5.16
ii  fontconfig   2.14.2-6+b1
ii  libasound2   1.2.10-3
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-15
ii  libcairo-gobject21.18.0-1+b1
ii  libcairo21.18.0-1+b1
ii  libdbus-1-3  1.14.10-4
ii  libdbus-glib-1-2 0.112-3+b1
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-2
ii  libfontconfig1   2.14.2-6+b1
ii  libfreetype6 2.13.2+dfsg-1+b1
ii  libgcc-s114-20240201-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.3-2
ii  libgtk-3-0   3.24.41-1
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.96.1-1
ii  libpango-1.0-0   1.51.0+ds-4
ii  libstdc++6   14-20240201-3
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.4-4
ii  zlib1g   1:1.3.dfsg-3+b1

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.4.2-1+b3
ii  libavcodec60  7:6.1.1-1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-5
ii  libcanberra0   0.30-11
ii  libgssapi-krb5-2   1.20.1-5+b1
pn  pulseaudio 

-- no debconf information

Bug#939406: ITP: ungoogled-chromium -- Web browser that aims to build a safer, faster, and more stable internet browsing experience

[Stefan Monnier]

> Please work on the already existing (and patched!) chromium in the archive
> instead of adding one additional chromium-based browser that then also lacks
> team power. If you need any additional patches on Debian's chromium that are
> in ungoogled chromium, make them available in Debian's chromium.

Does that mean that Debian's `chromium` is also "ungoogled"?
That would admittedly make a lot of sense.
I see a directory `ungoogled` in

https://sources.debian.org/src/chromium/121.0.6167.160-1/debian/patches/

but it contains a fairly trivial patch that doesn't do what I expect
"ungoogled" to mean.

If it is indeed, ungoogled, then the package's description should say
so, shouldn't it?  Currently it just says:

Description: web browser
 Web browser that aims to build a safer, faster, and more stable internet
 browsing experience. 
 
 This package contains the web browser component.

which doesn't hint at it being ungoogled at all.


Stefan

Bug#1063483: linux-headers-amd64:amd64: Can't install on 32bit system

[Stefan Monnier]

Package: linux-headers-amd64
Severity: normal

Dear Maintainer,

I've been using a i386 install running on an amd64 kernel for many
years, and recently a new problem showed up: to build kernel modules
`dkms` needs `linux-headers-amd64(:amd64)` and this package conflicts
with the 32bit GCC toolchain forcing me to install gcc-13:amd64 instead,
which in turns forces me to move to the amd64 version of many other
packages (such as `ocaml`, `ghc`, `emacs`, ...).

I suspect this is linked to bug#1042993


Stefan


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

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 linux-headers-amd64:amd64 depends on:
ii  linux-headers-6.5.0-5-amd64  6.5.13-1

linux-headers-amd64:amd64 recommends no packages.

linux-headers-amd64:amd64 suggests no packages.

-- no debconf information
--

Bug#1063356: Acknowledgement (debdelta: `debdelta-upgrade` generates file with wrong name (encoded + as %2b))

[Stefan Monnier]

Oh, and I finally did manage to recover the output where I noticed the
problem (from a script which runs debdelta-upgrade` followed by
`aptitude upgrade`):

[...]
Recreated debs are saved in the directory /var/cache/apt/archives   

 Deltas: 1 present and 0 not,   

 downloaded so far: time 0.23sec, size 10kB, speed 43kB/sec.
 Need to get 21kB of deltas.
Downloaded, time  0.04sec, speed 311kB/sec, 
libzbar0_0.23.92-7_0.23.92-7+deb12u1_amd64.debdelta
 Patching done, time 0.14sec, speed 886k/sec (script 0.11sec 
1153k/sec)(unaccounted 0.03sec)
Created,time  0.14sec, speed 886kB/sec, 
libzbar0_0.23.92-7%2bdeb12u1_amd64.deb
Delta-upgrade statistics:   

 downloaded deltas, size 21kB time 0sec speed 79kB/sec
 patching to debs, size 126kB time 0sec speed 885kB/sec
 total resulting debs, size 126kB time 0sec virtual speed 132kB/sec
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be upgraded: 
  libzbar0  
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 130 kB of archives. After unpacking 0 B will be used.
Do you want to continue? [Y/n/?] 
Get: 1 http://security.debian.org stable-security/main amd64 libzbar0 amd64 
0.23.92-7+deb12u1 [130 kB]
Fetched 130 kB in 0s (880 kB/s)  
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 465771 files and directories currently installed.)
Preparing to unpack .../libzbar0_0.23.92-7+deb12u1_amd64.deb ...
Unpacking libzbar0:amd64 (0.23.92-7+deb12u1) over (0.23.92-7) ...
Setting up libzbar0:amd64 (0.23.92-7+deb12u1) ...
Processing triggers for libc-bin (2.36-9+deb12u4) ...
[...]


- Stefan

Bug#1063356: debdelta: `debdelta-upgrade` generates file with wrong name (encoded + as %2b)

[Stefan Monnier]

Package: debdelta
Version: 0.67
Severity: normal

Dear Maintainer,

I happened to notice that after debdelta created a deb file for libzbar0,
`apt` downloaded it nevertheless.
So I went to check /var/cache and sure enough:

% l /var/cache/apt/archives/libzbar0_0.23.92-7*
-rw-r--r-- 1 root root 129748 jan  4  2023 
/var/cache/apt/archives/libzbar0_0.23.92-7_amd64.deb
-rw-r--r-- 1 root root 129788 jan 14 11:18 
/var/cache/apt/archives/libzbar0_0.23.92-7+deb12u1_amd64.deb
-rw-r--r-- 1 root root 129788 fv  4 08:50 
/var/cache/apt/archives/libzbar0_0.23.92-7%2bdeb12u1_amd64.deb
% 

As you can see, what happened is that `debdelta-upgrade` incorrectly
named the generated file `libzbar0_0.23.92-7%2bdeb12u1_amd64.deb`,
i.e. encoded the `+` as a `%2b`.


Stefan


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

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

Versions of packages debdelta depends on:
ii  binutils  2.40-2
ii  bzip2 1.0.8-5+b1
ii  libbz2-1.01.0.8-5+b1
ii  libc6 2.36-9+deb12u4
ii  python3   3.11.2-1+b1
ii  python3-requests  2.28.1+dfsg-1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages debdelta recommends:
pn  bsdiff   
ii  gnupg2   2.2.40-1.1
ii  gpg-agent [gnupg-agent]  2.2.40-1.1
ii  python3-apt  2.6.0
ii  python3-debian   0.1.49
pn  xdelta   
ii  xdelta3  3.0.11-dfsg-1.2
ii  xz-utils [lzma]  5.4.1-0.2

Versions of packages debdelta suggests:
pn  debdelta-doc  

-- no debconf information

Bug#1060172: xserver-xorg-core: Screen remains desperately black after starting Xorg on Thinkpad X201s

[Stefan Monnier]

> Xorg refuses to work on my Thinkpad X201s nowadays, tho it used to work just
> fine a year or so ago.  Wayland still works fine.
> The observed behavior is that when GDM3 starts up (using Xorg because
> I have set `WaylandEnable=false` in its config file) at the end of the
> boot process, the screen becomes black and remains so.
> I can use the keyboard to suspend and resume the machine, but I'm flying 
> blind.

I found a workaround.
If I create a file `/etc/X11/xorg.conf` with the following contents:

% cat /etc/X11/xorg.conf
# Workaround for Debian bug#1005359.
Section "Device"
Identifier "modesetting"
Driver "modesetting"
Option "UseGammaLUT" "false"
EndSection
%

then the Xorg server comes up fine.

As the comment indicate, I took this workaround from bug#1005359, so
maybe the two bugs should be merged.

(I hadn't tried this earlier since I presumed that the hardware was
sufficiently different between my X201s and my Librem mini that the
bugs would also be different).


Stefan

Bug#1060172: xserver-xorg-core: Screen remains desperately black after starting Xorg on Thinkpad X201s

[Stefan Monnier]

Package: xserver-xorg-core
Version: 2:21.1.10-1
Severity: normal

Dear Maintainer,

Xorg refuses to work on my Thinkpad X201s nowadays, tho it used to work just
fine a year or so ago.  Wayland still works fine.

The observed behavior is that when GDM3 starts up (using Xorg because
I have set `WaylandEnable=false` in its config file) at the end of the
boot process, the screen becomes black and remains so.

I can use the keyboard to suspend and resume the machine, but I'm flying blind.

The same happens if I start Xorg "manually".

I have attached the corresponding Xorg.0.log from
/var/lib/gdm3/.local/share/xorg/ (which is very similar to the log
I see below, tho not quite identical because it's more recent).


Stefan

-- 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:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor 
Integrated Graphics Controller [8086:0046] (rev 02)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 6.5.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-7) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC 
Debian 6.5.13-1 (2023-11-29)

Xorg X server log files on system:
--
-rw-r--r-- 1 monnier monnier 76698 Sep 12  2018 
/home/monnier/.local/share/xorg/Xorg.2.log
-rw-r--r-- 1 monnier monnier 42484 Nov  4 19:30 
/home/monnier/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 monnier monnier 36864 Nov  4 19:40 
/home/monnier/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 rootroot33004 Nov  4 20:48 /var/log/Xorg.2.log

Contents of most recent Xorg X server log file (/var/log/Xorg.2.log):
-
[  1354.627] 
X.Org X Server 1.21.1.9
X Protocol Version 11, Revision 0
[  1354.634] Current Operating System: Linux milanesa 6.5.0-3-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.5.8-1 (2023-10-22) x86_64
[  1354.634] Kernel command line: BOOT_IMAGE=/vmlinuz-6.5.0-3-amd64 
root=/dev/mapper/Milanesa-root ro
[  1354.639] xorg-server 2:21.1.9-1 (https://www.debian.org/support) 
[  1354.641] Current version of pixman: 0.42.2
[  1354.645]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1354.645] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1354.653] (==) Log file: "/var/log/Xorg.2.log", Time: Sat Nov  4 20:35:06 
2023
[  1354.655] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1354.657] (==) No Layout section.  Using the first Screen section.
[  1354.657] (==) No screen section available. Using defaults.
[  1354.657] (**) |-->Screen "Default Screen Section" (0)
[  1354.657] (**) |   |-->Monitor ""
[  1354.658] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  1354.658] (==) Automatically adding devices
[  1354.658] (==) Automatically enabling devices
[  1354.658] (==) Automatically adding GPU devices
[  1354.658] (==) Automatically binding GPU devices
[  1354.659] (==) Max clients allowed: 256, resource mask: 0x1f
[  1354.659] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  1354.659]Entry deleted from font path.
[  1354.659] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  1354.659] (==) ModulePath set to "/usr/lib/xorg/modules"
[  1354.659] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  1354.659] (II) Loader magic: 0x568b67a0
[  1354.659] (II) Module ABI versions:
[  1354.659]X.Org ANSI C Emulation: 0.4
[  1354.659]X.Org Video Driver: 25.2
[  1354.659]X.Org XInput driver : 24.4
[  1354.659]X.Org Server Extension : 10.0
[  1354.662] (--) using VT number 1

[  1354.662] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[  1354.665] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1354.665] (II) Platform probe for 
/sys/devices/pci:00/:00:02.0/drm/card0
[  1354.673] (--) PCI:*(0@0:2:0) 8086:0046:17aa:215a rev 2, Mem @ 
0xf200/4194304, 0xd000/268435456, I/O @ 0x1800/8, BIOS @ 
0x/131072
[  1354.673] (II) LoadModule: "glx"
[  1354.675] (II) Loading /usr/lib/x

Bug#1054660: debdelta: Improve performance info

[Stefan Monnier]

> 2) if there is no delta, it will "download" the new package (this may be
>because, the delta was too big, or the package was too small, or, some
>error)
> 3) after all available deltas have been applied, it may exit, or continue
>   downloading all needed new .deb
> This behavior can be tuned with the option --deb-policy option, see
> man page.

I guess my question is: why does it ever download the `.deb` package?

[..time passes..]

Oh.. could it be that you do it as an optimization: if we're still
applying patches, rather than leave the network unused and since we
can't start `apt` yet, download some of the remaining packages, so the
(presumed) subsequent `apt` will be faster?

>> Q uestions that I can't answer based on the above output:
>> - I don't see any other mention of "avahi-daemon" than the "created" line,
>>so how was it created?
> by downloading the delta and applying it

But in the output there was no mention of downloading anything related to
that package, whereas most other packages have two lines, one about the
download and one about the creation (in my sample out, this is the case
for `libreoffice-calc`).

>>There's no subsequent matching "created" line, so IIUC it was
>>downloaded in non-delta form, which I'd expect `debdelta-upgrade`
>>never does (leaving it to `apt upgrade` instead).
> actually, it does

I did not expect that behavior.

>> - I'd appreciate seeing the actual size of the downloaded data on each
>>   line (maybe instead of the time?).
> add some -v options

Duh, can't believe I didn't think of that.
This said, with a `-v` I get more output than what I'd like, but well,
one can't satisfy everyone.


Stefan

Bug#1054665: debdelta: Avoid generating the actual `.deb`

[Stefan Monnier]

> debpatch and debdelta-upgrade have an option
>  --format unzipped
> that will recreate the deb w/o compressing the data part: this is
> much faster.

But it would often use a lot more disk space :-(
If we were instead to just keep the original `.deb` together with the
xdelta, it would be in most cases smaller.

> The point is, I do not know if apt will accept those .debs . Maybe apt may
> have an option to accept debs even when the size is not what is expected.

I strongly suspect that it would require changes in APT, indeed.


Stefan

Bug#1054665: debdelta: Avoid generating the actual `.deb`

[Stefan Monnier]

Subject: debdelta: Avoid generating the actual `.deb`
Package: debdelta
Version: 0.67
Severity: wishlist

Dear Maintainer,

`debdelta-upgrade` is great at reducing the amount of data downloaded,
but on some of my (weaker) machines, generating the `.deb` files takes
a lot of time, and for no good reason: 99% of the time is spent not
applying the xdelta but (re)compressing the result with `xz`.

So, this wishlist item is to change APT such that we can skip the
generation of the `.deb` file and instead keep the old `.deb` together
with the patch(es) in `/var/cache/apt/archives`.
When APT needs to install the (not created) `.deb`, instead of
unpacking+uncompressing the (not created) `.deb`, it would
unpack+uncompress the old `.deb`, and apply the (set of) patch(es).

Since the old `.deb` + patch(es) is usually larger than
a patched+recompressed `.deb`, we could occasionally "repack" the files
in `/var/cache/apt/archives`, but that would be optional and could be
performed opportunistically in the background, a bit like Git's GC.


Stefan


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

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

Versions of packages debdelta depends on:
ii  binutils  2.41-6
ii  bzip2 1.0.8-5+b1
ii  libbz2-1.01.0.8-5+b1
ii  libc6 2.37-12
ii  python3   3.11.4-5+b1
ii  python3-requests  2.31.0+dfsg-1
ii  zlib1g1:1.2.13.dfsg-3

Versions of packages debdelta recommends:
ii  bsdiff   4.3-23
ii  gnupg2   2.2.40-1.1
ii  gpg-agent [gnupg-agent]  2.2.40-1.1
ii  lzma 9.22-2.2
ii  python3-apt  2.6.0
ii  python3-debian   0.1.49
ii  xdelta   1.1.3-10.4
ii  xdelta3  3.0.11-dfsg-1.2
ii  xz-utils [lzma]  5.4.4-0.1

Versions of packages debdelta suggests:
pn  debdelta-doc  

-- no debconf information

Bug#1054660: debdelta: Improve performance info

[Stefan Monnier]

Subject: debdelta: Improve performance info
Package: debdelta
Version: 0.67
Severity: minor

Dear Maintainer,

I'm very happily using `debdelta-upgrade` now that I finally heard about
it (I've been using Debian for 20 years and wishing for something like
DebDelta for a big part of it), so first: thanks!

One think that annoys me is that I find the output unclear.  E.g. I see
[note the output was actually in French, so I translated it by hand, it
probably doesn't match 100% what debdelta would say]:

Created,time  0.42sec, speed 202kB/sec, avahi-daemon_0.8-12_i386.deb
[...]
The delta est too large: libmbim-glib4_1.28.4-2_1.30.0-1_i386.debdelta
Delta was not created since new package is too small: 
libmbim-proxy_1.28.4-2_1.30.0-1_i386.debdelta
[...]
Created,time  1.07sec, speed 239kB/sec, 
libedata-book-1.2-27_3.50.1-1_i386.deb
[...]
Downloaded, time  0.11sec, speed  8kB/sec, 
libudisks2-0_2.10.1-1_2.10.1-2_i386.debdelta
Downloaded, time  0.24sec, speed 13MB/sec, 
libreoffice-calc_4%3a7.5.6-1_4%3a7.5.8~rc1-2_i386.debdelta
[...]
Downloaded, time  0.02sec, speed 488kB/sec, libmbim-proxy_1.30.0-1_i386.deb
Downloaded, time  0.03sec, speed 7658kB/sec, libmbim-glib4_1.30.0-1_i386.deb
[...]
Created,time 27.30sec, speed 296kB/sec, 
libreoffice-calc_4%3a7.5.8~rc1-2_i386.deb
[...]
Statistics of delta-upgrade:
   debs result total, size 115MB time 257sec virtual speed 458kB/sec

Questions that I can't answer based on the above output:
- I don't see any other mention of "avahi-daemon" than the "created" line,
  so how was it created?
  [ Could it be due to some previous `debdelta-upgrade` run which
was maybe interrupted?  I can't remember causing that recently
enough, tho.  ]
- Why/how were `libmbim-proxy` and `libmbim-glib4` downloaded (since
  there's a delta missing for them) and from where?
  There's no subsequent matching "created" line, so IIUC it was
  downloaded in non-delta form, which I'd expect `debdelta-upgrade`
  never does (leaving it to `apt upgrade` instead).
- The "Downloaded" speed varies very widely (which is admittedly fair
  game, it might just be the result of the state of the network and
  server), and oddly enough I've seen it often higher than my DSL
  connection speed (even for large packages, so it doesn't seem to be
  some kind of rounding error), so it makes me wonder what is it
  exactly measuring.
  Could it be that it's reporting the speed of "virtual bytes"
  (i.e. the number of bytes of the resulting `.deb` after patching,
  rather than the number of bytes of the actual xdelta file)?
- I'd appreciate seeing the actual size of the downloaded data on each
  line (maybe instead of the time?).
- In the final statistics, I'd be interested to see a report comparing
  the amount of bytes that passed over the network compared to the
  number of bytes in the resulting `.deb` files (so as to see how much
  we gained in this).  I'd also be interested to see the average network
  download speed (not virtual) and the average "creation speed" (number
  of `.deb` bytes generated via patching divided by the time it took to
  do it).


Stefan


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 debdelta depends on:
ii  binutils  2.41-6
ii  bzip2 1.0.8-5+b1
ii  libbz2-1.01.0.8-5+b1
ii  libc6 2.37-12
ii  python3   3.11.4-5+b1
ii  python3-requests  2.31.0+dfsg-1
ii  zlib1g1:1.2.13.dfsg-3

Versions of packages debdelta recommends:
ii  bsdiff   4.3-23
ii  gnupg2   2.2.40-1.1
ii  gpg-agent [gnupg-agent]  2.2.40-1.1
ii  lzma 9.22-2.2
ii  python3-apt  2.6.0
ii  python3-debian   0.1.49
ii  xdelta   1.1.3-10.4
ii  xdelta3  3.0.11-dfsg-1.2
ii  xz-utils [lzma]  5.4.4-0.1

Versions of packages debdelta suggests:
pn  debdelta-doc  

-- no debconf information

Bug#1051901: 1.2.10 breaks ability to play audio using i386 binaries on amd64 host

[Stefan Monnier]

> I'd go so far to think that this is not constrained to i386 binaries on
> amd64 hosts. `aplay /dev/zero` segfaults on a plain i386 host with asound
> 1.2.10. Downgrading to 1.2.9 helps.

Is this the same as https://github.com/alsa-project/alsa-lib/issues/352 ?


Stefan

Bug#1054043: texlive: Texlive updates are too large

[Stefan Monnier]

>>  Stefan "dreaming of Debian updates as efficient as
>>  `git fetch` :-)"
> You are not the first one, who complains and (probably) not the last
> one.  Due to the limited man power in the team, we simply copy the
> packaging scheme given by TeX Live upstream and this is what you
> see here.

Indeed, I think the "fix" should probably be in the generic Debian
infrastructure rather than in any specific (set of) packages.

At most, the package maintainers might need to activate a special flag
telling that delta-encoding this package should be done by default.

> I'm aware of an idea called debdelta[1], maybe it is helpful for you.

Oh, that's indeed very interesting.  I hadn't heard of it yet.
It's very close to what I was thinking Debian should do.
And now I wonder why this is not better integrated into Debian so it's
used by default for packages like `texlive-fonts-extra`.
It could reduce the bandwidth load on Debian servers and even
potentially reduce the disk space used as well (if some .deb are deleted
in favor of deltas).


Stefan

Bug#1054043: texlive: Texlive updates are too large

[Stefan Monnier]

Package: texlive
Version: 2023.20230613-3
Severity: wishlist

Dear Maintainer,

This is not a new problem, but after all these years I figured maybe
I should finally report it: I think updates to Texlive are larger than
they should.  This is probably not completely specific to Texlive but
that's where I see it in the most glaring way since some of its packages
are the largest .deb packages I have.

Let's take the example of `texlive-lang-french`: the last two `.deb`
packages I have for it in /var (I'm tracking Debian testing) are around
80MB each.

But if I use `xdelta` on their respective (uncompressed) `data.tar`
I get an 11MB result, there's a clear potential to reduce the needed
download size by a factor 7x in this case (and potentially disk space).

For the `texlive-fonts-extra` monster, the xdelta is 20MB while the
`.deb` are 500MB, a reduction by a factor 24x.

[ The above two comparisons are between 2022.20230122-4 and
  2023.20230613-2.  ]

Clearly, taking advantage of this will require changes to the Debian
infrastructure, so is outside of the scope of the Texlive team itself,
but I hope you'll know where to redirect this "bug" report.

And in the mean time: thank you for your work, of course,


Stefan "dreaming of Debian updates as efficient as
`git fetch` :-)"


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

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

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

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

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

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

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

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

or 

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

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 root staff 80 Apr  3  2016 /usr/local/share/texmf/ls-R
-rw-rw-r-- 1 root root 2302 Sep 28 12:24 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 12  2022 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 27 17:39 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 27 17:39 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
-rw-r--r-- 1 root root 80 Apr 14  2014 /usr/share/texlive/texmf/ls-R
##
 Config files
-rw-r--r-- 1 root root 475 Oct 24  2022 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 27 17:39 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 27 17:39 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5047 Sep 22 12:54 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Aug 24  2006 mktex.cnf
-rw-r--r-- 1 root root 475 Oct 24  2022 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 texlive depends on:
ii  texlive-fonts-recommended  2023.20230613-3
ii  texlive-latex-base 2023.20230613-3
ii  texliv

Bug#1051282: closed by Debian FTP Masters (reply to Hilmar Preusse ) (Bug#1041148: fixed in texlive-bin 2023.20230311.66589-5)

[Stefan Monnier]

Working great again, thank you!


Stefan


Debian Bug Tracking System [2023-09-14 18:03:06] wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the texlive-binaries package:
>
> #1051282: texlive-binaries: Can't install without SSE2 on i386
>
> It has been closed by Debian FTP Masters 
> (reply to Hilmar Preusse ).
>
> 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 Debian FTP Masters
>  (reply to Hilmar Preusse )
> by
> replying to this email.

Bug#1042993: dkms: DKMS fails to build amd64 kernel module in i386 userland

[Stefan Monnier]

> since the wrong package: linux-compiler-gcc-13-x86
> is isntalled.

Thanks... so this prompted me to dig again into the problem and this
time I found a workaround which consist in installing
`gcc-13-x86-64-linux-gnu` (which I found simply via `apt-file search
/usr/bin/x86_64-linux-gnu-gcc-13`.  Not sure why it didn't occur to me
to try that earlier).

Hopefully someone here has an idea how this package should be
(automatically) brought in (and replaced when upgrading to a newer
version of GCC).


Stefan

Bug#1042993: dkms: DKMS fails to build amd64 kernel module in i386 userland

[Stefan Monnier]

Ping?

Any idea what change might have caused this?  It worked fine for kernel 6.1.0-7.


Stefan


Stefan Monnier [2023-08-03 18:37:23] wrote:

> Package: dkms
> Version: 3.0.11-3
> Severity: normal
>
> Dear Maintainer,
>
> My machine is running Debian testing i386 but with an amd64 kernel
> (to make better use of my 8GB of RAM).  I also have `dkms` and `tp-smapi-dkms`
> installed.
>
> Until recently this worked fine and built the `tp-smapi` kernel module for
> my `amd64` kernel.  But now installation of the 6.4.0-1-amd64 kernel causes
> problems when dkms tries to build the dkms package.
>
> More specifically I get the following error:
>
> dkms: running auto installation service for kernel 6.4.0-1-amd64.
> Sign command: /lib/modules/6.4.0-1-amd64/build/scripts/sign-file
> Signing key: /var/lib/dkms/mok.key
> Public certificate (MOK): /var/lib/dkms/mok.pub
>
> Building module:
> Cleaning build area...
> make -j2 KERNELRELEASE=6.4.0-1-amd64 -C /lib/modules/6.4.0-1-amd64/build
> M=/var/lib/dkms/tp_smapi/0.43/build HDAPS=1...(bad exit status: 2)
> Error! Bad return status for module build on kernel: 6.4.0-1-amd64 
> (x86_64)
> Consult /var/lib/dkms/tp_smapi/0.43/build/make.log for more information.
> dkms autoinstall on 6.4.0-1-amd64/x86_64 failed for tp_smapi(10)
> Error! One or more modules failed to install during autoinstall.
> Refer to previous errors for more information.
>
> and `/var/lib/dkms/tp_smapi/0.43/build/make.log` says:
>
> DKMS make.log for tp_smapi-0.43 for kernel 6.4.0-1-amd64 (x86_64)
> jeu 03 aoû 2023 18:35:09 EDT
> make : on entre dans le répertoire « /usr/src/linux-headers-6.4.0-1-amd64 
> »
>   CC [M]  /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o
> /bin/bash: ligne 1: x86_64-linux-gnu-gcc-13 : commande introuvable
> make[1]: *** [/usr/src/linux-
> headers-6.4.0-1-common/scripts/Makefile.build:257 :
> /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o] Erreur 127
> make[1]: *** Attente des tâches non terminées
>   CC [M]  /var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o
> /bin/bash: ligne 1: x86_64-linux-gnu-gcc-13 : commande introuvable
> make[1]: *** [/usr/src/linux-
> headers-6.4.0-1-common/scripts/Makefile.build:257 :
> /var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o] Erreur 127
> make: *** [/usr/src/linux-headers-6.4.0-1-common/Makefile:2051 :
> /var/lib/dkms/tp_smapi/0.43/build] Erreur 2
> make : on quitte le répertoire « /usr/src/linux-headers-6.4.0-1-amd64 »
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable-security'), (100, 'stable')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
>
> Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 dkms depends on:
> ii  build-essential  12.10
> ii  dpkg-dev 1.21.22
> ii  gcc [c-compiler] 4:13.1.0-4
> ii  gcc-10 [c-compiler]  10.4.0-7
> ii  gcc-11 [c-compiler]  11.4.0-2
> ii  gcc-12 [c-compiler]  12.3.0-6
> ii  gcc-13 [c-compiler]  13.1.0-9
> ii  gcc-9 [c-compiler]   9.3.0-22
> ii  kmod 30+20230519-1
> ii  lsb-release  12.0-2
> ii  make 4.3-4.1
> ii  patch2.7.6-7
>
> Versions of packages dkms recommends:
> ii  fakeroot 1.32.1-1
> iu  linux-headers-amd64 [linux-headers-generic]  6.4.4-1
> ii  sudo 1.9.14p2-1
>
> Versions of packages dkms suggests:
> ii  e2fsprogs  1.47.0-2
> ii  menu   2.1.50
>
> -- Configuration Files:
> /etc/modprobe.d/dkms.conf changed:
>
>
> -- no debconf information

Bug#1051282: texlive-binaries: Can't install without SSE2 on i386

[Stefan Monnier]

Package: texlive-binaries
Version: 2022.20220321.62855-8
Severity: normal

Dear Maintainer,

Apparently bug#1035461 is back.  `apt show texlive-binaries/testing`
shows:

Package: texlive-binaries
Version: 2023.20230311.66589-3
[...]
Depends: [...] sse2-support [...]

Any chance we can fix this regression?


Stefan


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

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

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

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

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

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

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

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

or 

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

##
minimal input file


##
other files

##
 List of ls-R files

lrwxrwxrwx 1 root root 31 Apr  9 05:54 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
-rw-r--r-- 1 root root 80 Apr 16  2014 /usr/share/texlive/texmf/ls-R
##
 Config files
-rw-r--r-- 1 root root 475 Mar 28 16:31 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Apr  9 05:54 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Apr  9 05:54 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2862 Aug 24 20:54 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 4
-rw-r--r-- 1 root root 475 Mar 28 16:31 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 6.4.0-3-686-pae (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 texlive-binaries depends on:
ii  libc6   2.37-7
ii  libcairo2   1.16.0-7
ii  libfontconfig1  2.14.2-4
ii  libfreetype62.13.1+dfsg-1
ii  libgcc-s1   13.2.0-2
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   8.0.1-1
ii  libicu7272.1-3
ii  libkpathsea62022.20220321.62855-8
ii  libmpfr64.2.0-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-1
ii  libptexenc1 2022.20220321.62855-8
ii  libstdc++6  13.2.0-2
ii  libsynctex2 2022.20220321.62855-8
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2022.20220321.62855-8
ii  libx11-62:1.8.6-1
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.12-1.1
ii  libxt6  1:1.2.1-1.1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-7
ii  t1utils 1.41-4
ii  tex-common  6.18
ii  zlib1g  1:1.2.13.dfsg-3

Versions of packages texlive-binaries recommends:
pn  dvisvgm   
ii  texlive-base  2022.20230122-3

texlive-binaries suggests no packages.

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

Versions of packages tex-common suggests:
ii  debhelper  13.11.5

Versions of packages texlive-binaries is related to:
ii  tex-common6.18
ii  texlive-base  2022.20230122-3

-- debconf information:
  tex-common/check_texmf_missing:
  tex-common/check_texmf_wrong:

Bug#1042993: dkms: DKMS fails to build amd64 kernel module in i386 userland

[Stefan Monnier]

Package: dkms
Version: 3.0.11-3
Severity: normal

Dear Maintainer,

My machine is running Debian testing i386 but with an amd64 kernel
(to make better use of my 8GB of RAM).  I also have `dkms` and `tp-smapi-dkms`
installed.

Until recently this worked fine and built the `tp-smapi` kernel module
for my `amd64` kernel.  But now installation of the
`linux-image-6.4.0-1-amd64:amd64` kernel encounters problems when dkms
tries to build the dkms package.

More specifically I get the following error:

dkms: running auto installation service for kernel 6.4.0-1-amd64.
Sign command: /lib/modules/6.4.0-1-amd64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j2 KERNELRELEASE=6.4.0-1-amd64 -C /lib/modules/6.4.0-1-amd64/build
M=/var/lib/dkms/tp_smapi/0.43/build HDAPS=1...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.4.0-1-amd64 (x86_64)
Consult /var/lib/dkms/tp_smapi/0.43/build/make.log for more information.
dkms autoinstall on 6.4.0-1-amd64/x86_64 failed for tp_smapi(10)
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.

and `/var/lib/dkms/tp_smapi/0.43/build/make.log` says:

DKMS make.log for tp_smapi-0.43 for kernel 6.4.0-1-amd64 (x86_64)
jeu 03 aoû 2023 18:35:09 EDT
make : on entre dans le répertoire « /usr/src/linux-headers-6.4.0-1-amd64 »
  CC [M]  /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o
/bin/bash: ligne 1: x86_64-linux-gnu-gcc-13 : commande introuvable
make[1]: *** [/usr/src/linux-
headers-6.4.0-1-common/scripts/Makefile.build:257 :
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o] Erreur 127
make[1]: *** Attente des tâches non terminées
  CC [M]  /var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o
/bin/bash: ligne 1: x86_64-linux-gnu-gcc-13 : commande introuvable
make[1]: *** [/usr/src/linux-
headers-6.4.0-1-common/scripts/Makefile.build:257 :
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o] Erreur 127
make: *** [/usr/src/linux-headers-6.4.0-1-common/Makefile:2051 :
/var/lib/dkms/tp_smapi/0.43/build] Erreur 2
make : on quitte le répertoire « /usr/src/linux-headers-6.4.0-1-amd64 »


-- Stefan


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 dkms depends on:
ii  build-essential  12.10
ii  dpkg-dev 1.21.22
ii  gcc [c-compiler] 4:13.1.0-4
ii  gcc-10 [c-compiler]  10.4.0-7
ii  gcc-11 [c-compiler]  11.4.0-2
ii  gcc-12 [c-compiler]  12.3.0-6
ii  gcc-13 [c-compiler]  13.1.0-9
ii  gcc-9 [c-compiler]   9.3.0-22
ii  kmod 30+20230519-1
ii  lsb-release  12.0-2
ii  make 4.3-4.1
ii  patch2.7.6-7

Versions of packages dkms recommends:
ii  fakeroot 1.32.1-1
iu  linux-headers-amd64 [linux-headers-generic]  6.4.4-1
ii  sudo 1.9.14p2-1

Versions of packages dkms suggests:
ii  e2fsprogs  1.47.0-2
ii  menu   2.1.50

-- Configuration Files:
/etc/modprobe.d/dkms.conf changed:


-- no debconf information

Bug#1035461: texlive-binaries: Allow install of TeXlive without SSE2

[Stefan Monnier]

 code that uses SSE2 instructions, so `texlive-binaries` was changed to
 require `sse2-support`.
>> Hmm, so SSE2 is not a requirement on Debian?

No, indeed.  And the `sse2-support` package is the embodiment of this fact.

There's a fairly good reason why SSE2 is not a requirement:
The Debian i386 port's /raison d'être/ is to support those i386 CPUs which
don't also support x86-64, so it's focused on supporting old CPUs.

Further info at: https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1

> For post-bookworm I'll do the split, commit has been done.

Thanks.

> For bookworm itself I could think about removing the luajit binaries
> in a point release, if they are not needed in all cases. I'll test
> that later on.

That would be even better :-)


Stefan

Bug#1035461: texlive-binaries: Allow install of TeXlive without SSE2

[Stefan Monnier]

>> In bug#1023007, we discovered that `luatex`'s JIT compiler generates
>> code that uses SSE2 instructions, so `texlive-binaries` was changed to
>> require `sse2-support`.
>>
> As I understood the situation it is not luatex, which does not work on
> your computer, but just the luajit... variants.

Ah, that would be even better.

> So I could split them out into a new package, which is only needed by
> texlive-extra-utils, b/c this package tries to build
> luajit... formats.

I have had to use `texlive-extra-utils` in the past, but yes, that would
be a a big improvement.

> Seems to be a rather easy solution. Unfortunately we are late in the
> release cycle [1]

I understand that.

> and the change won't make it into the next stable release. Sorry!

I think it's OK because I should be able to install the next version
from `testing` and then pin it.


Stefan

Bug#1035461: texlive-binaries: Allow install of TeXlive without SSE2

[Stefan Monnier]

Package: texlive-binaries
Version: 2022.20220321.62855-5
Severity: wishlist

Dear Maintainer,

In bug#1023007, we discovered that `luatex`'s JIT compiler generates
code that uses SSE2 instructions, so `texlive-binaries` was changed to
require `sse2-support`.

This was a quick&easy way to avoid the crashes when `luatex` is run on
an old machine without support for SSE2, but it does this in a rather
crude way since it basically prevents installation of TeXlive altogether
on such old machines, even for those common cases where `luatex` is not
used at all.

I can see various ways to improve the situation:

- Arrange for `luatex` to work even in the absence of SSE2, e.g. by
  disabling the JIT compiler on those old machines.
- Arrange for `luatex` to exit cleanly with a human-readable
  error message when run on a machine without SSE2 support.
- Change the package structure by splitting `luatex` out of
  `texlive-binaries`.

I personally don't use `luatex`, so anything that lets me install and
use `pdflatex` as before will make me happy.


Stefan


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

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

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

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

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

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

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

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

or 

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

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 root staff 80 Apr  3  2016 /usr/local/share/texmf/ls-R
-rw-rw-r-- 1 root root 2313 May  2 13:03 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 12  2022 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Apr  9 05:54 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Apr  9 05:54 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
-rw-r--r-- 1 root root 80 Apr 14  2014 /usr/share/texlive/texmf/ls-R
##
 Config files
-rw-r--r-- 1 root root 475 Oct 19  2022 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Apr  9 05:54 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Apr  9 05:54 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5047 Apr 18 14:51 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Aug 24  2006 mktex.cnf
-rw-r--r-- 1 root root 475 Oct 19  2022 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: 12.0
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 texlive-binaries depends on:
ii  libc6   2.36-9
ii  libcairo2   1.16.0-7
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgcc-s1   12.2.0-14
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   6.0.0+dfsg-3
ii  libicu7272.1-3
ii  libkpathsea62022.20220321.62855-5
ii  libmpfr64.2.0-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.39-2
ii  libptexenc1 2022.20220321.62855-5
ii  libstdc++6  12.2.

Bug#1005359: xserver-xorg-core: Intel HD Graphics 620: blank screen

[Stefan Monnier]

Timo Aaltonen [2023-03-09 08:50:09] wrote:
> Stefan Monnier kirjoitti 9.3.2023 klo 0.18:
>> Control: found -1 2:21.1.7-1
>> I still see this problem with the latest version on `testing`.
> I'm sure the problem is in the kernel driver (i915) and not xserver.

In that case, the kernel version would be relevant, right?
My latest test is with kernel version 6.1.0-5.


Stefan

Bug#1005359: xserver-xorg-core: Intel HD Graphics 620: blank screen

[Stefan Monnier]

Control: found -1 2:21.1.7-1

I still see this problem with the latest version on `testing`.


Stefan


Stefan Monnier [2022-09-21 16:02:47] wrote:

> Jakub Wilk [2022-02-11 23:17:58] wrote:
>> After recent upgrades, the X server no longer works for me: I get only 
>> blank screen. Worse, the blankness remains even after I zap the server.
>> Downgrading xserver-xorg-core to 2:1.20.14-1 fixed it for me.
>
> I'm not sure if I suffer from the same problem, but I'm seeing similar
> symptoms here on my Librem mini.
>
> I run Debian testing on this machine and since I had not rebooted it in
> a while I don't know which version of Xorg I've been happily running
> last, but after an `apt full-upgrade` I did a reboot and as soon as gdm
> launched Xorg, the screens (I have two monitors connected) went black.
> I couldn't find a way to bring the screens back to life, short of
> rebooting: I tried to stop Xorg/gdm, I tried suspend+resume, I tried to
> use lightdm.
>
> I downgraded to `xserver-xorg-core/stable` and things are back
> to normal.
>
> I attach the Xorg.log from when it got me a black screen.
>
>
> Stefan
>
> [65.676] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() 
> failed
> [65.676] _XSERVTransMakeAllCOTSServerListeners: server already running
> [65.676] (--) Log file renamed from
> "/var/lib/gdm3/.local/share/xorg/Xorg.pid-2189.log" to
> "/var/lib/gdm3/.local/share/xorg/Xorg.1.log"
> [65.677] 
> X.Org X Server 1.21.1.4
> X Protocol Version 11, Revision 0
> [65.677] Current Operating System: Linux lechazo 5.16.0-3-amd64 #1 SMP
> PREEMPT Debian 5.16.11-1 (2022-02-25) x86_64
> [65.677] Kernel command line: BOOT_IMAGE=/vmlinuz-5.16.0-3-amd64
> root=/dev/mapper/Alfajor-root ro fbcon=rotate:3
> [65.677] xorg-server 2:21.1.4-1 (https://www.debian.org/support) 
> [65.677] Current version of pixman: 0.40.0
> [65.677]  Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> [65.677] Markers: (--) probed, (**) from config file, (==) default 
> setting,
>   (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [65.677] (==) Log file: "/var/lib/gdm3/.local/share/xorg/Xorg.1.log",
> Time: Wed Sep 21 15:16:48 2022
> [65.677] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> [65.677] (==) No Layout section.  Using the first Screen section.
> [65.677] (==) No screen section available. Using defaults.
> [65.677] (**) |-->Screen "Default Screen Section" (0)
> [65.677] (**) |   |-->Monitor ""
> [65.678] (==) No monitor specified for screen "Default Screen Section".
>   Using a default monitor configuration.
> [65.678] (==) Automatically adding devices
> [65.678] (==) Automatically enabling devices
> [65.678] (==) Automatically adding GPU devices
> [65.678] (==) Automatically binding GPU devices
> [65.678] (==) Max clients allowed: 256, resource mask: 0x1f
> [65.678] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
> exist.
> [65.678]  Entry deleted from font path.
> [65.678] (==) FontPath set to:
>   /usr/share/fonts/X11/misc,
>   /usr/share/fonts/X11/100dpi/:unscaled,
>   /usr/share/fonts/X11/75dpi/:unscaled,
>   /usr/share/fonts/X11/Type1,
>   /usr/share/fonts/X11/100dpi,
>   /usr/share/fonts/X11/75dpi,
>   built-ins
> [65.678] (==) ModulePath set to "/usr/lib/xorg/modules"
> [65.678] (II) The server relies on udev to provide the list of input 
> devices.
>   If no devices become available, reconfigure udev or disable 
> AutoAddDevices.
> [65.678] (II) Loader magic: 0x568a97a0
> [65.678] (II) Module ABI versions:
> [65.678]  X.Org ANSI C Emulation: 0.4
> [65.678]  X.Org Video Driver: 25.2
> [65.678]  X.Org XInput driver : 24.4
> [65.678]  X.Org Server Extension : 10.0
> [65.678] (++) using VT number 1
>
> [65.680] (II) systemd-logind: took control of session 
> /org/freedesktop/login1/session/c2
> [65.681] (II) xfree86: Adding drm device (/dev/dri/card0)
> [65.681] (II) Platform probe for 
> /sys/devices/pci:00/:00:02.0/drm/card0
> [65.681] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 13 
> paused 0
> [65.683] (--) PCI:*(0@0:2:0) 8086:3ea0:8086:2212 rev 0, Mem @
> 0xd000/16777216, 0xc000/268435456, I/O @ 0x3000/64, BIOS @
> 0x/131072
> [65.683] (II) LoadModule: "glx"
> [65.683] 

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Stefan Monnier]

> Just to be clear, this condition should be checked before emacs is
> willing to use the temporary directory in question.  No unprivileged
> user should be able to overwrite a directory entry the uid of the
> emacs process creates at any point in the path to the temporary file.

AFAIK we usually consider it's up to the user/system to make sure this
is the case.


Stefan

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Stefan Monnier]

> Before e6043641d30 the file was created by Fmake_temp_file_internal and
> afterwards overwritten by libgccjit.

Yes, that was good.

> So I guess one could remove the file after the first creation and make
> it a link pointing to some other file waiting for libgccjit to do
> its write.

"One" as in "an attacker"?  In `/tmp` an attacker should not be able to
do that because it's supposed to be using the sticky bit so that only
the owner of a file can remove it.


Stefan

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Stefan Monnier]

>> `make-temp-name` uses `O_EXCL | O_CREAT` so as to close the race
>> condition: if someone predicated the filename, we detect it atomically
>> and we try again.
>>
>> You might like to check
>>
>> 
>> https://wiki.sei.cmu.edu/confluence/display/c/FIO21-C.+Do+not+create+temporary+files+in+shared+directories
>
> Thanks for the pointer.
>
> I'm still not really convinced we have a problem here with trampolines.
> With `make-temp-file' we are really only choosing the filename and
> suggesting it to libgccjit, this last one will perform the file
> creation.

The important part is the use of `O_EXCL | O_CREAT` when creating
the file.
*BUT* `O_EXCL | O_CREAT` will fail if the file already exists.  Which is
why `make-temp-file` needs `make-temp-name` to generate new names until
we find one that really doesn't exist (not just at the time
`make-temp-name` is called but the fraction of a millisecond later when
we do try to create it).

> I'd be surprised if GCC does not handle this correctly, and
> in case shouldn't this be a GCC bug?

I'd be surprised.  If you tell it to write to a pre-existing file, does
it fail with an error?  If not, then I think it can't be used safely unless
*you* pre-create the file (e.g. with `make-temp-file`).


Stefan

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Stefan Monnier]

> Shouldn't make-temp-file-internal return a non predictable file name?

Nope.  It's less predictable but it's still predictable.

> Otherwise what's the point of using make-temp-file in the first place if
> the temporary name is predictable?

`make-temp-name` uses `O_EXCL | O_CREAT` so as to close the race
condition: if someone predicated the filename, we detect it atomically
and we try again.

You might like to check


https://wiki.sei.cmu.edu/confluence/display/c/FIO21-C.+Do+not+create+temporary+files+in+shared+directories


-- Stefan

Bug#1020460: xdaliclock: New version ignores Xresource settings and can't be made transparent

[Stefan Monnier]

Oh, it's worse: I installed `picom` which made the opacity slider work,
but that affects the whole window, whereas I only want the background to
be transparent.

Along the way I noticed another problem with the opacity compared to the
old code that relied on the "Shape" X11 extension: even if I can use the
"opacity" setting to let me see my windows underneath the clock,
clicking in the background of the clock sends the even to the clock
rather than to the underlying window  :-(


Stefan

Bug#1020460: xdaliclock: New version ignores Xresource settings and can't be made transparent

[Stefan Monnier]

Package: xdaliclock
Version: 2.44+debian-2
Severity: normal

The version of xdaliclock in Debian testing seems to be quite different from
the version I've been running for the last ... 20 years(?).  The most obvious
difference is that it disregards my Xresource settings.

But more importantly, I was running it with `XDaliClock.transparent: true`,
but with the new code I can't seem to make it transparent.
I tried to play with the opacity slider in the GUI config, but it has no effect
on my system.  That might be due to my window-manager (ctwm) but the
transparency was the main feature which made me use this program, but this
failure makes it pointless.

I reverted to the xdaliclock in Debian stable for now.  Could there be two
builds of `xdaliclock` available, a bit like the `emacs-lucid` and `emacs-gtk`
alternatives?


Stefan


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 xdaliclock depends on:
ii  libc6 2.34-7
ii  libx11-6  2:1.8.1-2
ii  libxext6  2:1.3.4-1
ii  libxt61:1.2.1-1

xdaliclock recommends no packages.

xdaliclock suggests no packages.

-- no debconf information

Bug#1005359: xserver-xorg-core: Intel HD Graphics 620: blank screen

[Stefan Monnier]

Jakub Wilk [2022-02-11 23:17:58] wrote:
> After recent upgrades, the X server no longer works for me: I get only 
> blank screen. Worse, the blankness remains even after I zap the server.
> Downgrading xserver-xorg-core to 2:1.20.14-1 fixed it for me.

I'm not sure if I suffer from the same problem, but I'm seeing similar
symptoms here on my Librem mini.

I run Debian testing on this machine and since I had not rebooted it in
a while I don't know which version of Xorg I've been happily running
last, but after an `apt full-upgrade` I did a reboot and as soon as gdm
launched Xorg, the screens (I have two monitors connected) went black.
I couldn't find a way to bring the screens back to life, short of
rebooting: I tried to stop Xorg/gdm, I tried suspend+resume, I tried to
use lightdm.

I downgraded to `xserver-xorg-core/stable` and things are back
to normal.

I attach the Xorg.log from when it got me a black screen.


Stefan
[65.676] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() 
failed
[65.676] _XSERVTransMakeAllCOTSServerListeners: server already running
[65.676] (--) Log file renamed from 
"/var/lib/gdm3/.local/share/xorg/Xorg.pid-2189.log" to 
"/var/lib/gdm3/.local/share/xorg/Xorg.1.log"
[65.677] 
X.Org X Server 1.21.1.4
X Protocol Version 11, Revision 0
[65.677] Current Operating System: Linux lechazo 5.16.0-3-amd64 #1 SMP 
PREEMPT Debian 5.16.11-1 (2022-02-25) x86_64
[65.677] Kernel command line: BOOT_IMAGE=/vmlinuz-5.16.0-3-amd64 
root=/dev/mapper/Alfajor-root ro fbcon=rotate:3
[65.677] xorg-server 2:21.1.4-1 (https://www.debian.org/support) 
[65.677] Current version of pixman: 0.40.0
[65.677]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[65.677] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[65.677] (==) Log file: "/var/lib/gdm3/.local/share/xorg/Xorg.1.log", Time: 
Wed Sep 21 15:16:48 2022
[65.677] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[65.677] (==) No Layout section.  Using the first Screen section.
[65.677] (==) No screen section available. Using defaults.
[65.677] (**) |-->Screen "Default Screen Section" (0)
[65.677] (**) |   |-->Monitor ""
[65.678] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[65.678] (==) Automatically adding devices
[65.678] (==) Automatically enabling devices
[65.678] (==) Automatically adding GPU devices
[65.678] (==) Automatically binding GPU devices
[65.678] (==) Max clients allowed: 256, resource mask: 0x1f
[65.678] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[65.678]Entry deleted from font path.
[65.678] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[65.678] (==) ModulePath set to "/usr/lib/xorg/modules"
[65.678] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[65.678] (II) Loader magic: 0x568a97a0
[65.678] (II) Module ABI versions:
[65.678]X.Org ANSI C Emulation: 0.4
[65.678]X.Org Video Driver: 25.2
[65.678]X.Org XInput driver : 24.4
[65.678]X.Org Server Extension : 10.0
[65.678] (++) using VT number 1

[65.680] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/c2
[65.681] (II) xfree86: Adding drm device (/dev/dri/card0)
[65.681] (II) Platform probe for 
/sys/devices/pci:00/:00:02.0/drm/card0
[65.681] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 13 paused 0
[65.683] (--) PCI:*(0@0:2:0) 8086:3ea0:8086:2212 rev 0, Mem @ 
0xd000/16777216, 0xc000/268435456, I/O @ 0x3000/64, BIOS @ 
0x/131072
[65.683] (II) LoadModule: "glx"
[65.683] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[65.684] (II) Module glx: vendor="X.Org Foundation"
[65.684]compiled for 1.21.1.4, module version = 1.0.0
[65.684]ABI class: X.Org Server Extension, version 10.0
[65.684] (==) Matched modesetting as autoconfigured driver 0
[65.684] (==) Matched fbdev as autoconfigured driver 1
[65.684] (==) Matched vesa as autoconfigured driver 2
[65.684] (==) Assigned the driver to the xf86ConfigLayout
[65.684] (II) LoadModule: "modesetting"
[65.684] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[65.684] (II) Module modesetting: vendor="X.Org Foundation"
[65.684]compiled for 1.21.1.4, module version = 1.

Bug#979276: xserver-xorg-video-intel: Server fails to start: "Illegal instruction"

[Stefan Monnier]

> I just tried to upgrade my `testing` installation but the problem is
> still present.  Did you install the patch there?

I just upgraded to the new `bullseye` release and the problem is
still there.


Stefan

Bug#979276: xserver-xorg-video-intel: Server fails to start: "Illegal instruction"

[Stefan Monnier]

Julien Cristau [2021-03-18 14:58:30] wrote:

> On Thu, Mar 18, 2021 at 09:39:36AM -0400, Stefan Monnier wrote:
>> > I tried to reconstruct the given backtrace in [1].
>> 
>> Thanks,
>> 
>> > So the actual issue seems to be a "movq" instruction which
>> > seems to be due to [3] a SSE2 instruction, which might
>> > the "Pentium III M" is lacking, like Stefan already noted.
>> > I am not sure where the current Debian baseline could be
>> > consulted regarding this, maybe [4] could give a hint.
>> 
>> AFAIK Debian's i386 architecture does not (yet) require SSE2 (as
>> witnessed by the existence of the package `sse2-support`).
>> 
>> Where does this instruction come from?
>> Is it generated by GCC (and if so, why does GCC generate it)?
>> 
>
> I'm guessing because of this:
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/blob/master/src/sna/blt.c#L37
>
> Does the below help?

I just tried to upgrade my `testing` installation but the problem is
still present.  Did you install the patch there?


Stefan

Bug#979276: xserver-xorg-video-intel: Server fails to start: "Illegal instruction"

[Stefan Monnier]

> I tried to reconstruct the given backtrace in [1].

Thanks,

> So the actual issue seems to be a "movq" instruction which
> seems to be due to [3] a SSE2 instruction, which might
> the "Pentium III M" is lacking, like Stefan already noted.
> I am not sure where the current Debian baseline could be
> consulted regarding this, maybe [4] could give a hint.

AFAIK Debian's i386 architecture does not (yet) require SSE2 (as
witnessed by the existence of the package `sse2-support`).

Where does this instruction come from?
Is it generated by GCC (and if so, why does GCC generate it)?


Stefan


PS: I hope the i386 port never will require SSE2, since all the
processors I have which support SSE2 also support AMD64.

Bug#979276: xserver-xorg-video-intel: Server fails to start: "Illegal instruction"

[Stefan Monnier]

> My Thinkpad X30 uses Debian testing and after a recentish update (a couple
> months ago) the X server doesn't want to start any more.
>
> As you can see in the Xorg.0.log below, it fails with an "Illegal 
> instruction".
> This machine is admittedly old, so I suspect it might have to do with the
> code using instructions not supported by the processor (Pentium III M),
> but AFAIK this *should* work, so I think it's a bug.

I just tried `dpkg --purge xsrver-xorg-video-intel` to se if using
another driver would circumvent the problm but that just makes me bump
into another problem; the modesetting driver fails with:

(EE) modest(0): Failed to initialize glamor at ScreenInit() time.


-- Stefan

Bug#923998: openvpn: Openvpn tun0 loses IP and route

[Stefan Monnier]

> One of our VPN users encountered the same issue on Ubuntu 20.04, which lead
> us to investigate this. The cause of this issue is netscript-2.4[1], a rather
> old and obscure alternative ifup/ifdown implementation. In its default 
> configuration a netscript systemd service instance is automatically started
> shortly after the OpenVPN tunnel interface is created:

Indeed, I also discovered that the problem disappeared when I removed
the `netscript` package (not sure why it was installed).
Thanks,


Stefan

Bug#982314: mpd: 100% of CPU time on ARM Cortex A8 when playing 88.2kHz flac

[Stefan Monnier]

Package: mpd
Version: 0.21.5-3
Severity: normal

Dear Maintainer,

I'm pretty sure this is not a bug in MPD but probably in some of the
libraries it uses (libresample, maybe?).

Usually, when playing 44.1kHz flac files on my ARM SoC based on
Allwinner A10 (with one ARM Cortex A8), the CPU use of MPD is
negligeable (<10%), but when playing flac files sampled at 88.2kHz the
CPU is pegged at 100% and the playback frequently skips because the
CPU can't keep up.

I tried this test on my BananaPi with the exact same setup (cloned
Debian install) and the BananPi plays the file with no problem at all,
with a CPU use still <10%.

The BananaPi is a very similar machine built around the Allwinner A20
which is also a very similar SoC (but with two ARM Cortex A7).  AFAIK
the audio output hardware is similar, so I'd expect that if resampling
is needed on one it's also needed on the other, but I'm not 100% sure
and don't know how to confirm it.

The other important difference is the CPU, where the A7 is a bit more
recent and lists support for the following additional features:

evtstrm
idiva
idivt
lpae
vfpv4

So I'm wondering if the problem might be that some library is using
one of those features and is then massively slowed down by
some in-kernel emulation of the missing feature?
Not sure how to check that either.


Stefan


-- System Information:
Debian Release: 10.8
  APT prefers stable
  APT policy: (990, 'stable'), (50, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 5.6.0-2-armmp (SMP w/1 CPU core)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH.U
TF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mpd depends on:
ii  adduser   3.118
ii  init-system-helpers   1.56+nmu1
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-1
ii  libao41.2.2+20180113-1
ii  libasound21.1.8-1
ii  libaudiofile1 0.3.6-5
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavcodec58  7:4.1.6-1~deb10u1
ii  libavformat58 7:4.1.6-1~deb10u1
ii  libavutil56   7:4.1.6-1~deb10u1
ii  libbz2-1.01.0.6-9.2~deb10u1
ii  libc6 2.28-10
ii  libcdio-cdda2 10.2+0.94+2-4
ii  libcdio-paranoia2 10.2+0.94+2-4
ii  libcdio18 2.0.0-2
ii  libcurl3-gnutls   7.64.0-4+deb10u1
ii  libdbus-1-3   1.12.20-0+deb10u1
ii  libexpat1 2.2.6-2+deb10u1
ii  libfaad2  2.8.8-3
ii  libflac8  1.3.2-3
ii  libfluidsynth11.1.11-1
ii  libgcc-s1 [libgcc1]   10.1.0-3
ii  libgcc1   1:8.3.0-6
ii  libgcrypt20   1.8.4-5
ii  libgme0   0.6.2-1
ii  libicu63  63.1-6+deb10u1
ii  libid3tag00.15.1b-14
ii  libiso9660-11 2.0.0-2
ii  libixml10 1:1.8.4-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libjs-sphinxdoc   1.8.4-1
ii  libmad0   0.15.1b-10
ii  libmikmod33.3.11.1-4
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-2
ii  libmp3lame0   3.100-2+b1
ii  libmpcdec62:0.1~r495-1+b2
ii  libmpdclient2 2.16-1
ii  libmpg123-0   1.25.10-2
ii  libnfs12  3.0.0-2
ii  libogg0   1.3.2-1+b1
ii  libopenal11:1.19.1-1
ii  libopus0  1.3-1
ii  libpcre3  2:8.39-12
ii  libpulse0 12.2-4+deb10u1
ii  libsamplerate00.1.9-2
ii  libshout3 2.4.1-2
ii  libsidplayfp4 1.8.8-1
ii  libsmbclient  2:4.9.5+dfsg-5+deb10u1
ii  libsndfile1   1.0.28-6
ii  libsoxr0  0.1.2-3
ii  libsqlite3-0  3.27.2-3+deb10u1
ii  libstdc++68.3.0-6
ii  libsystemd0   241-7~deb10u6
ii  libupnp13 1:1.8.4-2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libwavpack1   5.1.0-6
ii  libwildmidi2  0.4.3-1
ii  libyajl2  2.1.0-3
ii  libzzip-0-13  0.13.62-3.2
ii  lsb-base  10.2019051400
ii  zlib1g1:1.2.11.dfsg-1

mpd recommends 

Bug#979276: xserver-xorg-video-intel: Server fails to start: "Illegal instruction"

[Stefan Monnier]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20200714-1+b1
Severity: important

Dear Maintainer,

My Thinkpad X30 uses Debian testing and after a recentish update (a couple
months ago) the X server doesn't want to start any more.

As you can see in the Xorg.0.log below, it fails with an "Illegal instruction".
This machine is admittedly old, so I suspect it might have to do with the
code using instructions not supported by the processor (Pentium III M),
but AFAIK this *should* work, so I think it's a bug.


Stefan


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Mar 16  2010 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Dec  2 05:41 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 82830M/MG 
Integrated Graphics Controller [8086:3577] (rev 04)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  # dynpm=1 dynclks=1
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 5.9.0-5-686-pae (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-1) 10.2.1 20201207, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP 
Debian 5.9.15-1 (2020-12-17)

Xorg X server log files on system:
--
-rw-r--r-- 1 rootroot225345 Nov 16  2007 /var/log/Xorg.22.log
-rw-r--r-- 1 rootroot138823 Nov 16  2007 /var/log/Xorg.23.log
-rw-r--r-- 1 rootroot 40062 Nov 16  2007 /var/log/Xorg.24.log
-rw-r--r-- 1 rootroot 35148 Aug 16  2008 /var/log/Xorg.21.log
-rw-r--r-- 1 rootroot 39499 Aug 22  2011 /var/log/Xorg.20.log
-rw-r--r-- 1 rootroot 28942 Jul 14  2017 /var/log/Xorg.2.log
-rw-r--r-- 1 monnier monnier  21559 Dec 18  2019 
/home/monnier/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 monnier monnier  22890 Aug  5 16:28 
/home/monnier/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 rootroot 0 Dec  7 19:13 /var/log/Xorg.1.log
-rw-r--r-- 1 rootroot  8218 Jan  4 13:31 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[   142.347] 
X.Org X Server 1.20.10
X Protocol Version 11, Revision 0
[   142.348] Build Operating System: Linux 4.19.0-12-amd64 i686 Debian
[   142.349] Current Operating System: Linux yuca 5.9.0-5-686-pae #1 SMP Debian 
5.9.15-1 (2020-12-17) i686
[   142.349] Kernel command line: BOOT_IMAGE=/vmlinuz-5.9.0-5-686-pae 
root=/dev/mapper/Ceviche-root ro
[   142.349] Build Date: 02 December 2020  10:41:35AM
[   142.349] xorg-server 2:1.20.10-1 (https://www.debian.org/support) 
[   142.349] Current version of pixman: 0.36.0
[   142.349]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   142.349] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   142.351] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jan  4 13:31:59 
2021
[   142.353] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   142.354] (==) No Layout section.  Using the first Screen section.
[   142.354] (==) No screen section available. Using defaults.
[   142.354] (**) |-->Screen "Default Screen Section" (0)
[   142.354] (**) |   |-->Monitor ""
[   142.355] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   142.355] (==) Automatically adding devices
[   142.356] (==) Automatically enabling devices
[   142.356] (==) Automatically adding GPU devices
[   142.356] (==) Max clients allowed: 256, resource mask: 0x1f
[   142.356] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   142.356]Entry deleted from font path.
[   142.356] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   142.356] (==) ModulePath set to "/usr/lib/xorg/modules"
[   142.356] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   142.356] (II) Loader magic: 0x6df740
[   142.357] (II) Module ABI versions:
[   142.357]X.Org ANSI C Emulation: 0.4
[   142.357]X.Org Video Driver: 24.1
[   142.357]X.Org XInput driver : 24.1
[   142.357]X.Org Server Extension : 10.0
[   142.367] (++) using VT number 7

[   142.367] (II) systemd-logind: lo

Bug#966133: network-manager: NM is slow to reconnect after suspend

[Stefan Monnier]

Package: network-manager
Version: 1.26.0-1
Severity: normal

Dear Maintainer,

All my Debian machines are much slower at reconnecting to the
local network than other machines (be they smartphones, tablets,
or laptops using proprietary OSes).

Here's what I see in the NM applet in the XFCE4 panel, when I wake
up from suspend:
- for about 10s the icon is "two computers" (which IIUC represents
  just NetworkManager sitting there pondering what to do).
- then the icon changes to the one representing a wired ethernet
  connection and stays that way for about 10s (there's nothing
  plugged into the ethernet port of this computer).
- then the icon changes to the "two dots, with something circling
  between them" which indicates that the system is in the process of
  connecting to a wifi network.
- after about 5s this changes to the bars representation of the
  signal quality.

IOW, while it takes about 5s to connect to the wifi network, it takes
about 20 additional seconds for NM to decide that it should try to
connect.

The 5s delay is fine, but the extra 20s looks like a bug to me.



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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-1
ii  libaudit11:2.8.5-3+b1
ii  libbluetooth35.50-1.2
ii  libc62.31-1
ii  libcurl3-gnutls  7.68.0-1+b1
ii  libglib2.0-0 2.64.4-1
ii  libgnutls30  3.6.14-2+b1
ii  libjansson4  2.13.1-1
ii  libmm-glib0  1.14.0-0.1
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b1
ii  libnm0   1.26.0-1
ii  libpam-systemd   245.6-2
ii  libpsl5  0.21.0-1.1
ii  libreadline8 8.0-4
ii  libselinux1  3.0-1+b3
ii  libsystemd0  245.6-2
ii  libteamdctl0 1.30-1
ii  libudev1 245.6-2
ii  libuuid1 2.35.2-7
ii  policykit-1  0.105-28
ii  udev 245.6-2
ii  wpasupplicant2:2.9.0-13

Versions of packages network-manager recommends:
pn  crda 
ii  dnsmasq-base [dnsmasq-base]  2.81-4
ii  iptables 1.8.5-2
pn  modemmanager 
ii  ppp  2.4.7-2+4.1+deb10u1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1+b2
pn  libteam-utils

-- no debconf information

Bug#965240: gkrellm: Gkrellm crashes at startup

[Stefan Monnier]

Package: gkrellm
Version: 2.3.10-2+b1
Severity: important

Dear Maintainer,

`gkrellm` stopped working a while back for me (can't say for sure when it 
started).
It crashes soon after displaying its window for me.  The error message is:

% /usr/bin/gkrellm --sync
The program 'gkrellm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadPixmap (invalid Pixmap parameter)'.
  (Details: serial 5672 error_code 4 request_code 56 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
%

I tried starting it under `gdb`, setting a breakpoint on `gdk_x_error`
and starting it with `--sync` but the breakpoint is never hit (and it
seems this gdk function is never even defined).

This occurs on all of my machines running Debian testing.


Stefan


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gkrellm depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.3-2
ii  libgnutls-openssl27  3.6.14-2
ii  libgnutls30  3.6.14-2
ii  libgtk2.0-0  2.24.32-4
ii  libice6  2:1.0.9-2
ii  libntlm0 1.6-1+b1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpangoft2-1.0-01.44.7-4
ii  libsensors5  1:3.6.0-2
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.6.9-2+b1

gkrellm recommends no packages.

gkrellm suggests no packages.

-- no debconf information

Bug#964725: texlive-latex-recommended: Package xparse (required for example via mdframed) gives Undefined control sequence

[Stefan Monnier]

>> An article I was working on started to throw me lots and lots of errors and 
>> not
>> generating any PDF when passed to `pdflatex` after the last upgrade of 
>> Texlive.
[...]
> https://tex.stackexchange.com/questions/550158/undefined-control-sequence-in-expl3
>
> says that it could be caused by a local format file sitting below
> ~/.texmf . Could you check?

Indeed I did

rm -rf ~/.texlive20*

and the problem's gone!  Thanks a lot!

This said, while I now have a solution for my own, I don't think
I should have to do that, so it'd be important to make sure this gets
fixed automatically (e.g. by using a fresh new ~/.texlive rather
than reusing one that may contain stale data, or by detecting the stale
data and removing it on-the-fly).


Stefan

Bug#964725: texlive-latex-recommended: Package xparse (required for example via mdframed) gives Undefined control sequence

[Stefan Monnier]

Package: texlive-latex-recommended
Version: 2020.20200629-1
Severity: important

Dear Maintainer,

An article I was working on started to throw me lots and lots of errors and not
generating any PDF when passed to `pdflatex` after the last upgrade of Texlive.

I reduced the problem to the followint test case:

\documentclass{article}
\usepackage{mdframed}
\begin{document}
haha
\end{document}

The errors I get start with:

% pdflatex test.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2020-02-02> patch level 5
L3 programming layer <2020-04-06>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2019/12/20 v1.4l Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/mdframed/mdframed.sty
(/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty)
(/usr/share/texlive/texmf-dist/tex/generic/kvsetkeys/kvsetkeys.sty))
(/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
! Undefined control sequence.
l.67   \bool
_new:N \g__expl_reload_bool
?

Same happens if I usepackage on "xparse" rather than "mdframed", tho I'm not
familiar with this package so I'm not sure if it's OK to pass that to
usepackage.



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

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

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

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

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

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

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

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

or 

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

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 root staff 80 Apr  3  2016 /usr/local/share/texmf/ls-R
-rw-rw-r-- 1 root root 2270 Jul  8 18:24 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jun  8 04:31 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jun 28 21:59 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jun 28 21:59 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
-rw-r--r-- 1 root root 80 Apr 14  2014 /usr/share/texlive/texmf/ls-R
##
 Config files
-rw-r--r-- 1 root root 475 Jun 16 17:38 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Jun 28 21:59 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Jun 28 21:59 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5033 Jul  8 18:23 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Aug 24  2006 mktex.cnf
-rw-r--r-- 1 root root 475 Jun 16 17:38 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=

Bug#902061: works for me

[Stefan Monnier]

> it worked for me, because I have a separate /boot partition. After
> changing the uuid of /boot, the machine does not boot.
>
> But IMO it's a problem of grub, using this sort of code in grub.cfg:
>
> if [ x$feature_platform_search_hint = xy ]; then
>   search --no-floppy --fs-uuid --set=root  
> 31147a1b-b3d3-1234-93ee-93854ac2505d
> else
>   search --no-floppy --fs-uuid --set=root 31147a1b-b3d3-1234-93ee-93854ac2505d
> fi
>
> If if would not use uuids here, it may work.

IIRC, this part was not problematic: Grub came up and it did load the
relevant kernel (and initrd), thanks presumably to "sane fallback
defaults".  The problem showed up later when the initrd script somehow
insisted on cheking for the presence of the partition with the
relevant UUID.


Stefan

Bug#902061: works for me

[Stefan Monnier]

> I justs tested dracut with this in the kernel cmdline:
> root=/dev/mapper/vg1-root
> Works without any problems.

But have you tested it with a disk that has different UUIDs?

I just tried

# lsinitrd /boot/initrd.img-5.3.0-2-armmp| grep by-uuid
-rw-r--r--   1 root root  146 Dec 12 08:19 
lib/dracut/hooks/emergency/80-\\x2fdev\\x2fdisk\\x2fby-uuid\\x2f5de7a0ca-5026-4294-ac9a-da24e3bae135.sh
-rw-r--r--   1 root root   64 Dec 12 08:19 
lib/dracut/hooks/initqueue/finished/devexists-\\x2fdev\\x2fdisk\\x2fby-uuid\\x2f5de7a0ca-5026-4294-ac9a-da24e3bae135.sh
~-0#

so in Debian's stable version of dracut from December, the UUID still
appears in the initrd.  I haven't tried to swap the drive to see if I'd
encounter again the same problem, but it seems likely (the files have
the same name and same size as the ones that seemed to cause trouble).


Stefan

Bug#932246: Re : Bug#932246: Re : Bug#932246: printer-driver-hpcups: no more printing to a HP LaserJet 1320: stack smashing detected and hpcups crashed on signal 6

[Stefan Monnier]

>> FWIW, I have 3.19.8+dfsg0-7 installed and am still seeing this problem.
> Knowing the printer model is always useful.

HP-Deskjet-5150

> The file /usr/lib/os-release has bullseye/sid in PRETTY_NAME. Edit
> bullseye/sid to reduce the number of characters to less than 12.
> Does this have any effect?

Yes, I removed the "/sid" and that worked around the problem (that's
how I confirmed that it was still the same problem, before sending my
previous message ;-)


Stefan

Bug#932246: Re : Bug#932246: Re : Bug#932246: printer-driver-hpcups: no more printing to a HP LaserJet 1320: stack smashing detected and hpcups crashed on signal 6

[Stefan Monnier]

> That'll be 3.19.8+dfsg0-4, uploaded later tonight. It will also ship 
> autopkgtests, to also test hplip printing on fake printers.

FWIW, I have 3.19.8+dfsg0-7 installed and am still seeing this problem.


Stefan

Bug#940614: gdm3: GDM doesn't start (I see flickering on the console a few times until it decides it has failed)

[Stefan Monnier]

Package: gdm3
Version: 3.30.2-3
Severity: important

Dear Maintainer,

After the upgrade to Buster, I'm unable to get GDM3 working on this system (a 
thinkpad X201s).
It fails at start.  I tried to change /etc/gdm3/daemon.conf to prevent use of 
Wayland,
but it made no noticeable difference.

I can start `xinit` from a root console login and it successfully launches the 
X xserver and the xterm.
I haven't found anything in the logs which gave me any hint at the origin of 
the problem (e.g.
the Xorg log in /var/lib/gdm3 doesn't have any EE lines, AFAICT).


Stefan


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-6-686-pae (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.45-2
ii  adduser   3.118
ii  ctwm [x-window-manager]   3.7-4+b1
ii  dconf-cli 0.30.1-2
ii  dconf-gsettings-backend   0.30.1-2
ii  debconf [debconf-2.0] 1.5.71
ii  gir1.2-gdm-1.03.30.2-3
ii  gnome-session [x-session-manager] 3.30.1-2
ii  gnome-session-bin 3.30.1-2
ii  gnome-settings-daemon 3.30.2-3
ii  gnome-shell   3.30.2-9
ii  gnome-terminal [x-terminal-emulator]  3.30.2-2
ii  gsettings-desktop-schemas 3.28.1-1
ii  libaccountsservice0   0.6.45-2
ii  libaudit1 1:2.8.4-3
ii  libc6 2.28-10
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libgdm1   3.30.2-3
ii  libglib2.0-0  2.58.3-2+deb10u1
ii  libglib2.0-bin2.58.3-2+deb10u1
ii  libgtk-3-03.24.5-1
ii  libkeyutils1  1.6-6
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd241-7~deb10u1
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.44.10-2.1
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-7~deb10u1
ii  libwrap0  7.6.q-28
ii  libx11-6  2:1.6.7-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.13.1-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  10.2019051400
ii  metacity [x-window-manager]   1:3.30.1-2
ii  mutter [x-window-manager] 3.30.2-7
ii  policykit-1   0.105-25
ii  procps2:3.3.15-2
ii  ucf   3.0038+nmu1
ii  wmaker [x-window-manager] 0.95.8-3
ii  x11-common1:7.7+19
ii  x11-xserver-utils 7.7+8
ii  xfce4-session [x-session-manager] 4.12.1-6
ii  xfce4-terminal [x-terminal-emulator]  0.8.7.4-2
ii  xfwm4 [x-window-manager]  4.12.5-1
ii  xterm [x-terminal-emulator]   344-1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.30.0-7
ii  desktop-base10.0.2
ii  x11-xkb-utils   7.7+4
ii  xserver-xephyr  2:1.20.4-1
ii  xserver-xorg1:7.7+19
ii  zenity  3.30.0-2

Versions of packages gdm3 suggests:
ii  gnome-orca3.30.1-1
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.28.2-5

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

Bug#874003: Fixed by both #70 and #75

[Stefan Monnier]

> I tried both of the fixes mentioned in messages #70 and #75. They both
> worked for me. Thanks everyone!

I just bumped into this bug on Debian stable (I suspect that it appeared
when I updated from 10.0 to 10.1).  I had

# cat /home//.config/xfce4/helpers.rc
FileManager=nautilus

#

and after removing this file the problem seems to be fixed.

I also have the file `/usr/share/applications/exo-file-manager.desktop`
which belongs to the `exo-utils` package, but I haven't verified if
removing it (which leaving the /home//.config/xfce4/helpers.rc in
place) fixes the problem.


Stefan

Bug#875643: firefox-esr: Can't specify external viewer like /usr/bin/emacsclient

[Stefan Monnier]

Ping?


Stefan


Stefan Monnier  writes:

> Ping?
>
> Still seems to be the case with version 52.8.0
>
>
> Stefan
>
>
> Stefan  writes:
>
>> Package: firefox-esr
>> Version: 52.3.0esr-2
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> In older versions of Firefox, the dialog box which asked me whether
>> I want to downoload the file or pass it to some external viewer
>> let me choose the viewer via a file-selector, so I could very easily
>> specify a viewer such as /usr/bin/emacsclient.
>>
>> Now I can't see to be able to do this any more.  All I can do is choose
>> among a bunch of applications listed with their icons, emacsclient
>> is not among them and I can't see any way to specify the application
>> I want by giving its full file name.  This severely restricts the
>> choice of external viewer for some file types.

Bug#923998: openvpn: Openvpn tun0 loses IP and route

[Stefan Monnier]

Package: openvpn
Version: 2.4.7-1
Severity: normal

Dear Maintainer,

My OpenVPN client setup just stopped working, maybe/likely linked to a recent
update of Debian (testing).

The end result is that the openvpn daemon looks happy and gives me the right
syslog messages, yet the interface gets no IP address (and no routes either, of
course):

# ifconfig tun0
tun0: flags=4305  mtu 1500
inet6 fe80::e580:a6b8:6f2:dd5  prefixlen 64  scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen
100  (UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 7  bytes 336 (336.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The syslog includes the expected lines such as:

Jan 25 11:12:41 ceviche ovpn-foo[9570]: /sbin/ip addr add dev tun0
NN.MM.OO.PP/24 broadcast NN.MM.OO.255
Jan 25 11:12:41 ceviche ovpn-foo[9570]: /sbin/ip route add HOSTIP1/32 via
NN.MM.OO.1

and if I run these lines by hand, then things go back to working (until the VPN
is restarted, obviously).

So my impression is that the interface is setup correctly but is later "undone"
by some external thing.  This impression comes from some suspicious extra
messages mentioning `tun0` that appear a bit further in the log:

Jan 25 11:12:41 ceviche systemd[1]: Unnecessary job for
/sys/subsystem/net/devices/tun0 was removed.
Jan 25 11:12:41 ceviche systemd[1]: Started Netscript ifup for tun0.
[...]
Jan 25 11:12:41 ceviche sh[9617]: Configuring interface: tun0.

Any idea what might be going on, how to track it down, or how to fix it?

This is a Debian testing system that's been following Debian testing for many
years.



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

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

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  iproute2   4.20.0-2
ii  libc6  2.28-7
ii  liblz4-1   1.8.3-1
ii  liblzo2-2  2.10-0.1
ii  libpam0g   1.3.1-5
ii  libpkcs11-helper1  1.25.1-1
ii  libssl1.1  1.1.1a-1
ii  libsystemd0241-1
ii  lsb-base   10.2018112800

Versions of packages openvpn recommends:
pn  easy-rsa  

Versions of packages openvpn suggests:
ii  openssl   1.1.1a-1
pn  openvpn-systemd-resolved  
ii  resolvconf1.79

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

-- debconf information:
  openvpn/vulnerable_prng:
  openvpn/create_tun: false

Bug#864827: Please go ahead adding explanations to the wiki

[Stefan Monnier]

>> This bug basically makes the package unusable.  
> Unfortunately that's true.
>> I understand that adapting the packaging to the new structure of
>> Zotero-5 will take some time, but in the mean time, could someone add
>> a page to the Debian wiki outlining how to install Zotero-5 by hand on
>> a Debian system
> You are more than welcomed to do so.  Everyone can contribute to the
> Debian wiki.

I know that, but I need to read this wiki page ;-)


Stefan

Bug#905674: parallel: move to nonfree

[Stefan Monnier]

> usage of parallel requires agreeing to a click-wrap that is inconsistent
> with the DFSG. it should be moved to non-free
[...]
> parallell --bibtex:
> "When using programs that use GNU Parallel to process data for publication
> please cite:
> ...
> Or you can get GNU Parallel without this requirement by paying 1 EUR.
> ...
> Type: 'will cite' and press enter."

Apparently this was changed in the mean time to a wording that makes it
clear it's only a polite request and not a legal requirement.

So, AFAICT it doesn't conflict with the DFSG (at least, not any more).


Stefan

Bug#903654: tor: Tor doesn't start because of AppArmor

[Stefan Monnier]

Package: tor
Version: 0.2.9.15-1
Severity: normal

Dear Maintainer,

I installed Tor on my machine and haven't made any change to its config yet,
as far as I know.
But when I start it, AppArmor seems to stop it right at the start.
More specifically, I get:

# /etc/init.d/tor stop 
[ ok ] Stopping tor (via systemctl): tor.service.
# /etc/init.d/tor start
[ ok ] Starting tor (via systemctl): tor.service.
# /etc/init.d/tor status
 tor.service - Anonymizing overlay network for TCP (multi-instance-master)
   Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: 
enabled)
   Active: active (exited) since Thu 2018-07-12 11:03:03 EDT; 2min 39s ago
  Process: 6842 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 6842 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
   Memory: 0B
  CPU: 0
   CGroup: /system.slice/tor.service

Jul 12 11:03:03 faina systemd[1]: Starting Anonymizing overlay network for 
TCP (multi-instance-master)...
Jul 12 11:03:03 faina systemd[1]: Started Anonymizing overlay network for 
TCP (multi-instance-master).
#

and `journalctl -f` on the "start" part gives me:

Jul 12 11:03:03 faina systemd[1]: Starting Anonymizing overlay network for 
TCP...
Jul 12 11:03:03 faina systemd[1]: Started Anonymizing overlay network for 
TCP (multi-instance-master).
Jul 12 11:03:04 faina tor[6862]: Jul 12 11:03:04.973 [notice] Tor 0.2.9.15 
(git-2dc1a1a2abab5403) running on Linux with Libevent 2.0.21-stable, OpenSSL 
1.1.0f and Zlib 1.2.8.
Jul 12 11:03:04 faina tor[6862]: Jul 12 11:03:04.974 [notice] Tor can't 
help you if you use it wrong! Learn how to be safe at 
https://www.torproject.org/download/download#warning
Jul 12 11:03:04 faina tor[6862]: Jul 12 11:03:04.974 [notice] Read 
configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jul 12 11:03:04 faina tor[6862]: Jul 12 11:03:04.974 [notice] Read 
configuration file "/etc/tor/torrc".
Jul 12 11:03:05 faina tor[6862]: Configuration was valid
Jul 12 11:03:05 faina audit[6873]: AVC apparmor="DENIED" 
operation="change_onexec" info="label not found" error=-2 profile="unconfined" 
name="system_tor" pid=6873 comm="(tor)"
Jul 12 11:03:05 faina kernel: audit: type=1400 audit(1531407785.239:26): 
apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 
profile="unconfined" name="system_tor" pid=6873 comm="(tor)"
Jul 12 11:03:05 faina systemd[6873]: tor@default.service: Failed at step 
APPARMOR spawning /usr/bin/tor: No such file or directory
Jul 12 11:03:05 faina systemd[1]: tor@default.service: Main process exited, 
code=exited, status=231/APPARMOR
Jul 12 11:03:05 faina systemd[1]: Failed to start Anonymizing overlay 
network for TCP.
Jul 12 11:03:05 faina systemd[1]: tor@default.service: Unit entered failed 
state.
Jul 12 11:03:05 faina systemd[1]: tor@default.service: Failed with result 
'exit-code'.
Jul 12 11:03:05 faina systemd[1]: tor@default.service: Service hold-off 
time over, scheduling restart.
Jul 12 11:03:05 faina systemd[1]: Stopped Anonymizing overlay network for 
TCP.

repeated 5 times.

I do see some tor-related file in /etc, tho:

# find /etc/apparmor* -name '*tor*'
/etc/apparmor.d/abstractions/tor
/etc/apparmor.d/local/system_tor
/etc/apparmor.d/system_tor
#

What am I doing wrong?


Stefan


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (50, 'testing')
Architecture: armhf (armv7l)

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

Versions of packages tor depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u3
ii  libevent-2.0-5   2.0.21-stable-3
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libssl1.11.1.0f-3+deb9u2
ii  libsystemd0  232-25+deb9u2
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages tor recommends:
ii  logrotate3.11.0-0.1
pn  tor-geoipdb  
pn  torsocks 

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
pn  obfsproxy
ii  socat1.7.3.1-2+deb9u1
pn  tor-arm  
pn  torbrowser-launcher  

-- no debconf information

Bug#902061: dracut: Can't boot from backup disk because of UUID

[Stefan Monnier]

> > specifies the root partition via "root=/dev/mapper/VG-root" so there's
> > no need for any UUID to find the root partition.  And since dracut
> > is not configured in "hostonly" mode, I did not expect any problem.
> Please try to use root=LABEL=.
> and see if this helps.

I don't label my partitions (it would be redundant since I name
the LVM volumes already).


Stefan

Bug#902061: dracut: Can't boot from backup disk because of UUID

[Stefan Monnier]

Package: dracut
Version: 044+241-3
Severity: normal

Dear Maintainer,

The HDD on my little BananaPi homeserver is dying (keeps giving errors
causing SATA coection reset, etc...), so I took it out and plugged
in another HDD that contained a backup copy of the system (basically
and `rsync` of the boot and root partitions).  My U-boot script
specifies the root partition via "root=/dev/mapper/VG-root" so there's
no need for any UUID to find the root partition.  And since dracut
is not configured in "hostonly" mode, I did not expect any problem.

Yet, the boot failed telling me that it couldn't find
/dev/disk/by-uuid/blablabla.

It did put me into some emergency shell where I managed to mount the
LVM partition (which the initrd has successfully found and activated),
rerun dracut and finally get my system to boot successfully.
But given the use of LVM and an explicit "root=..." on the kernel
command line, I don't see any justification for the boot failure.

Indeed, given my setup (and arguably any non-hostonly initrd)
I don't see why any UUID would appear in the inird, yet:

# lsinitrd /boot/initrd.img-4.16.0-2-armmp| grep by-uuid
-rw-r--r--   1 root root  146 Jun 18 15:22 
lib/dracut/hooks/emergency/80-\\x2fdev\\x2fdisk\\x2fby-uuid\\x2f1d3f740e-7a96-434a-8dfb-4a17e3dc563b.sh
-rw-r--r--   1 root root   64 Jun 18 15:22 
lib/dracut/hooks/initqueue/finished/devexists-\\x2fdev\\x2fdisk\\x2fby-uuid\\x2f1d3f740e-7a96-434a-8dfb-4a17e3dc563b.sh
# 

How can I configure dracut to "stay away from UUID since I use
LVM names instead"?  Shouldn't this be the default anyway when
the root partition is on LVM?


Stefan


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (50, 'testing')
Architecture: armhf (armv7l)

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

Versions of packages dracut depends on:
ii  dracut-core  044+241-3

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- Configuration Files:
/etc/bash_completion.d/dracut changed:
__contains_word () {
local word=$1; shift
for w in $*; do [[ $w = $word ]] && return 0; done
return 1
}
_dracut() {
local field_vals= cur=${COMP_WORDS[COMP_CWORD]} 
prev=${COMP_WORDS[COMP_CWORD-1]}
local -A OPTS=(
[STANDALONE]='-f -v -q -l -H -h -M -N
  --ro-mnt --force --kernel-only --no-kernel 
--strip --nostrip
  --hardlink --nohardlink --noprefix --mdadmconf 
--nomdadmconf
  --lvmconf --nolvmconf --debug --profile --verbose 
--quiet
  --local --hostonly --no-hostonly --fstab --help 
--bzip2 --lzma
  --xz --no-compress --gzip --list-modules 
--show-modules --keep
  --printsize --regenerate-all --noimageifnotneeded 
--early-microcode
  --no-early-microcode --print-cmdline --prelink 
--noprelink --reproducible
  --uefi
  '
   [ARG]='-a -m -o -d -I -k -c -L --kver --add --force-add 
--add-drivers
  --omit-drivers --modules --omit --drivers 
--filesystems --install
  --fwdir --libdirs --fscks --add-fstab --mount 
--device --nofscks
  --kmoddir --conf --confdir --tmpdir --stdlog 
--compress --prefix
  --kernel-cmdline --sshkey --persistent-policy 
--install-optional
  --loginstall --uefi-stub --kernel-image
  '
)
if __contains_word "$prev" ${OPTS[ARG]}; then
case $prev in
--kmoddir|-k|--fwdir|--confdir|--tmpdir)
comps=$(compgen -d -- "$cur")
compopt -o filenames
;;

-c|--conf|--sshkey|--add-fstab|--add-device|-I|--install|--install-optional)
comps=$(compgen -f -- "$cur")
compopt -o filenames
;;
-a|-m|-o|--add|--modules|--omit)
comps=$(dracut --list-modules 2>/dev/null)
;;
--persistent-policy)
comps=$(cd /dev/disk/; echo *)
;;
--kver)
comps=$(cd /lib/modules; echo [0-9]*)
;;
*)
return 0
;;
esac
COMPREPLY

Bug#875643: firefox-esr: Can't specify external viewer like /usr/bin/emacsclient

[Stefan Monnier]

Ping?

Still seems to be the case with version 52.8.0


Stefan


Stefan  writes:

> Package: firefox-esr
> Version: 52.3.0esr-2
> Severity: normal
>
> Dear Maintainer,
>
> In older versions of Firefox, the dialog box which asked me whether
> I want to downoload the file or pass it to some external viewer
> let me choose the viewer via a file-selector, so I could very easily
> specify a viewer such as /usr/bin/emacsclient.
>
> Now I can't see to be able to do this any more.  All I can do is choose
> among a bunch of applications listed with their icons, emacsclient
> is not among them and I can't see any way to specify the application
> I want by giving its full file name.  This severely restricts the
> choice of external viewer for some file types.

Bug#895572: mupdf-tools: mutool fails with "Cannot convert between incompatible pixmaps"

[Stefan Monnier]

Ping?


Stefan


Stefan Monnier  writes:

> Package: mupdf-tools
> Version: 1.12.0+ds1-1
> Severity: normal
>
> Dear Maintainer,
>
> Recently, Emacs's doc-view-mode started failing for me in some cases.
> After tracking down the origin of the problem, it seems to be due to
> a problem in `mutool`.
> I can reproduce it with:
>
> mutool draw -o foo.png foo.pdf 1
>
> with the attached PDF file, which gives me:
>
> page foo.pdf 1error: Cannot convert between incompatible pixmaps
> error: Cannot convert between incompatible pixmaps
> warning: Ignoring error during interpretation
> error: Cannot convert between incompatible pixmaps
> warning: Ignoring error during interpretation
> error: Cannot convert between incompatible pixmaps
> warning: Ignoring error during interpretation
> error: Cannot convert between incompatible pixmaps
> warning: Ignoring error during interpretation
>
> even though both `evince` and `mupdf` display it just fine.
>
>
> Stefan
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable')
> Architecture: i386 (i686)
>
> Kernel: Linux 4.14.0-3-686-pae (SMP w/2 CPU cores)
> Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CH.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages mupdf-tools depends on:
> ii  libc62.27-3
> ii  libfreetype6 2.8.1-2
> ii  libharfbuzz0b1.7.2-1
> ii  libjbig2dec0 0.13-6
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libopenjp2-7 2.3.0-1
> ii  zlib1g   1:1.2.8.dfsg-5
>
> mupdf-tools recommends no packages.
>
> mupdf-tools suggests no packages.
>
> -- no debconf information

Bug#895572: mupdf-tools: mutool fails with "Cannot convert between incompatible pixmaps"

[Stefan Monnier]

Package: mupdf-tools
Version: 1.12.0+ds1-1
Severity: normal

Dear Maintainer,

Recently, Emacs's doc-view-mode started failing for me in some cases.
After tracking down the origin of the problem, it seems to be due to
a problem in `mutool`.
I can reproduce it with:

mutool draw -o foo.png foo.pdf 1

with the attached PDF file, which gives me:

page foo.pdf 1error: Cannot convert between incompatible pixmaps
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation

even though both `evince` and `mupdf` display it just fine.


Stefan


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

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

Versions of packages mupdf-tools depends on:
ii  libc62.27-3
ii  libfreetype6 2.8.1-2
ii  libharfbuzz0b1.7.2-1
ii  libjbig2dec0 0.13-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libopenjp2-7 2.3.0-1
ii  zlib1g   1:1.2.8.dfsg-5

mupdf-tools recommends no packages.

mupdf-tools suggests no packages.

-- no debconf information


foo.pdf
Description: Adobe PDF document

Bug#845938: pulseaudio: bt headset: a2dp sink is not selectable - only hsp/hfp works

[Stefan Monnier]

> This is still an issue in Debian stretch: the gdm3 package runs
> pulseaudio, which takes over the bluetooth device and makes it
> impossible for regular users to connect to their bluetooth device
> using the hifi A2DP sink.  See #805414 for more details on that
> side.  There's a workaround for gdm3 (disabling the BT sink in gdm), so
> I'll leave that aside for now and focus on the basic issue here.

The problem is not limited to GDM, tho.

If you have several users logged in at the same time, only one of them
gets to use the bluetooth speaker, and once he gets it, the only way to
"free" the speaker (so another user can use it) seems to be to kill that
user's pulseaudio daemon.

The worst part is that the bluetooth speaker can easily get awarded to
a user who hasn't actually played any sound at all.

Currently, I work around this by manually removing bluetooth from the
pulseaudio config of all users except for the lucky one who is "more
deserving".  But it's a real PITA.


Stefan

Bug#894984: cups-browsed: Stopping and starting `cups` ends up stopping `cups-browsed`

[Stefan Monnier]

Package: cups-browsed
Version: 1.20.1-1+b1
Severity: normal

Here's a sample session:

# ps auxw|grep cups
root 27143  0.0  0.1  19508  9600 ?Ss   Apr040:07
/usr/sbin/cupsd -l
root 27144  0.0  0.1  42080 11184 ?Ssl  Apr04   0:00
/usr/sbin/cups-browsed
root 31856  0.0  0.0   5284   876 pts/5RN+  14:27   0:00 grep cups
~-0# /etc/init.d/cups stop;/etc/init.d/cups start
[ ok ] Stopping cups (via systemctl): cups.service.
[ ok ] Starting cups (via systemctl): cups.service.
~-0# ps auxw|grep cups
root 31935  0.0  0.0  17516  6932 ?Ss   14:28   0:00
/usr/sbin/cupsd -l
root 31954  0.0  0.0   5284   796 pts/5SN+  14:28   0:00 grep cups
~-0#

As you can see before the `cups stop; cups start` both `cupsd` and `cups-
browsed` were running, whereas afterwards only `cupsd` is running.

I believe this behavior is incorrect since no part of `cups stop; cups start`
says explicitly that we want `cups-browsed` to be stopped.  So either `cups
stop` should not stop `cups-browsed`, or it should check if `cups-browsed` is
running and arrange to make sure a subsequent `cups start` restarts it if
applicable.



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

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

Versions of packages cups-browsed depends on:
ii  cups-daemon   2.2.7-1
ii  libavahi-client3  0.7-3.1
ii  libavahi-common3  0.7-3.1
ii  libavahi-glib10.7-3.1
ii  libc6 2.27-3
ii  libcups2  2.2.7-1
ii  libcupsfilters1   1.20.1-1+b1
ii  libglib2.0-0  2.56.0-4
ii  libldap-2.4-2 2.4.45+dfsg-1
ii  lsb-base  9.20170808

Versions of packages cups-browsed recommends:
ii  avahi-daemon  0.7-3.1

cups-browsed suggests no packages.

-- no debconf information

Bug#894664: cups: Libreoffice doesn't see my network printer

[Stefan Monnier]

> So I cannot reproduce your problem.  I suppose disconnecting the ethernet
> connection doesn't do anything for you?

No, indeed: using only the ethernet or only the wifi connection doesn't
make any difference (usually only the ethernet is up).

>  > Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ server' of type
>  > '_ipp._tcp' in domain +'local' skipped, could not determine IP address.
> is (to me) a clear indication that something is wrong.  My knowledge of
> DNS matters is sparse so I think it is time for some help.

Is "local" above meant to refer to the DNS domain appended to the host
(i.e. does it mean the complete host name that was tried is
"server.local")?

> Till, Stefan has provided quite a lot of information (is it enough?).
> Are we looking at a misconfiguration, a tweak to cups-browsed.conf or
> a bug?

Hmm... now I looked further into my cups-browsed.conf and I think
I found the culprit: I had "BrowseOrder Allow,Deny" in there.
I removed it and now the printer appears.

Not sure how it got there.  Maybe it's when I tried to prevent those
"spurious" printers advertized by some local laptops from appearing, and
since I was testing this with `evince` I got the impression that none of
the BrowseDeny/BrowseAllow directives had any effect and left the config
file in this broken state without noticing.

It's also not clear why the debug log doesn't say that those printers are
simply "denied by default" and why it gives this odd "could not
determine IP address" instead.

But at least, on my side you can consider this bug closed as a "pilot
error" (tho I'll be happy to provide more info if you want to dig
further).

Thank you very much for your help,


Stefan

Bug#894664: cups: Libreoffice doesn't see my network printer

[Stefan Monnier]

> Thank you for thinking to send the log.  There are three devices with IP
> addresses which cannot be found.  Are they all printers?

Only the HP-8100 is a real printer.  The other two are advertised by
some laptop which happened to be connected.

> Does Evince show them all?

Yes.

> Please do
>
>   avahi-browse -art > log
>
> and post log. avahi-browse is in the avahi-utils package.

Here it is (the laptop was absent this time).


Stefan
+  wlan0 IPv6 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
+  wlan0 IPv4 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
+   eth0 IPv6 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
+   eth0 IPv4 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
+  wlan0 IPv6 CUPS @ server Web Site
 local
+  wlan0 IPv4 CUPS @ server Web Site
 local
+   eth0 IPv6 CUPS @ server Web Site
 local
+   eth0 IPv4 CUPS @ server Web Site
 local
+  wlan0 IPv6 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
+  wlan0 IPv4 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
+   eth0 IPv6 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
+   eth0 IPv4 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
+  wlan0 IPv6 HP OfficeJet Pro 8100 @ server_ipps._tcp  
 local
+  wlan0 IPv4 HP OfficeJet Pro 8100 @ server_ipps._tcp  
 local
+   eth0 IPv6 HP OfficeJet Pro 8100 @ server_ipps._tcp  
 local
+   eth0 IPv4 HP OfficeJet Pro 8100 @ server_ipps._tcp  
 local
=  wlan0 IPv6 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [0]
   txt = []
=  wlan0 IPv4 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [0]
   txt = []
=   eth0 IPv6 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [0]
   txt = []
=   eth0 IPv4 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [0]
   txt = []
=  wlan0 IPv6 CUPS @ server Web Site
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [631]
   txt = []
=  wlan0 IPv4 CUPS @ server Web Site
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [631]
   txt = []
=   eth0 IPv6 CUPS @ server Web Site
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [631]
   txt = []
=   eth0 IPv4 CUPS @ server Web Site
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [631]
   txt = []
=  wlan0 IPv6 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [631]
   txt = ["printer-type=0x901E" "printer-state=3" "Duplex=T" "Color=T" 
"TLS=1.2" "UUID=8a590a22-8022-31c0-7155-5d1c1f5bb656" "URF=DM3" 
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
 "product=(HP Officejet Pro 8100 eprinter-n811a)" "priority=0" "note=Salon" 
"adminurl=https://server.local:631/printers/Salon-HP-8100"; "ty=HP Officejet Pro 
8100, hpcups 3.16.11" "rp=printers/Salon-HP-8100" "qtotal=1" "txtvers=1"]
=  wlan0 IPv4 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [631]
   txt = ["printer-type=0x901E" "printer-state=3" "Duplex=T" "Color=T" 
"TLS=1.2" "UUID=8a590a22-8022-31c0-7155-5d1c1f5bb656" "URF=DM3" 
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
 "product=(HP Officejet Pro 8100 eprinter-n811a)" "priority=0" "note=Salon" 
"adminurl=https://server.local:631/printers/Salon-HP-8100"; "ty=HP Officejet Pro 
8100, hpcups 3.16.11" "rp=printers/Salon-HP-8100" "qtotal=1" "txtvers=1"]
=   eth0 IPv6 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [631]
   txt = ["printer-type=0x901E" "printer-state=3" "Duplex=T" "Color=T" 
"TLS=1.2" "UUID=8a590a22-8022-31c0-7155-5d1c1f5bb656" "URF=DM3" 
"pdl=application/octet-stream,application/pdf

Bug#894664: cups: Libreoffice doesn't see my network printer

[Stefan Monnier]

> Tentatively, this looks more like a cups-browsed issue.
>
> /etc/cups/cups-browsed should have a line "BrowseRemoteProtocols dnssd cups".

Yes, I have that.

> Try uncommenting "LogDir /var/log/cups" and "DebugLogging file" and look
> at /var/log/cups/cups-browsed_log after restarting cups-browsed. Is the
> printer in there?

Yes, I attached the file below.
I guess the problem is

Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local' skipped, could not determine IP 
address.

but I don't know why.  "host server" on that same machine returns
"server.lan has address 192.168.1.2".


Stefan


Wed Apr  4 17:31:38 2018 cups-browsed: Creating http connection to local CUPS 
daemon: /var/run/cups/cups.sock:631
Wed Apr  4 17:31:38 2018 network interface at 192.168.1.112
Wed Apr  4 17:31:38 2018 network interface at 192.168.1.138
Wed Apr  4 17:31:38 2018 cups-browsed [BrowsePoll /var/run/cups/cups.sock:0]: 
IPP-Create-Subscription
Wed Apr  4 17:31:38 2018 cups-browsed [BrowsePoll /var/run/cups/cups.sock:0]: 
subscription ID=1250
Wed Apr  4 17:31:38 2018 cups-browsed (/var/run/cups/cups.sock): cupsGetDests
Wed Apr  4 17:31:38 2018 Could not determine system default printer!
Wed Apr  4 17:31:38 2018 Using signal handler SIGACTION
Wed Apr  4 17:31:38 2018 Avahi server connection got available, setting up 
service browsers.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: CACHE_EXHAUSTED
Wed Apr  4 17:31:38 2018 Avahi Browser: ALL_FOR_NOW
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: CACHE_EXHAUSTED
Wed Apr  4 17:31:38 2018 Avahi Browser: ALL_FOR_NOW
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of

Bug#894664: cups: Libreoffice doesn't see my network printer

[Stefan Monnier]

>> I have a printer connected via USB to a local server (running Debian
>> stable as well).  This printer is made visible to my clients by
>> running cups-browsed.
> For the server to advertise its printers with DNS-SD cups-browsed is
> superfluous.

I expressed myself poorly: the cups-browsed is running on the client.

> For most applications and command line programs cups-browsed has to be
> running on the client; seeing nothing at localhost:631 implies it is
> not. Please give the outputs of
>
>   systemctl status cups-browsed
>
> and
>
>   lpstat -t
>
> on the client.

% LANG=C systemctl status cups-browsed
* cups-browsed.service - Make remote CUPS printers available locally
   Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor pre
   Active: active (running) since Mon 2018-04-02 10:30:23 EDT; 21h ago
 Main PID: 5174 (cups-browsed)
Tasks: 3 (limit: 4915)
   CGroup: /system.slice/cups-browsed.service
   `-5174 /usr/sbin/cups-browsed
% LANG=C lpstat -t
scheduler is running
no system default destination
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
%

>> Yet, this somehow works: e.g. evince sees my network printer just fine.  But
>> Libreoffice doesn't.  I haven't tried all applications to figure out which do
>> and which don't, so maybe Libreoffice is not the only one affected.
>
> Evince can read the server's DNS-SD broadcasts directly; it doesn't need
> cups-browsed. Libreoffice cannot read the server's DNS-SD broadcasts
> directly.

Good to know, thanks.


Stefan

Bug#894664: cups: Libreoffice doesn't see my network printer

[Stefan Monnier]

Package: cups
Version: 2.2.1-8+deb9u1
Severity: normal

Dear Maintainer,

I have a printer connected via USB to a local server (running Debian stable as
well).  This printer is made visible to my clients by running cups-browsed.

My clients have no locally-configured printers (and hence no "default"
printer), and indeed when I go to "localhost:631" I don't see any printers
there.

Yet, this somehow works: e.g. evince sees my network printer just fine.  But
Libreoffice doesn't.  I haven't tried all applications to figure out which do
and which don't, so maybe Libreoffice is not the only one affected.

I've seen bug#867818 which seems related, but my `cups` is an older version
than the one that seems to be affected by that problem.

I've also seen bug#772097, but that one seems older than mine (back around that
time, cups-browsed would actually cause the network printer to appear in
/etc/cu0ps/printers.conf and in localhost:631 and Libreoffice could see it fine
then).



-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

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

Versions of packages cups depends on:
ii  cups-client2.2.1-8+deb9u1
ii  cups-common2.2.1-8+deb9u1
ii  cups-core-drivers  2.2.1-8+deb9u1
ii  cups-daemon2.2.1-8+deb9u1
ii  cups-filters   1.11.6-3
ii  cups-ppdc  2.2.1-8+deb9u1
ii  cups-server-common 2.2.1-8+deb9u1
ii  debconf [debconf-2.0]  1.5.61
ii  ghostscript9.20~dfsg-3.2+deb9u1
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libc-bin   2.24-11+deb9u3
ii  libc6  2.24-11+deb9u3
ii  libcups2   2.2.1-8+deb9u1
ii  libcupscgi12.2.1-8+deb9u1
ii  libcupsimage2  2.2.1-8+deb9u1
ii  libcupsmime1   2.2.1-8+deb9u1
ii  libcupsppdc1   2.2.1-8+deb9u1
ii  libgcc11:6.3.0-18+deb9u1
ii  libstdc++6 6.3.0-18+deb9u1
ii  libusb-1.0-0   2:1.0.21-1
ii  poppler-utils  0.48.0-2+deb9u2
ii  procps 2:3.3.12-3

Versions of packages cups recommends:
ii  avahi-daemon 0.6.32-2
ii  colord   1.3.3-2
ii  cups-filters [ghostscript-cups]  1.11.6-3
pn  printer-driver-gutenprint

Versions of packages cups suggests:
ii  cups-bsd   2.2.1-8+deb9u1
pn  foomatic-db-compressed-ppds | foomatic-db  
ii  hplip  3.16.11+repack0-3
ii  printer-driver-cups-pdf [cups-pdf] 2.6.1-22
ii  printer-driver-hpcups  3.16.11+repack0-3
pn  smbclient  
ii  udev   232-25+deb9u2

-- Configuration Files:
/etc/cups/cupsd.conf changed:
LogLevel warn
MaxLogSize 0
SystemGroup lpadmin
Listen localhost:631
Listen /var/run/cups/cups.sock
Browsing On
BrowseLocalProtocols dnssd
DefaultAuthType Basic
WebInterface Yes

  Order allow,deny


  Order allow,deny


  AuthType Default
  Require user @SYSTEM
  Order allow,deny


  # Job/subscription privacy...
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  # Job-related operations must be done by the owner or an administrator...
  
Order deny,allow
  
  
Require user @OWNER @SYSTEM
Order deny,allow
  
  # All administration operations require an administrator to authenticate...
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  # All printer operations require a printer operator to authenticate...
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  # Only the owner or an administrator can cancel or authenticate a job...
  
Require user @OWNER @SYSTEM
Order deny,allow
  
  
Order deny,allow
  


  # Job/subscription privacy...
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  # Job-related operations must be done by the owner or an administrator...
  
AuthType Default
Order deny,allow
  
  
AuthType Default
Require user @OWNER @SYSTEM
Order deny,allow
  
  # All administration operations require an administrator to authenticate...
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  # All printer operations require a printer operator to authenticate...
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  # Only the owner or an administrator can cancel or authenticate a job...
  
AuthType Default
Require user @OWNER @SYSTEM
Order deny,allow
  
  
Order deny,allow
  



-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, d

Bug#780606: Bug#792101: Done / Not Done

[Stefan Monnier]

> Just to be clear, this is not in Debian main, it is in contrib.

Thank you very much for that.  Happily running it on my BananaPi here now.
What is its status exactly: I see "contrib" described as "free but
depending on non-free code", but it's not clear exactly what non-free
code it relies on.

I see also that it's now in "unstable" (tho not yet in "testing",
apparently) and compiled for various architectures including the armhf
I'm using, which is great.  Until those JS packaging issues are
resolved, do you plan on keeping the package uptodate on
a regular basis?


Stefan

Bug#851819: ERROR: wget failed to download http://people.debian.org/~bartm/...

[Stefan Monnier]

I haven't seen any reaction to this.
Other than "mere users like us complaining", is there a plan?


Stef

Bug#798935: Starting dnsmasq deadlock with /etc/resolvconf/update-libc.d/squid3

[Stefan Monnier]

> On a system with systemd, dnsmasq and resolvconf installed, the
> /etc/resolvconf/update-libc.d/squid3 hook prevents dnsmasq from
> starting. As far as I can see, the problem is caused by a deadlock of
> "systemctl start dnsmasq.service" in conjunction with "systemctl
> reload squid3.service". The latter one is finally called by the
> /etc/resolvconf/update-libc.d/squid3 hook which is invoked by dnsmasq
> on startup.

Indeed, I just bumped into this problem.  I recently decided to move
from Polipo to Squid (on my home router), so I installed Squid.
Everything seemed to be dandy until I rebooted, at which point dnsmasq
failed to start, preventing access to the outside world to all other
machines.

> A possible solution might be, to check if systemd is running in the
> hook and calling
>
> systemctl --no-block reload squid3.service
>
> directly instead of
>
> invoke-rc.d squid3 reload

How 'bout just adding an & at the end of this reload line?
That's the workaround I'm using right now,


Stefan

Bug#669119: In ip-up.d if fail then try again after 3s.

[Stefan Monnier]

>   Don't know why but my PPP interface sometimes isn't working right away and
> needs some time to settle, so sometimes when ddclient runs from
> /etc/ppp/ip-up.d/ddclient it is unable to set the new IP.
>   My workaround was to add a "sleep 3" in /etc/default/ddclient.

I see the same problem here (running Debian stable on an OrangePi box).
More specifically, /etc/ppp/ip-up.d/ddclient almost never works for me,
and in that script ddclient returns the following:

WARNING:  cannot connect to www.dnsdynamic.org:80 socket: IO::Socket::INET: 
Bad hostname 'www.dnsdynamic.org'
FAILED:   updating : Could not connect to www.dnsdynamic.org.

Same with freedns.afraid.org.  I changed that file to end with

(sleep 10; /usr/sbin/ddclient -syslog -ip $PPP_LOCAL)&

and it seems to have fixed my problem, so it looks like the ip-up.d
script is run "too early" (i.e. before the DNS is properly setup).


Stefan


PS: BTW, this ddclient script is brittle.  E.g. the line

if [ ! $if = $PPP_IFACE ]; then

should be replaced with something like

if [ ! "x$if" = "x$PPP_IFACE" ]; then

Bug#810497: xwayland: There is no manpage for Xwayland

[Stefan Monnier]

Package: xwayland
Version: 2:1.17.3-2
Severity: normal

Dear Maintainer,

I see that Wayland is now used by default in Debian testing.
While trying to figure out why it happens not to work for me
(which may lead to another bug report) I found that there is
very little (if any) documentation about it.

Not even a manpage.



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

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

Versions of packages xwayland depends on:
ii  libaudit1   1:2.4.5-1
ii  libc6   2.21-6
ii  libdrm2 2.4.65-3
ii  libegl1-mesa [libegl1-x11]  11.0.8-1
ii  libepoxy0   1.3.1-1
ii  libgbm1 11.0.8-1
ii  libgcrypt20 1.6.4-4
ii  libgl1-mesa-glx [libgl1]11.0.8-1
ii  libpixman-1-0   0.33.4-1
ii  libselinux1 2.4-3
ii  libwayland-client0  1.9.0-1
ii  libxau6 1:1.0.8-1
ii  libxdmcp6   1:1.1.2-1
ii  libxfont1   1:1.5.1-1
ii  libxshmfence1   1.2-1
ii  xserver-common  2:1.17.3-2

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#805131: gnome-terminal: x-terminal-emulator fails in XFCE

[Stefan Monnier]

Package: gnome-terminal
Version: 3.18.1-1
Severity: normal

Dear Maintainer,

I use this machine both with Gnome and XFCE, depending on which user is logged
in.  My /etc/alternatives/x-terminal-emulator points to /usr/bin/gnome-
terminal.wrapper.

When I log into XFCE and try to open a terminal it fails.  The error I get when
I try to start it from the command line (e.g. inside an "xterm"):

   % x-terminal-emulator
   Error constructing proxy for
org.gnome.Terminal:/org/gnome/Terminal/Factory0: Erreur lors de l'appel de
StartServiceByName pour org.gnome.Terminal :
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process
org.gnome.Terminal exited with status 9
   %

So, it looks like gnome-terminal.wrapper is not appropriate as a global
/etc/alternatives/x-terminal-emulator since such a global setting should work
in other environments as well.
IOW either gnome-terminal.wrapper needs to be fixed to work in other
environments, or it should not be used for etc/alternatives/x-terminal-
emulator.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'stable'), (10, 'unstable')
Architecture: i386 (x86_64)

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

Versions of packages gnome-terminal depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gconf-service3.2.6-3
ii  gnome-terminal-data  3.18.1-1
ii  gsettings-desktop-schemas3.18.1-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo-gobject21.14.4-1
ii  libcairo21.14.4-1
ii  libdconf10.24.0-2
ii  libgconf-2-4 3.2.6-3
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libglib2.0-0 2.46.1-2
ii  libgtk-3-0   3.18.2-1
ii  libnautilus-extension1a  3.18.1-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libuuid1 2.27.1-1
ii  libvte-2.91-00.42.1-1
ii  libx11-6 2:1.6.3-1

Versions of packages gnome-terminal recommends:
ii  dbus-x11  1.10.2-1
ii  gvfs  1.26.1.1-1
ii  yelp  3.16.1-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#803303: general: Standardized troubleshooting

[Stefan Monnier]

Package: general
Severity: wishlist

Dear Maintainer,

I've been using Debian on all my machines for many years and am generally very
happy with it but I recently realized that my experience could have been even
better (both for me and for the maintainers of all the packages I use) if it
were easier to figure out how to troubleshoot problems.

Concrete suggestion: add a "TROUBLESHOOTING" section in the manpage of every
program, explaining how to get more info about what's going on when the program
doesn't do what the user wants.

I've often gone through steps like:
1- Program Foo crashes/hangs/misbehaves/younameit when I do something.
2- Search the web to see if someone else bumped into the same problem and found
a fix for it.
3- No luck, so I report the bug to Debian or to the upstream.
4- Someone gets back to me telling me to set env-var FOO_DEBUG=99 then re-run
the program and show her what is reported in file .foo_debug_log.

My suggestion is to try and skip step 3 and 4, replacing them with "man foo;
then look for the TROUBLESHOOTING section".  Usually this troubleshooting info
can be found somewhere, but every program puts it at a different place, making
it difficult to find.

Furthermore, the troubleshooting info needed may go further than the program
itself, e.g. when the program is not started from the command line but via some
other mechanism (inetd, systemd, gnome-shell, ...).

In the longer run, it would be even better to try and standardize not just the
place where the troubleshooting info is located, but the way troubleshooting is
done (e.g. always provide a "--troubleshoot" command-line flag which always
gives the output at "the same place"), so that I could for example do
"systemctl troubleshoot gdm3" and systemd would know how to start gdm3 in order
to get debugging info.

But a good first step seems to be to start collecting the troubleshooting info
at a standardized place (e.g. the manpage).
Of course if you prefer putting that info in
/usr/share/doc//TROUBLESHOOTING, that's fine as well.  As long as it's
always the same place.



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

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

Bug#803217: apt-get update while network is down throws away all the old data

[Stefan Monnier]

Package: apt
Version: 1.0.10.2
Severity: normal

Dear Maintainer,

If I run "apt-get update" (or "aptitude update") when the network is down (or
the proxy is unavailable), APT forgets everything instead of keeping using the
old data.

E.g. if I "Disconnect" the netowrk and run the following command:

(export LANG=C; aptitude show emacs; apt-get update; aptitude show emacs)

I get something like:

Package: emacs
New: yes
State: not installed
Version: 46.1
Priority: optional
Section: editors
Maintainer: Rob Browning 
Architecture: all
Uncompressed Size: 25.6 k
Depends: emacs24 | emacs24-lucid | emacs24-nox
Description: GNU Emacs editor (metapackage)
 GNU Emacs is the extensible self-documenting text editor. This is a
metapackage
 that will always depend on the latest recommended Emacs release.

Tags: devel::editor, role::dummy, role::metapackage, suite::emacs,
suite::gnu,
  use::editing

Ign http://ftp.ca.debian.org stable InRelease
[...]
Err http://security.debian.org stable/updates Release.gpg
  Something wicked happened resolving 'server:8123' (-5 - No address
associated with hostname)
[...]
Err http://ftp.ca.debian.org unstable/contrib i386 Packages
  Something wicked happened resolving 'server:8123' (-5 - No address
associated with hostname)
W: Failed to fetch http://ftp.ca.debian.org/debian/dists/stable/Release.gpg
Something wicked happened resolving 'server:8123' (-5 - No address associated
with hostname)
[...]
W: Failed to fetch
http://ftp.ca.debian.org/debian/dists/unstable/contrib/binary-i386/Packages
Something wicked happened resolving 'server:8123' (-5 - No address associated
with hostname)

E: Some index files failed to download. They have been ignored, or old ones
used instead.
E: The value 'testing' is invalid for APT::Default-Release as such a
release is not available in the sources
E: The value 'testing' is invalid for APT::Default-Release as such a
release is not available in the sources

Notice how the first "aptitude show" happily described the "emacs" package
before the update and couldn't do it any more after the update.  Instead I get
some bogus complaint about "testing" being an invalid setting for APT::Default-
Release.



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "i386";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-amd64$";
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:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Never-MarkAuto-Sections:: "oldlibs";
APT::Never-MarkAuto-Sections:: "restricted/oldlibs";
APT::Never-MarkAuto-Sections:: "universe/oldlibs";
APT::Never-MarkAuto-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "[ ! -f /var/run/dbus/system_bus_socket ] || 
/usr/bin/dbus-send --system --dest=org.debian.apt --type=signal /org/debian/apt 
org.debian.apt.CacheChanged || true";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --o

Bug#786989: xbmc: Eject/Load fails to eject my DVD

[Stefan Monnier]

>> Have you tried the solution from #709117?
> I already have dev.cdrom.lock=0 in my sysctl, yes.
> Also, I don't see anything like

>19:33:17 T:140173220951968   DEBUG: ExecuteXBMCAction : Translating 
> EjectTray()
>19:33:17 T:140173220951968   DEBUG: ExecuteXBMCAction : To EjectTray()

> in my log.  It seems XBMC is not even trying to eject the disc.

I found in http://forum.kodi.tv/showthread.php?tid=227908
a solution to this problem that worked for me: I basically had to remove
"--lock-media" from udev's 60-cdrom_id.rules.

I don't know if it qualifies as a real fix, or is just a workaround, but
hopefully it will be enough for someone else to figure out what is the
right fix.


Stefan


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

Bug#786989: xbmc: Eject/Load fails to eject my DVD

[Stefan Monnier]

> Have you tried the solution from #709117?

I already have dev.cdrom.lock=0 in my sysctl, yes.
Also, I don't see anything like

   19:33:17 T:140173220951968   DEBUG: ExecuteXBMCAction : Translating 
EjectTray()
   19:33:17 T:140173220951968   DEBUG: ExecuteXBMCAction : To EjectTray()

in my log.  It seems XBMC is not even trying to eject the disc.


Stefan


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

Bug#758902: systemd: Please make ^C interrupt systemd-fsck

[Stefan Monnier]

> http://cgit.freedesktop.org/systemd/systemd/tree/TODO?id=HEAD#n562

This points to line-number 562 in a long TODO list.  Of course, the item
at that line number is unrelated to this bug-report (tho I presume it
was related back when this reply was sent).

I think this is a very nasty regression that will hit relatively few
people but will really piss them off.

But I don't think we should focus exclusively on fsck: C-c should be
usable also to interrupt a "waiting for device to appear" or "waiting
for the network to come up".  So, basically, I think that any thingy
which takes more than N second to complete should be interruptible via
C-c (potentially with a prompt to confirm that the user really intended
to interrupt this operation).

In my experience, systemd has introduced various different *new* ways in
which the boot can get stuck in some long-running "operation" (which
might just be waiting for a timeout).  If we don't want to alienate
users, we should raise the severity of this bug (and broaden its scope).


Stefan


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

Bug#771832: xserver-xorg-video-modesetting: left or right rotation gives blank screen with gma500 card

[Stefan Monnier]

Package: xserver-xorg-video-modesetting
Version: 0.9.0-1+b1
Severity: normal

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 ***

The quoted xorg.conf file below is the one I've been using for a few
years now with a gma500 card for the first screen and a displaylink card
for the second.  Both rotated.

I'm trying to use the "modesetting" driver instead so as to be able to use
hotplugging of the displaylink, but the rotation does not work.

I start I used an empty xorg.conf (a symlink to /dev/null), the Xorg
server startyed fine.  Then I used xrandr and saw that "DVI-0" is
the name used for my monitor, so I tried

  xrandr --output DVI-0 --rotate left; sleep 10; xrandr --output DVI-0 --rotate 
normal;

and the screen went blank (not just black: the monitor went to sleep)
for 10 seconds and then came back.

This is with the stock Debian 3.16.0-4-686-pae kernel.  There was no dmesg
output during the rotation.


Stefan


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Mar 16  2007 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2556784 Nov  3 16:52 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation System Controller 
Hub (SCH Poulsbo) Graphics Controller [8086:8108] (rev 07)

Xorg X server configuration file status:

lrwxrwxrwx 1 root root 16 Dec  2 11:56 /etc/X11/xorg.conf -> xorg.conf.dualfb

Contents of /etc/X11/xorg.conf:
---
### DisplayLink Stuff ###

Section "Device"
Identifier  "DisplayLinkDevice"
driver  "fbdev"
#driver  "displaylink"
Option  "fbdev" "/dev/fb1"
# Hack to get fbdev to accept several devices.
# http://lists.freedesktop.org/archives/libdlo/2010-November/000791.html
BusID   "USB"
Option  "Rotate""CCW"
EndSection

Section "Monitor"
Identifier "DisplayLinkMonitor"
EndSection

Section "Screen"
Identifier "DisplayLinkScreen"
Device "DisplayLinkDevice"
Monitor "DisplayLinkMonitor"
SubSection "Display"
Depth 16 # 24bit works fine but for USB 2.0 a lot of data
#Modes "1280x1024"
EndSubSection
EndSection

 Original Video Settings ###

Section "Device"
Identifier  "Configured Video Device"
driver  "fbdev"
Option  "fbdev" "/dev/fb0"
# Hack to get fbdev to accept several devices.
# http://lists.freedesktop.org/archives/libdlo/2010-November/000791.html
BusID   "USB"
Option  "Rotate" "CCW"
EndSection

Section "Monitor"
Identifier  "Configured Monitor"
# Doesn't seem to work.
#Option "Rotate""left"
EndSection

Section "Screen"
Identifier  "DefaultScreen"
Monitor "Configured Monitor"
Device  "Configured Video Device"
EndSection

Section "ServerLayout"
Identifier "Server Layout"
Screen 0 "DefaultScreen" 0 0
Screen 1 "DisplayLinkScreen" RightOf "DefaultScreen"
Option "Xinerama" "on"
EndSection

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 3.16.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 225345 Nov 16  2007 /var/log/Xorg.22.log
-rw-r--r-- 1 root root 138823 Nov 16  2007 /var/log/Xorg.23.log
-rw-r--r-- 1 root root  40062 Nov 16  2007 /var/log/Xorg.24.log
-rw-r--r-- 1 root root   2485 Apr 13  2010 /var/log/Xorg.3.log
-rw-r--r-- 1 root root  52283 Apr 13  2010 /var/log/Xorg.1.7.6.log
-rw-r--r-- 1 root root  14860 Oct 21  2010 /var/log/Xorg.21.log
-rw-r--r-- 1 root root  15503 Oct 21  2010 /var/log/Xorg.20.log
-rw-r--r-- 1 root root  24851 May 29  2013 /var/log/Xorg.2.log
-rw-r--r-- 1 root root  15996 Dec  2 11:29 /var/log/Xorg.1.log
-rw-r--r-- 1 root root  22098 Dec  2 12:02 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[26.429] 
X.Org X Server 1.16.1.901 (1.16.2 RC 1)
Release Date: 2014-11-02
[26.429] X Protocol Version 11, Revision 0
[26.429] Build Operating System: Linux 3.2.0-4-amd64

Bug#766397: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stefan Monnier]

> Is there anything that uses imap.el?  I thought it was obsolete...

Should we move it to lisp/obsolete, then?


Stefan


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

Bug#766397: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stefan Monnier]

> [When possible, please preserve the -forwarded address in any replies.]
> The following issue was just reported against emacs23 in Debian, and
> from a quick glance, it looks like 24.4 still uses s_client, so if this
> is a problem, it's perhaps still relevant.

AFAIK, nowadays Emacs only use s_client if it was not linked against
libgnutls (and it can use gnutls-cli instead as well, tho I don't know
which of s_client or gnutls-cli is given preference if both are found).


Stefan


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

Bug#699325: bug#8705: Emacs 24.3 occasionally crashes (segfault) just after starting it

[Stefan Monnier]

> fixed in Emacs trunk bzr 111064; see Bug#13054 .
> This fix is in the next Emacs release, and the fix should be easily

Hmm... if it's in trunk it's not going to be in 24.4, so not in the next
release, right?


Stefan


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

Bug#732029: bug#18670: Bug#732029: emacs24: abort during normal usage

[Stefan Monnier]

> [If possible, please preserve the -forwarded address in any replies.]
> This 24.3 crash was reported to Debian:

>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732029

> I thought I'd pass it on for a look, though I'm not sure there's enough
> information for diagnosis.

Indeed, there's not enough info to figure out what happened.


Stefan


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

Bug#759400: bug#18392: Bug#759400: emacs24-nox: segfault when saving emacs lisp file

[Stefan Monnier]

> It appears that Emacs 24.3 is crashing on Debian mipsel, though it's not
> clear whether it's an Emacs problem, a toolchain issue, or something
> else.

Could you check whether the same problem shows up for the 24.4 pretest
(i.e. 24.3.93)?  Also, worthwhile would be to test to see if building
with different optimization settings changes the result.

I do have a mispel machine here, but its 64MB of RAM make it rather
painful to build Emacs (and I don't have a Debian install on it any
more, only OpenWRT).


Stefan


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

Bug#755351: bug#18372: Bug#755351: blink-cursor-mode should respect GTK+ setting by default

[Stefan Monnier]

 In the GTK+ version of Emacs, the default setting for
 blink-cursor-mode should respect the desktop setting of
 org.gnome.desktop.interface.cursor-blink .  An explicit setting of
 blink-cursor-mode in .emacs could still override it, but the default
 setting should not.
>> That would make a lot of sense, indeed.

> How do you distinguish between the default and

> % emacs
> M-x blink-cursor-mode
> M-x blink-cursor-mode

> ?

> The latter is an explicit setting to on.

No, AFAICT it's just asking to toggle it twice.


Stefan


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

Bug#755351: bug#18372: Bug#755351: blink-cursor-mode should respect GTK+ setting by default

[Stefan Monnier]

> Why should we only take blink-cursor-mode from there, and ignore all
> the rest?

Nobody asked to ignore the rest ;-)

> E.g., cursor-blink-time and cursor-blink-timeout.  And then
> there are other settings, like cursor-size, clock-format, etc.  It
> makes very little sense to take only one setting.

Currently we only take a few things such as foreground and
background color.  I agree that we should take "anything that's
applicable".


Stefan


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

Bug#755351: bug#18372: Bug#755351: blink-cursor-mode should respect GTK+ setting by default

[Stefan Monnier]

>> In the GTK+ version of Emacs, the default setting for
>> blink-cursor-mode should respect the desktop setting of
>> org.gnome.desktop.interface.cursor-blink .  An explicit setting of
>> blink-cursor-mode in .emacs could still override it, but the default
>> setting should not.

That would make a lot of sense, indeed.


Stefan


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

Bug#756903: systemd: Boot hangs if filesystems unavailable

[Stefan Monnier]

> Exactly.  I hope the reasoning behind current defaults has been explained
> adequately.

Not sure what you mean by "adequately".  I understand your argument, but
I disagree with it.  Do you understand my argument?

> That said, it would be great to improve reporting if something like this
> happens.  Hopefully with #755581 fixed, emergency mode will be entered
> successfully.

Makes no difference to the case where you're not sitting at the console.
The way I see it, this case is very common.


Stefan


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

Bug#756903: systemd: Boot hangs if filesystems unavailable

[Stefan Monnier]

> Yes, you can configure such behaviour.

I already have plenty of ways to configure the behavior I need.
This discussion is about the default behavior.


Stefan


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

Bug#756903: systemd: Boot hangs if filesystems unavailable

[Stefan Monnier]

>> In which way is it "safe and correct" to interrupt the boot in this case?
> In the way that missing some mounts may indicate a serious problem and
> could lead to incorrect behaviour or data loss.

Haven't heard many complaints about that over the years, so it shouldn't
be a super-top-priority goal, I think.

In any case, that's not incompatible with the desire to "boot enough for
remote maintenance to be possible".

> stopped when something important fails. You can configure things
> otherwise, but the default is to strictly obey dependencies.

To get the best of both worlds, I suggest that if a problem happens
during boot, systemd doesn't just interrupt the boot, but instead tries
to keep booting up to a "fallback/safe" state, so that maintenance can be
done conveniently over the network, instead of having to be done "on
console" which is all too often completely unworkable.


Stefan


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

Bug#756903: systemd: Boot hangs if filesystems unavailable

[Stefan Monnier]

>> - If a mount fails, keep on booting.  And then do your best to try and
>> bring this problem to the attention of someone (mentioning the
>> "nofail" option in that same message).  Only stop the boot if the
>> partition is explicitly marked as "critical" or "stoponfail".
> Well, 'fail', which is the default, means just that.

Not sure what "that" means here.  Does your "that" mean "that which you
just described" or does it mean "fail"?

> Systemd tries to do the corrent and safe thing by default.

I'd hope so, but here's my case:
- a machine somewhat far away with an old and unimportant fstab entry
  that refers to a drive that's rarely connected.
- after upgrading to systemd, the fstab entry caused systemd to stop the
  boot (presumably asking for the operator to do something on console).
- with the boot stopped, I (the operator who is not on console, since
  it's a remote machine), I can't fix the fstab entry.

In which way is it "safe and correct" to interrupt the boot in this case?

I can understand that making the mount wait (rather than just fail
right away) might be made necessary by the fact that systemd changes the
order in which operations are performed.  I.e. I understand why the
change nb 1 might be needed.

But that doesn't explain why change number 2 was needed.
Apparently you think Michael's response explains it, but I failed to
see how.


Stefan


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

Bug#757480: texlive-latex-recommended: seminar requires pstricks

[Stefan Monnier]

>> \RequirePackage{pst-ovl}
> Indeed. But since seminar is just one package, and we don't want to
> pull in unconditionally texlive-pstricks into texlive-latex-recommended,
> I made it a "suggests".

I'm not sure I understand.  AFAICT, `seminar' is 100% unusable without
texlive-pstricks, so if you don't want to add a hard dependency on
texlive-pstricks, it seems more sensible to move seminar out of
texlive-latex-recommended.
Or is the content of texlive-latex-recommended determined by "external forces"?


Stefan


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

Bug#756903: systemd: Boot hangs if filesystems unavailable

[Stefan Monnier]

> Well, I consider the sysvinit behaviour buggy and unfortunately this
> lead to broken fstab configurations in the past.

There are 2 changes here:
1- systemd seems to *wait* for the device to be available, whereas the
   old scripts just failed right away if the device was absent.
2- if the mount fails, this is considered by default as a fatal error.

Which of those 2 was "buggy" in sysvinit?  The lack of wait or the fact
that it moved on upon failure?

I like the idea of mounting/fscking partitions without blocking other
unrelated boot steps, so I'm OK with adding boot options to help systemd
do a better job, but blocking the boot just because some random fstab
entry has an error is really obnoxious (it took me a while to fix my
machine after installing systemd-sysv because of such an fstab entry
referring to a disk that was not connected.  Thank god there is
"break=mount"!).

Here are my suggestions:
- In the absence of an explicit request to "bootwait", systemd should
  not wait for a device to appear, or at least not anywhere near 90s,
  especially if it is holding back the whole rest of the boot process.
- If a mount fails, keep on booting.  And then do your best to try and
  bring this problem to the attention of someone (mentioning the
  "nofail" option in that same message).  Only stop the boot if the
  partition is explicitly marked as "critical" or "stoponfail".

The second part is really important, because in 99.9% of the cases, it's
much better to keep on booting, even if the resulting system won't be
fully functional: it's likely to be a lot easier to fix the problem with
a "half booted" machine than a "not booted" one.

E.g. If the /home partition is missing, the machine might be largely
unusable, but I should usually still be able to log into it remotely,
fix up the partition or fstab entry, and reboot.  But with the current
"stop on fail" behavior, I don't get such a chance.


Stefan


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

Bug#757480: texlive-latex-recommended: seminar requires pstricks

[Stefan Monnier]

Package: texlive-latex-recommended
Version: 2014.20140717-01
Severity: normal

Dear Maintainer,

If you install . but no texlive-pstricks, and then try to run pdflatex on a
file that starts with

\documentclass[display,semhelv]{seminar}

pdflatex stops right away with:

   (./slides.tex (/usr/share/texlive/texmf-dist/tex/latex/seminar/seminar.cls
   Document Class: seminar 2014/01/17, 1.61
   Documentclass: `seminar' v1.61 <2014/01/17> (tvz,hv)

   ! LaTeX Error: File `pst-ovl.sty' not found.

And indeed seminar requires the pst-ovl package:

   % grep pst-ovl /usr/share/texlive/texmf-dist/tex/latex/seminar/seminar.cls
   \RequirePackage{pst-ovl}
   \RequirePackage{pst-ovl}%hv 20131224
   %

Yet pst-ovl is provided by texlive-pstricks which is not installed as a
dependency of texlive-latex-recommended.



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

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

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

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

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

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

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

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

or 

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

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1175 Aug  8 12:06 /var/lib/texmf/ls-R
-rw-rw-r-- 1 root staff 80 Oct  8  2012 /usr/local/share/texmf/ls-R
lrwxrwxrwx 1 root root 29 May 30 05:00 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jul 16 12:29 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jul 16 12:29 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
-rw-r--r-- 1 root root 80 Apr 16 10:32 /usr/share/texlive/texmf/ls-R
##
 Config files
-rw-r--r-- 1 root root 475 Jun 13 14:20 /etc/texmf/web2c/texmf.cnf
-rw-r--r-- 1 root root 4970 Aug  8 12:06 /var/lib/texmf/web2c/fmtutil.cnf
lrwxrwxrwx 1 root root 32 Jul 16 12:29 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 8269 Aug  8 12:06 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jun 15  2013 mktex.cnf
-rw-r--r-- 1 root root 475 Jun 13 14:20 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-recommended depends on:
ii  dpkg1.17.10
ii  tex-common  5.02
ii  texlive-base2014.20140717-01
ii  texlive-binaries2014.20140528.34243-5
ii  texlive-latex-base  2014.20140717-01

Versions of packages texlive-latex-recommended recommends:
pn  prosper
pn  texlive-latex-recommended-doc  

texlive-latex-recommended suggests no packages.

Versions of packages tex-common depends on:
ii  debconf [debconf-2.0]  1.5.53
ii  dpkg   1.17.10
ii  ucf3.0030

Versions of packages tex-common suggests:
ii  debhelper  9.20140613

Versions of packages texlive-latex-recommended is related to:
ii  tex-common5.02
ii  texlive-binaries  2014.20140528.34243-5

-- debconf information:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:


-- 
To UN

Bug#651506: gnome-shell: screen becomes glitched when attempting to unlock

[Stefan Monnier]

> Control: tag -1 + moreinfo
> Hi,

I can't remember seeing this problem recently, so maybe it's OK now.

It's not like I could reproduce it on demand, tho,


Stefan


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

Bug#618471: uswsusp: continue_without_swp even though my swap is valid and active

[Stefan Monnier]

> If the problem continues with the new version, can you try if the
> problem happends:

I've fixed it locally years ago with the patch I sent.
Haven't seen the problem since,


Stefan


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

Bug#381516: emacsen-common: Rather emacs-package-install should not fail upon byte-compilation error

[Stefan Monnier]

> But even if Emacs guarantees that, we still have to have some way for
> emacsen-common to know that's the situation.

To the extent that neither aptitude nor dpkg offers a way for the user
to use something like a --force flag to ignore the problems, signaling
an error there should be limited to the utmost terrible cases where the
world is about to end.

Even in the very unlikely case that the package is somehow faulty,
I *much* prefer being able to install it, discover that it's faulty and
then remove it, then being left in the dark and told "sorry, we're not
100% sure that it will always work, so you can't even try using it".
Especially since the "100% sure" is not even true.  There can be plenty
of other errors which don't prevent installation but prevent use.

I used the word "mean" before to describe the behavior, but the word
I wanted to use was "obnoxious".


Stefan


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

Bug#381516: emacsen-common: Rather emacs-package-install should not fail upon byte-compilation error

[Stefan Monnier]

> But even if Emacs guarantees that, we still have to have some way for
> emacsen-common to know that's the situation.

Emacs doesn't guarantee anything.  But we know that's the situation
because it always is.


Stfean


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

Bug#381516: emacsen-common: Rather emacs-package-install should not fail upon byte-compilation error

[Stefan Monnier]

> Yes, but I don't see how emacsen-common could know that, and as far as I
> understand things, a successful exit from a dpkg run is supposed to
> indicate that everything's fine.

And as a general, rule when Elisp's byte-compilation signals an error,
everything is still fine.


Stefan


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

Bug#381516: emacsen-common: Rather emacs-package-install should not fail upon byte-compilation error

[Stefan Monnier]

> i.e. if an add-on package doesn't work with a given older emacs, then
> that package should add appropriate guards, and if an add-on package

This is not about a package not working with some older Emacs version.

It's about failure of *installation*, more specifically a failure which is
a pain in the rear to circumvent.  In all cases I've ever seen, the
package is still perfectly usable after circumventing this
installation problem.

And even if that package doesn't work with emacs19, who cares?
I should still be able to install it, in case I want to use it with emacs23.
A warning/message about the problem is fine, but an error that prevents
aptitude from doing its job is really mean.


Stefan


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

Bug#730059: busybox-syslogd conflicts with systemd

[Stefan Monnier]

Package: busybox-syslogd
Severity: normal

Dear Maintainer,

As stated in the subject, systemd and busybox-syslogd are in conflict
(via klogd, IIUC).  I'm not completely uptodate on systemd, but AFAIK
it does not provide syslogd functionality, so I'd like to keep running
busybox-syslogd alongside systemd.


Stefan

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

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

Versions of packages busybox-syslogd depends on:
ii  busybox  1:1.20.0-9

busybox-syslogd recommends no packages.

busybox-syslogd suggests no packages.


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