Christopher Berardi | 1 Apr 02:29 2011

Re: sqlite/Heimdal.

On Thu, Mar 31, 2011 at 09:56:00AM +0100, Roland C. Dowdeswell wrote:
> I am in the process of upgrading Heimdal in base.  It turns out
> that Heimdal now requires sqlite3 and includes its own version of
> same.  I think that it would be more general utility to import
> sqlite3 independently, though, and would like to start a discussion
> about doing it.
> 
> The license on sqlite3 is public domain.
> 
> It has no dependencies beyond -lc and -lphtread.  The package is
> one (rather large) C file, two headers and some autoconf goo only.
> And so it should be relatively easy to maintain and upgrade.
> 
> More information about sqlite3 can be found at http://sqlite.org/

+1 importing sqlite3

I've always liked sqlite and I've been doing a lot of development with it
lately at work and it is just a very nice product (and well tested, too!). 
While it is designed as an embedded database, I think it is strong enough to
take care of the vast majority of database needs (i.e., not many need the 
added benefits of a Postgres or the like).

--

-- 
Christopher Berardi
http://www.natoufa.com/

Be still, and know that I am God (Psalms 46:10)

(Continue reading)

Christos Zoulas | 1 Apr 04:02 2011

Re: sqlite/Heimdal.

In article <20110401002956.GA8906 <at> natoufa>,
Christopher Berardi  <cberardi <at> natoufa.com> wrote:
>On Thu, Mar 31, 2011 at 09:56:00AM +0100, Roland C. Dowdeswell wrote:
>> I am in the process of upgrading Heimdal in base.  It turns out
>> that Heimdal now requires sqlite3 and includes its own version of
>> same.  I think that it would be more general utility to import
>> sqlite3 independently, though, and would like to start a discussion
>> about doing it.
>> 
>> The license on sqlite3 is public domain.
>> 
>> It has no dependencies beyond -lc and -lphtread.  The package is
>> one (rather large) C file, two headers and some autoconf goo only.
>> And so it should be relatively easy to maintain and upgrade.
>> 
>> More information about sqlite3 can be found at http://sqlite.org/
>
>+1 importing sqlite3

+1 for importing sqlite3!

christos

Alistair Crooks | 1 Apr 08:06 2011

Re: sqlite/Heimdal.

On Fri, Apr 01, 2011 at 02:02:34AM +0000, Christos Zoulas wrote:
> In article <20110401002956.GA8906 <at> natoufa>,
> Christopher Berardi  <cberardi <at> natoufa.com> wrote:
> >On Thu, Mar 31, 2011 at 09:56:00AM +0100, Roland C. Dowdeswell wrote:
> >> I am in the process of upgrading Heimdal in base.  It turns out
> >> that Heimdal now requires sqlite3 and includes its own version of
> >> same.  I think that it would be more general utility to import
> >> sqlite3 independently, though, and would like to start a discussion
> >> about doing it.
> >> 
> >> The license on sqlite3 is public domain.
> >> 
> >> It has no dependencies beyond -lc and -lphtread.  The package is
> >> one (rather large) C file, two headers and some autoconf goo only.
> >> And so it should be relatively easy to maintain and upgrade.
> >> 
> >> More information about sqlite3 can be found at http://sqlite.org/
> >
> >+1 importing sqlite3
> 
> +1 for importing sqlite3!

+1 for stamping out "me too" emails!

Having said that, I'd also like to see sqlite3 imported into base,
with options rtree, fts and ucs enabled by default.

Best,
Alistair

(Continue reading)

Christoph Egger | 1 Apr 11:46 2011
Picon
Picon

xen-kernel boot fix: AT&T vs. GNU od(1)


Hi,

I submitted the fix to xen-devel <at>  that makes the xen kernel boot.
I got this response:

On 03/31/11 20:29, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] xen: fix reloc.S
generation"):
>> attached patch fixes generation of reloc.S and makes
>> xen boot out-of-the box since c/s 19146.
>> The output of AT&T UNIX and GNU od(1) are different.
>
> Which (if any) of these versions of od is correct ? The SuSv3
> specification of od is quite comprehensive so it should be possible to
> contrive a rune which doesn't need subsequent seddery. Could you try
> to do so ?

Christoph

Christoph Egger | 1 Apr 13:18 2011
Picon
Picon

Re: xen-kernel boot fix: AT&T vs. GNU od(1)

On 04/01/11 11:46, Christoph Egger wrote:
>
> Hi,
>
> I submitted the fix to xen-devel <at>  that makes the xen kernel boot.
> I got this response:

Sorry, I forgot the patch.

Christoph

> On 03/31/11 20:29, Ian Jackson wrote:
>> Christoph Egger writes ("[Xen-devel] [PATCH] xen: fix reloc.S
> generation"):
>>> attached patch fixes generation of reloc.S and makes
>>> xen boot out-of-the box since c/s 19146.
>>> The output of AT&T UNIX and GNU od(1) are different.
>>
>> Which (if any) of these versions of od is correct ? The SuSv3
>> specification of od is quite comprehensive so it should be possible to
>> contrive a rune which doesn't need subsequent seddery. Could you try
>> to do so ?
>
> Christoph

diff -r cebd5d3f0ec4 xen/arch/x86/boot/build32.mk
--- a/xen/arch/x86/boot/build32.mk	Fri Mar 25 11:29:24 2011 +0100
+++ b/xen/arch/x86/boot/build32.mk	Thu Mar 31 12:13:22 2011 +0200
(Continue reading)

Christoph Egger | 1 Apr 13:47 2011
Picon
Picon

Re: xen-kernel boot fix: AT&T vs. GNU od(1)

On 04/01/11 13:18, Christoph Egger wrote:
> On 04/01/11 11:46, Christoph Egger wrote:
>>
>> Hi,
>>
>> I submitted the fix to xen-devel <at>  that makes the xen kernel boot.
>> I got this response:
>
> Sorry, I forgot the patch.

I attached the reloc.bin which is the input.

This is what the build system does to generate the reloc.S:

(od -v -t x reloc.bin | awk 'NR > 1 {print s} {s=$0}' | \
         sed 's/ /,0x/g' | sed 's/^[0-9]*,/ .long /') >reloc.S

The attached reloc.S.atandt is the result with AT&T od(1)
The attached reloc.S is the result with GNU od(1) - and what is expected.

The xen_boot.diff changes above reloc.S generation to produce
the same output with both AT&T and GNU od(1).

Christoph

>> On 03/31/11 20:29, Ian Jackson wrote:
>>> Christoph Egger writes ("[Xen-devel] [PATCH] xen: fix reloc.S
>> generation"):
>>>> attached patch fixes generation of reloc.S and makes
>>>> xen boot out-of-the box since c/s 19146.
(Continue reading)

Abhinav Upadhyay | 1 Apr 14:54 2011
Picon

Re: Fwd: GSoC Project: Replacement for Apropos

On Wed, Mar 30, 2011 at 8:51 PM, Joerg Sonnenberger
<joerg <at> britannica.bec.de> wrote:

>> Also, I will be having my semester exams at the end of May so I will
>> not be available for around 10 days, will that be a problem ?
>
> Officially, work phase for the GSoC starts on May 24. Starting before
> that isn't really an issue. E.g. if "not available" means "completely
> vanishing from the world", that's going to ring some warning bells.
> Having a light week, especially if the prepation phase went well, isn't
> an issue though. We all know about the importance of exams. Mentors also
> have sometimes events that demand attention, but we have the advantage
> of being able to distribute the load :)
>
> Joerg
>

Hi,

I have put up the proposal on GSoC website. I would appreciate
feedback, so that I can improve it.

Here is the link:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/abhinav_upadhyay/1#

I personally feel that perhaps more details are required ? But it is
too long and I already cut short on a lot of stuff. But I tried to
answer as many questions as I could from the NetBSD SoC Application
guideline (http://www.netbsd.org/contrib/soc-application.html)

(Continue reading)

Abhinav Upadhyay | 1 Apr 17:15 2011
Picon

Re: sqlite/Heimdal.

On Thu, Mar 31, 2011 at 2:26 PM, Roland C. Dowdeswell <elric <at> imrryr.org> wrote:
> I am in the process of upgrading Heimdal in base.  It turns out
> that Heimdal now requires sqlite3 and includes its own version of
> same.  I think that it would be more general utility to import
> sqlite3 independently, though, and would like to start a discussion
> about doing it.
>
> The license on sqlite3 is public domain.
>
> It has no dependencies beyond -lc and -lphtread.  The package is
> one (rather large) C file, two headers and some autoconf goo only.
> And so it should be relatively easy to maintain and upgrade.
>
> More information about sqlite3 can be found at http://sqlite.org/
>
> --
>    Roland Dowdeswell                      http://Imrryr.ORG/~elric/
>

Sqlite3 with FTS support enabled is required for one of the GSoC projects.

+1 for this.

--
Abhinav

Edgar Fuß | 1 Apr 19:52 2011
Picon

undefined reference to `pqueue_size', net/freeradius not building rlm_eap_tls

Supposedly after applyin the fix fot SA2010-011, net/freeradius refuses to build most modules due to
OpenSSL not found.

There's a strange failure in config.log I can't make much sense out of:

configure:21465: checking for SSL_new in -lssl
configure:21500: cc -o conftest -O2 -I/usr/pkg/include -DLDAP_DEPRECATED -I/usr/include
-D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -I/usr/pkg/include -DLDAP_DEPRECATED -I/usr/include
-L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib conftest.c -lssl -lcrypto  -lcrypto
-lresolv   -pthread  >&5
/usr/lib/libssl.so: undefined reference to `pqueue_size'

I'm on 4.0.1/amd64 in case that matters.

I'm not subscribed to tech-userlevel, so please CC me if answering only there.

Andrew Doran | 1 Apr 22:33 2011
Picon

Re: ld.elf_so locking

On Mon, Mar 14, 2011 at 04:37:21PM +0100, Joerg Sonnenberger wrote:

> Comments?

Only a few right now..

> There are currently two situations left where a recursion would currently
> result in a dead lock: a signal handler or constructor using __tls_get_addr
> requiring memory allocation when already in ld.elf_so and a signal
> handler occuring during exclusively locked calls like dlopen trying to
> access a shared lock e.g. to lazily resolve a relocation.
> 
> The second can be mostly be adressed by using sigprocmask in the

For stuff like that one idea is to have the signal mask directly in the
_lwp_ctl area, so that sigprocmask() isn't any kind of performance concern. 
The signal mask is thread private state in the kernel with a couple of
exceptions, Oe can be worked around and I think the other relates to SA (and
so can die).  As a perhipheral benefit this could be a nice boost to some
workloads since sigprocmask() is called a lot.

On a related note is there a thread-private area that we can reserve to
point to the _lwp_ctl block?

> +static volatile bool _rtld_mutex_may_recurse;
> +

Prefer "int" or sigatomic_t as bool may be sub-word sized and thus cause
atomicity problems.  Maybe this is not a concern (although volatile
suggests it is).
(Continue reading)


Gmane