Hi,
On Sat, Oct 06, 2012 at 01:18:04PM +0200, Alex Thurgood wrote:
Le 03/10/2012 10:40, David Tardon a écrit :
Hi David,
These changes wouldn't happen to cause the build to fail in binfilter by
any chance, coz I'm seeing this now in tail_build :
No, for two reasons:
1. it does not touch
Le 07/10/2012 09:55, David Tardon a écrit :
Hi David,
No, for two reasons:
1. it does not touch sax at all
2. it is not in master yet
Ah, ok, thanks for the info.
Well, I did a complete complete git pull, make clean, rebuild and got
through to the end on Linux, will have to check on my
Le 03/10/2012 10:40, David Tardon a écrit :
Hi David,
These changes wouldn't happen to cause the build to fail in binfilter by
any chance, coz I'm seeing this now in tail_build :
autogen switches
--enable-binfilter
--enable-extra-template
Le 06/10/2012 13:18, Alex Thurgood a écrit :
These changes wouldn't happen to cause the build to fail in binfilter by
any chance, coz I'm seeing this now in tail_build :
autogen switches
--enable-binfilter
--enable-extra-template
FWIW, I get the same build failure on Mac OSX 10.8.2 and
On Wed, 2012-10-03 at 10:40 +0200, David Tardon wrote:
It has always bothered me (and other package maintainers too) that we
have to bundle saxon*[2] just because of something that is most probably
never used.
Yep - sounds annoying; it'd be nice to drop the 5Mb of jar file
duplicated
On Wed, 2012-10-03 at 03:58 -0500, Norbert Thiebaud wrote:
Why? if that become truly an extension, it can be on whatever license
no ? so just leave it as LGPL3...
To make it future-proof against wheel of reincarnation if saxon licence
changes again and/or something comes along and we want to
On Thu, 2012-10-04 at 10:14 +0100, Michael Meeks wrote:
And how/who builds and up-loads it is of interest to me; should we have
these extensions built and up-loaded by some automated mechanism in our
release process ? with some account that has widely known credentials -
so there is no
Hi,
On Thu, Oct 04, 2012 at 10:14:00AM +0100, Michael Meeks wrote:
On Wed, 2012-10-03 at 10:40 +0200, David Tardon wrote:
It has always bothered me (and other package maintainers too) that we
have to bundle saxon*[2] just because of something that is most probably
never used.
Hi,
Quoting David Tardon dtar...@redhat.com:
It would be the committer's responsibility to build the extension and
continue maintaining the code (if there is anything to maintain there
:-) I suppose that unfortunate maintainer is going to be me, unless we
decide to put the code in a repo under
On Thu, Oct 4, 2012 at 7:37 AM, d.ostrov...@idaia.de wrote:
Hi,
Quoting David Tardon dtar...@redhat.com:
It would be the committer's responsibility to build the extension and
continue maintaining the code (if there is anything to maintain there
:-) I suppose that unfortunate maintainer is
Hi Norbert,
Quoting Norbert Thiebaud nthieb...@gmail.com:
On Thu, Oct 4, 2012 at 7:37 AM, d.ostrov...@idaia.de wrote:
Hi,
Quoting David Tardon dtar...@redhat.com:
It would be the committer's responsibility to build the extension and
continue maintaining the code (if there is anything to
Hi,
On Thu, Oct 04, 2012 at 03:11:43PM +0200, d.ostrov...@idaia.de wrote:
Of course I welcome volunteers :-)
Another advantage if it is hosted on gerrit: i am going to
contribute to it ;-)
I did not mean 'volunteers' for contributing, but for the maintenance
:-) I personally do not expect any
Hi,
Quoting David Tardon dtar...@redhat.com:
Note that it is possible it will never be needed by anyone. I have
already said I do not know of any existing XSLT filter that uses XSLT
2.0. But there was demand for it back in OO.o times and it was one of
the reasons for switch from xerces to
Hi David,
I found the MS XML 2003 filters to use XSLT 2.0, but only for the way
they referred to extension functions (which is no longer required).
Also, Saxon offers some optimizations for the recursive templates used
in spreadsheetml 2003 (that Xalan doesn't handle well), so that might
Hi all,
we are currently shipping two transformers for XSLT import/export
filters. The default one is libxslt-based (thanks, Peter!) and is used
for all our internal filters. The older saxon-based one only remains as
a backup, in case some existing filter needs features not-supported by
libxslt
On Wed, Oct 3, 2012 at 3:40 AM, David Tardon dtar...@redhat.com wrote:
Hi all,
2. a repo on github or similar
PROS:
* distance from libreoffice. It is not part of our project, so we are not
obliged in any way to ship it :-)
CONS:
* no automatic commit rights (but who would want to commit
16 matches
Mail list logo
