You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Thomas <ma...@apache.org> on 2019/09/25 14:57:37 UTC
[VOTE] Release Apache Commons Daemon 1.2.2 RC1
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Mark Thomas <ma...@apache.org>.
On 28/09/2019 17:42, Mark Thomas wrote:
> On 28/09/2019 17:06, Gary Gregory wrote:
>> On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <ga...@gmail.com>
>> wrote:
<snip/>
>>> 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
These have been fixed in 1d0243e
I also tried turning up warnings from -W3 (the compiler default) to -W4
and I fixed a reasonable proportion (but not all) of the additional
warnings that generated.
<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?
I've modified the assembly descriptors to always exclude these files.
>>>>> 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.
I disagree with adding this to source control since it goes against the
standard convention and will not be what developers will expect.
>>>>> Also there are some Git files missing from the src zip.
>>>>> Not sure if that is intentional?
>>>>>
>>>>> CONTRIBUTING.md
>>>>> HOWTO-RELEASE.txt
>>>>> README.md
All fixed.
I want to do some test builds locally and then I should be ready to tag RC2.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Rob Tompkins <ch...@gmail.com>.
> On Sep 29, 2019, at 5:36 PM, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
>>
>>> On Sun, 29 Sep 2019 at 17:21, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
>>>
>>>> On Sat, 28 Sep 2019 at 17:42, Mark Thomas <ma...@apache.org> wrote:
>>>>>
>>>>> On 28/09/2019 17:06, Gary Gregory wrote:
>>>>>> On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <
>> garydgregory@gmail.com>
>>>>>> 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 <
>> garydgregory@gmail.com
>>>>>
>>>>>>> wrote:
>>>>>>>> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
>>>>>>>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <
>> garydgregory@gmail.com>
>>>>>>>>> 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: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> --
>>> Matt Sicker <bo...@gmail.com>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by sebb <se...@gmail.com>.
On Mon, 30 Sep 2019 at 09:23, Mark Thomas <ma...@apache.org> wrote:
>
> On 29/09/2019 23:15, Gary Gregory wrote:
> > On Sun, Sep 29, 2019 at 6:04 PM sebb <se...@gmail.com> wrote:
> >
> >> On Sun, 29 Sep 2019 at 22:36, Matt Sicker <bo...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Mark Thomas <ma...@apache.org>.
On 29/09/2019 23:15, Gary Gregory wrote:
> On Sun, Sep 29, 2019 at 6:04 PM sebb <se...@gmail.com> wrote:
>
>> On Sun, 29 Sep 2019 at 22:36, Matt Sicker <bo...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Sep 29, 2019 at 6:04 PM sebb <se...@gmail.com> wrote:
> On Sun, 29 Sep 2019 at 22:36, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
> >
> > > On Sun, 29 Sep 2019 at 17:21, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
> > > >
> > > > > On Sat, 28 Sep 2019 at 17:42, Mark Thomas <ma...@apache.org>
> wrote:
> > > > > >
> > > > > > On 28/09/2019 17:06, Gary Gregory wrote:
> > > > > > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <
> > > garydgregory@gmail.com>
> > > > > > > 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 <
> > > garydgregory@gmail.com
> > > > > >
> > > > > > >> wrote:
> > > > > > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com>
> wrote:
> > > > > > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <
> > > garydgregory@gmail.com>
> > > > > > >>>> 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: dev-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > > --
> > > > Matt Sicker <bo...@gmail.com>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > > --
> > Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by sebb <se...@gmail.com>.
On Sun, 29 Sep 2019 at 22:36, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
>
> > On Sun, 29 Sep 2019 at 17:21, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
> > >
> > > > On Sat, 28 Sep 2019 at 17:42, Mark Thomas <ma...@apache.org> wrote:
> > > > >
> > > > > On 28/09/2019 17:06, Gary Gregory wrote:
> > > > > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <
> > garydgregory@gmail.com>
> > > > > > 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 <
> > garydgregory@gmail.com
> > > > >
> > > > > >> wrote:
> > > > > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
> > > > > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <
> > garydgregory@gmail.com>
> > > > > >>>> 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: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > > --
> > > Matt Sicker <bo...@gmail.com>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Matt Sicker <bo...@gmail.com>.
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 <se...@gmail.com> wrote:
> On Sun, 29 Sep 2019 at 17:21, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
> >
> > > On Sat, 28 Sep 2019 at 17:42, Mark Thomas <ma...@apache.org> wrote:
> > > >
> > > > On 28/09/2019 17:06, Gary Gregory wrote:
> > > > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <
> garydgregory@gmail.com>
> > > > > 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 <
> garydgregory@gmail.com
> > > >
> > > > >> wrote:
> > > > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
> > > > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <
> garydgregory@gmail.com>
> > > > >>>> 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: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > > --
> > Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> --
Matt Sicker <bo...@gmail.com>
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Stefan Bodewig <bo...@apache.org>.
On 2019-09-30, sebb wrote:
> On Mon, 30 Sep 2019 at 10:25, Stefan Bodewig <bo...@apache.org> wrote:
>> On 2019-09-29, sebb wrote:
>>> On Sun, 29 Sep 2019 at 17:21, Matt Sicker <bo...@gmail.com> 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.
> But that does not make it right.
I'm afraid you and I have different interpretations of "right" :-)
> I'll ask again: is the generated config file universally applicable?
AFAIR yes, in certain details it may depend on the version of autotools
being used but the output is universally applicable in either
case. Disclaimer: it's been a long time since I last used autotools.
> If so, put it in the source repo.
And break with decade old traditions of C-projects, is that "right"?
What are the goals of distributing tar balls and of voting on them? IMHO
(my opinion, not one that anybody has to share) (1) we want to enable
developers to use our products and (2) ensue the ASF is not put at any
risk. Personally I don't really see the risk of shipping a configure
script that is not part of the SCM repository.
Note I haven't voted and don't intend to do so as I am unable to find
time to properly vet the release. I've just been offering an opinion and
will stop adding to the noise now.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by sebb <se...@gmail.com>.
On Mon, 30 Sep 2019 at 10:25, Stefan Bodewig <bo...@apache.org> wrote:
>
> On 2019-09-29, sebb wrote:
>
> > On Sun, 29 Sep 2019 at 17:21, Matt Sicker <bo...@gmail.com> 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.
But that does not make it right.
> 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.
I'll ask again: is the generated config file universally applicable?
If so, put it in the source repo.
If not, then having it in the source tarball is misleading as it may
not work for the downloader.
At least the file should have some clue as to which OSes it applies,
eg configure.freebsd
> > 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.
Again, not proof.
And anyway, how do reviewers check whether the configure file is correct?
It's very complicated; a single spurious space in the wrong place
could break it.
If it does not change, it can be added to the source repo once, and
validated then.
It then needs no further checking.
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Stefan Bodewig <bo...@apache.org>.
On 2019-09-29, sebb wrote:
> On Sun, 29 Sep 2019 at 17:21, Matt Sicker <bo...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by sebb <se...@gmail.com>.
On Sun, 29 Sep 2019 at 17:21, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
>
> > On Sat, 28 Sep 2019 at 17:42, Mark Thomas <ma...@apache.org> wrote:
> > >
> > > On 28/09/2019 17:06, Gary Gregory wrote:
> > > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <ga...@gmail.com>
> > > > 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 <garydgregory@gmail.com
> > >
> > > >> wrote:
> > > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
> > > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <ga...@gmail.com>
> > > >>>> 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: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Matt Sicker <bo...@gmail.com>.
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 <se...@gmail.com> wrote:
> On Sat, 28 Sep 2019 at 17:42, Mark Thomas <ma...@apache.org> wrote:
> >
> > On 28/09/2019 17:06, Gary Gregory wrote:
> > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <ga...@gmail.com>
> > > 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 <garydgregory@gmail.com
> >
> > >> wrote:
> > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
> > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <ga...@gmail.com>
> > >>>> 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: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> --
Matt Sicker <bo...@gmail.com>
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by sebb <se...@gmail.com>.
On Sat, 28 Sep 2019 at 17:42, Mark Thomas <ma...@apache.org> wrote:
>
> On 28/09/2019 17:06, Gary Gregory wrote:
> > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <ga...@gmail.com>
> > 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 <ga...@gmail.com>
> >> wrote:
> >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
> >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <ga...@gmail.com>
> >>>> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Mark Thomas <ma...@apache.org>.
On 28/09/2019 17:06, Gary Gregory wrote:
> On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <ga...@gmail.com>
> 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 <ga...@gmail.com>
>> wrote:
>>> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
>>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <ga...@gmail.com>
>>>> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <ga...@gmail.com>
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 <ga...@gmail.com>
> wrote:
>
>> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
>>
>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <ga...@gmail.com>
>>> 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 <ma...@apache.org> 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: dev-unsubscribe@commons.apache.org
>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>> > >
>>> > >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@gmail.com>
wrote:
> On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
>
>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <ga...@gmail.com>
>> 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 <ma...@apache.org> 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: dev-unsubscribe@commons.apache.org
>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Sep 28, 2019 at 10:03 AM sebb <se...@gmail.com> wrote:
> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <ga...@gmail.com> 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 <ma...@apache.org> 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: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by sebb <se...@gmail.com>.
On Sat, 28 Sep 2019 at 13:39, Gary Gregory <ga...@gmail.com> 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 <ma...@apache.org> 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: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Gary Gregory <ga...@gmail.com>.
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 <ma...@apache.org> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Rob Tompkins <ch...@gmail.com>.
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 <ma...@apache.org> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE][CANCELLED] Release Apache Commons Daemon 1.2.2 RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Sep 30, 2019 at 9:26 AM Mark Thomas <ma...@apache.org> wrote:
> I am cancelling this vote due to the presence of Windows build artefacts
> in RC1.
>
> RC2 should follow shortly.
>
>
Mark,
Thank you for working through all of this. I know this will make for a
better product :-)
Gary
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE][CANCELLED] Release Apache Commons Daemon 1.2.2 RC1
Posted by Mark Thomas <ma...@apache.org>.
I am cancelling this vote due to the presence of Windows build artefacts
in RC1.
RC2 should follow shortly.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
Posted by Rob Tompkins <ch...@gmail.com>.
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 <ma...@apache.org> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org