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 t
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
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 pl
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
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
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
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 o
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
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 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 `gi
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
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,
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
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
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 exclusivel
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 some
> 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 coup
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)
Should we pull the download temporarily? It may be a day or two before I
get the good packages up.
I apologize to everyone.
19 matches
Mail list logo
