)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000438,"name":"R. Diez","email":"rdiez-2006@rd10.de","username":"rdiez"},"change_message_id":"9a2f6211396c0f2f67911d10395c6e1ffb3b9710","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f3dc30a3_a59331c5","updated":"2025-06-02 17:15:40.000000000","message":"1) The commit summary does not say what drivers are affected by this patch.\n\n2) This is not actually true:\n\u003e Fixes: 7214c8be46f7 (\"configure: show adapter Xilinx XVC/PCIe in the configuration summary\")\nIf some headers are missing, then enabling the adapter before that patch would fail in the same way.\n\n3) \u003e For the driver amt_jtagaccel I\u0027m more in favor of reverting\nhttps://review.openocd.org/c/openocd/+/8835\n\nI do not understand why you want to revert that patch. The patch was fine, it is an improvement on the situation beforehand. If you do not want to fix the driver, because it is not worth it due to the upcoming deprecation, it would be better to switch its default from \u0027auto\u0027 to \u0027no\u0027 until deprecation","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"f74df728f5c0f8d076c17caadb80e6f4ac51be43","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f0b88961_0c1f0306","updated":"2025-05-29 02:49:04.000000000","message":"Looks reasonable. Thanks!","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"527394efb64d0879b9581d488d4606fefefdc0f9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"80fc788d_8d968a7b","updated":"2025-06-03 08:36:10.000000000","message":"Most of users simply run `./configure` without any extra flags.\nMany drivers are not built by default; nobody has complained on these drivers, probably because they never enabled them and we missed important feedback.\n\nIn jenkins build and in my local build, we enable all the possible drivers, but we have installed all the dependencies and we missed the issues that are popping out now.\n\nI have welcome the effort of R. Diez to change `configure.ac`, it\u0027s a nice cleanup and it improves the list of enable drivers.\nAnd I have also pushed him to put `auto` as default for all the drivers. The target was really to detect all build and dependency issues. And here we are! Issues detected thanks to the changes in `configure.ac`.\n\nThis simple patch fixes 2 of the 3 problematic drivers that are now built by default.\n\nFor `amt_jtagaccel` the fix would be more complex, and I don\u0027t see much interest in spending time there in dev and review. This driver will be removed the same day of tag v1.0.0, so around October or November 2025, with patch 8350.\nWe can rework configure.ac to make the driver default `no`. It would not fix the issue but it would be hidden as it has been till merge of 8835. Or we can revert 8835.\nI\u0027m sending out a patch for using default `no` on `amt_jtagaccel`. Let\u0027s move the discussion there.","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000859,"name":"Karl Palsson","email":"karlp@tweak.au","username":"karlp"},"change_message_id":"b2d8f6ede13561662468ff2c4fb8657e0aa7c409","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b7ab920f_f285a4ef","updated":"2025-05-29 14:30:05.000000000","message":"This is good, but we need one more check on parport:\nsrc/jtag/drivers/amt_jtagaccel.c:16:10: fatal error: linux/parport.h: No such file or directory","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000859,"name":"Karl Palsson","email":"karlp@tweak.au","username":"karlp"},"change_message_id":"5261c05934ebf17d1e6c8869cc506d60a775f955","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"946ca06d_7bb793c7","updated":"2025-06-02 21:50:24.000000000","message":"merge this, and make the parport stuff not auto enabled, but \"enableable\" would work fine for me.  Then \"auto\" does nothing wrong, but manual flags enabling partport stuff may or may not fail.","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000438,"name":"R. Diez","email":"rdiez-2006@rd10.de","username":"rdiez"},"change_message_id":"0f5130ef4f1e57577a0dce0c87626b5196c349e5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"36cfb702_6c1aba3b","in_reply_to":"6bbfdbb7_e6fb3ba0","updated":"2025-06-03 06:58:27.000000000","message":"\u003e Not sure if we need to revert `8835`, but the default should be changed to \u0027no\u0027. This makes the patch almost useless :D\n\nI am not sure what what patch you are referring to.\n\nFor the record, patch 8835 (which I wrote) is not \"almost useless\". It is part of an effort to simplify and unify the adapter options in configure.ac . The most visible side-effect is that the affected adapter properly shows up in the configuration summary, as stated in the commit comment.\n\nThe long-term goal of such changes is to clean the OpenOCD build system enough so that fixing other shortcomings I have noticed is easier. I have already fixed a few of them, but other improvements would be harder before such a clean-up.\n\nIf failing adapters are causing pain, the easiest and quickest thing to do would be to change their default from \u0027auto\u0027 to \u0027no\u0027, and mention next to the \u0027no\u0027 default why they cannot be set to \u0027auto\u0027 (which header file is missing, or that it is not worth fixing because it is to be deprecated soon). Fixing the \u0027auto\u0027 logic can be done in a separate patch.","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"4aaa812118c4e7410438e0bf86d4d454eabe2a87","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"c51cc4b2_6b6ba1e4","in_reply_to":"b7ab920f_f285a4ef","updated":"2025-06-02 15:24:08.000000000","message":"For the driver `amt_jtagaccel` I\u0027m more in favor of reverting\n https://review.openocd.org/c/openocd/+/8835\n\nThis driver will be deprecated with\n https://review.openocd.org/c/openocd/+/8349\nand dropped after the tag v1.0.0 with\n https://review.openocd.org/c/openocd/+/8350\n\nLooking at the complicated way the includes are handled in `gw16012.c`, `amt_jtagaccel.c` and `parport.c`, to completely support this mess we need to take care of FreeBSD too.\nDev and test all such code in configure.ac to simply drop it in 2~3 months is a big waste of time.\nI would revert 8835 and merge this 8935 and after v1.0.0 only address the remaining driver `parport.c`.\n\nAdded Marc and R. Diez for their comments","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"change_message_id":"7692d7053698677e048e73b8ac771e35ad57924c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6bbfdbb7_e6fb3ba0","in_reply_to":"c51cc4b2_6b6ba1e4","updated":"2025-06-02 20:07:25.000000000","message":"Not sure if we need to revert `8835`, but the default should be changed to \u0027no\u0027. This makes the patch almost useless :D Anyway, let\u0027s merge this patch (8935) and deprecate the `gw16012` and `amt_jtagaccel` driver as soon as possible.\n\nI have working FreeBSD setup to test the `parport` driver if necessary (later).","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"356f5a282b44eb5a8ac5744281c964df944583c1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ba45fb1a_49f895dd","in_reply_to":"f3dc30a3_a59331c5","updated":"2025-06-03 12:35:50.000000000","message":"1) yes, you are right, I will update it\n2) yes, I will remove the Fixes and simply state that the issue is visible \u0027after\u0027 these patches\n3) please see 8938","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000438,"name":"R. Diez","email":"rdiez-2006@rd10.de","username":"rdiez"},"change_message_id":"160cc0c3abe43ed88744ebe70057b536238f8ed4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"566f8462_147e703e","in_reply_to":"f3dc30a3_a59331c5","updated":"2025-06-03 12:13:59.000000000","message":"Done","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"}],"configure.ac":[{"author":{"_account_id":1000438,"name":"R. Diez","email":"rdiez-2006@rd10.de","username":"rdiez"},"change_message_id":"cbb87763d74d794bbc34341964d7e043995f2078","unresolved":true,"context_lines":[{"line_number":696,"context_line":"PROCESS_ADAPTERS([SYSFSGPIO_ADAPTER], [\"x$is_linux\" \u003d \"xyes\"], [Linux sysfs])"},{"line_number":697,"context_line":"PROCESS_ADAPTERS([REMOTE_BITBANG_ADAPTER], [true], [unused])"},{"line_number":698,"context_line":"PROCESS_ADAPTERS([LIBJAYLINK_ADAPTERS], [\"x$use_internal_libjaylink\" \u003d \"xyes\" -o \"x$use_libjaylink\" \u003d \"xyes\"], [libjaylink-0.2])"},{"line_number":699,"context_line":"PROCESS_ADAPTERS([PCIE_ADAPTERS], [\"x$is_linux\" \u003d \"xyes\" -a \"x$ac_cv_header_linux_pci_h\" \u003d \"xyes\"], [Linux build])"},{"line_number":700,"context_line":"PROCESS_ADAPTERS([SERIAL_PORT_ADAPTERS], [\"x$can_build_buspirate\" \u003d \"xyes\"],"},{"line_number":701,"context_line":"                                         [internal error: validation should happen beforehand])"},{"line_number":702,"context_line":"PROCESS_ADAPTERS([LINUXSPIDEV_ADAPTER], [\"x$is_linux\" \u003d \"xyes\" -a \"x$ac_cv_header_linux_spi_spidev_h\" \u003d \"xyes\"],"}],"source_content_type":"application/octet-stream","patch_set":2,"id":"72ca56b1_2aba0cb6","line":699,"updated":"2025-06-03 06:46:36.000000000","message":"The \"Linux build\" hint is not enough, an additional hint should be added here about what is missing. The other adapter mentions \"spidev\", perhaps something like \"PCI dev\" would suffice.","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000438,"name":"R. Diez","email":"rdiez-2006@rd10.de","username":"rdiez"},"change_message_id":"160cc0c3abe43ed88744ebe70057b536238f8ed4","unresolved":false,"context_lines":[{"line_number":696,"context_line":"PROCESS_ADAPTERS([SYSFSGPIO_ADAPTER], [\"x$is_linux\" \u003d \"xyes\"], [Linux sysfs])"},{"line_number":697,"context_line":"PROCESS_ADAPTERS([REMOTE_BITBANG_ADAPTER], [true], [unused])"},{"line_number":698,"context_line":"PROCESS_ADAPTERS([LIBJAYLINK_ADAPTERS], [\"x$use_internal_libjaylink\" \u003d \"xyes\" -o \"x$use_libjaylink\" \u003d \"xyes\"], [libjaylink-0.2])"},{"line_number":699,"context_line":"PROCESS_ADAPTERS([PCIE_ADAPTERS], [\"x$is_linux\" \u003d \"xyes\" -a \"x$ac_cv_header_linux_pci_h\" \u003d \"xyes\"], [Linux build])"},{"line_number":700,"context_line":"PROCESS_ADAPTERS([SERIAL_PORT_ADAPTERS], [\"x$can_build_buspirate\" \u003d \"xyes\"],"},{"line_number":701,"context_line":"                                         [internal error: validation should happen beforehand])"},{"line_number":702,"context_line":"PROCESS_ADAPTERS([LINUXSPIDEV_ADAPTER], [\"x$is_linux\" \u003d \"xyes\" -a \"x$ac_cv_header_linux_spi_spidev_h\" \u003d \"xyes\"],"}],"source_content_type":"application/octet-stream","patch_set":2,"id":"c936cc40_987485aa","line":699,"in_reply_to":"257f4cd3_c109d8bd","updated":"2025-06-03 12:13:59.000000000","message":"\u003e Yes, I agree, but it is out of the scope of this patch.\n\nOn the contrary, I think that now is the right time to mention \"PCI dev\" or similar in that line.\n\nAfter all, we have just realised that \"Linux build\" is not the only requirement, that some optional header is also necessary, and this patch is testing now for that particular header. Therefore, now is the right time to add a hint about it.\n\nI will not oppose this patch just for this reason. But think of the consequence: do you think that somebody else will propose a separate patch for this change alone? Would you do the effort for such a tiny thing?\n\nAs a result, the most likely scenario is that someone in the future tries to enable that adapter on Linux but without the right headers, and the configure script will reject it citing \"Linux build\" as the reason, which is very confusing.","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"527394efb64d0879b9581d488d4606fefefdc0f9","unresolved":false,"context_lines":[{"line_number":696,"context_line":"PROCESS_ADAPTERS([SYSFSGPIO_ADAPTER], [\"x$is_linux\" \u003d \"xyes\"], [Linux sysfs])"},{"line_number":697,"context_line":"PROCESS_ADAPTERS([REMOTE_BITBANG_ADAPTER], [true], [unused])"},{"line_number":698,"context_line":"PROCESS_ADAPTERS([LIBJAYLINK_ADAPTERS], [\"x$use_internal_libjaylink\" \u003d \"xyes\" -o \"x$use_libjaylink\" \u003d \"xyes\"], [libjaylink-0.2])"},{"line_number":699,"context_line":"PROCESS_ADAPTERS([PCIE_ADAPTERS], [\"x$is_linux\" \u003d \"xyes\" -a \"x$ac_cv_header_linux_pci_h\" \u003d \"xyes\"], [Linux build])"},{"line_number":700,"context_line":"PROCESS_ADAPTERS([SERIAL_PORT_ADAPTERS], [\"x$can_build_buspirate\" \u003d \"xyes\"],"},{"line_number":701,"context_line":"                                         [internal error: validation should happen beforehand])"},{"line_number":702,"context_line":"PROCESS_ADAPTERS([LINUXSPIDEV_ADAPTER], [\"x$is_linux\" \u003d \"xyes\" -a \"x$ac_cv_header_linux_spi_spidev_h\" \u003d \"xyes\"],"}],"source_content_type":"application/octet-stream","patch_set":2,"id":"257f4cd3_c109d8bd","line":699,"in_reply_to":"72ca56b1_2aba0cb6","updated":"2025-06-03 08:36:10.000000000","message":"Yes, I agree, but it is out of the scope of this patch.\nThis patch is only trying to fix the build asap.\n\nThere are other issues that I see we do not handle correctly.\nFor example we have in `configure.ac` lines like\n`AC_CHECK_HEADERS([unistd.h])`\nthat generate the macro `HAVE_UNISTD_H`, but many files directly include `unistd.h` without checking the macro!\nSimilar issue for many of the includes tested with `AC_CHECK_HEADERS`","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"356f5a282b44eb5a8ac5744281c964df944583c1","unresolved":false,"context_lines":[{"line_number":696,"context_line":"PROCESS_ADAPTERS([SYSFSGPIO_ADAPTER], [\"x$is_linux\" \u003d \"xyes\"], [Linux sysfs])"},{"line_number":697,"context_line":"PROCESS_ADAPTERS([REMOTE_BITBANG_ADAPTER], [true], [unused])"},{"line_number":698,"context_line":"PROCESS_ADAPTERS([LIBJAYLINK_ADAPTERS], [\"x$use_internal_libjaylink\" \u003d \"xyes\" -o \"x$use_libjaylink\" \u003d \"xyes\"], [libjaylink-0.2])"},{"line_number":699,"context_line":"PROCESS_ADAPTERS([PCIE_ADAPTERS], [\"x$is_linux\" \u003d \"xyes\" -a \"x$ac_cv_header_linux_pci_h\" \u003d \"xyes\"], [Linux build])"},{"line_number":700,"context_line":"PROCESS_ADAPTERS([SERIAL_PORT_ADAPTERS], [\"x$can_build_buspirate\" \u003d \"xyes\"],"},{"line_number":701,"context_line":"                                         [internal error: validation should happen beforehand])"},{"line_number":702,"context_line":"PROCESS_ADAPTERS([LINUXSPIDEV_ADAPTER], [\"x$is_linux\" \u003d \"xyes\" -a \"x$ac_cv_header_linux_spi_spidev_h\" \u003d \"xyes\"],"}],"source_content_type":"application/octet-stream","patch_set":2,"id":"98c6abf9_67b5e347","line":699,"in_reply_to":"c936cc40_987485aa","updated":"2025-06-03 12:35:50.000000000","message":"\u003e Would you do the effort for such a tiny thing?\n\nI\u0027m actually waiting to have all the drivers listed in the output table to consolidate the reworks.\nI see you are adding a new group for each driver, and that\u0027s ok because we still need to find the common requirements. But later we should group them.\n\nWe already have two entries in the output table that are not drivers:\n```\nUse Capstone disassembly framework       yes (auto)\nCollect coverage using gcov              no\n```\nso we can add more info like missing include file or libraries.\nAnd it should be nice to add, after each `no`, the reason for not building a driver.","commit_id":"ba70c2f9c99ec29f94e4c7c5b2f2143fca0421be"}]}