On Mon, Mar 14, 2011 at 04:20:22PM +0100, Jes Sorensen wrote:
> On 02/23/11 12:20, Alon Levy wrote:
> > +/* private data for PKI applets */
> > +typedef struct CACPKIAppletDataStruct {
> > +unsigned char *cert;
> > +int cert_len;
> > +unsigned char *cert_buffer;
> > +int cert_buffer
On 03/16/11 09:40, Alon Levy wrote:
> On Wed, Mar 16, 2011 at 09:23:20AM +0100, Jes Sorensen wrote:
>> It's really not far off, most of it is in the Makefiles. You really just
>> need to have a libcacard flag that is enabled per default (and is
>> required if one asks for --enable-smartcard), but c
On Wed, Mar 16, 2011 at 09:23:20AM +0100, Jes Sorensen wrote:
> On 03/15/11 15:23, Alon Levy wrote:
> > On Tue, Mar 15, 2011 at 08:45:29AM -0500, Anthony Liguori wrote:
> >> On 03/15/2011 08:14 AM, Alon Levy wrote:
> >>>
> Alternatively the external apps that build against it should be taught
On 03/15/11 16:14, Alon Levy wrote:
> On Tue, Mar 15, 2011 at 03:59:26PM +0100, Jes Sorensen wrote:
>> I don't think it is necessary for distro packaging. Most distros will
>> build multiple binary packages from one source package, and it is up to
>> the user to decide which ones to install.
>
> i
On 03/15/11 15:23, Alon Levy wrote:
> On Tue, Mar 15, 2011 at 08:45:29AM -0500, Anthony Liguori wrote:
>> On 03/15/2011 08:14 AM, Alon Levy wrote:
>>>
Alternatively the external apps that build against it should be taught
to link with the QEMU version.
>>> That would require me to te
On Tue, Mar 15, 2011 at 03:59:26PM +0100, Jes Sorensen wrote:
> On 03/15/11 15:56, Anthony Liguori wrote:
> > On 03/15/2011 09:51 AM, Jes Sorensen wrote:
> >> I don't think we want a --libs option that turns the build process into
> >> only producing the libs.
> >
> > No, but you should be able to
On 03/15/11 15:56, Anthony Liguori wrote:
> On 03/15/2011 09:51 AM, Jes Sorensen wrote:
>> I don't think we want a --libs option that turns the build process into
>> only producing the libs.
>
> No, but you should be able to use options to disable everything but the
> libs. Likewise, you should b
On 03/15/2011 09:51 AM, Jes Sorensen wrote:
On 03/15/11 15:25, Alon Levy wrote:
I am not sure what is the best way, if it stays in QEMU people will
eventually start making modifications to it, without looking at the
other copy that is being maintained.
Two copies is not really practical. QEMU
On 03/15/2011 09:25 AM, Alon Levy wrote:
On Tue, Mar 15, 2011 at 08:44:27AM -0500, Anthony Liguori wrote:
On 03/15/2011 07:42 AM, Jes Sorensen wrote:
On 03/14/11 17:40, Alon Levy wrote:
On Mon, Mar 14, 2011 at 04:20:22PM +0100, Jes Sorensen wrote:
ok, here is a note where I kinda ignored my o
On 03/15/11 15:25, Alon Levy wrote:
>>> I am not sure what is the best way, if it stays in QEMU people will
>>> > >eventually start making modifications to it, without looking at the
>>> > >other copy that is being maintained.
>> >
>> > Two copies is not really practical. QEMU should be the place
On Tue, Mar 15, 2011 at 08:44:27AM -0500, Anthony Liguori wrote:
> On 03/15/2011 07:42 AM, Jes Sorensen wrote:
> >On 03/14/11 17:40, Alon Levy wrote:
> >>On Mon, Mar 14, 2011 at 04:20:22PM +0100, Jes Sorensen wrote:
> >>
> >>ok, here is a note where I kinda ignored my own wishes but I want
> >>to b
On Tue, Mar 15, 2011 at 08:45:29AM -0500, Anthony Liguori wrote:
> On 03/15/2011 08:14 AM, Alon Levy wrote:
> >
> >>Alternatively the external apps that build against it should be taught
> >>to link with the QEMU version.
> >>
> >That would require me to teach qemu's configure to build libcacard, p
On Tue, Mar 15, 2011 at 02:40:04PM +0100, Jes Sorensen wrote:
> On 03/15/11 14:14, Alon Levy wrote:
> > On Tue, Mar 15, 2011 at 01:42:56PM +0100, Jes Sorensen wrote:
> >> Alternatively the external apps that build against it should be taught
> >> to link with the QEMU version.
> >>
> >
> > That wo
On 03/15/2011 08:14 AM, Alon Levy wrote:
Alternatively the external apps that build against it should be taught
to link with the QEMU version.
That would require me to teach qemu's configure to build libcacard, possibly
only libcacard (even though qemu doesn't need a lot of packages by itself
On 03/15/2011 07:42 AM, Jes Sorensen wrote:
On 03/14/11 17:40, Alon Levy wrote:
On Mon, Mar 14, 2011 at 04:20:22PM +0100, Jes Sorensen wrote:
ok, here is a note where I kinda ignored my own wishes but I want
to be very clear on them:
libcacard should not be part of qemu.
it is here because
On 03/15/11 14:14, Alon Levy wrote:
> On Tue, Mar 15, 2011 at 01:42:56PM +0100, Jes Sorensen wrote:
>> Alternatively the external apps that build against it should be taught
>> to link with the QEMU version.
>>
>
> That would require me to teach qemu's configure to build libcacard, possibly
> only
On Tue, Mar 15, 2011 at 01:42:56PM +0100, Jes Sorensen wrote:
> On 03/14/11 17:40, Alon Levy wrote:
> > On Mon, Mar 14, 2011 at 04:20:22PM +0100, Jes Sorensen wrote:
> >
> > ok, here is a note where I kinda ignored my own wishes but I want
> > to be very clear on them:
> > libcacard should not be
On 03/14/11 17:40, Alon Levy wrote:
> On Mon, Mar 14, 2011 at 04:20:22PM +0100, Jes Sorensen wrote:
>
> ok, here is a note where I kinda ignored my own wishes but I want
> to be very clear on them:
> libcacard should not be part of qemu.
> it is here because I once thought it would speed things
On Mon, Mar 14, 2011 at 04:20:22PM +0100, Jes Sorensen wrote:
ok, here is a note where I kinda ignored my own wishes but I want
to be very clear on them:
libcacard should not be part of qemu.
it is here because I once thought it would speed things up.
So I'm not taking it out or anything - it's
On 02/23/11 12:20, Alon Levy wrote:
> +/* private data for PKI applets */
> +typedef struct CACPKIAppletDataStruct {
> +unsigned char *cert;
> +int cert_len;
> +unsigned char *cert_buffer;
> +int cert_buffer_len;
> +unsigned char *sign_buffer;
> +int sign_buffer_len;
> +
20 matches
Mail list logo
