Hi,
Am 02.03.2018 um 06:33 schrieb Tiago Daitx:
> Hi,
>
> A simple relocation in jtb fixed the FTBFS - tested for surefire,
> javacc-maven-plugin, hawtbuf, avro-java, and activemq-protobuf.
Thank you very much for the investigation. I can NMU the package if
Ludovico is currently to busy.
Regard
Hi,
A simple relocation in jtb fixed the FTBFS - tested for surefire,
javacc-maven-plugin, hawtbuf, avro-java, and activemq-protobuf.
Regards,
Tiago
On Thu, Mar 1, 2018 at 9:48 PM, Tiago Daitx wrote:
> Hi,
>
> I tracked down this error to a change in jtb's pom.xml that changed
> jtb's groupId.
Hi,
I tracked down this error to a change in jtb's pom.xml that changed
jtb's groupId.
A commit [1] moved from using debian/pom.xml to using upstream's
pom.xml (introduced by [2]), but the problem is that groupId changed
from "edu.ucla.cs.compilers" (original pom.xml [3]) to "edu.purdue.cs"
(new
Hi tony,
Am 28.01.2018 um 17:57 schrieb tony mancill:
> Hi Debian Java,
>
> I'm working on a package that depends on javacc via the
> javacc-maven-plugin. The toolchain is broken at runtime and there is
> also a FTBFS bug for javacc-maven-plugin [0], both of which appear
> related to the the upl
Hi all,
ok, I didn't intent to update javacc in unstable to 6.x before stretch
either way, but creating a javacc6 remove the pressure from the
transition. With a javacc6 package we can bring the packages to javacc6
one by one without holding up the javacc6 upload and hopefully, the
workload for up
Le 14/12/2016 à 20:03, Benjamin Mesing a écrit :
> Any further thoughts?
Thank you for checking the reverse dependencies. The update looks rather
disruptive and we are no longer supposed to do transitions at this
point. Maybe a safer solution would be to upload a new javacc6 package
now, and late
Hi all,
> > * update javacc to 6 and create a javacc5 package, patching all
> > the
> > packages which do not compile with 6.1.3 (requires a team
> > effort)
>
> +1 for this solution. I can help switching the broken packages back
> to
> javacc5.
So be it. This is probably a task, that will
Le 11/12/2016 à 15:45, Benjamin Mesing a écrit :
> I now see several options:
>
> * update javacc to 6 and create a javacc5 package, patching all the
> packages which do not compile with 6.1.3 (requires a team effort)
+1 for this solution. I can help switching the broken packages back to
j
Hi,
I have prepared a javacc 6.1.3 package and recompiled some of its
dependencies.
So far three packages fail to compile (there are probably more):
* css-parser
* lucene-solr
* lucene2
All three packages are a couple of years behind the latest upstream
version.
Is there an easy way to autobui
Hi Benjamin,
Le 7/12/2016 à 17:46, Benjamin Mesing a écrit :
> Do you plan on updating javacc anytime soon?
> If not, do you see any obvious reasons, why an update might not be
> recommended (like any breaking changes in 6.x).
I didn't plan to upgrade javacc before the release of Stretch. I don'
Hello Paul,
On Sun, Nov 11, 2007 at 10:08:13PM +, Paul Cager wrote:
> I would say it's not _entirely_ the library developers' fault. JavaCC
> has always had a rather inconsistent use of Exceptions - ParseException
> (thrown for syntactic errors) extends Exception, but TokenMgrError
> (thrown
Michael Koch wrote:
> Hello,
> On Mon, Nov 05, 2007 at 10:49:29AM +0900, Sanghyeon Seo wrote:
>> In the original modifed file, ParseException extends CSSException
>> which extends RuntimeException, so it is an unchecked exception. But
>> unmodifed ParseException extends Exception by default, which
Hello,
On Mon, Nov 05, 2007 at 10:49:29AM +0900, Sanghyeon Seo wrote:
> Upstream modified ParseException.java after it was generated. Even the
> generated file says you can! ("You can modify this class to customize
> your error reporting...")
>
> In the original modifed file, ParseException exte
2007/11/5, Rene Engelhard <[EMAIL PROTECTED]>:
> When removing the generated files, re-building the parser and trying the
> build it fails, though (not at the &6 ;) ) when trying to build the
> stuff:
>
> http://zyklop.dyndns.org/~rene/flute-1.3-jfree_20061107-2_amd64.build
> http://zyklop.dyndns.o
Arnaud wrote:
> Sun does respond to your question before you ask! ;)
>
> http://javacc.dev.java.net/
>
> Summary: JavaCC is a parser/scanner generator for java
> Categories: None
> License: Berkeley Software Distribution (BSD) License
OK, thanks, but the "usage.html" file, provided with the 3.0
Arnaud wrote:
> Sun does respond to your question before you ask! ;)
>
> http://javacc.dev.java.net/
>
> Summary: JavaCC is a parser/scanner generator for java
> Categories: None
> License: Berkeley Software Distribution (BSD) License
OK, thanks, but the "usage.html" file, provided with the 3.0
Nicolas,
Sun does respond to your question before you ask! ;)
http://javacc.dev.java.net/
Summary: JavaCC is a parser/scanner generator for java
Categories: None
License: Berkeley Software Distribution (BSD) License
Owner(s): sreeni
-- Arnaud Vandyck
http://alioth.debian.org/users/arnaud-gue
Nicolas Sabouret <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm (still) trying to package GL4Java. After a few time inactivity, I
> looked deeper at the problem and it appears that part of the build
> process requires javacc:
> http://www.experimentalstuff.com/Technologies/JavaCC/
>
> Could any
Nicolas,
Sun does respond to your question before you ask! ;)
http://javacc.dev.java.net/
Summary: JavaCC is a parser/scanner generator for java
Categories: None
License: Berkeley Software Distribution (BSD) License
Owner(s): sreeni
-- Arnaud Vandyck
http://alioth.debian.org/users/arnaud-gue
Nicolas Sabouret <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm (still) trying to package GL4Java. After a few time inactivity, I
> looked deeper at the problem and it appears that part of the build
> process requires javacc:
> http://www.experimentalstuff.com/Technologies/JavaCC/
>
> Could any
20 matches
Mail list logo
