Description of problem: On firstboot page, Unexpected/unlocalized error/dummy message and traceback dialog pops up when register RHN with invalid username and password. Version-Release number of selected component (if applicable): firstboot-1.4.27.9-1.el5 subscription-manager-firstboot-1.0.24-1.el5 How reproducible: 100% Steps to Reproduce: 1. Install os with latest RHEL5.9 Beta build 2. On fresh installed system, first-boot should automatically run if need to re-run in desktop use following command * $ su - * $ firstboot --reconfig --debug 3. Next steps to 'Register' page. 4. Select 'RHN' to register. 5. Input invalid username/password on Red Hat Account page (ex. qa) and Next. 6. Click OK on the error message dialog and click Back, input invalid username/password (ex. test) and Next. 7. Click OK on the dummy long error message dialog and Next. 8. Check the traceback dialog for company/organization selection page. Actual results: On firstboot page, Unexpected/unlocalized error/dummy message and traceback dialog pops up when register RHN with invalid username and password. Expected results: 1. The error message should be localized. 2. The 'dummy' word should not be displayed and the error message dialog is too long, it should be resized to short. 3. Should have no traceback for organization selection page. Additional info:
Created attachment 639134 [details] RHN register error message
Created attachment 639135 [details] dummy error message dialog box is too long
Created attachment 639138 [details] traceback occurred in the organization module
Hi Lijun, Thanks for having such a sharp eye for potential problems. I am going to say that most of the things you mention here are not problems and explain why in a second. The long error message might be a problem, but I could not reproduce it. Here is my explanation of the things you mention: First, the error messages that you are getting that say "Error Class Code" are untranslatable because they are coming from the upstream source, RHN in this case, and there is no mechanism in place to request a translated version of the error. This is not a regression, it has always been that way, and we are not able to fix it here. Second, the reason that you get a "Bad username / password" error in one case and an "Account has been disabled" in another is because there is actually an account who's username / password is test / test, but RHN has disabled that account. It was disabled probably because it was too easy to guess the password. The different error message is expected. Third, the "dummy" message only appears if you are running firstboot manually from the console, which no one really does. On my test machine firstboot spews tons of warnings and other nonsense messages to the console during correct operation, so I am not worried about a few more lines of debug output in a use case that never happens. Fourth, I cannot reproduce the long error message that you have taken a screenshot of. I followed your reproducer steps exactly and never saw it. Finally, the traceback that you report is not a traceback at all. It is just a GTKWarning, along with the many that firstboot naturally produces on my system and again something that you would never see if you were not doing the incredibly unusual thing of running firstboot from a terminal window. Firstboot generates a lot of warnings and debug information when run from the console anyway, so I am not concerned that the RHN registration plugin also generates some. If you can tell me how to reproduce the long error message I will look into that further. Is it maybe possible that this is just tied to your particular system for some reason?
(In reply to comment #7) > Hi Lijun, > > Thanks for having such a sharp eye for potential problems. I am going to say > that most of the things you mention here are not problems and explain why in > a second. The long error message might be a problem, but I could not > reproduce it. Here is my explanation of the things you mention: > > First, the error messages that you are getting that say "Error Class Code" > are untranslatable because they are coming from the upstream source, RHN in > this case, and there is no mechanism in place to request a translated > version of the error. This is not a regression, it has always been that way, > and we are not able to fix it here. > > Second, the reason that you get a "Bad username / password" error in one > case and an "Account has been disabled" in another is because there is > actually an account who's username / password is test / test, but RHN has > disabled that account. It was disabled probably because it was too easy to > guess the password. The different error message is expected. > > Third, the "dummy" message only appears if you are running firstboot > manually from the console, which no one really does. On my test machine > firstboot spews tons of warnings and other nonsense messages to the console > during correct operation, so I am not worried about a few more lines of > debug output in a use case that never happens. > > Fourth, I cannot reproduce the long error message that you have taken a > screenshot of. I followed your reproducer steps exactly and never saw it. > > Finally, the traceback that you report is not a traceback at all. It is just > a GTKWarning, along with the many that firstboot naturally produces on my > system and again something that you would never see if you were not doing > the incredibly unusual thing of running firstboot from a terminal window. > Firstboot generates a lot of warnings and debug information when run from > the console anyway, so I am not concerned that the RHN registration plugin > also generates some. > > If you can tell me how to reproduce the long error message I will look into > that further. Is it maybe possible that this is just tied to your particular > system for some reason? Steps to reproduce the long error message: 1. $ LANG=ja_JP.UTF-8 firstboot --reconfig 2. Next steps to 'Register' page. 3. Select 'RHN' to register. 4. Input invalid username/password on Red Hat Account page (ex. test/test) and Next. 5. Click OK on the 'Error Class Code 'error message dialog and click Back, input invalid username/password again (ex. test/test) and Next. I verifed it on zh_CN locale, the long error message box is displayed good. For the ja_JP locale, I think it's better to divide the long Japanese error message into segments, so that the message box can short. Thanks, Robert
Created attachment 643925 [details] long error message box for zh_CN locale
To understand the scope of this request. Of the original comment 0, did this boil down to the comment 8 when that single error message "This error shouldn't have happened. If you'd like to help us improve this program, please file a bug at bugzilla.redhat.com. Including the relevant parts of '/var/log/up2date' would be very helpful. Thanks!" which is "発生すべきエラーではありません。 このプログラムの改善にご助力頂ける場合には、 bugzilla.redhat.com でバグ報告をお願いします。 「/var/log/up2date」の該当部分をバグ報告に入れて頂くと非常に助かります。ありがとうございます。" in Japanese locales should have some linebreaks in it in that Japanese translation? Can you please provide exact form / shape that the message should take?
Also, could you explain if the existing error message with long lines actually does not make sense in Japanese at all (the semantics is different without the linebreaks), or is that just a cosmetic thing, not having the lines too long?
(In reply to comment #12) > Also, could you explain if the existing error message with long lines > actually does not make sense in Japanese at all (the semantics is different > without the linebreaks), or is that just a cosmetic thing, not having the > lines too long? Think it's a just a cosmetic thing, anyway should add some linebreaks to the long translated Japanese strings so that all the strings can be displayed in the dialog and the dialog can be shorter.
(In reply to comment #11) > To understand the scope of this request. Of the original comment 0, did this > boil down to the comment 8 when that single error message > > "This error shouldn't have happened. If you'd like to help us improve this > program, please file a bug at bugzilla.redhat.com. Including the relevant > parts of '/var/log/up2date' would be very helpful. Thanks!" > > which is > > "発生すべきエラーではありません。 このプログラムの改善にご助力頂ける場合には、 bugzilla.redhat.com でバグ報告をお願いします。 > 「/var/log/up2date」の該当部分をバグ報告に入れて頂くと非常に助かります。ありがとうございます。" > > in Japanese locales should have some linebreaks in it in that Japanese > translation? > > Can you please provide exact form / shape that the message should take? ex. "発生すべきエラーではありません。 このプログラムの改善にご助力頂ける場合には、 bugzilla.redhat.com でバグ報告をお願いします。 「/var/log/up2date」の該当部分をバグ報告に入れて頂くと非常に助かります。ありがとうございます。"
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Ah I finally get it. The real problem here is not the string length (although that is sub-optimal). The real problem is that the error is displayed at all, which only happens if you try to authenticate with a user that has been disabled, click back, and try again. What *should* happen is that you see the exact same error message / failure screen as you did the first time. What *does* happen is that you see this second, long, worthless error message. You can all point and laugh at me because of how long it took me to understand the reproducer. This is definitely a valid bug.
Spacewalk master commit: 206ec3b009db5e9230ec97b195cb815b5377e938
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1328.html