On Tuesday, 24 June 2025 01:15:06 BST G. Branden Robinson wrote: > Follow-up Comment #33, bug #67207 (group groff): > > Resuming the conversation about build infrastructure stuff. > > Deri responded to me in an email: > >> (font/devpdf/download): Set write permission on the target to work > >> around GNU Automake "distcheck" feature that makes make(1)-generated > >> files read-only; however we want "BuildFoundries" to rewrite the file > >> in place. > > > > A while ago you changed it from writing download directly to > > writing > > to > > download.tmp which > > is then "mv"ed. > > I _think_ what's happening--but I haven't verified this or dug into Automake > internals to try to grasp what's going on--is that because > "BuildFoundries.pl" rewrites the "download" file by "clobbering" it, that > triggers the overwrite warning due to the permissions Automake sets to test > the distribution archive. > > We use the "mv $@.tmp $@" technique in other places without provoking this > issue, at any rate, so the foregoing is my guess.
Almost there. mv $@.tmp $@ works great if $@ does not already exist with read-
only permissions, similarly copying download.in works great if the mv has not
already happened. With 16 cores make -j would sometimes work (when the cp and
the mv finished before the chmod -R a=r hit).
> > Yes it could be a separate target, but I would prefer a pfb file (more
> > compact, gropdf is slow enough already). So maybe StandardSymSL.pfb.in
> > generates (cp -u) StandardSymSL.pfb.
> > SS does not actually need a separate rule, a change to foundry.in could
> > take care of it, but if you intend to retire BuildFoundries transferring
> > all the logic to devpdf.am it is probably not worth it.
>
> Okay. Adding the low-hanging fruit as a plan for this ticket.
>
> I don't have any short-term aim to retire "BuildFoundries.pl", but for
> build-related jiggery-pokery I'd like to do as much in _make_(1) targets as
> possible.
>
> By contrast, we can still use _pfbtops_ to generate a PFA from
> "StandardSymSL.pfb", but we don't have to name the PFA in the "download"
> file. Not doing so makes the exercise a bit of a digression from
> "devpdf.am"'s mission, but I like the idea of shipping the font in both
> formats, and I strongly like the idea of actually exercising _pfbtops_'s
> code.
Why do you like the idea?
> > My first time attempt at using the bug-list email interface, so it
> > probably
> > won't work.
>
> It did not work out well. You need to be sure to GPG-sign the reply with
> the key in your Savannah profile, and anything you put below the "savane"
> line that the reply interface says **has** to be there, it will discard
> from your message.
>
> I learned these things the hard way.
Second time was better, made it to the list, but mangled the pdf attachment,
this, the third attempt, got to be the charm. :-)
{savane: user = 90212; tracker = bugs; item = 67207}
signature.asc
Description: This is a digitally signed message part.
