Bug#1072299: Compositor-related crashes

All right, I've figured out what was going on, as well as a fix. Going back to that backtrace I posted some months ago, which I've seen crop up again and again: #0 0x00... in partition_alloc::internal::OnNoMemoryInternal(unsigned long) () #1 0x00... in partition_alloc::TerminateBecause

Bug#1090330: nslcd: Logging does not report TLS connection errors

Package: nslcd Version: 0.9.12-4 I have an nslcd configuration for a large site that uses tls_cacertfile to pin a specific root CA for the ldaps:// server. There was a cert update on the server (without my knowledge) that resulted in the required root CA changing. Unfortunately, this is how the si

Bug#1089507: urllib3.util.ssltransport module still refers to embedded python-six

Package: python3-urllib3 Version: 1.26.12-1 The 01_do-not-use-embedded-python-six.patch file is missing an edit to src/urllib3/util/ssltransport.py. Saw this in the course of building yt-dlp on bookworm: ___ ERROR collecting test/test_http_proxy.py ___ ImportError

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

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 cur

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

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

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

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:

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

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

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

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 alread

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

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 t

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

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

Bug#1072299: Compositor-related crashes

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

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

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 enabl

Bug#1072299: Compositor-related crashes

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 a

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

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/c

Bug#1072299: Compositor-related crashes

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 SIG

Bug#1072299: Compositor-related crashes

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

Bug#1072299: Compositor-related crashes

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://tr

Bug#1072317: Redundant build when making packed_resources

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/co

Bug#1072299: Compositor-related crashes

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

Bug#1072299: Compositor-related crashes

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 avoi

Bug#1072299: Compositor-related crashes

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

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

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

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 hap

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

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

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

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 librar

Bug#1068161: Video playback regression

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

Bug#1068161: Video playback regression

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 posit

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

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 in

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

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

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

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 ris

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

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 me

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

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,

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

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

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

nd 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

-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

s.) 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

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

maging 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

s 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

round 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

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

ules: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

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

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 b

Bug#1040471: Package configuration script mishandles multiple arch instances

-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

LVM 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

st 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

ture? 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

s 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

rged 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]

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]

ng: 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]

ncurrent_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.6

Bug#1031848: Need fallback mirrors for VideoLAN download

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

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

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

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

rk-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 .s

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

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

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

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

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 go

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

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.

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

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 t

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

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 existin

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

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 th

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

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.go

Bug#933372: Installed sox fails test suite

els=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

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 i

Bug#586709: closed by Thomas Goirand

ed 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

s, 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

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

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

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 b

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

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

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 D

Bug#742829: [pkg-apparmor] Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

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/c

Bug#877391: Please add apparmor profile

lar 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)

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

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

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

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

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 coup

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

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 st

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

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

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

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/ap

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

ner 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

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 exte

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

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

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

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 i

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

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

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

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

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

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

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

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

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 fi

Bug#858675: Per-user language setting not effective

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

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 yo

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

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/im

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

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 upstrea

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

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:

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

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 "importan

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

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

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

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-

  1   2   3   >