Re: [ITP] openh264 (2.3.1)
On 17/02/2023 08:49, Takashi Yano via Cygwin-apps wrote:
On Thu, 16 Feb 2023 19:24:24 +
Jon Turney wrote:
On 14/02/2023 21:21, Takashi Yano via Cygwin-apps wrote:
On Tue, 14 Feb 2023 17:41:16 +0100
ASSI wrote:
Takashi Yano via Cygwin-apps writes:
Thanks for the advice. I have revised the cygport file.
You are getting the file and the hash from the same unprotected source.
I was thinking you should put the hash into the cygport file and hence
the postinstall script.
Also note that the system doing the postinstall will not necessarily
have internet access, so you'll need to cope with errors that will
produce.
Thanks.
The new cygport file attached downloads md5hash during
the packaging process and embeds it into postinstall
script. Does this make sense?
Thanks.
So, this looks like it works, and meets the requirements.
Is md5 the only hash available? This is not really considered "good
enough" any more.
As a thought-experiment, consider doing it slightly differently:
package contains:
- the headers
- a data file with the version (or maybe URL) and hash
- a script which can fetch (using above data) or remove the DLL
- postinstall and preremove scripts which invoke that script appropriately
(I think this means the post/pre scripts can be static, and packaged via
$C, rather than written by the cygport itself)
What do you think of that?
Thanks for the advice!
So, how about this one?
package contains:
- the headers
- the data files with the version and hash
- postinstall and preremove scripts which fetch (using above data)
and remove the DLL
Great, thanks. I hope this means you think this is a better approach,
rather than just humouring me :)
A few minor points:
* It seems like the empty dummy archive could be made with something
like just:
tar -Jcf ${SRC_URI} --files-from /dev/null
* If the postinstall failed somehow, the preremove script will fail
trying to remove a file which doesn't exist. It might be a good idea to
use 'rm -f' to ensure that doesn't happen.
* I don't think you should need:
# Install postinstall/preremove scripts
mkdir -p ${D}/etc/postinstall ${D}/etc/preremove
cp ${C}/lib${NAME}.postinstall ${D}/etc/postinstall/lib${NAME}.sh
cp ${C}/lib${NAME}.preremove ${D}/etc/preremove/lib${NAME}.sh
This should happen automatically if the files are in $C (and you can
list them in CYGWIN_FILES or make them with cygwin.patch file to put
them there)
Re: Heads up: Problems with parallel make
On 2/20/2023 6:29 PM, Ken Brown via Cygwin-apps wrote: On 2/20/2023 5:00 PM, Ken Brown via Cygwin-apps wrote: On 2/20/2023 2:12 PM, Marco Atzeri via Cygwin-apps wrote: uploaded as test 4.4.0.91-1 following message is still present while missing in 4.4-1 make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. and I do not see clear evidence of parallelism like in 4.4-1 I doubt if this is related to the pipe vs. fifo issue, but maybe you should test 4.4.0.90-1 to be sure. Do you have a simple way to reproduce the problem? For example, does it happen if you just make a toy cmake project? Ignore what I said about 'make -j13 check' working right in the TeX Live build. I just retried it and saw the "jobserver unavailable" message. When I saw several makes running at once, I think it was because of recursion, not parallelism. So there's a real problem that can be reproduced without cmake. I'm going to report this upstream, as a continuation of the upstream bug report that I filed earlier. Ken
Re: Heads up: Problems with parallel make
On 2/20/2023 5:00 PM, Ken Brown via Cygwin-apps wrote: On 2/20/2023 2:12 PM, Marco Atzeri via Cygwin-apps wrote: uploaded as test 4.4.0.91-1 following message is still present while missing in 4.4-1 make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. and I do not see clear evidence of parallelism like in 4.4-1 I doubt if this is related to the pipe vs. fifo issue, but maybe you should test 4.4.0.90-1 to be sure. Do you have a simple way to reproduce the problem? For example, does it happen if you just make a toy cmake project? Ignore what I said about 'make -j13 check' working right in the TeX Live build. I just retried it and saw the "jobserver unavailable" message. When I saw several makes running at once, I think it was because of recursion, not parallelism. So there's a real problem that can be reproduced without cmake. Ken
Re: Heads up: Problems with parallel make
On 2/20/2023 2:12 PM, Marco Atzeri via Cygwin-apps wrote: uploaded as test 4.4.0.91-1 following message is still present while missing in 4.4-1 make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. and I do not see clear evidence of parallelism like in 4.4-1 I doubt if this is related to the pipe vs. fifo issue, but maybe you should test 4.4.0.90-1 to be sure. Do you have a simple way to reproduce the problem? For example, does it happen if you just make a toy cmake project? Ken
Re: Heads up: Problems with parallel make
On 2/20/2023 2:12 PM, Marco Atzeri via Cygwin-apps wrote: On 20.02.2023 18:34, Marco Atzeri wrote: On 20.02.2023 18:14, Ken Brown via Cygwin-apps wrote: On 2/20/2023 12:00 PM, Achim Gratz via Cygwin-apps wrote: Ken Brown via Cygwin-apps writes: Thanks, Marco. As expected, that fixes the problem for my test case (building TeX Live). Obviously it would be better if the make developers would provide a configure option to use a pipe for the jobserver, but this is a good workaround if they don't. Does it actually do a parallel build? I've quickly tested a cmake based project with it and it completely serializes the build. Reverting to 4.4 resolves that problem. uploaded as test 4.4.0.91-1 following message is still present while missing in 4.4-1 make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. and I do not see clear evidence of parallelism like in 4.4-1 It does for my build of TeX Live. I just tried 'make -j13 check', and I saw many make processes and many sh processes running at once. [But I'm currently testing a self-built make 4.4.0.91.] Ken How are you configuring your build ? Just a plain vanilla build, no configure options. Ken
Re: Heads up: Problems with parallel make
On 20.02.2023 18:34, Marco Atzeri wrote: On 20.02.2023 18:14, Ken Brown via Cygwin-apps wrote: On 2/20/2023 12:00 PM, Achim Gratz via Cygwin-apps wrote: Ken Brown via Cygwin-apps writes: Thanks, Marco. As expected, that fixes the problem for my test case (building TeX Live). Obviously it would be better if the make developers would provide a configure option to use a pipe for the jobserver, but this is a good workaround if they don't. Does it actually do a parallel build? I've quickly tested a cmake based project with it and it completely serializes the build. Reverting to 4.4 resolves that problem. uploaded as test 4.4.0.91-1 following message is still present while missing in 4.4-1 make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. and I do not see clear evidence of parallelism like in 4.4-1 It does for my build of TeX Live. I just tried 'make -j13 check', and I saw many make processes and many sh processes running at once. [But I'm currently testing a self-built make 4.4.0.91.] Ken How are you configuring your build ?
Re: Heads up: Problems with parallel make
On 2023-02-20 10:14, Ken Brown via Cygwin-apps wrote: On 2/20/2023 12:00 PM, Achim Gratz via Cygwin-apps wrote: Ken Brown via Cygwin-apps writes: Thanks, Marco. As expected, that fixes the problem for my test case (building TeX Live). Obviously it would be better if the make developers would provide a configure option to use a pipe for the jobserver, but this is a good workaround if they don't. Does it actually do a parallel build? I've quickly tested a cmake based project with it and it completely serializes the build. Reverting to 4.4 resolves that problem. It does for my build of TeX Live. I just tried 'make -j13 check', and I saw many make processes and many sh processes running at once. [But I'm currently testing a self-built make 4.4.0.91.] Definitely parallel jobs visible in top with make 4.4.0.90-1 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirerbut when there is no more to cut -- Antoine de Saint-Exupéry
Re: Heads up: Problems with parallel make
On 20.02.2023 18:14, Ken Brown via Cygwin-apps wrote: On 2/20/2023 12:00 PM, Achim Gratz via Cygwin-apps wrote: Ken Brown via Cygwin-apps writes: Thanks, Marco. As expected, that fixes the problem for my test case (building TeX Live). Obviously it would be better if the make developers would provide a configure option to use a pipe for the jobserver, but this is a good workaround if they don't. Does it actually do a parallel build? I've quickly tested a cmake based project with it and it completely serializes the build. Reverting to 4.4 resolves that problem. I noticed the same with another cmake build make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. but I do not see the message on Autoconf build It does for my build of TeX Live. I just tried 'make -j13 check', and I saw many make processes and many sh processes running at once. [But I'm currently testing a self-built make 4.4.0.91.] Ken I will build it and test again Regards Marco
Re: Heads up: Problems with parallel make
On 2/20/2023 12:00 PM, Achim Gratz via Cygwin-apps wrote: Ken Brown via Cygwin-apps writes: Thanks, Marco. As expected, that fixes the problem for my test case (building TeX Live). Obviously it would be better if the make developers would provide a configure option to use a pipe for the jobserver, but this is a good workaround if they don't. Does it actually do a parallel build? I've quickly tested a cmake based project with it and it completely serializes the build. Reverting to 4.4 resolves that problem. It does for my build of TeX Live. I just tried 'make -j13 check', and I saw many make processes and many sh processes running at once. [But I'm currently testing a self-built make 4.4.0.91.] Ken
Re: Heads up: Problems with parallel make
Ken Brown via Cygwin-apps writes: > Thanks, Marco. As expected, that fixes the problem for my test case > (building TeX Live). Obviously it would be better if the make > developers would provide a configure option to use a pipe for the > jobserver, but this is a good workaround if they don't. Does it actually do a parallel build? I've quickly tested a cmake based project with it and it completely serializes the build. Reverting to 4.4 resolves that problem. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: Heads up: Problems with parallel make
On 2/16/2023 9:21 PM, Ken Brown via Cygwin-apps wrote:
On 2/16/2023 2:47 AM, Marco Atzeri via Cygwin-apps wrote:
On 15.02.2023 19:09, Ken Brown via Cygwin-apps wrote:
On 2/14/2023 4:23 PM, Marco Atzeri via Cygwin-apps wrote:
On 14.02.2023 17:49, Brian Inglis via Cygwin-apps wrote:
There is a make 4.4.1 release candidate 4.40.0.90 with patches that
may help to deal with this:
https://alpha.gnu.org/gnu/make/make-4.4.0.90.tar.lz{,.sig}
https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=110=custom
test version built and on the way
The problems I reported with make 4.4 still exist in 4.4.0.90.
Until someone can figure out why this happens, you might want to
consider building make so that it doesn't default to using a FIFO for
its jobserver. I suggested to the make developers that they provide
a configure option for this purpose. If they don't do this, I think
you could accomplish the same thing by configuring make with
ac_cv_func_mkfifo=no.
Ken
version 2 uploaded.
Thanks, Marco. As expected, that fixes the problem for my test case
(building TeX Live). Obviously it would be better if the make
developers would provide a configure option to use a pipe for the
jobserver, but this is a good workaround if they don't.
Just to finish this off, there's now a new release candidate 4.4.0.91
for make, which makes the jobserver use a pipe by default on Cygwin.
You can override this default when building make by defining
JOBSERVER_USE_FIFO to 1, and you can override it when running make by
using the make option --jobserver-style=fifo. But there's no longer a
need to build make with ac_cv_func_mkfifo=no, and there's no longer a
need to use --jobserver-style=pipe when running make.
I'm very impressed with how responsive the make developer (Paul Smith) was.
Ken
Re: [ITP] openh264 (2.3.1)
On Sun, 19 Feb 2023 15:37:47 +
Jon Turney wrote:
> On 17/02/2023 08:49, Takashi Yano via Cygwin-apps wrote:
> > So, how about this one?
> >
> > package contains:
> > - the headers
> > - the data files with the version and hash
> > - postinstall and preremove scripts which fetch (using above data)
> >and remove the DLL
>
> Great, thanks. I hope this means you think this is a better approach,
> rather than just humouring me :)
Absolutely yes :)
> A few minor points:
>
> * It seems like the empty dummy archive could be made with something
> like just:
>
>tar -Jcf ${SRC_URI} --files-from /dev/null
Just doing this causes mismatch of SRC_DIR with actual source
package. However, making ${NAME}-{$VERSION}/dummy file does not
seem necessary.
So, I modified the cygport file as follows.
mkdir -p ${NAME}-${VERSION}
tar acf ${SRC_URI} ${NAME}-${VERSION}
rm -rf ${NAME}-${VERSION}
> * If the postinstall failed somehow, the preremove script will fail
> trying to remove a file which doesn't exist. It might be a good idea to
> use 'rm -f' to ensure that doesn't happen.
Indeed. Fixed. Thanks!
> * I don't think you should need:
>
> > # Install postinstall/preremove scripts
> > mkdir -p ${D}/etc/postinstall ${D}/etc/preremove
> > cp ${C}/lib${NAME}.postinstall ${D}/etc/postinstall/lib${NAME}.sh
> > cp ${C}/lib${NAME}.preremove ${D}/etc/preremove/lib${NAME}.sh
> >
>
> This should happen automatically if the files are in $C (and you can
> list them in CYGWIN_FILES or make them with cygwin.patch file to put
> them there)
That's what I understood from
https://cygwin.github.io/cygport/masterindex.html,
however, actually libopenh264.{postinstall,preremove} are
not installed during install process by cygport 0.36.0
even though openh264-2.3.1-1.cygwin.patch exists.
Could you please give me a hint how I can make it work?
--
Takashi Yano
