New issues seen when trying to update the wireshark package. First build went fine: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20151102200948.luigiwalser.valstar.10182 It just failed because the libmajor's changed. So it failed on all three arches and once I fixed it, it should have let me resubmit. It didn't, because it said: Submission errors, aborting: - wireshark-2.0.0-0.rc2.1.mga6: - Newer revisions already exists for cauldron in upload queue: [...] showing after that the .src.rpm was the one it was complaining about. When the build fails on all arches, it should not block the next build because of the source RPM. So I bumped the release tag, and then an install_deps issue only on ARM blocked the whole build: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20151102202442.luigiwalser.valstar.26674 ARM should be treated as a "secondary arch" and builds only failing there should not block everything. Once I added an ExclusiveArch tag to get around that for now, then I had to bump the release tag again. Reproducible: Steps to Reproduce:
I also see that failing builds are not automatically being terminated on all build nodes, consuming needed resources.
That last one is a very old bug.
CC: (none) => thierry.vignaud
Hardware: i586 => arm
Of course, there's also the new issue of not being able to submit builds to nonfree/tainted for packages that also exist in core. That needs to be fixed. More importantly, we need to make sure that it doesn't impact building updates for Mageia 6.
Priority: Normal => High
Priority: High => release_blocker
Target Milestone: --- => Mageia 6
Status comment: (none) => Need to make sure it doesn't affect building for updates_testing in Mageia 6
The issues in comment 0 and comment 1 are not critical for the release IMO (not release blockers), but the one in comment 3 is, unless we're fine with having to push SRPMs with different versions for updates of core + tainted packages.
The comment 3 issue is why this is a release blocker, because that's not fine.
Ping. Pascal, Olivier, any idea?
pterjan, blino... would you mind sorting this one out before we release mga6
CC: (none) => mageia, pterjan, tmb
Seems to be fixed. I just submitted drakx-installer-images to nonfree with same relase as in core. Thanks pterjan
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Nop I think it isn't yet fixed! drakx-installer-images can be pushed both on core and nonfree because of arch restriction in spec file: "ExclusiveArch: x86_64 %{ix86}"
CC: (none) => geiger.david68210Status: RESOLVED => REOPENEDResolution: FIXED => (none)
yes, but I couldnt submit them before with same rel... anyway a new mesa is coming today or so, and then we will know
This seems to have been fixed by Pascal in this commit: http://gitweb.mageia.org/software/build-system/iurt/commit/?id=2328f608ff92c8efad17fbc36e0bbcb50376ef21 (and a few others around this one)
There were several issues mentioned in comment 0, comment 1 and comment 3. For clarity, maybe this one can be closed and a new issue could be opened about remaining issues, if any?
Status comment: Need to make sure it doesn't affect building for updates_testing in Mageia 6 => Most critical issues fixed, some may remain
from pascal mail, this should be fixed. Please reopen if needed.
CC: (none) => mageiaStatus: REOPENED => RESOLVEDResolution: (none) => FIXED
Unfortunately... core/release package built/uploaded 1h ago... (currently building on arm* Trying to submit it to tainted gets: error: Failed to upload svn://svn.mageia.org/svn/packages/cauldron/mesa: Executing perl -I/usr/share/mga-youri-submit/lib /usr/share/mga-youri-submit/bin/youri-submit --config /etc/youri/submit-todo.conf --define user=tmb --define sid=a6755a68-381c-49eb-ab00-d1ab7fa9e3a8 --define section=tainted/release cauldron /var/lib/schedbot/repsys/srpms/@1070654:mesa-13.0.2-1.mga6.src.rpm (sudo_user tmb) Initializing repository Executing /usr/bin/rpmlint -f /usr/share/rpmlint/config /var/lib/schedbot/repsys/srpms/@1070654:mesa-13.0.2-1.mga6.src.rpm Submission errors, aborting: - mesa-13.0.2-1.mga6.src: - Newer revisions already exists for cauldron in upload queue: /var/lib/schedbot/uploads//todo/cauldron/core/release/20161128191716.tmb.duvel.4624_@1070654:mesa-13.0.2-1.mga6.src.rpm Of course, this is sort of "correct" if we intend to have arm* as an officially supported platform in mga6 in wich case we need the builds to stay in sync... So what do we want ?
Resolution: FIXED => (none)Status: RESOLVED => REOPENED
ARM was supposed to be a "secondary architecture" and is not supposed to interfere with the normal building operation on i586 and x86_64. We can't have this issue interfering with building normal updates. I actually think that for Mageia 6, ARM builds shouldn't be automatically activated at all, and periodically (maybe once a month) some script or something should ARM build the latest changed packages and push them all atomically, but that's up to you guys how you want to handle that.
Side question (does not answer the ARM topic): Do we need to prevent pushing the same NEVR to two different sections at the same time while the first one is still in the todo list? Allowing to push concurrent builds on different sections would solve that issue automatically. Of course we might waste some resources if packagers send broken builds on both core and tainted at the same time (e.g. a badly packaged mesa or ffmpeg), but how often would that happen? Or am I missing something that makes it necessary to prevent such concurrent builds?
(In reply to Thomas Backlund from comment #14) > core/release package built/uploaded 1h ago... > (currently building on arm* > > Trying to submit it to tainted gets: [...] Actually I still get the same submit error even now, when mesa has been properly uploaded for all 4 supported arches.
(In reply to Thomas Backlund from comment #14) > Unfortunately... > > core/release package built/uploaded 1h ago... > (currently building on arm* > > Trying to submit it to tainted gets: > > error: Failed to upload svn://svn.mageia.org/svn/packages/cauldron/mesa: > Executing perl -I/usr/share/mga-youri-submit/lib > /usr/share/mga-youri-submit/bin/youri-submit --config > /etc/youri/submit-todo.conf --define user=tmb --define > sid=a6755a68-381c-49eb-ab00-d1ab7fa9e3a8 --define section=tainted/release > cauldron /var/lib/schedbot/repsys/srpms/@1070654:mesa-13.0.2-1.mga6.src.rpm > (sudo_user tmb) > Initializing repository > Executing /usr/bin/rpmlint -f /usr/share/rpmlint/config > /var/lib/schedbot/repsys/srpms/@1070654:mesa-13.0.2-1.mga6.src.rpm > Submission errors, aborting: > - mesa-13.0.2-1.mga6.src: > - Newer revisions already exists for cauldron in upload queue: > /var/lib/schedbot/uploads//todo/cauldron/core/release/20161128191716.tmb. > duvel.4624_@1070654:mesa-13.0.2-1.mga6.src.rpm > > Yes this is expected, the bug which should be fixed was that it would still fail after arm finished building (or failed) as the src.rpm remained in the todo queue, but it still remains while it gets built. The proper fix would be anyway to finish supporting submitting to several sections at once (iurt support used to work, but I never started looking at adding support in mgarepo, and iurt may have been broken since). > Of course, this is sort of "correct" if we intend to have arm* as an > officially supported platform in mga6 in wich case we need the builds to > stay in sync... > > So what do we want ? That is a question I asked on IRC last week, we probably don't want to fully support armv5tl due to low expected usage. Supporting armv7hl would be nice but we probably don't want to delay a firefox security update because it takes more than a day to build on arm. Also, we can't ask QA to test extra architectures...
Are there any outstanding issues here other than what I reported in Bug 20098?
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=20098
So what's the status on this issue? The Mageia 6 release is getting near, so if there is something that we *must* fix before the release, it should be done now. (In reply to Pascal Terjan from comment #18) > (In reply to Thomas Backlund from comment #14) > > Of course, this is sort of "correct" if we intend to have arm* as an > > officially supported platform in mga6 in wich case we need the builds to > > stay in sync... > > > > So what do we want ? > > That is a question I asked on IRC last week, we probably don't want to fully > support armv5tl due to low expected usage. > > Supporting armv7hl would be nice but we probably don't want to delay a > firefox security update because it takes more than a day to build on arm. > Also, we can't ask QA to test extra architectures... This seems to be the most critical point to me in this issue. We can't have the slow ARM builds delay critical security updates. Do we have a plan? Who will handle the necessary changes?
So, I guess the plan is statu quo? Or do we want to change something before the release?
i think we should just dedicate something like 2 arm machines for mga6 BS. This will fix this issue for mga6 updates
Alright, closing as the most pressing issues were fixed. If we do as suggested in comment 22, it should be working fine for Mageia 6.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
We just need to make sure that packages that need to build on core and tainted don't get held up by ARM.