FBR MBS: Fix traceback when reusing components from module build with different buildrequires.
Hi,
this is FBR to fix MBS traceback which prevents builds of modules in situation
when new build-require is added to a module Foo. Currently, MBS tries to check
what was the commit hash ("ref") of such buildrequired module in previous build
of Foo, but it fails with KeyError, because the previous Foo module build did
not build-required this newly added build-required module.
Full traceback is here:
Traceback (most recent call last):
File
"/usr/lib/python2.7/site-packages/module_build_service/scheduler/consumer.py",
line 240, in process_message
further_work = handler(conf, session, msg) or []
File
"/usr/lib/python2.7/site-packages/module_build_service/scheduler/handlers/modules.py",
line 292, in wait
if attempt_to_reuse_all_components(builder, session, build):
File "/usr/lib/python2.7/site-packages/module_build_service/utils/reuse.py",
line 140, in attempt_to_reuse_all_components
previous_module_build = _get_reusable_module(session, module)
File "/usr/lib/python2.7/site-packages/module_build_service/utils/reuse.py",
line 123, in _get_reusable_module
ref2 = old_xmd['mbs']['buildrequires'][br_module_name].get('ref')
KeyError: 'platform'
Fixed patch [1] addresses this by catching the KeyError in this code block. It
has been tested on staging and I verified it fixes this issue.
[1]
https://src.fedoraproject.org/rpms/module-build-service/c/9d3a4923631efca2f9e7e3baf6b1bf15294d66fd?branch=epel7
Regards,
Jan Kaluza
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: [PATCH] mbs: remove gcc/gcc-c++ from buildroot
+1 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/KX46KFQ7V4XLX5RBNFZT7657JDOGS25J/
FBR: Apply MBS PR#1185 to fix Module Stream Expansion with new platform streams
Hi, Mohan filled MBS issue https://pagure.io/fm-orchestrator/issue/1184 and asked us to fix and deploy that during the freeze to unblock him. I therefore want to ask for +1 to deploy this small patch (already merged upstream): https://pagure.io/fm-orchestrator/pull-request/1185#request_diff . I think the issue is well described in the PR, unit-test and MBS issue tracker, so I won't repeat myself here. I hope that's OK. Regards, Jan Kaluza ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: Apply MBS PR#1185 to fix Module Stream Expansion with new platform streams
> On Wed, 27 Mar 2019 at 02:02, Jan Kaluža > I don't see this causing a breakage now, but I am wondering if the > test is 'fragile' because once those versions are EOL, then won't it > break because various tools (pdc/bodhi) may return something up the > stack that you can't build against it anyway? I'm not sure we have addressed this issue generally. Grepping the code for "EOL" and similar things only shows that you cannot submit module once it is EOL, but I was not able to find out any code which would prevent you to building module against EOLed module. I will ask Matt Prahl who should know more and create ticket to address that if it's needed. But I think it is not blocker for this FBR. Regards, Jan Kaluza ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Upgrading ODCS prod (hopefully) next week.
Hi, last few weeks, I was working on ODCS upgrade in staging. This is done now and I would like to do the same upgrade in prod. The ODCS running in Fedora prod infra is quite old and lot of things changed in the upstream. Therefore this upgrade is somehow big and I presume the service will not be running for few hours. The key changes in ODCS infrastructure will be: - ODCS prod VMs will be redeployed to upgrade to Fedora 30. - ODCS will stop using fedmsg-hub and starts using fedora-messaging. - ODCS will start using Celery over fedora-infrastructure's RabbitMQ for job planning. - Upgrade to latest ODCS and Pungi will be done. All of that is already done and tested on staging infrastructure. The service is currently used mainly by OSBS to build flatpak images and therefore I presume the flatpak builds will fail during this upgrade. I will coordinate the upgrade with Clement Verna (OSBS), Owen Taylor (flatpak) and Mikolaj Izdebski (fedora infra). In case you think you should be included in discussions related to this upgrade, please respond here :). Regards, Jan Kaluza ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
