Bug 1331621 - [PATCH] Fix zcurses default color setting
Summary: [PATCH] Fix zcurses default color setting
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: zsh
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-29 03:55 UTC by Jason Tibbitts
Modified: 2017-12-12 10:48 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-12 10:48:03 UTC
Type: Bug


Attachments (Terms of Use)
Patching fixing zcurses and test suite issues. (4.57 KB, patch)
2016-04-29 03:55 UTC, Jason Tibbitts
no flags Details | Diff

Description Jason Tibbitts 2016-04-29 03:55:11 UTC
Created attachment 1152109 [details]
Patching fixing zcurses and test suite issues.

The zcurses module has a bug which prevents you from using "default/default" as a color pair, which is annoying (zsh-nagivation-tools comes up super bright, which is really jarring when I use solarized dark).

There's a patch at http://www.zsh.org/mla/workers/2016/msg00889.html

While testing this, I found that the test suite fails when I do a mockbuild.  This is due to a bad test which tries to detect a noatime filesystem, but mock sets up the chroot such that there's no root filesystem visible in /proc/mounts or df.  And even if I fixed that, the test still fails.  I suspect that's because I build entirely in tmpfs, though I thought tmpfs supported atime properly.

http://www.zsh.org/mla/workers/2016/msg00890.html

I'll attach a patch which fixes both of these up and does some specfile cleanup.  If you like, I can just commit it, or send a version without the cleanups.

Comment 1 Kamil Dudka 2016-04-29 10:23:05 UTC
Looks good to me.  Feel free to commit it (preferably one commit per issue).

However, from long term point of view it would be good to improve the test-suite patch to be acceptable by upstream.  The test needs to be skipped if it runs on an unsupported file system *or* if the file system type is not available.

Comment 2 Jason Tibbitts 2016-04-29 20:24:41 UTC
Yeah, I don't actually know why that test is failing for me.  tmpfs should support atime just fine, and the filesystem is mounted with relatime just like pretty much every other Linux filesystem these days.  But even if I just remove everything but the actual test in the else clause, it still fails.  I guess I should print out a stat on each of those files.

So far, no upstream response to my message about the broken test.

BTW, that's not the only test at issue in C02cont.ztst; we patch two others out as well.  I'm not sure how to even detect the situations where either of these tests will fail.

Comment 3 Jason Tibbitts 2016-04-29 23:04:39 UTC
So I did get an update from upstream, and there's a committed fix.  However, it turns out I don't need it because everything is just fine if I actually check my mock config and realize that I was building on a filesystem mounted with noatime instead of the tmpfs one I normally use.  Oops.  Since it doesn't really matter for Fedora I'll drop it for now and let the fix come in with 5.3 (whenever that happens).

So really it's just down to the curses thing, which I could build locally, but would then have to deploy to every machine because otherwise znt is broken for me.  I'll go ahead and push it later today.

Comment 4 Kamil Dudka 2016-05-02 07:18:14 UTC
(In reply to Jason Tibbitts from comment #2)
> BTW, that's not the only test at issue in C02cont.ztst; we patch two others
> out as well.

Good point.  I was about to drop zsh-test-C02-dev_fd-mock.patch.  Does the patch still do anything useful?

Do we have any reproducer for the problem that the patch is supposed to resolve?

Comment 5 Jan Kurik 2016-07-26 05:08:47 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 6 Fedora End Of Life 2017-11-16 18:53:24 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 7 Fedora End Of Life 2017-12-12 10:48:03 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.