Welcome to the Pacman bug collection. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproduceable test case whenever possible.
Tasklist

FS#8145 - makepkg : invisible messages on white backgrounds

Attached to Project: Pacman
Opened by Xavier (shining) - Thursday, 27 September 2007, 13:05 GMT-5
Last edited by Dan McGee (toofishes) - Friday, 28 September 2007, 19:40 GMT-5
Task Type Bug Report
Category makepkg
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Low
Priority Normal
Reported Version git
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:
It seems makepkg 3.1 (git version) doesn't use the foreground color anymore for its output.
So even on a white background, it'll still display in white, resulting in invisible messages.

Steps to Reproduce:
For example, just run makepkg in a directory without PKGBUILD, with a dark on white terminal.
The "PKGBUILD does not exist." part is invisible.

But this also applies to many other messages displayed by makepkg, for examples the ones before/after building.
This task depends upon

View Dependency Graph

This task blocks these from closing
 FS#8109 - Pacman 3.1 Release Roadmap 
Closed by  Dan McGee (toofishes)
Friday, 28 September 2007, 19:40 GMT-5
Reason for closing:  Fixed
Additional comments about closing:  Fixed for real in GIT? I hope so.
Comment by Dan McGee (toofishes) - Thursday, 27 September 2007, 13:35 GMT-5
Did you look into why this happens at all? I haven't diff-ed the message/output functions at all, and I would think it is related to the color codes we are using or something like that.
Comment by Xavier (shining) - Thursday, 27 September 2007, 13:51 GMT-5
Well, I diff-ed them, and I noticed the output was done differently. But I don't know at all how this colors codes stuff work, so I hoped someone knew better..
Comment by Aaron Griffin (phrakture) - Thursday, 27 September 2007, 15:33 GMT-5
Yeah, I'm at work so I didn't go diff anything - I know the color code stuff well, so I figure I can track it down... could you post a diff for me, I don't have time to do it right now.
Comment by Xavier (shining) - Thursday, 27 September 2007, 15:47 GMT-5
I didn't know how exactly you want this diff. I just figured makepkg code is well factorized, and the message / output functions are all in a small section.
So I'm just attaching this section, cut from a diff -U (ie an invalid patch), since the rest should be irrelevant. Let me know if this was stupid :)
Comment by Xavier (shining) - Thursday, 27 September 2007, 15:48 GMT-5
oops, forgot to attach..
   makepkg.diff (2 KiB)
Comment by Aaron Griffin (phrakture) - Thursday, 27 September 2007, 17:01 GMT-5
Well that was easier than I expected!

Note most of the escapes went from:
\033[1;1m
to
\033[1;37m

The first param is the attributes (1 = bold), the second is the color, with all standard colors in the range 30-37 (bold and non-bold).

1 and 0 are special, meaning foreground and background - so 1;1m == bold foreground color and 1;37m == bold white.

Problem solved 8)
Comment by Aaron Griffin (phrakture) - Friday, 28 September 2007, 00:41 GMT-5
  • Field changed: Status (Assigned → Requires testing)
Should be fixed here:
http://code.phraktured.net/?p=pacman.git;a=commitdiff;h=3755f589c51e0c57efb9fddb17a20a7b8b6dfac2
Comment by Xavier (shining) - Friday, 28 September 2007, 09:48 GMT-5
Hmm, it's still not right, now the whole lines are in the same color, eg all green or all red.
Previously, it was done like this :

echo -e "\033[1;31m==> ERROR:\033[1;0m \033[1;1m$1\033[1;0m" >&2

Why are so many color codes needed to work correctly?
Comment by Aaron Griffin (phrakture) - Friday, 28 September 2007, 13:08 GMT-5
See Dan, I told you! 8)

Ok ok, another one for tonight.... /me sighs
Comment by Dan McGee (toofishes) - Friday, 28 September 2007, 13:45 GMT-5
Should be fixed for real on my working branch. (commit d5fa2da171c9f7...)
Comment by Xavier (shining) - Friday, 28 September 2007, 16:11 GMT-5
Yes, Dan is the best :) Fixed for real now, thanks.
I don't quite understand what was wrong, but it doesn't matter.
Comment by Aaron Griffin (phrakture) - Friday, 28 September 2007, 16:15 GMT-5
Can I be "the best" next time?

Loading...