[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
With that I'm closing this LP bug by updating it to Won't Fix. (This does not mean that fixes will never be possible or done at all, 'Won't Fix' in this case indicates that the workaround / alternative fix was not desired, hence was not chosen; and it was taken in lieu of a better status.) ** Changed in: ubuntu-power-systems Status: In Progress => Won't Fix ** Changed in: socat (Ubuntu Focal) Status: Incomplete => Won't Fix -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
I've removed this from the queue as requested. Thank you for all your work on this! -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
Hello @Jamie, thanks for your answer and feedback. Your decision is understood. @Robie Based on this, there is no need to follow the alternative approach anymore, and I think this SRU request can be recalled and I would like to ask you to reject socat from the focal unapproved queue. -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
> would like this avenue to be investigated To be clear, I mean the general avenue of workarounds in mkvterm, not necessarily my specific idea. -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
Interleaving Frank's and jldolan's comments here: > I just assumed socat was not a very popular package. My experience is the opposite! I understand it to be used in all kinds of corners - particularly in user scripts that don't appear in the archive. > I've learned (and I generally agree with that) that it is better to stick to entire upstream commits/patches (if possible) for the reason of future maintainability. This is true for development branch tips, but not for the maintenance of stable releases. "Future maintainability" is minimal for socat in Focal, for example: it hasn't had an update since before Focal's release in 2020, and is likely to only need the odd security update in the future. SRU policy says this: > ...the requirements for stable updates are not necessarily the same as those in the development release. When preparing future releases, one of our goals is to construct the most elegant and maintainable system possible, and this often involves fundamental improvements to the system's architecture, rearranging packages to avoid bundled copies of other software so that we only have to maintain it in one place, and so on. However, once we have completed a release, the priority is normally to minimise risk caused by changes not explicitly required to fix qualifying bugs, and this tends to be well-correlated with minimising the size of those changes. As such, the same bug may need to be fixed in different ways in stable and development releases. Therefore, I do not expect to see a change to Makefile.am in this case where changing the build system isn't necessary to fix the bug. If we decide to go ahead with the SRU (see below), then I'd like the upload replaced with a minimal one, please. Improvements to test suites are generally fine though, as they pose little risk to production users and we can benefit from such improvements during SRU verification. As long as we aren't making the tests less useful :) > I think it's close to a philosophical question what is best to do in case > "users of 20.04 relying on the current behaviour". > I personally believe that since the behavior is wrong, that it needs to be > corrected. I agree that it's a difficult question. Like you, I generally lean towards fixing bugs over changing behaviour: if the bug is obviously the wrong behaviour, then I figure that it's perhaps a regression for existing users that would be acceptable. So I would agree were this an issue in Jammy. But Focal is four years old now. At this point I think there are far more users relying on existing behaviour than new deployments relying on correct behaviour. This is what gives me concern. > Please notice that the behavior is correct in all releases newer than focal - means if not fixing this now with an upgrade, things will break at least after a dist-upgrade. This is fine - users expect behaviour changes over a release upgrade far more than they expect behaviour changes during the lifetime of a release. Considering just this point, the former is actually preferable. > Let me check with the Novalink team to see if this is an acceptable workaround for them. Thanks - I think this should at least be considered first given the above concern. If you conclude that it's not possible then I can consult with the SRU team to make a final decision. One possibility for example is to set an environment variable like LP2056485_SOCAT_BEHAVIOUR and have this socat SRU only activate if that is set. mkvterm could either set that, or you could arrange a wrapper. Then we wouldn't have to worry about changed behaviour for other users. I don't know if this is overkill though - I'd want to consult with other SRU team members before going ahead with it. ** Changed in: socat (Ubuntu Focal) Status: In Progress => Incomplete -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
** Changed in: socat (Ubuntu Focal) Status: Incomplete => In Progress -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
Thanks for having a look at this SRU. The general compile of the socat code works after just having commit 5ebf36038f39 "Under certain circumstances, options of the first address were applied to the second address" applied. However, the build also triggers a huge amount of tests, and one, test case 385 'TERMIOS_PH_ALL', is related to this modification and starts to fail. (Btw. this is roughly like the case you mentioned that "affected users of 20.04 may rely on the current behaviour".) Hence a fix is needed to make the 'TERMIOS_PH_ALL' test case work again. And I think this is also reasonable for other (non-test) cases. This was meanwhile upstream fixed "as part of" 9de26f1d0528 "minor corrections, not affecting binaries" (not a great commit msg). The commit 9de26f1d0528 covers different aspects, that are not well documented in the commit description. For this case the modification (as part of 9de26f1d0528) in Makefile.in (and obviously in CHANGES). are not needed. And even the hunks in test.sh: @@ -183,7 +183,7 @@ and @@ -13020,7 +13020,7 @@ are not relevant for the 'TERMIOS_PH_ALL' test case. Only the hunks: @@ -13057,8 +13057,10 @@ and @@ -13066,6 +13068,7 @@ (Whereas hunk '@@ -13066,6 +13068,7 @@' is again not absolutely required for a fixed test.) So yes, the patch could be minimized, for example to cover only: @@ -13057,8 +13057,10 @@ and @@ -13066,6 +13068,7 @@ Well, I thought about this, but from other work (esp. in the kernel area) I've learned (and I generally agree with that) that it is better to stick to entire upstream commits/patches (if possible) for the reason of future maintainability. I think this can be helpful if further patches (due to other bugs are needed) and will reduce risk as well, since the patch is like upstream, means tested like this and incl. like this in never versions. However, if you insist of having this patch minimized; I can do that of course. I think it's close to a philosophical question what is best to do in case "users of 20.04 relying on the current behaviour". I personally believe that since the behavior is wrong, that it needs to be corrected. Please notice that the behavior is correct in all releases newer than focal - means if not fixing this now with an upgrade, things will break at least after a dist-upgrade. Working around this in mkvterm might make the situation (imho) not a lot better (or even worse) and would introduce modification at another place (and would be for focal only, and mkvterm code in never releases might diverge). -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
SRU review Please could you explain why "minor-corrections-in-makefile-and-test- sh.patch" is required - in particular the change to Makefile.in, but also the test change? If only parts are required, can the patch be made more minimal? > [ Where problems could occur ] I accept that this is a bug and the fix is correct. However, I'm concerned about how the proposed change in behaviour might affect users of 20.04 relying on the current behaviour, even if it is incorrect. If a user already has scripting relying on this behaviour, it'll break. Notably, this is being proposed for 20.04 rather than the current LTS. We're four years from release now; I'd expect few new deployments on 20.04 at this point. Given its age and the existence of a newer LTS, users also expect behaviour to be more stable with fewer exceptions at this point in the 20.04 release lifecycle. Perhaps this is what you meant by "If the changed condition of IF was done wrong" but it's not clear to me if this risk has been considered in depth. For example, can you work around this problem in mkvterm instead, just for 20.04, so that the impact to users can be fixed without risking breaking existing users of socat who might be relying on the problem behaviour? If not, can we arrange for some interaction between mkvterm and socat to switch behaviour only if specifically requested? ** Changed in: socat (Ubuntu Focal) Status: In Progress => Incomplete -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
** Changed in: socat (Ubuntu) Status: Invalid => Fix Released -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
** Also affects: socat (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: socat (Ubuntu Focal) Status: New => In Progress ** Changed in: socat (Ubuntu) Status: In Progress => Invalid ** Changed in: socat (Ubuntu Focal) Importance: Undecided => High ** Changed in: socat (Ubuntu Focal) Assignee: (unassigned) => Frank Heimes (fheimes) ** Changed in: socat (Ubuntu) Assignee: Frank Heimes (fheimes) => (unassigned) -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
New build (with changes squashed into one) are successfully build here: https://launchpad.net/~fheimes/+archive/ubuntu/lp2056485-2 Especially test #384 was successful: " test 384 SOCAT_OPT_HINT: check if merging single character options is rejected... OK " The overall test results are like expected: " summary: 386 tests, 354 selected; 184 ok, 0 failed, 170 could not be performed " (Compared to the previous package version the '170 could not be performed' stays and there is in summary one test more, the #384.) Subscribing 'ubuntu-sponsors' (since socat is in 'main'). -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
Debdiff for socat/focal (from 1.7.3.3-2 to 1.7.3.3-2ubuntu0.1). ** Patch added: "debdiff_socat_focal_1.7.3.3-2_to_1.7.3.3-2ubuntu0.1.diff" https://bugs.launchpad.net/ubuntu/+source/socat/+bug/2056485/+attachment/5754053/+files/debdiff_socat_focal_1.7.3.3-2_to_1.7.3.3-2ubuntu0.1.diff ** Changed in: ubuntu-power-systems Status: Triaged => In Progress ** Changed in: socat (Ubuntu) Status: Triaged => In Progress ** Changed in: socat (Ubuntu) Assignee: (unassigned) => Frank Heimes (fheimes) -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
The second build with the additional patch succeeded: https://launchpad.net/~fheimes/+archive/ubuntu/lp2056485 " test 385 TERMIOS_PH_ALL: are termios options applied to the correct address... OK " (actually all test were not successfully completed) I'm now merging both into one package change and do a final build before uploading ... ** Description changed: + SRU Justification: + + [ Impact ] + + * IBM Novalink provides a tool called mkvterm. +Mkvterm takes an lpar id argument and creates a vty-server device on +device nodes /dev/hvcs*. +HVCS is a device driver for the IBM Hypervisor Virtual Console Server +(hvcs). Mkvterm then uses socat to connect. + + * But socat is not behaving as expected. +When escape=0x1d is passed, you have to hit enter for socat to close +(expected behavior is Ctrl-] closing the connection). + + * In addition, Ctrl-C closes the connection. +When using the up and down arrows, junk is printed. +Password is also visible! + + * This is caused by the fact that under certain circumstances, +options of the first address are applied to the second address. + + [ Fix ] + + * 5ebf36038f39 5ebf36038f3960798e769bff5646e755a91a1119 +"Under certain circumstances, options of the first address were applied to the second address" + + * 9de26f1d0528 9de26f1d05284257cd9bbb6eb6662089ab7a0680 +"minor corrections, not affecting binaries" + + [ Test Plan ] + + * There was a special test case introduced for this change +it's test #385. +If this succeeds, the reported issue is solved. + + * Initially this test case failed, because it required another commit +on top: 9de26f1d0528 + + * To verify the overall end-2-end case, the fixes from LP#056373 are required +as well, but can be taken from the PPA test build that was done there. + + * Then configure a vty-server and try to connect with socat: +/usr/bin/socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs[minor num] + + * With an unpatched version one will see that the password is visible. + + * In addition, the up and down arrows do not work and junk is outputted. +In addition, Ctrl-] does not close the vterm. + + * Ctrl-C closes the vterm, and it should not. + + * With a patched version the password will not be visible, +Ctrl+] and Ctrl+C behave as expected. + + [ Where problems could occur ] + + * The code modification is limited to a single line in if +and is pretty traceable, and it's on top limited to terminos. + + * If the changed condition of IF was done wrong, the expected +behavior can change (again) and unforeseen things may happen. + + * The rest of the code changes are text in CHANGES and +a new test case, introduced especially for this bug. + + * Nevertheless, issues can also occur in the (additional) +test code (which happened and got fixed by adding 9de26f1d0528). + + [ Other Info ] + + * Even the code states that this bug is limited to v1.7.3.3. + + * Nevertheless, the code of the socat versions of jammy, mantic +and noble were checked, and they all have the fix included. +(However the code in noble's version changed a bit). + + * So only focal is affected. + __ + ---Problem Description--- - Novalink provides a tool called mkvterm. Mkvterm takes an lpar id argument and creates a vty-server device on device nodes /dev/hvcs*. HVCS is a device driver for the IBM Hypervisor Virtual Console Server (hvcs). Mkvterm then uses socat to connect. + Novalink provides a tool called mkvterm. Mkvterm takes an lpar id argument and creates a vty-server device on device nodes /dev/hvcs*. HVCS is a device driver for the IBM Hypervisor Virtual Console Server (hvcs). Mkvterm then uses socat to connect. Socat is not behaving as expected. When escape=0x1d is passed, you have to hit enter for socat to close (expected behavior is Ctrl-] closing the connection). In addition, Ctrl-C closes the connection. When using the up and down arrows, junk is printed. Password is also visible. - The follow commit fixes the above issues, please add: https://repo.or.cz/socat.git/commit/5ebf36038f39 - + The follow commit fixes the above issues, please add: + https://repo.or.cz/socat.git/commit/5ebf36038f39 + ---uname output--- Linux neop91.pok.stglabs.ibm.com 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:54:35 UTC 2024 ppc64le ppc64le ppc64le GNU/Linux - + ---Steps to Reproduce--- - Fixes to other issues required to reproduce. Mentioned in other bugs. + Fixes to other issues required to reproduce. Mentioned in other bugs. Configure a vty-server and try to connect with socat: /usr/bin/socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs[minor num] Add You will see that the password is visible. In addition, the up and down arrows do not work, junk is outputted. In addition, Ctrl-] does not close the vterm. Ctrl-C closes the vterm, and it should not. -- You received this bug
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
I kicked-off some initial test builds in PPA, but one test fails now: " test 385 TERMIOS_PH_ALL: are termios options applied to the correct address... FAILED ./socat -t 0.1 -T 1 STDIO,echo=0 EXEC:cat " and I see that is related, and got added to test.sh by the requested patch: " +# test for a bug in Socat version 1.7.3.3 where +# termios options of the first address were applied to the second address. +NAME=TERMIOS_PH_ALL ... " It looks like this commit need to be applied on top: 'minor corrections, not affecting binaries' https://repo.or.cz/socat.git/patch/9de26f1d0528 Adding this and kicked off another test build ... -- 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
[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected
** Summary changed: - Multiple issues found on Ubuntu 20.04 against socat + Behaviour of socat in Ubuntu 20.04 unexpected -- 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
