Bug#1034601:

[Per Lundberg]

For reference, this was fixed in openjdk-11 (11.0.22+7-2) because of this 
patch: 
https://salsa.debian.org/openjdk-team/openjdk/-/blob/2aebf9c2fb202cf3648cbeda9d96d8b29650e79f/debian/patches/8307977-proposed.diff.
 I think it would make sense to apply the same patch could to openjdk-17 as 
well, so we can get this bug closed.

(The bug has been fixed upstream as part of 
https://github.com/openjdk/jdk/pull/17628, but the fix is not yet backported to 
JDK 17 in upstream)

Bug#1034600: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#1034600: fixed in openjdk-11 11.0.22+7-2)

[Per Lundberg]

For reference, this patch was merged into mainline JDK in 
https://github.com/openjdk/jdk/pull/17628, and will be part of the upcoming JDK 
23 release. (The patch that was merged there is basically the same as in 
https://salsa.debian.org/openjdk-team/openjdk/-/blob/2aebf9c2fb202cf3648cbeda9d96d8b29650e79f/debian/patches/8307977-proposed.diff,
 but with some comments modified).

Best regards,
Per

From: Per Lundberg 
Sent: Monday, January 29, 2024 10:17
To: 1034...@bugs.debian.org <1034...@bugs.debian.org>; d...@ubuntu.com 

Subject: Re: Bug#1034600 closed by Debian FTP Masters 
 (reply to Matthias Klose ) 
(Bug#1034600: fixed in openjdk-11 11.0.22+7-2)

Thanks for incorporating this fix into openjdk-11, appreciated Matthias. AFAIK, 
this should be applicable to openjdk-17-jdk as-is as well. I looked in the 
changelog at https://packages.debian.org/sid/openjdk-17-jdk and couldn't see it 
mentioned there (searched for JDK-8307977 and 1034600).

Do you want me to create a new bug for this or just reopen+reassign this bug to 
src:openjdk-17? (feel free to just reassign it yourself if you want to)

Best regards,
Per


From: Debian Bug Tracking System 
Sent: Friday, January 26, 2024 22:45
To: Per Lundberg 
Subject: Bug#1034600 closed by Debian FTP Masters 
 (reply to Matthias Klose ) 
(Bug#1034600: fixed in openjdk-11 11.0.22+7-2)

This is an automatic notification regarding your Bug report
which was filed against the src:openjdk-11 package:

#1034600: tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or 
greater

It has been closed by Debian FTP Masters  
(reply to Matthias Klose ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Matthias Klose ) by
replying to this email.


--
1034600: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034600
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034600: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#1034600: fixed in openjdk-11 11.0.22+7-2)

[Per Lundberg]

Thanks for incorporating this fix into openjdk-11, appreciated Matthias. AFAIK, 
this should be applicable to openjdk-17-jdk as-is as well. I looked in the 
changelog at https://packages.debian.org/sid/openjdk-17-jdk and couldn't see it 
mentioned there (searched for JDK-8307977 and 1034600).

Do you want me to create a new bug for this or just reopen+reassign this bug to 
src:openjdk-17? (feel free to just reassign it yourself if you want to)

Best regards,
Per


From: Debian Bug Tracking System 
Sent: Friday, January 26, 2024 22:45
To: Per Lundberg 
Subject: Bug#1034600 closed by Debian FTP Masters 
 (reply to Matthias Klose ) 
(Bug#1034600: fixed in openjdk-11 11.0.22+7-2)

This is an automatic notification regarding your Bug report
which was filed against the src:openjdk-11 package:

#1034600: tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or 
greater

It has been closed by Debian FTP Masters  
(reply to Matthias Klose ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Matthias Klose ) by
replying to this email.


--
1034600: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034600
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034392: Acknowledgement (tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or greater)

[Per Lundberg]

FYI: An OpenJDK bug regarding this has now been opened as well:
https://bugs.openjdk.org/browse/JDK-8307977
--
Best regards,
Per

Bug#1034392: Acknowledgement (tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or greater)

[Per Lundberg]

On 2023-04-20 00:03, Vladimir Petko wrote:


Oh, thank you for providing a patch for a quite annoying bug


The pleasure is ours. :-) (I didn't write the patch myself but I helped
out a bit with the initial debugging)


Would it be possible to add a header to the patch, so that it is
possible to see where it came from and why, e.g.


Great suggestions - I have added the header as suggested to the patch.

As mentioned, we haven't tested this on JDK 11. If someone has the JDK
11 sources & build environment readily available, it would be great to
get it verified if it works there as well. (This does not hinder the
patch from being applied to JDK 17 already, from my POV.)
--
Best regards,
PerDescription: attach in linux hangs due to permission denied accessing /proc/pid/root
  The attach API uses /proc/pid/root in order to support containers.
  Dereferencing this symlink is governed by ptrace access mode PTRACE_MODE_READ_FSCREDS
  which may not succeed when running as the user running the JRE.
  This breaks running jcmd and jmap as the same user the JVM is running as.
  Use tmpdir when pid matches ns_pid.
Author: Sebastian Lövdahl 
Bug: https://bugs.openjdk.org/browse/JDK-8226919
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034601
Last-Update: 2023-04-18

From 36b554e2de46d77898be4d0feae0ee2171b445bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sebastian=20L=C3=B6vdahl?= 
Date: Tue, 18 Apr 2023 12:50:32 +0300
Subject: [PATCH] 8226919: Fix dynamic attach in Linux for non-container
 environments

---
 .../sun/tools/attach/VirtualMachineImpl.java  | 37 ---
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
index 324e52235cb..605adc20157 100644
--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
@@ -209,11 +209,8 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
 }

 // Return the socket file for the given process.
-private File findSocketFile(int pid, int ns_pid) {
-// A process may not exist in the same mount namespace as the caller.
-// Instead, attach relative to the target root filesystem as exposed by
-// procfs regardless of namespaces.
-String root = "/proc/" + pid + "/root/" + tmpdir;
+private File findSocketFile(int pid, int ns_pid) throws IOException {
+String root = findTargetProcessTmpDirectory(pid, ns_pid);
 return new File(root, ".java_pid" + ns_pid);
 }

@@ -229,21 +226,33 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
 // Do not canonicalize the file path, or we will fail to attach to a VM in a container.
 f.createNewFile();
 } catch (IOException x) {
-String root;
-if (pid != ns_pid) {
-// A process may not exist in the same mount namespace as the caller.
-// Instead, attach relative to the target root filesystem as exposed by
-// procfs regardless of namespaces.
-root = "/proc/" + pid + "/root/" + tmpdir;
-} else {
-root = tmpdir;
-}
+String root = findTargetProcessTmpDirectory(pid, ns_pid);
 f = new File(root, fn);
 f.createNewFile();
 }
 return f;
 }

+private String findTargetProcessTmpDirectory(int pid, int ns_pid) throws IOException {
+String root;
+if (pid != ns_pid) {
+// A process may not exist in the same mount namespace as the caller.
+// Instead, attach relative to the target root filesystem as exposed by
+// procfs regardless of namespaces.
+String procRootDirectory = "/proc/" + pid + "/root";
+if (!Files.isReadable(Path.of(procRootDirectory))) {
+throw new IOException(
+String.format("Unable to access root directory %s " +
+  "of target process %d", procRootDirectory, pid));
+}
+
+root = procRootDirectory + "/" + tmpdir;
+} else {
+root = tmpdir;
+}
+return root;
+}
+
 /*
  * Write/sends the given to the target VM. String is transmitted in
  * UTF-8 encoding.
--
2.40.0

Bug#1034392: Acknowledgement (tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or greater)

[Per Lundberg]

On 2023-04-19 10:22, Thorsten Glaser wrote:

On Tue, 18 Apr 2023, Per Lundberg wrote:


wanted to share it with you as well. One option would be to include this in
Debian's set of local JDK patches


Shouldn’t this be added to 11 as well? Apparently, both are affected.


Good point. Yes, it should.


The OpenJDK (except for 8 which the ELTS people and I mostly work on)
is not maintained by the debian-java people but by Doko.


Hmm... who/what are Doko?


The usual way to hope for inclusion is to clone the bugreport, assign
one to src:openjdk-11 and the other to src:openjdk-17, mail the patch
with a description, add the tag patch and pray.


Thanks for the detailed description! I have done exactly that now. Here 
are the new bugs (added to the Cc line as well):


- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034600
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034601

To those reading this who might not have the context: the patch attached 
to the previous message in this thread fixes an issue with jstack/cmd

and similar tools not being able to connect to processes with Linux
capabilities added to them, when the processes are running as non-root.
This is a regression in the JDK:
https://bugs.openjdk.org/browse/JDK-8226919

The patch has been successfully tested on JDK 17 and works fine,
according to our testing. No guarantees are given as to whether it works
on JDK 11, but as long as it applies cleanly, it "should" be fine.

Best regards,
Per

Bug#1034392: Acknowledgement (tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or greater)

[Per Lundberg]

Hi,

A short update on this. This is a known regression in more recent 
versions of Java: https://bugs.openjdk.org/browse/JDK-8226919


One of my colleagues (thanks, Sebastian!) managed to workaround this by 
patching the JDK 17 sources to make it use plain /tmp in this case (when 
ns_pid == pid), and also added some better error handling in case this 
fails.


We are currently working on getting this submitted upstream to OpenJDK, 
but I wanted to share it with you as well. One option would be to 
include this in Debian's set of local JDK patches 
(https://salsa.debian.org/openjdk-team/openjdk/-/tree/master/debian/patches), 
but I don't know how conservative the project is re. fixes like this? 
I'll leave this up to the debian-java maintainers to decide.


Best regards,
Per--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
@@ -209,11 +209,8 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
 }
 
 // Return the socket file for the given process.
-private File findSocketFile(int pid, int ns_pid) {
-// A process may not exist in the same mount namespace as the caller.
-// Instead, attach relative to the target root filesystem as exposed by
-// procfs regardless of namespaces.
-String root = "/proc/" + pid + "/root/" + tmpdir;
+private File findSocketFile(int pid, int ns_pid) throws IOException {
+String root = findTargetProcessTmpDirectory(pid, ns_pid);
 return new File(root, ".java_pid" + ns_pid);
 }
 
@@ -229,21 +226,33 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
 // Do not canonicalize the file path, or we will fail to attach to a VM in a container.
 f.createNewFile();
 } catch (IOException x) {
-String root;
-if (pid != ns_pid) {
-// A process may not exist in the same mount namespace as the caller.
-// Instead, attach relative to the target root filesystem as exposed by
-// procfs regardless of namespaces.
-root = "/proc/" + pid + "/root/" + tmpdir;
-} else {
-root = tmpdir;
-}
+String root = findTargetProcessTmpDirectory(pid, ns_pid);
 f = new File(root, fn);
 f.createNewFile();
 }
 return f;
 }
 
+private String findTargetProcessTmpDirectory(int pid, int ns_pid) throws IOException {
+String root;
+if (pid != ns_pid) {
+// A process may not exist in the same mount namespace as the caller.
+// Instead, attach relative to the target root filesystem as exposed by
+// procfs regardless of namespaces.
+String procRootDirectory = "/proc/" + pid + "/root";
+if (!Files.isReadable(Path.of(procRootDirectory))) {
+throw new IOException(
+String.format("Unable to access root directory %s " +
+  "of target process %d", procRootDirectory, pid));
+}
+
+root = procRootDirectory + "/" + tmpdir;
+} else {
+root = tmpdir;
+}
+return root;
+}
+
 /*
  * Write/sends the given to the target VM. String is transmitted in
  * UTF-8 encoding.

Bug#1034392: tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or greater

[Per Lundberg]

Package: tomcat9
Version: 9.0.43-2~deb11u6
Severity: normal
X-Debbugs-Cc: sebastian.lovd...@hibox.tv

Hi,

We noticed while rolling out JDK 17 support for our in-house application
that the following command is "broken" (moral-martin is an LXD container
in my examples below, PID 4108 is the tomcat9 java process):

root@moral-martin:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye

root@moral-martin:~# sudo -u tomcat jstack 4108
4108: Unable to open socket file /proc/4108/root/tmp/.java_pid4108: target 
process 4108 doesn't respond within 10500ms or HotSpot VM not loaded

...when all following conditions are met:

* tomcat9 is running from systemd, _and_
* the JDK is of version 11 or greater, _and_
* the systemd unit (/lib/systemd/system/tomcat9.service) sets
  AmbientCapabilities=CAP_NET_BIND_SERVICE (which is done by the Debian
  package)

We have spent a significant amount of time debugging this and I'll try
to do my best to summarize our findings here:

The problem is that the way jstack and similar tools work have changed
from JDK8 to JDK11. In JDK8, it simply uses /tmp to try and communicate
with the target process:
https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java#L40-L45
and 
https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java#L293

In newer JDK versions (JDK 17 as an example), the code has been made
"smarter" to support mount namespaces:
https://github.com/openjdk/jdk17u/blob/master/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java#L299-L302

_However_... bear with me, this is where it gets interesting: this
presumes that the calling process can access /proc//root/tmp. When
AmbientCapabilities=CAP_NET_BIND_SERVICE is set in the systemd unit,
this is not the case:

root@moral-martin:~# sudo -u tomcat ls -l /proc/4108/root
ls: cannot read symbolic link '/proc/4108/root': Permission denied
lrwxrwxrwx 1 tomcat tomcat 0 Apr 13 12:55 /proc/4108/root

We have tested this and concluded that:

1. This happens whever _any_ capability is set in the systemd unit; it's
   not limited to CAP_NET_BIND_SERVICE. (Note: I haven't tested adding
   all possible capabilities yet; I believed I had but when writing this
   bug report I realize that my attempt at setting all of them didn't
   actually list all of them in `getpcaps pid`; will test this a bit
   more and see if it makes any difference)

2. When you remove AmbientCapabilities or set it to AmbientCapabilities=
   (empty string), it also works correctly.

I honestly don't know if tomcat9 is the correct package to report this
to; it can also be seen as a bug in the JDK. (We will work with the JDK
maintainers to get this reported to them as well.) Feel free to reassign
the bug report to another package.

With JDK 8, this works correctly. Some of our tooling/monitoring is
dependent on being able to connect to Tomcat (running on JDK 8 or 17) at
runtime. That's why this is imporant for us.

Workaround

What we have seen that on JDK 17, running `jstack` as root works; this
will connect to the target process correctly. However, this does _not_
work on JDK 8 and doesn't seem to work properly on JDK 11 either (I
think this has been fixed upstream in JDK for more recent JDK versions,
which is why it behaves differently on JDK 17). 

Our application supports both JDK 8 and 17 for now, and running `jstack`
as root *does not* work on JDK 8. Hence, having to run it as root with
our JDK 17-based installations (only) makes things unnecessarily
complex.

Conclusions

It puzzles me why setting the ambient capabilities for a process breaks
this. It's uncertain whether this is a "feature" by the kernel or
elsewhere. We have tried to find more details about this by studying the
systemd and dbus code to a certain extent, but have yet been unable to
find anything. If anyone reading this knows the prctl and cap_set_proc
semantics by heart, your help would be greatly appreciated.

Best regards,
Per

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

Kernel: Linux 6.1.0-6-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tomcat9 depends on:
ii  lsb-base11.6
ii  systemd [systemd-tmpfiles]  252.6-1
ii  sysvinit-utils [lsb-base]   3.06-2
pn  tomcat9-common  
ii  ucf 3.0043+nmu1

Versions of packages tomcat9 recommends:
ii  

Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

[Per Lundberg]

Hi Shengjing Zhu,

On 2023-02-21 11:44, Shengjing Zhu wrote:


Please read message#91
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975#91 and then
think about it.
If you still think there's a secure patch that we can apply, I'd like to review.


Hmm, you have some very valid points and concerns there. I should have 
read the whole bug before commenting... :-)



What surprises me though is that on Ubuntu, this seemingly works 
correctly (presuming that LXD is running as a snap in that case), as 
pointed out by a colleague. I don't know why but it would be interesting 
to dig deeper into the details here. I asked my colleague to check his 
sysctl settings and they look identical to mine (IPv4 forwarding not 
enabled in /etc/sysctl.conf). This is from his Ubuntu 22.04 machine:


user@host:~$ grep net.ipv4.ip_forward /etc/sysctl.conf
#net.ipv4.ip_forward=1

user@host:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

user@host:~$ grep ip_forward /etc/sysctl.d/*
/etc/sysctl.d/99-sysctl.conf:#net.ipv4.ip_forward=1

I'm almost inclined to set up an Ubuntu VM to test this in, but I don't 
really have the time (at work) right now. If anyone reading this has 
more insight into this, it would be incredibly interesting.


Best regards,
Per

Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

[Per Lundberg]

Regretfully, this bug is still active and it's trivial to reproduce with 
this configuration:


* apt-get install docker.io (ensure that the docker daemon is running 
afterwards. Tested with 20.10.22+dfsg1-2 locally)

* apt-get install lxd (tested with 5.0.1-5)

Then, "lxc launch ubuntu:22.04" (accepting the defaults for LXD 
configuration). Networking will be broken inside the newly created LXD 
container.


The workaround for me is to run "sudo iptables -P FORWARD ACCEPT" after 
bootup (and after Docker has started). But I agree with previous 
comments; it's EXTREMELY BAD and unacceptable for a program like Docker 
to misbehave like this.


On the LXD side, this has been discussed and is a known issue:

* 
https://discuss.linuxcontainers.org/t/lxd-and-docker-firewall-redux-how-to-deal-with-forward-policy-set-to-drop/9953/9
* 
https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_firewalld/#prevent-issues-with-lxd-and-docker


(The suggestion given there is to insert firewall rules into the 
DOCKER-USER chain.)


I suggest we would consider patching the Docker package in Debian to 
remove the FORWARD DROP nonsense until this has been properly resolved 
upstream. We can't have programs that misbehave this badly in the 
distribution, IMO.


Best regards,
Per Lundberg

Bug#768073: Status of package in the NEW queue

[Per Lundberg]

Hi,

I think we are probably a number of people excited to see this (soon!) finally 
making it into Debian proper. :) I am currently running LXD as a snap, but it 
would just be so much nicer and cleaner to be able to use the "real" packages 
for this.

The package is currently in the Debian "new" queue, where it has been since 
August 4: https://ftp-master.debian.org/new/lxd_5.0.0-1.html

Are there any impediments from seeing this making its way into 
unstable/experimental anytime soon, or is it just a matter of the FTP masters 
not having had time to look into it yet?

Best regards,
Per

Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat

[Per Lundberg]

Hi,

On 2022-03-02 17:24, Markus Koschany wrote:


(Speaking about tomcat10, I noted the package in experimental is really
old - doesn't seem to have been updated for a few years. Do you know if
anyone is working on updating the package to e.g. Tomcat 10.0.17 or will
it perhaps happen later in the Bookworm release cycle?)


I intend to update it in the near future. I believe the initial goal was to
make it co-installable with Tomcat 9. Currently there are still some file
conflicts which have to be resolved before we can upload Tomcat 10 to unstable.


Aha, I see. Good to know.


We still need OpenJDK 8 to bootstrap Kotlin. Please don't ask for its removal.
It would be great if we could use OpenJDK 11 instead but we are not there yet.


Alright, I will definitely not suggest it in that case. :D


As for the actual libeclipse-jdt-core-java package, is there any
particular reason for going with the 4.21 version in Debian unstable &
bookworm? I am just curious. It feels like a somewhat odd decision to go
with a more recent version than the 4.20 version which Apache bundles in
their distribution. But perhaps there are other Debian packages which
can find use of the newer package, or has it perhaps just been done to
be able to ship the "latest and greatest" version of this package with
Bookworm? (I mean: to not ship something which is "old" already at the
time of release.)


I guess there was no particular reason other than upgrading to the latest
available version back then. I have not investigated yet if another Debian
package requires 4.21 specifically but since we don't really support Java 8
anymore I think we can just move forward. Tomcat 9 will be gone next year and
since we rather have to invest time into fixing OpenJDK 17 bugs than making
packages Java 8 compatible, I would say let's keep it as is.


Thanks, I'm fine with this. I suggest we keep this bug open until we 
have the Dependencies line for tomcat9 fixed, as discussed.



For our own internal needs, we'll have to find another approach (either 
creating our own tomcat9 package as you suggested, or spending the time 
getting our software to be ready for Java 11 (and eventually Java 17) - 
or both. :-)


Given that we will likely have to spend quite an effort moving from 
tomcat9 to tomcat10 (because of the javax.* to jakarta.* package 
change), providing this as a package of our own might not be such a bad 
idea anyway, since it gives us total control of when to roll it our to 
our customers. (We have built an in-house product which is deployed 
using Tomcat at a number of on-premise & cloud-based installations, so 
being too dependent on the Tomcat version which happens to be in Debian 
unstable => Ubuntu LTS at any given time is perhaps not ideal for us.)


Best regards,
Per

Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat

[Per Lundberg]

Hi Markus,

On 2022-03-02 14:15, Markus Koschany wrote:


As a matter of fact OpenJDK 11 is the only supported Java version in oldstable,
stable and testing right now. We plan to release with Java 17 next year and one
of our goals is to ship only Tomcat 10 in Debian 12 "Bookworm". I think you are
right that we should tighten the dependency to java11-runtime-headless to avoid
any confusion but as I said, OpenJDK 11 is the only supported JDK/JRE at the
moment. If you cannot upgrade your application to Java 11, then you could
create a custom Tomcat 9 package or simply downgrade libeclipse-jdt-core-java
to 4.20 again.


Thanks for clarifying these things and mentioning the plan from the 
Debian Java maintainers in this case. I remember discussing something 
similar (JDK 11 only to be supported) a few years ago with you in fact; 
the problem was with visualvm at that time. :)


(Speaking about tomcat10, I noted the package in experimental is really 
old - doesn't seem to have been updated for a few years. Do you know if 
anyone is working on updating the package to e.g. Tomcat 10.0.17 or will 
it perhaps happen later in the Bookworm release cycle?)


Also, I wonder if it wouldn't even make sense to remove openjdk-8-jdk 
altogether from unstable at this point. The fact that it's present there 
is actually a bit confusing, since it gives the (completely false) 
impression that JDK 8 will be supported in future versions of Debian. If 
you agree, I can file a separate removal bug on that package. (I'm not 
currently a Debian maintainer myself, so I cannot help out more than 
that. ;)


As for the actual libeclipse-jdt-core-java package, is there any 
particular reason for going with the 4.21 version in Debian unstable & 
bookworm? I am just curious. It feels like a somewhat odd decision to go 
with a more recent version than the 4.20 version which Apache bundles in 
their distribution. But perhaps there are other Debian packages which 
can find use of the newer package, or has it perhaps just been done to 
be able to ship the "latest and greatest" version of this package with 
Bookworm? (I mean: to not ship something which is "old" already at the 
time of release.)


Best regards,
Per

Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat

[Per Lundberg]

reassign 1006647 tomcat9
thanks

This might better belong to this package, since the problem is that 
tomcat9-common depends on default-jre-headless | java8-runtime-headless 
| java8-runtime, while in reality it requires Java 11. (because of 
Eclipse JDT 4.21, see original bug report for details)


If we are unable to fully resolve this, I think that we should at least 
fix these incorrect dependencies to make the package depend on 
"default-jre-headless | java11-runtime-headless | java11-runtime" 
instead. But as previously mentioned, I would much rather see us move to 
Eclipse JDT 4.20 instead so we can retain Java 8 support until Debian at 
some point upgrades to Tomcat 10.1 (at which point requiring Java 11 is 
inevitable).


Best regards,
Per

Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat

[Per Lundberg]

Package: libeclipse-jdt-core-java
Version: 3.27.0+eclipse4.21-1
Severity: normal

Dear Maintainer,

The 3.27.0+eclipse4.21-1 version of the package has switched to using
the 4.21 version of the upstream package (libeclipse-jdt-core-java).
This is problematic for us and potentially others who are still forced
to use JDK 8, since this version has a strict Java 11 requirement. (This
is also listed in the changelog entry for the package.)

More so, this package is used as-is in Ubuntu (including the upcoming
Ubuntu 22.04 release), which means that the decision to bump the
libeclipse-jdt-core-java to a version which only works on Java 11 and
greater has significant ramifications to the ecosystem at large.

The 4.21 version is not _required_ by Tomcat 9.0.58. It works fine on
4.20 (and perhaps older versions as well, as we also indicate by the
libeclipse-jdt-core-java (>= 3.18.0) dependency line for the
libtomcat9-java package.

I see some ways this could be handled by the Debian project:

* Live with it. People who still are using JDK 8 are on their own anyway
  (Oracle does not support it). Unfortunately, this will cause problems
  for a number of people, who will be forced to find other ways than
  using the vendor-provided Tomcat package if their software cannot run
  on Java 11.

* Downgrade the version in Debian to 4.20. This should make our Tomcat
  work on JDK 8 and 11 alike, and be the "most compatible" approach in
  this case. I think this would be preferable if possible.

I don't know, but I wonder if providing a 4.21-based package in Debian
in this case could be an unintentional mistake? I just downloaded the
Tomcat 9.0.58 tarball from
https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.58/, and it
contains the lib/ecj-4.20.jar file, i.e. containing Eclipse JDT version
4.20. I would _guess_ that this is specifically done to avoid enforcing
a Java 11 dependency on all Tomcat users. Tomcat 9 (and 10.0) still
supports Java 8 in their upstream versions.

I'm not in charge of this decision in any way, but I think it does make
sense if Debian would consider doing the same. Especially given that
Debian is a project which takes backwards compatibility very seriously
and works hard to avoid unnecessary breakage for our end users. (In this
case, some of "our end users" are using Ubuntu. :)

Best regards,
Per

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#989816: Duplicate

[Per Lundberg]

For reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934372
#934372 - snapd WARNING: cgroup v2 is not fully supported yet, proceeding with 
partial confinement - Debian Bug report 
logs<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934372>
Package: snapd Version: 2.42.1-1 Followup-For: Bug #934372 Control: block 
943981 by -1 Control: severity -1 minor Control: user 
pkg-systemd-maintain...@lists.alioth.debian.org Control: usertag -1 + cgroupv2 
Dear Maintainer, The situation improved in version 2.42.1, now we have $ snap 
run hello-world WARNING: cgroup v2 is not fully supported yet, proceeding with 
partial confinement Hello World!
bugs.debian.org


(Unsure about how to mark this as a duplicate with the Debian BTS, someone who 
knows how to do it is welcome to do it.)

From: Per Lundberg 
Sent: Thursday, September 2, 2021 14:15
To: 989...@bugs.debian.org <989...@bugs.debian.org>
Subject: Duplicate

This seems like a duplicate of #934372 to me.

Bug#989816: Duplicate

[Per Lundberg]

This seems like a duplicate of #934372 to me.

Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8

[Per Lundberg]

On 2/4/19 10:07 PM, Moritz Mühlenhoff wrote:

> What is the specific use case for this, is there some package which
> needs 8 and can't be fixed in time for 11?

Yes, it was stated in this thread earlier that such packages do exist.

Emmanuel/others, is this the correct list of packages which can only be 
built w/ openjdk-8 or am I missing something out? If so, it doesn't seem 
like a huge list and making all of these work on openjdk-11 "could" be 
doable/the release could possibly live without them. (well, ideally not 
of course)

$ grep-dctrl -FBuild-Depends openjdk-8 -sPackage /var/lib/apt/lists/*Sources
Package: virtualbox
Package: icedtea-web
Package: jzmq
Package: leiningen-clojure
Package: libbluray
Package: lombok
Package: openjdk-8
Package: openjdk-8-jre-dcevm
Package: openjdk-8
Package: openjfx
Package: uwsgi

Personally, I still rely on openjdk-8 for my work (because of customer 
environments still using it for at least 3-5 more years), but I can live 
with getting it from an unofficial repository. It's more important to 
provide a smooth user experience for the majority of people, who are 
perhaps not _developers_ of Java-based software but more _users_ of the 
same.

Best regards,
--
Per

Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8

[Per Lundberg]

On 2/1/19 11:20 AM, Matthias Klose wrote:
> On 01.02.19 10:03, Emmanuel Bourg wrote:

>> This is an excellent suggestion. We should file a bug for openjdk-8 to
>> implement that.
> please attach the patch.

Sure, I should be able to write something up. Forbear my ignorance: 
should I use debconf to show the message or what do you think would be 
right approach? (I haven't been involved at this level in Debian since I 
stepped down as package maintainer 15 years ago. :)

Best regards,
Per

Bug#897945: #897945 still present/breaks with Java 8

[Per Lundberg]

On 1/29/19 3:36 PM, Markus Koschany wrote:

> We usually ship only with one JDK per release because of security
> support. OpenJDK 8 will be EOL before the end of the Debian 10 release
> cycle. We still have a couple of packages that will not compile with
> OpenJDK 11 hence we also thought about shipping OpenJDK 8 for building
> those packages but declaring it as unsupported at runtime. However, as
> this bug report shows, people tend to assume that OpenJDK 8 is supported
> as well.

Yes, it's easy to get this impression and I think it'll get even worse 
when more people start using Buster.

> So we either end up without OpenJDK 8 in Buster at all and with
> less packages, that are only there to build other packages, or we
> declare OpenJDK 8 as unsupported at runtime in our release notes which
> carries the risk of nobody reading them.

I think that risk is significant. If we go that route, I would suggest a 
postinst/debhelper message saying that "OpenJDK 8 is included but 
unsupported. Many packages will not work with it. Use at your own risk." 
or something similar.

But removing it altogether is probably less cumulative work for the 
whole Debian team in the long run, so I think that option should be 
strongly considered. It will also increase the motivation for people to 
fix the broken packages to build correctly on OpenJDK 11... :-)

(Do we have a list of these packages btw?)

Best regards,
--
Per

Bug#897945: #897945 still present/breaks with Java 8

[Per Lundberg]

Hi Markus,

On 1/29/19 1:32 PM, Markus Koschany wrote:
> 
>> I am sorry but OpenJDK 8 will not be supported at runtime in
>> Buster.
Another question: if this is the case, should the openjdk-8-jdk package 
(and friends) be removed altogether in sid? I looked briefly but 
couldn't find any bugs mentioning this.

Bug#897945: #897945 still present/breaks with Java 8

[Per Lundberg]

On 1/29/19 1:32 PM, Markus Koschany wrote:

Hi Markus and Emmanuel,

Emmanuel - the problem is that VisualVM will display its splash screen, 
then die with an error in the log about java.lang.NoSuchMethodError: 
java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;

>> I am sorry but OpenJDK 8 will not be supported at runtime in
>> Buster. If it works with OpenJDK 11, which it does, then we should
>> spend the remaining time before the release on more urgent issues.
> 
> I should have added that we compile for Java 9 bytecode with the
> - -Dpermit.jdk9.builds=true switch in visualvm and in
> libnb-platform18-java. No surprises here that it won't work with
> OpenJDK 8.

I am fine with this; we should just try to make the user experience a 
bit smoother.

> What we can and probably should do is to force OpenJDK 11
> by using a stricter dependency on default-jdk (>= 2:1.11) | java11-sdk
> and by also updating the 03-launcher.patch and remove the alternative
> search paths for OpenJDK 7 and OpenJDK 8. The result is that visualvm
> simply will not start anymore and quit with "No jdkhome found" if
> someone uses an unsupported JDK.

That sounds like a reasonable path: the effort should not be huge, and 
the user experience will be improved. The problem right now (with Java 
8) is that it just "dies" as described above, no error message printed. 
You have to more or less _know_ that you should go digging in 
~/.visualvm/1.4/var/log/messages.log for it. This is not so great.

But, the approach you suggest is fine. Markus, will you reopen this bug 
or should we file a new one about it, what do you prefer?
--
Best regards,
Per

Bug#897945: #897945 still present/breaks with Java 8

[Per Lundberg]

FWIW, version 1.4.2-1 works correctly with openjdk-11-jdk version 
11.0.2+7-1, but it _does not_ work correct any more with Java 8 
(openjdk-8-jdk version 8u191-b12-2)

This worked correctly with 1.3.9-1 after downgrading the libnb-*-java 
packages as suggested by Ben - visualvm worked fine on Java 8 with this 
combination of packages.

So, we should either:

- Reopen the bug and fix the problem (likely by compiling visualvm with 
openjdk-8, which should make it work on newer JDK versions also)

- Accept the breakage and indicate this somehow, preferably in the 
package metadata. (I don't know if we can use dpkg dependencies in this 
case? It's perfectly legal to have both OpenJDK 11 and 8 _installed_ on 
a machine; it's just that the latter is unusable with visualvm from now on.)

Because the resolution here is not perfectly clear, I will refrain from 
just reopening the bug until it has been discussed a bit more.

Best regards,
--
Per

Bug#897945: Verified

[Per Lundberg]

FWIW, I have verified this bug on my machine - downgrading to 
8.1+dfsg1-7 as suggested by Ben helped, making it work again. (Thanks, Ben!)

Here is the stack trace when running with 8.1+dfsg1-8. To me, this looks 
like code compiled for Java 9+ trying to run on Java 8 (which I am 
currently using) but there could of course also be other possible 
explanations.

> java.lang.NoSuchMethodError: 
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at org.netbeans.core.startup.layers.BinaryFS.(Unknown Source)
> at org.netbeans.core.startup.layers.BinaryCacheManager.load(Unknown 
> Source)
> at 
> org.netbeans.core.startup.layers.LayerCacheManager$1Updater.run(Unknown 
> Source)
> at org.openide.filesystems.EventControl.runAtomicAction(Unknown 
> Source)
> at org.openide.filesystems.FileSystem.runAtomicAction(Unknown Source)
> at org.openide.filesystems.FileUtil.runAtomicAction(Unknown Source)
> at org.netbeans.core.startup.layers.LayerCacheManager.store(Unknown 
> Source)
> at 
> org.netbeans.core.startup.layers.ModuleLayeredFileSystem.setURLs(Unknown 
> Source)
> at 
> org.netbeans.core.startup.layers.ModuleLayeredFileSystem.addURLs(Unknown 
> Source)
> at org.netbeans.core.startup.NbInstaller.loadLayers(Unknown Source)
> at org.netbeans.core.startup.NbInstaller.loadImpl(Unknown Source)
> at org.netbeans.core.startup.NbInstaller.access$000(Unknown Source)
> at org.netbeans.core.startup.NbInstaller$1.run(Unknown Source)
> at org.openide.filesystems.FileUtil$2.run(Unknown Source)
> at org.openide.filesystems.EventControl.runAtomicAction(Unknown 
> Source)
> at org.openide.filesystems.FileSystem.runAtomicAction(Unknown Source)
> at org.openide.filesystems.FileUtil.runAtomicAction(Unknown Source)
> INFO [null]: Last record repeated again.
> at org.netbeans.core.startup.NbInstaller.load(Unknown Source)
> at org.netbeans.ModuleManager.enable(Unknown Source)
> INFO [null]: Last record repeated again.
> at org.netbeans.core.startup.ModuleList.installNew(Unknown Source)
> at org.netbeans.core.startup.ModuleList.trigger(Unknown Source)
> at org.netbeans.core.startup.ModuleSystem.restore(Unknown Source)
> at org.netbeans.core.startup.Main.getModuleSystem(Unknown Source)
> INFO [null]: Last record repeated again.
> at org.netbeans.core.startup.Main.start(Unknown Source)
> at org.netbeans.core.startup.TopThreadGroup.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)

Bug#915880: Acknowledgement (lvm2: Dependency on liblz4-1 causes /sbin binaries to depend on /usr/lib libraries)

[Per Lundberg]

FWIW, I tried doing a blank install with the Buster Alpha 3 installer,
putting /usr on a separate LVM volume to see if Debian Buster would
also be affected of this. It was not - /usr was mounted without any
obvious problems during bootup. (This seems to be different from
Ubuntu 18.04, but I haven't tried that install myself, only seen
others failing with it when /usr was on a separate LVM volume.)

So, the severity of this is rightfully "normal". Would you like me to
re-route it to the liblz4-1 package instead of lvm2? (I guess the
proper fix for this would be to fix the build script for liblz4-1 so
that it's build output gets packaged into /lib instead of /usr/lib)

On Fri, Dec 7, 2018 at 4:57 PM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 915880: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915880.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   per...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian LVM Team 
>
> If you wish to submit further information on this problem, please
> send it to 915...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 915880: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915880
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#915880: lvm2: Dependency on liblz4-1 causes /sbin binaries to depend on /usr/lib libraries

[Per Lundberg]

Package: lvm2
Version: 2.02.176-4.1
Severity: normal

Dear Maintainer,

We just noted on a fresh Ubuntu 18.04 installation after it failed to
mount the /usr partition on boot, that its /sbin/lvm tool depends on
libraries in /usr/lib. I assumed at first that this bug was local to
Ubuntu, but for the sake of it I installed lvm2 on my Debian desktop
machine (which doesn't use LVM volumes itself) just to investigate
things further.

I was surprised to see that this was the case here also:

$ ldd /sbin/lvm
linux-vdso.so.1 (0x7ffd681ed000)
libdevmapper-event.so.1.02.1 => 
/lib/x86_64-linux-gnu/libdevmapper-event.so.1.02.1 (0x7f6367766000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f63676da000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f63676ba000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f63676b5000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7f6367663000)
libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 
(0x7f63673f8000)
libreadline.so.5 => /lib/x86_64-linux-gnu/libreadline.so.5 
(0x7f63671b4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f6366ff7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f6366fd6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f6366fcc000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f6366da6000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f6366b89000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f6366a69000)
/lib64/ld-linux-x86-64.so.2 (0x7f6368039000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f6366a6)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 
(0x7f6366838000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f63666a4000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7f6366676000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f6366652000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f63665de000)

The liblz4.so.1 library, coming from liblz4-1, causes an /sbin ->
/usr/lib dependency which is bad because it means the LVM binaries are
unable to be used before /usr is mounted.

I briefly looked in the FHS to see if this was stated there, but
couldn't find it. Anyway, it seems reasonable that /bin and /sbin depend
on libraries below /lib *only*, so that /usr can be kept on a separate
volume.

(I wonder, but haven't confirmed this, if the root cause on the
above-mentioned Ubuntu 18.04 machine not finding its /usr filesystem by
UUID is this bug. If it _is_, then I think the severity should be bumped
since it essentially makes it impossible to put your /usr partition on
an LVM volume in Debian and Ubuntu, which is rather bad. I find this
unlikely though, since it's reasonable someone else would have spotted
this by now.)

For the record, I briefly looked at the 2.02.133-1ubuntu10 package
provided by Ubuntu 16.04, and it _does not_ have the lz4 dependency, so
maybe this is a bug that has crept into Debian and Ubuntu during the
recent years? If so, it would explain to a certain degree why it hasn't
been reported yet.

$ ldd /sbin/lvm
linux-vdso.so.1 =>  (0x7ffd1aff9000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fbc22e05000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fbc22676000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7fbc22435000)
libdevmapper-event.so.1.02.1 => 
/lib/x86_64-linux-gnu/libdevmapper-event.so.1.02.1 (0x7fbce000)
libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 
(0x7fbc21fd5000)
libreadline.so.5 => /lib/x86_64-linux-gnu/libreadline.so.5 
(0x7fbc21d97000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbc219cd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fbc217c5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fbc215a8000)
/lib64/ld-linux-x86-64.so.2 (0x7fbc22c0c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fbc213a3000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 
(0x7fbc21181000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fbc20e78000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fbc20c4f000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7fbc209df000

Best regards,
Per


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

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

Bug#906447: tomcat8: Errors thrown when connecting

[Per Lundberg]

On 8/27/18 3:07 PM, Markus Koschany wrote:


I believe you both misunderstand the current issue at hand. In Debian we
default to OpenJDK 10 at the moment and soon OpenJDK 11 because this
will be the only supported (security wise) runtime environment for
Debian 10 "Buster". [...]


Thanks for the writeup, and yes - you're right, I misunderstood you. :)


The only way to fix this is to pass the --release flag to javac manually
and where appropriate. This was done upstream in 8.5.33 and your problem
should be addressed now.


Excellent, thanks a lot for your efforts Markus.
--
Best regards,
Per

Bug#906447: tomcat8: Errors thrown when connecting

[Per Lundberg]

On 8/26/18 12:46 AM, Markus Koschany wrote:


I believe we should tighten the dependency on default-jre-headless. We
currently have for tomcat8-common:

default-jre-headless | java8-runtime-headless | java8-runtime

We should simply change that to

default-jre-headless (>= 10) | java10-runtime-headless | java10-runtime


Why can't we just compile it with OpenJDK 8? There are some of us who 
are still stuck on Java 8 for various reasons (because of dependencies 
of other projects), and I think it would be more convenient to let the 
package be compiled for Java 8 for the time being. As long as Tomcat 
doesn't actually use any Java 10 features, I don't really see the big 
benefit of compiling it with OpenJDK 10 at this stage.

--
Best regards,
Per

Bug#906447: Bug confirmed

[Per Lundberg]

I agree, this seems to be a regression. The package was incorrectly 
built with Java 10 previously, but this was fixed as part of #895866. 
Apparently, the problem seems to have reappeared. Verified with Java 
1.8.0_181-8u181-b13-1-b13 (package list below).


ii  openjdk-8-jdk-headless:amd64 8u181-b13-1 
amd64    OpenJDK Development Kit (JDK) (headless)
ii  openjdk-8-jre:amd64 8u181-b13-1 
amd64    OpenJDK Java runtime, using Hotspot JIT
ii  openjdk-8-jre-headless:amd64 8u181-b13-1 
amd64    OpenJDK Java runtime, using Hotspot JIT (headless)


For reference, here is the stack trace:

<2>Error reading request, ignored
<2>java.lang.NoSuchMethodError: 
java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
<2>    at 
org.apache.coyote.http11.Http11InputBuffer.init(Http11InputBuffer.java:696)
<2>    at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:669)
<2>    at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
<2>    at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:800)
<2>    at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)
<2>    at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
<2>    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
<2>    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
<2>    at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

<2>    at java.lang.Thread.run(Thread.java:748)

Bug#839088: Sorry: TypeError: compile() expected string without null bytes

[Per Lundberg]

Package: python2.7
Version: 2.7.12-3
Severity: important

I get the error reported in  when trying to configure this version of 
python (which has been introduced in 'stretch' recently. I guess it could be 
caused by some 3rd party library on my system? 
Any suggestions on how to debug it further?


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python2.7 depends on:
ii  libpython2.7-stdlib  2.7.12-3
ii  mime-support 3.60
ii  python2.7-minimal2.7.12-3

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.26.1-1
pn  python2.7-doc  

-- no debconf information

Bug#348019: fixed in 0.2.36-3

[Per Lundberg]

On Mon, 2006-01-16 at 15:22 -0800, Ryan Murray wrote:
 On Mon, Jan 16, 2006 at 11:40:58PM +0100, Per Lundberg wrote:
  This is the gdb output, including backtrace:
 This is useless without debugging symbols for the related libs, and
 indication of the LD_PRELOAD that was used at start time being given to gdb.
 you'd need to install dbg packages, and rebuild a few things with debugging
 symbols to make it useful.

With some dbg packages installed, I get this:

#0  0x2b5ab62c in raise (
sig=value optimized out)
at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:45
45int res = INLINE_SYSCALL (tgkill, 3, pid, THREAD_GETMEM
(THREAD_SELF, tid),
(gdb) backtrace
#0  0x2b5ab62c in raise (sig=value optimized out)
at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:45
#1  0x0044a844 in ?? ()
#2  signal handler called
#3  0x2b085348 in ?? ()
#4  0x2b464348 in ?? ()
#5  0x7fffdc80 in ?? ()
#6  0x06f74c45 in ?? ()
#7  0x7fffdc40 in ?? ()
#8  0x2b46b2c3 in ?? () from /usr/lib/firefox/libnspr4.so
#9  0x in ?? ()

I am currently recompiling firefox with --enable-debug to see if we can
get some more out of this. Shouldn't take too long, I'll get back to you
with a better trace ASAP.

 what's the output of nm --dynamic /usr/lib/esound/libesddsp.so.0 ?

001022dc A __bss_start
1aa0 T close
 w __cxa_finalize
 U dlsym
001022dc A _edata
00102380 A _end
 U esd_free_all_info
 U esd_get_all_info
 U esd_open_sound
 U esd_set_stream_pan
 U exit
1d78 T _fini
 U free
 U fwrite
 U getenv
 U gettimeofday
 w __gmon_start__
0be0 T _init
1330 T ioctl
 w _Jv_RegisterClasses
 U malloc
1c30 T mmap
1c70 T mmap64
00102370 B mmapemu_last_flush
1cb0 T munmap
11b0 T open
1270 T open64
 U read
 U sprintf
 U stderr
 U strcmp
 U strlen
 U strncpy
1b10 T wrap_mmap
0f50 T wrap_open
 U write

-- 
Best regards,
Per Lundberg




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#347751: fixed in 0.2.36-3

[Per Lundberg]

Reading symbols from /usr/lib/libz.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/firefox/libsmime3.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/firefox/libsmime3.so
Reading symbols from /usr/lib/firefox/libssl3.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/firefox/libssl3.so
Reading symbols from /usr/lib/firefox/libnss3.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/firefox/libnss3.so
Reading symbols from /usr/lib/firefox/libsoftokn3.so...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/firefox/libsoftokn3.so
Reading symbols from /usr/X11R6/lib/libXt.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/X11R6/lib/libXt.so.6
Reading symbols from /usr/X11R6/lib/libXp.so.6...(no debugging symbols
found)...done.
Loaded symbols for /usr/X11R6/lib/libXp.so.6
Reading symbols from /usr/lib/firefox/libxpcom_compat.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/firefox/libxpcom_compat.so
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libgcc_s.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/lib/libfreetype.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfreetype.so.6
Reading symbols from /usr/lib/libXft.so.2...(no debugging symbols
found)...done.Loaded symbols for /usr/lib/libXft.so.2
Reading symbols from /usr/lib/libaudiofile.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libaudiofile.so.0
Reading symbols from /lib/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/libexpat.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libexpat.so.1
Reading symbols from /usr/X11R6/lib/libSM.so.6...(no debugging symbols
found)...done.
Loaded symbols for /usr/X11R6/lib/libSM.so.6
Reading symbols from /usr/X11R6/lib/libICE.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/X11R6/lib/libICE.so.6
Reading symbols
from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...(no debugging
symbols found)...done.
Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2
Reading symbols from /lib/libnss_compat.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/gconv/ISO8859-1.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gconv/ISO8859-1.so
Reading symbols from /usr/lib/gconv/UTF-16.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/gconv/UTF-16.so

#0  0x2b5ba62c in raise () from /lib/libpthread.so.0
(gdb) backtrace
#0  0x2b5ba62c in raise () from /lib/libpthread.so.0
#1  0x0044a844 in ?? ()
#2  signal handler called
#3  0x2adcfcb0 in ?? ()
#4  0x2b25bca8 in ?? ()
#5  0x7fffdd10 in ?? ()
#6  0x06f74c45 in ?? ()
#7  0x7fffdcd0 in ?? ()
#8  0x2b46a2c3 in ?? () from /usr/lib/firefox/libnspr4.so
#9  0x in ?? ()

-- 
Best regards,
Per Lundberg




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#348019: firefox: The problem is due to the esddsp wrapper and is really in esound-clients

[Per Lundberg]

Package: firefox
Version: 1.5.dfsg-4
Followup-For: Bug #348019

I have also reproduced this bug here. However, it worked for me with a
non-root user (another user account than the one that I regularly use), so
it is not a permissions problem. There was a .mozilla directory in the other
users home directory before I started firefox; I moved it away and it worked.
I removed the new .mozilla directory and moved the original one back, it
worked now as well! Unfortunately, I didn't make a backup of the original
.mozilla directory so I am unable to tell the last Firefox version run
from the prefs.js.

I have also run firefox with the -g parameter, to run it in gdb. The weird
thing is that it actually WORKS when run in gdb, so there is some side
effect of gdb that causes it to work... And even stranger is that at first
when I tried it with -g it segfaulted there as well. It might be because of
remnant firefox processes in the system or something

Since it works for me now when run with -g, it is a bit hard to debug it. ;-)

[ Fiddling around a bit more ]

I have managed to localize the problem; it is with esddsp. When I set
FIREFOX_DSP in /etc/firefox/firefoxrc to a junk value (meep), it worked!

The output of firefox --verbose without this change:

[EMAIL PROTECTED]:~$ firefox --verbose
FIREFOX_DSP=esddsp
APPLICATION_ID=firefox
CMDLINE_DISPLAY=
DISPLAY=:0.0
OPTIONS=
DEBUG=0
DEBUGGER=
Running: esddsp /usr/lib/firefox/firefox-bin -a firefox

...and with the change:

[EMAIL PROTECTED]:~$ firefox --verbose
FIREFOX_DSP=meep
APPLICATION_ID=firefox
CMDLINE_DISPLAY=
DISPLAY=:0.0
OPTIONS=
DEBUG=0
DEBUGGER=
Running: /usr/lib/firefox/firefox-bin -a firefox

My only question now is, why did it work with my other user account? I was
running two X sessions at the same time, and it turned out this was the 
problem: esd was running in mine, but not the other! So firefox --verbose in
the account that worked showed that esddsp was not being run, which is the
reason it worked.

Conclusion: esddsp is somehow causing this. Here is my package info for
esdound-clients which includes esddsp.

Package: esound-clients
Status: install ok installed
Priority: optional
Section: sound
Installed-Size: 168
Maintainer: Ryan Murray [EMAIL PROTECTED]
Architecture: amd64
Source: esound
Version: 0.2.36-2
Depends: libaudiofile0 (= 0.2.3-4), libc6 (= 2.3.5-1), libesd0 (= 0.2.35) | 
libesd-alsa0 (= 0.2.35), esound-common (= 0.2.36-2)
Conflicts: libesd0 ( 0.2.36-1), libesd-alsa0 ( 0.2.36-1)
Description: Enlightened Sound Daemon - clients
 Utilities that control and interact with the Enlightened Sound Daemon.
 [EMAIL PROTECTED]:~$ sudo apt-get install esound-clients
 Reading package lists... Done
 Building dependency tree... Done
 esound-clients is already the newest version.

The workaround to this, for now, is to:
1) disable esd altogheter (to be able to have sound in firefox) OR
2) disable the esd wrapper (by setting a junk value in /etc/firefox/firefoxrc)
   and have sound in all other apps than firefox.

To Jesus Christ be the Glory, for helping me in finding this!

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.11-9-amd64-k8
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages firefox depends on:
ii  debianutils   2.15.2 Miscellaneous utilities specific t
ii  fontconfig2.3.2-1.1  generic font configuration library
ii  libatk1.0-0   1.10.3-1   The ATK accessibility toolkit
ii  libc6 2.3.5-11   GNU C Library: Shared libraries an
ii  libcairo2 1.0.2-3The Cairo 2D vector graphics libra
ii  libfontconfig12.3.2-1.1  generic font configuration library
ii  libfreetype6  2.1.10-1   FreeType 2 font engine, shared lib
ii  libgcc1   1:4.0.2-6  GCC support library
ii  libglib2.0-0  2.8.5-1The GLib library of C routines
ii  libgtk2.0-0   2.8.9-2The GTK+ graphical user interface 
ii  libidl0   0.8.5-1library for parsing CORBA IDL file
ii  libjpeg62 6b-11  The Independent JPEG Group's JPEG 
ii  libpango1.0-0 1.10.2-1   Layout and rendering of internatio
ii  libpng12-01.2.8rel-5 PNG library - runtime
ii  libstdc++64.0.2-6The GNU Standard C++ Library v3
ii  libx11-6  6.9.0.dfsg.1-3 X Window System protocol client li
ii  libxcursor1   1.1.3-1X cursor management library
ii  libxext6  6.9.0.dfsg.1-3 X Window System miscellaneous exte
ii  libxft2   2.1.7-1FreeType-based font drawing librar
ii  libxi66.9.0.dfsg.1-3 X Window System Input extension li
ii  libxinerama1  6.9.0.dfsg.1-3 X Window 

Bug#297283: Reproduced on my system

[Per Lundberg]

Package: mysql-server
Version: 4.0.23-7
Followup-For: Bug #297283

This bug was reproduced on my system.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages mysql-server depends on:
ii  adduser  3.59Add and remove users and groups
ii  debconf  1.4.30.11   Debian configuration management sy
ii  gawk 1:3.1.4-2   GNU awk, a pattern scanning and pr
ii  libc62.3.2.ds1-20GNU C Library: Shared libraries an
ii  libdbi-perl  1.46-6  Perl5 database interface by Tim Bu
ii  libmysqlclient12 4.0.23-7mysql database client library
ii  libstdc++5   1:3.3.5-8   The GNU Standard C++ Library v3
ii  libwrap0 7.6.dbs-6   Wietse Venema's TCP wrappers libra
ii  mailx1:8.1.2-0.20040524cvs-4 A simple mail user agent
ii  mysql-client 4.0.23-7mysql database client binaries
ii  mysql-common 4.0.23-7mysql database common files (e.g. 
ii  passwd   1:4.0.3-30.9change and administer password and
ii  perl 5.8.4-6 Larry Wall's Practical Extraction 
ii  psmisc   21.5-1  Utilities that use the proc filesy
ii  zlib1g   1:1.2.2-3   compression library - runtime

-- debconf information:
  mysql-server/nis_warning:
  mysql-server/really_downgrade_from_41: false
  mysql-server/mysql_update_hints1:
* mysql-server/start_on_boot: true
  mysql-server/postrm_remove_databases: false
* mysql-server/postrm_remove_database: false
* mysql-server/mysql_install_db_notes:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]