Bug#1065440: tomcat10: /etc/cron.daily/tomcat10 breaks tomcat's own deletion of old access logs

2024-03-04 Thread Jorge Moraleda
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

2023-04-16 Thread Jorge Moraleda
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

2023-03-19 Thread Jorge Moraleda
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

2023-03-18 Thread Jorge Moraleda
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

2023-02-10 Thread Jorge Moraleda
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

2023-02-08 Thread Jorge Moraleda
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

2023-02-08 Thread Jorge Moraleda
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:

2023-01-24 Thread Jorge Moraleda
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:

2023-01-24 Thread Jorge Moraleda
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

2023-01-20 Thread Jorge Moraleda
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"

2023-01-20 Thread Jorge Moraleda
> 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"

2023-01-19 Thread Jorge Moraleda
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"

2023-01-18 Thread Jorge Moraleda
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

2023-01-13 Thread Jorge Moraleda
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:

2023-01-13 Thread Jorge Moraleda
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:

2020-09-27 Thread Jorge Moraleda
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

2020-07-31 Thread Jorge Moraleda
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:

2019-10-30 Thread Jorge Moraleda
The solution given by Paul Wise worked for me after restarting app armor:
systemctl restart apparmor


Bug#893134:

2018-11-29 Thread Jorge Moraleda
This is still broken in version 11.0.1+13-2


Bug#898391:

2018-06-01 Thread Jorge Moraleda
> 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:

2018-06-01 Thread Jorge Moraleda
​> ​
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:

2018-05-31 Thread Jorge Moraleda
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

2017-06-16 Thread Jorge Moraleda
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, Lumin  wrote:

> 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

2017-06-15 Thread Jorge Moraleda
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.

2017-06-13 Thread Jorge Moraleda
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

2017-06-13 Thread Jorge Moraleda
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

2017-06-02 Thread Jorge Moraleda
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

2017-05-07 Thread Jorge Moraleda
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

2017-04-17 Thread Jorge Moraleda
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

2017-04-17 Thread Jorge Moraleda
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/

2017-03-23 Thread Jorge Moraleda
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

2017-03-23 Thread Jorge Moraleda
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

2011-03-30 Thread Jorge Moraleda
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

2010-12-30 Thread Jorge Moraleda
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

2010-12-29 Thread Jorge Moraleda
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 )

2010-12-29 Thread Jorge Moraleda
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

2010-06-12 Thread Jorge Moraleda
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

2009-10-06 Thread Jorge Moraleda
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