On 2017-04-20 15:04 GMT+02:00 Martin Jansa :
> On Thu, Apr 20, 2017 at 03:37:24PM +0300, Alexander Kanavin wrote:
>> On 04/19/2017 04:03 PM, David Vincent wrote:
>> > The problem is that I must be able to manage the configuration of a machine
>> > without physical
On Thu, Apr 20, 2017 at 03:37:24PM +0300, Alexander Kanavin wrote:
> On 04/19/2017 04:03 PM, David Vincent wrote:
> > The problem is that I must be able to manage the configuration of a machine
> > without physical intervention and only via package upgrades. A new
> > configuration can be applied
On 4/20/17 7:37 AM, Alexander Kanavin wrote:
> On 04/19/2017 04:03 PM, David Vincent wrote:
>> The problem is that I must be able to manage the configuration of a machine
>> without physical intervention and only via package upgrades. A new
>> configuration can be applied simply by incrementing
On 04/19/2017 04:03 PM, David Vincent wrote:
The problem is that I must be able to manage the configuration of a machine
without physical intervention and only via package upgrades. A new
configuration can be applied simply by incrementing the PR of a configuration
package.
But maybe this is a
On mercredi 19 avril 2017 13:57:40 CEST Alexander Kanavin wrote:
> On 04/19/2017 02:53 PM, David Vincent wrote:
> >> This kind of thing is better done via ROOTFS_POSTPROCESS_COMMAND, I
> >> think. Look for examples in rootfs-postcommands.bbclass.
> >
> > The problem of ROOTFS_POSTPROCESS_COMMAND
On 04/19/2017 02:57 PM, Alexander Kanavin wrote:
On 04/19/2017 02:53 PM, David Vincent wrote:
This kind of thing is better done via ROOTFS_POSTPROCESS_COMMAND, I
think. Look for examples in rootfs-postcommands.bbclass.
The problem of ROOTFS_POSTPROCESS_COMMAND is that it is a one shot
On 04/19/2017 02:53 PM, David Vincent wrote:
This kind of thing is better done via ROOTFS_POSTPROCESS_COMMAND, I
think. Look for examples in rootfs-postcommands.bbclass.
The problem of ROOTFS_POSTPROCESS_COMMAND is that it is a one shot function
that is run at image creation. In my case, I
On mercredi 19 avril 2017 12:21:18 CEST Alexander Kanavin wrote:
> On 04/19/2017 11:27 AM, David Vincent wrote:
> > The package is then chosen during image creation based on some
> > MACHINE_FEATURES, i.e. if the machine provides a crypto accelerator to use
> > instead of relying on software
On 04/19/2017 11:27 AM, David Vincent wrote:
The package is then chosen during image creation based on some
MACHINE_FEATURES, i.e. if the machine provides a crypto accelerator to use
instead of relying on software implementations. I hope that these new details
will help you understand what I was
On jeudi 13 avril 2017 10:05:29 CEST Jussi Kukkonen wrote:
> Hi David,
>
> Just a heads-up: I will propose a revert of this patch this week unless
> better ideas come up in the mean time.
Sorry, I've been away last week so didn't have time to respond to your
previous mails. I've seen the revert
On Fri, Apr 07, 2017 at 02:27:45PM +0200, David Vincent wrote:
> On jeudi 6 avril 2017 15:03:36 CEST Martin Jansa wrote:
> > I still don't understand why not use standard update-alternatives and
> > install another package with your favorite openssl.conf which has higher
> > ALTERNATIVE_PRIORITY.
On 7 April 2017 at 15:27, David Vincent wrote:
>
> On jeudi 6 avril 2017 15:03:36 CEST Martin Jansa wrote:
> > I still don't understand why not use standard update-alternatives and
> > install another package with your favorite openssl.conf which has higher
> >
On jeudi 6 avril 2017 15:03:36 CEST Martin Jansa wrote:
> I still don't understand why not use standard update-alternatives and
> install another package with your favorite openssl.conf which has higher
> ALTERNATIVE_PRIORITY.
Why not, but maybe this
I still don't understand why not use standard update-alternatives and
install another package with your favorite openssl.conf which has higher
ALTERNATIVE_PRIORITY.
This way u-a will switch to new config even when you just install the
package which require it on the target later and will switch
On 6 April 2017 at 12:23, David Vincent wrote:
>
> On mercredi 5 avril 2017 09:30:52 CEST Jussi Kukkonen wrote:
> > This apparently breaks key generation with openssl-native because the
file
> > doesn't exist.
>
> Looking at the recipe right now, I understand why key
On mercredi 5 avril 2017 09:30:52 CEST Jussi Kukkonen wrote:
> This apparently breaks key generation with openssl-native because the file
> doesn't exist.
Looking at the recipe right now, I understand why key generation is broken for
native build (I should have been more careful). I see two ways
On 23 January 2017 at 15:59, David Vincent wrote:
> Symlinking the openssl configuration file at install time results in
> errors when overriding it using an external package which also provides
> openssl-conf. This should be done as a postinstall task for such
> packages.
17 matches
Mail list logo