Bug#1079735: libglib2.0-0t64: "Exec format error" in foreign-arch installation

[Daniel Richard G.]

On Tue, 2024 Aug 27 05:10-04:00, Simon McVittie wrote:
>
>> The postinst script should check that the package is being installed
>> on a compatible architecture before running these (binary) programs.
>
> How? We cannot know whether running a foreign-architecture executable
> is possible on the current architecture (perhaps natively, perhaps via
> qemu-user-binfmt or box86 or similar) other than by trying it.

If running the actual binary is the only viable way of checking
whether or not it is usable, then do so explicitly with a trivial
invocation, e.g.

if ! /usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas --version 
>/dev/null 2>&1
then
  # System architecture is probably incompatible
  echo 'Cannot run glib-compile-schemas, skipping update'
  exit 0
fi

(Even better would be to detect the package_arch != system_arch
condition and print out a more specific error message, but I don't know
the right way of getting that info in a postinst script.)

That at least avoids showing an error message to the user that is, to
all appearances, not anticipated/handled by the package installation.

Bug#1079737: libgtk-3-0t64: "Exec format error" in foreign-arch installation

[Daniel Richard G.]

Package: libgtk-3-0t64
Version: 3.24.43-3

I am installing this package as a cross-compilation dependency for an
amd64-to-armhf build. In the install log, I see

Setting up libgtk-3-0t64:armhf (3.24.43-3) ...
/var/lib/dpkg/info/libgtk-3-0t64:armhf.postinst: 17: 
/usr/lib/arm-linux-gnueabihf/libgtk-3-0t64/gtk-query-immodules-3.0: Exec format 
error

The postinst script should check that the package is being installed on
a compatible architecture before running this (binary) program.

Bug#1079736: libgdk-pixbuf-2.0-0: "Exec format error" in foreign-arch installation

[Daniel Richard G.]

Package: libgdk-pixbuf-2.0-0
Version: 2.42.12+dfsg-1

I am installing this package as a cross-compilation dependency for an
amd64-to-armhf build. In the install log, I see

Setting up libgdk-pixbuf-2.0-0:armhf (2.42.12+dfsg-1) ...
/var/lib/dpkg/info/libgdk-pixbuf-2.0-0:armhf.postinst: 30: 
/usr/lib/arm-linux-gnueabihf/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: Exec 
format error

The postinst script should check that the package is being installed on
a compatible architecture before running this (binary) program.

Bug#1079735: libglib2.0-0t64: "Exec format error" in foreign-arch installation

[Daniel Richard G.]

Package: libglib2.0-0t64
Version: 2.82.0-1

I am installing this package as a cross-compilation dependency for an
amd64-to-armhf build. In the install log, I see

Setting up libglib2.0-0t64:armhf (2.82.0-1) ...
/var/lib/dpkg/info/libglib2.0-0t64:armhf.postinst: 37: 
/usr/lib/arm-linux-gnueabihf/glib-2.0/glib-compile-schemas: Exec format error
/var/lib/dpkg/info/libglib2.0-0t64:armhf.postinst: 38: 
/usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules: Exec format error

The postinst script should check that the package is being installed on
a compatible architecture before running these (binary) programs.

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

[Daniel Richard G.]

On Wed, 2024 Aug 14 08:31-04:00, Jeremy Bícha wrote:
>
> I think it would be as simple for you as to build the harfbuzz package
> with this addition to the dh_auto_configure build-main line:
> --default-library both
>
> And then add the .a file to debian/libharfbuzz-dev.install
>
> Since you already have to build harfbuzz yourself to get the subset
> library, I think you should just make that change to your harfbuzz
> package.

I made a similar change (enabling only the static library) and built the
package myself out of immediate need. But the point of Debian is to be a
distro, not Linux From Scratch.

There are two reasons aside from that immediate need for which I've
filed this bug:

1. Avoiding the need to modify the package. This may not sound like
   much, but in the context of supply-chain tampering and
   vulnerabilities, being able to use Debian's vetted source verbatim
   simplifies the review process considerably;

2. Taking a step toward being able to produce a Chromium binary
   build for jammy that will also run on noble (where an ABI-
   compatible library is not available). This is why libdav1d-dev is
   also a concern.

> I don't see a need to make a change to the current Debian packaging to
> fix an issue that doesn't actually exist in Debian Unstable/Ubuntu
> 24.10. The real issue is that the subset library isn't built for older
> distros but it is built for current distros.

Debian software would not be very useful if it were limited to solving
problems within Debian. Static libraries lend themselves to a number of
use cases, which include overcoming limitations of the packaging.


--Daniel

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

[Daniel Richard G.]

On Mon, 2024 Aug 12 15:21-04:00, Jeremy Bícha wrote:
>
> No, they don't. There definitely are several C libraries that do
> include a static library in Debian, but most of the C libraries I
> maintain do not.

Of the 57 lib*-dev libraries that chromium lists in its Build-Deps, all
of which appear to be C/C++ libraries, 19 do not have lib*.a libraries.
And only two are of concern with my builds (harfbuzz and dav1d).

> It's going to be a bit painful to try to use a newer/different system
> library than provided by the system if you're not going to use a
> sandboxed approach. However, it sounds like you figured out a working
> solution.

Yes; my solution was to work around the missing static library, and
report the issue to Debian so that it can be fixed.

> Hopefully, you don't need to maintain support for older distros for
> very long.

How long is jammy being supported? As long as I don't have to provide
half the world as build deps, that would be the ideal.

> In this case, it's not that you need a new library; it's that Debian
> didn't enable the subset feature earlier. Sorry about that.

It's all the same from my perspective...

> Sorry, I don't see enough demand for harfbuzz to be distributed as a
> static library for me to make that change in the Debian packaging at
> this time.

What kind of quorum are you looking for? It's not like this package gets
much in the way of bug reports in general, after all. I think I've made
a reasonable case for including a static build.

(If you want to argue that this package is complex enough that adding a
static build is a fair amount of work, then that's a different story,
of course.)


--Daniel

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

[Daniel Richard G.]

Hi Jeremy,

On Mon, 2024 Aug 12 10:46-04:00, Jeremy Bícha wrote:
> The vast majority of libraries packaged in Debian do not include .a files.

Most e.g. Rust library packages don't, sure. But normal C/C++ lib*-dev
packages typically include a static library.

> It sounds to me like your real issue is that you are attempting to use
> newer libraries on a distro that doesn't provide those libraries.

Indeed, this is a good use case for static libraries.

> You have some additional options beyond the workaround you
> implemented:
>
> - Encourage your users to switch to Snap or Flatpak for much easier
> dependency handling for older distros. This is what Canonical did with
> Firefox, Chromium, and Thunderbird

I am providing .deb packages of those applications for users who don't
want to deal with Snap or Flatpak. Including myself :)

> - Also package the libraries you need in a PPA or similar repository.
> This is a bit more complex to handle the initial user install. You're
> also responsible for providing security support for the library.
> Hopefully, it doesn't interact badly with the rest of the system. It
> could cause users difficulties on upgrading to new versions of their
> OS.

My goal is to provide the application, not the library. As you can see,
providing the library generally would be a much bigger/riskier deal than
just using it as a build-dep.


--Daniel

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

I did another round of debugging, and have some new findings to report.

To start with, I put a breakpoint on OnNoMemoryInternal(). That works
better than trying to catch the SIGILL. However, this failure mode has
been relatively infrequent with my modified 126.0.6478.126 build.

More common lately has been a straight segfault related to Mojo that
invariably brings down the entire browser. Here is a typical example:

Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f92e4ff8480 (LWP 876682)]
0x55c72dfed9c2 in 
mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept(mojo::Message*)
 ()
(gdb) bt
#0  0x55c72dfed9c2 in 
mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept(mojo::Message*)
 ()
#1  0x55c72dff5314 in mojo::MessageDispatcher::Accept(mojo::Message*) ()
#2  0x55c72dfefbed in 
mojo::InterfaceEndpointClient::HandleIncomingMessage(mojo::Message*) ()
#3  0x55c72dff9496 in 
mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper*,
 mojo::internal::MultiplexRouter::ClientCallBehavior, 
base::SequencedTaskRunner*) ()
#4  0x55c72dff8c73 in 
mojo::internal::MultiplexRouter::Accept(mojo::Message*) ()
#5  0x55c72dff5314 in mojo::MessageDispatcher::Accept(mojo::Message*) ()
#6  0x55c72dfeb74e in 
mojo::Connector::DispatchMessage(mojo::ScopedHandleBase) ()
#7  0x55c72dfebeda in mojo::Connector::ReadAllAvailableMessages() ()
#8  0x55c72d7e03ff in 
base::TaskAnnotator::RunTaskImpl(base::PendingTask&)
()
#9  0x55c72d801667 in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() 
()
#10 0x55c72d873e6a in base::(anonymous 
namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) ()
#11 0x7f92e80b97a9 in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x7f92e80b9a38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7f92e80b9acc in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x55c72d872c00 in 
base::MessagePumpGlib::Run(base::MessagePump::Delegate*) ()
#15 0x55c72d802190 in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool,
 base::TimeDelta) ()
#16 0x55c72d7c18a9 in base::RunLoop::Run(base::Location const&) ()
#17 0x55c72adc4fda in content::BrowserMainLoop::RunMainMessageLoop() ()
#18 0x55c72adc114d in content::BrowserMain(content::MainFunctionParams) 
()
#19 0x55c72ca25b49 in 
content::ContentMainRunnerImpl::RunBrowser(content::MainFunctionParams, bool) ()
#20 0x55c72ca25637 in content::ContentMainRunnerImpl::Run() ()
#21 0x55c72ca221a4 in content::ContentMain(content::ContentMainParams) 
()
#22 0x55c7284eafc5 in ChromeMain ()
#23 0x7f92e644624a in __libc_start_call_main (
main=main@entry=0x55c7284eac60 , argc=argc@entry=8, 
argv=0x7ffdc854dc48, argv@entry=0xec0002740e0)
at ../sysdeps/nptl/libc_start_call_main.h:58
#24 0x7f92e6446305 in __libc_start_main_impl (main=0x55c7284eac60 
, 
argc=8, argv=0xec0002740e0, init=, fini=, 
rtld_fini=, stack_end=0x7ffdc854dc38)
at ../csu/libc-start.c:360
#25 0x55c728167021 in _start ()

Right before, I'll get a message on the terminal like

[885352:885352:0709/095917.737560:ERROR:interface_endpoint_client.cc(722)] 
Message 0 rejected by interface viz.mojom.Gpu

[890042:890062:0709/222611.345773:ERROR:interface_endpoint_client.cc(722)] 
Message 0 rejected by interface blink.mojom.Blob

I suspect this is a bug that is being tickled by the memory pressure
(because otherwise everyone would be complaining about a crashing
browser). Could use some guidance on what to poke in GDB/chromium to get
some useful information out.

One other oddity I've noticed: I often keep the browser's Task Manager
window running on the side. I've noticed numerous cases where the
"Browser" process's "Memory footprint" column hovers around ~350 MB,
then spikes to ~850 MB for several seconds, then drops back down to
~350. This is with no visible activity in the browser that could explain
it, like the loading of a new page. Memory allocations break very easily
while this stat is elevated, as you'd expect.

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

[Daniel Richard G.]

A couple of updates:

* Tim fixed ThinLTO on ppc64el via fix-clang-selection.patch, added in
  the 123.0.6312.86 release.

* Thanks to bug #1072299, I've built chromium 126.0.6478.126 for
  bookworm for my own usage/testing, and in addition to the allocator
  tweak suggested in that thread, I enabled ThinLTO. Here are the tweaks
  currently needed on stable to avoid subsequent build breakage:

--- a/build/config/compiler/BUILD.gn
+++ b/build/config/compiler/BUILD.gn
@@ -772,10 +772,6 @@ config("compiler") {
   if (is_apple) {
 ldflags += [ "-Wcrl,object_path_lto" ]
   }
-
-  # 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(crbug.com/335365324): Enable on other platforms.
--- a/build/config/rust.gni
+++ b/build/config/rust.gni
@@ -75,7 +75,7 @@ declare_args() {
   #
   # TODO(crbug.com/40281834): Re-enable ThinLTO for Rust on LaCrOS
   # TODO(b/300937673): Re-enable ThinLTO for Rust on ash-chrome
-  toolchain_supports_rust_thin_lto = !is_chromeos
+  toolchain_supports_rust_thin_lto = false
 
   # Any extra std rlibs in your Rust toolchain, relative to the standard
   # Rust toolchain. Typically used with 'rust_sysroot_absolute'

(The stable version of Rust appears not capable of LTO.)

So far, I haven't noticed any ill effects in my "production" home
environment... a laptop with 3 GB RAM, and chrome://discards showing 691
tabs :]  (But I can't say it feels noticeably snappier, either. Some
kind of browser-performance benchmarking is probably in order...)

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

On Tue, 2024 Jun 25 14:26-04:00, Andres Salomon wrote:
>
> That backtrace makes sense; it's running OnNoMemoryInternal(), which 
> calls PA_IMMEDIATE_CRASH(), which generates an invalid opcode customized 
> for various architectures (ironically to provide a better backtrace 
> compared to calling abort() or something).
>
> It's a maze of #ifdefs, but it appears that on x86, it calls 'int3' 
> (which should emit SIGTRAP), followed by 'ud2' (undefined instruction). 
> You can probably get gdb to catch the SIGTRAP, but that honestly doesn't 
> help diagnose _why_ you're running out of memory.

Even though GDB didn't catch all the crashes, the circumstantial
evidence of all of them going through OnNoMemoryInternal() is
pretty strong.

> I don't know how chromium handles GPU memory, but I wonder if the issue 
> is that GPU memory can't be swapped, and the partition allocator is just 
> grabbing way too much of it and wasting it?
>
> Try changing the following in 
> base/allocator/partition_allocator/src/partition_alloc/partition_alloc_constants.h
>  
> , around line 144:
>
> constexpr size_t kMaxPartitionPagesPerRegularSlotSpan = 4;
>
> Change that value to be 3 or 2, and see if that helps. Keep in mind by 
> doing this you're trading memory for speed, so memory allocations might 
> be a bit slower.

Yep, I put the build-reproducibility issue aside, and built with this
set to 2. (I also set use_thin_lto=true, in hopes of getting a small
speed boost.)

The difference is pretty stark, feels like an order of magnitude fewer
crashes compared to the stock build. I can do the kind of aggressive
browsing that previously took it down, and it keeps going. I've counted
only two crashes so far, in quick succession on the same complex Web
page, across multiple hours of use.

I tried putting together a quick-and-dirty patch that allows setting the
value via an environment variable, but the value gets used in a lot of
other constexpr's, as well as array sizes, etc. (it's practically a
#define). Do you think a patch is ultimately the way to go, or would the
upstream be receptive to improving [configurability of] low-memory
behavior?

> If that doesn't help, it could also be that the CreateSharedImage() code 
> for your specific graphics driver is leaking memory or something. If you 
> can try a different graphics driver/stack, that could also point to a 
> specific bug in the driver.

It seemed like --use-gl=egl was somewhat more crash-y with the stock
build, so I reverted that tweak a while back. I need to try it again,
it might be fine now.

> Memory Saver is exactly what I was going to recommend as a workaround, 
> before I saw the backtrace.  ;)

Overall, Chromium does very well with what I'm throwing at it. The
crashes feel like a minor issue that can be fixed easily, not some hard
architectural problem requiring a refactor.


--Daniel

Bug#1074610: [chdist] Produces warnings due to deprecated Perl syntax

[Daniel Richard G.]

Package: devscripts
Version: 2.23.7

The chdist(1) program needs an update. On unstable:

$ chdist create local http://apt.example.com/debian trixie main
given is deprecated at /usr/bin/chdist line 710.
when is deprecated at /usr/bin/chdist line 711.
when is deprecated at /usr/bin/chdist line 714.
when is deprecated at /usr/bin/chdist line 717.
when is deprecated at /usr/bin/chdist line 720.
when is deprecated at /usr/bin/chdist line 723.
when is deprecated at /usr/bin/chdist line 726.
when is deprecated at /usr/bin/chdist line 729.
when is deprecated at /usr/bin/chdist line 732.
when is deprecated at /usr/bin/chdist line 735.
when is deprecated at /usr/bin/chdist line 738.
when is deprecated at /usr/bin/chdist line 741.
when is deprecated at /usr/bin/chdist line 744.
when is deprecated at /usr/bin/chdist line 747.
when is deprecated at /usr/bin/chdist line 750.
when is deprecated at /usr/bin/chdist line 753.
when is deprecated at /usr/bin/chdist line 756.
when is deprecated at /usr/bin/chdist line 759.
when is deprecated at /usr/bin/chdist line 762.
Run chdist apt local update
And enjoy.


--Daniel

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&arch=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&arch=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.]

--begin build log excerpt
make[2]: Entering directory '/tmp/firefox-117.0'
dh_dwz -X libxul
dwz: debian/firefox/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...&C
  │ -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 (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 (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 (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
  /etc/chromium-browser/policies/** r,

 

Bug#742829: closed by intrigeri (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 (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 (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 (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 th

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.