@ngie , it seems we could land it, and copyright topic could be revised for entire project with separate commit(s). What do you think?
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Sun, Jan 11
Throw std::system_error instead of std::runtime_error upon kldload failure
Explicitly describe execenv involvement in "kyua help debug"
Sat, Dec 27
Make it skip writing stdout/stderr to tmp files, as "debug -p" does
Fri, Dec 26
Communicate kldload issues via exceptions
Thu, Dec 25
In D52642#1205688, @markj wrote:This works almost exactly how I want, thank you. I have one "complaint": when I use this mode, kyua 1) drops me in the shell, 2) waits for the shell to exit, 3) prints the debug output, e.g., executed commands and the test failure string. The -p mode is basically the same. It is more useful to do 3) first, then 1) and 2). Is it hard to make this change?
Resolved review comments
Dec 19 2025
Hi @ngie. It seems your time budget is very limited. Thank you for all the comments you provided for this patch, it helped polishing the things and making it better. I'm going to land it soon so that we could start actual testing of the idea. Fortunately, it's an opt-in helper tool for a developer and nothing depends on it. Anyway, before it can be useful we need to continue labelling the tests with required_kmods declarations.
Dec 16 2025
Dec 14 2025
LGTM. The same testing passed on my side, with the same build and test env. The only obstacle I had is this:
In file included from netlink_netlink_snl_route_parsers.c:1:
In file included from /home/igoro/src/sys/netlink/netlink_snl_route_parsers.h:30:
/home/igoro/src/sys/netlink/netlink_snl.h:122:12: error: comparison of integers of different signs: 'int' and 'uint32_t' (aka 'unsigned int') [-Werror,-Wsign-compare]
122 | if (delta > lb->size - lb->offset)
| ~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~
1 error generated.
*** [netlink_netlink_snl_route_parsers.o] Error code 1Dec 13 2025
Implement x/y flaky spec
Dec 10 2025
In D54148#1237012, @jhb wrote:Igor, are you able to test this again on your armv7 setup btw?
Dec 9 2025
LGTM. That's an important point regarding the other data allocated from the snl_state.
Dec 6 2025
Dec 1 2025
It seems to be ready for landing to slowly start actual testing and adoption.
Nov 15 2025
In D53697#1226388, @jhb wrote:@igoro would you be able to test this on your workload (armv7) to ensure it still does the correct thing?
Nov 11 2025
Now I remember that the latest fix's key goal was to add missing nw->size maintenance not to realloc again-and-again when it's actually not needed, i.e. after each realloc we still think that nw->size is only 256. And the motivation was to avoid overlapping buffers appeared to be there as a consequence of missing nw->size maintenance.
Oct 11 2025
Oct 10 2025
In D52910#1211188, @ivy wrote:i'm not opposed to this, but i don't understand why it's required. is this an upstream bug, or are we building libkrb5 wrongly?
Oct 5 2025
Thanks for your time and review.
Oct 4 2025
This seems to be revealed with the recent switch to MIT version. For example, 15-CURRENT back in March had this:
# ldd /usr/lib/libkrb5.so
/usr/lib/libkrb5.so:
libasn1.so.11 => /usr/lib/libasn1.so.11 (0x36e32d570000)
libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x36e309956000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x36e30a44a000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0x36e30a600000)
libhx509.so.11 => /usr/lib/libhx509.so.11 (0x36e339780000)
libroken.so.11 => /usr/lib/libroken.so.11 (0x36e30ac5a000)
libwind.so.11 => /usr/lib/libwind.so.11 (0x36e33bec0000)
libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x36e30834e000)
libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 (0x36e30ba76000)
libc.so.7 => /lib/libc.so.7 (0x36e308e00000)
libmd.so.7 => /lib/libmd.so.7 (0x36e30c885000)
libthr.so.3 => /lib/libthr.so.3 (0x36e30d741000)
libsys.so.7 => /lib/libsys.so.7 (0x36e318150000)Sep 21 2025
Sep 20 2025
The prototype has the following logic currently:
Always attempt to use $SHELL
Sep 6 2025
Sep 5 2025
In D51136#1196294, @ngie wrote:In D51136#1170880, @igoro wrote:In D51136#1170613, @ngie wrote:What was the behavior prior to this change?
It's turned out that kyua test catches issues with temporary dir/files cleanup but does not propagate it -- that's obvious from the code where test_result is not used actually. As a result, a test is marked as passed leaving garbage behind (tmp dirs/files), while by design and code comments it is expected to be broken instead.
Will this cause false positives with cleanup failures?
Rebase onto the latest kyua changes and rework from rr to prepare
Aug 24 2025
Aug 16 2025
Aug 3 2025
A minuscule improvement to get the following upon atf_check_equal failure:
Error Message: 1 != $(jexec alcatraz sysctl -n net.dummymbuf.hits) (1 != 2)
instead of this:
Error Message: 1 != 2 (1 != 2)
Aug 1 2025
Jul 18 2025
Thank you very much for identifying the root cause. I've been monitoring the false positives on the CI since Oct-2024 -- 25 of them so far. And my TODO list is too deep.
Jul 13 2025
Jul 12 2025
In D51136#1170613, @ngie wrote:What was the behavior prior to this change?
Jul 9 2025
LGTM. And I had a successful testing on my side.
Jul 2 2025
LGTM
In D51035#1165778, @ngie wrote:Please submit this upstream. We need to work through the porting issues with Linux/MacOS in order to land this to avoid having multiple different forks/mutations of this (ATF) code.
Jun 8 2025
May 24 2025
May 23 2025
The combinatorics seems to be as follows:
May 17 2025
May 11 2025
Improve the man page wording
May 10 2025
It looks fine that atf-check wants to verify that its temporary dir has enough access rights as it needs to store output files beneath. Why does it add so many code to handle it explicitly? Probably, a usual noperm file system error does not propagate nicely and leaves a test result reader guessing about the actual root cause. Why doesn't it "escape" the current umask instead (as this patch proposes)? Maybe, there was another reason to obey the current umask when ATF was just a separate project before Kyua introduction and it was invoked directly. I do not see answers in the code parts I've read.
In D49463#1143637, @ngie wrote:This feature can be refined, but I don’t want to get in the way of the utility of this change for folks like @kp, who need the debuggability. Let’s go forward with this change and refine things/sand down rough edges on GitHub.
Fix the man page format
Apr 21 2025
Apr 16 2025
I remember ngie@ agreed in some past cases to go directly to the src while the expected vendor path could go in parallel at its own pace. The vendor branch seems to be non-updated since its import back in 2020, so the vendor path may face obstacles and could take time. I mention this just in case if there is a need to hit src sooner, so that an exception agreement could be considered.
Apr 13 2025
In D49798#1135647, @ziaee wrote:for format/typo changes, I don't bump the date.
Sorry for the oversight, this is correct. We should not bump the date here.
Apr 12 2025
Apr 8 2025
Apr 5 2025
Many thanks for review! It was a rush to meet the deadline, and there weren't enough rounds of self-check.
Fix format and style
Apr 2 2025
It seems that as a temporary solution it is good to have them explicitly "tagged" to easily find the ones which need revising to avoid external dependencies.
Apr 1 2025
In D49594#1131294, @lwhsu wrote:I am happy to see allow_network_access feature has been added to the test framework. I believe it would be useful in some cases that network access is mandatory. However, in the case of DNS resolving, I suggest we just using the built-in local unbound for a simple local resolver to serve the test needs.
In D49594#1131294, @lwhsu wrote:Sorry for being late to this (well, the window is quite short and I have been busy with other things recently...)
In D49594#1130770, @igoro wrote:While ideally tests should not depend on external things as much as possible to have more reproducible nature, some of them may require to reach external resources, let's say to fetch something or to talk to the world services like DNS, etc.
Indeed and that's also why I am still hesitated to enable internet access on the jails in builder (when doing builds with the patches come from external) and when running the tests in VM. It's not only the security reason but also the matter of tests stability and reliability.
Mar 31 2025
In D49594#1130777, @ziaee wrote:We can do it later, but if you mark these variables up as It Va instead of It, they become searchable; e.g. apropos Va=allow_network.
While ideally tests should not depend on external things as much as possible to have more reproducible nature, some of them may require to reach external resources, let's say to fetch something or to talk to the world services like DNS, etc.