kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 8/4/19 11:07 AM, Steven A. Falco wrote:
> On 8/3/19 1:00 PM, Seth Hillbrand wrote:
>> On 2019-08-03 11:12, Wayne Stambaugh wrote:
>>> On 8/2/19 5:18 PM, Steven A. Falco wrote:
>>>> On 8/2/19 3:05 PM, Wayne Stambaugh wrote:
>>>>> Looks like we will be forgoing a 5.1.3 release and jumping to 5.1.4.
>>>>> This bug is a definite show stopper.  We need to do a better job of
>>>>> testing fixes before we merge them into the 5.1 branch.  Maybe we need
>>>>> to start doing release candidates on the stable branch before releasing
>>>>> buggy bug fixes?  For those packagers who are providing 5.1.3 for
>>>>> distos, I would avoid releasing it.
>>>>
>>>> I'm attempting to stop 5.1.3 from moving into Fedora.  I may need a Fedora admin to grant me additional privileges to do so, since the build has already entered the package queue.
>>>>
>>>> I'll wait for 5.1.4 to be tagged and then I'll start up a new build.
>>>>
>>>> As to Wayne having to delay his announcement because of insufficient Fedora karma, I'll request that people on this list test and give karma for future builds.  Just three positive votes will be sufficient to expedite release.
>>>>
>>>> As to the discussion from https://bugs.launchpad.net/kicad/+bug/1838448 I've now had two folks working for RedHat advise me not to circumvent the _GLIBCXX_ASSERTIONS, because of security concerns related to buffer overflows.  So I think in the interest of safety, I need to leave those asserts in place.
>>>>
>>>>     Steve
>>>>
>>>
>>> I think I found a solution.  I can tag commit
>>> 090073cc3b79f4f646f3c82390eb02a253e488d8 as 5.1.4.  No translations are
>>> required so we should be able to tag the translations, libs, and docs at
>>> the same commit as the 5.1.3 tag.  This would only require updating the
>>> builds and stable release announcement.  Unfortunately this doesn't
>>> solve the assertion issue on Fedora.  If I include the commits that fix
>>> the Fedora issue, we will have to wait for the translations because
>>> there are a bunch of string changes after commit
>>> cf949609b25a43b66b985baab8ae5354ad8510ae so including them would push
>>> back the release significantly.  If there are no objections, I will tag
>>> 5.1.4 today so we can get moving on a new stable release.
>>>
>>> Cheers,
>>>
>>> Wayne
>>
>> Hi Wayne-
>>
>> We could revert the commits post 090073cc3b79f4f646f3c82390eb02a253e488d8 that changed strings and then tag 5.1.4 and re-commit the reverts.  Not pretty but it for a one-off, it might not be so bad.
>>
>> -Seth
> 
> Wayne - have you decided to tag 090073cc3b79f4f646f3c82390eb02a253e488d8 as 5.1.4 or follow Seth's approach?
> 
> I was able to stop 5.1.3 from being released in Fedora 30, but I was _not_ able to stop it from being released in Fedora Rawhide.
> 
> If 5.1.4 will be tagged soon, then that will fix Rawhide.  If 5.1.4 will be delayed significantly, then I will probably need to do something semi-ugly (involving a permanent Epoch change) in order to force Rawhide to downgrade to 5.1.2.  How critical is the bug that was found in 5.1.3?
> 
> 	Steve
> 

I decided to revert all of the commits that contained UI string changes
and tagged 5.1.4.  It's ugly but it contains the Fedora fix along with
the update footprint position fix.  I already uploaded the source
archive and started a 5.1.5 milestone.  Please tag the doc, translation,
and library repos to 5.1.4 using the same commit as 5.1.3.  I'll update
the release announcement and there will be no official 5.1.3 release.
Thank you everyone for your cooperation and patience.

Cheers,

Wayne