I consulted with other SRU team members today. We agree that the bug is valid and that the current behaviour is wrong. However, if we were to change behaviour, the concern is that existing users might be regressed in a way that will be difficult for them to track down. The trade-off we must make is between this, what a fix/workaround for such regressed users would look like and the (very valid) issue with mkvterm in Focal, and what a fix/workaround for mkvterm would look like.
I assume that the fix itself for regressed users would be to adjust the call to socat so that it works correctly, which should be straightforward once an affected user identifies the call to socat as the cause of a regression and assuming that the user is in a position to change the socat call. We'd like to hear more about the opportunity to work around the issue in mkvterm. For example, am I right in understanding that the issue is that when specifying "socat $spec_a,extra-options $spec_b", extra-options in $spec_a are (incorrectly) _copied_ forward to $spec_b? Does this happen the other way round? Would a workaround be to use "socat $spec_b $spec_a,extra-options" instead, or would this not work? If it would work, then how difficult would it be to work around the issue in this way in mkvterm or by adding a wrapper around it? The SRU team would like this avenue to be investigated before making a decision please. > The updated debdiff is attached. Did you forget to attach this? The latest upload in the queue still has changes to Makefile.in which I think are unnecessary? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056485 Title: Behaviour of socat in Ubuntu 20.04 unexpected To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2056485/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
