Re: [Wireshark-dev] MSVC gives warnings "qt_ui_utils.cpp(208, 25): warning C4996: 'QProcess::startDetached'"

en if it's an empty > QStringList. > >> On Fri, 11 Feb 2022 at 10:15, Anders Broman via Wireshark-dev >> wrote: >> Hi, >> >> Latest released one >> >> C:\Qt\5.15.2 >> >> Regards >> >> Anders >> >>

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

. And forcing them by breaking mid-release is not a good idea in my point of view. Now breaking between major releases - I am all for that (within reason). Am Do., 20. Jan. 2022 um 22:25 Uhr schrieb Guy Harris : > On Jan 20, 2022, at 1:12 PM, Roland Knall wrote: > > > But it was

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

Just to add to utilities that utilize such a library is https://github.com/epl-viz/EPL-Viz I agree that such an utility could be added to Wireshark itself, and it is not actively developed anymore (at least to my knowledge). But it was implemented by utilizing heavily a wireshark installation

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

May I suggest that we focus on the discussion at hand here. The discussion about the package itself seems to be better suited for the issue list specific for that package, as is the purpose for that list. The issue here is, that with change

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

For clarification: " but the change should most certainly happen with a version beyond 3.6" means, that the break should be reverted for 3.6.x, but it should be put in place for -dev to be in the next major release cheers Am Do., 20. Jan. 2022 um 16:28 Uhr schrieb Roland Knall :

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

I think it is reasonable to assume that libraries provided with the project are being used by external programs. I know one utility which is being used in a rather closed-off community (but nonetheless widely adopted by around 200-300 people), which got broken by this. Their solution is to stay on

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

er, but >> that was removed in 6e5ba74b. I think it would be worthwhile to try adding >> it back in a more simplified form for release branches, but I'm not sure >> when I would have time to work on that. >> >>> On 1/20/22 7:29 AM, Roland Knall wrote: >>

Re: [Wireshark-dev] Description of Wireshark User's Guide 4.3.0

Hi Yes, the developer and user guides live a somewhat trist live beside the main source code repository. But you can easily change the content, by submitting a merge request. Both are generated by the sources underneath /docbook inside the repository. wsug is the directory for the user guide and

[Wireshark-dev] Qt6 default for -dev tree

Hi all With the release of the release candidate for 4.0 something else changed in the source-tree and I just wanted to make you aware of that. Over the past few weeks, whenever you built from the source-tree, you had the option to run cmake with the parameter -DUSE_qt6=ON to enable a build

Re: [Wireshark-dev] Future of extcap "API"

Adding another helper may be helpful, as it would probably gives us greater control, and maybe also solve the "helper-script" issue in the future by putting that stuff inside Wireshark? I am just wondering if it is worth the effort. We can obviously strive for a perfect - no user interaction

Re: [Wireshark-dev] Future of extcap "API"

One of the benefits of the extcap-cli is, that we can and currently do, send an API version to the extcap utility which would allow breaking changes while still enabling a compatibility mode for older versions. Because of that, I think 2 would be an ideal scenario, just define the response to

Re: [Wireshark-dev] CARES to old for CentOS8?

The reason for 1.14 was a CVE that was fixed. I would vote strongly against reducing the Version just to support an older version. Regards, RolandAm 28.09.2022 um 18:48 schrieb John Thacker :On Wed, Sep 28, 2022, 10:47 AM Anders Broman wrote:Hi,Is there a workaround

Re: [Wireshark-dev] can't compile wireshark version 4.0

Please attach your cmake outputAm 20.10.2022 um 17:30 schrieb chuck c :Can you add a link to the source bundle you downloaded.On Thu, Oct 20, 2022 at 10:22 AM w...@comcast.net wrote: I can't compile wireshark version 4.0 on Raspberry Pi ubuntu 22.04

Re: [Wireshark-dev] Compile fails with Qt 6.4.0 on windows

Hi For now, 6.4.0 is not supported. 6.3.x are the latest compatible versions. Work is being done on achieving compatibility. regards Roland Am Di., 11. Okt. 2022 um 21:23 Uhr schrieb Anders Broman < a.broma...@gmail.com>: > Hi, > Setting up on a new PC I just grabbed the latest Qt version and

Re: [Wireshark-dev] CARES to old for CentOS8?

officially supports RHEL 8 derived > distributions seems hasty to me. > > John > > On Fri, Sep 30, 2022, 7:43 AM Roland Knall wrote: > >> Hi. >> >> Ok, maybe I have to clarify my thought process here a little bit. The >> original version we required as

Re: [Wireshark-dev] CARES to old for CentOS8?

already shipping (i.e., they'd create a >>>>> version like 1.13.0. rather than upgrading to 1.14.x). They >>>>> work >>>>> hard to avoid changing version numbers for compatibility reasons. >>>>> >>>>> On Thu, Sep 29, 2022 at 6

Re: [Wireshark-dev] CARES to old for CentOS8?

Hi, >> Well a choice to make if we want to support CentOS8/RHEL8 or not. One >> could argue that CVE:s in support libraries might not be for us to >> decide on but rather the OS maintainers. >> Best regards >> Anders >> >> Den tors 29 sep. 2022 kl 08:19

Re: [Wireshark-dev] What is the best way to locate [GLib CRITICAL] -- g_string_free: assertion 'string != NULL' failed

Also, more on the point, we have our own memory management system called wmem in which you allocate stuff within a scope and Wireshark handles freeing up the memory. Look for a README.wmem underneath /doc as well as the Wireshark developer guide for usage and the examples Cheers Roland > Am

Re: [Wireshark-dev] Error building from source: /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libgpg-error.a(libgpg_error_la-init.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be

Not sure if you can build dumpcap statically. Can you build the whole suite on the same machine, without building it statically? Just to ensure, that all the right libraries are installed at least. regards Roland Am Do., 10. Nov. 2022 um 17:38 Uhr schrieb jorge.pinto.sousa via Wireshark-dev : >

Re: [Wireshark-dev] macOS Xcode build failure on multiple commands producing same directory

Always Am Fr., 3. März 2023 um 13:27 Uhr schrieb Alexander Kapshuk < alexander.kaps...@gmail.com>: > On Wed, Mar 1, 2023 at 9:21 PM Guy Harris wrote: > > > > On Mar 1, 2023, at 7:18 AM, Alexander Kapshuk < > alexander.kaps...@gmail.com> wrote: > > > > > Pointers on how to proceed with this

Re: [Wireshark-dev] Wireshark 4.0.1 clone and build fails with test failures and complaints about paths prefixed in the source directory

It is preferred, that WIRESHARK_BASE_DIR is defined at the top directory, and not underneath the source directory. Also, it cannot be omitted as documented in our build documentation. Additionally, it is recommended to do an out-of-source build, to better be able to update the sources if needed.

Re: [Wireshark-dev] Building Wireshark From Source MacOS

That version of Wireshark is not supported with Mac OSX 13.x or higher. Please use a later version. But, for that specific protocol, you could also try the following dissector, written in Lua: https://github.com/netspooky/dissectors/blob/main/acble.lua cheers Roland Am Do., 4. Mai 2023 um 16:52

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Ok, I am not ignoring those points, as I think those points are valid. It makes sense, that building debian packages from the repository should behave in the same way as it does with the overall projects. Now, one could argue, that having multiple packages could have been avoided in the beginning

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi Balint It would be worth amending the Readme with this information, as well as the packaging section of the wiki, to ensure this information is not getting lost and future discussions may be avoided by pointing to it. kind regards Roland Am Mi., 20. Dez. 2023 um 14:24 Uhr schrieb Bálint

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde : > > > On 20/12/23 16:06, Roland Knall wrote: > > Ok, I am not ignoring those points, as I think those points are valid. > > It makes sense, that building debian packages from the repository > > should behave

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

It might be the best for their users, but we also facilitated that approach by our approach to the whole issue. Am Mi., 20. Dez. 2023 um 19:57 Uhr schrieb Bálint Réczey < bal...@balintreczey.hu>: > Roland Knall ezt írta (időpont: 2023. dec. 20., Sze, > 17:06): > > > > Ok, I am

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

> Am 20.12.2023 um 22:43 schrieb João Valverde : > >  > >> On 20/12/23 21:21, Roland Knall wrote: >> >>>> Am 20.12.2023 um 22:02 schrieb João Valverde : >>> >>>  >>> >>>> On 20/12/23 20:52, Roland Knall wrote:

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

> Am 20.12.2023 um 22:02 schrieb João Valverde : > >  > >> On 20/12/23 20:52, Roland Knall wrote: >> >> >> Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde : >> >> >> >>On 20/12/23 16:06, Roland Knall wrote: >>

Re: [Wireshark-dev] Changes to the plugin registration API

matches the FSF FAQ, is wrong, >>>> please do >> >> share. I'm very open to a good-faith discussion. >>>> >>>> >>>> > Best regards >>>> > Anders >>>&

Re: [Wireshark-dev] Changes to the plugin registration API

I do not think we need to revert the whole change. I actually like the way the new version check is implemented and think it is beneficial to a lot of users, because it will reduce the number of changes they have to make in order to update their version. But I do think the enforcement of licenses

Re: [Wireshark-dev] Changes to the plugin registration API

I do not think there is a need for calling someone confused. The whole discussion is not in any way useful for our users. There is the explicit corporate usecase, where in-house versions do exist with their own protocols and plugins. Often times those versions do not even deal with licenses for

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

As mentioned on the ticket - just putting it here as well - I am against dropping packaging/debian. But I am for having it underneath packaging, and not in the main directory, which is what the original change was about. I respect Joao's opinion as well as yours Balint. In this case here I think,

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi I would recommend that we bring this topic before the technical steering committee. As of right now, that committee needs to be formed in January and this topic is exactly why we are going to have the committee in the first place. The process is in the final steps and should be finished by the

Re: [Wireshark-dev] Bug report: Wireshark windows ignores the space character in the "ssh remote capture" feature for "ssh server password" login credentials

Hi Could you file an issue at https://gitlab.com/wireshark/wireshark/-/issues/new ? kind regards Roland Am Mi., 17. Apr. 2024 um 17:17 Uhr schrieb Nicolo Campari < nicolo.camp...@intecs.it>: > Hi, > > Wireshark windows ignores the space character in the "ssh remote capture" > feature for "ssh

Re: [Wireshark-dev] adding a Group filter option to the expert info dialog

Hi I would take the combobox for "Show" and put a second one for the levels beside it. You than can copy the code that gets triggered by that box "ExpertInfoDialog::limitCheckBoxToggled" and add your code to it. Don't worry about the design (the whole dialog is not really up to date) and just add

Re: [Wireshark-dev] Is wireshark.org possibly hacked?

We will be looking into it kind regards Roland Am Di., 25. Juni 2024 um 18:24 Uhr schrieb Triton Circonflexe < triton+enu...@kumal.info>: > It seems to be an issue with the placement of the clear/dark theme > javascript. > > I checked the about.html page with a simple "view source" and Firefox

<    1   2   3   4   5