Bug#1065440: tomcat10: /etc/cron.daily/tomcat10 breaks tomcat's own deletion of old access logs
Package: tomcat10 Version: 10.1.6-1+deb12u1 Severity: normal X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, The tomcat10 package installs file '/etc/cron.daily/tomcat10' that encrypts "old" logs in the '/var/log/tomcat10' directory. The problem is that this cron jobs breaks the new mechanism that tomcat10 uses for deleting its own old log files. In particular adding the option 'maxDays="2" in section pn tomcat10-docs pn tomcat10-examples pn tomcat10-user -- Configuration Files: /etc/tomcat10/policy.d/01system.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/01system.policy' /etc/tomcat10/policy.d/02debian.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/02debian.policy' /etc/tomcat10/policy.d/03catalina.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/03catalina.policy' /etc/tomcat10/policy.d/04webapps.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/04webapps.policy' /etc/tomcat10/policy.d/50local.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/50local.policy' -- no debconf information
Bug#1034492: libtcnative-1: Tomcat warning suggesting a minimum version of 2.0.1 for tcnative
Package: libtcnative-1 Version: 1.2.35-1 Severity: normal X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, When running tomcat 10 (installed from default bookworm repo) it warns that "An older version [1.2.35] of the Apache Tomcat Native library is installed, while Tomcat recommends a minimum version of [2.0.1]" I feel debian should package a version of tc-native equals or newer than the recommendation of the packaged tomcat version. I wonder if we tomcat 9 still requires version 1.x of tcnative, which means debian should package both libtcnative-1 and a libtcnative-2, or if the latest tcnative 2 would suffice for both tomcat 9 and tomcat 10, and then we might want to drop the 1 in the tcnative package name and just package the latest 2.x version under that name. Thank you. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (800, 'testing'), (500, 'testing-security'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libtcnative-1 depends on: ii libapr1 1.7.2-3 ii libc62.36-8 ii libssl3 3.0.8-1 libtcnative-1 recommends no packages. libtcnative-1 suggests no packages. -- no debconf information
Bug#1033170: libitext-rups-java: Does not work at all
Hello Tony, I propose that we either reduce the severity, ignore the bug for the > bookworm release cycle, or remove only the libitext-rups-java binary > package from bookworm. > Thank you. I believe the appropriate action is #3 (remove libitext-rups-java binary package from bookworm) because it is useless as it stands. Two other comments for the record (1) An apt list libitext* reveals libitext-java/testing,unstable,testing,now 2.1.7-13 all [installed,automatic] libitext-rtf-java/testing,unstable,testing 2.1.7-13 all libitext-rups-java/testing,unstable,testing 2.1.7-13 all libitext1-java/testing,unstable,testing 1.4-7 all libitext5-java/testing,unstable,testing 5.5.13.3-2 all I am not familiar with libitext, so I don't know if we really need to maintain multiple versions of it in the repo. From the comments on the ubuntu bug report. It appears that versions 1 and 2 are hopelessly updated, but I do see that there are indeep packages that depend on the older versions. (2) If there is a maintainer for libitext-rups-java I would suggest they upgrade to use at least libitext5-java and then reupload to experimental. (Version 5 is not so old, but upstream is already at 7). On Sun, Mar 19, 2023 at 8:50 PM tony mancill wrote: > On Sat, Mar 18, 2023 at 05:42:12PM -0400, Jorge Moraleda wrote: > > Package: libitext-rups-java > > Version: 2.1.7-13 > > Severity: grave > > Justification: renders package unusable > > X-Debbugs-Cc: jorge.moral...@gmail.com > > > > Dear Maintainer, > > > > The package does not work at all. Based on the following Ubuntu bug > report it > > appears the version packaged is too old to work: > > https://bugs.launchpad.net/ubuntu/+source/libitext-java/+bug/802021 > > Hi Jorge, > > Thanks for filing the bug. You don't describe the desired behavior, but > when I run "java -jar /usr/share/java/itext-rups.jar" I don't get a GUI > for PDF manipulation, so there is definitely something broken there. > > By filing a severity grave [0] bug against this binary package you have > created a release-critical bug that also affects libitext-java [1], > which has almost 3 installs [2] and impacts multiple reverse > dependencies. And we're in the midst of the freeze for the bookwork > release [3]. > > I propose that we either reduce the severity, ignore the bug for the > bookworm release cycle, or remove only the libitext-rups-java binary > package from bookworm. > > Thank you, > tony > > [0] https://www.debian.org/Bugs/Developer#severities > [1] https://tracker.debian.org/pkg/libitext-java > [2] https://qa.debian.org/popcon.php?package=libitext-java > [3] https://release.debian.org/bookworm/freeze_policy.html >
Bug#1033170: libitext-rups-java: Does not work at all
Package: libitext-rups-java Version: 2.1.7-13 Severity: grave Justification: renders package unusable X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, The package does not work at all. Based on the following Ubuntu bug report it appears the version packaged is too old to work: https://bugs.launchpad.net/ubuntu/+source/libitext-java/+bug/802021 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (800, 'testing'), (500, 'testing-security'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libitext-rups-java depends on: ii libitext-java 2.1.7-13 libitext-rups-java recommends no packages. libitext-rups-java suggests no packages. -- no debconf information
Bug#1031036: sagemath: sage starts from command line but not from desktop menu
Package: sagemath Version: 9.5-6 Severity: normal X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, Sage fails to start from the graphical menu with "Failed to execute default Terminal Emulator" "Input/output error". The problem is confined to the menu launcher: sage starts without problem from the command line (e.g. typing "sage -n" from the terminal emulator). - The problem appears specific to sage, not to my configuration. This is the information that leads me to believe this: *** I have verified that all other applicatons that launch with "Terminal=true" work as intended. In particular all applications listed here, except for sage, open from their respective menu items /usr/share/applications$ grep "Terminal=true" * emacs-term.desktop:Terminal=true jupyter-notebook.desktop:Terminal=true mc.desktop:Terminal=true mcedit.desktop:Terminal=true python3.11.desktop:Terminal=true R.desktop:Terminal=true sagemath.desktop:Terminal=true vim.desktop:Terminal=true *** I use "terminator" as my default terminal emulator. # update-alternatives --config x-terminal-emulator There are 5 choices for the alternative x-terminal-emulator (providing /usr/bin/x-terminal-emulator). SelectionPath Priority Status * 0/usr/bin/terminator 50auto mode 1/usr/bin/koi8rxterm 20manual mode 2/usr/bin/lxterm 30manual mode 3/usr/bin/terminator 50manual mode 4/usr/bin/uxterm 20manual mode 5/usr/bin/xterm20manual mode $ x-terminal-emulator works as intended (opens a new window running terminator) *** I run xfce-4 as my window manager. My xfce4 configuration (Menu Applications -> Settings -> Default Applications -> Utilities -> Terminal Emulator) is set to "Debian X Terminal Emulator" This works as intended: $ exo-open --launch TerminalEmulator works as intended (opens a new window running terminator) -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (800, 'testing'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sagemath depends on: ii python3 3.11.1-3 ii python3-sage 9.5-6 Versions of packages sagemath recommends: ii sagemath-doc9.5-6 ii sagemath-jupyter9.5-6 ii sagetex 3.6.1+ds-1 ii texlive-latex-base 2022.20230122-1 Versions of packages sagemath suggests: pn dot2tex pn gap-design ii gap-factint 1.6.3+ds-2 pn gap-grape pn gap-guava ii gap-laguna 3.9.5+ds-2 pn gap-sonata pn gap-toric -- no debconf information
Bug#1030871: libtcnative-1: Current version of tcnative is not compatible with version of tomcat 10 packaged
Package: libtcnative-1 Version: 1.2.32-1+b1 Severity: important X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, The version of tomcat10 currently packaged (10.1.5) cannot work with the version of libtcnative-1 currently packaged (1.2.32). The exact log error in Catalina.out is An incompatible version [1.2.32] of the Apache Tomcat Native library is installed, while Tomcat requires version [1.2.34] I think that tomcat9 "may" still be able to use 1.2.32 version (I have not tested it) hence I have marked the severity "important" and not "grave". Thank you -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (800, 'testing'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libtcnative-1 depends on: ii libapr1 1.7.0-8 ii libc62.36-8 ii libssl3 3.0.7-2 libtcnative-1 recommends no packages. libtcnative-1 suggests no packages. -- no debconf information
Bug#1030869: tomcat10: Catalina won't deploy applications missing class jakarta.websocket.DeploymentException
Package: tomcat10 Version: 10.1.5-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, Catalina is unable to deploy any applications (including samplp ROOT) complaining of java.lang.ClassNotFoundException: jakarta.websocket.DeploymentException Please see full log of Catalina.out [2023-02-08 11:21:24] [info] Listening for transport dt_socket at address: 8000 [2023-02-08 11:21:24] [info] Server version name: Apache Tomcat/10.1.5 (Debian) [2023-02-08 11:21:24] [info] Server built: Jan 2 1970 23:05:43 UTC [2023-02-08 11:21:24] [info] Server version number: 10.1.5.0 [2023-02-08 11:21:24] [info] OS Name: Linux [2023-02-08 11:21:24] [info] OS Version:6.1.0-3-amd64 [2023-02-08 11:21:24] [info] Architecture: amd64 [2023-02-08 11:21:24] [info] Java Home: /usr/lib/jvm/java-17-openjdk-amd64 [2023-02-08 11:21:24] [info] JVM Version: 17.0.6+10-Debian-1 [2023-02-08 11:21:24] [info] JVM Vendor:Debian [2023-02-08 11:21:24] [info] CATALINA_BASE: /var/lib/tomcat10 [2023-02-08 11:21:24] [info] CATALINA_HOME: /usr/share/tomcat10 [2023-02-08 11:21:24] [info] Command line argument: -Djava.util.logging.config.file=/var/lib/tomcat10/conf/logging.properties [2023-02-08 11:21:24] [info] Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager [2023-02-08 11:21:24] [info] Command line argument: -Djava.awt.headless=true [2023-02-08 11:21:24] [info] Command line argument: -agentlib:jdwp=transport=dt_socket,address=nile:8000,server=y,suspend=n [2023-02-08 11:21:24] [info] Command line argument: -Djdk.tls.ephemeralDHKeySize=2048 [2023-02-08 11:21:24] [info] Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources [2023-02-08 11:21:24] [info] Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 [2023-02-08 11:21:24] [info] Command line argument: --add- opens=java.base/java.lang=ALL-UNNAMED [2023-02-08 11:21:24] [info] Command line argument: --add- opens=java.base/java.io=ALL-UNNAMED [2023-02-08 11:21:24] [info] Command line argument: --add- opens=java.base/java.util=ALL-UNNAMED [2023-02-08 11:21:24] [info] Command line argument: --add- opens=java.base/java.util.concurrent=ALL-UNNAMED [2023-02-08 11:21:24] [info] Command line argument: --add- opens=java.rmi/sun.rmi.transport=ALL-UNNAMED [2023-02-08 11:21:24] [info] Command line argument: -Dcatalina.base=/var/lib/tomcat10 [2023-02-08 11:21:24] [info] Command line argument: -Dcatalina.home=/usr/share/tomcat10 [2023-02-08 11:21:24] [info] Command line argument: -Djava.io.tmpdir=/tmp [2023-02-08 11:21:24] [info] The Apache Tomcat Native library which allows using OpenSSL was not found on the java.library.path: [/usr/java/packages/lib:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux- gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib] [2023-02-08 11:21:25] [info] The ["https-jsse-nio-8443"] connector has been configured to support negotiation to [h2] via ALPN [2023-02-08 11:21:25] [info] Initializing ProtocolHandler ["https-jsse- nio-8443"] [2023-02-08 11:21:25] [info] Server initialization in [1098] milliseconds [2023-02-08 11:21:25] [info] Starting service [Catalina] [2023-02-08 11:21:25] [info] Starting Servlet engine: [Apache Tomcat/10.1.5 (Debian)] [2023-02-08 11:21:26] [info] Deploying web application directory [/var/lib/tomcat10/webapps/ROOT] [2023-02-08 11:21:26] [crit] Error deploying web application directory [/var/lib/tomcat10/webapps/ROOT] [2023-02-08 11:21:26] [crit] java.lang.IllegalStateException: Error starting child [2023-02-08 11:21:26] [crit] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:729) [2023-02-08 11:21:26] [crit] at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698) [2023-02-08 11:21:26] [crit] at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747) [2023-02-08 11:21:26] [crit] at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1136) [2023-02-08 11:21:26] [crit] at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1971) [2023-02-08 11:21:26] [crit] at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [2023-02-08 11:21:26] [crit] at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [2023-02-08 11:21:26] [crit] at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) [2023-02-08 11:21:26] [crit] at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:123) [2023-02-08 11:21:26] [crit] at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1046) [2023-02-08 11:21:26] [crit] at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:428) [2023-02-08 11:21:26] [crit] at
Bug#1028345:
Dear maintainer, The package is also uninstallable in bookworm with: The following packages have unmet dependencies: python3-sage : Depends: libgap7 (>= 4.11.0-1) but it is not installable Depends: libpari-gmp-tls7 but it is not installable Depends: libsingular4m2n1 (>= 1:4.2.1-p3+ds) but it is not installable Recommends: cysignals-tools but it is not going to be installed Recommends: maxima-sage-doc (>= 5.42.2) but it is not going to be installed Recommends: python3-sagenb-export (>= 3.2) but it is not going to be installed Recommends: singular-doc (>= 1:4.2.1-p2+ds-3) but it is not going to be installed With respect to the missing dependencies, I remark that bookworm contains the following packages: ** libgap8* instead of *libgap7* ** libpari-gmp-tls8* instead of *libpari-gmp-tls7* ** libsingular4m3n0 *instead of *libsingular4m2n1* Potentially, fixing installability might be as simple as updating the dependencies.
Bug#1028433:
This other bug is at the core of why sagemath cannot be installed in bookworm https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028345
Bug#1029293: wxhexeditor: undefined symbol when accessing wxWidgets library
Package: wxhexeditor Version: 0.24+repack-2+b2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, The current version of wxHexEditor fails to start with error: wxHexEditor: symbol lookup error: wxHexEditor: undefined symbol: _ZN12wxEvtHandler21WXReservedEvtHandler1EPv, version WXU_3.2 Perhaps this is related to the upgrade of the wxWidgets dependency from version 3.0 to version 3.2 as discussed in https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1019812 ? -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (800, 'testing'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wxhexeditor depends on: ii libc6 2.36-8 ii libdisasm0 0.23-6+b1 ii libgcc-s1 12.2.0-14 ii libgomp112.2.0-14 ii libmhash2 0.9.9.9-9 ii libstdc++6 12.2.0-14 ii libwxbase3.2-1 3.2.1+dfsg-4+b1 ii libwxgtk3.2-1 3.2.1+dfsg-4+b1 wxhexeditor recommends no packages. wxhexeditor suggests no packages. -- no debconf information
Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"
> I searched for some definition that says, that a .pfb file has to > be prefixed with 80 01 91 03 00 00 (in front of %!PS-AdobeFont-1.), > but didn't find such a specification. I found this in case it helps https://personal.math.ubc.ca/~cass/piscript/type1.pdf
Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"
Hello Fabian and James, Thank you for looking into this. I remark that the symbolic links created in the *"X11/Type1" *folder change the file extension of the original file. In particular: > > file /usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb > /usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb: symbolic link to > ../../type1/urw-base35/NimbusSans-BoldItalic.t1 > (Notice the origin file has extension *"t1"* but the symbolic link changes that to *"pfb"*) Is this change intentional? It appears pdfbox is using the extension to determine the file type because renaming the symbolic link to preserve the "t1" extension in the symbolic link fixes the problem. Fabian mentioned that *"upstream has decided to rename the binary font files and in that course change the file extensions from .pfb to .t1." *but from the above experiment it seems that upstream changed the actual file format, and then they changed the file extensions to match the new format. IMHO opinion, the solution would be to either not create the symbolic links or to preserve the original names including the extension. I don't know enough to know what is best.
Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"
Package: fonts-urw-base35 Version: 20200910-6 Severity: important X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, I use fonts as part of a java application I develop. I recently upgraded my system (to an up-to-date debian bookworm). After this upgrade all fonts packaged in this packet are unloadable by apache pdfbox (but fonts in the many other font packages that I have installed all load fine). This is the relevant portion of the logs showing the error (I am including logs for the error when loading font "NimbusSans-BoldItalic.pfb" but logs for other fonts in the package are the same) [2023-01-18 13:15:26] [info] 2023-01-18 13:15:26.561 WARN 228307 --- [alina- utility-1] o.a.p.p.f.FileSystemFontProvider : Could not load font file: /usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb [2023-01-18 13:15:26] [info] java.io.IOException: Start marker missing [2023-01-18 13:15:26] [info] #011at org.apache.fontbox.pfb.PfbParser.parsePfb(PfbParser.java:147) [2023-01-18 13:15:26] [info] #011at org.apache.fontbox.pfb.PfbParser.(PfbParser.java:115) [2023-01-18 13:15:26] [info] #011at org.apache.fontbox.type1.Type1Font.createWithPFB(Type1Font.java:54) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addType1Font(FileSystemFontProvider.java:790) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:391) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.(FileSystemFontProvider.java:361) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.(FontMapperImpl.java:141) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:160) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:430) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:393) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:367) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:146) [2023-01-18 13:15:26] [info] #011at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:79) I am using apache pdfbox version 2.0.27 (https://mvnrepository.com/artifact/org.apache.pdfbox/pdfbox) I am not familiar with fonts, but according to the source code (https://github.com/apache/pdfbox/blob/trunk/fontbox/src/main/java/org/apache/fontbox/pfb/PfbParser.java) it appears that pdfbox expects the font files in pfb format to start with character 0x80 but they do not. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (800, 'testing'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fonts-urw-base35 depends on: ii xfonts-utils 1:7.7+6 fonts-urw-base35 recommends no packages. Versions of packages fonts-urw-base35 suggests: ii fonts-freefont-otf 20120503-10 ii fonts-freefont-ttf 20120503-10 ii fonts-texgyre 20180621-6 -- no debconf information
Bug#1028632: tomcat10: Catalina fails to load due to missing MbeansDescriptorsIntrospectionSource
Package: tomcat10 Version: 10.0.0~M7-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, I just tested the tomcat 10 version packaged in the "debian/experimental". (10.0.0~M7-1) on top of a recent debian 12 (bookworm) installation. It failed with "java.lang.ClassNotFoundException: org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource". I don't think detailed logs are necessary because: (1) This bug is the same as https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=964908 (that one is against tomcat9). (2) From the above it seems that it has to do with the format of "bnd" and from this package changelogs, I believe the maintainers are already familiar with this issue. (https://metadata.ftp- master.debian.org/changelogs//main/t/tomcat10/tomcat10_10.0.0~M7-1_changelog) Thank you -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (800, 'testing'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tomcat10 depends on: ii lsb-base 11.5 ii systemd252.4-1 ii sysvinit-utils [lsb-base] 3.06-2 ii tomcat10-common10.0.0~M7-1 ii ucf3.0043 Versions of packages tomcat10 recommends: ii libtcnative-1 1.2.32-1+b1 Versions of packages tomcat10 suggests: pn tomcat10-admin pn tomcat10-docs pn tomcat10-examples pn tomcat10-user -- Configuration Files: /etc/tomcat10/policy.d/01system.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/01system.policy' /etc/tomcat10/policy.d/02debian.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/02debian.policy' /etc/tomcat10/policy.d/03catalina.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/03catalina.policy' /etc/tomcat10/policy.d/04webapps.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/04webapps.policy' /etc/tomcat10/policy.d/50local.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/50local.policy' -- no debconf information
Bug#965006:
I think getting tomcat 10 into unstable so it is in a path to eventually making into testing and then stable has become a higher priority now that tomcat 10 is required when using webapps developed using the latest Spring framework version ( https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-6.x ) Thus IMHO we should resolve this issue by adding the Breaks+Replaces to libtomcat10-java and give up co-instalability. Of course we should immediately open a feature request to get co-instalability back, but that would not stop the package from going into unstable and, after bookworm is released, testing.
Bug#964908:
Buster backports now contains version 9.0.38-1~bpo10+1 which does not exhibit this bug.
Bug#948286: maven: CDK 2.3 fails to compile with Maven 3.6.2 with ClassNotFoundException
I confirm this is still an issue and that it can be manually fixed by installing libplexus-utils2-java from Testing. On Wed, 8 Jan 2020 17:35:04 +0200 Andrius Merkys wrote: > On Tue, 7 Jan 2020, 23:41 Emmanuel Bourg, wrote: > > > I confirm this is not a cdk issue. It happened because the maven package > > from testing was installed in stable and libplexus-utils2-java 3.2 > > wasn't brought along. > > > > This wouldn't happen if libmaven3-core-java had the correct versioned > > dependency on libplexus-utils2-java. Unfortunately due to a bug in > > maven-debian-helper the versioned dependency is wrong (the version is > > 2.x instead of 3.2.1). > > > > Hello, > > I was too quick to jump to conclusions, sorry. Is there a bug filed for > this issue in maven-debian-helper? If so, we should consider merging this > report to it. > > Best, > Andrius > > >
Bug#942901:
The solution given by Paul Wise worked for me after restarting app armor: systemctl restart apparmor
Bug#893134:
This is still broken in version 11.0.1+13-2
Bug#898391:
> I did an update just yesterday, and going > apt install -t stretch-backports > nvidia-driver nvidia-driver-libs-nonglvnd worked Thank you again. What repository do you get xserver-xorg-core from? The one in stretch depends on libegl1-mesa | libegl1 which conflict with nvidia-driver-libs-nonglvnd.
Bug#898391:
> aptitude will resolve it just fine, apt seems to need a helping hand > depending on whether you want the glvnd or non-glvnd flavours, specify > one of the nvidia-driver-libs* packages as well as nvidia-driver and it > will upgrade it. Dear Luca, Thank you for your quick reply. When I try to use aptitude to resolve the conflicts, eventually I get to the following problem: NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) Some dependencies of nvidia-driver-libs (broken, 390.48-2~bpo9+1) are not satisfied: * nvidia-driver-libs (upgrade, 390.48-2~bpo9+1 -> 390.48-2~bpo9+3) conflicts with libegl1 (> 0) * nvidia-driver-libs (upgrade, 390.48-2~bpo9+1 -> 390.48-2~bpo9+3) conflicts with libegl1-mesa (>= 17) * nvidia-driver-libs (upgrade, 390.48-2~bpo9+1 -> 390.48-2~bpo9+3) conflicts with libgl1 (> 0) * nvidia-driver-libs (upgrade, 390.48-2~bpo9+1 -> 390.48-2~bpo9+3) conflicts with libgl1-mesa-glx (>= 17) * nvidia-driver-libs (upgrade, 390.48-2~bpo9+1 -> 390.48-2~bpo9+3) conflicts with libgles2 (> 0) * nvidia-driver-libs (upgrade, 390.48-2~bpo9+1 -> 390.48-2~bpo9+3) conflicts with libglvnd0 (> 0) * nvidia-driver-libs (upgrade, 390.48-2~bpo9+1 -> 390.48-2~bpo9+3) conflicts with libglx0 (> 0) * nvidia-driver-libs (upgrade, 390.48-2~bpo9+1 -> 390.48-2~bpo9+3) conflicts with libopengl0 (> 0) I get the same conflicts with the non-GLVND version. I could continue manually removing the conflicting libraries, but I feel that is the wrong path because several unrelated applications complain of missing dependencies. What do you think?
Bug#898391:
What is the state of this? I am on stretch backports trying to upgrade from 390.48-2~bpo9+1 (everything working fine) to 390.48-2~bpo9+3. I am experiencing something which is another symptom of this bug. Many packets are held back. I believe the fundamental problem lies with nvidia-driver : Depends: nvidia-driver-libs (= 390.48-2~bpo9+3) but it is not going to be installed or nvidia-driver-libs-nonglvnd (= 390.48-2~bpo9+3) but it is not going to be installed I am on stretch backports trying to upgrade from 390.48-2~bpo9+1 (everything working fine) to 390.48-2~bpo9+3
Bug#864840: error: cannot overload functions distinguished by return type alone version graph
Hello Lumin, Thank you for looking into it. Personally, I have no problem if you decide not to fix this and I can see that patching the package instead of waiting for upstream support could open a can of worms. I have patched my own system with the fix I sent you and cuda is working smoothly for me with the default gcc 6 tool chain after that. The fact that I had a patch and it was minimal is the reason I sent the bug report: I thought other people would benefit from the simplicity of being able to use the default tool chain. Also, even though cuda 8 does not officially support gcc 6, in practice recent releases have been moving into compliance in preparation for the 8.5 release (in fact the two lines the patch comments out were introduced explicitly to address an ideosyncracy of gcc 6.1 as the comments in that file reveal). Thank you again. Best regards, Jorge On 15 June 2017 at 20:03, Luminwrote: > Control: tags -1 +wontfix > > Hi, > > > The header file math_functions.h is not compatible with gcc 6.3 shipped > with stretch. > > Actually CUDA 8.0.44 does not support GCC-6 at all. Lookup this document > for > working compiler combinations: > > /usr/share/doc/nvidia-cuda-toolkit/README.Debian > > I'd suggest that (1) compile the application with clang-3.8 (shipped > by stretch). > OR (2) temporarily add the sid/unstable apt source, pull GCC-5 then remove > that apt source and compile with GCC-5. OR (3) Get GCC-5/clang-3.8 by other > approaches. > > We can do nothing to change the fact, hence marking this bug as wontfix. >
Bug#864840: error: cannot overload functions distinguished by return type alone
Package: nvidia-cuda-dev Version: 8.0.44-4 Severity: important Dear Maintainer, The header file math_functions.h is not compatible with gcc 6.3 shipped with stretch. In particular, when this header is included in a cuda project the following errors are reported: /usr/include/math_functions.h(8897): error: cannot overload functions distinguished by return type alone /usr/include/math_functions.h(8901): error: cannot overload functions distinguished by return type alone The solution is to comment out the offending lines (which is completely harmless since the lines are work arounds an issue with gcc 6.1 as mentioned in the source itself). The following is a diff of the modified file and original file: diff /usr/include/math_functions.h /usr/include/math_functions.h~ 8897c8897 < //__DEVICE_FUNCTIONS_DECL__ __cudart_builtin__ int isnan(double x) throw(); --- > __DEVICE_FUNCTIONS_DECL__ __cudart_builtin__ int isnan(double x) throw(); 8901c8901 < //__DEVICE_FUNCTIONS_DECL__ __cudart_builtin__ int isinf(double x) throw(); --- > __DEVICE_FUNCTIONS_DECL__ __cudart_builtin__ int isinf(double x) throw(); This problem also occurred in Fedora 24 and was solved the same way as can be seen at: https://xpra.org/trac/ticket/1328 Thank you very much. Best regards, Jorge Moraleda -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nvidia-cuda-dev depends on: ii libcublas8.08.0.44-4 ii libcudart8.08.0.44-4 ii libcufft8.0 8.0.44-4 ii libcufftw8.08.0.44-4 ii libcuinj64-8.0 8.0.44-4 ii libcurand8.08.0.44-4 ii libcusolver8.0 8.0.44-4 ii libcusparse8.0 8.0.44-4 ii libnppc8.0 8.0.44-4 ii libnppi8.0 8.0.44-4 ii libnppial8.08.0.44-4 ii libnppicc8.08.0.44-4 ii libnppicom8.0 8.0.44-4 ii libnppidei8.0 8.0.44-4 ii libnppif8.0 8.0.44-4 ii libnppig8.0 8.0.44-4 ii libnppim8.0 8.0.44-4 ii libnppist8.08.0.44-4 ii libnppisu8.08.0.44-4 ii libnppitc8.08.0.44-4 ii libnpps8.0 8.0.44-4 ii libnvblas8.08.0.44-4 ii libnvgraph8.0 8.0.44-4 ii libnvrtc8.0 8.0.44-4 ii libnvtoolsext1 8.0.44-4 ii libnvvm38.0.44-4 ii libthrust-dev 1.8.1-1 Versions of packages nvidia-cuda-dev recommends: ii libcuda1 [libcuda-8.0-1] 375.66-1 ii libgl1-mesa-dev [libgl-dev] 13.0.6-1+b2 ii libnvcuvid1 375.66-1 ii libvdpau-dev 1.1.1-6 nvidia-cuda-dev suggests no packages. -- no debconf information
Bug#708508: Follow up. Instructions to set up pdf indexing on debian.
On a debian stretch release, I followed this instructions and the result worked: http://vk5tu.livejournal.com/54476.html?nojs=1 The package should be able to set this up automatically. Thank you.
Bug#708508: Bug still present in stretch, but has been fixed upstream as of April 2015
Dear debian package maintainer, The version of zotero-standalone including in the stretch release still is trying to find executables pdftotext-Linux-x86_64 and pdfinfo-Linux-x86_64 instead of the files pdftotext and pdfinfo that are installed with poppler-utils. As reported earlier in this bug, in the past zotero used custom executables so depending on poppler-utils and using the standard pdfinfo and pdftotext was a problem, but according to zotero developer dstillman, as of April 2015 zotero uses the standard executables included in poppler utils (See dstillman comment on https://github.com/zotero/zotero-standalone-build/issues/28). So it finally should be possible to build a debian package that resolves this issue. Best regards, Jorge
Bug#863988: remmina not in stretch repository
Package: remmina Version: 1.1.2-4 Severity: grave Justification: renders package unusable Dear Maintainer, Package remmina has disappeared from the stretch repository. This can be seen for example here: https://packages.debian.org/search?keywords=remmina where remmina shows both in jessie and sid, but not stretch. This can also be verified by executing: apt-get install remmina which produces output Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package remmina For your reference this is the sources.list: ## Debian Main Repos deb http://deb.debian.org/debian/ stretch main contrib non-free deb-src http://deb.debian.org/debian/ stretch main contrib non-free deb http://deb.debian.org/debian/ stretch-updates main contrib non-free deb-src http://deb.debian.org/debian/ stretch-updates main contrib non-free ## Debian Updates from the Security team deb http://security.debian.org/ stretch/updates main deb-src http://security.debian.org/ stretch/updates main ## Debian backports from testing deb http://deb.debian.org/debian/ stretch-backports main contrib non-free -- It is worth noting that package remmina used to be present in the stretch repository until recently and installed and worked as expected. For your reference, the system information below is from a machine running stretch where I installed remmina from the stretch repo before it disappeared. remmina works just fine in that machine which otherwise has an up to date version of stretch. Thank you. Best regards, Jorge Moraleda -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages remmina depends on: ii dbus-user-session [default-dbus-session-bus] 1.10.18-1 ii dbus-x11 [dbus-session-bus] 1.10.18-1 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libavahi-ui-gtk3-00.6.32-2 ii libc6 2.24-10 ii libgcrypt20 1.7.6-1 ii libgdk-pixbuf2.0-02.36.5-2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libpango-1.0-01.40.5-1 ii libssh-4 0.7.3-2 ii libvte-2.91-0 0.46.1-1 ii libx11-6 2:1.6.4-3 ii remmina-common1.1.2-4 Versions of packages remmina recommends: ii remmina-plugin-rdp 1.1.2-4 ii remmina-plugin-vnc 1.1.2-4 remmina suggests no packages. -- no debconf information
Bug#862054: python3-igraph: error when plotting graph inline in jupyter notebook
Package: python3-igraph Version: 0.7.1.post6-3 Severity: normal Dear Maintainer, Attempting to plot within jupyter notebook yields the error: AttributeError: 'bytes' object has no attribute 'encode' This code reproduces this bug when typed inside a jupyter notebook: import igraph G = igraph.Graph.Erdos_Renyi(100, 0.1); igraph.plot(G) This bug agains the python igraph package is discussed in greater detail at https://github.com/igraph/python-igraph/issues/88 and was fixed in the 0.7 release branch of python-igraph that debian includes on August 5, 2016 (https://github.com/igraph/python-igraph/commit/8864b46849b031a3013764d03e167222963c0f5d) We should repackage the debian package python3-igraph with a later version python igraph that incorporates this fix as plotting is an important component of the igraph library. Thank you. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-igraph depends on: ii libc6 2.24-10 ii libigraph0v5 0.7.1-2.1+b2 ii python3 3.5.3-1 pn python3:any python3-igraph recommends no packages. python3-igraph suggests no packages. -- no debconf information
Bug#860501: python3-pyvirtualdisplay should require python3-xvfbwrapper
Package: python3-pyvirtualdisplay Version: 0.2.1-1 Severity: normal Dear Maintainer, python3-pyvirtualdisplay requires python3-xvfbwrapper and it should list it as a dependency but it does not. If python3-xvfbwrapper is not installed, the line: display = pyvirtualdisplay.Display(visible=0, size=(800, 600)) will fail with: display = pyvirtualdisplay.Display(visible=0, size=(800, 600)) File "/usr/lib/python3/dist-packages/pyvirtualdisplay/display.py", line 34, in __init__ self._obj = self.display_class( File "/usr/lib/python3/dist-packages/pyvirtualdisplay/display.py", line 52, in display_class cls.check_installed() File "/usr/lib/python3/dist-packages/pyvirtualdisplay/xvfb.py", line 38, in check_installed ubuntu_package=PACKAGE).check_installed() File "/usr/lib/python3/dist-packages/easyprocess/__init__.py", line 180, in check_installed raise EasyProcessCheckInstalledError(self) easyprocess.EasyProcessCheckInstalledError: cmd=['Xvfb', '-help'] OSError=[Errno 2] No such file or directory: 'Xvfb' Program install error! -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-pyvirtualdisplay depends on: ii python3-easyprocess 0.2.3-1 pn python3:any python3-pyvirtualdisplay recommends no packages. python3-pyvirtualdisplay suggests no packages. -- no debconf information
Bug#860485: phantomjs: Does not work as webdriver for selenium because ghostdriver is not packaged
Package: phantomjs Version: 2.1.1+dfsg-2 Severity: important Dear Maintainer, phantomjs will not work as a headless webdriver with selenium because src/ghostdriver/third_party/webdriver-atoms files needed for using phantomjs as a selenium backend are not included. This a packaging issue as things work as expected when downloading phantomjs from the phantomjs website instead of using the version packaged. This post includes code necessary to reproduce the problem: http://stackoverflow.com/questions/36770303/phantomjs-with-selenium-unable-to-load-atom-find-element The following two posts further clarify what the exact packing problem is: https://github.com/ariya/phantomjs/issues/14424 https://bugs.launchpad.net/ubuntu/+source/phantomjs/+bug/1578444 Best regards, Jorge Moraleda -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages phantomjs depends on: ii libc6 2.24-9 ii libgcc1 1:6.3.0-12 ii libgl1-mesa-glx [libgl1] 13.0.6-1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5gui55.7.1+dfsg-3+b1 ii libqt5network55.7.1+dfsg-3+b1 ii libqt5printsupport5 5.7.1+dfsg-3+b1 ii libqt5webkit5 5.7.1+dfsg-1 ii libqt5widgets55.7.1+dfsg-3+b1 ii libstdc++66.3.0-12 phantomjs recommends no packages. phantomjs suggests no packages. -- no debconf information
Bug#857795: Correct location for installed files is /usr/share/locale/
Dear Mantainer, All files installed in /usr/@DATADIRNAME@/locale/ should instead be installed to /usr/share/locale. One other packet, mssh, also incorrectly installs files to /usr/@DATADIRNAME@/locale. This has been reported separately as bug #858567 Best regards, Jorge Moraleda
Bug#858567: mssh: local files installed to /usr/@DATADIRNAME@/locale
Package: mssh Severity: normal Tags: l10n Dear Maintainer, mssh incorrectly installs local files to /usr/@DATADIRNAME@/locale It should install them to /usr/share/locale instead $ apt-file search @DATADIRNAME@ | grep mssh mssh: /usr/@DATADIRNAME@/locale/es/LC_MESSAGES/mssh.mo A similar problem occurs in package gnome-system-tools. That packaging bug has been reported as bug #857795. Thank you, Jorge Moraleda -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#620193: #include statements in packaged header files point to wrong directory
Package: libpoppler-dev Version: 0.12.4-1.2 Justification: renders package unusable Severity: grave Tags: patch Several header files in /usr/include/poppler/fofi and /usr/include/poppler/splash include headers that are in /usr/include/poppler/goo through lines of the form #include goo/foobar.h These lines are broken and need to be replaced with lines of the form #include ../goo/foobar.h. This can be fixed by running: sed -i 's/#include goo\//#include ..\/goo\//g' *h inside usr/include/poppler/fofi and /usr/include/poppler/splash -- System Information: Debian Release: 6.0.1 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpoppler-dev depends on: ii libfontconfig1-dev2.8.0-2.1 generic font configuration library ii libpoppler5 0.12.4-1.2 PDF rendering library libpoppler-dev recommends no packages. libpoppler-dev suggests no packages. -- no debconf information
Bug#608347: libtbb2-dbg: Segfault at _dl_relocate_object() dl-reloc.c:242 0x00007ffff7de9b03
Dear Neil and Roberto, Thank you for looking so quickly into this. Here are instructions on how to reproduce the bug: 1) For source code we will use one of the examples that come with the library. To obtain the example install package tbb-examples. 2) Following the instructions in /usr/share/doc/tbb-examples/README.debian, we will make a copy of the examples source to a directory where we have write permissions: cd ~ cp -r /usr/share/doc/tbb-examples/ . cd tbb-examples find . -name '*.gz'| xargs gunzip cd examples 3) The README.debian file now calls to execute make to build all examples. Unfortunately the Makefiles shipped with the examples have not been debianized, so they will fail because the directory structure in debian is not the same one that you get when you install directly from http://www.threadingbuildingblocks.org/file.php?fid=77, which is what the current Makefiles expect (this is a separate bug that should be filed against package tbb-examples), so instead, we will fix the Makefile for one of the examples: cd parallel_for/tachyon perl -p -i -e s/-ltbb_debug/\/usr\/lib\/debug\/usr\/lib\/libtbb.so.2/g Makefile 4) We will make and try the release version: make release ./tachyon.tbb We get some Usage output 5) Now the debug version: make clean make debug ./tachyon.tbb We get a Segmentation fault My guess is that the libraries in debug mode need to be compiled with some switch in g++ but unfortunately I don't know what it is. Thank you. Regards, Jorge On Thu, Dec 30, 2010 at 2:33 AM, Neil Williams codeh...@debian.org wrote: On Wed, 29 Dec 2010 22:06:52 -0500 Roberto C. Sánchez robe...@connexer.com wrote: I am curious as to whether the release team thinks that #608347 (quoted below) is really RC. Do I need to target the fix for this to go into Squeeze? I've tried a simple test program to replicate the results but I don't know enough about the library to get it to compile. Is there a snippet of C code which can be compiled with a simple: $ gcc -o test -ltbb test.c ? (Preferably a sample which just #include's the appropriate headers and doesn't have to initialise too much other stuff.) It doesn't seem fair to seek judgement on the importance of the bug report without being able to reproduce the problem or find out whether the problem actually exists on other systems than that of the submitter. When linking against the tbb debug libraries from the package, a segmentation fault occurs at initialization time: It would be very useful to have a test case piece of code from the original use case too. -- Neil Williams = http://www.linux.codehelp.co.uk/
Bug#608347: libtbb2-dbg: Segfault at _dl_relocate_object() dl-reloc.c:242 0x00007ffff7de9b03
Package: libtbb2-dbg Version: 3.0+r035-1 Justification: renders package unusable Severity: grave When linking against the tbb debug libraries from the package, a segmentation fault occurs at initialization time: 17 _dl_relocate_object() dl-reloc.c:242 0x77de9b03 16 dl_main() rtld.c:2232 0x77de2970 15 _dl_sysdep_start() dl-sysdep.c:243 0x77df36e7 14 _dl_start_final() rtld.c:338 0x77de0423 13 _dl_start() rtld.c:564 0x77de0423 12 _start() 0x77ddfaf8 This problem does not occur when linking against the release version of the library in package libtbb2 or when linking aganst the release or debug versions downloaded from http://www.threadingbuildingblocks.org -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libtbb2-dbg depends on: ii libtbb2 3.0+r035-1 parallelism library for C++ - runt libtbb2-dbg recommends no packages. libtbb2-dbg suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608348: libtbb2-dbg: Segfault during initialization ( _dl_relocate_object() dl-reloc.c:242 )
Package: libtbb2-dbg Version: 3.0+r035-1 Justification: renders package unusable Severity: grave *** Please type your report below this line *** When linking against the tbb debug libraries from the package, a segmentation fault occurs at initialization time: 17 _dl_relocate_object() dl-reloc.c:242 0x77de9b03 16 dl_main() rtld.c:2232 0x77de2970 15 _dl_sysdep_start() dl-sysdep.c:243 0x77df36e7 14 _dl_start_final() rtld.c:338 0x77de0423 13 _dl_start() rtld.c:564 0x77de0423 12 _start() 0x77ddfaf8 This problem does not occur when linking against the release version of the library in package libtbb2 or when linking against the linux binary versions downloaded from http://www.threadingbuildingblocks.org (either release or debug). I am running up-to-date debian sid with kernel: 2.6.32-5-amd64 I will be glad to help to submit any other information that might be helpful. Thank you for packaging TBB. Regards, Jorge
Bug#585679: libscilab-java: should, but does not, install /usr/lib/scilab/libjavasci
Package: libscilab-java Version: 5.2.2-1 Severity: grave Justification: renders package unusable libjavasci is not installed by this package, but it is required for the package to provide the desired functionality. In particular to invoke scilab from java. Currently java programs trying to invoke scilab fail with: The native library javasci does not exist or cannot be found. java.lang.UnsatisfiedLinkError: no javasci in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1681) at java.lang.Runtime.loadLibrary0(Runtime.java:840) at java.lang.System.loadLibrary(System.java:1047) at javasci.Scilab.clinit(Unknown Source) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libscilab-java depends on: ii scilab-full-bin 5.2.2-1Scientific software package for nu libscilab-java recommends no packages. libscilab-java suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549997: update opencv to version 2.0
Package: opencv Version: 1.0.0-6.2 opencv recently released version 2.0. Please update in sid. http://opencv.willowgarage.com/wiki/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org