Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#8145 - makepkg : invisible messages on white backgrounds

Attached to Project: Pacman
Opened by Xavier (shining) - Thursday, 27 September 2007, 17:05 GMT
Last edited by Dan McGee (toofishes) - Friday, 28 September 2007, 23:40 GMT
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

This task blocks these from closing
 FS#8109 - Pacman 3.1 Release Roadmap 
Closed by  Dan McGee (toofishes)
Friday, 28 September 2007, 23:40 GMT
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, 17:35 GMT
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, 17:51 GMT
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, 19:33 GMT
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, 19:47 GMT
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, 19:48 GMT
oops, forgot to attach..
   makepkg.diff (2 KiB)
Comment by Aaron Griffin (phrakture) - Thursday, 27 September 2007, 21:01 GMT
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, 04:41 GMT
  • 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, 13:48 GMT
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, 17:08 GMT
See Dan, I told you! 8)

Ok ok, another one for tonight.... /me sighs
Comment by Dan McGee (toofishes) - Friday, 28 September 2007, 17:45 GMT
Should be fixed for real on my working branch. (commit d5fa2da171c9f7...)
Comment by Xavier (shining) - Friday, 28 September 2007, 20:11 GMT
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, 20:15 GMT
Can I be "the best" next time?

Loading...