Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

I'm going to need a spot of help with this.

I have Chromium running under GDB, with surprisingly low overhead (I can
browse like normal if I drop the --single-process flag). As far as I
could find, the "trap invalid opcode" error reported in syslog is
synonymous with a SIGILL, so I set "handle SIGILL stop pass".
Unfortunately, the trap errors continue to occur without GDB stopping
execution.

Do you know how to set this up to get to a backtrace? Maybe a way of
disabling the signal/crash handler?

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

On Fri, 2024 May 31 21:49-04:00, Andres Salomon wrote:
> Oh! Apparently my info is outdated. According to 
> , this was fixed back in August. It does 
> indeed look like
>  
> has the dbgsym packages for .141.

Thanks for the pointer. I did not know about debian-security-debug, as
the Debian wiki pages make no mention of it.

I've installed .141 and the dbgsym package, and confirmed that at
least the tab crash still occurs. Will try to get some useful
telemetry out of this.


--Daniel

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

On Fri, 2024 May 31 18:36-04:00, Andres Salomon wrote:
>
> I'm going from memory here, but I believe the dak installation on 
> security.debian.org doesn't keep dbgsym packages for historical reasons. 
> Thus, they're only available once chromium gets moved to 
> stable-proposed-updates. https://tracker.debian.org/pkg/chromium shows 
> .60 as being the last one in stable-p-u. At some point in the next week 
> or two, someone from the release team will likely accept the newer 
> chromium packages into stable-p-u, at which point the dbgsym packages 
> for .141 (or whatever the latest version is) will be available.

Eeegh, not a great state of affairs for a package that revs this often.

> It sucks, but it is what it is. You could either spend a bunch of time 
> building chromium for the dbgsym packages, or I could put my local build 
> of .141 online w/ dbgsym packages for you to try out (assuming amd64?), 
> or you could downgrade to .60 and use those dbgsym packages.

If it's not too much trouble to put up that .141 package (and the
problem still persists in that version), I'll gladly make use of it.

> Yes, just running 'chromium -g' will launch it inside gdb; you may have 
> to manually type 'run' to start it inside gdb, I forget.  But then 
> you'll get a backtrace (or you can ctrl-c and run 'bt', if it's a 
> deadlock or something). I haven't bothered w/ core dumps of chromium 
> before, so I can't speak to that.

Understood. The system in question is a bit tight on memory, so
hopefully it won't fall over with Chromium under GDB.


--Daniel

Bug#1072317: Redundant build when making packed_resources

[Daniel Richard G.]

Package: chromium
Version: 125.0.6422.141-1
Severity: minor

This is something I've noticed in the course of the build that has been
annoying me for some time, and I thought I'd write it up.

Here is an excerpt from the build log which illustrates the problem:

[...]
[61738/61742] AR obj/content/web_test/libweb_test_renderer.a
[61739/61742] AR obj/content/web_test/libweb_test_browser.a
[61740/61742] AR obj/content/shell/libcontent_shell_app.a
[61741/61742] LINK ./content_shell
[61742/61742] LINK ./chrome
cp out/Release/chrome out/Release/chromium
cp out/Release/content_shell out/Release/chromium-shell
[...]
   debian/rules override_dh_auto_build-indep
make[1]: Entering directory '/tmp/chromium-125.0.6422.141'
gn gen out/Release --args="clang_use_chrome_plugins=false ..."
Done. Made 20173 targets from 3449 files in 10398ms
ninja -j8 -C out/Release packed_resources
ninja: Entering directory `out/Release'
[1/30013] CXX 
obj/base/allocator/partition_allocator/src/partition_alloc/allocator_base/file_util_posix.o
[2/30013] CXX 
obj/base/allocator/partition_allocator/src/partition_alloc/allocator_base/time_override.o
[3/30013] CXX 
obj/base/allocator/partition_allocator/src/partition_alloc/allocator_base/stack_trace_linux.o
[...]

It's not clear why, but the "gn gen" operation in the
override_dh_auto_build-indep target renders a significant chunk of the
existing build tree stale, and the packed_resources build then has to
recompile a bunch of things that are distant dependencies of the
requested resource files.

I can't say at what version this started happening, but I do seem to
recall at one point the packed_resources build needing only a three-
digit number of steps.

Would it be reasonable to do something like

 override_dh_auto_build-indep:
-gn gen out/Release --args="$(defines)"
+test -f out/Release/build.ninja || gn gen out/Release 
--args="$(defines)"
 ninja -j$(njobs) -C out/Release packed_resources

so that it doesn't run "gn gen" again, if not necessary?


--Daniel

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

Sigh, spoke too soon.

Chromium still crashes in both modes (tab and browser) even without
Firefox running, but much less frequently. I had a good half-hour
without crashes after closing Firefox, enough to lead me to think that
was the cause.

At this point, we're probably better off waiting to see if .141
still has the issue. But is there a reason why that -dbgsym package
isn't there?


--Daniel

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

I believe I've found a correlation: The crashes seem to have started
with an instance of firefox-esr (115.11.0esr-1~deb12u1) that I was
running on the side, since earlier today. Once I closed Firefox, the
crashiness went away, completely.

(This is on the same laptop that needs --use-gl=egl to avoid visual
artifacts, so that might have something to do with this)

On Fri, 2024 May 31 15:27-04:00, Andres Salomon wrote:
>
> Interesting. Any chance of a backtrace (with the chromium-dbgsym 
> package)? I'm wondering if some (bundled) third party lib has started 
> requiring newer cpu extensions or something.

I'm happy to provide this, but two questions:

1. In http://debug.mirrors.debian.org/debian-debug/pool/main/c/chromium/
   as well as https://deb.debian.org/debian-debug/pool/main/c/chromium/,
   I don't see any packages with a matching version string of
   "125.0.6422.112-1~deb12u1" (and .141 isn't there yet). Am I missing
   something?

2. To get the stack trace, is the right way just running the whole
   thing in GDB, using "chromium -g"? Or do you set it up to make a
   core dump? (Sure would be nice to have an Apport-like after-the-fact
   workflow for this)


--Daniel

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

Package: chromium
Version: 125.0.6422.112-1~deb12u1
Severity: important

Recently, I have been observing crashes of individual tabs, and even
of the entire browser, when navigating some Web pages. The crashed
tabs correlate with the following syslog messages (multiple instances
listed below):

2024-05-31T12:42:35.334876-04:00 runabout kernel: [1324259.940186] traps: 
Compositor[125485] trap invalid opcode ip:55a9cc8c18cd sp:7ff9a0ded490 error:0 
in chromium[55a9c7e22000+b13d000]
2024-05-31T12:57:20.174268-04:00 runabout kernel: [1325144.782743] traps: 
Compositor[125761] trap invalid opcode ip:55a9cc8c18cd sp:7ff9a0ded1e0 error:0 
in chromium[55a9c7e22000+b13d000]
2024-05-31T13:24:20.059327-04:00 runabout kernel: [1326764.664063] traps: 
Compositor[126515] trap invalid opcode ip:55daaca498cd sp:7f9f6c1ed1e0 error:0 
in chromium[55daa7faa000+b13d000]
2024-05-31T13:55:26.767783-04:00 runabout kernel: [1328631.258090] traps: 
Compositor[126307] trap invalid opcode ip:55daaca498cd sp:7f9f6c1ecfb0 error:0 
in chromium[55daa7faa000+b13d000]

The whole-browser crash occurs with no unusual messages to syslog or
~/.xsession-errors, strangely enough.

And even stranger, only today (May 31) have I started observing these
crashes. This particular version has been installed and running fine
since May 23, and now it's crashing left and right. /var/log/dpkg.log
shows no new package installs since the 25th, and I haven't futzed with
any configurations for at least that long.

Since the error relates to an invalid opcode, I'll include some details
about the CPU:

vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 CPU T7200  @ 2.00GHz
stepping: 6
microcode   : 0xc7
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow dtherm


--Daniel

Bug#1071556: Acknowledgement (Dvorak keymap not loaded after login)

[Daniel Richard G.]

I've reported this issue to the upstream project at

https://github.com/neutrinolabs/xrdp/issues/3081

Ubuntu's version 0.9.24-4 in 24.04/noble is likewise affected.

Bug#1071556: Dvorak keymap not loaded after login

[Daniel Richard G.]

Package: xrdp
Version: 0.9.24-5
Severity: important

Recently, I have noticed that logging in via a recent version of xrdp,
while using the Dvorak layout on the client, yields a QWERTY layout in
the remote framebuffer after getting past the login dialog. This is
incorrect behavior and has never happened before.

After some digging, I tracked the problem down to this:

https://bugs.debian.org/1063725

It is no longer possible to refer to the Dvorak layout as just "dvorak"
(as when one would run "setxkbmap dvorak"); one must now use either
"us dvorak" or "us(dvorak)". The below edit fixes the issue and allows
me the proper keymap after logging in:

--- /etc/xrdp/xrdp_keyboard.ini.orig
+++ /etc/xrdp/xrdp_keyboard.ini
@@ -86,7 +86,7 @@
 ;  = 
 [default_layouts_map]
 rdp_layout_us=us
-rdp_layout_us_dvorak=dvorak
+rdp_layout_us_dvorak=us(dvorak)
 rdp_layout_us_dvp=us(dvp)
 rdp_layout_dk=dk
 rdp_layout_de=de
@@ -125,7 +125,7 @@
 
 [rdp_layouts_map_mac]
 rdp_layout_us=us
-rdp_layout_us_dvorak=dvorak
+rdp_layout_us_dvorak=us(dvorak)
 rdp_layout_us_dvp=us(dvp)
 rdp_layout_dk=dk
 rdp_layout_de=de


--Daniel

Bug#1070671: Please include static library builds in libharfbuzz-dev

[Daniel Richard G.]

Package: libharfbuzz-dev
Version: 8.3.0-2+b1

It is customary for -dev packages to provide static archive libraries in
addition to the bare .so files for shared-library linking. The current
version of libharfbuzz-dev only provides the latter, and thus does not
allow applications to statically link the libraries.

I understand that GObject introspection requires a shared-library build,
but this functionality is often not needed. In particular, the Chromium
browser consumes harfbuzz and harfbuzz-subset, and does perfectly well
without introspection support. I recently ran into a situation on the
Ubuntu side of things where the lack of a static-linking option caused
some difficulty in supporting Chromium on 22.04/jammy:

https://bugs.launchpad.net/bugs/2064821

My solution was to produce a modified harfbuzz package that provides
(only) static libraries:


https://launchpad.net/~xtradeb/+archive/ubuntu/deps/+sourcepub/16120809/+listing-archive-extra

Needless to say, it would be preferable if the official packages
supported static linking from the get-go.

Bug#1070669: Please include a static library build in libdav1d-dev

[Daniel Richard G.]

Package: libdav1d-dev
Version: 1.4.1-1

It is customary for -dev packages to provide a static archive library in
addition to the bare .so file for shared-library linking. The current
version of libdav1d-dev only provides the latter, and thus does not
allow applications to statically link the library.

Bug#1068161: Video playback regression

[Daniel Richard G.]

Hi Andres,

On Tue, 2024 Apr 30 02:42-04:00, Andres Salomon wrote:
> Please let me know if this is still broken with chromium 124.

I'm happy to report that the issue appears to be resolved in the current
124.0.6367.78-1~deb12u1. (I did not test 124.0.6367.60.)

Some additional info that I meant to send in earlier:

* I was able to work around the problem in 123 with "--use-gl=egl".
  Even now, with 124, I get "MESA: error: Out of instructions"
  messages on the terminal when this flag is removed (but video now
  works either way).

* The video adapter is listed as a "VGA compatible controller [0300]:
  Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated
  Graphics Controller [8086:27a2]", on a Lenovo ThinkPad.

* This is a different and much older bug, but I've observed that some
  Web sites show visual artifacts in chromium on this particular system,
  and --use-gl=egl also cleared those up. I think the issue may be that
  the driver for this specific hardware is buggy, and affected users are
  better off using the alternate GL implementation. (I can provide more
  details if this is of interest.)

Bug#1068161: Video playback regression

[Daniel Richard G.]

Package: chromium
Version: 123.0.6312.86-1~deb12u1
Severity: important

Video playback worked fine in the previous version,
122.0.6261.128-1~deb12u1

In the current version, when I attempt to play a video, the visual
portion is completed whited out. The playback controls are present,
playback position advances, audio can be heard, but the video is just a
solid, constant white (regardless of the site's background color).

During playback, the following pair of error messages are printed
repeatedly to the terminal:

[179003:179003:0331/180459.326096:ERROR:raster_decoder.cc(2407)] 
[.RenderCompositor-0x38dc004ddc00]GL ERROR :GL_INVALID_OPERATION : 
glWritePixelsYUV: Failed to upload pixels to dest shared image

[179003:179003:0331/180459.385907:ERROR:shared_image_representation.cc(478)] 
Attempt to read from an uninitialized SharedImage. Initialized region: (0, 0, 
0, 0) Size: (544, 360)

I have downloaded the previous 122.0.6261.128-1~deb12u1 package, and
run it to confirm that it can still play video correctly. In fact, I
have 122 and 123 running side by side, with one working and the other
spewing errors.


--Daniel

Bug#959867: ifup kills dhclient on if-up.d script failure

[Daniel Richard G.]

I was recently bitten by this as well.

It was particularly bad in my case: on a headless server, with the
network connection being my only way in---and the problem was not with
the main Ethernet interface, but with a separate WireGuard one that I
was not using (both marked as "auto").

The eno1 interface got a DHCP connection without issue. But the wg0
config had a post-up routing-setup bug that I'd missed in earlier
testing. As the syslog excerpt below shows, the failure to bring up wg0
caused *all* of the "Raise network interfaces" task to be walked back.
And as this only killed dhclient and left eno1 configured, I thought all
was fine... until the system dropped off the network twelve hours later.

(It's also clear that dhclient was killed uncleanly, because the next
time it runs, you get a "Removed stale PID file" message.)

The "FIB table does not exist" error is where things start to go wrong:

2024-02-05T22:19:06.343712-05:00 darkstar systemd[1]: Starting 
networking.service - Raise network interfaces...
2024-02-05T22:19:06.377118-05:00 darkstar dhclient[620]: Internet Systems 
Consortium DHCP Client 4.4.3-P1
2024-02-05T22:19:06.377147-05:00 darkstar ifup[620]: Internet Systems 
Consortium DHCP Client 4.4.3-P1
2024-02-05T22:19:06.377154-05:00 darkstar ifup[620]: Copyright 2004-2022 
Internet Systems Consortium.
2024-02-05T22:19:06.377159-05:00 darkstar ifup[620]: All rights reserved.
2024-02-05T22:19:06.377164-05:00 darkstar ifup[620]: For info, please visit 
https://www.isc.org/software/dhcp/
2024-02-05T22:19:06.377178-05:00 darkstar dhclient[620]: Copyright 
2004-2022 Internet Systems Consortium.
2024-02-05T22:19:06.377190-05:00 darkstar dhclient[620]: All rights 
reserved.
2024-02-05T22:19:06.377201-05:00 darkstar dhclient[620]: For info, please 
visit https://www.isc.org/software/dhcp/
2024-02-05T22:19:06.377213-05:00 darkstar dhclient[620]: 
2024-02-05T22:19:06.675691-05:00 darkstar dhclient[620]: Listening on 
LPF/eno1/XX:XX:XX:XX:XX:XX
2024-02-05T22:19:06.675765-05:00 darkstar ifup[620]: Listening on 
LPF/eno1/XX:XX:XX:XX:XX:XX
2024-02-05T22:19:06.675783-05:00 darkstar ifup[620]: Sending on   
LPF/eno1/XX:XX:XX:XX:XX:XX
2024-02-05T22:19:06.675796-05:00 darkstar ifup[620]: Sending on   
Socket/fallback
2024-02-05T22:19:06.675831-05:00 darkstar dhclient[620]: Sending on   
LPF/eno1/XX:XX:XX:XX:XX:XX
2024-02-05T22:19:06.675863-05:00 darkstar dhclient[620]: Sending on   
Socket/fallback
2024-02-05T22:19:06.675919-05:00 darkstar dhclient[620]: DHCPREQUEST for 
192.168.1.2 on eno1 to 255.255.255.255 port 67
2024-02-05T22:19:06.675956-05:00 darkstar ifup[620]: DHCPREQUEST for 
192.168.1.2 on eno1 to 255.255.255.255 port 67
2024-02-05T22:19:09.219179-05:00 darkstar kernel: [6.436538] e1000e 
:00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
2024-02-05T22:19:09.219201-05:00 darkstar kernel: [6.436674] IPv6: 
ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
2024-02-05T22:19:11.467192-05:00 darkstar dhclient[620]: DHCPREQUEST for 
192.168.1.2 on eno1 to 255.255.255.255 port 67
2024-02-05T22:19:11.467252-05:00 darkstar ifup[620]: DHCPREQUEST for 
192.168.1.2 on eno1 to 255.255.255.255 port 67
2024-02-05T22:19:11.470106-05:00 darkstar dhclient[620]: DHCPACK of 
192.168.1.2 from 192.168.1.1
2024-02-05T22:19:11.470172-05:00 darkstar ifup[620]: DHCPACK of 192.168.1.2 
from 192.168.1.1
2024-02-05T22:19:11.509438-05:00 darkstar dhclient[620]: bound to 
192.168.1.2 -- renewal in 21284 seconds.
2024-02-05T22:19:11.509497-05:00 darkstar ifup[620]: bound to 192.168.1.2 
-- renewal in 21284 seconds.
2024-02-05T22:19:11.575017-05:00 darkstar kernel: [8.793246] wireguard: 
WireGuard 1.0.0 loaded. See www.wireguard.com for information.
2024-02-05T22:19:11.575027-05:00 darkstar kernel: [8.793252] wireguard: 
Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights 
Reserved.
2024-02-05T22:19:11.589364-05:00 darkstar ifup[689]: Error: ipv4: FIB table 
does not exist.
2024-02-05T22:19:11.589373-05:00 darkstar ifup[689]: Flush terminated
2024-02-05T22:19:11.589765-05:00 darkstar ifup[583]: ifup: failed to bring 
up wg0
2024-02-05T22:19:11.599118-05:00 darkstar systemd[1]: networking.service: 
Main process exited, code=exited, status=1/FAILURE
2024-02-05T22:19:11.663575-05:00 darkstar systemd[1]: networking.service: 
Failed with result 'exit-code'.
2024-02-05T22:19:11.664060-05:00 darkstar systemd[1]: Failed to start 
networking.service - Raise network interfaces.
2024-02-05T22:19:11.664996-05:00 darkstar systemd[1]: Reached target 
network.target - Network.
2024-02-05T22:19:11.665371-05:00 darkstar systemd[1]: Reached target 
network-online.target - Network is Online.

Bug#1051998: chromium: please to add support for riscv64

[Daniel Richard G.]

On Thu, 2023 Nov 23 22:44-05:00, Bo YU wrote:
>
> But likely the Chromium developer has picked this now:
> 1. angle:
> https://chromium-review.googlesource.com/c/angle/angle/+/5057086
> 2. base:
> https://chromium-review.googlesource.com/c/chromium/src/+/5054184
> 3. sandbox:
> https://chromium-review.googlesource.com/c/chromium/src/+/5056263
> 4. ffmpeg:
> https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/5054185
>
> we have one dav1d to be left, but the developer told me he has did it.

Thanks Bo. It is good that the upstream is willing to accept patches for
riscv64. I was worried that Google would not support the platform, in
the same way that they do not support ppc64el.

I had considered adjusting the patches here so that they can be applied
after the ppc64el patches. (There is no way that a conditional patch set
would be accepted by Debian---all the patches have to apply together.)
But if the patches are accepted by the upstream, then there is no need
to adjust the patches for Debian.

Bug#1051998: chromium: please to add support for riscv64

[Daniel Richard G.]

Hello Bo YU,

On Sun, 2023 Nov 19 10:01-05:00, Bo YU wrote:
>
> I have rebased the patchset base on 119.0.6045.159-1, there is no code
> changed but maybe small change will be happened on next version from
> upstream's supporting for riscv64.

Do you have links/references for the upstreaming of riscv64 support?
I am interested to see the status of that in Chromium development.

(Did Google accept all of the patches needed, or only a small
part of them?)

Bug#1033305: chromium: try enabling use_thin_lto for faster build

[Daniel Richard G.]

On Sat, 2023 Nov 18 20:37-05:00, Andres Salomon wrote:
>
> I still haven't messed around with thinlto yet, but my primary concern 
> at this point is that various ARM build machines keep running out of 
> memory while building chromium. In particular, on armhf the arm-ubc-* 
> buildds run out of memory and kill the build,

On armhf, it's not possible to enable ThinLTO, because the final link
requires more than 4 GB RAM. (I tried a full build in an armhf Docker
container running under QEMU, on a system with 48 GB RAM, and still
it failed.) I haven't tried i386, but presumably the same issue will
occur there.

(Is there a way to have official Debian packages be cross-compiled? This
is a case where native compilation isn't ideal.)

> as you can see on 
> https://buildd.debian.org/status/logs.php?pkg=chromium=armhf

There's something unrelated going on there, doubtful it's any kind of
OOM at that point in the build. I think you'd have to peek at syslog to
get an answer. Could be a hardware issue, for all the log shows.

> I'm wondering if thinlto would possibly result in faster/less-memory-
> intensive object (or bitcode or whatever) generation that might work
> better on platforms with less memory? Do you know offhand how memory
> usage of thinlto compares to what we (debian) do now (no LTO at all)?

I'm not aware of LTO, in general, helping much with run-time memory
usage. But it's supposed to make things run faster to some degree, and I
figure that alone would be welcome on the less-beefy platforms.


By the way, I've been meaning to write in with a related issue. ThinLTO
currently fails on ppc64el, with this GN error:

begin build log excerpt
gn gen out/Release --args="clang_use_chrome_plugins=false ... use_thin_lto=true 
..."
ERROR at //build/config/compiler/BUILD.gn:696:5: Assertion failed.
assert(use_lld, "LTO is only supported with lld")
^-
LTO is only supported with lld
See //build/config/BUILDCONFIG.gn:333:3: which caused the file to be included.
  "//build/config/compiler:afdo",
  ^-
make[1]: *** [debian/rules:164: override_dh_auto_build-arch] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:127: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
end build log excerpt

(Credit to Luiz Guzman @ Trisquel Linux for bringing this to my attention:
https://github.com/ungoogled-software/ungoogled-chromium-debian/issues/334#issuecomment-1767888316)

The issue comes down to this conditional in build/config/BUILDCONFIG.gn:

  # Set to true when compiling with the Clang compiler.
  is_clang = current_os != "linux" ||
 (current_cpu != "s390x" && current_cpu != "s390" &&
  current_cpu != "ppc64" && current_cpu != "ppc" &&
  current_cpu != "mips" && current_cpu != "mips64" &&
  current_cpu != "riscv64")

The assumption underlying that logic is clearly incorrect in the Debian
context. Perhaps we should just hard-code it to true.

I don't know if there are other ramifications of is_clang=false in the
ppc64el build. I sent a note to Tim about this, but never heard back.

Bug#1055905: Build dependencies not installable on (old)stable

[Daniel Richard G.]

On Mon, 2023 Nov 13 21:00-05:00, Andres Salomon wrote:
>
> That is a harder question to answer. :)
>
> If you go to https://buildd.debian.org/status/package.php?p=chromium 
> and select "Bookworm" for the suite, and hit "Go", you can see the 
> build logs for the latest (bookworm) release. However, I have no idea 
> how to get build logs for older releases - the "old" link takes you to 
> older build logs for sid. I suspect that's a bug.

Okay, so it's not just me. getbuildlog(1) likewise doesn't work for the
(old)stable versions.

That would be a pretty flagrant bug, so hopefully someone else will
notice and straighten it out. Thanks again!

Bug#1055905: Build dependencies not installable on (old)stable

[Daniel Richard G.]

On Mon, 2023 Nov 13 20:24-05:00, Andres Salomon wrote:
> The dependencies are in (old)stable-proposed-updates. For example, add 
> the following to your /etc/apt/sources.list:
>
> deb http://deb.debian.org/debian/ bullseye-proposed-updates main
> deb-src http://deb.debian.org/debian/ bullseye-proposed-updates main

Thanks, I've confirmed that this allows build-dep to succeed on
bookworm.

(Where can I find the build logs? Those would have answered this
question, and more.)

> The buildds already use these repos, which is why building chromium 
> works. Once a new (old)stable point release is made, the packages will 
> move from (old)stable-proposed-updates into (old)stable. According to 
> https://lists.debian.org/debian-release/2023/11/msg00136.html , the 
> next bookworm point release (12.3) should be happening on Dec 9th.

This is good to know, as I would have expected a newer compiler to land
in -backports.

Bug#1055905: Build dependencies not installable on (old)stable

[Daniel Richard G.]

Package: chromium
Version: 119.0.6045.123-1~deb12u1

On bookworm, with backports enabled:

# apt-get build-dep chromium
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:chromium : Depends: lld-16 but it is not installable
  Depends: clang-16 but it is not installable
  Depends: clang-format-16 but it is not installable
  Depends: libclang-rt-16-dev but it is not installable
E: Unable to correct problems, you have held broken packages.

Where are those LLVM 16 packages supposed to come from?

The same situation arises on bullseye. The associated chromium source
package pages even notes those packages as "not available":

https://packages.debian.org/source/bookworm/chromium
https://packages.debian.org/source/bullseye/chromium

Also, I cannot find (old)stable build logs for the package at e.g.

https://buildd.debian.org/status/logs.php?pkg=chromium=amd64

Is there a different place where I should find them? I was hoping the
build logs would shed some light on how these build dependencies were
being handled.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1055317: Various problems in source build

[Daniel Richard G.]

Source: llvm-toolchain-16-16.0.6
Version: 1:16.0.6-17

I am experimentally building this package on Ubuntu jammy, and have
found a few problems in the debian/ files. I'll describe them in order
of most to least significant.

First, this build failure:

begin build log excerpt
[2672/2769] cd /home/build/llvm/llvm-toolchain-16-16.0.6/libclc/build && 
/usr/bin/llvm-spirv-15 --spirv-max-version=1.1 -o spirv-mesa3d-.spv 
builtins.link.spirv-mesa3d-.bc
FAILED: spirv-mesa3d-.spv 
/home/build/llvm/llvm-toolchain-16-16.0.6/libclc/build/spirv-mesa3d-.spv 
cd /home/build/llvm/llvm-toolchain-16-16.0.6/libclc/build && 
/usr/bin/llvm-spirv-15 --spirv-max-version=1.1 -o spirv-mesa3d-.spv 
builtins.link.spirv-mesa3d-.bc
Unknown attribute kind (86) (Producer: 'LLVM16.0.6' Reader: 'LLVM 15.0.7')
end build log excerpt

The Build-Depends: resulted in llvm-spirv-15 getting installed (as that
is the latest jammy has available), and this fallback-logic line in
d/rules enabled its use:

LLVM_SPIRV_VERSION := $(shell expr $(LLVM_VERSION) - 1)

It seems pretty clear that llvm-spirv-N with N != 16 cannot be used for
the build, however.

Secondly, d/rules does not appear to be parallel-safe. If I build with
"dpkg-buildpackage -b -j8", I run into this:

begin build log excerpt
ar ruv libFuzzer.a Fuzzer*.o
Using cmake: cmake
LD_LIBRARY_PATH=/home/build/llvm/llvm-toolchain-16-16.0.6/build-llvm/lib:$LD_LIBRARY_PATH
 \
VERBOSE=1  cmake --build build-llvm -j 8 --target stage2 || cat 
build-llvm/tools/clang/stage2-bins/CMakeFiles/CMakeOutput.log
mkdir -p libclc/build
-O2 -DNDEBUG -g1 -fstack-protector-strong -Wformat -Werror=format-security 
-Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2
/bin/sh: 5: 
/home/build/llvm/llvm-toolchain-16-16.0.6/build-llvm/tools/clang/stage2-bins/bin/clang++:
 not found
make[1]: *** [debian/rules:760: debian-libfuzzer-build] Error 1
make[1]: *** Waiting for unfinished jobs
end build log excerpt

Adding a ".NOTPARALLEL:" line to the file prevents this from occurring.

I also noticed this (non-fatal) error:

begin build log excerpt
if ldd build-llvm/tools/clang/stage2-bins/lib/libclang-16.so.1|grep -q 
libclang-cpp-16; then \
echo "libclang-16.so.1 depends on libclang-cpp. Should not be the 
case"; \
exit 2; \
fi
ldd: build-llvm/tools/clang/stage2-bins/lib/libclang-16.so.1: No such file or 
directory
end build log excerpt

The library file is named differently:

$ ls -l build-llvm/tools/clang/stage2-bins/lib/libclang-16.so*
lrwxrwxrwx 1 build users21 Nov  3 20:40 
build-llvm/tools/clang/stage2-bins/lib/libclang-16.so -> libclang-16.so.16.0.6
-rwxr-xr-x 1 build users 124310912 Nov  3 20:40 
build-llvm/tools/clang/stage2-bins/lib/libclang-16.so.16.0.6

The check should be rewritten to ensure an absent file causes failure.

Lastly, there was this (non-fatal) error:

begin build log excerpt
   dh_fixperms
   dh_missing
   debian/rules override_dh_strip
make[1]: Entering directory '/home/build/llvm/llvm-toolchain-16-16.0.6'
: # running out of diskspace on the buildds
find build-llvm -name '*.o' -o -name '*.a' -type f | xargs -r rm -f
find: ‘build-llvm’: No such file or directory
end build log excerpt

The build-llvm directory was already removed by the
"rm -rf $(TARGET_BUILD)" line at the end of the
"override_dh_auto_install" target.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1054104: Use hardlinks in /usr/libexec/qemu-binfmt/ instead of symlinks

[Daniel Richard G.]

Package: qemu-user-static
Version: 1:8.1.1+ds-2
Severity: wishlist

I am using qemu-user-static in conjunction with binfmt-support and
Docker/Podman to allow running foreign-arch containers on amd64. This
approach works quite well, once you get past the speed hit.

The main step involved is making the appropriate static interpreter
executable available at the same path location within the container as
on the host system (because the kernel's binfmt support does not
differentiate between the two environments). For example, the aarch64
interpreter lives on the host at

/usr/libexec/qemu-binfmt/aarch64-binfmt-P

so when I create an arm64 container, I need to copy in the interpreter
executable to that same location, so that the kernel can find it
whenever it is asked to run an arm64 binary inside the container.

Now, instead of copying the interpreter into the container, a simpler
approach would be to just bind-mount the host's /usr/libexec/qemu-binfmt/
directory inside the container, at the same location. This not only
keeps the foreign-arch container "pure" (no random amd64 binaries in the
image) but also ensures the interpreter is up-to-date, since no copy is
ever made of it that could become stale.

Unfortunately, this approach is currently not possible, because the
qemu-binfmt/ directory only contains symlinks. (I could copy over the
appropriate /usr/bin/qemu-*-static file and it would work, but that then
defeats the purpose of avoiding copies.) If the directory contained
hardlinks, then it would be amenable to bind-mounting into a different
filesystem root.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1021239: opensmtpd: debconf answers during installation are not saved/used

[Daniel Richard G.]

I can confirm that this behavior persists in opensmtpd 7.3.0p2-1, the
current sid version.

The package scripts take settings from the (possibly absent)
/etc/mailname and /etc/aliases files, and push those into debconf,
instead of the other way around. This breaks pre-seeding, and makes the
package's debconf support little better than using an editor on those
files directly.

You can kinda-sorta pre-seed by doing

# echo my.mail.name >/etc/mailname
# echo "root: my.r...@addr.com" >/etc/aliases

and then installing the package, but then you don't get the more
elaborate aliases file that is generated by the install scripts.

(The configuration scripts are in need of an overhaul, generally. The
absence of settings for a smarthost and additional mail-names is
conspicuous. Ideally, opensmtpd would have a debconf implementation
similar to that of postfix or exim4-config.)


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1051304: error: out of memory

[Daniel Richard G.]

On Thu, 2023 Sep  7 05:42-04:00, Julian Andres Klode wrote:
>
> Things are quite complex with the memory management patch set, while
> I have a backport to 2.06 in Ubuntu, I also did not release the final
> patch set there yet. There was concern of additional regressions from
> that. But we know for sure the current state was regressing some, but
> I guess they are all regressed now if that makes sense.
>
> I can try to get the patches together for a stable update, but I think
> we might want to wait until the final set landed in Ubuntu updates for
> LTS so we don't get the regression potential on both ends (and we have
> more control over the update phasing in Ubuntu than Debian).

Thanks for explaining the backstory on this issue. I was not aware that
the Ubuntu-side fix had yet to be finalized.

(I'm surprised that this has remained an issue so late in the EFI game.
I've avoided it till now by sticking to BIOS boot mode on my systems,
but that's just me---the rest of the world has moved on.)

> For a wholesale upload of grub 2.12 to stable, we need to wait for
> the final 2.12 release and also we don't plan to do this if we can
> backport any security patches coming up to 2.06.

Would bookworm-backports be a more feasible target in the short term?

> I think generally this is a low priority issue for Debian if you
> can't loopback large images, and Debian doesn't have initrds as huge
> as Ubuntu so that never became a significant issue.

The use case for this is booting into a live rescue system on an ISO
file on a hard drive, along the lines of what grml-rescueboot allows.
This is useful not just as a boot option when the regular OS eats
itself, but also as a way to run (re)imaging and other diagnostics that
are not possible when the OS partition is active.

I hope to avoid having to enable "Legacy Boot Mode" just to get this
working again...

-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1051304: error: out of memory

[Daniel Richard G.]

Hi Julian,

On Wed, 2023 Sep  6 04:17-04:00, Julian Andres Klode wrote:
>
> Yes, so please just try the 2.12~rc1-9 in unstable and see if it
> fixes your issue.

I've confirmed that this version no longer gives the "out of memory"
error, and can load and boot the ISO images that previously failed.

Is this a long way from making it into stable? Or at least -backports?

-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1051304: error: out of memory

[Daniel Richard G.]

Package: grub-efi-amd64
Version: 2.06-13
Severity: important

I have encountered a situation where grub-efi-amd64 reports

error: out of memory

in the pre-boot environment despite the system having an adequate amount
of RAM (8 GB). This occurs when attempting to load an ISO9660 image file
via loopback, e.g.

loopback loop /path/to/debian-live-11.2.0-amd64-standard.iso

(note that this ISO file is ~1 GB in size)

This issue is easily reproducible in VirtualBox with an EFI-based VM. I
do notice that a somewhat smaller ISO (systemrescue-10.01-amd64.iso,
~740 MB) is able to be loaded via loopback and booted. Also, this issue
does NOT occur on grub-pc with an equally-spec'ed BIOS-based VM; that
one can boot the same ISO file just fine.

This issue appears to match the following one from the Ubuntu side:

https://bugs.launchpad.net/bugs/1842320

That one revolved more around loading larger initrd files, which
prevented some users' installed systems from booting. The issue was
resolved earlier this year, so assuming it is the same as this one, a
fix should be readily available.

-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1050890: Firefox LTO build breakage (and fixage)

[Daniel Richard G.]

/usr/lib/firefox/libmozavcodec.so: Unknown DWARF DW_OP_0 
referenced from DIE at [325272]
dwz: debian/firefox/usr/lib/firefox/libmozavutil.so: Unknown DWARF DW_OP_0 
referenced from DIE at [3f546]
dwz: debian/firefox/usr/lib/firefox/libmozavutil.so: Unknown DWARF DW_OP_0 
referenced from DIE at [3f546]
dwz: debian/firefox/usr/lib/firefox/libmozsqlite3.so: DWARF compression not 
beneficial - old size 1647652 new size 1661321
dwz: debian/firefox/usr/lib/firefox/libmozavcodec.so: Unknown DWARF DW_OP_0 
referenced from DIE at [325272]
dwz: debian/firefox/usr/lib/firefox/libipcclientcerts.so: DWARF compression not 
beneficial - old size 2613256 new size 2630714
dh_dwz: error: dwz 
-mdebian/firefox/usr/lib/debug/.dwz/x86_64-linux-gnu/firefox.debug 
-M/usr/lib/debug/.dwz/x86_64-linux-gnu/firefox.debug -- 
debian/firefox/usr/lib/firefox/crashreporter 
debian/firefox/usr/lib/firefox/firefox debian/firefox/usr/lib/firefox/glxtest 
debian/firefox/usr/lib/firefox/gmp-clearkey/0.1/libclearkey.so 
debian/firefox/usr/lib/firefox/libipcclientcerts.so 
debian/firefox/usr/lib/firefox/liblgpllibs.so 
debian/firefox/usr/lib/firefox/libmozavcodec.so 
debian/firefox/usr/lib/firefox/libmozavutil.so 
debian/firefox/usr/lib/firefox/libmozgtk.so 
debian/firefox/usr/lib/firefox/libmozsandbox.so 
debian/firefox/usr/lib/firefox/libmozsqlite3.so 
debian/firefox/usr/lib/firefox/libmozwayland.so 
debian/firefox/usr/lib/firefox/minidump-analyzer 
debian/firefox/usr/lib/firefox/pingsender 
debian/firefox/usr/lib/firefox/plugin-container 
debian/firefox/usr/lib/firefox/vaapitest returned exit code 1
dh_dwz: error: Aborting due to earlier error
make[2]: *** [debian/rules:321: override_dh_dwz] Error 25
make[2]: Leaving directory '/tmp/firefox-117.0'
make[1]: *** [debian/rules:340: install] Error 2
make[1]: Leaving directory '/tmp/firefox-117.0'
make: *** [debian/rules:340: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2
end build log excerpt

Not sure why those two libraries are causing trouble, but I resolved it
by adding "-X libmozav" to the dh_dwz invocation.


With these three fixes, the Firefox build with LTO enabled completes
successfully.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1050615: Crash: Illegal instruction / invalid opcode in libxul.so on Pentium M

[Daniel Richard G.]

Package: firefox-esr
Version: 102.14.0esr-1~deb12u1
Severity: important

Loading certain sites in Firefox ESR causes the tab to crash, and on
occasion, the browser as a whole. A reliable cause of this is the Google
account login page, which this crash makes impossible to traverse.

I had to start the browser with MOZ_CRASHREPORTER_DISABLE=1 set in
the environment to disable BreakPad, or else I would not get useful
telemetry from the system logs.

The terminal output shows

Illegal instruction

and syslog shows these entries:

2023-08-27T02:31:20.899434-04:00 darkstar kernel: [  713.633343] traps: 
Isolated Web Co[2454] trap invalid opcode ip:b0af8174 sp:bff0c340 error:0 in 
libxul.so[ab957000+5c91000]
2023-08-27T02:33:48.231483-04:00 darkstar kernel: [  860.962987] traps: 
Isolated Web Co[2843] trap invalid opcode ip:b0af8abc sp:bfcd35b0 error:0 in 
libxul.so[ab957000+5c91000]

This is on a Pentium M laptop running the i386 build of Debian bookworm.
CPU information:

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 13
model name  : Intel(R) Pentium(R) M processor 1.80GHz
stepping: 6
microcode   : 0x17
cpu MHz : 800.000
cache size  : 2048 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov clflush 
dts acpi mmx fxsr sse sse2 ss tm pbe bts cpuid est tm2 pti
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit mmio_unknown
bogomips: 3588.46
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 32 bits virtual
power management:


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1040471: Package configuration script mishandles multiple arch instances

[Daniel Richard G.]

Forgot to mention: I don't see this error on a similarly configured
Ubuntu system, from this package or any other in my installed set. It's
possible the issue comes down to some difference in debconf itself.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1040471: Package configuration script mishandles multiple arch instances

[Daniel Richard G.]

Package: libgstreamer1.0-0
Version: 1.22.0-2

The package configuration script does not handle correctly the case of
both the amd64 and i386 packages being installed simultaneously on the
system (a situation arising, in my case, from the use of 32-bit Wine):

# dpkg -l | grep libgstreamer1.0-0
ii  libgstreamer1.0-0:amd64  1.22.0-2 
amd64Core GStreamer libraries and elements
ii  libgstreamer1.0-0:i386   1.22.0-2 
i386 Core GStreamer libraries and elements

# dpkg-reconfigure libgstreamer1.0-0
dpkg-query: error: --status needs a valid package name but 'libgstreamer1.0-0' 
is not: ambiguous package name 'libgstreamer1.0-0' with more than one installed 
instance

Use --help for help about querying packages.
/usr/sbin/dpkg-reconfigure: libgstreamer1.0-0 is not installed


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1033305: chromium: try enabling use_thin_lto for faster build

[Daniel Richard G.]

In recent versions, enabling use_thin_lto causes a new linker flag to be
added, which as far as I've seen, Clang <= 15 doesn't recognize. (I have
not tested >= 16)

This is the build error I've observed:

[2789/56743] SOLINK ./libvulkan.so.1
FAILED: libvulkan.so.1 libvulkan.so.1.TOC 
"python3" "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" 
--nm="nm"  --sofile="./libvulkan.so.1" --tocfile="./libvulkan.so.1.TOC" 
--output="./libvulkan.so.1" -- clang++ -shared -Wl,-soname="libvulkan.so.1" 
-fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack 
-Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics 
-Wl,-mllvm,-instcombine-lower-dbg-declare=0 -flto=thin -Wl,--thinlto-jobs=all 
-Wl,--thinlto-cache-dir=thinlto-cache 
-Wl,--thinlto-cache-policy=cache_size=10\%:cache_size_bytes=40g:cache_size_files=10
 -Wl,-mllvm,-import-instr-limit=30 -Wl,-mllvm,-disable-auto-upgrade-debug-info 
-fwhole-program-vtables -Wl,--undefined-version 
-Wl,--no-call-graph-profile-sort -m64 -no-canonical-prefixes -Wl,-O2 
-Wl,--gc-sections -rdynamic -Wl,-z,defs -Wl,--as-needed -Wl,--lto-O0 
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--stats -o 
"./libvulkan.so.1" @"./libvulkan.so.1.rsp"  
ld.lld: error: -mllvm: ld.lld: Unknown command line argument 
'-disable-auto-upgrade-debug-info'.  Try: '/usr/bin/ld.lld --help'
ld.lld: Did you mean '--disable-arm-parallel-dsp'?
clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)


The following patch fixes the issue:

--- a/build/config/compiler/BUILD.gn
+++ b/build/config/compiler/BUILD.gn
@@ -726,14 +726,6 @@ config("compiler") {
   }
 
   ldflags += [ "-Wl,-mllvm,-import-instr-limit=$import_instr_limit" ]
-
-  if (!is_chromeos) {
-# TODO(https://crbug.com/972449): turn on for ChromeOS when that
-# toolchain has this flag.
-# We only use one version of LLVM within a build so there's no need to
-# upgrade debug info, which can be expensive since it runs the 
verifier.
-ldflags += [ "-Wl,-mllvm,-disable-auto-upgrade-debug-info" ]
-  }
 }
 
 # TODO(https://crbug.com/1211155): investigate why this isn't effective on


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1038679: bullseye node-acorn workaround breaks build on some systems

[Daniel Richard G.]

Package: chromium
Version: 114.0.5735.133-1
Severity: minor

Currently, the debian/rules file contains this bit under the
override_dh_auto_configure target:

# bullseye workarounds; delete this post-bullseye
cp -ra /usr/share/nodejs/acorn  third_party/node/node_modules/
cp -ra /usr/share/nodejs/acorn-walk third_party/node/node_modules/walk
sed -i -e "s#'acorn-walk'#'walk'#" 
third_party/node/node_modules/rollup/dist/es/shared/rollup.js
sed -i -e "s#'acorn-walk'#'walk'#" 
third_party/node/node_modules/rollup/dist/shared/rollup.js

When I build the chromium package on Ubuntu kinetic, I run into this:

# use system rollup
cp -ra /usr/share/nodejs/rollup third_party/node/node_modules/
# bullseye workarounds; delete this post-bullseye
cp -ra /usr/share/nodejs/acorn  third_party/node/node_modules/
cp: cannot stat '/usr/share/nodejs/acorn': No such file or directory
make[1]: *** [debian/rules:123: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/home/build/chromium-114.0.5735.133'
make: *** [debian/rules:114: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

The /usr/share/nodejs/acorn directory comes from node-debbundle-acorn or
node-acorn. The former appears to have previously been a dependency of
the rollup package, and the latter is a direct dependency of (the much
newer) libnode108. In between, however, there is a gap in which no acorn
module is pulled in for the package build.

Solution: Either add "node-acorn | node-debbundle-acorn" to
Build-Depends, or remove the workaround from the post-bullseye suites.

(Incidentally, I was able to build the ~deb11u1 package on bullseye just
fine with the workaround disabled, so it's not clear to me that it is
still needed even there.)


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1029218: dkms should perform reproducible build of modules

[Daniel Richard G.]

On Tue, 2023 Apr  4 12:07-04:00, Andreas Beckmann wrote:
> We should probably file a bug against diffoscope to make it aware of 
> this file "modification"

Done: https://bugs.debian.org/1034034

Please tweak or elaborate as needed.

>> Is a unique signature being added to the modules? I noticed that
>> /var/lib/dkms/mok.{key,pub} differ between the two systems.
>
> That's probably the reason. Not sure if something could/should be
> done about that difference. We should probably take this to the
> reproducible builds people
> https://wiki.debian.org/ReproducibleBuilds ...

My thoughts would be

1. I'm vaguely aware that on secure-boot-enabled systems, the kernel and
   kernel modules need to be signed. But setting that up for things one
   builds themselves is non-trivial (the whole key-enrolling mess), and
   necessarily needs to be opt-in. My expectation is that if one doesn't
   explicitly request that, no signing should be performed (the
   signatures would be either unused or rejected anyway), and thus no
   caveat should need to be made on kernel modules differing.

2. Can't these things use a detached signature? That would make the
   reproducible aspect much easier to deal with.

(Is dkms the proper place to address this?)


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1029218: dkms should perform reproducible build of modules

[Daniel Richard G.]

Hi Andreas,

On Fri, 2023 Mar 31 09:22-04:00, Andreas Beckmann wrote:
>
> Do you have an example how the kernel modules differ? diffoscope might 
> help ...
> Does this happen with all or only with certain dkms modules?

The only DKMS modules I am using currently are the ones associated with
virtualbox, so I can't offer a comparison. Here is the output from
diffoscope, however, for one of the modules:

  $ diffoscope 
test-debian-sid-amd64-[12]/usr/lib/modules/6.1.0-7-amd64/updates/dkms
  --- test-debian-sid-amd64-1/usr/lib/modules/6.1.0-7-amd64/updates/dkms
  +++ test-debian-sid-amd64-2/usr/lib/modules/6.1.0-7-amd64/updates/dkms
  │   --- 
test-debian-sid-amd64-1/usr/lib/modules/6.1.0-7-amd64/updates/dkms/vboxdrv.ko
  ├── +++ 
test-debian-sid-amd64-2/usr/lib/modules/6.1.0-7-amd64/updates/dkms/vboxdrv.ko
  │┄ Format-specific differences are supported for ELF binaries but no 
file-specific differences were detected; falling back to a binary diff. file(1) 
reports: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), 
BuildID[sha1]=5ed23a6ee7417643717766d7b5307da88409fe5a, not stripped
  │┄ File has been modified after NT_GNU_BUILD_ID has been applied.
  │ @@ -55695,29 +55695,29 @@
  │  000d98e0:     3082 0199 0609 2a86  0.*.
  │  000d98f0: 4886 f70d 0107 02a0 8201 8a30 8201 8602  H..0
  │  000d9900: 0101 310d 300b 0609 6086 4801 6503 0402  ..1.0...`.H.e...
  │  000d9910: 0130 0b06 092a 8648 86f7 0d01 0701 3182  .0...*.H..1.
  │  000d9920: 0163 3082 015f 0201 0130 3a30 2231 2030  .c0.._...0:0"1 0
  │  000d9930: 1e06 0355 0403 0c17 444b 4d53 206d 6f64  ...UDKMS mod
  │  000d9940: 756c 6520 7369 676e 696e 6720 6b65 7902  ule signing key.
  │ -000d9950: 1420 b794 fc24 18fe 9e24 595e b7f3 026d  . ...$...$Y^...m
  │ -000d9960: 4469 13b4 5230 0b06 0960 8648 0165 0304  Di..R0...`.H.e..
  │ +000d9950: 1412 4e86 5c0c d923 77b1 7c57 6b90 8c67  ..N.\..#w.|Wk..g
  │ +000d9960: 9f64 a4e0 9930 0b06 0960 8648 0165 0304  .d...0...`.H.e..
  │  000d9970: 0201 300d 0609 2a86 4886 f70d 0101 0105  ..0...*.H...
  │ -000d9980: 0004 8201 0057 6678 aee0 2003 cfc3 6f00  .Wfx.. ...o.
  │ -000d9990: 29d9 f1ee 301a 35a9 2fb4 d127 ef5f db28  )...0.5./..'._.(
  │ -000d99a0: 6902 15cf 725d 04c4 69c6 58e2 e1e8 2643  i...r]..i.X...
  │ -000d99b0: 592b 91bd 9fcd 2966 8460 4797 9069 a5cd  Y+)f.`G..i..
  │ -000d99c0: bba6 3cf4 9e0b 1c7f 9277 121e ed08 156d  ..<..w.m
  │ -000d99d0: c180 4ca4 d84f 6884 ecdd 5fe9 0939 b681  ..L..Oh..._..9..
  │ -000d99e0: 2b6f 3e32 d63e 4231 2b2e 1a96 5732 0ad7  +o>2.>B1+...W2..
  │ -000d99f0: cb62 7a5b 4bf6 491a c197 0833 d61a 7bd4  .bz[K.I3..{.
  │ -000d9a00: 59f3 7c2b c834 ad42 fc19 f4c3 6de9 c20b  Y.|+.4.Bm...
  │ -000d9a10: 54d1 78de 9034 ba24 da45 9346 74ba efb7  T.x..4.$.E.Ft...
  │ -000d9a20: 4e67 4743 ee19 dd06 8722 d8cd 3c99 ad27  NgGC."..<..'
  │ -000d9a30: ca63 067b 1310 5c52 3f76 f860 b625 6a54  .c.{..\R?v.`.%jT
  │ -000d9a40: a40a 3142 c889 b921 e19b 4b92 9725 248e  ..1B...!..K..%$.
  │ -000d9a50: ec81 7aad 86d4 28d6 e832 3f0d d09d 3ee0  ..z...(..2?...>.
  │ -000d9a60: c88d dbce 32ac 7d6d 8047 5c39 ab3f 9289  2.}m.G\9.?..
  │ -000d9a70: 424c bb85 293c 4cbf 2ca6 7006 a0d5 2b7f  BL..)(..+.Ck.
  │ +000d9a50: 9e80 c7ac 8e83 7b8b de36 6624 67fe 7a40  ..{..6f$g.z@
  │ +000d9a60: 77cf bf6d 6220 2cb6 e42a 7dff eceb 3102  w..mb ,..*}...1.
  │ +000d9a70: 7265 3b0b 28d3 f8c6 53af 6b09 57e5 e42e  re;.(...S.k.W...
  │ +000d9a80: 7beb 1fec 4600 0002    0001  {...F...
  │  000d9a90: 9d7e 4d6f 6475 6c65 2073 6967 6e61 7475  .~Module signatu
  │  000d9aa0: 7265 2061 7070 656e 6465 647e 0a re appended~.

Is a unique signature being added to the modules? I noticed that
/var/lib/dkms/mok.{key,pub} differ between the two systems.

(No secure-boot configuration has been performed on these systems;
everything was debootstrap'ed and installed from scratch in chroots)

> Is the build reproducible on the same host, e.g. does the sequence
> dkms build
> dkms unbuild
> dkms build
> produce binary identical modules?

I had to do "dkms install ..." / "dkms unbuild ...", but yes, the
resulting modules are identical.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1033283: Please remove $http_proxy validation from postinst script

[Daniel Richard G.]

Package: ttf-mscorefonts-installer
Version: 3.8

The package postinst script contains this bit:

while ! echo "$http_proxy" | \
egrep -iq 'https?://[[:alnum:]][-.[:alnum:]]+(:\d+)?/?' &&  \
[ ! -z "$http_proxy" ] ; do
db_fset msttcorefonts/http_proxy seen false
db_input high msttcorefonts/http_proxy
db_go
db_get msttcorefonts/http_proxy
http_proxy=$RET
done

This appears intended to reject an environment setting of, for example,

http_proxy=socks5h://proxy.example.com/

as wget(1) (which is used to download the font archives) does not
support SOCKS proxies.

However, note that wget can also be configured to use a proxy via a
wgetrc file, which will override the environment variable. In my
deployment, I set http_proxy in the environment to a SOCKS server so
that APT will download packages via same, and set http_proxy in
~/.wgetrc to an alternate HTTP proxy so that wget will work. (The latter
proxy happens to be somewhat unreliable, so the SOCKS one is preferable
wherever it can be used.) This has worked fine with everything I've used
save for this package.

The postinst script's validation of $http_proxy is thus not helpful, and
prevents downloading the package and then the fonts in a single APT
invocation. Here is the error I saw in an automated install process:

Unpacking ttf-mscorefonts-installer (3.8) ...
Setting up libmspack0:i386 (0.10.1-2) ...
Setting up cabextract (1.9-3) ...
Setting up ttf-mscorefonts-installer (3.8) ...
dpkg: error processing package ttf-mscorefonts-installer (--configure):
 installed ttf-mscorefonts-installer package post-installation script 
subprocess returned error exit status 30
Processing triggers for libc-bin (2.31-13+deb11u5) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for fontconfig (2.13.1-4.2) ...
Errors were encountered while processing:
 ttf-mscorefonts-installer
E: Sub-process /usr/bin/dpkg returned an error code (1)

If I attempt to complete the installation by hand, I get a debconf
dialog that pops back up repeatedly unless I remove the SOCKS proxy
setting. Given that the dialog makes no mention of wget's limited proxy
support, and neglects to give any sort of error message, this behavior
is quite user-hostile.

Note that the Ubuntu version of this package not only gets rid of the
$http_proxy validation, it also eliminates the msttcorefonts/http_proxy
debconf setting, and the questionable behavior of storing the install-
time value of $http_proxy therein. In fact, the package scripts make no
mention of a proxy at all. That not only seems to me like the right
approach (in that it avoids making assumptions on how the user manages
their proxies), it appears to be the convention followed by other
packages that perform an embedded download, like libdvd-pkg.

Given that the Ubuntu package has diverged slightly from the Debian one,
this may be a good opportunity/excuse to merge them back together.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1033015: Minor issues in debian/rules [patch]

[Daniel Richard G.]

On Fri, 2023 Mar 17 21:26-04:00, Andres Salomon wrote:
>
> Is Ubuntu looking to switch to using Debian's chromium instead of the
> snap or flatpak or whatever they currently use?

Unfortunately no, not to my knowledge. I'm just working with a
gentleman who maintains an Ubuntu PPA build of Chromium, that is
based on Debian's source.

> If that's a "yes", and you're the one working on it, I'd suggest
> joining Debian's chromium team. :)

That's what they should have done, all right...

>> The attached patch addresses both issues.
>
> Thanks! I'll apply the patch (though I'm not sure yet if we want more 
> verbose linker output, build logs are already pretty big).

Oh, I didn't add that bit; my patch just moves it down in the file.

>> Side note: You may want to consider enabling ThinLTO, by setting
>> use_thin_lto=true and unsetting concurrent_links. The final link
>> requires only ~10.5 GB RAM, and completes within minutes.
>
> I'm not clear on how that affects runtime performance; any ideas? I'd 
> also have to make sure that it works okay on clang-13 (which is what 
> bullseye is building with).

I haven't run any benchmarks myself, but commentary from folks who do
performance-optimized builds of Chromium (https://thorium.rocks/ is one
example) seem to indicate that ThinLTO is beneficial.

(LTO generally is, isn't it? It's just that with Chromium, standard LTO
is prohibitively expensive.)

I tried a test build on bullseye with use_thin_lto=true, and it goes
through, FWIW. I don't have at this time an environment to actually try
out the build, however.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1033015: Minor issues in debian/rules [patch]

[Daniel Richard G.]

-shell/usr/lib/chromium/chromium-shell: Too many DIEs, not 
optimizing
dh_dwz: error: dwz -- debian/chromium-shell/usr/lib/chromium/chromium-shell 
returned exit code 1
objcopy --compress-debug-sections 
debian/chromium-common/usr/lib/debug/.dwz/x86_64-linux-gnu/chromium-common.debug
dh_dwz: error: Aborting due to earlier error
make: *** [debian/rules:112: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
end

Build success with compat 13 and DEB_BUILD_OPTIONS=nostrip:
begin
   dh_missing
dh: command-omitted: The call to "dh_dwz" was omitted due to 
"DEB_BUILD_OPTIONS=nostrip"
dh: command-omitted: The call to "dh_strip" was omitted due to 
"DEB_BUILD_OPTIONS=nostrip"
   dh_makeshlibs -a
rm -f debian/chromium/DEBIAN/shlibs
objdump: Warning: Unrecognized form: 0x22
objdump: Warning: Unrecognized form: 0x22
objdump: Warning: Unrecognized form: 0x22
objdump: Warning: Unrecognized form: 0x22
end


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1033015: Minor issues in debian/rules [patch]

[Daniel Richard G.]

Package: chromium
Version: 111.0.5563.64-1
Severity: minor

I've been experimenting with building the latest Debian chromium package
on Ubuntu 22.04, and in the course of that have found a couple of minor
issues in the debian/rules file:

* The flags added by optimize=+lto in DEB_BUILD_MAINT_OPTIONS will
  cause every compile invocation to print "optimization flag
  '-ffat-lto-objects' is not supported" warnings (as the dpkg LTO flags
  are meant for GCC, not Clang), and balloon the RAM required for the
  final link from ~2.5 GB to ~30 GB. The link will also require much
  more time to complete; on my fairly beefy test system, it went from
  under a minute to four hours.

  Disabling this explicitly before Debian enables LTO system-wide would
  be a good move, in my view. On Ubuntu, LTO is already the default, and
  without adding this bit, the package is difficult to build in their
  infrastructure due to the resource requirements.

* LDFLAGS is set without obtaining an initial value from
  dpkg-buildflags(1).

The attached patch addresses both issues.

Side note: You may want to consider enabling ThinLTO, by setting
use_thin_lto=true and unsetting concurrent_links. The final link
requires only ~10.5 GB RAM, and completes within minutes.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.--- chromium-111.0.5563.64/debian/rules.orig	2023-03-02 01:24:58.0 +
+++ chromium-111.0.5563.64/debian/rules	2023-03-15 08:15:54.485885154 +
@@ -6,6 +6,9 @@
 # enable all build hardening flags
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+# disable lto flags, as they are for gcc, not clang
+export DEB_BUILD_MAINT_OPTIONS+=optimize=-lto
+
 # indicate that binary targets do not require root
 export DEB_RULES_REQUIRES_ROOT=no
 
@@ -15,12 +18,13 @@
 export CC=clang
 export CXX=clang++
 
-# more verbose linker output
-export LDFLAGS+=-Wl,--stats
-
 # initial flags from dpkg-buildflags
 export DEB_CXXFLAGS_MAINT_STRIP=-g
 export CXXFLAGS=$(shell dpkg-buildflags --get CXXFLAGS)
+export LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
+
+# more verbose linker output
+export LDFLAGS+=-Wl,--stats
 
 # extra flags to reduce warnings that aren't very useful
 export CXXFLAGS+=-Wno-conversion \

Bug#1031848: Need fallback mirrors for VideoLAN download

[Daniel Richard G.]

Package: libdvd-pkg
Version: 1.4.3-1-1

The VideoLAN download site has been fairly robust over time, but today I
encountered this:

# dpkg-reconfigure libdvd-pkg
libdvd-pkg: Downloading orig source...
I: libdvdcss_1.4.3
/usr/bin/wget --tries=3 --timeout=40 --read-timeout=40 --continue -O 
libdvdcss_1.4.3.orig.tar.bz2 \
  
https://download.videolan.org/pub/libdvdcss/1.4.3/libdvdcss-1.4.3.tar.bz2 \
|| /usr/bin/uscan --noconf --verbose --rename 
--destdir=/usr/src/libdvd-pkg --check-dirname-level=0 --force-download 
--download-current-version /usr/share/libdvd-pkg/debian
--2023-02-23 23:25:59--  
https://download.videolan.org/pub/libdvdcss/1.4.3/libdvdcss-1.4.3.tar.bz2
Resolving download.videolan.org (download.videolan.org)... 213.36.253.2, 
2a01:e0d:1:3:58bf:fa02:c0de:5
Connecting to download.videolan.org 
(download.videolan.org)|213.36.253.2|:443... failed: Connection timed out.
Connecting to download.videolan.org 
(download.videolan.org)|2a01:e0d:1:3:58bf:fa02:c0de:5|:443... failed: Network 
is unreachable.
/bin/sh: 3: /usr/bin/uscan: not found
make: *** [/usr/share/libdvd-pkg/debian/rules:24: get-orig-source] Error 127


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030979: Script error: "cannot create /dev/stdout: No such device or address"

[Daniel Richard G.]

Package: ifupdown-extra
Version: 0.33+nmu1
Severity: minor

In testing ifupdown-extra, I noticed this in syslog:

Feb  9 22:14:53 image-debian64 ifup[495]: 
/etc/network/if-up.d/10check-duplicate-ip: 86: cannot create /dev/stdout: No 
such device or address

/dev/stdout is a Bash feature, but 10check-duplicate-ip is run using
/bin/sh (see first line). On Debian systems, /bin/sh is normally a
symlink to dash, which is a much more limited implementation of the
Bourne shell.

The script should either limit itself to using POSIX standard shell
features, or switch to a /bin/bash shebang line.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030977: DO_SYSLOG=yes produces duplicate messages in syslog

[Daniel Richard G.]

Package: ifupdown-extra
Version: 0.33+nmu1

In testing out a stock installation of ifupdown-extra, I noticed the
following pair of messages in syslog:

Feb  9 22:06:44 image-debian64 root[493]: WARNING: Initialising interface 
enp0s3 which does not have a link
Feb  9 22:06:44 image-debian64 ifup[493]: <27>Feb  9 22:06:44 root[493]: 
WARNING: Initialising interface enp0s3 which does not have a link

This is coming from 00check-network-cable, and DO_SYSLOG is untouched
from its default value of "yes". The second message, of course, appears
to be a repackaged duplicate of the first and should not be there.

If I set DO_SYSLOG=no in /etc/default/network-test, then all I see is

Feb  9 22:12:21 image-debian64 ifup[480]: WARNING: Initialising interface 
enp0s3 which does not have a link

There is apparently something in the Debian standard logging system that
causes logger(1) messages to be duplicated. Since stdout is going to
syslog anyway, making DO_SYSLOG=no the shipped default seems like a
reasonable solution.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030976: Scripts do not handle IFACE="--all" case correctly

[Daniel Richard G.]

Package: ifupdown-extra
Version: 0.33+nmu1

In testing out an installation of ifupdown-extra, I noticed the
following trio of messages in syslog:

Feb  9 22:12:21 image-debian64 ifup[526]: ERROR: Interface --all does not 
seem to be present in the system
Feb  9 22:12:21 image-debian64 ifup[533]: Device "--all" does not exist.
Feb  9 22:12:21 image-debian64 ifup[531]: WARNING: Cannot check for 
duplicate IP address in the network as the script could not find the ip address 
of --all. You can disable this test by setting DO_ARPING to 'no' in 
/etc/default/network-test .

The first and third messages appear to come from the 00check-network-cable
and 10check-duplicate-ip scripts, respectively.

Note that IFACE="--all" is a valid invocation of the if-*.d scripts, per
bug #826000.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030975: 00check-network-cable script is in wrong directory

[Daniel Richard G.]

Package: ifupdown-extra
Version: 0.33+nmu1
Severity: important

The 00check-network-cable script is currently in /etc/network/if-up.d/,
but it should be in if-pre-up.d/, because it needs to run before the
interface is configured. (Running after configuration defeats the entire
purpose of checking whether a cable is connected.) The script even has a
comment at the top stating

# This script should be installed in /etc/network/if-pre-up.d/

I've confirmed that this breaks the intended behavior when
ABORT_NO_LINK=yes is set in /etc/default/network-test . This issue is
also present in the bullseye version of the package (0.32).


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030292: Cannot bind to privileged port

[Daniel Richard G.]

Package: apt-cacher-ng
Version: 3.7.4-1+b2
Severity: important

I want to run apt-cacher-ng on port 80 for a dedicated caching server.

After configuring via debconf to use that port, and restarting, nothing
is listening at localhost:80. I see the following in syslog:

2023-02-02T00:10:04.728949-05:00 image-debian64 systemd[1]: Starting 
apt-cacher-ng.service - Apt-Cacher NG software download proxy...
2023-02-02T00:10:04.740737-05:00 image-debian64 apt-cacher-ng[668]: 
Couldn't bind socket: Permission denied
2023-02-02T00:10:04.740858-05:00 image-debian64 apt-cacher-ng[668]: 
Couldn't bind socket: Permission denied
2023-02-02T00:10:04.743750-05:00 image-debian64 systemd[1]: Started 
apt-cacher-ng.service - Apt-Cacher NG software download proxy.

If this is a limitation of the current package, then it should be noted
in the documentation and debconf prompt.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1029218: dkms should perform reproducible build of modules

[Daniel Richard G.]

Package: dkms
Version: 3.0.10-1
Severity: wishlist

If I install the same DKMS package on two identically-configured Debian
sid systems, the resulting kernel modules are not bit-for-bit identical.

The integrity of kernel modules is critical to a secure system, and
ensuring that their builds are reproducible will help make that quality
significantly easier to verify.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1024870: Scenario in which --extra-suites leads to breakage

[Daniel Richard G.]

Package: debootstrap
Version: 1.0.128+nmu2

I attempted to bootstrap an Ubuntu jammy system, and got an error:

$ debootstrap \
--extra-suites=jammy-security,jammy-updates \
--force-check-gpg \
--arch=amd64 \
jammy \
test-ubuntu \
http://local-apt-mirror.example.com/ubuntu
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id F6ECB3762474EDA9D21B7022871920D1991BC93C)
I: Retrieving Packages 
[...]
I: Configuring login...
I: Configuring libc-bin...
I: Unpacking the base system...
W: Failure trying to run: chroot "/tmp/test-ubuntu" dpkg --force-overwrite 
--force-confold --skip-same-version --install
W: See /tmp/test-ubuntu/debootstrap/debootstrap.log for details

The last part of the debootstrap.log file:

[...]
Unpacking systemd-sysv (249.11-0ubuntu3) ...
Setting up systemd-sysv (249.11-0ubuntu3) ...
dpkg: error: --install needs at least one package archive file argument

Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or 
'more' !

If I remove the --extra-suites option, the bootstrap completes
successfully.

It appears that the relevant portion of the script is not guarding
against the possibility of an empty package list.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#983916: dma can't send mail with long lines

[Daniel Richard G.]

FYI, there is a long discussion on this issue at

https://github.com/corecode/dma/issues/18

Much of it centers around RFC2822's "Each line of characters MUST be no
more than 998 characters" verbiage.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#959922: xdg-autostart does not comply with freedesktop.org spec

[Daniel Richard G.]

Package: obsession
Version: 20140608-2

I have an XDG config hierarchy with the following directories:

/etc/xdg/autostart/
/etc/xdg/xdg-openbox/autostart/

The Xsession startup scripts correctly set

XDG_CONFIG_DIRS=/etc/xdg/xdg-openbox:/etc/xdg

I have placed a number of *.desktop files under xdg-openbox/autostart/
which effectively disable those under xdg/autostart/, by adding the
Hidden=true directive to files of the same name. The intent is for
Openbox sessions to not run any of the normal XDG autostart programs, in
order to keep the session lightweight.

As an example...

# /etc/xdg/autostart/xiccd.desktop
[Desktop Entry]
Name=xiccd
GenericName=X color management daemon
Comment=Applies color management profiles to your session
Exec=xiccd
Terminal=false
Type=Application
NotShowIn=GNOME;KDE;

# /etc/xdg/xdg-openbox/autostart/xiccd.desktop
[Desktop Entry]
Hidden=true

Unfortunately, xdg-autostart executes files in xdg/autostart/. In
~/.xsession-errors, I see this:

** Message: 23:00:46.576: xdg-autostart.vala:39: Processing 
/etc/xdg/autostart/xiccd.desktop file.
** Message: 23:00:46.584: xdg-autostart.vala:94: Launching: xiccd 
(xiccd.desktop)

This behavior disregards the following section of the "Desktop
Application Autostart Specification":

Hidden Key

When the .desktop file has the Hidden key set to true, the .desktop
file MUST be ignored. When multiple .desktop files with the same
name exists in multiple directories then only the Hidden key in the
most important .desktop file must be considered: If it is set to
true all .desktop files with the same name in the other directories
MUST be ignored as well.


(https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html)

Upstream appears to have abandoned the xdg-autostart implementation
used in Debian. I would suggest removing it from the obsession package,
and have openbox rely on its own openbox-xdg-autostart program, which
uses PyXDG and handles the startup process in a more conformant manner.

(The openbox package would then probably need to gain a dependency on
python3-xdg, as currently it has none.)


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#697643: openntpd: Does not make large adjustments.

[Daniel Richard G.]

On Fri, 11 Nov 2016 17:48:45 -0300, Dererk wrote:
> Usually from the standpoint of some servers that contain timestamp
> operations embedded on them, like databases or things alike, enabling
> -s could possible trigger data corruption, since from one instant to
> the other time change backwards. This is also default behavior from
> openntpd upstream.
>
> Personally I do have set -s on systems I know risks are not taken.

Note that -s only makes large adjustments to the time on startup. In
normal operation, this will occur only when the system boots, before any
databases or other critical processes begin.

I don't see that the upstream default is reasonable, especially when I
see messages like the following in my system log:

Apr 13 00:23:00 test64 ntpd[931]: adjusting local clock by 199.207333s
Apr 13 00:25:39 test64 ntpd[931]: adjusting local clock by 199.127660s
Apr 13 00:29:20 test64 ntpd[931]: adjusting local clock by 199.017683s
Apr 13 00:30:25 test64 ntpd[931]: adjusting local clock by 198.985143s
Apr 13 00:34:12 test64 ntpd[931]: adjusting local clock by 198.871842s
Apr 13 00:37:22 test64 ntpd[931]: adjusting local clock by 198.776466s
Apr 13 00:38:56 test64 ntpd[931]: adjusting local clock by 198.728357s
Apr 13 00:40:36 test64 ntpd[931]: adjusting local clock by 198.679637s

I would argue that the expectation for openntpd in Debian is to work as
a drop-in replacement for ntp, and so should be configured to behave
similarly, even if this differs from the upstream default. That is,
presumably, why the config file lists four Debian NTP pool systems. If
there are data-loss issues that arise with -s, then these should also
arise with -g in ntp---and would have a much bigger impact there, as
that package is many times more popular.

Can -s be made the default in /etc/default/openntpd ?


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#933743: LibXSLT in Debian stable has three unpatched security vulnerabilities

[Daniel Richard G.]

On Tue, 2019 Aug  6 15:20-04:00, Salvatore Bonaccorso wrote:
> 
> No I was refering to the bugs filled in the BTS, they were #926895,
> #931321 and #931320. We then cross reference those to/from the
> security-tracker as well. I added your bug as well later on.

I think what may have happened was that these bugs were filed against
the source package, but I had (only) checked the bugs for libxslt1.1,
the runtime binary package.

I will make a note to additionally check the source package in this kind
of situation in the future.

> Done and it entered unstable today,
> https://tracker.debian.org/news/1052113/accepted-libxslt-1132-21-source-into-unstable/
> . Will look into prepare based on that as well a buster-pu update and
> possibly time permitting as well one back to stretch.

Greatly appreciate your work here, as will users running those releases.

Bug#933743: LibXSLT in Debian stable has three unpatched security vulnerabilities

[Daniel Richard G.]

On Sun, 2019 Aug  4 03:20-04:00, Salvatore Bonaccorso wrote:
>
> Sure it might have been overlooked, but pinging the existing bug would
> have been less overhead to now as well start tracking this one as well
> adjusting metadata etc. But no worries.

Just so that I understand, there was an existing bug? I checked the open
bugs before filing this one, but didn't see anything relating to those
CVEs. Do you mean something with the security tracker?

> CVSS severity scores are really very dependent and who assess it. I
> guess you are refering to the ones as assessed by NVD. Agreed though
> that Felix Wilhelm has provided a nice exploiting vector example in
> the upstream issue for local file access depending on context of how
> libxslt would be used.

And I figure LibXSLT is used in a number of ways that may result in
security exposure, not just within Debian itself, but also user
applications built on top of it.

> Anyway I prepared a non-maintainer upload for libxslt adressing all
> three CVEs in unstable and uploaded it to DELAYED/2 and create a merge
> request on salsa.

Thank you, I will watch for it in sid :)

Bug#933743: LibXSLT in Debian stable has three unpatched security vulnerabilities

[Daniel Richard G.]

Hi Salvatore,

On Sat, 2019 Aug  3 09:32-04:00, Salvatore Bonaccorso wrote:
>
> As you can see from the security-tracker btw, for all three there are
> bugs filled already. So why a new bug for all three together? :)

The earliest CVE is nearly four months old, and patches already exist. I
filed the bug since it seems a sid/stable update has been overlooked...

> Btw, they do not warrant a DSA, but LTS might not classify them
> similarly as for stretch and buster, so there was a DLA because there
> is no point release in LTS.

The CVSS severity scores are fairly high for CVE-2019-11068... don't
DSAs include less-exploitable issues than this? (I'm pretty sure a
number of network-facing applications use LibXSLT)

I understand that LTS may handle updates differently, but aren't these
issues rather significant to defer fixes to the next point release? And
even then, shouldn't at least sid have the fix already?

Bug#933743: LibXSLT in Debian stable has three unpatched security vulnerabilities

[Daniel Richard G.]

Package: libxslt1.1
Version: 1.1.32-2
Severity: grave

The upstream version of LibXSLT shipped in Debian stable (1.1.32) has
the following three CVEs reported against it:

https://nvd.nist.gov/vuln/detail/CVE-2019-11068
https://nvd.nist.gov/vuln/detail/CVE-2019-13117
https://nvd.nist.gov/vuln/detail/CVE-2019-13118

Debian has taken notice of these, but has only patched them in jessie
(a.k.a. oldoldstable):

https://lists.debian.org/debian-lts-announce/2019/04/msg00016.html
https://lists.debian.org/debian-lts-announce/2019/07/msg00020.html

The current jessie package version of LibXSLT (1.1.28-2+deb8u5) contains
the following patch files:

CVE-2019-11068.patch
CVE-2019-13117.patch
CVE-2019-13118.patch

These are not present in 1.1.32-2, and so these vulnerabilities appear
to be exploitable in Debian stable, testing, and sid.

The current upstream release of LibXSLT is 1.1.33, which unfortunately
still has the above three CVEs. However, they appear to have been
patched in Git.

Bug#933372: Installed sox fails test suite

[Daniel Richard G.]

Package: sox
Version: 14.4.2+git20190427-1

After building and installing the current SoX package, running the
"installcheck" target fails with the following error:

[...]
ok channels=1 "ima" <--> "dat".
ok channels=1 "ima" <--> "au".
ok channels=1 "ima" <--> "aiff".
ok channels=1 "ima" <--> "aifc".
ok channels=1 "ima" <--> "flac".
ok channels=1 "ima" <--> "caf".
ok channels=1 "u8 in wav" <--> "smp".
ok channels=1 "u8 in wav" <--> "s8".
ok channels=1 "u8 in wav" <--> "s8 (swap bits)".
ok channels=1 "u8 in wav" <--> "s8 (swap nibbles)".
ok channels=1 "u8 in wav" <--> "s8 (swap nibbles & bits)".
ok channels=1 "u8 in wav" <--> "sndt".
ok channels=1 "u8 in wav" <--> "sndr".
/usr/bin/sox FAIL formats: can't open input file `intermediate.hcom': Invalid 
dictionary
*FAIL* channels=1 "u8 in wav" <--> "hcom".
Makefile:3085: recipe for target 'installcheck' failed
make[1]: *** [installcheck] Error 1
make[1]: Leaving directory '/tmp/sox-14.4.2+git20190427/src'
Makefile:656: recipe for target 'installcheck-recursive' failed
make: *** [installcheck-recursive] Error 1


Might one of the many Debian patches applied to the source have broken
HCOM format support?


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#586709: closed by Thomas Goirand

[Daniel Richard G.]

Arrgh, my apologies, everyone. Despite being the reporter, I have not
been receiving any messages on this thread save for those Cc'ed to me.

I have re-subscribed to my own bug and will hopefully not miss any
further updates.

On Sat, 2018 Oct 27 22:53+0100, Ian Jackson wrote:
>
> That it's a bug in just that one package is good because if halt
> sometimes does its work by indirecting via init(8) and
> /etc/init.d/halt, then it is more convenient to improve the
> communication if both things are in the same package.

Certainly. I'm not clear on how the communication was originally
intended to work, but what's there now does not appear to support the
expected behavior (or documented behavior, at least for one reasonable
interpretation of the docs).

The /run solution sounds quite reasonable to me.


--Daniel

Bug#586709: closed by Thomas Goirand

[Daniel Richard G.]

On Fri, 2018 Oct 26 11:56-0300, Jesse Smith wrote:
>
> It's not documented in the halt manual page because it's not a
> limitation of the halt command. It's a problem with the
> /etc/init.d/halt script. The halt command is working as expected, it's
> the script that is overriding the command line behaviour.

The halt(8) (and poweroff(8)) commands are *not* working as expected, or
else I would not have filed this bug report. You could say that the
frontend program is working correctly, and the backend (init script) is
not, but user expectation is about the whole unit. And a bug in the
backend is still a bug in this package.

> Agreed. I'm just saying this isn't a coding problem with halt, or a
> problem with its documentation. I'm saying that my opinion is that
> this is a problem with the way /etc/default/halt and its corresponding
> script change behaviour vs what the user expects from running halt
> from the command line. Those scripts are doing what they're told to do
> (override halt's command line behaviour).

Bear in mind that there is a distinction between default behavior (e.g.
running halt(8) with no arguments) versus requested behavior ("halt -p").
The config file changes the former, but there is nothing to indicate
that the latter will not be respected.

> It's basically a case of one person telling halt to always stop the
> system (in /etc/default/halt) and another person telling halt to
> poweroff (via the command line). Debian currently is set up so the
> first user "wins". Both settings can't be right, so the implementation
> (as it is now) follows the first user's instruction.

In other words, as it is now, the implementation has a bug.

> It might be possible to change this using various tricks so the second
> user "wins", but that means overriding /etc/default/init

(Did you mean /etc/default/halt?)

Yes, overriding the config file is exactly what is supposed to happen
when the user requests non-default behavior (like "halt -p").

I don't know if you or Thomas intend to fix the implementation, but if
the behavior is going to remain as it is now, then the documentation
needs to be updated to reflect that. This bug isn't as urgent for me now
as it was eight years ago, when I needed proper halt behavior for a UPS-
connected server. But if this bug report is going to be closed, then for
God's sake at least do it right.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#586709: closed by Thomas Goirand

[Daniel Richard G.]

For some reason, I did not receive any of these recent messages prior to
the one that closed the bug.

Just a few things I'd like to point out:

1. "poweroff" performing a halt is incorrect behavior regardless of the
   setting in /etc/default/halt;

2. Regarding this:

   > The user is basically reporting, in the above situation, that they
   > change the default behaviour, but then want to change it back using
   > another method and I don't think Debian's approach supports that.

   Where is this limitation documented in the halt(8) or halt(5) man
   pages, or the /etc/default/halt config file itself?

   > Basically, everything is working "as expected",

   What I expect is that the system works as documented.

3. Better late than never...


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#911658: Please update Debian's Mono suite to current upstream

[Daniel Richard G.]

Package: mono-runtime
Version: 4.6.2.7+dfsg-2

As of this writing, the current upstream stable release version of Mono
is 5.16.0. Many changes have been made in Mono since 4.6 and I've run
into .NET applications that will not run with the existing packaged
version. Debian's Mono suite is sorely in need of an update.

Bug#904152: Request: Rename "ubuntu-archive-keyring" package to "ubuntu-keyring" for consistency with Ubuntu

[Daniel Richard G.]

Package: ubuntu-archive-keyring
Version: 2016.05.13-1
Severity: wishlist

The package that Debian calls "ubuntu-archive-keyring" is present in
Ubuntu as "ubuntu-keyring".

Unlike Debian, Ubuntu does not (and will not) have separate
ubuntu-keyring and ubuntu-archive-keyring packages. The reasoning behind
this is explained by Dimitri John Ledkov in this bug report:

https://bugs.launchpad.net/bugs/1782641

As there is no likelihood that the "ubuntu-keyring" package name will
be needed in the future for a hypothetical Ubuntu equivalent of the
debian-keyring package, it would be desirable to eliminate this
otherwise needless naming inconsistency between the two distros.

(This report was motivated by a package install script, which normally
runs on Ubuntu, failing on Debian for this arguably trivial reason.)

Incidentally... this package could use an update!

Bug#717477: grub-pc: Unable to reconfigure grub using dpkg-reconfigure grub-pc, if initially installed with DEBIAN_FRONTEND=noninteractive

[Daniel Richard G.]

Is this still an issue? I am not able to reproduce it with the current
version of GRUB (2.02).

Bug#904062: Allow concurrent installation of grub-pc and grub-efi-ami64

[Daniel Richard G.]

Package: grub-efi-amd64
Version: 2.02+dfsg1-4
Severity: wishlist

Currently, you can have both grub-{pc,efi-amd64}-bin installed, but you
can only have one or the other of grub-{pc,efi-amd64}, as the packages
conflict with each other. This means that only one grub-install --target
is supported in Debian's configuration framework at any one time.

(It is already possible to install both grub-*-bin packages and invoke
grub-install with the desired --target manually, but this occurs outside
of the Debian framework and so is not a good long-term solution.)

I would like to request making it possible to install both packages
simultaneously, with an appropriate configuration mechanism to
disable one, both, or none. There are at least a couple of use cases
I can see for this:

1. Assembling system images that can support both BIOS and EFI booting
   without needing to install/remove any packages to switch from one
   mode to the other;

2. A Debian install on e.g. a portable USB hard drive with a hybrid
   MBR/GPT partition table that supports *both* the BIOS and EFI
   boot paths.

Bug#742829: [pkg-apparmor] Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

Hi Seth,

On Wed, 2017 Oct  4 18:39-0700, Seth Arnold wrote:
> Thanks for tackling this Daniel,
> 
> On Fri, Sep 29, 2017 at 04:09:02PM -0400, Daniel Richard G. wrote:
> > alias /etc/chromium-browser/ -> /etc/chromium/,
> > alias /usr/bin/chromium-browser -> /usr/bin/chromium,
> > alias /usr/lib/chromium-browser/chromium-browser-sandbox -> 
> > /usr/lib/chromium/chrome-sandbox,
> > alias /usr/lib/chromium-browser/chromium-browser -> 
> > /usr/lib/chromium/chromium,
> > alias /usr/lib/chromium-browser/ -> /usr/lib/chromium/,
> 
> Be aware that use of alias rules can drastically affect compilation
> times and generated policy sizes. Maybe these should be variables that
> could be set as they are changed?
> 
> > # We need 'flags=(attach_disconnected)' in newer chromium versions
> > /usr/lib/chromium-browser/chromium-browser flags=(attach_disconnected) {
> 
> Please consider using a shorter, friendlier, profile name:
>
> profile chromium-browser /usr/lib/chromium-browser/chromium-browser 
> flags=(attach_disconnected) {
> 
> >   capability sys_admin,
> >   capability sys_chroot,
> >   capability sys_ptrace,
> 
> I like sticking capabilities high in the profile, just after the
> #include statements, so that they're more easily visible.

Bear in mind that the profile I have is based on Ubuntu's. Mine is only
a few lines beyond ubuntu/17.10/usr.bin.chromium-browser in the
apparmor-profiles Git repository, and I deliberately want to keep the
diff small to simplify maintenance/PRs.

I like the changes you're proposing, but the easiest way forward would
be to apply these to the 17.10 or forthcoming 18.04 edition of the
profile in Git, after which I'll merge them in here.

At this point in time, Ubuntu is still the primary source for the
Chromium profile. That will hopefully move over to Debian (as Debian
ultimately maintains the Chromium packages for both distros), but
for now that's the main limiting factor on what I'm doing.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#877391: Please add apparmor profile

[Daniel Richard G.]

Hi Guido,

On Sun, 2017 Oct  1 12:28+0200, Guido Günther wrote:
> Package: chromium
> Version: 61.0.3163.100-2
> Severity: wishlist
> Tags: patch
> 
> Hi,
>
> I'd be great if Debian would ship an apparmor profile for chromium. The
> attached profile was mostly prepared by Daniel Richard and is based on
> the one in Ubuntu so I assume it has seen quiet some exposure to real
> world usage. It works here nicely here. I'm sure there will be tweaks
> needed over time so feel free to cc' me and Richard on apparmor related
> issues. If this shouldn't work out we can always disable it again.

I had a look at your additions to the profile. Some comments:

* As mentioned in the earlier bug report, we should add the abstractions
  file to Debian as well (though not necessarily the same file as Ubuntu
  has). I'd like to move the aliases into an include file, eventually,
  and that one would probably make the most sense.

* This line gave me pause:

+ @{PROC}/@{pid}/task/@{tid}/status rw,

  I've seen denials from the lack of this line, but have hesitated to
  add this. I'm quite suspicious of Chromium wanting write access to
  this proc file of unrelated processes, and would want more information
  as to why this is needed before allowing this.

  (@{pid} and @{tid} will one day represent actual kernel variables, but
  for now they remain basically equivalent to "[0-9]*".)

  I've found no issues with this access being denied, and would have in
  fact added this line with a "deny" qualifier if that didn't also
  disallow such access to Chromium's own processes.

* The new lines for "tr" and "head": As much as possible, I try to keep
  lists of similar items in alphabetical order, because it's more work
  to maintain lists when there isn't a well-defined ordering.

* The rest looks reasonable, the sort of AppArmor footprint increment
  that Chromium usually follows.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

On Sat, 2017 Sep 30 19:19+0200, Guido Günther wrote:
>
> >   #include 
>
> This file is currently not included in Debian's apparmor package.
> @intrigeri, can this be added? I assume we don't want other packages
> to mess around in abstractions? If not I can pull the code from that
> file into the profile.

This file should be added to Debian, rather than modifying the profile.
Not only to minimize the diff with Ubuntu, but also because this may be
a better place to put the Debian aliases.

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

On Fri, 2017 Sep 29 00:18+0200, Guido Günther wrote:
>
> Attaching to this the report is fine. I can handle it from there.

Okay, greatly appreciated. My current profile is attached. Please Cc: me
on the new bug report.

As it happens, this file is identical to the current version of the
profile in the apparmor-profiles Git repository, with the exception of
the Debian alias lines.

It seems that the AppArmor folks accepted my changes in the merge
request, not by approving the merge, but by applying the changes to a
new version-specific copy in the repo. They added a few more things of
their own, which I have in turn merged into my/this copy.

I never heard anything from them about this, however; I learned about
this only now that I diffed my profile with their latest. Their process
could certainly stand to be more transparent.
# Author: Jamie Strandboge 
#include 

# Debian compatibility aliases
# https://bugs.debian.org/742829
#
alias /etc/chromium-browser/ -> /etc/chromium/,
alias /usr/bin/chromium-browser -> /usr/bin/chromium,
alias /usr/lib/chromium-browser/chromium-browser-sandbox -> 
/usr/lib/chromium/chrome-sandbox,
alias /usr/lib/chromium-browser/chromium-browser -> /usr/lib/chromium/chromium,
alias /usr/lib/chromium-browser/ -> /usr/lib/chromium/,

# We need 'flags=(attach_disconnected)' in newer chromium versions
/usr/lib/chromium-browser/chromium-browser flags=(attach_disconnected) {
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  # This include specifies which ubuntu-browsers.d abstractions to use. Eg, if
  # you want access to productivity applications, adjust the following file
  # accordingly.
  #include 

  # Networking
  network inet stream,
  network inet6 stream,
  @{PROC}/[0-9]*/net/if_inet6 r,
  @{PROC}/[0-9]*/net/ipv6_route r,

  # Should maybe be in abstractions
  /etc/mime.types r,
  /etc/mailcap r,
  /etc/mtab r,
  /etc/xdg/xubuntu/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/mimeinfo.cache r,

  @{PROC}/[0-9]*/fd/ r,
  @{PROC}/filesystems r,
  @{PROC}/ r,
  @{PROC}/[0-9]*/task/[0-9]*/stat r,
  owner @{PROC}/[0-9]*/cmdline r,
  owner @{PROC}/[0-9]*/io r,
  owner @{PROC}/[0-9]*/setgroups w,
  owner @{PROC}/[0-9]*/{uid,gid}_map w,
  @{PROC}/[0-9]*/smaps r,
  owner @{PROC}/[0-9]*/stat r,
  @{PROC}/[0-9]*/statm r,
  owner @{PROC}/[0-9]*/status r,
  owner @{PROC}/[0-9]*/task/[0-9]*/status r,
  deny @{PROC}/[0-9]*/oom_{,score_}adj w,
  @{PROC}/sys/kernel/yama/ptrace_scope r,
  @{PROC}/sys/net/ipv4/tcp_fastopen r,

  # Newer chromium needs these now
  /etc/udev/udev.conf r,
  /sys/devices/**/uevent r,
  /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq r,
  /sys/devices/system/node/node*/meminfo r,
  /sys/devices/pci[0-9]*/**/class r,
  /sys/devices/pci[0-9]*/**/device r,
  /sys/devices/pci[0-9]*/**/irq r,
  /sys/devices/pci[0-9]*/**/resource r,
  /sys/devices/pci[0-9]*/**/vendor r,
  /sys/devices/pci[0-9]*/**/removable r,
  /sys/devices/pci[0-9]*/**/block/**/size r,
  /sys/devices/virtual/block/**/removable r,
  /sys/devices/virtual/block/**/size r,
  /sys/devices/virtual/tty/tty*/active r,
  # This is requested, but doesn't seem to actually be needed so deny for now
  deny /run/udev/data/** r,

  # Needed for the crash reporter
  owner @{PROC}/[0-9]*/auxv r,

  # chromium mmaps all kinds of things for speed.
  /etc/passwd m,
  /usr/share/fonts/truetype/**/*.tt[cf] m,
  /usr/share/fonts/**/*.pfb m,
  /usr/share/mime/mime.cache m,
  /usr/share/icons/**/*.cache m,
  owner /{dev,run}/shm/pulse-shm* m,
  owner @{HOME}/.local/share/mime/mime.cache m,
  owner /tmp/** m,

  @{PROC}/sys/kernel/shmmax r,
  owner /{dev,run}/shm/{,.}org.chromium.* mrw,
  owner /{,var/}run/shm/shmfd-* mrw,

  /usr/lib/chromium-browser/*.pak mr,
  /usr/lib/chromium-browser/locales/* mr,

  # Noisy
  deny /usr/lib/chromium-browser/** w,

  capability sys_admin,
  capability sys_chroot,
  capability sys_ptrace,

  # Allow ptracing ourselves
  ptrace (trace) peer=@{profile_name},

  # Make browsing directories work
  / r,
  /**/ r,

  # Allow access to documentation and other files the user may want to look
  # at in /usr
  /usr/{include,share,src}** r,

  # Default profile allows downloads to ~/Downloads and uploads from ~/Public
  owner @{HOME}/ r,
  owner @{HOME}/Public/ r,
  owner @{HOME}/Public/* r,
  owner @{HOME}/Downloads/ r,
  owner @{HOME}/Downloads/* rw,

  # For migration
  owner @{HOME}/.mozilla/firefox/profiles.ini r,
  owner @{HOME}/.mozilla/firefox/*/prefs.js r,

  # Helpers
  /usr/bin/xdg-open ixr,
  /usr/bin/gnome-open ixr,
  /usr/bin/gvfs-open ixr,
  /usr/bin/kdialog ixr,
  # TODO: xfce

  # Importing firefox settings (requires 'r' access to @{HOME}/.mozilla/**
  # which is provided by abstractions/ubuntu-browsers.d/user-files).
  /etc/firefox/profile/bookmarks.html r,
  owner @{HOME}/.mozilla/** k,

  # Chromium Policies
  

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

On Thu, 2017 Sep 28 22:07+0200, Guido Günther wrote:
>
> I would have hoped you'd simply report wishlist bug against chromium
> with the new profile attached? This gives us a bug to track for futher
> discussion. I'd do it myself but my profile is less well tested since
> I just hacked it up a couple of days ago.

Lately, I'm not in a good position to get so involved here. Replying to
inquiries is one thing; opening new bugs and starting new discussions
is another.

I'll provide the profile, but someone else would have to handle the
bug/discussion legwork needed to get it into Debian.

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

On Thu, 2017 Sep 28 11:21+0200, Guido Günther wrote:
>
> > That would amount to the Debian Chromium maintainers becoming the
> > new upstream for the profile. (Apparmor is basically maintained by
>
> Or maybe people caring about the chromium profile like you, me and
> others in this thread.

You still need someone to actually upload it to Debian. It doesn't do
much good if I have a current profile in GitHub somewhere and
Debian/Ubuntu fail to pick it up.

> > I don't know any of the Debian-Chromium folks to have a sense of
> > what they're open to; would you?
>
> Unfortunately not.
>
> > I'll be happy to provide that updated Chromium profile if you
> > want it.
>
> Could you attach this to new bug against Chromium. If you'd be willing
> to maintain the profile longterm I'd add that to the report too.

I'll be happy to attach it; just let this thread know the new bug
number.

Before that, however, you may want to bring this up on a Debian mailing
list, to get a feel for things.

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

On Wed, 2017 Sep 27 22:26+0200, Guido Günther wrote:
>
> Great! I'm a big fan of doing things upstream but from my pov I'd
> consider apparmor or chromium to be upstream not Ubuntu. What about
> filing a bug against the Debian chromium package with an updated
> profile as a start? We can then take it from there and file another
> one against apparor once it proves working for more people.

That would amount to the Debian Chromium maintainers becoming the new
upstream for the profile. (Apparmor is basically maintained by
Canonical, so also Ubuntu, and Google pretty surely will never touch
this.) If they're willing, I can hardly see how they could do worse
than Ubuntu.

And if it does work out, then that would be a basis to have Ubuntu ship
the Debian profile instead of its own (neglected) version.

I don't know any of the Debian-Chromium folks to have a sense of what
they're open to; would you?

I'll be happy to provide that updated Chromium profile if you want it.

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

Hi Guido!

On Wed, 2017 Sep 27 15:31+0200, Guido Günther wrote:
> 
> I stumbled across this today again since I was looking for a chromium
> profile and still had one in /etc/apparmor.d/usr.bin.chromium-browser
> so it seems the fix for 742829 didn't remove existing files:
> 
>$ dpkg -S /etc/apparmor.d/usr.bin.chromium-browser 
>apparmor-profiles: /etc/apparmor.d/usr.bin.chromium-browse
> 
> So I ended up writing the same fixes in that were already suggested
> here and I wonder why we can't just ship a profile if it's working
> for people?

You'll get no argument from me :)  The main difficulty I've had is
getting upstream (Ubuntu) to accept patches to fix the profile whenever
Chromium's footprint gets bigger.

Case in point: No one's looked at this (old) merge request since it
was posted, even though I was told to file a merge request to get
my fixes in:


https://code.launchpad.net/~skunk/apparmor-profiles/+git/apparmor-profiles/+merge/321802

I wouldn't mind officially maintaining the Chromium profile myself,
given that I already do so for my own use and would like to see others
benefit as well.

> That said I'd rather see this shipped with the chromium package so we
> could reassign this (or open a separate report).

I'd like to see this happen too, if for no other reason than that the
Chromium profile is currently maintained in a sort of no-man's land on
the Ubuntu side.

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Daniel Richard G.]

On Wed, 2017 Mar 29 09:58+0200, Rene Engelhard wrote:
> 
> Or one can Recommends: it in libreoffice. Yeah.

Well, I guess that would let me do what I originally wanted...

# apt-get install libreoffice libreoffice-java-common-
(note the minus at the end)

to install LibreOffice without the Java stuff, even if a JRE is already
installed.

> And what if they decide to remove it later? And autoremove kicks in?
> They will have their stuff break suddenly.

If they remove packages that provide X, then things that require X
will break. This is a fact of the universe, people have to learn this
sooner or later.

> Still that is not obvious, and even newbies sometimes get told you
> disable Recommends: install.. That was *your* argument when we came up
> with -base-drivers and -sdbc-hsqldb.

If they disable Recommends:, then they don't get the JRE, and Java stuff
breaks anyway. The only way to change this is to make "libreoffice" hard-
depend on a JRE, and (thankfully) you've already said that you don't
want this.

> I will _think_ about just Recommending java-common.

It may not be the cleanest solution IMO, but this would be enough to
make LO installation sane for me.

> But that is it. In no way will every Java dependency move to java-
> common (and that is what this bug is about, if you wanted
> something else you would have written something else), because
> that would be bogus.

Given your role as maintainer of the LO beast, I thought you would want
to simplify the dependency tree as much as possible.

> And this will be my last mail to this "bug".

That is okay with me.


Cheers,


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Daniel Richard G.]

On Tue, 2017 Mar 28 09:35+0200, Rene Engelhard wrote:
> >
> > If LibreOffice is installed without Java runtime support, then how
> > is the failed installation of Java-based third-party extensions a
> > problem? That is exactly what should happen.
>
> But people out there don't know what their extension is written in and
> (often) don't know about java-common or so. Thus the metapackage gets
> it in because newbies out there just do apt-get install libreoffice.

That command already pulls in the Java stuff, including lo-java-common, because 
the metapackage Recommends: packages that require Java (like
lo-report-builder).

You already solved this problem without Depends: lo-java-common.

> Trust me, we have been there various times and thus why a default LO
> install *does* install it.

It's not that I don't trust you, it is that this "solution" does not
help the problem you are describing.

If you try an experimental build without that dependency,
"apt-get install libreoffice" will install exactly the same set of
packages as now.

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Daniel Richard G.]

On Tue, 2017 Mar 28 08:36+0200, Rene Engelhard wrote:
> >
> > > That installation would fail with a non clear message if the Java
> > > support is not there. -> Bad.
> > >
> > > We had that "fun" in the past...
> >
> > So, there are Java-based LibreOffice extension packages that do not
> > properly declare their Java dependencies?
>
> I didn't say "packages"? Extensions from the wild, from upstream, from
> LOs extension website _in oxt format_.

If LibreOffice is installed without Java runtime support, then how is
the failed installation of Java-based third-party extensions a
problem? That is exactly what should happen.

> > ...are in libobasis5.2-extension-report-builder-5.2.6.2-2.x86_64.rpm,
> > not in libobasis5.2-core-5.2.6.2-2.x86_64.rpm. The situation is the
> > same in 5.3.
>
> Hmm, then I misremember and need to dig out again why this was in the
> metapackage...

I'm curious...

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Daniel Richard G.]

On Mon, 2017 Mar 27 11:01+0200, Rene Engelhard wrote:
>
> The metapackage is supposed to install (mostly) everything.
>
> This includes the Java stuff.
>
> Think of people wanting to install extensions (which happen to be
> written in Java more often than I'd like it but it's a fact...).
>
> That installation would fail with a non clear message if the Java
> support is not there. -> Bad.
>
> We had that "fun" in the past...

So, there are Java-based LibreOffice extension packages that do not
properly declare their Java dependencies?

> > Also, shouldn't "libreoffice" Recommends: lo-report-builder rather
> > than Depends: lo-report-builder-bin? (lo-r-b-bin is a support
> > package that is not usable by itself and so doesn't belong in the
> > metapackage; lo-r-b is the useful package, but it requires Java and
> > so should only be recommended.)
>
> It's totally irrelevant whether it's installed or not for your case
> and I already said why this one is in the metapackage.

You said,

It [lo-report-builder-bin] is installed because in a standard
upstream install it's in "core" packages afaicr (with -report-
builder being in a extra "package" there, too)

I checked the upstream RPM packages for LibreOffice 5.2. These library
files from lo-report-builder-bin ...

/usr/lib/libreoffice/program/librptlo.so
/usr/lib/libreoffice/program/librptuilo.so
/usr/lib/libreoffice/program/librptxmllo.so

...are in libobasis5.2-extension-report-builder-5.2.6.2-2.x86_64.rpm,
not in libobasis5.2-core-5.2.6.2-2.x86_64.rpm. The situation is the
same in 5.3.

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Daniel Richard G.]

On Sun, 2017 Mar 26 10:12+0200, Rene Engelhard wrote:
>
> > Right. I'd like to be able to say, let's not install that package
> > (lo-java-common), and end up with a clean install of LO sans Java
> > stuff.
>
> You can do that right now, too. Just avoid the Java-using modules. You
> already were on the right track, except that as you say
> -wiki-publisher missed the JRE depends and the script-provider-*
> missed the -java-common depends.
>
> That will be fixed.

What about the hard dependency of "libreoffice" on lo-java-common? This
package is just a dependency of components that need Java, so it is not
appropriate for the metapackage.

Also, shouldn't "libreoffice" Recommends: lo-report-builder rather than
Depends: lo-report-builder-bin? (lo-r-b-bin is a support package that is
not usable by itself and so doesn't belong in the metapackage; lo-r-b is
the useful package, but it requires Java and so should only be
recommended.)

> That -script-provider-{bsh,js} don't have the Depends: is a bug. That
> is acknowledged and will be fixed.

Okay, I am glad that we are squishing bugs :)

> > My apologies, I left out an important bit in that paragraph: to also
> > move all the JRE dependencies to lo-java-common. So when LO as a
> > whole is being installed, the only package that actually pulls in
> > the JRE is lo-java-common.
>
> As I said, libreoffice-java-common just contains libraries.
>
> https://www.debian.org/doc/packaging-manuals/java-policy/x126.html
>
> "Libraries must not depend on a Java runtime."

Ah, but that policy also says

Java libraries packages must be named libXXX[version]-java (without
the brackets), where the version part is optional and should only
contain the necessary part.

So lo-java-common isn't _really_ a Java library package :-)

What I am suggesting is for the JRE dependency to be expressed via the
lo-java-common package. If it helps, imagine that there is a
"libreoffice-jre" package, with this description:

This dependency package points to a Java runtime that is compatible
with LibreOffice. Any LibreOffice component that requires Java will
depend on this package.

In this formulation, it is a separate package from lo-java-common, and
contains no actual Java files (as the package exists only for the
dependency). The reason why I did not suggest this approach is because
there is no reason why you would want to install only one of lo-jre or
lo-java-common, so there is no reason to have two separate packages.

> 100% as said above was admittedly oversimplicating as it only applies
> to the hsqldb driver...
>
> This is a compromise. One might want no Java (as you) and thus I
> didn't want to force it on anyone in -base itself.
>
> E.g. Because you use Firebird or connect to MySQL or PostgreSQL via
> Base.

Yes! My users would much sooner use MySQL/Postgres than that
hsqldb thing.

> So I only recommend the hsqldb driver in base-drivers. Recommends:
> installing is per default on and people who disable it (should) know
> what they do and eventually can install -sdbc-hsqldb theirselves.

Yes, this is good. Of course, they may "disable" it not by declining
hsqldb directly, but by declining installation of the JRE that
hsqldb requires.

(However, declining the JRE is not a good enough solution, because if
you do have a JRE installed for other purposes, then it becomes much
harder to tell apt-get to decline all the LO Java stuff.)

> > Having lo-java-common Recommends: a JRE would be fine---as long as
> > that was the only JRE dependency, that would then allow me to
> > decline all Java- requiring components by declining lo-java-common.
>
> If at all, only a Suggests: (see above)
>
> But this discussion is artificial, if there was a Recommends: there
> *any* module which needs Java needs *extra* Depends on it as - as you
> say yourself - one can install without Recommends and _THEN_ the
> package would be broken. So any package requiring Java would still
> needs to Depend on Java _in addition_.

Ah, yes, you are correct. lo-java-common would need a hard dependency on
a JRE, or else the latter can be declined and packages will break
(unless they have their own JRE dependencies).

On the other hand, it _is_ possible to achieve a similar effect with
separate lo-java-common/JRE dependencies. But then it is necessary to
always have the two dependencies in tandem---if a package Depends: on
one, then it Depends: on the other. If it Recommends: one, then it
Recommends: the other. There can't be any instance where a package
depends on only one of the two, or has a hard dep on one and a soft dep
on the other.

I would prefer to have a single dependency instead of two parallel ones,
but maybe this approach is more to your liking?

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Daniel Richard G.]

Hi Rene,

On Sat, 2017 Mar 25 23:54+0100, Rene Engelhard wrote:
>
> Because you install the metapackage which installs those "all
> components". And libreoffice-base (well, its internal database) _is
> written in Java_.

My intention is to install LibreOffice as a whole minus the Java stuff.

As I understand it, some LO stuff is in Java, but not much. The Java
stuff is notorious for being slow, and as I'm not aware of anyone at my
site needing it, I want to not even install it.

> Yes. Note that "libreoffice" DOES NOT depend on the JRE or Java
> libs itself.
>
> That's pulled in by -base and -report-builder.

Of course. I don't care too much which specific components need Java
(unless e.g. Writer one day starts requiring it); I just want to tell
apt-get "no Java!" and let it do its thing.

> > Let's try installing sans what appears to be LibreOffice's main Java-
> > dependency package:
>
> It's the base stuff without which Java stuff inside LO won't work.
> Basically anything needed for Java in LO is inside that one (besides
> those which belong into the UNO runtime environment or have
> specializied packages).

Right. I'd like to be able to say, let's not install that package
(lo-java-common), and end up with a clean install of LO sans Java stuff.

> > This doesn't make much sense to me. I can't decline installation of
> > lo-java-common, but I can decline default-jre, yet some of the
> > resulting
>
> It does make perfect sense.

How are the *.jar files in lo-java-common useful without a Java runtime?
It doesn't make sense to me for the dependencies to say that these files
are required, when the component required to use them does not need to
be installed.

> > installed packages are useless (lo-report-buildir-bin without
> > lo-report-builder?) or at worse broken.
>
> lo-report-builder-bin without -report-builder installed is not
> breaking stuff. It's more or less a noop. It's installed because in a
> standard upstream install it's in "core" packages afaicr (witgh -report-
> builder being in a extra "package" there, too)
>
> In fact, the RB is in report-builder and report-builder-bin is just
> arch-dep support libraries and it appears only then.

Installing a support package that is not used is better than installing
a broken package, but it is still the result of inaccurate package
dependency information. It doesn't make sense to install just lo-r-b-bin
and not lo-r-b.

(This particular issue is more a symptom of the problem, than a real
problem in itself.)

> > Looking through the dependencies in the various LibreOffice
> > packages, one issue I see is that several of them depend directly on
> > default-jre (or more specifically, "default-jre | openjdk-8-jre |
> > openjdk-7-jre | openjdk-6-jre | gcj-jre | sun-java5-jre | sun-java6-jre
> > | java5-runtime | jre") as well as lo-java-common, when the JRE
> > dependency should in fact be redundant alongside lo-java-common.
>
> No, why should simple support libraries (and this is -java-common)
> depend on a JRE? Stuff needing a JRE should depend on a JRE, not some
> "random" package containing just libraries. Doing this causes many
> issues also for normal Java library packages in Debian. Count this
> package as having only many LO-internal Java libraries.

The dependency need not be a Depends:... Recommends: would be fine too.

> > What I would like to see is for all the various LibreOffice packages
> > that can/must make use of Java to Depends:/Recommends:/Suggests:
>
> That is *exactly* what we have right now.

My apologies, I left out an important bit in that paragraph: to also
move all the JRE dependencies to lo-java-common. So when LO as a whole
is being installed, the only package that actually pulls in the JRE is
lo-java-common.

Think of it as a bottleneck in the dependency graph. This then makes it
easy to pull out that dependency.

> libreoffice installs everything you need. Including a JRE.
>
> If you don't want it/want more control, install the various modules
> yourself. The only one where you really do need Java is Base (and
> the script providers mentioned above and the Java-based extensions
> of course)

"libreoffice" already does not have a hard dependency on a JRE, so there
is no need to give up the metapackage abstraction. I can do without Base
if that absolutely requires a Java runtime, and the other stuff isn't
interesting.

(I don't want to start worrying about the list of all the various
LibreOffice components, because that defeats the purpose of having
metapackages.)

> > lo-java-common, and then have lo-java-common Depends: default-jre et
> > al. That way, when installing LibreOffice, I can decline lo-java-
> > common, the JRE won't get pulled in, and no LibreOffice package that
> > requires Java (or is related to one that does) will get installed.
>
> If you install "libreoffice" you install Base.
>
> Which 100% needs Java right now (because of -sdbc-hsqldb). Of course,
> if you disable Recommends:, you won't see it, but it's 

Bug#858677: No /etc/rc.local file provided

[Daniel Richard G.]

On Sat, 2017 Mar 25 13:25+0100, Martin Pitt wrote:
>
> Right. This is part of the SysV backwards compatibility stuff, but
> that doesn't mean that rc.local should be created and eternally
> handled by systemd itself.

As far as I'm concerned, rc.local stands on its own merits,
independently of SysV.

If I want to "just" add a small startup task---e.g. call setterm(1) to
disable console blanking---without figuring out the intricacies of the
init system du jour, then that's where I go.

> In fact it very much should not, as the precise semantics of rc.local
> are not well defined and it has caused several bug reports and
> confusion already (e. g. "does it wait for the network to be up?",
> which is a question which itself is not well-defined any more in a
> world of hotplug devices, wifi, and roaming).

If the semantics are not well-defined, then the solution is to flesh
them out. Disappearing the file altogether is a non-sequitur,
especially given that all the systemd machinery to execute rc.local
remains in place.

As concerns networking, I would add a note to the file about it, and
perhaps a pointer to the .service file where the dependency can be
tweaked. Choose a reasonable default, and let the user deal with the
hard cases.

> Therefore I close this. The proper way to add your custom jobs to the
> service manager is through systemd units.

Writing a custom systemd unit, and fully integrating with the init
system, is orders of magnitude harder than just adding a line or three
to an existing shell script. Harder, even, than it was to add a custom
SysV init.d script, which was evidently not good enough a solution to
make rc.local unnecessary.

Please remember that not everyone is as familiar with systemd as you
are, and while rc.local is an imperfect solution, it is one that many
users have found helpful---and that continues to be so regardless of the
underlying init system.

Bug#858682: Use /var/cache/zoneminder/temp/ instead of /tmp/zm/

[Daniel Richard G.]

Package: zoneminder
Version: 1.30.0+dfsg-2
Severity: wishlist

The /tmp/zm/ directory is somewhat redundant in light of
/var/cache/zoneminder/temp/, and the latter presents none of the
security risks of the former. Why not have all the temp stuff
live in one location under /var?

Bug#858677: No /etc/rc.local file provided

[Daniel Richard G.]

Package: systemd
Version: 232-19

The systemd package supports executing an /etc/rc.local file on
system boot, but unlike the initscripts package of SysV init, it does
not create/provide the "By default this script does nothing" stub
file itself.

For users who are not already familiar with this file, its absence
reduces discoverability, and may give the impression that it is not
supported at all.

Bug#858675: Per-user language setting not effective

[Daniel Richard G.]

Package: zoneminder
Version: 1.30.0+dfsg-2

This was originally reported on the ZoneMinder forums for 1.25.0, but
the bug appears to still be present in the current version:

https://forums.zoneminder.com/viewtopic.php?t=19403

A package patch is probably in order.

Bug#838548: certbot: Please allow to easily set post-hooks

[Daniel Richard G.]

Hello bug,

I think the original wishlist item is implemented as of 0.10.0. See
this (closed) issue:

https://github.com/certbot/certbot/issues/3394

Hooks are not passed to the "certbot renew" command, but are instead
saved in the /etc/letsencrypt/renewal/$DOMAIN.conf files.

Sylvain, could you give this functionality a try?

Bug#858673: Incorrect example of bind-mount /etc/fstab entries in README.Debian.gz

[Daniel Richard G.]

Package: zoneminder
Version: 1.30.0+dfsg-2
Severity: minor

In /usr/share/doc/zoneminder/README.Debian.gz, in the section "Changing
the location for images and events," the following example of an
/etc/fstab stanza is given:

/dev/sdX1 /otherdrive ext3 defaults 0 2
/otherdrive/zoneminder/images /var/cache/zoneminder/images bind defaults 0 2
/otherdrive/zoneminder/events /var/cache/zoneminder/events bind defaults 0 2

The last two lines are incorrect. Attempting to mount the /var dirs
will yield

mount: unknown filesystem type 'bind'

Rather, they should be written

/otherdrive/zoneminder/images /var/cache/zoneminder/images none bind
/otherdrive/zoneminder/events /var/cache/zoneminder/events none bind

I've also seen "defaults,bind" for the fourth field. The 5th and 6th
fields should be zero and as such can be elided.

Bug#858672: ZM_TELEMETRY_DATA=no in /etc/zm/zm.conf not effective

[Daniel Richard G.]

Package: zoneminder
Version: 1.30.0+dfsg-2

Per /usr/share/perl5/ZoneMinder/ConfigData.pm, ZoneMinder has a
configuration variable ZM_TELEMETRY_DATA that can be set to "yes" (the
default) or "no" to respectively enable or disable automatic
transmission of usage information to the ZoneMinder upstream.

I don't care for opt-out "telemetry" of this sort, so I added
ZM_TELEMETRY_DATA=no to the /etc/zm/zm.conf file prior to starting
ZoneMinder for the first time. Unfortunately, when I started ZM, the log
file showed these entries:

2017-03-24 23:26:56.638730 zmtelemetry[1722].INF-zmtelemetry.pl [Sending 
data to ZoneMinder Telemetry server.]
2017-03-24 23:26:56.880710 zmtelemetry[1722].INF-zmtelemetry.pl [Telemetry 
data uploaded successfully.]

Frustrating, to say the least.

I have already added ZM_CSS_DEFAULT=flat to this file successfully, so
the syntax and variable name should be correct.

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Daniel Richard G.]

Package: src:libreoffice
Version: 1:5.2.5-2

I am interested in the topic of installing LibreOffice without Java.
This is possible, of course, but this bug report is concerned with a
dependency structure that makes this needlessly messy.

A regular LibreOffice install has many Java dependencies:

# apt-get -s install libreoffice | grep '^Inst' | egrep 'jre|jdk|java'
Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all])
Inst ca-certificates-java (20161107 Debian:testing [all]) []
Inst java-common (0.58 Debian:testing [all]) []
Inst openjdk-8-jre-headless (8u121-b13-4 Debian:testing [amd64])
[long list of Java-related packages elided]

Let's try installing sans what appears to be LibreOffice's main Java-
dependency package:

# apt-get -s install libreoffice libreoffice-java-common-
[...]
The following packages have unmet dependencies:
 libreoffice : Depends: libreoffice-java-common (>= 1:5.2.5~) but it is not 
going to be installed
   Recommends: libreoffice-nlpsolver but it is not going to be 
installed
   Recommends: libreoffice-report-builder but it is not going 
to be installed
   Recommends: libreoffice-wiki-publisher but it is not going 
to be installed
E: Unable to correct problems, you have held broken packages.

Darn. Okay, can we install without pulling in the JRE?

# apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep 
'jre|jdk|java'
Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all])

Hunh, that worked. The lo-java-common package went in, even though it's
presumably useless without a Java runtime. So what about those
aforementioned components that supposedly required Java?

# apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep 
'nlpsolver|report-builder|wiki-publisher'
Inst libreoffice-report-builder-bin (1:5.2.5-2 Debian:testing [amd64])
Inst libreoffice-wiki-publisher (1.2.0+LibO5.2.5-2 Debian:testing [all])

So nlpsolver didn't go in (reasonable), only the bin package of
report-builder was installed (huh?), and wiki-publisher went in just
fine (will that even work in light of its hard dep on lo-java-common?).

This doesn't make much sense to me. I can't decline installation of
lo-java-common, but I can decline default-jre, yet some of the resulting
installed packages are useless (lo-report-buildir-bin without
lo-report-builder?) or at worse broken.

Looking through the dependencies in the various LibreOffice packages,
one issue I see is that several of them depend directly on default-jre
(or more specifically, "default-jre | openjdk-8-jre | openjdk-7-jre |
openjdk-6-jre | gcj-jre | sun-java5-jre | sun-java6-jre | java5-runtime
| jre") as well as lo-java-common, when the JRE dependency should in fact
be redundant alongside lo-java-common.

(Interestingly, libreoffice-script-provider-{bsh,js} depend on a JRE
_without_ depending on lo-java-common. Does that make sense?)

What I would like to see is for all the various LibreOffice packages
that can/must make use of Java to Depends:/Recommends:/Suggests:
lo-java-common, and then have lo-java-common Depends: default-jre et al.
That way, when installing LibreOffice, I can decline lo-java-common, the
JRE won't get pulled in, and no LibreOffice package that requires Java
(or is related to one that does) will get installed.

Bug#858080: s-nail does not Provide: mail-reader, mailx

[Daniel Richard G.]

On Sat, 2017 Mar 18 22:26+0100, Hilko Bengen wrote:
>
> > Wasn't heirloom-mailx (the predecessor of s-nail) the primary mailx
> > provider for Debian?
>
> No, that must have been bsd-mailx.

Okay, this is fair. I see that heirloom-mailx had "Priority: optional"
while bsd-mailx had this at "important".

(For my needs, then, bsd-mailx is actually what I want.)

> > In any event, h-m originally provided /usr/bin/mail and the upgrade
> > path causes this to disappear. Scripts breaking due to mail(1)
> > interface variations is a pain, but scripts breaking due to mail(1)
> > disappearing altogether is a regression.
>
> Oh, I see. There are a number of packages which  depend on heirloom-
> mailx | mailx... Those packages need some grave bugs reported,
> then. Damn.

I mean, it _is_ right in the name...

When I saw in the (current) heirloom-mailx description that "It only
contains symlinks to the s-nail binary and manpage," I thought that
meant a /usr/bin/mail -> s-nail symlink, which would have been
reasonable. But then I saw that the installed symlink was from
/usr/bin/heirloom-mailx, which is not very useful.

Why not have the transitional heirloom-mailx package provide a
/usr/bin/mail symlink? That then gives a reasonable upgrade path and
installation option even for new systems. If you just want a mailx-style
interface but no /usr/bin/mail, then you just install s-nail. If you
want both, then you install heirloom-mailx and s-nail.

(This would be like the distinction between the "esmtp" and "esmtp-run"
packages. The former provides the actual programs, the latter gives you
symlinks for /usr/sbin/sendmail et al.)

> > When I read "/usr/bin/mail interface," that implies to me that there
> > is a /usr/bin/mail executable. Was the description intended to mean
> > something like "mailx-style interface?"
>
> To be honest, I don't know. I read that as the command-line user
> interface one might know from mailx.

I think that these days, when few people still use mail(1)
interactively, the presence of /usr/bin/mail for the benefit of scripts
is a more important point than the style of the interface. IMO,
variations like -a are not significant---if one has experience from
other Unix systems, they will know that -s is about the only option that
can be used reliably anyway.

Bug#858080: s-nail does not Provide: mail-reader, mailx

[Daniel Richard G.]

Hi Hilko,

On Sat, 2017 Mar 18 10:35+0100, Hilko Bengen wrote:
>
> This is intentional, see #847049. It turned out that the /usr/bin/mail
> "interface" was not well-defined and having the alternative set to s-
> nail broke scripts provided by other packages.

Wasn't heirloom-mailx (the predecessor of s-nail) the primary mailx
provider for Debian? I don't understand why package scripts would
have broken, when they would have been prototyped using h-m in the
first place.

In any event, h-m originally provided /usr/bin/mail and the upgrade path
causes this to disappear. Scripts breaking due to mail(1) interface
variations is a pain, but scripts breaking due to mail(1) disappearing
altogether is a regression.

> > Note that the package description for bsd-mailx indicates that this
> > package (s-nail) provides /usr/bin/mail .
>
> That's not quite how I read the description. I'm open to suggestions
> for improvements, though.

When I read "/usr/bin/mail interface," that implies to me that there is
a /usr/bin/mail executable. Was the description intended to mean
something like "mailx-style interface?"

> > Also, the s-nail package in Ubuntu Xenial (14.8.6-1 as of this
> > writing) does Provide: mail-reader, mailx .
>
> I'd expect this to change by the time Ubuntu Z-whatever (17.04) is
> released: Ubuntu's s-nail package is taken from Debian -- just before
> I removed the "Provides:" header.

Ah, understood. I thought they might have tweaked the package source.


--Daniel

Bug#858080: s-nail does not Provide: mail-reader, mailx

[Daniel Richard G.]

Package: s-nail
Version: 14.8.16-1

heirloom-mailx may have been superseded by s-nail, but the latter fails
to provide the /usr/bin/mail and /usr/bin/mailx frontends as the former.

Installing bsd-mailx or mailutils will make those available, but
these packages are supposed to be alternatives to s-nail, not
supplements to it.

Note that the package description for bsd-mailx indicates that this
package (s-nail) provides /usr/bin/mail .

Also, the s-nail package in Ubuntu Xenial (14.8.6-1 as of this
writing) does Provide: mail-reader, mailx .

Bug#726148: Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined

[Daniel Richard G.]

Still seeing this in Debian Stretch.

# dpkg-reconfigure -f editor watchdog
Calling POSIX::tmpnam() is deprecated at /usr/share/perl5/Debconf/TmpFile.pm 
line 16,  line 6.
Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 6.
Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 6.
Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 8.
Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 8.
Subroutine Debconf::Element::Editor::Boolean::SUPER::value redefined at 
/usr/share/perl5/Debconf/Base.pm line 31.
Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 11.
Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 11.
Subroutine Debconf::Element::Editor::Boolean::SUPER::value redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 11.
Subroutine Debconf::Element::Editor::Boolean::SUPER::value redefined at 
/usr/share/perl5/Debconf/Base.pm line 31.
Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 14.
Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 14.
Subroutine Debconf::Element::Editor::Boolean::SUPER::value redefined at 
/usr/share/perl5/Debconf/Base.pm line 31,  line 11.
Subroutine Debconf::Element::Editor::Boolean::SUPER::value redefined at 
/usr/share/perl5/Debconf/Base.pm line 31.
update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults

Bug#827427: tumbler: Large image file causes system denial-of-service

[Daniel Richard G.]

Package: tumbler
Version: 0.1.30-1+b1

I use ristretto to view an image file in /tmp for a few seconds, then
quit, and switch to another task. Suddenly, I notice the system is 
unresponsive---
Web pages no longer scroll, the mouse moves sluggishly, switching
virtual desktops takes several seconds instead of instantly.

I check the process table. Nothing hogging the CPU. I switch to sort-by-
memory, and see that a new "tumbler" process is at the top, using
something around 6GB of RAM.

I look in /proc/$PID/fd/, and see that it has open what appears to be an
old ImageMagick temp file in /tmp. A little examination...

$ file /tmp/magick-1507aN2NBN8aASXP1
/tmp/magick-1507aN2NBN8aASXP1: PNG image data, 91905 x 18168, 8-bit/color 
RGBA, non-interlaced

...pretty much spells out what was going on.

This tumbler daemon needs to have reasonable safeguards so that it
doesn't tank the system when it encounters an unreasonably-sized image
file like the above.

(FYI, this file is ~12MB, so it is not huge in terms of raw file size.)

Bug#825244: nslcd: Allow arbitrary maps via getent.ldap(1)

[Daniel Richard G.]

On Fri, 2016 Jun  3 14:21+0200, Arthur de Jong wrote:
>
> The tricky bit here is that autofs, while partially configured in
> /etc/nsswitch.conf does not use the C library NSS layer for these
> lookups. You can use LDAP to export automounter maps but these will
> not go through nslcd.
>
> Maybe I don't understand your use case completely.

The goal is, as you later mention, to centralize the LDAP configuration
in nslcd. I want /etc/nslcd.conf to have all the LDAP server-related
configuration (including SSL cert info in my setup), and have everything
else talk to the Unix socket.

I don't know about autofs not using proper NSS calls, but in theory
you can point it to nslcd's Unix socket as well. (I already do this
with nscd.)

For autofs, I'm using "program" maps (i.e. a script that, given a key,
returns a mount path), which are more flexible. What I want is a command
I can call in there that will do an LDAP query via nslcd---instead of,
say, a standalone invocation of ldapsearch(1) with most of the config
stuff in nslcd.conf duplicated.

> The problem here is that this also does not go through the NSS
> subsystem so will not reach nslcd.

Note that part of my request is to enable getent.ldap(1) to query these
custom maps, so the query *would* go through nslcd, even though NSS has
no concept of them. Making it possible to set up arbitrary maps [without
needing to hard-code them in] is the goal.

> Extracting these pictures and updating local copies should be pretty
> simple with a small script.

Not so simple when the company has over 10K users :]

> A long time ago I made something like that for gdm (probably no longer
> works with the most recent version), see
> https://arthurdejong.org/ldapgdmfaces/

I was thinking of something along these lines for LightDM. But it
would be something that returns just a single photo, not all the
photos in LDAP.

> At one point I did have a look into providing an autofs lookup module
> that would direct requests to nslcd but the main benefit would be to
> centralise configuration while that may not always be what you want
> (e.g. having automounter maps on a different LDAP server than user
> accounts).

This would be worthwhile. Centralizing configuration is very helpful,
especially for a fire-and-forget system facility like LDAP. If you have
mount maps on a different server, then, well, you can't centralize two
(or more) configs into one... that's less of a counterargument than it
is an orthogonal use case. And at least in my (quite large)
organization, it's still one all-powerful LDAP server, not a bunch of
LDAP fiefdoms.

> I would gladly help integrating an autofs lookup module and
> automounter map support in nslcd but for me personally the current
> software solution works without any real problems.

Well, what I'm asking for is something more general. It could be used to
implement an autofs backend, or the user-photo lookup, or any number of
other things. At present, the best I can do is call ldapsearch(1) with a
dozen or so arguments, post-process it with Perl, and return the requested
nugget of information.

> For some background see:
>   https://bugs.debian.org/638007

In theory, arbitrary maps could be used to implement support for
sudo-ldap without requiring modifications to nslcd.

> Anyway, patches for implementing automounter lookups in nslcd and
> perhaps an autofs lookup module are welcome and I will do my best to
> try to integrate them into nss-pam-ldapd.

Again, automount maps are just an example. What I'm after is a
general facility. I think quite a few folks would find that useful.

Bug#824293: closed by Eduard Bloch <bl...@debian.org> (Bug#824293: fixed in apt-cacher-ng 0.9.3-1)

[Daniel Richard G.]

Hi Eduard,

I'm afraid I'm still seeing some issues with 0.9.3.

First, the misbehaving "Check all" button. I've confirmed that marking
every checkbox manually (using Space-Tab repeatedly) does not give the
same result as "Check all"; the latter results in a much larger list of
files to delete. Furthermore, hitting "Check all" even when there are no
checkboxes on the page (!) results in a long list of files to delete.
And as before, the files to be deleted with "Check all" include numerous
current index files for amd64 and i386, which is clearly incorrect.

Without using "Check all", I manually selected all the phantom exotic-
architecture index files that were causing me grief earlier and deleted
them. Re-scanning for expiration did not, as before, bring them back.
However, for good measure I did another scan with hash checking, and
this unfortunately brought back the 404 errors for the exotic-arch
index files.

One other thing I noticed: A number of files related to debian-installer
gave "checksum mismatch" errors, but I'm not sure if that is
appropriate. Here is the list:

debian/dists/jessie/main/installer-amd64/current/images/MD5SUMS
debian/dists/jessie/main/installer-amd64/current/images/netboot/mini.iso
debian/dists/jessie/main/installer-i386/current/images/MD5SUMS
debian/dists/jessie/main/installer-i386/current/images/netboot/mini.iso
debian/dists/sid/main/installer-amd64/current/images/SHA256SUMS
debian/dists/sid/main/installer-amd64/current/images/netboot/mini.iso
debian/dists/stable/main/installer-i386/current/images/netboot/mini.iso
debian/dists/wheezy/main/installer-amd64/current/images/netboot/mini.iso
debian/dists/wheezy/main/installer-i386/current/images/MD5SUMS
debian/dists/wheezy/main/installer-i386/current/images/netboot/mini.iso
ubuntu/dists/vivid/main/installer-amd64/current/images/netboot/mini.iso
ubuntu/dists/vivid/main/installer-i386/current/images/netboot/mini.iso

Unlike package files, these don't have version numbers in the names. Yet
they are updated from time to time. It doesn't seem right to call them
"damaged" when they are at most out of date; might some special-case
handling be in order?

Bug#825153: nslcd: Numerous '

[Daniel Richard G.]

On Wed, 2016 May 25 22:54+0200, Arthur de Jong wrote:
>
> Good find. Thanks for tracking this down!

Getting the PID of the requesting process was the piece I was missing :)

> > > Would you agree that this appears to be a bug in bash-completion?
>
> I would think so. Please file a bug against bash-completion.

Filed as #825317.

Cursory testing after a manual fix shows no more "*" queries. That gets
rid of the need to mitigate the resulting log entries, so unless
something else starts making bad queries and can't be fixed, this bug
report may be closed. Thank you for your help!

Bug#825317: bash-completion: Un-escaped "~*" leads to spurious NSS lookups

[Daniel Richard G.]

Package: bash-completion
Version: 1:2.1-4.3
Severity: minor

Bug #825153 (mysterious "*" passwd queries in LDAP) turned out to be the
result of a minor thinko in bash-completion.

The _quote_readline_by_ref() shell function uses "~*" without the tilde
being escaped (like all other instances of same), resulting in a
getpwnam() lookup for a user named "*". If NSS lookups are going to
files, then this is no big deal. But this is occurring in a setup where
such queries go to LDAP, and as "*" is not valid syntax for a username,
the query is rejected and logged. And there are a _lot_ of log entries
coming from this bug.

Note that the issue is not even in the upstream bash-completion source,
but in a Debian patch:

debian/patches/00-fix_quote_readline_by_ref.patch

Bug#825244: nslcd: Allow arbitrary maps via getent.ldap(1)

[Daniel Richard G.]

Package: nslcd
Version: 0.9.6-3
Severity: wishlist

I would like for it to be possible to configure nslcd so that
getent.ldap(1) can return information not covered by the current maps.
Here are three use cases:

1. Alternate "home" directories. I'm in a company subdivision where
   employees have departmental home directories, something like

 map passwd homeDirectory "/home/$sAMAccountName"

   where /home is NFS-mounted from our own server. But there is also
   another set of homedirs, ones that are global to the company but are
   tightly quota-bound and thus not as useful. I want to have an autofs
   mount for these so that they are accessible, but I need to query a
   "unixHomeDirectory" attribute in LDAP (homedirs are spread across
   multiple servers so I can't just construct a path from the username)
   and the "homeDirectory" slot is already spoken for.

   For now, I am (ab)using the "userPassword" attribute in the "shadow"
   map to get this information, but that's an awkward one-off at best.

2. User pictures. My company LDAP server has a "thumbnailPhoto"
   attribute for each user, which is some kind of base64-encoded image
   that is likely the same user photo shown in the Outlook mail client.
   It would be lovely to show this as a "user picture" in LightDM, or
   perhaps elsewhere in the Linux desktop, without needing to configure
   a separate LDAP client to get at it.

3. Automount maps in general. An "automount" map is supported by
   libnss-ldap, and while first-class support for this in libnss-ldapd
   would be nice, I can foresee greater flexibility in being able to
   specify multiple sources for automount definitions (e.g.
   "automount1", "automount2", ...)

Bug#825153: nslcd: Numerous '

[Daniel Richard G.]

On Tue, 2016 May 24 22:42+0200, Arthur de Jong wrote:
> 
> At the very least it is weird behaviour. I don't expect any NSS module
> would return useful information. It could be a compat lookup thing but
> I thought it only worked on "+" entries, not "*" and those entries are
> only supported in flat files (/etc/passwd, /etc/shadow).
>
> If you could track it down I would be very interested to know why some
> application would do that. If this is some kind of standard use of the
> API I'm not aware of perhaps that would be an argument to change the
> behaviour of nslcd.
>
> Running nslcd in debug mode will show application pids that perform
> the request, that will probably help in tracking it down.

Ah, yes, that is very helpful. I have some information for you.

The culprit here is Bash, although what specifically within Bash is
harder to suss out. The issue does appear to be in the bash_completion
logic, because if I disable that, the "*" requests go away.

The completion logic is about as close to line noise as typical Perl, so
I can't make much headway in there. But strace shows a connect() call to
the nslcd socket for each request, and no other connect()s, so I ran a
debug build of bash in a debugger.

After picking through the backtrace, I've found exactly what is
generating the request. Below, I've copied the entire shell function in
question (from /usr/share/bash-completion/bash_completion), and have
marked the offending line:

# This function quotes the argument in a way so that readline dequoting
# results in the original argument.  This is necessary for at least
# `compgen' which requires its arguments quoted/escaped:
#
# $ ls "a'b/"
# c
# $ compgen -f "a'b/"   # Wrong, doesn't return output
# $ compgen -f "a\'b/"  # Good
# a\'b/c
#
# See also:
# - http://lists.gnu.org/archive/html/bug-bash/2009-03/msg00155.html
# - http://www.mail-archive.com/bash-completion-devel@lists.alioth.\
#   debian.org/msg01944.html
# @param $1  Argument to quote
# @param $2  Name of variable to return result to
_quote_readline_by_ref()
{
if [ -z "$1" ]; then
# avoid quoting if empty
printf -v $2 %s "$1"
elif [[ $1 == \'* ]]; then
# Leave out first character
printf -v $2 %s "${1:1}"
elif [[ $1 == ~* ]]; then< HERE
# avoid escaping first ~
printf -v $2 ~%q "${1:1}"
else
printf -v $2 %q "$1"
fi

# Replace double escaping ( \\ ) by single ( \ )
# This happens always when argument is already escaped at cmdline,
# and passed to this function as e.g.: file\ with\ spaces
[[ ${!2} == *\\* ]] && printf -v $2 %s "${1///\\}"

# If result becomes quoted like this: $'string', re-evaluate in order to
# drop the additional quoting.  See also: http://www.mail-archive.com/
# bash-completion-de...@lists.alioth.debian.org/msg01942.html
[[ ${!2} == \$* ]] && eval $2=${!2}
} # _quote_readline_by_ref()


There are other instances of "~*" in the file, but they all have a
backslash escaping the tilde.

Would you agree that this appears to be a bug in bash-completion?

Bug#825153: nslcd: Numerous '

[Daniel Richard G.]

On Tue, 2016 May 24 20:47+0200, Arthur de Jong wrote:
>
> I'm not really sure what triggers it but I also see this in the logs a
> lot. I just ignore it. It could be that nscd makes it more difficult
> to trigger because it sometimes also caches negative hits.
> Furthermore, the application may be caching it.

Ah, yes, that makes sense. I'm using nscd as well.

> > I claim ignorance as to why this request occurs (is this really
> > supposed to return a list of all users?)
>
> No, I'm pretty sure it is some sort of lookup that is meant to return
> nu users at all or a misconfiguration somewhere.

If I can find what is doing this, should the behavior be
considered a bug?

(I'd be happy to file a report, as long as the maintainer is not likely
to respond with "working as designed, closing.")

> To not report it as an invalid name you could set validnames to
>
> /^[a-z0-9._@$()*]([a-z0-9._@$() \\~-]*[a-z0-9._@$()~-])?$/i
>
> but that is a bit ugly and it results in a useless LDAP search
> each time.

Yes, I'd want to avoid the extra network chatter (and server load, once
you're talking about many clients).

Bug#825153: nslcd: Numerous '

[Daniel Richard G.]

Package: nslcd
Version: 0.9.6-3
Severity: minor

I am seeing relatively frequent entries of this form in syslog:

May 24 03:04:23 darkstar nslcd[1187]: [3c9869] 

Bug#824293: apt-cacher-ng: "Problem with" non-existent index files

[Daniel Richard G.]

On Sat, 2016 May 14 22:11+0200, Eduard Bloch wrote:
>
> Yes, they are gone. And the expiration algorithm should to ignore them
> if a better version is found, i.e. Packages.xz. Just like apt does.
> Such files are also stored there when the pdiff patcher recreated a
> copy using pdiff patches so the next run can take this version as base
> for patching.
>
> Do you see any problem with that files?

These "Packages" files had a parallel .xz version in the cache, and also
a .gz on the upstream server. Now that you mention it, it's possible the
uncompressed files were the result of pdiff patching... although
wouldn't there not be .head files then?

Whatever their provenance, acng should not have sent out e-mail about
them. The 404 errors were either expected (when the uncompressed file is
a creation of acng that does not exist on the server) or non-fatal
(when other forms of the same index file are present for expiration
purposes). Neither situation should require intervention from the admin.

> > Unlike the previous situation, none of these index files exist on
> > the upstream server. I only have empty files (and no .head file)
> > for each.
>
> Maybe because it's arm64 and many mirrors don't contain it? Do have
> arm64 clients?

Correct, my mirrors certainly don't have those files. There were also
empties for armhf, s390x, etc. and I don't have clients on those either.

> Please share more information: which mirror, what's else inside of
> your cache ("find /var/cache/apt-cacher-ng").

I'm just using the "primary" U.S. mirror servers, http.us.debian.org and
us.archive.ubuntu.com. There are other repositories as well, but the
problem is already observable with these.

> The new extension in 0.9.2 identifies a by-hash/... file referenced by
> InRelease file then it creates an empty file there. This is designed
> specially for the case where user installs xenial with their recent
> apt which does not bother to download Packages.xz from the original
> location so the file is not created ever (not visible to proxy) and
> eventually cache maintenance starts cleaning "unreferenced" stuff.

I do notice that [Ubuntu xenial] InRelease lists a bunch of things that
are actually not available from the "primary" mirror, like binary-
arm64/*, binary-powerpc/*, etc. Is acng assuming that a mirror server
can provide everything that is in InRelease?

> > I did recall seeing during a manual scan/expiration shortly after
> > installing 0.9.2 that acng was "touching" a lot of index files. I
> > suspect it was doing so in the sense of creating empty files rather
> > than just updating timestamps.
>
> "touching" means what touch(1) does.

Okay, so acng creates those empty files. It shouldn't complain, then, if
it can't download those files from the upstream. Just because InRelease
describes X doesn't mean that X can actually be downloaded from that
(same) server, at least in the Ubuntu case.

> > And if that weren't enough, when I went to the expiration page and
> > hit "Check all" and then "Delete selected" to clean up this mess,
> > the resulting list on the confirmation page included numerous valid
> > index files for amd64/i386---even though they did exist upstream,
> > had been
>
> Please send the resulting web page, my crystal ball is broken.

It's pretty big. My point is, "Check all" appears to select more files
than just those with a checkbox. None of the amd64/i386 index files had
trouble downloading, so none of those had checkboxes, and yet there they
are on the delete-confirmation page after "Check all."

> > downloaded correctly, and did not have a "Tag" checkbox on the
> > expiration page. It was even going to delete files like
> > ubuntu/dists/xenial/Release!
>
> Checkbox is displayed only once per file, maybe you needed to scroll
> up to find the first one?

I looked through the whole list, and didn't see a checkbox for any
amd64/i386 index file. And the Release file didn't have a checkbox,
because it was downloadable.

(Isn't the fact that acng was about to expire-delete the Release file
for the current Ubuntu release a pretty clear indicator in itself that
something's not right? Sure, maybe if all files on the upstream server
suddenly disappeared. But short of something extraordinary like that,
this should never happen.)

> > I ended up deleting these files from the cache manually, but as soon
> > as I ran another scan, there they were again.
>
> Correct. That's why I would like to see what exactly was found in
> your cache.

I'll send you some telemetry soon, probably off-list due to its bulk.
The behavior is consistently reproducible, much to my aggravation, but
at least that should make catching it easy.

Bug#824293: apt-cacher-ng: "Problem with" non-existent index files

[Daniel Richard G.]

Package: apt-cacher-ng
Version: 0.9.2-1

Previously, with 0.9.1-1, I have been getting these e-mails daily:

/etc/cron.daily/apt-cacher-ng:
Maintenance Task: Expiration
See file /var/log/apt-cacher-ng/maint_1463136764.log.html for more 
details.
Server url: 
http://localhost:3142//acng-report.html?doExpire=Start+Expiration=aOe
Problem with debian/dists/sid/main/binary-amd64/Packages
Problem with debian/dists/sid/main/binary-armel/Packages
Problem with debian/dists/sid/non-free/binary-amd64/Packages
Problem with debian/dists/sid/non-free/binary-armel/Packages

This was no big deal, a case of index files actually disappearing on the
upstream server. (I had real content and .head files for these in the
cache, with recent timestamps.) I was going to write in to request
better automagic handling of this situation, since I eventually had to
go in and delete these files on the expiration page to stop the e-mails.
(I figure, if you can download other things from that server, those 404s
are unlikely to be transient.)

However, I upgraded to 0.9.2-1 for the by-hash goodness, and now I see
this in my inbox:

/etc/cron.daily/apt-cacher-ng:
Maintenance Task: Expiration
See file /var/log/apt-cacher-ng/maint_146383.log.html for more 
details.
Server url: 
http://localhost:3142//acng-report.html?doExpire=Start+Expiration=aOe
Problem with 
ubuntu-security/dists/xenial-security/restricted/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu-security/dists/xenial-security/multiverse/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu-security/dists/xenial-security/universe/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial-proposed/multiverse/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial-proposed/restricted/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial-updates/multiverse/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial-updates/restricted/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial-proposed/universe/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu-security/dists/xenial-security/restricted/binary-arm64/Packages.xz
Problem with 
ubuntu-security/dists/xenial-security/multiverse/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial/restricted/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial/multiverse/debian-installer/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial-proposed/multiverse/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial-proposed/restricted/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial-updates/restricted/binary-arm64/Packages.xz
Problem with 
ubuntu/dists/xenial-updates/multiverse/binary-arm64/Packages.xz
Problem with ubuntu/dists/xenial/restricted/binary-arm64/Packages.xz
Problem with 
ubuntu-security/dists/trusty-security/multiverse/debian-installer/binary-arm64/Packages.gz
Problem with 
ubuntu-security/dists/trusty-security/restricted/debian-installer/binary-arm64/Packages.gz
Problem with 
ubuntu-security/dists/xenial-security/restricted/debian-installer/binary-arm64/Packages.gz
Problem with 
ubuntu-security/dists/xenial-security/multiverse/debian-installer/binary-arm64/Packages.gz
Problem with 
ubuntu-security/dists/xenial-security/universe/debian-installer/binary-arm64/Packages.gz
Problem with 
ubuntu-security/dists/xenial-security/restricted/debian-installer/binary-armhf/Packages.xz
Problem with 
ubuntu-security/dists/xenial-security/multiverse/debian-installer/binary-armhf/Packages.xz
Problem with 
ubuntu-security/dists/xenial-security/universe/debian-installer/binary-armhf/Packages.xz
Problem with 
ubuntu/dists/xenial-proposed/restricted/debian-installer/binary-armhf/Packages.xz
Problem with 
ubuntu/dists/xenial-proposed/multiverse/debian-installer/binary-armhf/Packages.xz
Problem with 
ubuntu/dists/xenial-updates/multiverse/debian-installer/binary-armhf/Packages.xz
[...]

(That's about one-fifth of the message.)

Unlike the previous situation, none of these index files exist on the
upstream server. I only have empty files (and no .head file) for each.

I did recall seeing during a manual scan/expiration shortly after
installing 0.9.2 that acng was "touching" a lot of index files. I
suspect it was doing so in the sense of creating empty files rather than
just updating timestamps.

And if that weren't enough, when I went to the expiration page and hit
"Check all" and then "Delete selected" to clean up this mess, the
resulting list on the confirmation page included numerous valid index
files for amd64/i386---even though they did exist upstream, 

Bug#823568: krb5-auth-dialog: Don't autostart for non-Kerberos users

[Daniel Richard G.]

On Fri, 2016 May 13 12:22+0200, Guido Günther wrote:
> > 
> > I can just click on the little systray icon. How is the notification
> > necessary for me to get a ticket? (I am using the program under
> > Xfce, if that makes a difference.)
>
> Only if there is such an icon. E.g. GNOME relies solely on
> notifiations (which, at least there, is a good thing).

Oh. Okay. That's a different way of doing things...

> Yeah, I agree that the startup case should better indicate that the
> user does not have any creds, not that they're expired.

That would be great.

On a similar note, regarding the man page description for the --auto
option:

If this option is specified, krb5-auth-dialog will exit if it finds
that the user has no Kerberos credentials.

This could be misread as stating that the program will exit at a later
time when the user's credentials expire. I would at least add the words
"at startup" or "when it starts." Alternately, I'd suggest this
elaborated wording:

If this option is specified, krb5-auth-dialog will start only if it
finds that the user has Kerberos credentials. This may be used to
ensure that only users who actually use Kerberos see the program.
(Note that in some settings, users may authenticate to Kerberos at a
later time even if they do not have Kerberos credentials initially.)

> The Systray icon is a bandaid. On a proper integrated desktop it
> should not be needed to get a ticket.

Xfce may not be that, but in that environment, the systray icon works
perfectly :]

Bug#823568: krb5-auth-dialog: Don't autostart for non-Kerberos users

[Daniel Richard G.]

On Sun, 2016 May  8 11:28+0200, Guido Günther wrote:
> >
> > I would not mind having the program run for all users, but for the
> > "credentials expired" notification. Is there a reason to give that
> > message on startup when no credentials (not even expired ones) are
> > present?
>
> Yes, this gives you the persistent notification in GNOMEs notification
> area that allows you to grab a ticket via mouse click (in contrast to
> getting it via the API).

I can just click on the little systray icon. How is the notification
necessary for me to get a ticket? (I am using the program under Xfce, if
that makes a difference.)

Bear in mind, strictly speaking, it is incorrect for the program to
report "credentials expired" when a non-Kerberos user logs in---because
no credentials (even expired/invalid ones) are present at all. It's like
telling someone who has never had a passport in their life that their
passport is expired. That's going to be quite confusing for them.

> The current behaviour is reasonable under the objective that you want
> to give the user an easy way to fetch a ticket at any time and not all
> applications being able to request a ticket via the DBus API.

I don't understand why you're bringing up the DBus API. Yes, some
applications can request krb5-auth-dialog get the user's password and
then Kerberos tickets. But there is a systray icon that is independent
of DBus, and the user can click on it whenever they like, and that is
about as easy as it gets.