copr-devel September 2016

copr-devel@lists.fedorahosted.org

9 participants
14 discussions

Child pid '4787' is dead
by Miro Hrončok 08 Sep '16

08 Sep '16

My builds in [python26], IDs 450012 and 450019 end weird on F23, while succeeding on other Fedoras. The last lines of build.log.gz are: + exit 0 Child pid '4787' is dead Child dead, killing orphans Child return code was: 0 While on other Fedoras: + exit 0 Child return code was: 0 The [koji] build is fine (at least for non-arm now). The RPM files are there in the output directory, but not installable from the repo. Is that some problem in Copr? Thanks for help. [python26]: https://copr.fedorainfracloud.org/coprs/g/python/python26/ [koji]: http://koji.fedoraproject.org/koji/taskinfo?taskID=15521245 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 2

tasks in waiting mode
by Jean-Marc Liger 07 Sep '16

07 Sep '16

Hi, There are 142 tasks in waiting mode while only 7 tasks are running. Regards, Jean-Marc

2 2

Re: New Release!
by Pavel Raiskup 06 Sep '16

06 Sep '16

On Tuesday, September 6, 2016 10:18:31 AM CEST Michal Novotny wrote: > On Tue, Aug 30, 2016 at 7:43 AM, Pavel Raiskup <praiskup(a)redhat.com> wrote: > > > On Tuesday, August 30, 2016 7:39:14 AM CEST Pavel Raiskup wrote: > > > Currently it looks like such error-handling is not implemented anyway, > > > we drop the build and it is re-submitted after some deadline. > > > > By "drop" here I mean that the build simply fails on BE, while it is still > > in "running" state in FE databse. That build is put in queue once again > > after MAX_BUILD_TIMEOUT.handling non-responsive VMs. > > But that's different from the (primitive) deferring mechanism where > backend takes any job that frontend feeds it with and returns it back > (effectively saying "try to give me this job later") if it finds out the > job cannot be handled at the moment. Right, that's why I say that the actual deferring is not needed at all. Because backend is not going to ask for build if it is not able to immediately handle it. > If you would like to use what you have described to implement > "deferring", then I doubt you can fit it on that very well. I don't follow here. > I am satisfied with the current state and will implement more only > if/when I find it insufficient (meaning "performing very badly") later > but feel free to send us patches for this sooner if desired. Now, slower architectures (ppc64le) will (a bit) delay the queues in faster architectures (x86_64/i386). Or am I wrong here? Yes, it is not big issue. But I just claim that the "major rewrite" (without code review!) reached production too early, because it brings zero benefits. It would be beneficial, and I could appreciate it, if it was 1:1 replacement, but so far it is not. Please consider having simple "Pull-request -> LGTM -> merge" commit process. Pavel

1 0

Fwd: New Release!
by Michal Novotny 06 Sep '16

06 Sep '16

On Tue, Aug 30, 2016 at 7:43 AM, Pavel Raiskup <praiskup(a)redhat.com> wrote: > On Tuesday, August 30, 2016 7:39:14 AM CEST Pavel Raiskup wrote: > > Currently it looks like such error-handling is not implemented anyway, > > we drop the build and it is re-submitted after some deadline. > > By "drop" here I mean that the build simply fails on BE, while it is still > in "running" state in FE databse. That build is put in queue once again > after MAX_BUILD_TIMEOUT.handling non-responsive VMs. But that's different from the (primitive) deferring mechanism where backend takes any job that frontend feeds it with and returns it back (effectively saying "try to give me this job later") if it finds out the job cannot be handled at the moment. If you would like to use what you have described to implement "deferring", then I doubt you can fit it on that very well. I am satisfied with the current state and will implement more only if/when I find it insufficient (meaning "performing very badly") later but feel free to send us patches for this sooner if desired. > > Pavel > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel September 2016