[VOTE] Release Apache Commons Daemon 1.2.2 RC1

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Release Apache Commons Daemon 1.2.2 RC1

Mark Thomas
A further regression has been identified in the 1.2.0/1.2.1 releases so
I'd like to get 1.2.2 released to address it. So, time for another
release vote.

Notable changes since 1.2.1 include:
- Correct a regression (DAEMON-408) that caused Windows services to
  crash on start-up when the universal C runtime was not available

The full set of changes is in the changelog

1.2.2 RC1 can be obtained from (r36024)
https://dist.apache.org/repos/dist/dev/commons/daemon/

The git tag is:
Tag: COMMONS_DAEMON_1_2_2_RC1
URL:
https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=cb6754d51a008418ed93e29cde141f046766fee3
Hash:  cb6754d51a008418ed93e29cde141f046766fee3

The Maven Staging repo is:
https://repository.apache.org/content/repositories/orgapachecommons-1471/

The Windows binaries have been signed by the DigiCert (formerly
Symantec) code signing service.

Files signed with my preferred key:
http://people.apache.org/~markt/
KEYS file is standard Apache Commons keys file:
http://www.apache.org/dist/commons/KEYS


[ ] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2
[ ] Broken   - do not release because...

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

Mark Thomas
On 25/09/2019 15:57, Mark Thomas wrote:

<snip/>

> [X] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2

Tested a Tomcat 9.0.26 install that failed to start with 1.2.1 and it
starts cleanly with 1.2.2

Also double-checked that the configure script was in place.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

Rob Tompkins
In reply to this post by Mark Thomas
I could build the unix binaries with the directions in the project. The java builds with 8 and 11. The signatures look correct, and all the reports look good.

+1

@Mark - if you do more than this for validating the release could you include it either in the project or in the [VOTE] email?

> On Sep 25, 2019, at 10:57 AM, Mark Thomas <[hidden email]> wrote:
>
> A further regression has been identified in the 1.2.0/1.2.1 releases so
> I'd like to get 1.2.2 released to address it. So, time for another
> release vote.
>
> Notable changes since 1.2.1 include:
> - Correct a regression (DAEMON-408) that caused Windows services to
>  crash on start-up when the universal C runtime was not available
>
> The full set of changes is in the changelog
>
> 1.2.2 RC1 can be obtained from (r36024)
> https://dist.apache.org/repos/dist/dev/commons/daemon/
>
> The git tag is:
> Tag: COMMONS_DAEMON_1_2_2_RC1
> URL:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=cb6754d51a008418ed93e29cde141f046766fee3
> Hash:  cb6754d51a008418ed93e29cde141f046766fee3
>
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1471/
>
> The Windows binaries have been signed by the DigiCert (formerly
> Symantec) code signing service.
>
> Files signed with my preferred key:
> http://people.apache.org/~markt/
> KEYS file is standard Apache Commons keys file:
> http://www.apache.org/dist/commons/KEYS
>
>
> [ ] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2
> [ ] Broken   - do not release because...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

Rob Tompkins
In reply to this post by Mark Thomas
Hello all - could we get more votes here as we’re coming in on that 72 hour point in the vote.

Cheers,
-Rob

> On Sep 25, 2019, at 10:57 AM, Mark Thomas <[hidden email]> wrote:
>
> A further regression has been identified in the 1.2.0/1.2.1 releases so
> I'd like to get 1.2.2 released to address it. So, time for another
> release vote.
>
> Notable changes since 1.2.1 include:
> - Correct a regression (DAEMON-408) that caused Windows services to
>  crash on start-up when the universal C runtime was not available
>
> The full set of changes is in the changelog
>
> 1.2.2 RC1 can be obtained from (r36024)
> https://dist.apache.org/repos/dist/dev/commons/daemon/
>
> The git tag is:
> Tag: COMMONS_DAEMON_1_2_2_RC1
> URL:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=cb6754d51a008418ed93e29cde141f046766fee3
> Hash:  cb6754d51a008418ed93e29cde141f046766fee3
>
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1471/
>
> The Windows binaries have been signed by the DigiCert (formerly
> Symantec) code signing service.
>
> Files signed with my preferred key:
> http://people.apache.org/~markt/
> KEYS file is standard Apache Commons keys file:
> http://www.apache.org/dist/commons/KEYS
>
>
> [ ] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2
> [ ] Broken   - do not release because...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

garydgregory
In reply to this post by Mark Thomas
It seems we provide too much in the src zip file like exe and obj files.
Also old pdb files because I get:

.\..\..\src\cmdline.c: fatal error C1051: program database file,
'C:\temp\rc\commons-daemon-1.2.2-src\src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE\prunsrv-src.pdb',
has an obsolete format, delete it and recompile
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\HostX86\x86\cl.EXE"' :
return code '0x2'

Since we do not provide class files and jars in the src zip, why should we
provide pdb, objs and exes in these all caps folders?

It seems we should NOT deliver the following folders in the src zip which
now contain objs and exes:

src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE

WDYT?

Gary


On Wed, Sep 25, 2019 at 10:57 AM Mark Thomas <[hidden email]> wrote:

> A further regression has been identified in the 1.2.0/1.2.1 releases so
> I'd like to get 1.2.2 released to address it. So, time for another
> release vote.
>
> Notable changes since 1.2.1 include:
> - Correct a regression (DAEMON-408) that caused Windows services to
>   crash on start-up when the universal C runtime was not available
>
> The full set of changes is in the changelog
>
> 1.2.2 RC1 can be obtained from (r36024)
> https://dist.apache.org/repos/dist/dev/commons/daemon/
>
> The git tag is:
> Tag: COMMONS_DAEMON_1_2_2_RC1
> URL:
>
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=cb6754d51a008418ed93e29cde141f046766fee3
> Hash:  cb6754d51a008418ed93e29cde141f046766fee3
>
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1471/
>
> The Windows binaries have been signed by the DigiCert (formerly
> Symantec) code signing service.
>
> Files signed with my preferred key:
> http://people.apache.org/~markt/
> KEYS file is standard Apache Commons keys file:
> http://www.apache.org/dist/commons/KEYS
>
>
> [ ] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2
> [ ] Broken   - do not release because...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

sebb-2-2
On Sat, 28 Sep 2019 at 13:39, Gary Gregory <[hidden email]> wrote:

>
> It seems we provide too much in the src zip file like exe and obj files.
> Also old pdb files because I get:
>
> .\..\..\src\cmdline.c: fatal error C1051: program database file,
> 'C:\temp\rc\commons-daemon-1.2.2-src\src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE\prunsrv-src.pdb',
> has an obsolete format, delete it and recompile
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\HostX86\x86\cl.EXE"' :
> return code '0x2'
>
> Since we do not provide class files and jars in the src zip, why should we
> provide pdb, objs and exes in these all caps folders?
>
> It seems we should NOT deliver the following folders in the src zip which
> now contain objs and exes:
>
> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>
> WDYT?

Looks like the build created the files in the wrong directories?

The src zip also contains:
src/native/unix/configure
AIUI this is a generated file; I would expect it to be in the binary
artifact, if anywhere

Also there are some Git files missing from the src zip.
Not sure if that is intentional?

CONTRIBUTING.md
HOWTO-RELEASE.txt
README.md


> Gary
>
>
> On Wed, Sep 25, 2019 at 10:57 AM Mark Thomas <[hidden email]> wrote:
>
> > A further regression has been identified in the 1.2.0/1.2.1 releases so
> > I'd like to get 1.2.2 released to address it. So, time for another
> > release vote.
> >
> > Notable changes since 1.2.1 include:
> > - Correct a regression (DAEMON-408) that caused Windows services to
> >   crash on start-up when the universal C runtime was not available
> >
> > The full set of changes is in the changelog
> >
> > 1.2.2 RC1 can be obtained from (r36024)
> > https://dist.apache.org/repos/dist/dev/commons/daemon/
> >
> > The git tag is:
> > Tag: COMMONS_DAEMON_1_2_2_RC1
> > URL:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=cb6754d51a008418ed93e29cde141f046766fee3
> > Hash:  cb6754d51a008418ed93e29cde141f046766fee3
> >
> > The Maven Staging repo is:
> > https://repository.apache.org/content/repositories/orgapachecommons-1471/
> >
> > The Windows binaries have been signed by the DigiCert (formerly
> > Symantec) code signing service.
> >
> > Files signed with my preferred key:
> > http://people.apache.org/~markt/
> > KEYS file is standard Apache Commons keys file:
> > http://www.apache.org/dist/commons/KEYS
> >
> >
> > [ ] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2
> > [ ] Broken   - do not release because...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

garydgregory
On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:

> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <[hidden email]> wrote:
> >
> > It seems we provide too much in the src zip file like exe and obj files.
> > Also old pdb files because I get:
> >
> > .\..\..\src\cmdline.c: fatal error C1051: program database file,
> >
> 'C:\temp\rc\commons-daemon-1.2.2-src\src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE\prunsrv-src.pdb',
> > has an obsolete format, delete it and recompile
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\HostX86\x86\cl.EXE"'
> :
> > return code '0x2'
> >
> > Since we do not provide class files and jars in the src zip, why should
> we
> > provide pdb, objs and exes in these all caps folders?
> >
> > It seems we should NOT deliver the following folders in the src zip which
> > now contain objs and exes:
> >
> > src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> >
> > WDYT?
>
> Looks like the build created the files in the wrong directories?
>
> The src zip also contains:
> src/native/unix/configure
> AIUI this is a generated file; I would expect it to be in the binary
> artifact, if anywhere
>
> Also there are some Git files missing from the src zip.
> Not sure if that is intentional?
>
> CONTRIBUTING.md
> HOWTO-RELEASE.txt
> README.md
>

I certainly would expect CONTRIBUTING.md and README.md to be in the src
zip, not quite a blocker for me. I am more concerned that we are including
all of these OBJ and EXE files.

Gary

>
>
> > Gary
> >
> >
> > On Wed, Sep 25, 2019 at 10:57 AM Mark Thomas <[hidden email]> wrote:
> >
> > > A further regression has been identified in the 1.2.0/1.2.1 releases so
> > > I'd like to get 1.2.2 released to address it. So, time for another
> > > release vote.
> > >
> > > Notable changes since 1.2.1 include:
> > > - Correct a regression (DAEMON-408) that caused Windows services to
> > >   crash on start-up when the universal C runtime was not available
> > >
> > > The full set of changes is in the changelog
> > >
> > > 1.2.2 RC1 can be obtained from (r36024)
> > > https://dist.apache.org/repos/dist/dev/commons/daemon/
> > >
> > > The git tag is:
> > > Tag: COMMONS_DAEMON_1_2_2_RC1
> > > URL:
> > >
> > >
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=cb6754d51a008418ed93e29cde141f046766fee3
> > > Hash:  cb6754d51a008418ed93e29cde141f046766fee3
> > >
> > > The Maven Staging repo is:
> > >
> https://repository.apache.org/content/repositories/orgapachecommons-1471/
> > >
> > > The Windows binaries have been signed by the DigiCert (formerly
> > > Symantec) code signing service.
> > >
> > > Files signed with my preferred key:
> > > http://people.apache.org/~markt/
> > > KEYS file is standard Apache Commons keys file:
> > > http://www.apache.org/dist/commons/KEYS
> > >
> > >
> > > [ ] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2
> > > [ ] Broken   - do not release because...
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

garydgregory
I can confirm that if I delete all of:

src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE

I can build without errors but with warnings:

.\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': This
function or variable may be unsafe. Consider using _wfopen_s instead. To
disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
details.
C:\Program Files (x86)\Windows
Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
declaration of '_wfopen'
.\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': This
function or variable may be unsafe. Consider using _wfopen_s instead. To
disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
details.
C:\Program Files (x86)\Windows
Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
declaration of '_wfopen'
.\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': This
function or variable may be unsafe. Consider using _snprintf_s instead. To
disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
details.
C:\Program Files (x86)\Windows
Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
'_snprintf'
.\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': This
function or variable may be unsafe. Consider using _snprintf_s instead. To
disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
details.
C:\Program Files (x86)\Windows
Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
'_snprintf'
        rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc

Gary



On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <[hidden email]>
wrote:

> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:
>
>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <[hidden email]>
>> wrote:
>> >
>> > It seems we provide too much in the src zip file like exe and obj files.
>> > Also old pdb files because I get:
>> >
>> > .\..\..\src\cmdline.c: fatal error C1051: program database file,
>> >
>> 'C:\temp\rc\commons-daemon-1.2.2-src\src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE\prunsrv-src.pdb',
>> > has an obsolete format, delete it and recompile
>> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> >
>> Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\HostX86\x86\cl.EXE"' :
>> > return code '0x2'
>> >
>> > Since we do not provide class files and jars in the src zip, why should
>> we
>> > provide pdb, objs and exes in these all caps folders?
>> >
>> > It seems we should NOT deliver the following folders in the src zip
>> which
>> > now contain objs and exes:
>> >
>> > src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
>> > src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
>> > src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>> >
>> > WDYT?
>>
>> Looks like the build created the files in the wrong directories?
>>
>> The src zip also contains:
>> src/native/unix/configure
>> AIUI this is a generated file; I would expect it to be in the binary
>> artifact, if anywhere
>>
>> Also there are some Git files missing from the src zip.
>> Not sure if that is intentional?
>>
>> CONTRIBUTING.md
>> HOWTO-RELEASE.txt
>> README.md
>>
>
> I certainly would expect CONTRIBUTING.md and README.md to be in the src
> zip, not quite a blocker for me. I am more concerned that we are including
> all of these OBJ and EXE files.
>
> Gary
>
>>
>>
>> > Gary
>> >
>> >
>> > On Wed, Sep 25, 2019 at 10:57 AM Mark Thomas <[hidden email]> wrote:
>> >
>> > > A further regression has been identified in the 1.2.0/1.2.1 releases
>> so
>> > > I'd like to get 1.2.2 released to address it. So, time for another
>> > > release vote.
>> > >
>> > > Notable changes since 1.2.1 include:
>> > > - Correct a regression (DAEMON-408) that caused Windows services to
>> > >   crash on start-up when the universal C runtime was not available
>> > >
>> > > The full set of changes is in the changelog
>> > >
>> > > 1.2.2 RC1 can be obtained from (r36024)
>> > > https://dist.apache.org/repos/dist/dev/commons/daemon/
>> > >
>> > > The git tag is:
>> > > Tag: COMMONS_DAEMON_1_2_2_RC1
>> > > URL:
>> > >
>> > >
>> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=cb6754d51a008418ed93e29cde141f046766fee3
>> > > Hash:  cb6754d51a008418ed93e29cde141f046766fee3
>> > >
>> > > The Maven Staging repo is:
>> > >
>> https://repository.apache.org/content/repositories/orgapachecommons-1471/
>> > >
>> > > The Windows binaries have been signed by the DigiCert (formerly
>> > > Symantec) code signing service.
>> > >
>> > > Files signed with my preferred key:
>> > > http://people.apache.org/~markt/
>> > > KEYS file is standard Apache Commons keys file:
>> > > http://www.apache.org/dist/commons/KEYS
>> > >
>> > >
>> > > [ ] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2
>> > > [ ] Broken   - do not release because...
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

garydgregory
On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <[hidden email]>
wrote:

> I can confirm that if I delete all of:
>
> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>
> I can build without errors but with warnings:
>
> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': This
> function or variable may be unsafe. Consider using _wfopen_s instead. To
> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> details.
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> declaration of '_wfopen'
> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': This
> function or variable may be unsafe. Consider using _wfopen_s instead. To
> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> details.
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> declaration of '_wfopen'
> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': This
> function or variable may be unsafe. Consider using _snprintf_s instead. To
> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> details.
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
> '_snprintf'
> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': This
> function or variable may be unsafe. Consider using _snprintf_s instead. To
> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> details.
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
> '_snprintf'
>         rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
>

FWIW, using:

Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

Gary


>
> Gary
>
>
>
> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <[hidden email]>
> wrote:
>
>> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:
>>
>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <[hidden email]>
>>> wrote:
>>> >
>>> > It seems we provide too much in the src zip file like exe and obj
>>> files.
>>> > Also old pdb files because I get:
>>> >
>>> > .\..\..\src\cmdline.c: fatal error C1051: program database file,
>>> >
>>> 'C:\temp\rc\commons-daemon-1.2.2-src\src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE\prunsrv-src.pdb',
>>> > has an obsolete format, delete it and recompile
>>> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>> >
>>> Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\HostX86\x86\cl.EXE"' :
>>> > return code '0x2'
>>> >
>>> > Since we do not provide class files and jars in the src zip, why
>>> should we
>>> > provide pdb, objs and exes in these all caps folders?
>>> >
>>> > It seems we should NOT deliver the following folders in the src zip
>>> which
>>> > now contain objs and exes:
>>> >
>>> > src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
>>> > src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
>>> > src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>>> >
>>> > WDYT?
>>>
>>> Looks like the build created the files in the wrong directories?
>>>
>>> The src zip also contains:
>>> src/native/unix/configure
>>> AIUI this is a generated file; I would expect it to be in the binary
>>> artifact, if anywhere
>>>
>>> Also there are some Git files missing from the src zip.
>>> Not sure if that is intentional?
>>>
>>> CONTRIBUTING.md
>>> HOWTO-RELEASE.txt
>>> README.md
>>>
>>
>> I certainly would expect CONTRIBUTING.md and README.md to be in the src
>> zip, not quite a blocker for me. I am more concerned that we are including
>> all of these OBJ and EXE files.
>>
>> Gary
>>
>>>
>>>
>>> > Gary
>>> >
>>> >
>>> > On Wed, Sep 25, 2019 at 10:57 AM Mark Thomas <[hidden email]> wrote:
>>> >
>>> > > A further regression has been identified in the 1.2.0/1.2.1 releases
>>> so
>>> > > I'd like to get 1.2.2 released to address it. So, time for another
>>> > > release vote.
>>> > >
>>> > > Notable changes since 1.2.1 include:
>>> > > - Correct a regression (DAEMON-408) that caused Windows services to
>>> > >   crash on start-up when the universal C runtime was not available
>>> > >
>>> > > The full set of changes is in the changelog
>>> > >
>>> > > 1.2.2 RC1 can be obtained from (r36024)
>>> > > https://dist.apache.org/repos/dist/dev/commons/daemon/
>>> > >
>>> > > The git tag is:
>>> > > Tag: COMMONS_DAEMON_1_2_2_RC1
>>> > > URL:
>>> > >
>>> > >
>>> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=cb6754d51a008418ed93e29cde141f046766fee3
>>> > > Hash:  cb6754d51a008418ed93e29cde141f046766fee3
>>> > >
>>> > > The Maven Staging repo is:
>>> > >
>>> https://repository.apache.org/content/repositories/orgapachecommons-1471/
>>> > >
>>> > > The Windows binaries have been signed by the DigiCert (formerly
>>> > > Symantec) code signing service.
>>> > >
>>> > > Files signed with my preferred key:
>>> > > http://people.apache.org/~markt/
>>> > > KEYS file is standard Apache Commons keys file:
>>> > > http://www.apache.org/dist/commons/KEYS
>>> > >
>>> > >
>>> > > [ ] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2
>>> > > [ ] Broken   - do not release because...
>>> > >
>>> > > ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: [hidden email]
>>> > > For additional commands, e-mail: [hidden email]
>>> > >
>>> > >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

Mark Thomas
On 28/09/2019 17:06, Gary Gregory wrote:

> On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <[hidden email]>
> wrote:
>
>> I can confirm that if I delete all of:
>>
>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>>
>> I can build without errors but with warnings:
>>
>> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': This
>> function or variable may be unsafe. Consider using _wfopen_s instead. To
>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>> details.
>> C:\Program Files (x86)\Windows
>> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
>> declaration of '_wfopen'
>> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': This
>> function or variable may be unsafe. Consider using _wfopen_s instead. To
>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>> details.
>> C:\Program Files (x86)\Windows
>> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
>> declaration of '_wfopen'
>> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': This
>> function or variable may be unsafe. Consider using _snprintf_s instead. To
>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>> details.
>> C:\Program Files (x86)\Windows
>> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
>> '_snprintf'
>> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': This
>> function or variable may be unsafe. Consider using _snprintf_s instead. To
>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>> details.
>> C:\Program Files (x86)\Windows
>> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
>> '_snprintf'
>>         rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
>> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
>>
>
> FWIW, using:
>
> Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86
> Copyright (C) Microsoft Corporation.  All rights reserved.

Since I am going to re-tag for an RC2 (see below) I'll see what I can do
to clean up those warnings.

>> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <[hidden email]>
>> wrote:
>>> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:
>>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <[hidden email]>
>>>> wrote:

<snip/>

>>>>> It seems we should NOT deliver the following folders in the src zip
>>>> which
>>>>> now contain objs and exes:
>>>>>
>>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
>>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
>>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>>>>>
>>>>> WDYT?
>>>>
>>>> Looks like the build created the files in the wrong directories?

They should not be present in the source zip. I normally build the
binaries from the same tag but in a completely different checkout to
avoid this sort of thing. I'll see if I can figure out what I did wrong
but regardless of whether I can or not, I'll cancel this release, update
the estimated release date, re-tag and start an RC2 vote.

I'll also take a brief look at whether I can exclude those directories
explicitly from the source build to avoid this issue in future although
my Maven foo may not be up to that.


>>>> The src zip also contains:
>>>> src/native/unix/configure
>>>> AIUI this is a generated file; I would expect it to be in the binary
>>>> artifact, if anywhere

No. The configure script is generated but it *is* meant to be in the
source distribution. Without it, building from source is more difficult.
I forgot this for the 1.2.0 release and there were complaints as a result.

>>>> Also there are some Git files missing from the src zip.
>>>> Not sure if that is intentional?
>>>>
>>>> CONTRIBUTING.md
>>>> HOWTO-RELEASE.txt
>>>> README.md
>>>>
>>>
>>> I certainly would expect CONTRIBUTING.md and README.md to be in the src
>>> zip, not quite a blocker for me. I am more concerned that we are including
>>> all of these OBJ and EXE files.

The .md files are generated but I agree they should be in the source
distribution. I'll see about getting them added.

The HOWTO_RELEASE.txt is perhaps more debatable but on balance I think
it should be there too.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

sebb-2-2
On Sat, 28 Sep 2019 at 17:42, Mark Thomas <[hidden email]> wrote:

>
> On 28/09/2019 17:06, Gary Gregory wrote:
> > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <[hidden email]>
> > wrote:
> >
> >> I can confirm that if I delete all of:
> >>
> >> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> >> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> >> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> >>
> >> I can build without errors but with warnings:
> >>
> >> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': This
> >> function or variable may be unsafe. Consider using _wfopen_s instead. To
> >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> >> details.
> >> C:\Program Files (x86)\Windows
> >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> >> declaration of '_wfopen'
> >> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': This
> >> function or variable may be unsafe. Consider using _wfopen_s instead. To
> >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> >> details.
> >> C:\Program Files (x86)\Windows
> >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> >> declaration of '_wfopen'
> >> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': This
> >> function or variable may be unsafe. Consider using _snprintf_s instead. To
> >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> >> details.
> >> C:\Program Files (x86)\Windows
> >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
> >> '_snprintf'
> >> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': This
> >> function or variable may be unsafe. Consider using _snprintf_s instead. To
> >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> >> details.
> >> C:\Program Files (x86)\Windows
> >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
> >> '_snprintf'
> >>         rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
> >> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
> >>
> >
> > FWIW, using:
> >
> > Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86
> > Copyright (C) Microsoft Corporation.  All rights reserved.
>
> Since I am going to re-tag for an RC2 (see below) I'll see what I can do
> to clean up those warnings.
>
> >> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <[hidden email]>
> >> wrote:
> >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:
> >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <[hidden email]>
> >>>> wrote:
>
> <snip/>
>
> >>>>> It seems we should NOT deliver the following folders in the src zip
> >>>> which
> >>>>> now contain objs and exes:
> >>>>>
> >>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> >>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> >>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> >>>>>
> >>>>> WDYT?
> >>>>
> >>>> Looks like the build created the files in the wrong directories?
>
> They should not be present in the source zip. I normally build the
> binaries from the same tag but in a completely different checkout to
> avoid this sort of thing. I'll see if I can figure out what I did wrong
> but regardless of whether I can or not, I'll cancel this release, update
> the estimated release date, re-tag and start an RC2 vote.
>
> I'll also take a brief look at whether I can exclude those directories
> explicitly from the source build to avoid this issue in future although
> my Maven foo may not be up to that.
>

Why not create them in a different output directory under target?

> >>>> The src zip also contains:
> >>>> src/native/unix/configure
> >>>> AIUI this is a generated file; I would expect it to be in the binary
> >>>> artifact, if anywhere
>
> No. The configure script is generated but it *is* meant to be in the
> source distribution. Without it, building from source is more difficult.
> I forgot this for the 1.2.0 release and there were complaints as a result.

Is the config file OS and version  independent?
If not, then it might be confusing.

Why is it not in the Git repo?

> >>>> Also there are some Git files missing from the src zip.
> >>>> Not sure if that is intentional?
> >>>>
> >>>> CONTRIBUTING.md
> >>>> HOWTO-RELEASE.txt
> >>>> README.md
> >>>>
> >>>
> >>> I certainly would expect CONTRIBUTING.md and README.md to be in the src
> >>> zip, not quite a blocker for me. I am more concerned that we are including
> >>> all of these OBJ and EXE files.
>
> The .md files are generated but I agree they should be in the source
> distribution. I'll see about getting them added.
>
> The HOWTO_RELEASE.txt is perhaps more debatable but on balance I think
> it should be there too.

Does no harm, and makes it easier to compare source tag with source bundle.

> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

Matt Sicker
Projects that have a configure script usually include that in the source
distribution but not in the source repository (at least for autotools
users).

On Sat, Sep 28, 2019 at 17:41, sebb <[hidden email]> wrote:

> On Sat, 28 Sep 2019 at 17:42, Mark Thomas <[hidden email]> wrote:
> >
> > On 28/09/2019 17:06, Gary Gregory wrote:
> > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <[hidden email]>
> > > wrote:
> > >
> > >> I can confirm that if I delete all of:
> > >>
> > >> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > >> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > >> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > >>
> > >> I can build without errors but with warnings:
> > >>
> > >> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': This
> > >> function or variable may be unsafe. Consider using _wfopen_s instead.
> To
> > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> > >> details.
> > >> C:\Program Files (x86)\Windows
> > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> > >> declaration of '_wfopen'
> > >> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': This
> > >> function or variable may be unsafe. Consider using _wfopen_s instead.
> To
> > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> > >> details.
> > >> C:\Program Files (x86)\Windows
> > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> > >> declaration of '_wfopen'
> > >> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': This
> > >> function or variable may be unsafe. Consider using _snprintf_s
> instead. To
> > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> > >> details.
> > >> C:\Program Files (x86)\Windows
> > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> declaration of
> > >> '_snprintf'
> > >> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': This
> > >> function or variable may be unsafe. Consider using _snprintf_s
> instead. To
> > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> > >> details.
> > >> C:\Program Files (x86)\Windows
> > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> declaration of
> > >> '_snprintf'
> > >>         rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
> > >> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
> > >>
> > >
> > > FWIW, using:
> > >
> > > Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86
> > > Copyright (C) Microsoft Corporation.  All rights reserved.
> >
> > Since I am going to re-tag for an RC2 (see below) I'll see what I can do
> > to clean up those warnings.
> >
> > >> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <[hidden email]
> >
> > >> wrote:
> > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:
> > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <[hidden email]>
> > >>>> wrote:
> >
> > <snip/>
> >
> > >>>>> It seems we should NOT deliver the following folders in the src zip
> > >>>> which
> > >>>>> now contain objs and exes:
> > >>>>>
> > >>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > >>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > >>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > >>>>>
> > >>>>> WDYT?
> > >>>>
> > >>>> Looks like the build created the files in the wrong directories?
> >
> > They should not be present in the source zip. I normally build the
> > binaries from the same tag but in a completely different checkout to
> > avoid this sort of thing. I'll see if I can figure out what I did wrong
> > but regardless of whether I can or not, I'll cancel this release, update
> > the estimated release date, re-tag and start an RC2 vote.
> >
> > I'll also take a brief look at whether I can exclude those directories
> > explicitly from the source build to avoid this issue in future although
> > my Maven foo may not be up to that.
> >
>
> Why not create them in a different output directory under target?
>
> > >>>> The src zip also contains:
> > >>>> src/native/unix/configure
> > >>>> AIUI this is a generated file; I would expect it to be in the binary
> > >>>> artifact, if anywhere
> >
> > No. The configure script is generated but it *is* meant to be in the
> > source distribution. Without it, building from source is more difficult.
> > I forgot this for the 1.2.0 release and there were complaints as a
> result.
>
> Is the config file OS and version  independent?
> If not, then it might be confusing.
>
> Why is it not in the Git repo?
>
> > >>>> Also there are some Git files missing from the src zip.
> > >>>> Not sure if that is intentional?
> > >>>>
> > >>>> CONTRIBUTING.md
> > >>>> HOWTO-RELEASE.txt
> > >>>> README.md
> > >>>>
> > >>>
> > >>> I certainly would expect CONTRIBUTING.md and README.md to be in the
> src
> > >>> zip, not quite a blocker for me. I am more concerned that we are
> including
> > >>> all of these OBJ and EXE files.
> >
> > The .md files are generated but I agree they should be in the source
> > distribution. I'll see about getting them added.
> >
> > The HOWTO_RELEASE.txt is perhaps more debatable but on balance I think
> > it should be there too.
>
> Does no harm, and makes it easier to compare source tag with source bundle.
>
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

sebb-2-2
On Sun, 29 Sep 2019 at 17:21, Matt Sicker <[hidden email]> wrote:
>
> Projects that have a configure script usually include that in the source
> distribution but not in the source repository (at least for autotools
> users).

But is that correct?

Surely the source archive should only contain source that is in the source repo?

Provenance of source is vital: i.e. each file can be found in SVN/Git.

> On Sat, Sep 28, 2019 at 17:41, sebb <[hidden email]> wrote:
>
> > On Sat, 28 Sep 2019 at 17:42, Mark Thomas <[hidden email]> wrote:
> > >
> > > On 28/09/2019 17:06, Gary Gregory wrote:
> > > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <[hidden email]>
> > > > wrote:
> > > >
> > > >> I can confirm that if I delete all of:
> > > >>
> > > >> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > > >> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > > >> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > > >>
> > > >> I can build without errors but with warnings:
> > > >>
> > > >> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': This
> > > >> function or variable may be unsafe. Consider using _wfopen_s instead.
> > To
> > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> > > >> details.
> > > >> C:\Program Files (x86)\Windows
> > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> > > >> declaration of '_wfopen'
> > > >> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': This
> > > >> function or variable may be unsafe. Consider using _wfopen_s instead.
> > To
> > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> > > >> details.
> > > >> C:\Program Files (x86)\Windows
> > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> > > >> declaration of '_wfopen'
> > > >> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': This
> > > >> function or variable may be unsafe. Consider using _snprintf_s
> > instead. To
> > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> > > >> details.
> > > >> C:\Program Files (x86)\Windows
> > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> > declaration of
> > > >> '_snprintf'
> > > >> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': This
> > > >> function or variable may be unsafe. Consider using _snprintf_s
> > instead. To
> > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
> > > >> details.
> > > >> C:\Program Files (x86)\Windows
> > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> > declaration of
> > > >> '_snprintf'
> > > >>         rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
> > > >> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
> > > >>
> > > >
> > > > FWIW, using:
> > > >
> > > > Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86
> > > > Copyright (C) Microsoft Corporation.  All rights reserved.
> > >
> > > Since I am going to re-tag for an RC2 (see below) I'll see what I can do
> > > to clean up those warnings.
> > >
> > > >> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <[hidden email]
> > >
> > > >> wrote:
> > > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:
> > > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <[hidden email]>
> > > >>>> wrote:
> > >
> > > <snip/>
> > >
> > > >>>>> It seems we should NOT deliver the following folders in the src zip
> > > >>>> which
> > > >>>>> now contain objs and exes:
> > > >>>>>
> > > >>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > > >>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > > >>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > > >>>>>
> > > >>>>> WDYT?
> > > >>>>
> > > >>>> Looks like the build created the files in the wrong directories?
> > >
> > > They should not be present in the source zip. I normally build the
> > > binaries from the same tag but in a completely different checkout to
> > > avoid this sort of thing. I'll see if I can figure out what I did wrong
> > > but regardless of whether I can or not, I'll cancel this release, update
> > > the estimated release date, re-tag and start an RC2 vote.
> > >
> > > I'll also take a brief look at whether I can exclude those directories
> > > explicitly from the source build to avoid this issue in future although
> > > my Maven foo may not be up to that.
> > >
> >
> > Why not create them in a different output directory under target?
> >
> > > >>>> The src zip also contains:
> > > >>>> src/native/unix/configure
> > > >>>> AIUI this is a generated file; I would expect it to be in the binary
> > > >>>> artifact, if anywhere
> > >
> > > No. The configure script is generated but it *is* meant to be in the
> > > source distribution. Without it, building from source is more difficult.
> > > I forgot this for the 1.2.0 release and there were complaints as a
> > result.
> >
> > Is the config file OS and version  independent?
> > If not, then it might be confusing.
> >
> > Why is it not in the Git repo?
> >
> > > >>>> Also there are some Git files missing from the src zip.
> > > >>>> Not sure if that is intentional?
> > > >>>>
> > > >>>> CONTRIBUTING.md
> > > >>>> HOWTO-RELEASE.txt
> > > >>>> README.md
> > > >>>>
> > > >>>
> > > >>> I certainly would expect CONTRIBUTING.md and README.md to be in the
> > src
> > > >>> zip, not quite a blocker for me. I am more concerned that we are
> > including
> > > >>> all of these OBJ and EXE files.
> > >
> > > The .md files are generated but I agree they should be in the source
> > > distribution. I'll see about getting them added.
> > >
> > > The HOWTO_RELEASE.txt is perhaps more debatable but on balance I think
> > > it should be there too.
> >
> > Does no harm, and makes it easier to compare source tag with source bundle.
> >
> > > Mark
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
> Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

Matt Sicker
I’m sort of going off of what GNU projects do (they use autotools for any C
projects), but the common ‘./configure && make && sudo make install’
snippet is almost timeless.

On Sun, Sep 29, 2019 at 13:01, sebb <[hidden email]> wrote:

> On Sun, 29 Sep 2019 at 17:21, Matt Sicker <[hidden email]> wrote:
> >
> > Projects that have a configure script usually include that in the source
> > distribution but not in the source repository (at least for autotools
> > users).
>
> But is that correct?
>
> Surely the source archive should only contain source that is in the source
> repo?
>
> Provenance of source is vital: i.e. each file can be found in SVN/Git.
>
> > On Sat, Sep 28, 2019 at 17:41, sebb <[hidden email]> wrote:
> >
> > > On Sat, 28 Sep 2019 at 17:42, Mark Thomas <[hidden email]> wrote:
> > > >
> > > > On 28/09/2019 17:06, Gary Gregory wrote:
> > > > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <
> [hidden email]>
> > > > > wrote:
> > > > >
> > > > >> I can confirm that if I delete all of:
> > > > >>
> > > > >> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > > > >> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > > > >> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > > > >>
> > > > >> I can build without errors but with warnings:
> > > > >>
> > > > >> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen':
> This
> > > > >> function or variable may be unsafe. Consider using _wfopen_s
> instead.
> > > To
> > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
> for
> > > > >> details.
> > > > >> C:\Program Files (x86)\Windows
> > > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> > > > >> declaration of '_wfopen'
> > > > >> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen':
> This
> > > > >> function or variable may be unsafe. Consider using _wfopen_s
> instead.
> > > To
> > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
> for
> > > > >> details.
> > > > >> C:\Program Files (x86)\Windows
> > > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> > > > >> declaration of '_wfopen'
> > > > >> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf':
> This
> > > > >> function or variable may be unsafe. Consider using _snprintf_s
> > > instead. To
> > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
> for
> > > > >> details.
> > > > >> C:\Program Files (x86)\Windows
> > > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> > > declaration of
> > > > >> '_snprintf'
> > > > >> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf':
> This
> > > > >> function or variable may be unsafe. Consider using _snprintf_s
> > > instead. To
> > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
> for
> > > > >> details.
> > > > >> C:\Program Files (x86)\Windows
> > > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> > > declaration of
> > > > >> '_snprintf'
> > > > >>         rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
> > > > >> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
> > > > >>
> > > > >
> > > > > FWIW, using:
> > > > >
> > > > > Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for
> x86
> > > > > Copyright (C) Microsoft Corporation.  All rights reserved.
> > > >
> > > > Since I am going to re-tag for an RC2 (see below) I'll see what I
> can do
> > > > to clean up those warnings.
> > > >
> > > > >> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <
> [hidden email]
> > > >
> > > > >> wrote:
> > > > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:
> > > > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <
> [hidden email]>
> > > > >>>> wrote:
> > > >
> > > > <snip/>
> > > >
> > > > >>>>> It seems we should NOT deliver the following folders in the
> src zip
> > > > >>>> which
> > > > >>>>> now contain objs and exes:
> > > > >>>>>
> > > > >>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > > > >>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > > > >>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > > > >>>>>
> > > > >>>>> WDYT?
> > > > >>>>
> > > > >>>> Looks like the build created the files in the wrong directories?
> > > >
> > > > They should not be present in the source zip. I normally build the
> > > > binaries from the same tag but in a completely different checkout to
> > > > avoid this sort of thing. I'll see if I can figure out what I did
> wrong
> > > > but regardless of whether I can or not, I'll cancel this release,
> update
> > > > the estimated release date, re-tag and start an RC2 vote.
> > > >
> > > > I'll also take a brief look at whether I can exclude those
> directories
> > > > explicitly from the source build to avoid this issue in future
> although
> > > > my Maven foo may not be up to that.
> > > >
> > >
> > > Why not create them in a different output directory under target?
> > >
> > > > >>>> The src zip also contains:
> > > > >>>> src/native/unix/configure
> > > > >>>> AIUI this is a generated file; I would expect it to be in the
> binary
> > > > >>>> artifact, if anywhere
> > > >
> > > > No. The configure script is generated but it *is* meant to be in the
> > > > source distribution. Without it, building from source is more
> difficult.
> > > > I forgot this for the 1.2.0 release and there were complaints as a
> > > result.
> > >
> > > Is the config file OS and version  independent?
> > > If not, then it might be confusing.
> > >
> > > Why is it not in the Git repo?
> > >
> > > > >>>> Also there are some Git files missing from the src zip.
> > > > >>>> Not sure if that is intentional?
> > > > >>>>
> > > > >>>> CONTRIBUTING.md
> > > > >>>> HOWTO-RELEASE.txt
> > > > >>>> README.md
> > > > >>>>
> > > > >>>
> > > > >>> I certainly would expect CONTRIBUTING.md and README.md to be in
> the
> > > src
> > > > >>> zip, not quite a blocker for me. I am more concerned that we are
> > > including
> > > > >>> all of these OBJ and EXE files.
> > > >
> > > > The .md files are generated but I agree they should be in the source
> > > > distribution. I'll see about getting them added.
> > > >
> > > > The HOWTO_RELEASE.txt is perhaps more debatable but on balance I
> think
> > > > it should be there too.
> > >
> > > Does no harm, and makes it easier to compare source tag with source
> bundle.
> > >
> > > > Mark
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > > --
> > Matt Sicker <[hidden email]>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

sebb-2-2
On Sun, 29 Sep 2019 at 22:36, Matt Sicker <[hidden email]> wrote:
>
> I’m sort of going off of what GNU projects do (they use autotools for any C
> projects), but the common ‘./configure && make && sudo make install’
> snippet is almost timeless.

Not sure what that has to do with the question at hand, i.e

Is the file is allowed to be in the source artifact if it is not in
the source repository?

> On Sun, Sep 29, 2019 at 13:01, sebb <[hidden email]> wrote:
>
> > On Sun, 29 Sep 2019 at 17:21, Matt Sicker <[hidden email]> wrote:
> > >
> > > Projects that have a configure script usually include that in the source
> > > distribution but not in the source repository (at least for autotools
> > > users).
> >
> > But is that correct?
> >
> > Surely the source archive should only contain source that is in the source
> > repo?
> >
> > Provenance of source is vital: i.e. each file can be found in SVN/Git.
> >
> > > On Sat, Sep 28, 2019 at 17:41, sebb <[hidden email]> wrote:
> > >
> > > > On Sat, 28 Sep 2019 at 17:42, Mark Thomas <[hidden email]> wrote:
> > > > >
> > > > > On 28/09/2019 17:06, Gary Gregory wrote:
> > > > > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <
> > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > >> I can confirm that if I delete all of:
> > > > > >>
> > > > > >> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > > > > >> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > > > > >> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > > > > >>
> > > > > >> I can build without errors but with warnings:
> > > > > >>
> > > > > >> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen':
> > This
> > > > > >> function or variable may be unsafe. Consider using _wfopen_s
> > instead.
> > > > To
> > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
> > for
> > > > > >> details.
> > > > > >> C:\Program Files (x86)\Windows
> > > > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> > > > > >> declaration of '_wfopen'
> > > > > >> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen':
> > This
> > > > > >> function or variable may be unsafe. Consider using _wfopen_s
> > instead.
> > > > To
> > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
> > for
> > > > > >> details.
> > > > > >> C:\Program Files (x86)\Windows
> > > > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
> > > > > >> declaration of '_wfopen'
> > > > > >> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf':
> > This
> > > > > >> function or variable may be unsafe. Consider using _snprintf_s
> > > > instead. To
> > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
> > for
> > > > > >> details.
> > > > > >> C:\Program Files (x86)\Windows
> > > > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> > > > declaration of
> > > > > >> '_snprintf'
> > > > > >> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf':
> > This
> > > > > >> function or variable may be unsafe. Consider using _snprintf_s
> > > > instead. To
> > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
> > for
> > > > > >> details.
> > > > > >> C:\Program Files (x86)\Windows
> > > > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> > > > declaration of
> > > > > >> '_snprintf'
> > > > > >>         rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
> > > > > >> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
> > > > > >>
> > > > > >
> > > > > > FWIW, using:
> > > > > >
> > > > > > Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for
> > x86
> > > > > > Copyright (C) Microsoft Corporation.  All rights reserved.
> > > > >
> > > > > Since I am going to re-tag for an RC2 (see below) I'll see what I
> > can do
> > > > > to clean up those warnings.
> > > > >
> > > > > >> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <
> > [hidden email]
> > > > >
> > > > > >> wrote:
> > > > > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:
> > > > > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <
> > [hidden email]>
> > > > > >>>> wrote:
> > > > >
> > > > > <snip/>
> > > > >
> > > > > >>>>> It seems we should NOT deliver the following folders in the
> > src zip
> > > > > >>>> which
> > > > > >>>>> now contain objs and exes:
> > > > > >>>>>
> > > > > >>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > > > > >>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > > > > >>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > > > > >>>>>
> > > > > >>>>> WDYT?
> > > > > >>>>
> > > > > >>>> Looks like the build created the files in the wrong directories?
> > > > >
> > > > > They should not be present in the source zip. I normally build the
> > > > > binaries from the same tag but in a completely different checkout to
> > > > > avoid this sort of thing. I'll see if I can figure out what I did
> > wrong
> > > > > but regardless of whether I can or not, I'll cancel this release,
> > update
> > > > > the estimated release date, re-tag and start an RC2 vote.
> > > > >
> > > > > I'll also take a brief look at whether I can exclude those
> > directories
> > > > > explicitly from the source build to avoid this issue in future
> > although
> > > > > my Maven foo may not be up to that.
> > > > >
> > > >
> > > > Why not create them in a different output directory under target?
> > > >
> > > > > >>>> The src zip also contains:
> > > > > >>>> src/native/unix/configure
> > > > > >>>> AIUI this is a generated file; I would expect it to be in the
> > binary
> > > > > >>>> artifact, if anywhere
> > > > >
> > > > > No. The configure script is generated but it *is* meant to be in the
> > > > > source distribution. Without it, building from source is more
> > difficult.
> > > > > I forgot this for the 1.2.0 release and there were complaints as a
> > > > result.
> > > >
> > > > Is the config file OS and version  independent?
> > > > If not, then it might be confusing.
> > > >
> > > > Why is it not in the Git repo?
> > > >
> > > > > >>>> Also there are some Git files missing from the src zip.
> > > > > >>>> Not sure if that is intentional?
> > > > > >>>>
> > > > > >>>> CONTRIBUTING.md
> > > > > >>>> HOWTO-RELEASE.txt
> > > > > >>>> README.md
> > > > > >>>>
> > > > > >>>
> > > > > >>> I certainly would expect CONTRIBUTING.md and README.md to be in
> > the
> > > > src
> > > > > >>> zip, not quite a blocker for me. I am more concerned that we are
> > > > including
> > > > > >>> all of these OBJ and EXE files.
> > > > >
> > > > > The .md files are generated but I agree they should be in the source
> > > > > distribution. I'll see about getting them added.
> > > > >
> > > > > The HOWTO_RELEASE.txt is perhaps more debatable but on balance I
> > think
> > > > > it should be there too.
> > > >
> > > > Does no harm, and makes it easier to compare source tag with source
> > bundle.
> > > >
> > > > > Mark
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > --
> > > Matt Sicker <[hidden email]>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
> Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

garydgregory
On Sun, Sep 29, 2019 at 6:04 PM sebb <[hidden email]> wrote:

> On Sun, 29 Sep 2019 at 22:36, Matt Sicker <[hidden email]> wrote:
> >
> > I’m sort of going off of what GNU projects do (they use autotools for
> any C
> > projects), but the common ‘./configure && make && sudo make install’
> > snippet is almost timeless.
>
> Not sure what that has to do with the question at hand, i.e
>
> Is the file is allowed to be in the source artifact if it is not in
> the source repository?
>

For me, no, I expect the source zip/tar to be a subset of what is in the
repo for the purposes of building usable artifacts, not a super-set.

Gary

>
> > On Sun, Sep 29, 2019 at 13:01, sebb <[hidden email]> wrote:
> >
> > > On Sun, 29 Sep 2019 at 17:21, Matt Sicker <[hidden email]> wrote:
> > > >
> > > > Projects that have a configure script usually include that in the
> source
> > > > distribution but not in the source repository (at least for autotools
> > > > users).
> > >
> > > But is that correct?
> > >
> > > Surely the source archive should only contain source that is in the
> source
> > > repo?
> > >
> > > Provenance of source is vital: i.e. each file can be found in SVN/Git.
> > >
> > > > On Sat, Sep 28, 2019 at 17:41, sebb <[hidden email]> wrote:
> > > >
> > > > > On Sat, 28 Sep 2019 at 17:42, Mark Thomas <[hidden email]>
> wrote:
> > > > > >
> > > > > > On 28/09/2019 17:06, Gary Gregory wrote:
> > > > > > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <
> > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> I can confirm that if I delete all of:
> > > > > > >>
> > > > > > >> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > > > > > >> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > > > > > >> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > > > > > >>
> > > > > > >> I can build without errors but with warnings:
> > > > > > >>
> > > > > > >> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen':
> > > This
> > > > > > >> function or variable may be unsafe. Consider using _wfopen_s
> > > instead.
> > > > > To
> > > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online
> help
> > > for
> > > > > > >> details.
> > > > > > >> C:\Program Files (x86)\Windows
> > > > > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130):
> note: see
> > > > > > >> declaration of '_wfopen'
> > > > > > >> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen':
> > > This
> > > > > > >> function or variable may be unsafe. Consider using _wfopen_s
> > > instead.
> > > > > To
> > > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online
> help
> > > for
> > > > > > >> details.
> > > > > > >> C:\Program Files (x86)\Windows
> > > > > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130):
> note: see
> > > > > > >> declaration of '_wfopen'
> > > > > > >> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996:
> '_snprintf':
> > > This
> > > > > > >> function or variable may be unsafe. Consider using _snprintf_s
> > > > > instead. To
> > > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online
> help
> > > for
> > > > > > >> details.
> > > > > > >> C:\Program Files (x86)\Windows
> > > > > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> > > > > declaration of
> > > > > > >> '_snprintf'
> > > > > > >> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996:
> '_snprintf':
> > > This
> > > > > > >> function or variable may be unsafe. Consider using _snprintf_s
> > > > > instead. To
> > > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online
> help
> > > for
> > > > > > >> details.
> > > > > > >> C:\Program Files (x86)\Windows
> > > > > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
> > > > > declaration of
> > > > > > >> '_snprintf'
> > > > > > >>         rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
> > > > > > >> WINXP_X86_EXE_RELEASE\prunsrv.res
> .\..\../apps/prunsrv/prunsrv.rc
> > > > > > >>
> > > > > > >
> > > > > > > FWIW, using:
> > > > > > >
> > > > > > > Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2
> for
> > > x86
> > > > > > > Copyright (C) Microsoft Corporation.  All rights reserved.
> > > > > >
> > > > > > Since I am going to re-tag for an RC2 (see below) I'll see what I
> > > can do
> > > > > > to clean up those warnings.
> > > > > >
> > > > > > >> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <
> > > [hidden email]
> > > > > >
> > > > > > >> wrote:
> > > > > > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]>
> wrote:
> > > > > > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <
> > > [hidden email]>
> > > > > > >>>> wrote:
> > > > > >
> > > > > > <snip/>
> > > > > >
> > > > > > >>>>> It seems we should NOT deliver the following folders in the
> > > src zip
> > > > > > >>>> which
> > > > > > >>>>> now contain objs and exes:
> > > > > > >>>>>
> > > > > > >>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> > > > > > >>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> > > > > > >>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
> > > > > > >>>>>
> > > > > > >>>>> WDYT?
> > > > > > >>>>
> > > > > > >>>> Looks like the build created the files in the wrong
> directories?
> > > > > >
> > > > > > They should not be present in the source zip. I normally build
> the
> > > > > > binaries from the same tag but in a completely different
> checkout to
> > > > > > avoid this sort of thing. I'll see if I can figure out what I did
> > > wrong
> > > > > > but regardless of whether I can or not, I'll cancel this release,
> > > update
> > > > > > the estimated release date, re-tag and start an RC2 vote.
> > > > > >
> > > > > > I'll also take a brief look at whether I can exclude those
> > > directories
> > > > > > explicitly from the source build to avoid this issue in future
> > > although
> > > > > > my Maven foo may not be up to that.
> > > > > >
> > > > >
> > > > > Why not create them in a different output directory under target?
> > > > >
> > > > > > >>>> The src zip also contains:
> > > > > > >>>> src/native/unix/configure
> > > > > > >>>> AIUI this is a generated file; I would expect it to be in
> the
> > > binary
> > > > > > >>>> artifact, if anywhere
> > > > > >
> > > > > > No. The configure script is generated but it *is* meant to be in
> the
> > > > > > source distribution. Without it, building from source is more
> > > difficult.
> > > > > > I forgot this for the 1.2.0 release and there were complaints as
> a
> > > > > result.
> > > > >
> > > > > Is the config file OS and version  independent?
> > > > > If not, then it might be confusing.
> > > > >
> > > > > Why is it not in the Git repo?
> > > > >
> > > > > > >>>> Also there are some Git files missing from the src zip.
> > > > > > >>>> Not sure if that is intentional?
> > > > > > >>>>
> > > > > > >>>> CONTRIBUTING.md
> > > > > > >>>> HOWTO-RELEASE.txt
> > > > > > >>>> README.md
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>> I certainly would expect CONTRIBUTING.md and README.md to be
> in
> > > the
> > > > > src
> > > > > > >>> zip, not quite a blocker for me. I am more concerned that we
> are
> > > > > including
> > > > > > >>> all of these OBJ and EXE files.
> > > > > >
> > > > > > The .md files are generated but I agree they should be in the
> source
> > > > > > distribution. I'll see about getting them added.
> > > > > >
> > > > > > The HOWTO_RELEASE.txt is perhaps more debatable but on balance I
> > > think
> > > > > > it should be there too.
> > > > >
> > > > > Does no harm, and makes it easier to compare source tag with source
> > > bundle.
> > > > >
> > > > > > Mark
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > > --
> > > > Matt Sicker <[hidden email]>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > > --
> > Matt Sicker <[hidden email]>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

Rob Tompkins
In reply to this post by Matt Sicker


> On Sep 29, 2019, at 5:36 PM, Matt Sicker <[hidden email]> wrote:
>
> I’m sort of going off of what GNU projects do (they use autotools for any C
> projects), but the common ‘./configure && make && sudo make install’
> snippet is almost timeless.
>

+1 to that

>> On Sun, Sep 29, 2019 at 13:01, sebb <[hidden email]> wrote:
>>
>>> On Sun, 29 Sep 2019 at 17:21, Matt Sicker <[hidden email]> wrote:
>>>
>>> Projects that have a configure script usually include that in the source
>>> distribution but not in the source repository (at least for autotools
>>> users).
>>
>> But is that correct?
>>
>> Surely the source archive should only contain source that is in the source
>> repo?
>>
>> Provenance of source is vital: i.e. each file can be found in SVN/Git.
>>
>>>> On Sat, Sep 28, 2019 at 17:41, sebb <[hidden email]> wrote:
>>>
>>>> On Sat, 28 Sep 2019 at 17:42, Mark Thomas <[hidden email]> wrote:
>>>>>
>>>>> On 28/09/2019 17:06, Gary Gregory wrote:
>>>>>> On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <
>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> I can confirm that if I delete all of:
>>>>>>>
>>>>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
>>>>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
>>>>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>>>>>>>
>>>>>>> I can build without errors but with warnings:
>>>>>>>
>>>>>>> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen':
>> This
>>>>>>> function or variable may be unsafe. Consider using _wfopen_s
>> instead.
>>>> To
>>>>>>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
>> for
>>>>>>> details.
>>>>>>> C:\Program Files (x86)\Windows
>>>>>>> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
>>>>>>> declaration of '_wfopen'
>>>>>>> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen':
>> This
>>>>>>> function or variable may be unsafe. Consider using _wfopen_s
>> instead.
>>>> To
>>>>>>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
>> for
>>>>>>> details.
>>>>>>> C:\Program Files (x86)\Windows
>>>>>>> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
>>>>>>> declaration of '_wfopen'
>>>>>>> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf':
>> This
>>>>>>> function or variable may be unsafe. Consider using _snprintf_s
>>>> instead. To
>>>>>>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
>> for
>>>>>>> details.
>>>>>>> C:\Program Files (x86)\Windows
>>>>>>> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
>>>> declaration of
>>>>>>> '_snprintf'
>>>>>>> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf':
>> This
>>>>>>> function or variable may be unsafe. Consider using _snprintf_s
>>>> instead. To
>>>>>>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help
>> for
>>>>>>> details.
>>>>>>> C:\Program Files (x86)\Windows
>>>>>>> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see
>>>> declaration of
>>>>>>> '_snprintf'
>>>>>>>        rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
>>>>>>> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
>>>>>>>
>>>>>>
>>>>>> FWIW, using:
>>>>>>
>>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for
>> x86
>>>>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>>>
>>>>> Since I am going to re-tag for an RC2 (see below) I'll see what I
>> can do
>>>>> to clean up those warnings.
>>>>>
>>>>>>> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <
>> [hidden email]
>>>>>
>>>>>>> wrote:
>>>>>>>> On Sat, Sep 28, 2019 at 10:03 AM sebb <[hidden email]> wrote:
>>>>>>>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <
>> [hidden email]>
>>>>>>>>> wrote:
>>>>>
>>>>> <snip/>
>>>>>
>>>>>>>>>> It seems we should NOT deliver the following folders in the
>> src zip
>>>>>>>>> which
>>>>>>>>>> now contain objs and exes:
>>>>>>>>>>
>>>>>>>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
>>>>>>>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
>>>>>>>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> Looks like the build created the files in the wrong directories?
>>>>>
>>>>> They should not be present in the source zip. I normally build the
>>>>> binaries from the same tag but in a completely different checkout to
>>>>> avoid this sort of thing. I'll see if I can figure out what I did
>> wrong
>>>>> but regardless of whether I can or not, I'll cancel this release,
>> update
>>>>> the estimated release date, re-tag and start an RC2 vote.
>>>>>
>>>>> I'll also take a brief look at whether I can exclude those
>> directories
>>>>> explicitly from the source build to avoid this issue in future
>> although
>>>>> my Maven foo may not be up to that.
>>>>>
>>>>
>>>> Why not create them in a different output directory under target?
>>>>
>>>>>>>>> The src zip also contains:
>>>>>>>>> src/native/unix/configure
>>>>>>>>> AIUI this is a generated file; I would expect it to be in the
>> binary
>>>>>>>>> artifact, if anywhere
>>>>>
>>>>> No. The configure script is generated but it *is* meant to be in the
>>>>> source distribution. Without it, building from source is more
>> difficult.
>>>>> I forgot this for the 1.2.0 release and there were complaints as a
>>>> result.
>>>>
>>>> Is the config file OS and version  independent?
>>>> If not, then it might be confusing.
>>>>
>>>> Why is it not in the Git repo?
>>>>
>>>>>>>>> Also there are some Git files missing from the src zip.
>>>>>>>>> Not sure if that is intentional?
>>>>>>>>>
>>>>>>>>> CONTRIBUTING.md
>>>>>>>>> HOWTO-RELEASE.txt
>>>>>>>>> README.md
>>>>>>>>>
>>>>>>>>
>>>>>>>> I certainly would expect CONTRIBUTING.md and README.md to be in
>> the
>>>> src
>>>>>>>> zip, not quite a blocker for me. I am more concerned that we are
>>>> including
>>>>>>>> all of these OBJ and EXE files.
>>>>>
>>>>> The .md files are generated but I agree they should be in the source
>>>>> distribution. I'll see about getting them added.
>>>>>
>>>>> The HOWTO_RELEASE.txt is perhaps more debatable but on balance I
>> think
>>>>> it should be there too.
>>>>
>>>> Does no harm, and makes it easier to compare source tag with source
>> bundle.
>>>>
>>>>> Mark
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> --
>>> Matt Sicker <[hidden email]>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>> --
> Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

Mark Thomas
In reply to this post by garydgregory
On 29/09/2019 23:15, Gary Gregory wrote:

> On Sun, Sep 29, 2019 at 6:04 PM sebb <[hidden email]> wrote:
>
>> On Sun, 29 Sep 2019 at 22:36, Matt Sicker <[hidden email]> wrote:
>>>
>>> I’m sort of going off of what GNU projects do (they use autotools for
>> any C
>>> projects), but the common ‘./configure && make && sudo make install’
>>> snippet is almost timeless.
>>
>> Not sure what that has to do with the question at hand, i.e
>>
>> Is the file is allowed to be in the source artifact if it is not in
>> the source repository?
>>
>
> For me, no, I expect the source zip/tar to be a subset of what is in the
> repo for the purposes of building usable artifacts, not a super-set.

That goes against the standard practice which is not to put the
configure script under version control.

I assume that this is because the file is generated.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

sebb-2-2
On Mon, 30 Sep 2019 at 09:23, Mark Thomas <[hidden email]> wrote:

>
> On 29/09/2019 23:15, Gary Gregory wrote:
> > On Sun, Sep 29, 2019 at 6:04 PM sebb <[hidden email]> wrote:
> >
> >> On Sun, 29 Sep 2019 at 22:36, Matt Sicker <[hidden email]> wrote:
> >>>
> >>> I’m sort of going off of what GNU projects do (they use autotools for
> >> any C
> >>> projects), but the common ‘./configure && make && sudo make install’
> >>> snippet is almost timeless.
> >>
> >> Not sure what that has to do with the question at hand, i.e
> >>
> >> Is the file is allowed to be in the source artifact if it is not in
> >> the source repository?
> >>
> >
> > For me, no, I expect the source zip/tar to be a subset of what is in the
> > repo for the purposes of building usable artifacts, not a super-set.
>
> That goes against the standard practice which is not to put the
> configure script under version control.

It's perfectly OK not to put generated files under version control.

I don't think it's OK to include files in the source archive that are
not in the tag.

> I assume that this is because the file is generated.

If it is created as part of the build, why is it included in the source archive?

> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

Stefan Bodewig
In reply to this post by sebb-2-2
On 2019-09-29, sebb wrote:

> On Sun, 29 Sep 2019 at 17:21, Matt Sicker <[hidden email]> wrote:

>> Projects that have a configure script usually include that in the source
>> distribution but not in the source repository (at least for autotools
>> users).

> But is that correct?

This is what people expect.

As others have already pointed out it is very common to not check in the
configure script but to include it with source tarballs.  Users can be
expected to have male installed but only few of them will install
autotools.

> Surely the source archive should only contain source that is in the
> source repo?

I'm not sure this is true for generated artifacts that can be verified
easily. Also I'm pretty sure some other C based projects of the ASF do
ship a generated configure script as part of the source tarball as well.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12