ggregory2004/03/29 00:10:14
Modified:codecproject.xml
Log:
Mark current version as 1.3-dev.
Revision ChangesPath
1.30 +1 -1 jakarta-commons/codec/project.xml
Index: project.xml
===
RCS
Eric Pugh wrote on Monday, March 29, 2004 10:57 AM:
Ok,
I just went back and reread the posts.. Basically what you
want is to refactor the HierarchicalDOM4JConfiguration into
AbstractHierarchicalConfiguration and then have
HierarchicalDOM4JConfiguration and HierarchicalDOMConfiguration.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28002.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 26 Mar 2004, at 17:28, Rob Oxspring wrote:
Moving to list for general info and to get any feedback from John.
Thanks for checking. Regarding v2 (all IMHO):
2.0 release plan?
Several times now we've said in a month or in a couple of months.
Personally I think I'm out of new features for now
I just looked at the patch :
--- PropertiesConfiguration.java28 Mar 2004 14:43:04 - 1.5
+++ PropertiesConfiguration.java28 Mar 2004 15:34:23 - 1.6
@@ -99,7 +99,9 @@
public void load(String fileName) throws ConfigurationException
{
try {
-
Jörg,
I think wat you have proposed is a good compromise.. We'll leave
configurationfactory alone so as not to create a dependency on the apis for
jdk1.3, and if you can get me that patch, I'll do it all tomarrow morning.
then, as part of 1.1, doing the refactoring on ConfigurationFactory will
Eric Pugh wrote on Monday, March 29, 2004 12:58 PM:
Jörg,
I think wat you have proposed is a good compromise.. We'll
leave configurationfactory alone so as not to create a
dependency on the apis for jdk1.3, and if you can get me that
patch, I'll do it all tomarrow morning.
Fine, sounds
roxspring2004/03/29 02:42:20
jakarta-commons/cli/src/test/org/apache/commons/cli2/help - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
roxspring2004/03/29 02:43:22
jakarta-commons/cli/src/java/org/apache/commons/cli2/help - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
John Keyes wrote:
On 26 Mar 2004, at 17:28, Rob Oxspring wrote:
Moving to list for general info and to get any feedback from John.
Thanks for checking. Regarding v2 (all IMHO):
2.0 release plan?
Several times now we've said in a month or in a couple of months.
Personally I think I'm out of
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27870.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I think Digester.parse(java.io.File) should do it for me, or?
(this method does build an input-source with correct URL, btw)
There's even, in the maven code, efforts towards making this an
absolute path.
But the problem remains: if you look at the code of Digester.java,
there's nothing that
Can someone please explain the difference between the
ListOrderedMap and the LinkedMap? I mean: they basically
provide the same functionality, right?
cheers
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
We can do that.. Just need to trap and throw the resulting IOException as a
ConfigurationException then...
Eric
-Original Message-
From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
Sent: Monday, March 29, 2004 10:34 AM
To: Jakarta Commons Developers List
Subject: Re: [configuration]
I think you may be referring to something said by a user last week, in which
he solved the problem by configuring his NT FTP server to use the Unix
display format. I didn't know before that that was an option. What I still
don't know is if one takes that option, does the SYST command return
Eric Pugh wrote:
We can do that.. Just need to trap and throw the resulting IOException as a
ConfigurationException then...
I wouldn't throw an exception if close() fails, it doesn't prevent using
the configuration since we have finished reading the stream at this
point. A warning or a stack
I've been looking at how to resolve the jdepend test failure without
taking the ignoring approach (up the threshold to 0.3). I went in
search of a way to package things better and after thinking it through I
came up with the following proposed renamings:
1) o.a.c.c.HelpFormatter -
Steve Cohen wrote:
It is an
attempt to raise the default success rate of using listFiles() out of the box
from maybe 90% to 98%, by autodetecting other cases,
...
I don't think we'll ever hit 100%. FTP is too
loosely specced for that to happen.
I am complete with you. And i know, that it
I don't know what the proper way to report a bug but I found the
SplineInterpolator useful for my needs... except that it didn't work (which
was likely for version 0.14)
Here is my fix:
Replace
double dquot = (yval[1] - yval[0]) / (xval[1] - xval[0]);
for (int i = 0;
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sorry to get into this one late. Had too though since I'm one of those
directory folks :-).
I'm finally finding that I can get svn installed on suse and os x [it's
not without issue] and am looking forward to
OH I had a look at your ideas and now I have a few questions and remarks.
Great!
OH At first let me say that I like the idea of using a graph representation
[...]
I definitely agree. Things get a lot easier that way. Besides, we
could even support a special debug mode, where we plug in a graph
ListOrderedMap cannot be instantiated directly. Per the Javadocs, it's a
decorator, not a Map implementation. You get an instance of
ListOrderedMap by passing an existing Map to
ListOrderedMap.decorate(Map).
LinkedMap, however, can be instantiated directly and has similar
constructors to
Okay, I am thinking of this then:
public void load(String fileName) throws ConfigurationException
{
InputStream is=null;
try {
is = getPropertyStream(fileName);
load(is);
}
catch (IOException ioe){
throw new
Thank you Joel,
It would be good to submit these into bigzilla, you can attach your
changes either as unified diff patches or as java file attachments.
Follow the directions here:
http://jakarta.apache.org/commons/math/developers.html
Cheers,
Mark
On Mon, 2004-03-29 at 09:23, [EMAIL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28019.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28002.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hello folks,
today I've build a SNAPSHOT version of configurations and with the new subsets I got a
failed unit test in my own application. I've boiled it down to something in
commons-configuration that worked before the subset refactoring:
/**
* Tests subsets and still can resolve
ggregory2004/03/29 09:10:36
Modified:lang project.xml
Log:
Turn on Clover.
Revision ChangesPath
1.32 +1 -1 jakarta-commons/lang/project.xml
Index: project.xml
===
RCS file:
ggregory2004/03/29 09:14:10
Modified:codecproject.xml
Log:
Add but comment out FindBugs report.
Revision ChangesPath
1.31 +1 -0 jakarta-commons/codec/project.xml
Index: project.xml
===
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28026.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28026.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
-Original Message-
--- Martin Cooper [EMAIL PROTECTED] wrote:
On Mon, 29 Mar 2004, Niall Pemberton wrote:
I think its the ExceptionTest which is failing and it looks like it
should
from the code. There are three tests in ExceptionTest - only one has
code to
pass the
Paul Libbrecht wrote:
I think Digester.parse(java.io.File) should do it for me, or?
(this method does build an input-source with correct URL, btw)
There's even, in the maven code, efforts towards making this an
absolute path.
In theory it should ... but if it doesn't, you can easily construct a
Here on a Windows2003 server toggling the DIRSTYLE doesn't change the
output of the SYS command. It still reports Windows NT 5.0, so if the
MSDOS dirstyle is off, then the wrong parser will get autoselected. I
guess we could put this in the FAQ or something with some examples
maybe.
On Mon,
On Mon, 29 Mar 2004, [EMAIL PROTECTED] wrote:
-Original Message-
--- Martin Cooper [EMAIL PROTECTED] wrote:
On Mon, 29 Mar 2004, Niall Pemberton wrote:
I think its the ExceptionTest which is failing and it looks like it
should
from the code. There are three tests in
On Mon, 29 Mar 2004, Niall Pemberton wrote:
OK, I was wrong - but then its difficult to to debug with the wrong stack
trace ;-)
Sorry. ;-) I keep forgetting that the console output from Maven for unit
tests is basically useless, and you need to look at the report files to
see what really
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
I have a bit of trouble with supposed to fail. Perhaps currently
expected to fail? ;-)
In any case, I'm not comfortable with rolling a release where 'maven clean
dist' fails right out of the box. Can we disable the
On Mon, 29 Mar 2004, [EMAIL PROTECTED] wrote:
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
I have a bit of trouble with supposed to fail. Perhaps currently
expected to fail? ;-)
In any case, I'm not comfortable with rolling a release where 'maven clean
--- Martin Cooper [EMAIL PROTECTED] wrote:
On Mon, 29 Mar 2004, [EMAIL PROTECTED] wrote:
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
I have a bit of trouble with supposed to fail. Perhaps currently
expected to fail? ;-)
In any case, I'm not
Hi,
A clean dist on validator with Maven 1.0 rc1 doesn't work for me either:
it compiles fine (1 warning), but there's a test failure:
[junit] Running org.apache.commons.validator.EmailTest
[junit] Tests run: 8, Failures: 2, Errors: 0, Time elapsed: 1.008 sec
[junit] [ERROR] TEST
On Mon, 29 Mar 2004, David Graham wrote:
--- Martin Cooper [EMAIL PROTECTED] wrote:
On Mon, 29 Mar 2004, [EMAIL PROTECTED] wrote:
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
I have a bit of trouble with supposed to fail. Perhaps currently
Hi,
I plan to try to add a status callback to the FileUpload package. Here
is the scenario I would like to support (I'm making this up as I go, but
something like this):
1) User uploads a large file (form target is an invisible IFRAME so that
the browser does not leave the form page on
See:
http://issues.apache.org/bugzilla/show_bug.cgi?id=25830
--
Martin Cooper
On Mon, 29 Mar 2004, Karl Goldstein wrote:
Hi,
I plan to try to add a status callback to the FileUpload package. Here
is the scenario I would like to support (I'm making this up as I go, but
something like
On 29 Mar 2004, at 18:52, Craig McClanahan wrote:
Paul Libbrecht wrote:
I think Digester.parse(java.io.File) should do it for me, or?
(this method does build an input-source with correct URL, btw)
There's even, in the maven code, efforts towards making this an
absolute path.
In theory it should
Karl,
There is some stuff in bugzilla regarding Upload Progress Reporting
which supports a component I wrote to work with Turbine.
I think I left some unneeded synchronization in, which was kindly
pointed out by someone and there was also a useful additional method
suggested, from memory it was
On 29 Mar 2004, at 20:52, robert burrell donkin wrote:
On 29 Mar 2004, at 18:52, Craig McClanahan wrote:
Paul Libbrecht wrote:
I think Digester.parse(java.io.File) should do it for me, or?
(this method does build an input-source with correct URL, btw)
There's even, in the maven code, efforts
I think you are right.. I update scarab (scarab.tigris.org) to use the
latest, and am having subset issues there as well...
Argh..
Eric
-Original Message-
From: Jörg Schaible [mailto:[EMAIL PROTECTED]
Sent: Monday, March 29, 2004 5:56 PM
To: Jakarta Commons Developers List
Subject:
rdonkin 2004/03/29 12:34:54
Modified:digester/src/java/org/apache/commons/digester Digester.java
Log:
Just some reformating
Revision ChangesPath
1.98 +8 -8
jakarta-commons/digester/src/java/org/apache/commons/digester/Digester.java
Index: Digester.java
I've been looking at how to resolve the jdepend test failure without
taking the ignoring approach (up the threshold to 0.3). I went in
search of a way to package things better and after thinking it through
I came up with the following proposed renamings:
1) o.a.c.c.HelpFormatter -
rdonkin 2004/03/29 12:50:07
Added: betwixt/src/test/org/apache/commons/betwixt Tag:
REFACTORING-BRANCH_2004-01-13 IdMap.java
Log:
Fix for bug in map adder type conversion. Patch contributed by Brian Pugh.
Revision ChangesPath
No
rdonkin 2004/03/29 12:50:21
Modified:betwixt/src/java/org/apache/commons/betwixt/expression Tag:
REFACTORING-BRANCH_2004-01-13 MapEntryAdder.java
betwixt/src/test/org/apache/commons/betwixt Tag:
REFACTORING-BRANCH_2004-01-13
John Keyes wrote:
I've been looking at how to resolve the jdepend test failure without
taking the ignoring approach (up the threshold to 0.3). I went in
search of a way to package things better and after thinking it through
I came up with the following proposed renamings:
1)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28033.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28033.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
roxspring2004/03/29 14:52:30
Modified:cli/src/test/org/apache/commons/cli2/commandline Tag:
RESEARCH_CLI_2_ROXSPRING
PropertiesCommandLineTest.java
Log:
Added apache licence
Revision ChangesPath
No
roxspring2004/03/29 14:52:54
Added: cli/src/java/org/apache/commons/cli2/commandline Tag:
RESEARCH_CLI_2_ROXSPRING
PreferencesCommandLine.java
cli/src/test/org/apache/commons/cli2/commandline Tag:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28033.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
brekke 2004/03/29 20:16:29
Modified:net project.xml
Added: net/xdocs index.xml
Log:
Updated the index to formatted a little better.
Revision ChangesPath
1.41 +3 -23 jakarta-commons/net/project.xml
Index: project.xml
On Mon, 29 Mar 2004 00:25:59 -0500, Gary Gregory [EMAIL PROTECTED] said:
WRT http://jakarta.apache.org/commons/net/ Shouldn't the heading
Jakarta Commons/Net probably just be Jakarta Commons Net?
Also that whole paragraph could use some formatting, for example a
bullet list of features.
Looks much better! Now I might be nit picking here but here it goes
anyway.
(1) IMHO, the 1st sentence (This is an Internet protocol suite Java
library originally developed by ORO, Inc.) should be moved to the
Background section. The first sentence should tell you something very
important, this
On Mon, 29 Mar 2004, David Graham wrote:
--- Martin Cooper [EMAIL PROTECTED] wrote:
On Mon, 29 Mar 2004, David Graham wrote:
--- Martin Cooper [EMAIL PROTECTED] wrote:
On Mon, 29 Mar 2004, [EMAIL PROTECTED] wrote:
-Original Message-
From: Martin Cooper
Hi,
I notice that Xalan has implemented a new class:
org.apache.xalan.Version
with a method
static String getVersion()
and also a static main method which prints the version#.
See:
http://xml.apache.org/xalan-j/apidocs/org/apache/xalan/Version.html
The comment associated with this
I think the problem may be in the first line below. I don't think you
want to hash the reference. If you change hash(ref) to ref.hashCode() all
tests (including commented out ones) succeed.
private void purge(Reference ref) {
// The hashCode of the reference is the hashCode of the
Rowan,
See http://gump.apache.org
--- Noel
-Original Message-
From: Rowan Christmas [mailto:[EMAIL PROTECTED]
Sent: Monday, March 29, 2004 19:27
To: [EMAIL PROTECTED]
Subject: Commons Graph Project
Hello,
I have been developing a new Graphing library ( the nodes and edges
Noel J. Bergman wrote:
FYI: http://java.sun.com/j2se/1.5.0/jcp/beta1/apidiffs/java/util/UUID.html
Seems to me that it would make sense to have code in our library that
provides a compatible interface.
Noel,
I agree with you, and I don't see anything that would be difficult for us
to provide
This class implements the upcoming standard of having
org.apache.project-name.Version.getVersion() be a standard way to get
version information.
That's news to me. I suspect it is news to most. As far as I know, it may
be someone's strawman and/or wishful thinking, but this is the first I have
martinc 2004/03/29 22:18:06
Modified:validator build.xml project.xml
Log:
Update version for 1.1.2 release.
Revision ChangesPath
1.32 +2 -2 jakarta-commons/validator/build.xml
Index: build.xml
A number of bug fixes and other changes have been made since the Commons
Validator 1.1.1 release. It is time to make these changes available as
part of an official release.
Therefore I propose to release CVS HEAD as a 1.1.2 release of Commons
Validator.
I have created a release candidate, which
martinc 2004/03/29 22:22:54
Modified:validator build.xml project.xml
Log:
Update version for 1.1.3-dev.
Revision ChangesPath
1.33 +2 -2 jakarta-commons/validator/build.xml
Index: build.xml
The problem HierarchicalConfiguration and related stuff had with
SubsetConfiguration has to do with code in the ConfigurationXMLDocument
class that tries to determine a correct ConfigurationXMLReader
implementation for a passed in Configuration object. This code tests if
the Configuration
Noel J. Bergman wrote:
This class implements the upcoming standard of having
org.apache.project-name.Version.getVersion() be a standard way to get
version information.
That's news to me. I suspect it is news to most. As far as I know, it may
be someone's strawman and/or wishful thinking, but
---
Vote: Commons Validator 1.1.2 Release
[X] +1 I am in favor of the release, and will help support it
[ ] +0 I am in favor of the release, but am unable to help support it
[ ] -0 I am not in favor of the release
[ ] -1 I am
Noel J. Bergman wrote:
FYI:
http://java.sun.com/j2se/1.5.0/jcp/beta1/apidiffs/java/util/UUID.html
Seems to me that it would make sense to have code in our library that
provides a compatible interface.
Phil Steitz wrote:
Noel,
I agree with you, and I don't see anything that would be
On Tue, 2004-03-30 at 18:33, Craig McClanahan wrote:
Noel J. Bergman wrote:
This class implements the upcoming standard of having
org.apache.project-name.Version.getVersion() be a standard way to get
version information.
That's news to me. I suspect it is news to most. As far as I know,
Hi,
We had a discussion about author tags a while ago. The general consensus
was that individuals should no longer be listed in these tags [NB: not
an official vote]. I think this is now also apache policy?
Robert Donkin suggested using them to credit the commons team, with
the benefit that a
Oliver Heger wrote on Tuesday, March 30, 2004 8:31 AM:
The problem HierarchicalConfiguration and related stuff had with
SubsetConfiguration has to do with code in the
ConfigurationXMLDocument
class that tries to determine a correct ConfigurationXMLReader
implementation for a passed in
Noel J. Bergman wrote:
This class implements the upcoming standard of having
org.apache.project-name.Version.getVersion() be a standard way to get
version information.
That's news to me. I suspect it is news to most. As far as I know, it may
be someone's strawman and/or wishful thinking, but
I agree that the actual solution is ugly. So what do you suggest?
Almost all features of a HierarchicalConfiguration can be used through
the Configuration interface; there is just an enhanced syntax for
property keys passed in the getter methods.
The exception is XML handling.
On Thu, 2004-03-25 at 12:01, Simon Kitching wrote:
On Thu, 2004-03-25 at 04:36, Edelson, Justin wrote:
Since coding these changes, I've rethought whether or not this needs to
be a subclass - since @text() can't be a legal XML element, existing
code shouldn't be affected. After starting to
Oliver Heger wrote on Tuesday, March 30, 2004 9:24 AM:
I agree that the actual solution is ugly. So what do you suggest?
Almost all features of a HierarchicalConfiguration can be
used through
the Configuration interface; there is just an enhanced syntax for
property keys passed in the
On Tue, 2004-03-30 at 18:11, matthew.hawthorne wrote:
Isn't this sort of thing supposed to be handled by manifest files? I
might be oversimplifying.
The initial problem that Xalan faced was people reporting bugs in xalan
when they weren't actually running the version they thought they were,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27589.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
The vote has passed. We will put forth the proposal below to the Jakarta
PMC to move HttpClient to a Jakarta level project. The vote details are
below:
+1 votes -
Adrian Sutton [EMAIL PROTECTED]
Oleg Kalnichevski [EMAIL PROTECTED]
Michael Becke [EMAIL PROTECTED]
dIon Gillard
Yes, unfortunately the nightly builds are from HEAD. I'm not sure if
we can create both 2.0 and HEAD nightly builds. Anyone know more about
this?
Mike
On Mar 29, 2004, at 4:27 AM, [EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB
Mike,
I believe the only way to find this out is to approach the
infrastructure folks ([EMAIL PROTECTED])
Oleg
On Mon, 2004-03-29 at 15:30, Michael Becke wrote:
Yes, unfortunately the nightly builds are from HEAD. I'm not sure if
we can create both 2.0 and HEAD nightly builds. Anyone know
On 29/3/04 8:47 PM, Adrian Sutton [EMAIL PROTECTED] wrote:
The vote has passed. We will put forth the proposal below to the Jakarta
PMC to move HttpClient to a Jakarta level project. The vote details are
below:
I also want to note that I've received replies from Rodney Waldhoff and
Sung-Gu.
Message sent.
Mike
On Mar 29, 2004, at 4:26 PM, Oleg Kalnichevski wrote:
Mike,
I believe the only way to find this out is to approach the
infrastructure folks ([EMAIL PROTECTED])
Oleg
On Mon, 2004-03-29 at 15:30, Michael Becke wrote:
Yes, unfortunately the nightly builds are from HEAD. I'm
87 matches
Mail list logo
