Sounds good :
o built from source
o checked the installer for MAcOSX from dist
o checked the signatures
o checked the N&L files
+1
Thanks Stefan !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
pEpkey.asc
Description: application/pgp-keys
Hi Emmanuel,
On 9/11/18 3:05 PM, Emmanuel Lécharny wrote:
> while checking the release, I tried to build the MacOS package with mvn
> -Pmacos install, but it ends with an error :
>
> error: The specified item could not be found in the keychain.
> [ERROR] Command execution failed.
> org.apache.com
> On Sep 11, 2018, at 12:43 PM, Emmanuel Lécharny wrote:
>
>>>
>>> On Sep 11, 2018, at 5:43 AM, Emmanuel Lécharny wrote:
>>> , and on MacOSC, tomcat is not
>>> excatly installed as described
>>> (/usr/local/tomcat8/apache-tomcat-8.0.30/... instead of
>>> /usr/local/tomcat8/... as specified in
> On Sep 11, 2018, at 12:24 PM, Lothar Haeger
> wrote:
>
> Shawn McKinney wrote:
>
>> mv apache-tomcat-8.0.30 /usr/local/tomcat8
>>
>> Not sure why on a Mac (in Bash) the mv command appends distro name to the
>> path and not in Linux.
>
> BSD (Mac) vs. GNU (Linux) seem to differ in behavior
>>
>> On Sep 11, 2018, at 5:43 AM, Emmanuel Lécharny wrote:
>>
>> - I had a bit of hard time checking the code against ApacheDS, because
>> the INSTALL-xxx files are a bit outdated (typically, the number of
>> successful tests is not what I get)
>
> What we’ll do here is remove the literal number
Shawn McKinney wrote:
> mv apache-tomcat-8.0.30 /usr/local/tomcat8
>
> Not sure why on a Mac (in Bash) the mv command appends distro name to the
> path and not in Linux.
BSD (Mac) vs. GNU (Linux) seem to differ in behavior when the second parameter
is a directory that already exists:
BSD mv:
N
> On Sep 11, 2018, at 5:43 AM, Emmanuel Lécharny wrote:
>
> A few remarks :
>
> - signatures on dist should not supply a SHA1 signature (neither a MD5),
> SHA256 or/and SHA512 should be provided bseside a .asc file. You can
> easily add the sha256/512 signatures to the existing dist directory
We need your help to make the Apache Washington DC Roadshow on Dec 4th a
success.
What do we need most? Speakers!
We're bringing a unique DC flavor to this event by mixing Open Source
Software with talks about Apache projects as well as OSS CyberSecurity,
OSS in Government and and OSS Career
Hi Stefan,
while checking the release, I tried to build the MacOS package with mvn
-Pmacos install, but it ends with an error :
error: The specified item could not be found in the keychain.
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error:
1
On Tue, Sep 11, 2018 at 3:49 PM, Emmanuel Lécharny
wrote:
>
>
> Le 11/09/2018 à 11:53, Kiran Ayyagari a écrit :
> > I propose to convert the classes PartitionReadTxn and PartitionWriteTxn
> > to interfaces so that new Txn implementations need not be restricted to
> > Java inheritance's single par
Pavel Zlámal created DIRAPI-320:
---
Summary: ClassCastException on Objects.equals(Value,Value) for
userPassword attribute
Key: DIRAPI-320
URL: https://issues.apache.org/jira/browse/DIRAPI-320
Project: Dir
Also forgot to mention that at some point a Read transaction may need to
be 'committed' : typically, in Mavibot, it releases the revision in use,
allowing the page collector to reclaim the associated pages.
Le 11/09/2018 à 11:53, Kiran Ayyagari a écrit :
> I propose to convert the classes Partiti
My +1.
o Built from sources and dist
o Checked the signatures
o Checked the N&L files
o Checked against ApacheDS
A few remarks :
- signatures on dist should not supply a SHA1 signature (neither a MD5),
SHA256 or/and SHA512 should be provided bseside a .asc file. You can
easily add the sha256/51
Le 11/09/2018 à 11:53, Kiran Ayyagari a écrit :
> I propose to convert the classes PartitionReadTxn and PartitionWriteTxn
> to interfaces so that new Txn implementations need not be restricted to
> Java inheritance's single parent restriction.
>
> These classes currently do not hold any logic so
I propose to convert the classes PartitionReadTxn and PartitionWriteTxn
to interfaces so that new Txn implementations need not be restricted to
Java inheritance's single parent restriction.
These classes currently do not hold any logic so making such a change will
not
break the existing code in th
15 matches
Mail list logo