On 06/25/2012 02:39 AM, John Clizbe wrote:
> The mutex region grows from ~7MB to ~12MB. BDB sets an initial mutex count of
> 57435. It when then grow the mutex pool as it needs more. mutex_set_max is
> just an upper bound on that growth.
So the main concern is just allocation of a few more MiB of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi John,
On 06/24/12 23:54, John Clizbe wrote:
> db_recover -h DB
It says:
atlanta# db4.6_recover -h DB
db4.6_recover: Unacceptable log file DB/log.002109: unsupported
log version 19
db4.6_recover: Invalid log file: log.002109: Invalid argum
David Benfell wrote:
> On 06/24/12 23:08, David Benfell wrote:
>> On 06/24/12 23:01, John Clizbe wrote:
>>> set_lk_detect DB_LOCK_DEFAULT
>
>> I don't seem to have a file by the name DB_CONFIG
>
> I found DB_CONFIG in the sample configuration in the build directory
> and copied it to /e
Daniel Kahn Gillmor wrote:
> On 06/25/2012 02:16 AM, John Clizbe wrote:
>> After Christoph's last email re mutex_set_max I checked my own databases,
>> both
>> of which were set to 64K. PTree was almost equally split between in-use and
>> free. KDB was very close to running out with only about 3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/24/12 23:08, David Benfell wrote:
> On 06/24/12 23:01, John Clizbe wrote:
>> set_lk_detect DB_LOCK_DEFAULT
>
> I don't seem to have a file by the name DB_CONFIG
>
I found DB_CONFIG in the sample configuration in the build directory
an
On 06/25/2012 02:16 AM, John Clizbe wrote:
> After Christoph's last email re mutex_set_max I checked my own databases, both
> of which were set to 64K. PTree was almost equally split between in-use and
> free. KDB was very close to running out with only about 3K left of the 64K.
Would you mind s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1,SHA256
Christoph Egger wrote:
> Hi!
>
> Daniel Kahn Gillmor writes:
>> On 06/25/2012 12:44 AM, Kristian Fiskerstrand wrote:
>>> Please let me know if we should push the timeline some for the 1.1.2
>>> minimum to get more time for testing, as origina
Hi!
Daniel Kahn Gillmor writes:
> On 06/25/2012 01:50 AM, Christoph Egger wrote:
>> Daniel Kahn Gillmor writes:
>>> On 06/25/2012 12:44 AM, Kristian Fiskerstrand wrote:
Please let me know if we should push the timeline some for the 1.1.2
minimum to get more time for testing, as origin
Hi Christoph--
On 06/25/2012 01:50 AM, Christoph Egger wrote:
> Daniel Kahn Gillmor writes:
>> On 06/25/2012 12:44 AM, Kristian Fiskerstrand wrote:
>>> Please let me know if we should push the timeline some for the 1.1.2
>>> minimum to get more time for testing, as originally stated my primary g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/24/12 23:01, John Clizbe wrote:
> set_lk_detect DB_LOCK_DEFAULT
I don't seem to have a file by the name DB_CONFIG
drwx-- 2 sks sks 52224 Jun 24 23:02 .
drwxr-xr-x 5 sks sks1024 Jun 24 22:46 ..
- -rw--- 1 root r
David Benfell wrote:
> On 06/24/12 22:40, David Benfell wrote:
>> However, attempting to start produces the following:
>
>> DB_ENV->set_lk_detect: unknown deadlock detection mode specified
>> zsh: segmentation fault /usr/local/bin/sks cleandb
Check DB_CONFIG in the KDB/DB directory for typos
Hi!
Daniel Kahn Gillmor writes:
> On 06/25/2012 12:44 AM, Kristian Fiskerstrand wrote:
>> Please let me know if we should push the timeline some for the 1.1.2 minimum
>> to get more time for testing, as originally stated my primary goal is
>> getting to 1.1.3, so this shouldn't necessarily affe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/24/12 22:40, David Benfell wrote:
> However, attempting to start produces the following:
>
> DB_ENV->set_lk_detect: unknown deadlock detection mode specified
> zsh: segmentation fault /usr/local/bin/sks cleandb
>
It turns out that it's the sa
On 06/25/2012 12:44 AM, Kristian Fiskerstrand wrote:
> Please let me know if we should push the timeline some for the 1.1.2 minimum
> to get more time for testing, as originally stated my primary goal is getting
> to 1.1.3, so this shouldn't necessarily affect too much, we can still keep
> that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I've been digging into the Arch Linux situation further. It appears
the AUR package has been orphaned.
I mentioned separately that I had attempted to tweak the Arch User
Repository package and encountered an error with the libisl version.
It was
Sent from my iPad
On Jun 25, 2012, at 5:38 AM, Daniel Kahn Gillmor wrote:
> On 06/24/2012 03:20 PM, Kristian Fiskerstrand wrote:
>> As of *7. July 2012* I intend to change the minimum version for
>> qualification in the pool to 1.1.2, which would currently mean that
>> the number of servers in
On 06/24/2012 03:20 PM, Kristian Fiskerstrand wrote:
> As of *7. July 2012* I intend to change the minimum version for
> qualification in the pool to 1.1.2, which would currently mean that
> the number of servers in the pool will be 33 (although I expect more
> servers to be upgrade by this time, o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/24/12 17:35, Kristian Fiskerstrand wrote:
>
> This seems to be an Arch bug, see [0]
>
> [0] https://bugs.archlinux.org/task/30367
>
Oops. I also notice I have cryptokit 1.5 installed. The last mention I
recall of that was right before our, ah
Kristian,
Would it be a good idea to contact the operators of keyservers running
versions prior to v1.1.3 and let them know about this coming change and
perhaps get them to upgrade? I'm guessing a great number of the
keyserver operators are not on the sks-devel list.
I'm willing to work through
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2012-06-25 01:28, David Benfell wrote:
> On 06/24/12 12:20, Kristian Fiskerstrand wrote:
>
>> On the way to this goal, grandfathering 1.1.2 seems to be
>> necessary to maintain a higher number in the pool.
>
>
>
...
>
> I did take a quick l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/24/12 12:20, Kristian Fiskerstrand wrote:
>
> On the way to this goal, grandfathering 1.1.2 seems to be necessary
> to maintain a higher number in the pool.
>
> As of *7. July 2012* I intend to change the minimum version for
> qualification
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
In order to have the full pool being able to handle searching subkeys
using the Long KeyID, which is available in SKS 1.1.3, I intend on
making some changes to the minimum required SKS version of the servers
to be included in the main Pool.
- F
22 matches
Mail list logo
