Please stabilize lnav-0.9.0. There is a test that fails, as reported at https://bugs.gentoo.org/713600. I have not noticed runtime issues with the package, though I admittedly have not been using all of the package's features. If there are objections to stabilizing with this failing test we can wait and see if upstream responds at https://github.com/tstack/lnav/issues/830.
FWIW, if a test is known to fail, it may be worth disabling it to make automation (much) easier for the arch teams.
I've opened https://github.com/gentoo/gentoo/pull/20975 to fix https://bugs.gentoo.org/713600. I think what I'll do is wait for that PR to get reviewed/merged, give the -r1 30 days to cook, and then open a new stabilization bug at that time. Thanks!
Hey! Thanks! If they’re fixes _just_ to tests themselves, we don’t need to revbump fortunately.
Hey Sam! They indeed are fixes just to the tests. Here are the two upstream commits that fixed the tests for easier reference: * https://github.com/tstack/lnav/commit/60dde499ac87c2399ac24ae85c98ed8cce564858 * https://github.com/tstack/lnav/commit/cc072d29ead6f1df896bc61b83d7d41dab0b7132 Are you suggesting that I should reopen this bug and stability 0.9.0 as is? Or is your suggestion that I should change my open PR to patch the existing 0.9.0 with these patches, and not create an -r1 just for test patches? I'm happy with either solution, but assumed that any change to an ebuild in the tree should bump the release (you know what they say about assumptions though…)
(In reply to Randy Barlow from comment #4) > Hey Sam! > > They indeed are fixes just to the tests. Here are the two upstream commits > that fixed the tests for easier reference: > > * > https://github.com/tstack/lnav/commit/ > 60dde499ac87c2399ac24ae85c98ed8cce564858 > * > https://github.com/tstack/lnav/commit/ > cc072d29ead6f1df896bc61b83d7d41dab0b7132 So, these really are just changing the tests. They’re not fixing the program to make the tests pass or adjusting the program together with the tests. This is good news for us. It means the only change is going to be either making more tests pass, fewer tests pass, or no change. Not too big of a risk given these commits mention the problem reported here, fortunately! > > Are you suggesting that I should reopen this bug and stability 0.9.0 as is? > Or is your suggestion that I should change my open PR to patch the existing > 0.9.0 with these patches, and not create an -r1 just for test patches? I'm > happy with either solution, but assumed that any change to an ebuild in the > tree should bump the release (you know what they say about assumptions > though…) See https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html but the gist is that no installed files are changed plus this is really only affecting tests which are run during stabilisation. There’s no real way that the program at runtime can be affected given no other code is touched. => we do your second option and make a PR to directly apply the patches to the current revision (no revbump) The point I’m trying get across is, we’re not keeping any users safe from bugs by waiting 30 days for a test-only fix. But if we were changing program behaviour (even if it was faulty), we might have to be more nuanced and think a bit more carefully. On mobile so let me know if I’ve not explained properly!
Hey Sam, thanks for the explanation. That all seems sensible to me. I've modified https://github.com/gentoo/gentoo/pull/20975 to patch the existing lnav-0.9.0 ebuild rather than to introduce a new 0.9.0-r1 ebuild. Once that is merged we can revisit this request.
(In reply to Randy Barlow from comment #6) > Hey Sam, thanks for the explanation. That all seems sensible to me. I've > modified https://github.com/gentoo/gentoo/pull/20975 to patch the existing > lnav-0.9.0 ebuild rather than to introduce a new 0.9.0-r1 ebuild. > > Once that is merged we can revisit this request. Sorry we took so long. Done now!
Let's just do it, given there's no stable version anyway.
amd64 done
x86 stable. Closing.
