Well, to me it looks like socat is like a Swiss army knife, where some features are popular and are used often, but others are very rarely used.
Also please consider potential reactions of users that run into this (or similar cases): 1) (trivial) Users notice this problem (or not) and don't do anything. We would not become aware of a problem, hence nothing will be done. Things are probably less important and critical. 2) Users notice this problem and work around this, but do not open a bug. It is fixed for that particular user, and this user is well aware about the bug, since it got fixed by him/her; but this is not the desired reaction, since a bug should have been opened on top to report this. 3) Users notice this problem (and work around this or not), and open a bug. This is (imho) the desired behavior - due to the report and with that the ask to get it fixed. And with an update on the bug, they'll get a notification. Item 3) might cause an adjustment on their side once a fix got rolled out, but will protect for upgrade regressions. The fact that a package wasn't modified for a while does not necessarily mean that no modifications were needed. In this case here, several users reported this (way) earlier in LP: #1883957, and (I think) are waiting for a fix, and we do not know all their use cases, hence it's virtually impossible to have workarounds in place for all potential cases (we only have the needed details for just one: LP#1883957, but shouldn't limit ourselves to this). So I am still an advocate for getting things fixed where they are broken and believe that this also helps to reduce risk, compared to touching more/other components and at the end maybe not being able cover everything. The idea of using LP2056485_SOCAT_BEHAVIOUR could work, but might again lead to other risks, like cases where user may switch accounts, but in a way that they loose previously set environment variables etc. - I personally would consider that as more risky and overkill. But the final decision is of course at the SRU team. Meanwhile I've modified the patched package to just cover the two hunks that are related to the TERMIOS_PH_ALL test case - if we will go that route or not. Just try to speed up things in case this will be the way to go ... (since this is about a customer case) (Btw. I have marked LP#1883957 as dup of LP#2056485, because as partner/customer case LP#2056485 came in via the BZ-2-LP-bridge and will cause issues otherwise. But I've referenced both bugs in the changelog, see debdiff - it's probably not the best way, but want to ensure that people who reported this will be notified in case of a fix. If there is a better way, I am happy t adapt it ...) PPA test build (with minimized patch for test case): https://launchpad.net/~fheimes/+archive/ubuntu/lp2056485-3 (build includes successful tests) The updated debdiff is attached. -- 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
