Here's something I didn't expect from the new ABI gate. Which, before I go further, I think will be a great idea nearly all of the time. I think avoiding unintentional ABI breaks in stable releases is a worthy goal.
But ... I maintain a package called gap. It provides what amounts to a scripting language for doing certain types of math. It comes with a bunch of addon packages that provide specific mathematical capabilities. Most of them are written solely in the scripting language, but a few have to interface with external libraries. When that is required, these packages build a small internal-only shared object to act as the glue between the external library and the scripting language.
I've got a pending update for one of these packages that fixes some bugs. It has been caught by the ABI gate: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7
There is no danger in pushing this to stable, since the only consumer of the changed ABI is inside the same package. Now what do I do? Are ABI changes completely disallowed in all circumstances? Is there a button somewhere that says, "I am aware of the danger of pushing this to stable and I have verified that nothing will break in this case"?
Thanks,
On Mon, Jan 22, 2018 at 3:49 PM, Rex Dieter rdieter@math.unl.edu wrote:
As far as I know and can tell, those gating things are advisory only at this point.
I am logged into bodhi. I am looking at the page for the gap-pkg-io update I mentioned earlier: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7
There is no button to push to batched. There are only two buttons: Edit and Unpush. On the right hand side, I see:
Test Gating Status Tests Failed 1 of 2 required tests failed
The "1 of 2 required tests failed" text is linked to a page that has this text at the top:
Automated Test Results The update can not be pushed: 1 of 2 required tests failed
If the gate is supposed to be advisory only at this time, then where is the button to push to batched? I do not see it anywhere.
On Mon, Jan 22, 2018 at 3:49 PM, Rex Dieter <rdieter(a)math.unl.edu> wrote:
I am logged into bodhi. I am looking at the page for the gap-pkg-io update I mentioned earlier: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7
There is no button to push to batched. There are only two buttons: Edit and Unpush. On the right hand side, I see:
Test Gating Status Tests Failed 1 of 2 required tests failed
The "1 of 2 required tests failed" text is linked to a page that has this text at the top:
Automated Test Results The update can not be pushed: 1 of 2 required tests failed
If the gate is supposed to be advisory only at this time, then where is the button to push to batched? I do not see it anywhere.
Yep, bodhi is definitely blocking things now without any way to override that I can see. :-( I've got a similar situation, I was able to push to batched 5 days ago but just now bodhi sent me an email saying "Bodhi is unable to request this update for stabilization: This update has not yet met the minimum testing requirements defined in the Package Update Acceptance Criteria."
Scott
On 22 January 2018 at 22:12, Scott Talbert wrote:
Yep, bodhi is definitely blocking things now without any way to override that I can see. :-( I've got a similar situation, I was able to push to batched 5 days ago but just now bodhi sent me an email saying "Bodhi is unable to request this update for stabilization: This update has not yet met the minimum testing requirements defined in the Package Update Acceptance Criteria."
Interesting. In my case it doesn't allow me pushing with: "The update can not be pushed: 1 of 2 required tests not found" Unfortunately it doesn't tell me what is required, what is not found.
Orcan
On Mon, Jan 22, 2018 at 01:57:34PM -0700, Jerry James wrote:
Here's something I didn't expect from the new ABI gate. Which, before I go further, I think will be a great idea nearly all of the time. I think avoiding unintentional ABI breaks in stable releases is a worthy goal.
But ... I maintain a package called gap. It provides what amounts to a scripting language for doing certain types of math. It comes with a bunch of addon packages that provide specific mathematical capabilities. Most of them are written solely in the scripting language, but a few have to interface with external libraries. When that is required, these packages build a small internal-only shared object to act as the glue between the external library and the scripting language.
I've got a pending update for one of these packages that fixes some bugs. It has been caught by the ABI gate: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7
There is no danger in pushing this to stable, since the only consumer of the changed ABI is inside the same package. Now what do I do? Are ABI changes completely disallowed in all circumstances? Is there a button somewhere that says, "I am aware of the danger of pushing this to stable and I have verified that nothing will break in this case"?
We just sent an announcement about this, sorry for being late on this.
Basically, you can "waive" test results using waiverdb-cli (dnf install waiverdb-cli) which will allow the update to go through despite of the failing test. We're working on putting this into bodhi itself for easier use.
Pierre
On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote:
We just sent an announcement about this, sorry for being late on this.
Basically, you can "waive" test results using waiverdb-cli (dnf install waiverdb-cli) which will allow the update to go through despite of the failing test. We're working on putting this into bodhi itself for easier use.
Can someone who knows what they're talking about put this into https://fedoraproject.org/wiki/Package_update_HOWTO?rd=PackageMaintainers/Up...
(Also, that document is a great candidate for conversion to the new docs system. Just sayin'.)
On Tue, 2018-01-23 at 08:13 -0500, Matthew Miller wrote:
On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote:
We just sent an announcement about this, sorry for being late on this.
Basically, you can "waive" test results using waiverdb-cli (dnf install waiverdb-cli) which will allow the update to go through despite of the failing test. We're working on putting this into bodhi itself for easier use.
Can someone who knows what they're talking about put this into https://fedoraproject.org/wiki/Package_update_HOWTO?rd=PackageMaintainers/Up...
Note: I've just updated the page somewhat, mainly to bring it into line with the current reality regarding what automated tests are run and how the results are displayed. I did introduce a little stub sentence about waiverdb-cli, but it'd still be great if someone who knows the exact syntax for waiving a particular result could extend that.
(Also, that document is a great candidate for conversion to the new docs system. Just sayin'.)
It's a bit off-topic, but...when this happens, what do we do about links? There are probably many links to this page. This applies to anything being 'converted' from the wiki to docs, I guess...can we make wiki URLs redirect to a docs page after conversion? Or do we have to make the wiki page just show a link to the docs page?
On Tue, Jan 23, 2018 at 03:21:56PM +0100, Adam Williamson wrote:
It's a bit off-topic, but...when this happens, what do we do about links? There are probably many links to this page. This applies to anything being 'converted' from the wiki to docs, I guess...can we make wiki URLs redirect to a docs page after conversion? Or do we have to make the wiki page just show a link to the docs page?
I've just been making stubs like https://fedoraproject.org/wiki/Council, which isn't ideal.
Mediawiki has some extensions which allow external redirects, but I don't think we can safely enable anything which allows *arbitrary* redirects.
We could either look at modifying the ExternalRedirecct extension to be something like DocsRedirect and hard-code the https://docs. part, or we could follow this suggestion https://stackoverflow.com/a/36634532/479426, which is to create a "MovedToDocs" namespace and allow the extension there, and then give a restricted set of people permission to move things into that space.
(Resending with correct docs list cc. Sorry about that.)
On Tue, Jan 23, 2018 at 11:30:46AM -0500, Matthew Miller wrote:
On Tue, Jan 23, 2018 at 03:21:56PM +0100, Adam Williamson wrote:
It's a bit off-topic, but...when this happens, what do we do about links? There are probably many links to this page. This applies to anything being 'converted' from the wiki to docs, I guess...can we make wiki URLs redirect to a docs page after conversion? Or do we have to make the wiki page just show a link to the docs page?
I've just been making stubs like https://fedoraproject.org/wiki/Council, which isn't ideal.
Mediawiki has some extensions which allow external redirects, but I don't think we can safely enable anything which allows *arbitrary* redirects.
We could either look at modifying the ExternalRedirecct extension to be something like DocsRedirect and hard-code the https://docs. part, or we could follow this suggestion https://stackoverflow.com/a/36634532/479426, which is to create a "MovedToDocs" namespace and allow the extension there, and then give a restricted set of people permission to move things into that space.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
On Tue, Jan 23, 2018 at 11:42:57AM -0500, Matthew Miller wrote:
We could either look at modifying the ExternalRedirecct extension to be something like DocsRedirect and hard-code the
Annnd.... https://pagure.io/fedora-infrastructure/issue/6650
On Tue, Jan 23, 2018 at 03:44:22PM -0500, Matthew Miller wrote:
On Tue, Jan 23, 2018 at 11:42:57AM -0500, Matthew Miller wrote:
We could either look at modifying the ExternalRedirecct extension to be something like DocsRedirect and hard-code the
Annnd.... https://pagure.io/fedora-infrastructure/issue/6650
Okay, so, this is now live on the wiki. To create a redirect from a wiki page to a new docs page, use this at the top of the page:
{{#fedoradocs: https://docs.fedoraproject.org/fedora-project/council/fpl.html%7D%7D
It's okay to leave the rest of the page as it is.
Check out https://fedoraproject.org/wiki/Project_Leader to see this in action. It will *only* work with https://docs.fedoraproject.org/; you can't make arbitrary redirects.
If you need to fix a typo or remove or change the redirect, you can access the edit page at a URL like https://fedoraproject.org/w/index.php?title=Project_Leader&action=edit
Ironically, I'm not sure exactly where to document this. :)
Thanks to Kevin Fenzi, Patrick Uiterwijk, and Jared Smith for helping me with this.
On Tue, Jan 23, 2018 at 08:13:02AM -0500, Matthew Miller wrote:
On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote:
We just sent an announcement about this, sorry for being late on this.
Basically, you can "waive" test results using waiverdb-cli (dnf install waiverdb-cli) which will allow the update to go through despite of the failing test. We're working on putting this into bodhi itself for easier use.
Can someone who knows what they're talking about put this into https://fedoraproject.org/wiki/Package_update_HOWTO?rd=PackageMaintainers/Up...
I added some more detail just now.
On Tue, 2018-01-23 at 10:32 +0100, Pierre-Yves Chibon wrote:
We just sent an announcement about this, sorry for being late on this.
Basically, you can "waive" test results using waiverdb-cli (dnf install waiverdb-cli) which will allow the update to go through despite of the failing test. We're working on putting this into bodhi itself for easier use.
Note, just waiving this kind of failure one-by-one doesn't seem like the proper fix for this to me. Patrick told me yesterday that he'd seen or been told about a different (I think) but similar case; I think there may be kind of a generic issue with the ABI diff test checking the ABI of shared objects that aren't actually 'public' in any meaningful way. We should look at that as a generic issue. I'm sending a mail to qa-devel@ to flag this up to the Taskotron devs. We could consider dropping this test from the gating list again until this is looked into...
On Tue, Jan 23, 2018 at 02:21:02PM +0100, Adam Williamson wrote:
On Tue, 2018-01-23 at 10:32 +0100, Pierre-Yves Chibon wrote:
We just sent an announcement about this, sorry for being late on this.
Basically, you can "waive" test results using waiverdb-cli (dnf install waiverdb-cli) which will allow the update to go through despite of the failing test. We're working on putting this into bodhi itself for easier use.
Note, just waiving this kind of failure one-by-one doesn't seem like the proper fix for this to me. Patrick told me yesterday that he'd seen or been told about a different (I think) but similar case; I think there may be kind of a generic issue with the ABI diff test checking the ABI of shared objects that aren't actually 'public' in any meaningful way. We should look at that as a generic issue. I'm sending a mail to qa-devel@ to flag this up to the Taskotron devs. We could consider dropping this test from the gating list again until this is looked into...
I've removed the abicheck requirement from the greenwave policies for now until we know more: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=465f155...
On 23 January 2018 at 18:20, Ralph Bean rbean@redhat.com wrote:
I've removed the abicheck requirement from the greenwave policies for
now until we know more: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id= 465f155d140a9fbe34f0f51dbfc2137b2900a6f8
Do we have to do anything to proceed? I still seem not able to push my update to stable.
Att. -- Rafael Fonseca
On Tue, Jan 23, 2018 at 06:37:56PM +0100, Rafael dos Santos wrote:
On 23 January 2018 at 18:20, Ralph Bean rbean@redhat.com wrote:
I've removed the abicheck requirement from the greenwave policies for
now until we know more: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id= 465f155d140a9fbe34f0f51dbfc2137b2900a6f8
Do we have to do anything to proceed? I still seem not able to push my update to stable.
Hopefully the Bodhi maintainers can have a look; Bodhi may be caching the decision here. IIRC, there's a cronjob to synchronize on the Bodhi side.
On 01/23/2018 01:19 PM, Ralph Bean wrote:
Hopefully the Bodhi maintainers can have a look; Bodhi may be caching the decision here. IIRC, there's a cronjob to synchronize on the Bodhi side.
Correct - currently Bodhi polls Greenwave every 6 hours, so it could take a bit for it to notice the decision change.
We do have a plan to make Bodhi listen for Greenwave fedmsgs so we don't have to rely on slow polling, so this delay should improve in the future.
On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote:
On Mon, Jan 22, 2018 at 01:57:34PM -0700, Jerry James wrote:
Here's something I didn't expect from the new ABI gate. Which, before I go further, I think will be a great idea nearly all of the time. I think avoiding unintentional ABI breaks in stable releases is a worthy goal.
But ... I maintain a package called gap. It provides what amounts to a scripting language for doing certain types of math. It comes with a bunch of addon packages that provide specific mathematical capabilities. Most of them are written solely in the scripting language, but a few have to interface with external libraries. When that is required, these packages build a small internal-only shared object to act as the glue between the external library and the scripting language.
I've got a pending update for one of these packages that fixes some bugs. It has been caught by the ABI gate: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7
There is no danger in pushing this to stable, since the only consumer of the changed ABI is inside the same package. Now what do I do? Are ABI changes completely disallowed in all circumstances? Is there a button somewhere that says, "I am aware of the danger of pushing this to stable and I have verified that nothing will break in this case"?
We just sent an announcement about this, sorry for being late on this.
Basically, you can "waive" test results using waiverdb-cli (dnf install waiverdb-cli) which will allow the update to go through despite of the failing test. We're working on putting this into bodhi itself for easier use.
FYI, here's the change for the Bodhi UI: https://github.com/fedora-infra/bodhi/pull/2095
Jerry James wrote:
Here's something I didn't expect from the new ABI gate.
Why did you not expect it? I pointed out this exact issue on January 13, right after this change was announced, and ~5 days before it was implemented without anybody responding to my objection:
https://pagure.io/fesco/issue/1810#comment-488673 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
I wrote there:
Uh, `dist.abicheck` produces a lot of false positives on:
- libraries that are internal and that nothing should depend on (e.g., in
QupZilla, package `qupzilla`),
^ That's exactly the case we are in here. ^
- APIs explicitly documented as "private, can change at any version", as
common in all Qt modules (e.g., in QtWebEngine, package `qt5-qtwebengine`).
My packages often fail `dist.abicheck`. It is absolutely not realistic to expect it to pass for all updates.
Where do I need to send such information next time for people to actually READ it? I sent it both to the FESCo ticket and to the mailing list!
Kevin Kofler
-
Adam Williamson -
Jerry James -
Kevin Kofler -
Matthew Miller -
Orcan Ogetbil -
Pierre-Yves Chibon -
Rafael dos Santos -
Ralph Bean -
Randy Barlow -
Rex Dieter -
Scott Talbert