Re: plan to update F27 to systemd-235

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 8, 2017 at 8:19 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
> On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
>> On Sat, Oct 7, 2017, at 08:14 AM, Zbigniew Jędrzejewski-Szmek wrote:
>>
>> > Well, my point is that in this case there aren't any big changes, only> some relatively minor feature additions. According to the policy,
>> > "minor" upgrades are OK after beta. The only difference for critical
>> > path packages is some additional karma requirements.
>>
>> I'm personally very in favor of this; of course my usual refrain
>> here is that we should *try* new things and have the ability
>> to back them out if they don't work (the latter bit is what the
>> current system doesn't support).
>
> That's a valid point. Going back to the previous version will not be
> very nice. So yeah, if the updated version leaves updates-testing,
> I'd prefer not to go back. If it later turns out to be absolutely
> necessary, I'd rather just build a bastard v235 with a number of
> patches reverted, rather than bump the epoch. This sounds worse than
> it is, since current "v234" in F27 already has some user-visible stuff
> backported, so it'd be a change of degree, not kind.
>
>> > The formal side is pretty clear. Instead, I'm giving the heads up in
>> > case any technical issues or regressions crop up. I'm especially
>> > interested in feedback from people who run rawhide, especially if they> use various container technologies, namespaces, and such, which is
>> > probably the area most like to regress.
>>
>> Yes that said...things like the systemd-nspawn changing to
>> a syscall whitelist seems highly likely to aggravate the current
>> problems with mock:
>> https://pagure.io/releng/issue/6967
>>
>> See also https://pagure.io/releng/issue/6602#comment-71214
>> From a while ago.  We go to quite a bit of effort in the rpm-ostree side
>> to work around oddities from running in nspawn.
>> https://github.com/projectatomic/bubblewrap/issues/171#issuecomment-27773181[1]Was also really fun.
>>
>> Basically nspawn isn’t very focused on the privileged/recursive
>> container case.  And while nspawn is OK for building RPMs, other cases
>> like Lorax and rpm-ostree need more privileges.
>
> Yeah, those are all hard issues. There's no clear single thing to fix,
> but rather a number of adjustments in various projects will be needed.
> That said, afaik, builders do not run the latest Fedora, so they wouldn't
> be affected by an update of systemd, at least not in the near future?
>

Release Engineering will likely be forced to upgrade the builders to
Fedora 27 shortly after it releases, because we'll need the new RPM
and DNF on the builders for transitioning to all-DNF based releng
tooling as well as allowing rich deps in BuildRequires.

That said, the simple solution (that releng is using now) is to patch
mock back to using regular chroots until mock and nspawn play nice for
image and rpm-ostree composes.


-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux