Bug#1034601:
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)
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)
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)
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)
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)
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)
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
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
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
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
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
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
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
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
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
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
This seems like a duplicate of #934372 to me.
Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8
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
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
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
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
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
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
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)
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
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 /run/systemd/system
Bug#906447: tomcat8: Errors thrown when connecting
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
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
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
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
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=) 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=) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:45 #1 0x0044a844 in ?? () #2 #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
peg.so.62 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 #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
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
Bug#297283: Reproduced on my system
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]