Re: fdo#63315: sign windows binaries during build

Hi,

On Tue, May 06, 2014 at 02:24:15PM +0200, Christian Lohmaier wrote:
> Hi *,
>
> On Tue, May 6, 2014 at 11:23 AM, Andras Timar <timar74@gmail.com> wrote:
> > Hi,
> >
> > On Tue, May 6, 2014 at 1:56 AM, Mathias MICHEL
> > <mathias-michel@laposte.net> wrote:
> > > See https://bugs.freedesktop.org/show_bug.cgi?id=63315
> > > From the Cloph's comment it seems the issue is fixed but with room for
> > > improvement.
>
> The room for improvement is in the general build, not specific to
> signing (i.e. copying files individually instead of using for example
> tar, or at least copy with multiple files at once/recursive copy,
> touching lots and lots of files,...) calling cp x times (creating a
> process that often), instead of once for x files is slow as hell on
> windows/cygwin.

I would strongly object to any change that improves performance of the
release builds at the expense of incremental builds, e.g., by dropping
precise dependencies in order to copy more files at once. I really do
not want to go back to the world of "compatible" vs. "incompatible"
builds...

> LO's patched version of make did make some touch and cp builtin
> functionality, but since gbuildification those rules don't match the
> majority of cases.

I do not really understand that... Does that mean there is something
that actively prevents make to use the builtin functions?

> > > Should we close it or not ?
> >
> > I'm interested in stability in this area and the current functionality
> > is good enough for me, so I'd say let's close it.
>
> Yes, close it.
>
> Signing needs exclusive lock on the file, so signing will fail when
> the file is opened by another process - so this is another problem
> that would likely occur if the signing was done after each creation.

No, it would not. It is the current state, which does the signing at
arbitrary time, that has this inherent problem. The proposal in that
easy hack is to sign every library during linking; _nothing_ can be
using the library at that point, unless there are missing dependencies.

> (see 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea391abb3f2eb0ffaa892f9d7437dcf33bda6440
> that made singing depend on slowchecks being done, as otherwise
> signing would fail)

And I strongly suspect the next stop will be gallery creation, as gengal
is internal tool which needs a zillion libraries... If we really want to
continue to use this script for signing, IMHO it should be done as a
separate step after build.

D.