Re: cygport test has zero exit status on failures
Jason Pyeron writes: > Cygport test is not returning a non zero exit status on failure! Is > this expected? Yes, it is using 'make -k' under the hood. Again, if you need to do something else than what the standard invocation provides, you would generally write your own src_test() function. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
RE: pdfgrep [ITA]
(resending, accidentally sent direct to Marco) > -Original Message- > From: Marco Atzeri > Sent: Sunday, May 9, 2021 4:05 PM > > On 09.05.2021 21:54, Marco Atzeri wrote: > > On 09.05.2021 20:22, Jason Pyeron wrote: > > > > > > > $ ./pdfgrep.exe --help > > terminate called after throwing an instance of 'std::runtime_error' > >what(): locale::facet::_S_create_c_locale name not valid > > Aborted (core dumped) > > > > Same for your binary > > > > it seems the program does not like a locale different from C > > $ LC_ALL=C bin/pdfgrep.exe > Usage: bin/pdfgrep [OPTION]... PATTERN FILE... > > See 'bin/pdfgrep --help' for more information > > $ LC_ALL="en_US.UTF-8" bin/pdfgrep.exe > terminate called after throwing an instance of 'std::runtime_error' >what(): locale::facet::_S_create_c_locale name not valid > Aborted (core dumped) Testing is on my list - hence the CI build infra... That being said - I cannot reproduce your core dumps for 1.4.1, I can for 2.1.2 jenkinsoss-ci-cygwin ~ $ cd ./workspace/oss-cygwin-pdfgrep-1.4.1-x64/pdfgrep-1.4.1-2.x86_64/inst/usr/bin/ jenkinsoss-ci-cygwin ~/workspace/oss-cygwin-pdfgrep-1.4.1-x64/pdfgrep-1.4.1-2.x86_64/inst/usr/bin $ ./pdfgrep.exe --help Usage: ./pdfgrep [OPTION]... PATTERN FILE... Search for PATTERN in each FILE. PATTERN is, by default, an extended regular expression. Options: -i, --ignore-case Ignore case distinctions -P, --pcre Use Perl compatible regular expressions (PCRE) -H, --with-filenamePrint the file name for each match -h, --no-filename Suppress the prefixing of file name on output -n, --page-number Print page number with output lines -c, --countPrint only a count of matches per file -C, --context NUM Print at most NUM chars of context --color WHEN Use colors for highlighting; WHEN can be `always', `never' or `auto' -p, --page-count Print only a count of matches per page -m, --max-count NUMStop reading after NUM matching lines (per file) -q, --quietSuppress normal output -r, --recursiveSearch directories recursively -R, --dereference-recursiveLikewise, but follow all symlinks --help Print this help -V, --version Show version information jenkinsoss-ci-cygwin ~/workspace/oss-cygwin-pdfgrep-1.4.1-x64/pdfgrep-1.4.1-2.x86_64/inst/usr/bin $ cd .. jenkinsoss-ci-cygwin ~/workspace/oss-cygwin-pdfgrep-1.4.1-x64/pdfgrep-1.4.1-2.x86_64/inst/usr $ LC_ALL="en_US.UTF-8" bin/pdfgrep.exe Usage: bin/pdfgrep [OPTION]... PATTERN FILE... See 'bin/pdfgrep --help' for more information jenkinsoss-ci-cygwin ~/workspace/oss-cygwin-pdfgrep-1.4.1-x64/pdfgrep-1.4.1-2.x86_64/inst/usr $ Upstream bugs: https://gitlab.com/pdfgrep/pdfgrep/-/issues/45 and https://gitlab.com/pdfgrep/pdfgrep/-/issues/47 -Jason
cygport test has zero exit status on failures
Cygport test is not returning a non zero exit status on failure! Is this expected? jenkinsoss-ci-cygwin ~/workspace/oss-cygwin-pdfgrep-2.1.2-x64 $ cygport pdfgrep.cygport test; echo $? >>> Testing pdfgrep-2.1.2-1.x86_64 Making check in src ... WARNING: Couldn't find the global config file. Test Run By jenkins$ on Sun May 9 17:08:41 2021 Native configuration is x86_64-pc-cygwin === pdfgrep tests === Schedule of variations: unix Running target unix ... === pdfgrep Summary === # of unexpected failures2 # of unsupported tests 12 WARNING: pdfgrep_version failed: terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid make[3]: *** [Makefile:445: check-DEJAGNU] Error 1 make[3]: Leaving directory '/cygdrive/c/Users/jenkins$/workspace/oss-cygwin-pdfgrep-2.1.2-x64/pdfgrep-2.1.2-1.x86_64/build/testsuite' make[2]: *** [Makefile:545: check-am] Error 2 make[2]: Leaving directory '/cygdrive/c/Users/jenkins$/workspace/oss-cygwin-pdfgrep-2.1.2-x64/pdfgrep-2.1.2-1.x86_64/build/testsuite' make[1]: *** [Makefile:352: check-recursive] Error 1 make[1]: Target 'check' not remade because of errors. make[1]: Leaving directory '/cygdrive/c/Users/jenkins$/workspace/oss-cygwin-pdfgrep-2.1.2-x64/pdfgrep-2.1.2-1.x86_64/build/testsuite' make[1]: Entering directory '/cygdrive/c/Users/jenkins$/workspace/oss-cygwin-pdfgrep-2.1.2-x64/pdfgrep-2.1.2-1.x86_64/build' make[1]: Leaving directory '/cygdrive/c/Users/jenkins$/workspace/oss-cygwin-pdfgrep-2.1.2-x64/pdfgrep-2.1.2-1.x86_64/build' make: *** [Makefile:389: check-recursive] Error 1 make: Target 'check' not remade because of errors. 0
Re: pdfgrep [ITA]
On 09.05.2021 21:54, Marco Atzeri wrote: On 09.05.2021 20:22, Jason Pyeron wrote: $ ./pdfgrep.exe --help terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Aborted (core dumped) Same for your binary it seems the program does not like a locale different from C $ LC_ALL=C bin/pdfgrep.exe Usage: bin/pdfgrep [OPTION]... PATTERN FILE... See 'bin/pdfgrep --help' for more information $ LC_ALL="en_US.UTF-8" bin/pdfgrep.exe terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Aborted (core dumped)
Re: pdfgrep [ITA]
On 09.05.2021 20:22, Jason Pyeron wrote:
pull it up to the latest version (2.1.2),
2 Issues encountered and mitigated.
1. There are some significant changes in the functionality of 2.1.2 vs 1.4.1.
2. The tool chain has evolved a bit since 2016, so the current 1.4.1-1 release
would not build anymore, so I have updated the cygport as release 2.
So I have built both 1.4.1 and 2.1.2 on Windows Server 2019 with all updates
installed.
check the patches for the
major Linux distros (if any, Fedora does not for instance) and make sure
I started with pdfgrep's master branch, so when the next release is made there
should not be any surprises. But I did not yet review other distro's patches. I
can make master branch builds available as test marked packages, but need
guidance on version number and release numbering first.
I have not pushed my changes outside of my private repo, as I expect that there
will be some editorial change requests along with any additional patching.
it works on both 32bit and 64bit architecture and show the result.
How should I force cygport to run `make check`? In other words how do I link
the `cygport test` command to `make check` ? I read the cygport docs, but
README and html/manual/src_test_cygpart.html were not helpful.
`cygport pdfgrep.cygport check` will run make check.
the default test method is
src_test() {
cd ${B}
cygmake check
}
On my build, it is all failing
and the binary itself is not really functional
$ ./pdfgrep.exe --help
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted (core dumped)
Same for your binary
May be some other patches are needed ?
General suggestion:
- add BUILD_REQUIRES="libpcre-devel libgcrypt-devel libpoppler-cpp-devel"
the test suite seems to need tcl so you may need to add more packages
Re: pdfgrep [ITA]
Jason Pyeron writes: > 2 Issues encountered and mitigated. > > 1. There are some significant changes in the functionality of 2.1.2 vs > 1.4.1. 2. The tool chain has evolved a bit since 2016, so the current > 1.4.1-1 release would not build anymore, so I have updated the cygport > as release 2. > > So I have built both 1.4.1 and 2.1.2 on Windows Server 2019 with all > updates installed. Great. >> > check the patches for the major Linux distros (if any, Fedora does >> > not for instance) and make sure > > I started with pdfgrep's master branch, so when the next release is > made there should not be any surprises. But I did not yet review other > distro's patches. I can make master branch builds available as test > marked packages, but need guidance on version number and release > numbering first. Looks fine to me, any particular question? > I have not pushed my changes outside of my private repo, as I expect > that there will be some editorial change requests along with any > additional patching. Looks like pfsgrep doesn't need much or any patching, so I guess the only patch will be your fix for the build (which eventually should be upstreamed). >> > it works on both 32bit and 64bit architecture and show the result. > > How should I force cygport to run `make check`? In other words how do > I link the `cygport test` command to `make check` ? I read the cygport > docs, but README and html/manual/src_test_cygpart.html were not > helpful. It automatically does this (it tries to run 'make check' and if that doesn't work it tries to run 'make test'. If you need to do anything else, you would define a src-test() function in the cygport file and do whatever that is there. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
RE: pdfgrep [ITA]
> -Original Message- > From: Jason Pyeron > Sent: Monday, May 3, 2021 3:28 PM > > > -Original Message- > > From: Achim Gratz > > Sent: Monday, May 3, 2021 3:21 PM > > > > Jason Pyeron writes: > > > Just noticed that https://cygwin.com/packages/summary/pdfgrep.html is > > > marked as ORPHANED. > > > > > > If that is the case, how can we help? Very willing to take on the > > > maintainer role. > > > > Go to > > > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pdfgrep.git > > > > pull it up to the latest version (2.1.2), 2 Issues encountered and mitigated. 1. There are some significant changes in the functionality of 2.1.2 vs 1.4.1. 2. The tool chain has evolved a bit since 2016, so the current 1.4.1-1 release would not build anymore, so I have updated the cygport as release 2. So I have built both 1.4.1 and 2.1.2 on Windows Server 2019 with all updates installed. > > check the patches for the > > major Linux distros (if any, Fedora does not for instance) and make sure I started with pdfgrep's master branch, so when the next release is made there should not be any surprises. But I did not yet review other distro's patches. I can make master branch builds available as test marked packages, but need guidance on version number and release numbering first. I have not pushed my changes outside of my private repo, as I expect that there will be some editorial change requests along with any additional patching. > > it works on both 32bit and 64bit architecture and show the result. How should I force cygport to run `make check`? In other words how do I link the `cygport test` command to `make check` ? I read the cygport docs, but README and html/manual/src_test_cygpart.html were not helpful. > > Will do this weekend. The 1.4.1 built artifacts can be reviewed here: https://www.pdinc.us/ci/job/oss-cygwin-pdfgrep-1.4.1-x64/lastSuccessfulBuild/artifact/pdfgrep-1.4.1-2.x86_64/dist/ https://www.pdinc.us/ci/job/oss-cygwin-pdfgrep-1.4.1-x86/lastSuccessfulBuild/artifact/pdfgrep-1.4.1-2.i686/dist/ The 2.1.2 built artifacts can be reviewed here: https://www.pdinc.us/ci/job/oss-cygwin-pdfgrep-2.1.2-x64/lastSuccessfulBuild/artifact/pdfgrep-2.1.2-1.x86_64/dist/ https://www.pdinc.us/ci/job/oss-cygwin-pdfgrep-2.1.2-x86/lastSuccessfulBuild/artifact/pdfgrep-2.1.2-1.i686/dist/ v/r, Jason Pyeron
[PATCH cygport] Raise an error if we package files in /usr/local
If we end up with files in /usr/local/ in a package, this tends to
suggest the prefix hasn't been applied somewhere, so raise an error.
---
lib/pkg_pkg.cygpart | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 91e8768..d643426 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -243,7 +243,7 @@ __pkg_pkgcheck() {
sort < ${tmp1} > "${tmp1}.sorted";
mv -f "${tmp1}.sorted" ${tmp1};
- if grep "\.stackdump$" ${tmp1} > ${T}/pkgcheck.lst
+ if grep -E "^usr/local|\.stackdump$" ${tmp1} > ${T}/pkgcheck.lst
then
warning "Packages contain unexpected files:";
cat ${T}/pkgcheck.lst;
--
2.31.1
Re: GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]
On 17/01/2021 15:33, Adam Dinwoodie wrote:
On Sat, 16 Jan 2021 at 22:31, Ken Brown wrote:
On 1/16/2021 3:33 PM, Adam Dinwoodie wrote:
On Sat, 16 Jan 2021 at 20:22, Adam Dinwoodie wrote:
Version 0.65-1 of moreutils has been uploaded and should be coming
soon to a distribution server near you.
In case anyone's interested or has thoughts:
As part of working on this release, I've been playing with GitHub's
automation tools. The entire build / test / package / release / upload
process was performed using free ephemeral GitHub-managed VMs. At
least in theory, this reduces the manual work for future releases to:
- Commit a version of the Cygport file with an updated version number.
- Create a tag and push that tag to GitHub
- Wait for the confirmation email to arrive
- Send the announcement email
Thanks for sharing this.
One architectural problem that requires solving in cygport that we both
have is that we aren't building from the source package, but the package
repository (so this doesn't verify that all the files used by the build
are put into the source package). Ideally we'd be able to instruct
cygport to make just the source package, then unpack and build from that.
This is obviously serving a similar purpose to the automated builds
that Scallywag provides; I'm not sure I'd have bothered with this
project had I not already been most of the way through it before I
spotted Scallywag existed. I suspect in theory Scallywag's access to
the Cygwin servers means it's potentially more powerful, but Scallywag
also comes with some general caveats ("at this stage, this is only
probably useful for verifying that BUILD_REQUIRES is correct"),
I assume you're quoting from https://cygwin.com/packaging/build.html. Scallywag
does have some limitations currently, but I think the statement you quoted is
obsolete. I often have Scallywag deploy my packages, as does Jon Turney.
The caveat was mainly driven by the fact that 'it's only been tested by
me' :)
Yes, that was my source here. I experimented with Scallywag briefly,
but was put off by (a) that warning and (b) the fact that my first
builds failed because I apparently use the wrong quoting style in my
Cygport files. And, as I say, that I was already a significant way to
a working GitHub Action process.
The limitations I've bumped into are:
1. Scallywag will time out after an hour on each arch.
This is a killer for me. Getting this working with moreutils was a
simple proof-of-concept; the key package where this will likely save
me time and energy is Git, and the Git test suite takes multiple hours
to run on Cygwin. GitHub actions have a per-job limit of 6 hours, and
a per-workflow limit of 72 hours.
Yeah.
2. Several of my packages fail to build on x86 because of gcc crashes.
I think these limitations are outweighed by the fact that a Scallywag build is
automatically triggered by a push to an official source repo
(https://cygwin.com/packaging/repos.html). All maintainers can use this without
any special setup.
That's clearly incredibly valuable, yes. I'm hoping to reduce the
special setup using GitHub Actions requires, but it's clearly going to
require more than zero setup.
I'd rather not be replicating the tooling to do this into every package
repository.
All the AppVeyor builds that scallywag does are of the scallywag
repository itself, since the AppVeyor API lets me parameterize the build
(by the package repository and commit-id)
In a brief investigation, I didn't find anything similar for github actions.
Re: git repositories for cygwin packaging - please test
On 23/08/2020 22:01, Jon Turney wrote: On 27/05/2020 23:27, Jon Turney wrote: On 04/08/2019 21:08, Jon Turney wrote: To remedy this lack, using the same ssh key you use for sftp package upload, package maintainers can now also push to git repositories, like so: Package maintainers may have noticed that the output from pushing to these git repositories now includes a line like: "remote: scallywag: build nnn queued" This is a *prototype* of a system to automatically build the packages, where the results appear (some time later) at [1] (URL subject to change) [1] https://cygwin.com/cgi-bin2/jobs.cgi Currently, many packages will fail to build correctly due to: I now have built an (opt-in) system which fetches the packages built by this into your upload area and triggers calm to process them, which I'm looking for a volunteer to test. Since that seems to be working about as well as can be expected, I've bodged together something so maintainers can now opt themselves in (and out) of this, by uploading (or removing) a file called '!scallywag' containing 'deploy' in the root of their upload area. I've updated the brief documentation at [1] to mention this. [1] https://cygwin.com/packaging/build.html I'm still not crazy about using AppVeyor as the back-end for this, but unless someone wants to donate some compute resources... Currently, these packages are built using 'cygport all-test', and so will always be marked test:
Re: [PATCHES] cygport
On 20/02/2021 08:15, Achim Gratz wrote: Achim Gratz writes: I've rebased several of my patches that have been offered before (and a new one) on top of the current upstream and would like to see them picked up: https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream The first two are needed for building Perl and Perl distributions without manual intervention and/or editing of generated files. Yaakov, ping? Reminder, this branch sits on top of the URL-updates branch. Let me add a 'R-b' for "stop generating packages for obsoletions", which I almost wasted time writing again. For some time now, nobody can be successfully using version of setup which doesn't support 'obsoletes:'.
