pdfgrep [ITA]

pdfgrep [ITA]

[Jason Pyeron]

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.

v/r,

Jason Pyeron

--
Jason Pyeron  | Architect
PD Inc        |
10 w 24th St  |
Baltimore, MD |
 
.mil: jason.j.pyeron.ctr@mail.mil
.com: jpyeron@pdinc.us
tel : 202-741-9397

Re: pdfgrep [ITA]

[Achim Gratz]

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), check the patches for the
major Linux distros (if any, Fedora does not for instance) and make sure
it works on both 32bit and 64bit architecture and show the result.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

RE: pdfgrep [ITA]

[Jason Pyeron]

> -----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), check the patches for the
> major Linux distros (if any, Fedora does not for instance) and make sure
> it works on both 32bit and 64bit architecture and show the result.

Will do this weekend.

RE: pdfgrep [ITA]

[Jason Pyeron]

> -----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

Re: pdfgrep [ITA]

[Achim Gratz]

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]

[Marco Atzeri]

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]

[Marco Atzeri]

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]

[Jason Pyeron]

(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-filename            Print 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, --count                    Print 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 NUM            Stop reading after NUM matching lines (per file)
 -q, --quiet                    Suppress normal output
 -r, --recursive                Search directories recursively
 -R, --dereference-recursive    Likewise, 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

Re: pdfgrep [ITA]

[Marco Atzeri]

On 09.05.2021 23:12, Jason Pyeron wrote:
> (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
>

I tested only 2.1.2

Re: pdfgrep [ITA]

[Marco Atzeri]

On 10.05.2021 08:35, Marco Atzeri wrote:
> On 09.05.2021 23:12, Jason Pyeron wrote:
>>
> 
> I tested only 2.1.2

I suggest for the time being to deploy the pdfgrep-1.4.1-2

                 === pdfgrep Summary ===

# of expected passes            52
# of unexpected failures        4
# of expected failures          2

just add the BUILD_REQUIRES and it is fine for me.

I changed maintainership to you on
https://www.cygwin.com/cygwin-pkg-maint

please follow

https://cygwin.com/packaging/key.html#sshkey
https://cygwin.com/package-upload.html

Regards
Marco

RE: pdfgrep [ITA]

[Jason Pyeron]

> -----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)

Tracking upstream at: https://gitlab.com/pdfgrep/pdfgrep/-/issues/50

Bug introduced between v1.4.1 and v2.0 in commit 3eb727125f119e1fbc19ba67449838c3f91cd9f6
Author: Hans-Peter Deifel
Date:   Tue Jun 21 16:56:30 2016 +0200

    Set locale to user preferred one

    This enables some unicode awareness in regcomp/regexec if the user has
    set a UTF-8 loacle.


Specifically the change was the addition of:

   locale::global(locale(""));

Re: pdfgrep [ITA]

[Marco Atzeri]

On 17.05.2021 07:00, Jason Pyeron wrote:
>> -----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)
> 
> Tracking upstream at: https://gitlab.com/pdfgrep/pdfgrep/-/issues/50
> 
> Bug introduced between v1.4.1 and v2.0 in commit 3eb727125f119e1fbc19ba67449838c3f91cd9f6
> Author: Hans-Peter Deifel
> Date:   Tue Jun 21 16:56:30 2016 +0200
> 
>      Set locale to user preferred one
> 
>      This enables some unicode awareness in regcomp/regexec if the user has
>      set a UTF-8 loacle.
> 
> 
> Specifically the change was the addition of:
> 
>     locale::global(locale(""));
> 
also the simple example on
https://en.cppreference.com/w/cpp/locale/locale


$ cat test-locale.cpp
#include <iostream>
#include <locale>

int main()
{
     std::wcout << "User-preferred locale setting is " << 
std::locale("").name().c_str() << '\n';
     // on startup, the global locale is the "C" locale
     std::wcout << 1000.01 << '\n';
     // replace the C++ global locale as well as the C locale with the 
user-preferred locale
     std::locale::global(std::locale(""));
     // use the new global locale for future wide character output
     std::wcout.imbue(std::locale());
     // output the same number again
     std::wcout << 1000.01 << '\n';
}


  ./test-locale.exe
terminate called after throwing an instance of 'std::runtime_error'
   what():  locale::facet::_S_create_c_locale name not valid
Aborted (core dumped)


so or the standard is changed or Cygwin implementation has an issue

Regards
Marco

RE: pdfgrep [ITA]

[Jason Pyeron]

> -----Original Message-----
> From: Marco Atzeri
> Sent: Sunday, May 9, 2021 3:55 PM
> 
<snip/>
> 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
> 
> 

I am assuming that I should not include cygport in the build requires. These are the packages I install to build:

asciidoc gcc-g++ libpoppler-cpp-devel libgcrypt-devel libpcre-devel dejagnu texlive-collection-latex

cygport

-Jason

Re: pdfgrep [ITA]

[Marco Atzeri]

On 17.05.2021 21:59, Jason Pyeron wrote:
>> -----Original Message-----
>> From: Marco Atzeri
>> Sent: Sunday, May 9, 2021 3:55 PM
>>
> <snip/>
>> 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
>>
>>
> 
> I am assuming that I should not include cygport in the build requires. These are the packages I install to build:
> 
> asciidoc gcc-g++ libpoppler-cpp-devel libgcrypt-devel libpcre-devel dejagnu texlive-collection-latex
> 
> cygport
> 
> -Jason
> 

I am almost sure that also gcc-g++ is assumed to be present

Dejagnu pulls tcl, so that is covered:


$ cygcheck-dep -S -q -R dejagnu
  dejagnu: recursively requires ( bash coreutils cygwin expect libattr1 
libgmp10 libiconv2 libintl8 libncursesw10 libreadline7 sed tcl terminfo 
terminfo-extra tzcode tzdata zlib0 )

Re: pdfgrep [ITA]

[Achim Gratz]

Jason Pyeron writes:
> I am assuming that I should not include cygport in the build
> requires.

Yes, we currently assume cygport and its transitive dependencies to be
available for a cygport based package.  The build requires should enable
the CI to build the package correctly.


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: pdfgrep [ITA]

[Jason Pyeron]

> -----Original Message-----
> From: Achim Gratz
> Sent: Tuesday, May 18, 2021 1:13 PM
> 
> Jason Pyeron writes:
> > I am assuming that I should not include cygport in the build
> > requires.
> 
> Yes, we currently assume cygport and its transitive dependencies to be
> available for a cygport based package.  The build requires should enable
> the CI to build the package correctly.

Yeah, doing the CI thing here right now. Been having fun getting Jenkins to use multibranch to build both x64 and x86 in the one pipeline.

  stage("32bit")
  {
    // "." needs to be in the user's path env var for this hack...
    dir("c:\\cygwin.jenkins\\bin\\")
    {
      //replace nohup with the correct cygwin home's version
      bat """
ln -vf nohup.exe c:/Users/jenkins/
"""
      //Jenkins does a nohup sh -xe ..., 
      sh '''
. /etc/profile
export TMP="$(cygpath -ua "${WORKSPACE_TMP}")"
export TEMP="${TMP}"
cd "$(cygpath -ua "${WORKSPACE}")"
#now goes your script...