Re: [Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

Ah, are you thinking of KICAD_VERSION_EXTRA?

I already did that, but I didn't think it was clear that
5.0.2-4-286de261e-5 was newer than 5.0.2-4-29799fda.  Perhaps I am
overthinking it.

On Sat, Jan 19, 2019 at 2:18 AM Nick Østergaard  wrote:

> Sorry, but I am not on my workstation. But we have the thing from git
> describe in the paranthesis and you append a monotonically increasing
> serial number, like pkgrel in a PKGBUILD. I think that will work good, ot
> should help to tell the difference between binaries.
>
> lør. 19. jan. 2019 04.45 skrev Adam Wolf :
>
>> Sorry, resending since I sent from the wrong address.
>>
>> On Fri, Jan 18, 2019, 6:57 PM Adam Wolf >
>>> If I use git am, how do I release another 5.0.2, Nick?
>>>
>>> On Fri, Jan 18, 2019, 6:08 PM Nick Østergaard >>
 IMHO, just use git am and be happy with the output. I should be unique
 and mention 5.0.2 plus some additions.

 fre. 18. jan. 2019 22.33 skrev Bob Gustafson :

> Maybe the suffix would start with an alpha character (a,b,c,d,..) The
> first would start with a. If another patch comes along, change the suffix
> to b, ... etc.
>
> When the number come back in sync, drop the suffix.
>
> Anyway - a suggestion.
> On 1/18/19 3:25 PM, Adam Wolf wrote:
>
> Exactly.  I won't say it's 5.0.2, which isn't true, but I'll add a
> suffix on.
>
> Thanks folks.  I'll make these changes this weekend.
>
> Adam
>
> On Fri, Jan 18, 2019, 2:33 PM Wayne Stambaugh  wrote:
>
>> That make sense to me.  This way we will know that there are patches
>> applied to the macos build that are beyond the 5.0.2 tag.
>>
>> On 1/18/19 3:13 PM, Adam Wolf wrote:
>> > So I originally used git am.  I apply 4 patches, so my first
>> release was
>> > 5.0.2-4-SOMESHA.  I want to make a new version, that is obviously
>> newer
>> > and higher than that.
>> >
>> > I asked Wayne, and he said to apply the macOS-packaging-specific
>> patches
>> > outside of git, so that git describe is OK.  I forgot that it would
>> > describe it as dirty.
>> >
>> > Maybe, in order to get clean, obvious version numbers, I should I
>> apply
>> > with git am, and then make a local tag?  Thoughts?
>> >
>> > Adam
>> >
>> > On Fri, Jan 18, 2019 at 1:41 PM Wayne Stambaugh <
>> stambau...@gmail.com
>> > > wrote:
>> >
>> > If you use `git am` to apply the patches, you wont get -dirty
>> appended
>> > to the version string.  However, you will end up with
>> -###-gcommithash
>> > appended so you still wont end up with 5.0.2 as the version
>> string which
>> > is what I'm gessing Adam is looking for.
>> >
>> > On 1/18/19 2:33 PM, Nick Østergaard wrote:
>> > > Mmm, what is wrong wit the git describe when the patches are
>> applied
>> > > with git am?
>> > >
>> > > fre. 18. jan. 2019 20.11 skrev Wayne Stambaugh
>> > mailto:stambau...@gmail.com>
>> > > >>:
>> > >
>> > > This is a result of modifications to the repo.  The
>> --dirty
>> > option of
>> > > `git describe` checks to see anything is modified and
>> appends
>> > -dirty to
>> > > the version string.  This way we know if someone modified
>> the
>> > source for
>> > > a given commit.  You could change the command in
>> > > CreateGitVersionHeader.cmake to `git descibe` to drop
>> -dirty
>> > from the
>> > > version string.
>> > >
>> > > Wayne
>> > >
>> > > On 1/18/19 1:40 PM, Adam Wolf wrote:
>> > > > Hi Wayne!
>> > > >
>> > > > I have since fixed the ngspice build race condition on
>> > macOS. I have
>> > > > modified the build scripts so that patches occur via
>> patch,
>> > not git
>> > > > itself.  Unfortunately, now the git version info shows
>> > > 5.0.2-dirty.  Is
>> > > > this how it shows on the Windows builds too?
>> > > >
>> > > > Adam Wolf
>> > > >
>> > > > On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf
>> > > > > 
>> > > > >
>> > > > > > 
>> > > > > > > > >
>> > > > Alright.  Those changes are made.  I am doing
>> builds now.
>> > > They are
>> > >   

Re: [Kicad-developers] Pulling mac 5.0.2...

[Nick Østergaard]

Sorry, but I am not on my workstation. But we have the thing from git
describe in the paranthesis and you append a monotonically increasing
serial number, like pkgrel in a PKGBUILD. I think that will work good, ot
should help to tell the difference between binaries.

lør. 19. jan. 2019 04.45 skrev Adam Wolf :

> Sorry, resending since I sent from the wrong address.
>
> On Fri, Jan 18, 2019, 6:57 PM Adam Wolf 
>> If I use git am, how do I release another 5.0.2, Nick?
>>
>> On Fri, Jan 18, 2019, 6:08 PM Nick Østergaard >
>>> IMHO, just use git am and be happy with the output. I should be unique
>>> and mention 5.0.2 plus some additions.
>>>
>>> fre. 18. jan. 2019 22.33 skrev Bob Gustafson :
>>>
 Maybe the suffix would start with an alpha character (a,b,c,d,..) The
 first would start with a. If another patch comes along, change the suffix
 to b, ... etc.

 When the number come back in sync, drop the suffix.

 Anyway - a suggestion.
 On 1/18/19 3:25 PM, Adam Wolf wrote:

 Exactly.  I won't say it's 5.0.2, which isn't true, but I'll add a
 suffix on.

 Thanks folks.  I'll make these changes this weekend.

 Adam

 On Fri, Jan 18, 2019, 2:33 PM Wayne Stambaugh >>> wrote:

> That make sense to me.  This way we will know that there are patches
> applied to the macos build that are beyond the 5.0.2 tag.
>
> On 1/18/19 3:13 PM, Adam Wolf wrote:
> > So I originally used git am.  I apply 4 patches, so my first release
> was
> > 5.0.2-4-SOMESHA.  I want to make a new version, that is obviously
> newer
> > and higher than that.
> >
> > I asked Wayne, and he said to apply the macOS-packaging-specific
> patches
> > outside of git, so that git describe is OK.  I forgot that it would
> > describe it as dirty.
> >
> > Maybe, in order to get clean, obvious version numbers, I should I
> apply
> > with git am, and then make a local tag?  Thoughts?
> >
> > Adam
> >
> > On Fri, Jan 18, 2019 at 1:41 PM Wayne Stambaugh <
> stambau...@gmail.com
> > > wrote:
> >
> > If you use `git am` to apply the patches, you wont get -dirty
> appended
> > to the version string.  However, you will end up with
> -###-gcommithash
> > appended so you still wont end up with 5.0.2 as the version
> string which
> > is what I'm gessing Adam is looking for.
> >
> > On 1/18/19 2:33 PM, Nick Østergaard wrote:
> > > Mmm, what is wrong wit the git describe when the patches are
> applied
> > > with git am?
> > >
> > > fre. 18. jan. 2019 20.11 skrev Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >>:
> > >
> > > This is a result of modifications to the repo.  The --dirty
> > option of
> > > `git describe` checks to see anything is modified and
> appends
> > -dirty to
> > > the version string.  This way we know if someone modified
> the
> > source for
> > > a given commit.  You could change the command in
> > > CreateGitVersionHeader.cmake to `git descibe` to drop
> -dirty
> > from the
> > > version string.
> > >
> > > Wayne
> > >
> > > On 1/18/19 1:40 PM, Adam Wolf wrote:
> > > > Hi Wayne!
> > > >
> > > > I have since fixed the ngspice build race condition on
> > macOS. I have
> > > > modified the build scripts so that patches occur via
> patch,
> > not git
> > > > itself.  Unfortunately, now the git version info shows
> > > 5.0.2-dirty.  Is
> > > > this how it shows on the Windows builds too?
> > > >
> > > > Adam Wolf
> > > >
> > > > On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf
> > >  > 
> >  > >
> > > >  > 
> > >  >  > > >
> > > > Alright.  Those changes are made.  I am doing builds
> now.
> > > They are
> > > > going to be 5.0.2-5 in order to ... reduce confusion.
> > > >
> > > > After builds, I need to upload them to testing/,
> download
> > > them, run
> > > > them through a test procedure that's in the README,
> and then
> > > see if
> > > > this fixes the issues for users.  If so, I 

Re: [Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

Sorry, resending since I sent from the wrong address.

On Fri, Jan 18, 2019, 6:57 PM Adam Wolf  If I use git am, how do I release another 5.0.2, Nick?
>
> On Fri, Jan 18, 2019, 6:08 PM Nick Østergaard 
>> IMHO, just use git am and be happy with the output. I should be unique
>> and mention 5.0.2 plus some additions.
>>
>> fre. 18. jan. 2019 22.33 skrev Bob Gustafson :
>>
>>> Maybe the suffix would start with an alpha character (a,b,c,d,..) The
>>> first would start with a. If another patch comes along, change the suffix
>>> to b, ... etc.
>>>
>>> When the number come back in sync, drop the suffix.
>>>
>>> Anyway - a suggestion.
>>> On 1/18/19 3:25 PM, Adam Wolf wrote:
>>>
>>> Exactly.  I won't say it's 5.0.2, which isn't true, but I'll add a
>>> suffix on.
>>>
>>> Thanks folks.  I'll make these changes this weekend.
>>>
>>> Adam
>>>
>>> On Fri, Jan 18, 2019, 2:33 PM Wayne Stambaugh >> wrote:
>>>
 That make sense to me.  This way we will know that there are patches
 applied to the macos build that are beyond the 5.0.2 tag.

 On 1/18/19 3:13 PM, Adam Wolf wrote:
 > So I originally used git am.  I apply 4 patches, so my first release
 was
 > 5.0.2-4-SOMESHA.  I want to make a new version, that is obviously
 newer
 > and higher than that.
 >
 > I asked Wayne, and he said to apply the macOS-packaging-specific
 patches
 > outside of git, so that git describe is OK.  I forgot that it would
 > describe it as dirty.
 >
 > Maybe, in order to get clean, obvious version numbers, I should I
 apply
 > with git am, and then make a local tag?  Thoughts?
 >
 > Adam
 >
 > On Fri, Jan 18, 2019 at 1:41 PM Wayne Stambaugh >>> > > wrote:
 >
 > If you use `git am` to apply the patches, you wont get -dirty
 appended
 > to the version string.  However, you will end up with
 -###-gcommithash
 > appended so you still wont end up with 5.0.2 as the version
 string which
 > is what I'm gessing Adam is looking for.
 >
 > On 1/18/19 2:33 PM, Nick Østergaard wrote:
 > > Mmm, what is wrong wit the git describe when the patches are
 applied
 > > with git am?
 > >
 > > fre. 18. jan. 2019 20.11 skrev Wayne Stambaugh
 > mailto:stambau...@gmail.com>
 > > >>:
 > >
 > > This is a result of modifications to the repo.  The --dirty
 > option of
 > > `git describe` checks to see anything is modified and
 appends
 > -dirty to
 > > the version string.  This way we know if someone modified
 the
 > source for
 > > a given commit.  You could change the command in
 > > CreateGitVersionHeader.cmake to `git descibe` to drop -dirty
 > from the
 > > version string.
 > >
 > > Wayne
 > >
 > > On 1/18/19 1:40 PM, Adam Wolf wrote:
 > > > Hi Wayne!
 > > >
 > > > I have since fixed the ngspice build race condition on
 > macOS. I have
 > > > modified the build scripts so that patches occur via
 patch,
 > not git
 > > > itself.  Unfortunately, now the git version info shows
 > > 5.0.2-dirty.  Is
 > > > this how it shows on the Windows builds too?
 > > >
 > > > Adam Wolf
 > > >
 > > > On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf
 > > >>> > 
 >  >
 > > >  
 > >   > >
 > > > Alright.  Those changes are made.  I am doing builds
 now.
 > > They are
 > > > going to be 5.0.2-5 in order to ... reduce confusion.
 > > >
 > > > After builds, I need to upload them to testing/,
 download
 > > them, run
 > > > them through a test procedure that's in the README,
 and then
 > > see if
 > > > this fixes the issues for users.  If so, I will move
 the
 > 5.0.2-5
 > > > packages to stable/, and adjust the website.
 > > >
 > > > In the meantime, I am going to move the 5.0.2 packages
 > out of the
 > > > way on the server.  I'm getting multiple tickets a day
 > for the
 > > same
 > > > issue and we don't need more people downloading the
 bad
 > macOS
 > > > 

Re: [Kicad-developers] Pulling mac 5.0.2...

[Nick Østergaard]

IMHO, just use git am and be happy with the output. I should be unique and
mention 5.0.2 plus some additions.

fre. 18. jan. 2019 22.33 skrev Bob Gustafson :

> Maybe the suffix would start with an alpha character (a,b,c,d,..) The
> first would start with a. If another patch comes along, change the suffix
> to b, ... etc.
>
> When the number come back in sync, drop the suffix.
>
> Anyway - a suggestion.
> On 1/18/19 3:25 PM, Adam Wolf wrote:
>
> Exactly.  I won't say it's 5.0.2, which isn't true, but I'll add a suffix
> on.
>
> Thanks folks.  I'll make these changes this weekend.
>
> Adam
>
> On Fri, Jan 18, 2019, 2:33 PM Wayne Stambaugh 
>> That make sense to me.  This way we will know that there are patches
>> applied to the macos build that are beyond the 5.0.2 tag.
>>
>> On 1/18/19 3:13 PM, Adam Wolf wrote:
>> > So I originally used git am.  I apply 4 patches, so my first release was
>> > 5.0.2-4-SOMESHA.  I want to make a new version, that is obviously newer
>> > and higher than that.
>> >
>> > I asked Wayne, and he said to apply the macOS-packaging-specific patches
>> > outside of git, so that git describe is OK.  I forgot that it would
>> > describe it as dirty.
>> >
>> > Maybe, in order to get clean, obvious version numbers, I should I apply
>> > with git am, and then make a local tag?  Thoughts?
>> >
>> > Adam
>> >
>> > On Fri, Jan 18, 2019 at 1:41 PM Wayne Stambaugh > > > wrote:
>> >
>> > If you use `git am` to apply the patches, you wont get -dirty
>> appended
>> > to the version string.  However, you will end up with
>> -###-gcommithash
>> > appended so you still wont end up with 5.0.2 as the version string
>> which
>> > is what I'm gessing Adam is looking for.
>> >
>> > On 1/18/19 2:33 PM, Nick Østergaard wrote:
>> > > Mmm, what is wrong wit the git describe when the patches are
>> applied
>> > > with git am?
>> > >
>> > > fre. 18. jan. 2019 20.11 skrev Wayne Stambaugh
>> > mailto:stambau...@gmail.com>
>> > > >>:
>> > >
>> > > This is a result of modifications to the repo.  The --dirty
>> > option of
>> > > `git describe` checks to see anything is modified and appends
>> > -dirty to
>> > > the version string.  This way we know if someone modified the
>> > source for
>> > > a given commit.  You could change the command in
>> > > CreateGitVersionHeader.cmake to `git descibe` to drop -dirty
>> > from the
>> > > version string.
>> > >
>> > > Wayne
>> > >
>> > > On 1/18/19 1:40 PM, Adam Wolf wrote:
>> > > > Hi Wayne!
>> > > >
>> > > > I have since fixed the ngspice build race condition on
>> > macOS. I have
>> > > > modified the build scripts so that patches occur via patch,
>> > not git
>> > > > itself.  Unfortunately, now the git version info shows
>> > > 5.0.2-dirty.  Is
>> > > > this how it shows on the Windows builds too?
>> > > >
>> > > > Adam Wolf
>> > > >
>> > > > On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf
>> > > > > 
>> > > > >
>> > > > > > 
>> > > > > > > > >
>> > > > Alright.  Those changes are made.  I am doing builds
>> now.
>> > > They are
>> > > > going to be 5.0.2-5 in order to ... reduce confusion.
>> > > >
>> > > > After builds, I need to upload them to testing/,
>> download
>> > > them, run
>> > > > them through a test procedure that's in the README, and
>> then
>> > > see if
>> > > > this fixes the issues for users.  If so, I will move the
>> > 5.0.2-5
>> > > > packages to stable/, and adjust the website.
>> > > >
>> > > > In the meantime, I am going to move the 5.0.2 packages
>> > out of the
>> > > > way on the server.  I'm getting multiple tickets a day
>> > for the
>> > > same
>> > > > issue and we don't need more people downloading the bad
>> > macOS
>> > > > package.  Once we have the new package up, we can put it
>> > back for
>> > > > posterity's sake or whatever.
>> > > >
>> > > > Adam
>> > > >
>> > > > On Tue, Jan 8, 2019 at 8:15 AM Adam Wolf
>> > > > > > 
>> > > > > >
>> > > > > > 

Re: [Kicad-developers] Pulling mac 5.0.2...

[Bob Gustafson]

Maybe the suffix would start with an alpha character (a,b,c,d,..) The 
first would start with a. If another patch comes along, change the 
suffix to b, ... etc.


When the number come back in sync, drop the suffix.

Anyway - a suggestion.

On 1/18/19 3:25 PM, Adam Wolf wrote:
Exactly.  I won't say it's 5.0.2, which isn't true, but I'll add a 
suffix on.


Thanks folks.  I'll make these changes this weekend.

Adam

On Fri, Jan 18, 2019, 2:33 PM Wayne Stambaugh  wrote:


That make sense to me.  This way we will know that there are patches
applied to the macos build that are beyond the 5.0.2 tag.

On 1/18/19 3:13 PM, Adam Wolf wrote:
> So I originally used git am.  I apply 4 patches, so my first
release was
> 5.0.2-4-SOMESHA.  I want to make a new version, that is
obviously newer
> and higher than that.
>
> I asked Wayne, and he said to apply the macOS-packaging-specific
patches
> outside of git, so that git describe is OK.  I forgot that it would
> describe it as dirty.
>
> Maybe, in order to get clean, obvious version numbers, I should
I apply
> with git am, and then make a local tag?  Thoughts?
>
> Adam
>
> On Fri, Jan 18, 2019 at 1:41 PM Wayne Stambaugh
mailto:stambau...@gmail.com>
> >> wrote:
>
>     If you use `git am` to apply the patches, you wont get
-dirty appended
>     to the version string.  However, you will end up with
-###-gcommithash
>     appended so you still wont end up with 5.0.2 as the version
string which
>     is what I'm gessing Adam is looking for.
>
>     On 1/18/19 2:33 PM, Nick Østergaard wrote:
>     > Mmm, what is wrong wit the git describe when the patches
are applied
>     > with git am?
>     >
>     > fre. 18. jan. 2019 20.11 skrev Wayne Stambaugh
>     mailto:stambau...@gmail.com>
>
>     > 
     >
>     >     This is a result of modifications to the repo.  The
--dirty
>     option of
>     >     `git describe` checks to see anything is modified and
appends
>     -dirty to
>     >     the version string.  This way we know if someone
modified the
>     source for
>     >     a given commit.  You could change the command in
>     >     CreateGitVersionHeader.cmake to `git descibe` to drop
-dirty
>     from the
>     >     version string.
>     >
>     >     Wayne
>     >
>     >     On 1/18/19 1:40 PM, Adam Wolf wrote:
>     >     > Hi Wayne!
>     >     >
>     >     > I have since fixed the ngspice build race condition on
>     macOS. I have
>     >     > modified the build scripts so that patches occur via
patch,
>     not git
>     >     > itself.  Unfortunately, now the git version info shows
>     >     5.0.2-dirty.  Is
>     >     > this how it shows on the Windows builds too?
>     >     >
>     >     > Adam Wolf
>     >     >
>     >     > On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf
>     >     mailto:adamw...@feelslikeburning.com>
>     >
>     
>     >>
>     >     > 
>     >
>     >     
>      wrote:
>     >     >
>     >     >     Alright.  Those changes are made. I am doing
builds now.
>     >     They are
>     >     >     going to be 5.0.2-5 in order to ... reduce
confusion.
>     >     >
>     >     >     After builds, I need to upload them to testing/,
download
>     >     them, run
>     >     >     them through a test procedure that's in the
README, and then
>     >     see if
>     >     >     this fixes the issues for users. If so, I will
move the
>     5.0.2-5
>     >     >     packages to stable/, and adjust the website.
>     >     >
>     >     >     In the meantime, I am going to move the 5.0.2
packages
>     out of the
>     >     >     way on the server.  I'm getting multiple tickets
a day
>     for the
>     >     same
>     >     >     issue and we don't need more people downloading
the bad
>     

Re: [Kicad-developers] Pulling mac 5.0.2...

[Wayne Stambaugh]

That make sense to me.  This way we will know that there are patches
applied to the macos build that are beyond the 5.0.2 tag.

On 1/18/19 3:13 PM, Adam Wolf wrote:
> So I originally used git am.  I apply 4 patches, so my first release was
> 5.0.2-4-SOMESHA.  I want to make a new version, that is obviously newer
> and higher than that.
> 
> I asked Wayne, and he said to apply the macOS-packaging-specific patches
> outside of git, so that git describe is OK.  I forgot that it would
> describe it as dirty.
> 
> Maybe, in order to get clean, obvious version numbers, I should I apply
> with git am, and then make a local tag?  Thoughts?
> 
> Adam
> 
> On Fri, Jan 18, 2019 at 1:41 PM Wayne Stambaugh  > wrote:
> 
> If you use `git am` to apply the patches, you wont get -dirty appended
> to the version string.  However, you will end up with -###-gcommithash
> appended so you still wont end up with 5.0.2 as the version string which
> is what I'm gessing Adam is looking for.
> 
> On 1/18/19 2:33 PM, Nick Østergaard wrote:
> > Mmm, what is wrong wit the git describe when the patches are applied
> > with git am?
> >
> > fre. 18. jan. 2019 20.11 skrev Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > >>:
> >
> >     This is a result of modifications to the repo.  The --dirty
> option of
> >     `git describe` checks to see anything is modified and appends
> -dirty to
> >     the version string.  This way we know if someone modified the
> source for
> >     a given commit.  You could change the command in
> >     CreateGitVersionHeader.cmake to `git descibe` to drop -dirty
> from the
> >     version string.
> >
> >     Wayne
> >
> >     On 1/18/19 1:40 PM, Adam Wolf wrote:
> >     > Hi Wayne!
> >     >
> >     > I have since fixed the ngspice build race condition on
> macOS. I have
> >     > modified the build scripts so that patches occur via patch,
> not git
> >     > itself.  Unfortunately, now the git version info shows
> >     5.0.2-dirty.  Is
> >     > this how it shows on the Windows builds too?
> >     >
> >     > Adam Wolf
> >     >
> >     > On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf
> >      
>  >
> >     >  
> >       >     >
> >     >     Alright.  Those changes are made.  I am doing builds now. 
> >     They are
> >     >     going to be 5.0.2-5 in order to ... reduce confusion.
> >     >
> >     >     After builds, I need to upload them to testing/, download
> >     them, run
> >     >     them through a test procedure that's in the README, and then
> >     see if
> >     >     this fixes the issues for users.  If so, I will move the
> 5.0.2-5
> >     >     packages to stable/, and adjust the website.
> >     >
> >     >     In the meantime, I am going to move the 5.0.2 packages
> out of the
> >     >     way on the server.  I'm getting multiple tickets a day
> for the
> >     same
> >     >     issue and we don't need more people downloading the bad
> macOS
> >     >     package.  Once we have the new package up, we can put it
> back for
> >     >     posterity's sake or whatever.
> >     >
> >     >     Adam
> >     >
> >     >     On Tue, Jan 8, 2019 at 8:15 AM Adam Wolf
> >     >      
> >      >
> >     >      
> >       >     >
> >     >         Thanks Wayne.  Will do.  I appreciate your fast
> response.
> >     >
> >     >         Adam
> >     >
> >     >         On Tue, Jan 8, 2019 at 7:58 AM Wayne Stambaugh
> >     >         mailto:stambau...@gmail.com>
> >
> >     
>  >     >
> >     >             Hey Adam,
> >     >
> >     >             Rather than committing the macos build patches
> to the git
> >     >             repo, why not
> >     >             just run patch from the build script to apply
> them?  This
> >     >             way you don't
> >     >             

Re: [Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

So I originally used git am.  I apply 4 patches, so my first release was
5.0.2-4-SOMESHA.  I want to make a new version, that is obviously newer and
higher than that.

I asked Wayne, and he said to apply the macOS-packaging-specific patches
outside of git, so that git describe is OK.  I forgot that it would
describe it as dirty.

Maybe, in order to get clean, obvious version numbers, I should I apply
with git am, and then make a local tag?  Thoughts?

Adam

On Fri, Jan 18, 2019 at 1:41 PM Wayne Stambaugh 
wrote:

> If you use `git am` to apply the patches, you wont get -dirty appended
> to the version string.  However, you will end up with -###-gcommithash
> appended so you still wont end up with 5.0.2 as the version string which
> is what I'm gessing Adam is looking for.
>
> On 1/18/19 2:33 PM, Nick Østergaard wrote:
> > Mmm, what is wrong wit the git describe when the patches are applied
> > with git am?
> >
> > fre. 18. jan. 2019 20.11 skrev Wayne Stambaugh  > >:
> >
> > This is a result of modifications to the repo.  The --dirty option of
> > `git describe` checks to see anything is modified and appends -dirty
> to
> > the version string.  This way we know if someone modified the source
> for
> > a given commit.  You could change the command in
> > CreateGitVersionHeader.cmake to `git descibe` to drop -dirty from the
> > version string.
> >
> > Wayne
> >
> > On 1/18/19 1:40 PM, Adam Wolf wrote:
> > > Hi Wayne!
> > >
> > > I have since fixed the ngspice build race condition on macOS. I
> have
> > > modified the build scripts so that patches occur via patch, not git
> > > itself.  Unfortunately, now the git version info shows
> > 5.0.2-dirty.  Is
> > > this how it shows on the Windows builds too?
> > >
> > > Adam Wolf
> > >
> > > On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf
> > mailto:adamw...@feelslikeburning.com
> >
> > >  > >> wrote:
> > >
> > > Alright.  Those changes are made.  I am doing builds now.
> > They are
> > > going to be 5.0.2-5 in order to ... reduce confusion.
> > >
> > > After builds, I need to upload them to testing/, download
> > them, run
> > > them through a test procedure that's in the README, and then
> > see if
> > > this fixes the issues for users.  If so, I will move the
> 5.0.2-5
> > > packages to stable/, and adjust the website.
> > >
> > > In the meantime, I am going to move the 5.0.2 packages out of
> the
> > > way on the server.  I'm getting multiple tickets a day for the
> > same
> > > issue and we don't need more people downloading the bad macOS
> > > package.  Once we have the new package up, we can put it back
> for
> > > posterity's sake or whatever.
> > >
> > > Adam
> > >
> > > On Tue, Jan 8, 2019 at 8:15 AM Adam Wolf
> > >  > 
> > >  > >> wrote:
> > >
> > > Thanks Wayne.  Will do.  I appreciate your fast response.
> > >
> > > Adam
> > >
> > > On Tue, Jan 8, 2019 at 7:58 AM Wayne Stambaugh
> > > mailto:stambau...@gmail.com>
> > >> wrote:
> > >
> > > Hey Adam,
> > >
> > > Rather than committing the macos build patches to the
> git
> > > repo, why not
> > > just run patch from the build script to apply them?
> This
> > > way you don't
> > > taint the git repo commit log and the version string
> > will be
> > > 5.0.2
> > > assuming that it the branch that you are building.
> > This is
> > > how we have
> > > done this in the past on other platforms.
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> > > On 1/8/2019 8:41 AM, Adam Wolf wrote:
> > > > Hi Wayne,
> > > >
> > > > I need a judgement call, and it's a little urgent.
> > > >
> > > > The current Mac packages call themselves 5.0.2, but
> the
> > > version
> > > > information inside is Version: (5.0.2-4-g3082e92af),
> > > release build.
> > > > This is because there are 4 patches applied to the
> 5.0.2
> > > source during
> > > > packaging.  These are exclusively for packaging
> changes,
> > > mostly to get
> > > > Python to work the way it needs to be
> > redistributable for
> > > 

Re: [Kicad-developers] Pulling mac 5.0.2...

[Wayne Stambaugh]

If you use `git am` to apply the patches, you wont get -dirty appended
to the version string.  However, you will end up with -###-gcommithash
appended so you still wont end up with 5.0.2 as the version string which
is what I'm gessing Adam is looking for.

On 1/18/19 2:33 PM, Nick Østergaard wrote:
> Mmm, what is wrong wit the git describe when the patches are applied
> with git am?
> 
> fre. 18. jan. 2019 20.11 skrev Wayne Stambaugh  >:
> 
> This is a result of modifications to the repo.  The --dirty option of
> `git describe` checks to see anything is modified and appends -dirty to
> the version string.  This way we know if someone modified the source for
> a given commit.  You could change the command in
> CreateGitVersionHeader.cmake to `git descibe` to drop -dirty from the
> version string.
> 
> Wayne
> 
> On 1/18/19 1:40 PM, Adam Wolf wrote:
> > Hi Wayne!
> >
> > I have since fixed the ngspice build race condition on macOS. I have
> > modified the build scripts so that patches occur via patch, not git
> > itself.  Unfortunately, now the git version info shows
> 5.0.2-dirty.  Is
> > this how it shows on the Windows builds too?
> >
> > Adam Wolf
> >
> > On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf
> mailto:adamw...@feelslikeburning.com>
> >  >> wrote:
> >
> >     Alright.  Those changes are made.  I am doing builds now. 
> They are
> >     going to be 5.0.2-5 in order to ... reduce confusion.
> >
> >     After builds, I need to upload them to testing/, download
> them, run
> >     them through a test procedure that's in the README, and then
> see if
> >     this fixes the issues for users.  If so, I will move the 5.0.2-5
> >     packages to stable/, and adjust the website.
> >
> >     In the meantime, I am going to move the 5.0.2 packages out of the
> >     way on the server.  I'm getting multiple tickets a day for the
> same
> >     issue and we don't need more people downloading the bad macOS
> >     package.  Once we have the new package up, we can put it back for
> >     posterity's sake or whatever.
> >
> >     Adam
> >
> >     On Tue, Jan 8, 2019 at 8:15 AM Adam Wolf
> >      
> >      >> wrote:
> >
> >         Thanks Wayne.  Will do.  I appreciate your fast response.
> >
> >         Adam
> >
> >         On Tue, Jan 8, 2019 at 7:58 AM Wayne Stambaugh
> >         mailto:stambau...@gmail.com>
> >> wrote:
> >
> >             Hey Adam,
> >
> >             Rather than committing the macos build patches to the git
> >             repo, why not
> >             just run patch from the build script to apply them?  This
> >             way you don't
> >             taint the git repo commit log and the version string
> will be
> >             5.0.2
> >             assuming that it the branch that you are building. 
> This is
> >             how we have
> >             done this in the past on other platforms.
> >
> >             Cheers,
> >
> >             Wayne
> >
> >             On 1/8/2019 8:41 AM, Adam Wolf wrote:
> >             > Hi Wayne,
> >             >
> >             > I need a judgement call, and it's a little urgent.
> >             >
> >             > The current Mac packages call themselves 5.0.2, but the
> >             version
> >             > information inside is Version: (5.0.2-4-g3082e92af),
> >             release build. 
> >             > This is because there are 4 patches applied to the 5.0.2
> >             source during
> >             > packaging.  These are exclusively for packaging changes,
> >             mostly to get
> >             > Python to work the way it needs to be
> redistributable for
> >             macOS. Without
> >             > these patches, kicad works, but it does not work in a
> >             redistributable
> >             > way.  If they were included in upstream, they
> wouldn't work at
> >             > all--unless folks also used the rest of the macOS build
> >             script.  Because
> >             > of this, I deemed it reasonable to include the
> patches in
> >             the macOS
> >             > build script process.
> >             >
> >             > I need to rerelease the 5.0.2 packages.  Normally,
> the way
> >             this would be
> >             > done on other projects is that I would make a 5.0.2-2
> >             release.  I
>

Re: [Kicad-developers] Pulling mac 5.0.2...

[Nick Østergaard]

Mmm, what is wrong wit the git describe when the patches are applied with
git am?

fre. 18. jan. 2019 20.11 skrev Wayne Stambaugh :

> This is a result of modifications to the repo.  The --dirty option of
> `git describe` checks to see anything is modified and appends -dirty to
> the version string.  This way we know if someone modified the source for
> a given commit.  You could change the command in
> CreateGitVersionHeader.cmake to `git descibe` to drop -dirty from the
> version string.
>
> Wayne
>
> On 1/18/19 1:40 PM, Adam Wolf wrote:
> > Hi Wayne!
> >
> > I have since fixed the ngspice build race condition on macOS. I have
> > modified the build scripts so that patches occur via patch, not git
> > itself.  Unfortunately, now the git version info shows 5.0.2-dirty.  Is
> > this how it shows on the Windows builds too?
> >
> > Adam Wolf
> >
> > On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf  > > wrote:
> >
> > Alright.  Those changes are made.  I am doing builds now.  They are
> > going to be 5.0.2-5 in order to ... reduce confusion.
> >
> > After builds, I need to upload them to testing/, download them, run
> > them through a test procedure that's in the README, and then see if
> > this fixes the issues for users.  If so, I will move the 5.0.2-5
> > packages to stable/, and adjust the website.
> >
> > In the meantime, I am going to move the 5.0.2 packages out of the
> > way on the server.  I'm getting multiple tickets a day for the same
> > issue and we don't need more people downloading the bad macOS
> > package.  Once we have the new package up, we can put it back for
> > posterity's sake or whatever.
> >
> > Adam
> >
> > On Tue, Jan 8, 2019 at 8:15 AM Adam Wolf
> >  > > wrote:
> >
> > Thanks Wayne.  Will do.  I appreciate your fast response.
> >
> > Adam
> >
> > On Tue, Jan 8, 2019 at 7:58 AM Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> >
> > Hey Adam,
> >
> > Rather than committing the macos build patches to the git
> > repo, why not
> > just run patch from the build script to apply them?  This
> > way you don't
> > taint the git repo commit log and the version string will be
> > 5.0.2
> > assuming that it the branch that you are building.  This is
> > how we have
> > done this in the past on other platforms.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 1/8/2019 8:41 AM, Adam Wolf wrote:
> > > Hi Wayne,
> > >
> > > I need a judgement call, and it's a little urgent.
> > >
> > > The current Mac packages call themselves 5.0.2, but the
> > version
> > > information inside is Version: (5.0.2-4-g3082e92af),
> > release build.
> > > This is because there are 4 patches applied to the 5.0.2
> > source during
> > > packaging.  These are exclusively for packaging changes,
> > mostly to get
> > > Python to work the way it needs to be redistributable for
> > macOS. Without
> > > these patches, kicad works, but it does not work in a
> > redistributable
> > > way.  If they were included in upstream, they wouldn't
> work at
> > > all--unless folks also used the rest of the macOS build
> > script.  Because
> > > of this, I deemed it reasonable to include the patches in
> > the macOS
> > > build script process.
> > >
> > > I need to rerelease the 5.0.2 packages.  Normally, the way
> > this would be
> > > done on other projects is that I would make a 5.0.2-2
> > release.  I
> > > actually built those this weekend, but the problem is that
> > folks could
> > > definitely think they are already running 5.0.2-4.
> > >
> > > I thought, oh, ok! For release builds, we should override
> > the git
> > > version string, and burn in what we're building, so that
> > would just say
> > > Version: (5.0.2), release build.  It appears we cannot
> > override the git
> > > generated part, only append to the end.
> > >
> > > Normally I'd throw this to the list and wait a while for
> > consensus, but
> > > many Mac users are reporting issues with the current 5.0.2
> > package and
> > > it needs to be replaced as soon as we can.
> > >
> > > One option would be to "fix it for this release" by adding
> > yet another
> > > patch that makes it so the 

Re: [Kicad-developers] Pulling mac 5.0.2...

[Wayne Stambaugh]

This is a result of modifications to the repo.  The --dirty option of
`git describe` checks to see anything is modified and appends -dirty to
the version string.  This way we know if someone modified the source for
a given commit.  You could change the command in
CreateGitVersionHeader.cmake to `git descibe` to drop -dirty from the
version string.

Wayne

On 1/18/19 1:40 PM, Adam Wolf wrote:
> Hi Wayne!
> 
> I have since fixed the ngspice build race condition on macOS. I have
> modified the build scripts so that patches occur via patch, not git
> itself.  Unfortunately, now the git version info shows 5.0.2-dirty.  Is
> this how it shows on the Windows builds too?
> 
> Adam Wolf
> 
> On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf  > wrote:
> 
> Alright.  Those changes are made.  I am doing builds now.  They are
> going to be 5.0.2-5 in order to ... reduce confusion.
> 
> After builds, I need to upload them to testing/, download them, run
> them through a test procedure that's in the README, and then see if
> this fixes the issues for users.  If so, I will move the 5.0.2-5
> packages to stable/, and adjust the website.
> 
> In the meantime, I am going to move the 5.0.2 packages out of the
> way on the server.  I'm getting multiple tickets a day for the same
> issue and we don't need more people downloading the bad macOS
> package.  Once we have the new package up, we can put it back for
> posterity's sake or whatever.
> 
> Adam
> 
> On Tue, Jan 8, 2019 at 8:15 AM Adam Wolf
>  > wrote:
> 
> Thanks Wayne.  Will do.  I appreciate your fast response.
> 
> Adam
> 
> On Tue, Jan 8, 2019 at 7:58 AM Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> 
> Hey Adam,
> 
> Rather than committing the macos build patches to the git
> repo, why not
> just run patch from the build script to apply them?  This
> way you don't
> taint the git repo commit log and the version string will be
> 5.0.2
> assuming that it the branch that you are building.  This is
> how we have
> done this in the past on other platforms.
> 
> Cheers,
> 
> Wayne
> 
> On 1/8/2019 8:41 AM, Adam Wolf wrote:
> > Hi Wayne,
> >
> > I need a judgement call, and it's a little urgent.
> >
> > The current Mac packages call themselves 5.0.2, but the
> version
> > information inside is Version: (5.0.2-4-g3082e92af),
> release build. 
> > This is because there are 4 patches applied to the 5.0.2
> source during
> > packaging.  These are exclusively for packaging changes,
> mostly to get
> > Python to work the way it needs to be redistributable for
> macOS. Without
> > these patches, kicad works, but it does not work in a
> redistributable
> > way.  If they were included in upstream, they wouldn't work at
> > all--unless folks also used the rest of the macOS build
> script.  Because
> > of this, I deemed it reasonable to include the patches in
> the macOS
> > build script process.
> >
> > I need to rerelease the 5.0.2 packages.  Normally, the way
> this would be
> > done on other projects is that I would make a 5.0.2-2
> release.  I
> > actually built those this weekend, but the problem is that
> folks could
> > definitely think they are already running 5.0.2-4.
> >
> > I thought, oh, ok! For release builds, we should override
> the git
> > version string, and burn in what we're building, so that
> would just say
> > Version: (5.0.2), release build.  It appears we cannot
> override the git
> > generated part, only append to the end.
> >
> > Normally I'd throw this to the list and wait a while for
> consensus, but
> > many Mac users are reporting issues with the current 5.0.2
> package and
> > it needs to be replaced as soon as we can.
> >
> > One option would be to "fix it for this release" by adding
> yet another
> > patch that makes it so the gitversion can be overridden,
> make a 5.0.2-5
> > release, and get those patches upstreamed behind some
> conditionals
> > before the next release, so that the gitversion, next
> time, will be 5.1
> > or 5.0.3 or whatever, and then I could append a -2 or
> 

Re: [Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

Hi Wayne!

I have since fixed the ngspice build race condition on macOS. I have
modified the build scripts so that patches occur via patch, not git
itself.  Unfortunately, now the git version info shows 5.0.2-dirty.  Is
this how it shows on the Windows builds too?

Adam Wolf

On Tue, Jan 8, 2019 at 9:05 AM Adam Wolf 
wrote:

> Alright.  Those changes are made.  I am doing builds now.  They are going
> to be 5.0.2-5 in order to ... reduce confusion.
>
> After builds, I need to upload them to testing/, download them, run them
> through a test procedure that's in the README, and then see if this fixes
> the issues for users.  If so, I will move the 5.0.2-5 packages to stable/,
> and adjust the website.
>
> In the meantime, I am going to move the 5.0.2 packages out of the way on
> the server.  I'm getting multiple tickets a day for the same issue and we
> don't need more people downloading the bad macOS package.  Once we have the
> new package up, we can put it back for posterity's sake or whatever.
>
> Adam
>
> On Tue, Jan 8, 2019 at 8:15 AM Adam Wolf 
> wrote:
>
>> Thanks Wayne.  Will do.  I appreciate your fast response.
>>
>> Adam
>>
>> On Tue, Jan 8, 2019 at 7:58 AM Wayne Stambaugh 
>> wrote:
>>
>>> Hey Adam,
>>>
>>> Rather than committing the macos build patches to the git repo, why not
>>> just run patch from the build script to apply them?  This way you don't
>>> taint the git repo commit log and the version string will be 5.0.2
>>> assuming that it the branch that you are building.  This is how we have
>>> done this in the past on other platforms.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 1/8/2019 8:41 AM, Adam Wolf wrote:
>>> > Hi Wayne,
>>> >
>>> > I need a judgement call, and it's a little urgent.
>>> >
>>> > The current Mac packages call themselves 5.0.2, but the version
>>> > information inside is Version: (5.0.2-4-g3082e92af), release build.
>>> > This is because there are 4 patches applied to the 5.0.2 source during
>>> > packaging.  These are exclusively for packaging changes, mostly to get
>>> > Python to work the way it needs to be redistributable for macOS.
>>> Without
>>> > these patches, kicad works, but it does not work in a redistributable
>>> > way.  If they were included in upstream, they wouldn't work at
>>> > all--unless folks also used the rest of the macOS build script.
>>> Because
>>> > of this, I deemed it reasonable to include the patches in the macOS
>>> > build script process.
>>> >
>>> > I need to rerelease the 5.0.2 packages.  Normally, the way this would
>>> be
>>> > done on other projects is that I would make a 5.0.2-2 release.  I
>>> > actually built those this weekend, but the problem is that folks could
>>> > definitely think they are already running 5.0.2-4.
>>> >
>>> > I thought, oh, ok! For release builds, we should override the git
>>> > version string, and burn in what we're building, so that would just say
>>> > Version: (5.0.2), release build.  It appears we cannot override the git
>>> > generated part, only append to the end.
>>> >
>>> > Normally I'd throw this to the list and wait a while for consensus, but
>>> > many Mac users are reporting issues with the current 5.0.2 package and
>>> > it needs to be replaced as soon as we can.
>>> >
>>> > One option would be to "fix it for this release" by adding yet another
>>> > patch that makes it so the gitversion can be overridden, make a 5.0.2-5
>>> > release, and get those patches upstreamed behind some conditionals
>>> > before the next release, so that the gitversion, next time, will be 5.1
>>> > or 5.0.3 or whatever, and then I could append a -2 or whatever if this
>>> > happens in the future...
>>> >
>>> > Thoughts?
>>> >
>>> > Adam Wolf
>>> >
>>> >
>>> > On Mon, Jan 7, 2019 at 7:42 PM Adam Wolf <
>>> adamw...@feelslikeburning.com
>>> > > wrote:
>>> >
>>> > It looks like there's something wrong with the shared library
>>> > references of just the 5.0.2 packages.  They were generated using
>>> > the build script, but not 100% automatically.  I've set Jenkins up
>>> > to build those too, which should help reduce human error next time.
>>> >
>>> > This is assuming I fatfingered something in the build.
>>> >
>>> > The nighties and 5.0.1 seem fine.
>>> >
>>> > I have a contract delivery this week, and things are a little
>>> > frantic, but I should still be able to get this fixed.
>>> >
>>> > Adam
>>> >
>>> > On Mon, Jan 7, 2019, 5:46 PM Andy Peters >> >  wrote:
>>> >
>>> >
>>> >
>>> > > On Jan 7, 2019, at 3:20 PM, Adam Wolf
>>> > >> > > wrote:
>>> > >
>>> > > Hi folks!
>>> > >
>>> > > Just a heads up, the macos 5.0.2 packages are gross for some
>>> > reason.  I am regenerating them and we'll see what's going on.
>>> > >
>>> > > (I am regenerating them at 5.0.2-2)
>>> >
>>> > Gross in what 

Re: [Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

Alright.  Those changes are made.  I am doing builds now.  They are going
to be 5.0.2-5 in order to ... reduce confusion.

After builds, I need to upload them to testing/, download them, run them
through a test procedure that's in the README, and then see if this fixes
the issues for users.  If so, I will move the 5.0.2-5 packages to stable/,
and adjust the website.

In the meantime, I am going to move the 5.0.2 packages out of the way on
the server.  I'm getting multiple tickets a day for the same issue and we
don't need more people downloading the bad macOS package.  Once we have the
new package up, we can put it back for posterity's sake or whatever.

Adam

On Tue, Jan 8, 2019 at 8:15 AM Adam Wolf 
wrote:

> Thanks Wayne.  Will do.  I appreciate your fast response.
>
> Adam
>
> On Tue, Jan 8, 2019 at 7:58 AM Wayne Stambaugh 
> wrote:
>
>> Hey Adam,
>>
>> Rather than committing the macos build patches to the git repo, why not
>> just run patch from the build script to apply them?  This way you don't
>> taint the git repo commit log and the version string will be 5.0.2
>> assuming that it the branch that you are building.  This is how we have
>> done this in the past on other platforms.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 1/8/2019 8:41 AM, Adam Wolf wrote:
>> > Hi Wayne,
>> >
>> > I need a judgement call, and it's a little urgent.
>> >
>> > The current Mac packages call themselves 5.0.2, but the version
>> > information inside is Version: (5.0.2-4-g3082e92af), release build.
>> > This is because there are 4 patches applied to the 5.0.2 source during
>> > packaging.  These are exclusively for packaging changes, mostly to get
>> > Python to work the way it needs to be redistributable for macOS. Without
>> > these patches, kicad works, but it does not work in a redistributable
>> > way.  If they were included in upstream, they wouldn't work at
>> > all--unless folks also used the rest of the macOS build script.  Because
>> > of this, I deemed it reasonable to include the patches in the macOS
>> > build script process.
>> >
>> > I need to rerelease the 5.0.2 packages.  Normally, the way this would be
>> > done on other projects is that I would make a 5.0.2-2 release.  I
>> > actually built those this weekend, but the problem is that folks could
>> > definitely think they are already running 5.0.2-4.
>> >
>> > I thought, oh, ok! For release builds, we should override the git
>> > version string, and burn in what we're building, so that would just say
>> > Version: (5.0.2), release build.  It appears we cannot override the git
>> > generated part, only append to the end.
>> >
>> > Normally I'd throw this to the list and wait a while for consensus, but
>> > many Mac users are reporting issues with the current 5.0.2 package and
>> > it needs to be replaced as soon as we can.
>> >
>> > One option would be to "fix it for this release" by adding yet another
>> > patch that makes it so the gitversion can be overridden, make a 5.0.2-5
>> > release, and get those patches upstreamed behind some conditionals
>> > before the next release, so that the gitversion, next time, will be 5.1
>> > or 5.0.3 or whatever, and then I could append a -2 or whatever if this
>> > happens in the future...
>> >
>> > Thoughts?
>> >
>> > Adam Wolf
>> >
>> >
>> > On Mon, Jan 7, 2019 at 7:42 PM Adam Wolf > > > wrote:
>> >
>> > It looks like there's something wrong with the shared library
>> > references of just the 5.0.2 packages.  They were generated using
>> > the build script, but not 100% automatically.  I've set Jenkins up
>> > to build those too, which should help reduce human error next time.
>> >
>> > This is assuming I fatfingered something in the build.
>> >
>> > The nighties and 5.0.1 seem fine.
>> >
>> > I have a contract delivery this week, and things are a little
>> > frantic, but I should still be able to get this fixed.
>> >
>> > Adam
>> >
>> > On Mon, Jan 7, 2019, 5:46 PM Andy Peters > >  wrote:
>> >
>> >
>> >
>> > > On Jan 7, 2019, at 3:20 PM, Adam Wolf
>> > > > > wrote:
>> > >
>> > > Hi folks!
>> > >
>> > > Just a heads up, the macos 5.0.2 packages are gross for some
>> > reason.  I am regenerating them and we'll see what's going on.
>> > >
>> > > (I am regenerating them at 5.0.2-2)
>> >
>> > Gross in what way? I haven’t pulled down a nightly in a couple
>> > of weeks.
>> >
>> > -a
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > 
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>> > 

Re: [Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

Thanks Wayne.  Will do.  I appreciate your fast response.

Adam

On Tue, Jan 8, 2019 at 7:58 AM Wayne Stambaugh  wrote:

> Hey Adam,
>
> Rather than committing the macos build patches to the git repo, why not
> just run patch from the build script to apply them?  This way you don't
> taint the git repo commit log and the version string will be 5.0.2
> assuming that it the branch that you are building.  This is how we have
> done this in the past on other platforms.
>
> Cheers,
>
> Wayne
>
> On 1/8/2019 8:41 AM, Adam Wolf wrote:
> > Hi Wayne,
> >
> > I need a judgement call, and it's a little urgent.
> >
> > The current Mac packages call themselves 5.0.2, but the version
> > information inside is Version: (5.0.2-4-g3082e92af), release build.
> > This is because there are 4 patches applied to the 5.0.2 source during
> > packaging.  These are exclusively for packaging changes, mostly to get
> > Python to work the way it needs to be redistributable for macOS. Without
> > these patches, kicad works, but it does not work in a redistributable
> > way.  If they were included in upstream, they wouldn't work at
> > all--unless folks also used the rest of the macOS build script.  Because
> > of this, I deemed it reasonable to include the patches in the macOS
> > build script process.
> >
> > I need to rerelease the 5.0.2 packages.  Normally, the way this would be
> > done on other projects is that I would make a 5.0.2-2 release.  I
> > actually built those this weekend, but the problem is that folks could
> > definitely think they are already running 5.0.2-4.
> >
> > I thought, oh, ok! For release builds, we should override the git
> > version string, and burn in what we're building, so that would just say
> > Version: (5.0.2), release build.  It appears we cannot override the git
> > generated part, only append to the end.
> >
> > Normally I'd throw this to the list and wait a while for consensus, but
> > many Mac users are reporting issues with the current 5.0.2 package and
> > it needs to be replaced as soon as we can.
> >
> > One option would be to "fix it for this release" by adding yet another
> > patch that makes it so the gitversion can be overridden, make a 5.0.2-5
> > release, and get those patches upstreamed behind some conditionals
> > before the next release, so that the gitversion, next time, will be 5.1
> > or 5.0.3 or whatever, and then I could append a -2 or whatever if this
> > happens in the future...
> >
> > Thoughts?
> >
> > Adam Wolf
> >
> >
> > On Mon, Jan 7, 2019 at 7:42 PM Adam Wolf  > > wrote:
> >
> > It looks like there's something wrong with the shared library
> > references of just the 5.0.2 packages.  They were generated using
> > the build script, but not 100% automatically.  I've set Jenkins up
> > to build those too, which should help reduce human error next time.
> >
> > This is assuming I fatfingered something in the build.
> >
> > The nighties and 5.0.1 seem fine.
> >
> > I have a contract delivery this week, and things are a little
> > frantic, but I should still be able to get this fixed.
> >
> > Adam
> >
> > On Mon, Jan 7, 2019, 5:46 PM Andy Peters  >  wrote:
> >
> >
> >
> > > On Jan 7, 2019, at 3:20 PM, Adam Wolf
> >  > > wrote:
> > >
> > > Hi folks!
> > >
> > > Just a heads up, the macos 5.0.2 packages are gross for some
> > reason.  I am regenerating them and we'll see what's going on.
> > >
> > > (I am regenerating them at 5.0.2-2)
> >
> > Gross in what way? I haven’t pulled down a nightly in a couple
> > of weeks.
> >
> > -a
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pulling mac 5.0.2...

[Wayne Stambaugh]

Hey Adam,

Rather than committing the macos build patches to the git repo, why not
just run patch from the build script to apply them?  This way you don't
taint the git repo commit log and the version string will be 5.0.2
assuming that it the branch that you are building.  This is how we have
done this in the past on other platforms.

Cheers,

Wayne

On 1/8/2019 8:41 AM, Adam Wolf wrote:
> Hi Wayne,
> 
> I need a judgement call, and it's a little urgent.
> 
> The current Mac packages call themselves 5.0.2, but the version
> information inside is Version: (5.0.2-4-g3082e92af), release build. 
> This is because there are 4 patches applied to the 5.0.2 source during
> packaging.  These are exclusively for packaging changes, mostly to get
> Python to work the way it needs to be redistributable for macOS. Without
> these patches, kicad works, but it does not work in a redistributable
> way.  If they were included in upstream, they wouldn't work at
> all--unless folks also used the rest of the macOS build script.  Because
> of this, I deemed it reasonable to include the patches in the macOS
> build script process.
> 
> I need to rerelease the 5.0.2 packages.  Normally, the way this would be
> done on other projects is that I would make a 5.0.2-2 release.  I
> actually built those this weekend, but the problem is that folks could
> definitely think they are already running 5.0.2-4.
> 
> I thought, oh, ok! For release builds, we should override the git
> version string, and burn in what we're building, so that would just say
> Version: (5.0.2), release build.  It appears we cannot override the git
> generated part, only append to the end.
> 
> Normally I'd throw this to the list and wait a while for consensus, but
> many Mac users are reporting issues with the current 5.0.2 package and
> it needs to be replaced as soon as we can.
> 
> One option would be to "fix it for this release" by adding yet another
> patch that makes it so the gitversion can be overridden, make a 5.0.2-5
> release, and get those patches upstreamed behind some conditionals
> before the next release, so that the gitversion, next time, will be 5.1
> or 5.0.3 or whatever, and then I could append a -2 or whatever if this
> happens in the future...
> 
> Thoughts?
> 
> Adam Wolf
> 
> 
> On Mon, Jan 7, 2019 at 7:42 PM Adam Wolf  > wrote:
> 
> It looks like there's something wrong with the shared library
> references of just the 5.0.2 packages.  They were generated using
> the build script, but not 100% automatically.  I've set Jenkins up
> to build those too, which should help reduce human error next time.
> 
> This is assuming I fatfingered something in the build.
> 
> The nighties and 5.0.1 seem fine.
> 
> I have a contract delivery this week, and things are a little
> frantic, but I should still be able to get this fixed.
> 
> Adam
> 
> On Mon, Jan 7, 2019, 5:46 PM Andy Peters   wrote:
> 
> 
> 
> > On Jan 7, 2019, at 3:20 PM, Adam Wolf
>  > wrote:
> >
> > Hi folks!
> >
> > Just a heads up, the macos 5.0.2 packages are gross for some
> reason.  I am regenerating them and we'll see what's going on.
> >
> > (I am regenerating them at 5.0.2-2)
> 
> Gross in what way? I haven’t pulled down a nightly in a couple
> of weeks.
> 
> -a
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

Hi Wayne,

I need a judgement call, and it's a little urgent.

The current Mac packages call themselves 5.0.2, but the version information
inside is Version: (5.0.2-4-g3082e92af), release build.  This is because
there are 4 patches applied to the 5.0.2 source during packaging.  These
are exclusively for packaging changes, mostly to get Python to work the way
it needs to be redistributable for macOS. Without these patches, kicad
works, but it does not work in a redistributable way.  If they were
included in upstream, they wouldn't work at all--unless folks also used the
rest of the macOS build script.  Because of this, I deemed it reasonable to
include the patches in the macOS build script process.

I need to rerelease the 5.0.2 packages.  Normally, the way this would be
done on other projects is that I would make a 5.0.2-2 release.  I actually
built those this weekend, but the problem is that folks could definitely
think they are already running 5.0.2-4.

I thought, oh, ok! For release builds, we should override the git version
string, and burn in what we're building, so that would just say Version:
(5.0.2), release build.  It appears we cannot override the git generated
part, only append to the end.

Normally I'd throw this to the list and wait a while for consensus, but
many Mac users are reporting issues with the current 5.0.2 package and it
needs to be replaced as soon as we can.

One option would be to "fix it for this release" by adding yet another
patch that makes it so the gitversion can be overridden, make a 5.0.2-5
release, and get those patches upstreamed behind some conditionals before
the next release, so that the gitversion, next time, will be 5.1 or 5.0.3
or whatever, and then I could append a -2 or whatever if this happens in
the future...

Thoughts?

Adam Wolf


On Mon, Jan 7, 2019 at 7:42 PM Adam Wolf 
wrote:

> It looks like there's something wrong with the shared library references
> of just the 5.0.2 packages.  They were generated using the build script,
> but not 100% automatically.  I've set Jenkins up to build those too, which
> should help reduce human error next time.
>
> This is assuming I fatfingered something in the build.
>
> The nighties and 5.0.1 seem fine.
>
> I have a contract delivery this week, and things are a little frantic, but
> I should still be able to get this fixed.
>
> Adam
>
> On Mon, Jan 7, 2019, 5:46 PM Andy Peters 
>>
>>
>> > On Jan 7, 2019, at 3:20 PM, Adam Wolf 
>> wrote:
>> >
>> > Hi folks!
>> >
>> > Just a heads up, the macos 5.0.2 packages are gross for some reason.  I
>> am regenerating them and we'll see what's going on.
>> >
>> > (I am regenerating them at 5.0.2-2)
>>
>> Gross in what way? I haven’t pulled down a nightly in a couple of weeks.
>>
>> -a
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

It looks like there's something wrong with the shared library references of
just the 5.0.2 packages.  They were generated using the build script, but
not 100% automatically.  I've set Jenkins up to build those too, which
should help reduce human error next time.

This is assuming I fatfingered something in the build.

The nighties and 5.0.1 seem fine.

I have a contract delivery this week, and things are a little frantic, but
I should still be able to get this fixed.

Adam

On Mon, Jan 7, 2019, 5:46 PM Andy Peters 
>
> > On Jan 7, 2019, at 3:20 PM, Adam Wolf 
> wrote:
> >
> > Hi folks!
> >
> > Just a heads up, the macos 5.0.2 packages are gross for some reason.  I
> am regenerating them and we'll see what's going on.
> >
> > (I am regenerating them at 5.0.2-2)
>
> Gross in what way? I haven’t pulled down a nightly in a couple of weeks.
>
> -a
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pulling mac 5.0.2...

[Andy Peters]

> On Jan 7, 2019, at 3:20 PM, Adam Wolf  wrote:
> 
> Hi folks!
> 
> Just a heads up, the macos 5.0.2 packages are gross for some reason.  I am 
> regenerating them and we'll see what's going on.
> 
> (I am regenerating them at 5.0.2-2)

Gross in what way? I haven’t pulled down a nightly in a couple of weeks.

-a
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp