do-release-upgrade crashes in Greek locale

On the fourth try, I did manage to get it to continue by pressing "ν", which is the Greek letter for "y", Yes.

"ο" which is the Greek letter for "N", No, also worked.

So to sum up the bugs I saw:
1) [Enter] should work and select the default choice when the prompt is "[yN]". It didn't; it prompt me again.

2)
a) The code is wrong, it should support both the English letters (y/n) and the localized ones (ν/ο).
b) OR, the translation is wrong and it shouldn't list the English letters.

3) Ctrl+C didn't revert my sources.list.

4) The initial crash while pressing "λ".

The logs indicate that the text view was being used:

2016-04-20 08:38:55,901 DEBUG Using 'DistUpgradeViewText' view

Looking at the translations for el we can see that 'y' and 'n' are not translated.

1594 #: ../DistUpgrade/DistUpgradeViewText.py:209
1595 #: ../DistUpgrade/DistUpgradeViewText.py:247
1596 #: ../DistUpgrade/DistUpgradeViewText.py:254
1597 msgid "Continue [yN] "
1598 msgstr "Συνέχεια [yN] "

1644 #: ../DistUpgrade/DistUpgradeViewText.py:261
1645 msgid "Continue [Yn] "
1646 msgstr "Συνέχεια [Yn] "

So that answers part 2 at least.

The backtrace shows:
 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcf in position 0: invalid continuation byte

You state in your bug report that your locale is set to el_GR.UTF-8; so 'utf-8' codec should be correct and your input should be in utf-8 encoding.

Confusingly, I can't see why your input would *include* the listed 0xcf byte. The UTF-8 encoding of λ is 0xce 0xb4.

If this problem is reproducible, please do:

  echo -n <text_to_paste_into_prompt> | od -tx1

Attach the result of this command to this bug.

Then, instead of typing the answer into the do-release-upgrade terminal, please cut and paste the text there and verify that the backtrace is still reproducible.

Unfortunately, since I upgraded that PC to 16.04, I cannot use do-release-upgrade anymore to reproduce anything related to this bug report.

If (4) is not reproducible by anyone else, maybe addressing (1), (2) and (3) will be enough...

I can confirm 2, and this is a bug in the translation. Fixed in bzr.

I can also confirm 1, from the source. Also fixed in bzr.

3, I'm not surprised if that's an issue. I doubt we have a very robust signal handler in place. This seems unrelated to the main topic of the bug report, however; feel free to file a new one.

Still looking at trying to reproduce 4. But this may come down to a bit flip error on your system, because I can't think of any other way that a 'λ' keypress would generate 0xcf instead of 0xce.

And the failure for 4 is reproducible if you use the backspace key on the input; since we're not using a real readline library that counts characters, a backspace will delete the character on the screen but leave part of the bytes in the input buffer.

Maybe use readline and built-in input() instead?

https://docs.python.org/3/library/readline.html
https://docs.python.org/3/library/functions.html#input

Hello Alkis, or anyone else affected,

Accepted ubuntu-release-upgrader into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:16.04.13 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hi adconrad,

1) I can't test the proposed do-release-upgrade because I've already upgraded.

2) Even if I find another 14.04 system to test with, I'd need the package to be in trusty-proposed, not in xenial-proposed, right?
Or should I directly download the .deb? Will the python dependencies etc be compatible in that case?

The release upgrade process downloads a tarball from the release to which you are upgrading and uses the code in that tarball. Subsequently, the fix only needs to appear in the destination release.

The launchpad translation importer messed me up on this last upload, and we wound up reverting the translation fixes I had committed. So another upload will be needed.

I also think, from local testing, that the use of the built-in input() is not a 100% fix for the backspace problem, though it may give some improvement.

There is a new version of the release upgrader in proposed now that should fix this.

Tried in both Trusty (where python3 == python3.4) and Xenial (where python3 == python3.5) chroots, with -updates enabled and thus the latest python3.x's available, using the reproducer in the bug description. I get no crashes or bogus output. Pasting Greek input, hitting backspace (test: one, several, none) just results in the Greek prompt being redisplayed.

We'll call this verification-done!

This bug was fixed in the package ubuntu-release-upgrader - 1:16.10.1

---------------
ubuntu-release-upgrader (1:16.10.1) yakkety; urgency=medium

  * DistUpgrade/{EOL,}ReleaseAnnouncement,
    DistUpgrade/DistUpgrade/window_main.ui,
    data/gtkbuilder/DistUpgrade.ui,
    data/DistUpgrade.cfg,
    pre-build.sh:
    - updated for 16.04 -> 16.10
  * tests/test_country_mirror.py: modify how the LANG environment variable was
    being modified there by fixing a test failure in test_sources_list.py.

 -- Brian Murray <email address hidden> Tue, 03 May 2016 08:54:38 -0700