Vít Ondruch wrote on 2022/01/18 17:15:
Dne 18. 01. 22 v 8:44 Mamoru TASAKA napsal(a):
> Vít Ondruch wrote on 2022/01/18 0:15:
>> Hi,
>>
>> It is time of the year when new version of Ruby was released upstream and we
should land it in Fedora. Unfortunately, the change proposal was approved just last
Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the
failing test cases for the moment and hope for the best). So this brings us into
situation, where won't have enough time prior Fedora Mass rebuild. I have discussed
this a bit with relengs and one of the options would be to build Ruby early during the
mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild
ticket [2]. One downside would be that in case of problems, we could not trigger our
contingency plan, which is "drop our side tag". But I hope we won't need
that.
>>
>> Any thoughts?
>>
>> My fist concern is that maybe we should build more then just Ruby. rubygem-json
comes to my mind and possibly rubygem-nokogiri?
>>
>> Vít
>>
>>
>> [1]
https://bugzilla.redhat.com/show_bug.cgi?id=2040380
>> [2]
https://pagure.io/releng/issue/10538#comment-775197
>>
>
> My light idea is that as "Change Checkpoint" and "Branch Fedora Linux
36 from Rawhide" happends
> on 2022/Feb/08 (Tue),
Please note that this also marks end of mass rebuild phase.
> I think we have enough time even if we start rebuilding with ruby31 beginning at,
> say, 2022/Jan/24 (Mon) or Jan/25
Right, I agree.
> (if mass rebuild "really" begins tomorrow).
Yeah, this worries me, because I think that there used to be delays for past several
occasions.
Or, once we can determine we wait rebuild until 2022/Jan/24 (Mon) or so on, and
if mass rebuild doesn't go well by that day, we will force ruby rebuild anyway, for
example.
One note:
At least side-tag build can be done (queued) from the branch other than rawhide/main,
(by specifying --release explicitly, like $ fedpkg --release f36 build --target
f36-build-side-XXXXXX )
So you can
- push ruby 3.1 change to ruby.git other than rawhide branch (say ruby31-temp branch)
- create side-tag for ruby rebuild, build ruby3.1 on that side-tag from ruby.git
ruby31-temp branch
- At this time, mass rebuild can happen, but mass rebuild will happen using rawhide/main
branch,
so mass rebuild will be done using ruby3.0
- If that happen, merge rawhide and ruby31-temp (anyway), rebuild again on ruby31
side-tag
- Then later, push bodhi to merge side-tag builds into rawhide
BTW Is your preference based on your availability or is that just
considering the schedule and processes or what not?
Well, for my availability, although I cannot spare full time on ruby work (as I have my
"daily" work),
currently I have no worry for this and I can do rebuild of ruby related srpms at my own
pace
for the time being.
So I am just considering the schedule for now.
Thx
Vít
Regards,
Mamoru