Hi,
> > I vaguely remember that replacing a symlink with a file during a package
> > update was causing some issues (i.e. the target is updated but the symlink
>
> Wasn’t that only for directories?
Seems to work:
$ ls -la /usr/share/java/htmlcleaner*
lrwxrwxrwx 1 root root 15 18 mars 1
Hi,
> >>> Not sure though what is the impact of this policy inversion. Most of
> >>> Java-related software seems to read both regular files and symbolic
> >>> links transparently.
> >>
> >> There isn't much impact, both styles are fine in my opinion.
> >
> > This seems to trigger https://lintian.
Hi,
> > Not sure though what is the impact of this policy inversion. Most of
> > Java-related software seems to read both regular files and symbolic
> > links transparently.
>
> There isn't much impact, both styles are fine in my opinion.
This seems to trigger https://lintian.debian.org/tags/bad
Hi,
> > > Therefore, I can quickly prepare a 5.3 upload.
> > >
> > > Are there any blockers regarding uploading a newer version?
> >
> > Should I prepare an upload? A merge request? Any known blockers?
> >
> > $ apt-cache rdepends libwoodstox-java
> > libwoodstox-java
> > Reverse Depends:
> >
Hi list,
On Thu, Apr 23, 2020 at 10:21 AM Alexandre Rossi wrote:
>
> Package: libwoodstox-java
> Version: 1:5.1.0-2
> Severity: wishlist
>
> Dear Maintainer,
>
> woodstox-core 6.1.1 is available.
>
> upstream of davmail is carrying out a patch and would like at leas
> > unfortunately davmail fails to build from source with
> > libjackrabbit-java 2.18.0. Long deprecated methods have been removed.
> > Your package build-depends on a very old version of jackrabbit (2.4.3).
This is too much work and I'm afraid if I do not get help I'll miss
the 2019-02-12 - Soft-
Hi,
I just noticed that swt4-gtk 4.8 makes davmail fail to build from
source. Are there some release notes pointing to deprecated APIs ?
[javac] /<>/src/java/davmail/ui/tray/SwtGatewayTray.java:201:
error: cannot find symbol
[javac] OS.gdk_error_trap_push();
[javac]
Hi,
I'm not familiar with perl but the rewrite[1] of jh_exec reads "chmod
-x" while the tool is expected to make some jars executable. My
debhelper log shows "chmod -x" while I would expect "chmod +x".
[1]
https://salsa.debian.org/java-team/javatools/commit/4d3e2123f5e747014a0d060416f7f3283e6c31
Hi,
I have two ways of fixing #909040 [1] : either I build against an
older jdk or I use a wrapper script ensuring at least java9.
[1] https://bugs.debian.org/909040
What should I do? What is the policy?
Thanks,
Alex
Hi,
> At http://mentors.debian.net/debian/pool/main/d/davmail/
> there is a davmail_4.2.1.orig.tar.gz and a
> davmail_4.2.1-1~3.gbp244580.debian.tar.gz
>
> Upstream has davmail-srconly-4.2.1-2089.tgz
> and `uscan` makes davmail_4.2.1-2089.orig.tar.gz
>
> I will be spending time to see if I can co
Hi,
> In general the issue appears to be that there's no orig.tar.gz file and
> not documentation about how to create one. Alexandre, on May 10th you
> posted to the bug report that you uploaded the packages (presumably one
> of which was libhtmlcleaner-java) to mentors.debian.net, but I'm not
>
Hi,
> i used the packaging work of Alex and updated the packaging [1] to the
> newest version (davmail 4.2.1).
Thanks!
> As the Wheezy release will still take some little time what about
> uploading davmail (and the dependency libhtmlcleaner-java) to
> experimental?
unstable would be just fine
Hi,
Just a quick update on this ITP.
I packaged the latest upstream.
http://sousmonlit.incube.tk/~niol/apt/pool/main/d/davmail/davmail_4.1.0-2042-1~pre+1.dsc
(no change for htmlcleaner :
http://sousmonlit.incube.tk/~niol/apt/pool/main/libh/libhtmlcleaner-java/libhtmlcleaner-java_2.2-1~pre+1.dsc
Hi,
> I see that libjackrabbit-java is now in Debian. How are you getting on
> with libhtmlcleaner-java and, more pertinently davmail packaging?
I have a working package using Debian libraries instead of embedded ones :
-
http://sousmonlit.dyndns.org/~niol/apt/pool/main/libh/libhtmlcleaner-java/
Hi,
> I've already seen this library, but it is not a compatible API.
> I gonna ask to biojava team if they would go to using such library
> instead of org.json one...
For what it's worth, from the work I've begun doing on GWT, which had
the same problem among others, I settled using json-simple
> I didn't see any issue in GWT's issue tracker about our problems with
> crockford's library. Could you open an issue there? Maybe we could get
> upstream do to anything in this regard.
> There are also other issues for the keyword "json" and it seems that somebody
> is working in this area.
I ad
>> - liborgjson-java (json library from http://json.org/java )
>
> please be careful: this is considered non-free code because of the 'evil
> clause'. There is some older version which is free but I do not remember
> the details atm.
http://lists.debian.org/debian-legal/2010/03/msg00065.html
Than
Hi all,
A little status update. I have gwt-dev.jar, gwt-user.jar building with
external dependencies. It does not work : I cannot compile my GWT
application. From the error message, I think my naive patch to port to
jdt 3.5+ is not good, so this will need more work.
I'd like to setup repositories
> I would probably not use "org.eclipse.jdt.core_3.5.2.v_981_R35x.jar",
> since the last part of a version in eclipse jars has been known to be
> volatile.
Done.
> Consider a wildcard like "org.eclipse.jdt.core_3.5.2.*.jar" and please
> check it works with eclipse 3.7 (in experimental).
It buil
Hi all,
I'll now share my work at the following URL:
http://sousmonlit.dyndns.org/~niol/gitweb/?p=gwt-debian.git/.git;a=summary
This also should work :
$ git clone
http://sousmonlit.dyndns.org/~niol/repositories.git/gwt-debian.git/.git
(git is easier to work with without commit access, I'll con
Dear all,
Please find attached a patch against the current packaging svn
svn://svn.debian.org/pkg-eucalyptus/gwt/trunk .
It make it possible to build gwt-dev.jar .
I'll continue working towards building gwt-user.jar (when I get the
chance), but I wanted to share my work in case people were tackl
Hi,
> I'd also need gwt2 to package gerrit.
> Is there an ITP to follow? A GIT repo with your packaging so far? Have you
> documented the missing dependencies somewhere?
>From the Debian bug report[1], works seems to be occurring :
$ svn co svn://svn.debian.org/pkg-eucalyptus/gwt/trunk
[1] http:
Hi,
> my package (and certainly others) uses GWT 2.
> This version is not packaged in Debian, and maintainers did not answered
> my requests to know if it was planned (via mail and bug request).
Same here.
> GWT is quite huge and seems really a pain to packagedue to dependencies.
> So I wonder i
23 matches
Mail list logo
