kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #38898
Re: Pulling mac 5.0.2...
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 <adamwolf@xxxxxxxxxxxxxxxxxxxx
> <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>> 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 <devel@xxxxxxxxx
> <mailto:devel@xxxxxxxxx> wrote:
>
>
>
> > On Jan 7, 2019, at 3:20 PM, Adam Wolf
> <adamwolf@xxxxxxxxxxxxxxxxxxxx
> <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References