Wireshark-dev: Re: [Wireshark-dev] Failed pipeline for nvmeof_getlog_page | wireshark | 3a8e09e
From: "Constantine Gavrilov" <CONSTG@xxxxxxxxxx>
Date: Thu, 1 Apr 2021 08:24:17 +0000
Gerald, João:
Thank you for provided answers. I think it covers it all.
I will fix the warnings. I am not sure how to trigger this pipeline, I hope it will be picked up automatically. If I do not see a build, I will try a manual run.
In retrospective, I am curious whether the project needs CLANG-11 build with a stricter set of compile options? Is it relevant for providing binary packages (perhaps on MACOS)? Or is is purely for the purpose of supporting other people who would like to use other compilers?
--
----------------------------------------
Constantine Gavrilov
Storage Architect
Master Inventor
Tel-Aviv Storage Lab IDT Lead
Tel-Aviv IBM Storage Lab
1 Azrieli Center, Tel-Aviv
Phone: +972-3-6897318
Fax: +972-3-6897230
----------------------------------------
From: "João Valverde via Wireshark-dev" <wireshark-dev@xxxxxxxxxxxxx>
To: wireshark-dev@xxxxxxxxxxxxx
Cc: "João Valverde" <joao.valverde@xxxxxxxxxxxxxxxxxx>
Date: 04/01/2021 12:33 AM
Subject: [EXTERNAL] Re: [Wireshark-dev] Failed pipeline for nvmeof_getlog_page | wireshark | 3a8e09ef
Sent by: "Wireshark-dev" <wireshark-dev-bounces@xxxxxxxxxxxxx>
gitlab.com/constg2021/wireshark
On 31/03/21 21:00, Gerald Combs wrote:
> Hi Constantine,
>
> You receivied the failure notice because:
>
> - You pushed a commit to gitlab.com/constg2021/wireshark. Was this for
> a merge request for wireshark/wireshark? From GitLab's perspective it
> dosen't matter. constg2021/wireshark is a separate project.
>
> - CI/CD is enabled in constg2021/wireshark → Settings →
General →
> Visibility, project features, permissions (which is the default as I
> recall).
>
> - The "clang-11" rule in .gitlab-ci.yml didn't have any rules that
> kept it from running.
>
> - The step failed.
>
> We might want to see if we can update .gitlab-ci.yml to only run build
> steps when $CI_PROJECT_NAME == "wireshark" or when triggered manually.
It's worth noting that the failure for constg2021/wireshark would happen
the same way in wireshark/wireshark when the MR is merged onto
Wireshark's master branch.
So those failures do need fixing before the MR is merged (even though
they are not caught by Merge Request CI/CD).
>
>
> On 3/31/21 11:40 AM, Constantine Gavrilov wrote:
>> Ronnie:
>>
>> Thank you for taking your time to reply. I think you entirely missed
>> my point.
>>
>> The question was not regarding how to fix but about significance of
>> this build test.
>>
>> I saw my previous merge requests approved and even merged when this
>> test failed. I then saw it post factum, and voluntarily updated code
>> in next commits.
>>
>> I also get only occasional reminder about this -- I do not understand
>> why it is not linked to MR, or why MR does not indicate build failure.
>>
>> You are asking why core developers shall care? Obviously, this
>> additional build test was implemented by the project, not by me, as
>> well as unique compile options for CLNAG-11 that make the build to
>> fail while other compilers succeed. Obviously, the was some purpose
>> and thought in this. I do not think it is documented anywhere, so it
>> was a reasonable question.
>>
>> I fail to see how this innocuous question can "rub you in a serious
>> way" or rub other "helpful people". You have made it sound very
>> personal and none of my communications were. If you have issues with
>> other communications I would recommend you reply in the context of
>> those threads and not this one.
>>
>> There is no reason to use a context of a technical question as means
>> of a personal "rub".
>>
>> Can someone answer my question regarding additional build pipeline
>> please?
>>
>>
>> --
>> ----------------------------------------
>> Constantine Gavrilov
>> Storage Architect
>> Master Inventor
>> Tel-Aviv Storage Lab IDT Lead
>> Tel-Aviv IBM Storage Lab
>> 1 Azrieli Center, Tel-Aviv
>> ----------------------------------------
>>
>>
>>
>> From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
>> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>> Date: 03/31/2021 10:41 AM
>> Subject: [EXTERNAL] Re: [Wireshark-dev] Failed pipeline for
>> nvmeof_getlog_page | wireshark | 3a8e09ef
>> Sent by: "Wireshark-dev" <wireshark-dev-bounces@xxxxxxxxxxxxx>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>>
>> It seems like you already know what is wrong and how to solve this.
>> Why not just change your patch so it does not trigger this compiler
>> error/warning? Maybe the compiler is overly sensitive here? Who
>> knows. Why is this a problem for wireshark ZjQcmQRYFpfptBannerStart
>> *This Message Is From an External Sender *
>> This message came from outside your organization.
>> ZjQcmQRYFpfptBannerEnd
>> It seems like you already know what is wrong and how to solve this.
>> Why not just change your patch so it does not trigger this compiler
>> error/warning?
>>
>>
>> Maybe the compiler is overly sensitive here? Who knows.
>> Why is this a problem for wireshark developers?
>>
>> Do this:
>> * fix your code so it does not trigger the warnings. Wireshark
>> developers are not supposed to
>> keep track of what are false warnings that are bogus or what are real
>> problems.
>> * if you have a problem with the compiler, bring it up with them. we
>> are not compiler developers or maintainers.
>> * work on your people skills. You are rubbing people that could help
>> you in seriosly the wrong way.
>>
>>
>> On Wed, Mar 31, 2021 at 5:21 PM Constantine Gavrilov
>> <_CONSTG@xxxxxx.com_ <mailto:CONSTG@xxxxxxxxxx>> wrote:
>> I have a question regarding for a special form of automatic builds
>> that I do not understand.
>>
>> Occasionally, I get an email for additional pipeline build that is
>> different from default pipeline linked to the ticket. It is a wider
>> set of compilers and distributions.
>>
>> Several questions:
>> 1. What is the significance of this and when it is triggered?
>> 2. Why it is not linked to MR (meaning I cannot see this
>> failure in MR)?
>> 3. Shall I fix these failures?
>> 4. How do I know that the issue is fixed, since such builds
>> are not linked to MR?
>> I have looked at this particular one, and it is a a bug in compiler:
>>
>> guint64 off =...; /* take from command context, now looking at reply
*/
>> if (off < 40)
>> proto_add_item(...., .... 40-off,.....);
>>
>> So, the error (in CLANG-11) is (40-off) is 64-bit and passing it as
>> 32-bit parameter "looses high-order bits".
>>
>> First, the compiler shall see that no loss of value takes place
>> because of the "IF" statement here. Second, since when passing 64-bit
>> value as a 32-bit parameter shall be a compiler error in C language?
>>
>> I can easily fix this (check the value in saved context, and if it is
>> above possible payload length return, then declare off as 32-bit),
>> but I need to know if CLANG-11 (with draconian compile options) is a
>> MUST to pass.
>>
>>
>> -
>> ----------------------------------------
>> Constantine Gavrilov
>> Storage Architect
>> Master Inventor
>> Tel-Aviv Storage Lab IDT Lead
>> Tel-Aviv IBM Storage Lab
>> 1 Azrieli Center, Tel-Aviv
>> ----------------------------------------
>> ----- Forwarded by Constantine Gavrilov/Israel/IBM on 03/31/2021
>> 10:07 AM -----
>>
>> From: GitLab <_gitlab@mg.gitlab.com_ <mailto:gitlab@xxxxxxxxxxxxx>>
>> To:
>> Date: 03/30/2021 05:37 PM
>> Subject: [EXTERNAL] Failed pipeline for nvmeof_getlog_page |
>> wireshark | 3a8e09ef
>> Sent by: _gitlab@mg.gitlab.com_ <mailto:gitlab@xxxxxxxxxxxxx>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>> Pipeline #278885577 has failed! Project Constantine Gavrilov /
>> wireshark Branch nvmeof_getlog_page Commit
>> ZjQcmQRYFpfptBannerStart*
>> This Message Is From an External Sender *
>> This message came from outside your organization.
>> ZjQcmQRYFpfptBannerEnd
>>
>> Pipeline #278885577 has failed!
>>
>>
>> Project
>>
>> _Constantine Gavrilov _ <https://gitlab.com/constg2021>/ _wireshark _
>> <https://gitlab.com/constg2021/wireshark>
>> Branch
>>
>>
>> _nvmeof_getlog_page _
>> <https://gitlab.com/constg2021/wireshark/-/commits/nvmeof_getlog_page>
>>
>>
>> Commit
>>
>>
>> _3a8e09ef _
>> <https://gitlab.com/constg2021/wireshark/-/commit/3a8e09ef456178d296452a05fa3624a7755820bf>
>>
>> NVMe: Get LogPage: Commands Supported and Effects
>> Commit Author
>>
>>
>> _Constantine Gavrilov _ <https://gitlab.com/constg2021>
>>
>>
>>
>> Pipeline _#278885577 _
>> <https://gitlab.com/constg2021/wireshark/-/pipelines/278885577>triggered
>> by
>>
>> _Constantine Gavrilov _ <https://gitlab.com/constg2021>
>>
>>
>> had 1 failed build.
>> Failed builds
>>
>> build
>>
>>
>>
>> _clang-11 _ <https://gitlab.com/constg2021/wireshark/-/jobs/1140094712>
>>
>>
>>
>>
>>
>> You're receiving this email because of your account on _gitlab.com_
>> <http://gitlab.com>. _Manage all notifications_
>> <https://gitlab.com/-/profile/notifications>· _Help_
>> <https://gitlab.com/help>
>>
>>
>>
>>
>> ___________________________________________________________________________
>>
>> Sent via: Wireshark-dev mailing list
>> <_wireshark-dev@wireshark.org_ <mailto:wireshark-dev@xxxxxxxxxxxxx>>
>> Archives: _https://www.wireshark.org/lists/wireshark-dev_
>> <https://www.wireshark.org/lists/wireshark-dev>
>> Unsubscribe:
>> _https://www.wireshark.org/mailman/options/wireshark-dev_
>> <https://www.wireshark.org/mailman/options/wireshark-dev>
>> mailto:_wireshark-dev-request@wireshark.org_
>> <mailto:wireshark-dev-request@xxxxxxxxxxxxx>?subject=unsubscribe___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> <https://www.wireshark.org/lists/wireshark-dev>
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> <https://www.wireshark.org/mailman/options/wireshark-dev>
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>> <mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe>
>>
>>
>>
>> ___________________________________________________________________________
>>
>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
>
> ___________________________________________________________________________
>
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
Thank you for provided answers. I think it covers it all.
I will fix the warnings. I am not sure how to trigger this pipeline, I hope it will be picked up automatically. If I do not see a build, I will try a manual run.
In retrospective, I am curious whether the project needs CLANG-11 build with a stricter set of compile options? Is it relevant for providing binary packages (perhaps on MACOS)? Or is is purely for the purpose of supporting other people who would like to use other compilers?
--
----------------------------------------
Constantine Gavrilov
Storage Architect
Master Inventor
Tel-Aviv Storage Lab IDT Lead
Tel-Aviv IBM Storage Lab
1 Azrieli Center, Tel-Aviv
Phone: +972-3-6897318
Fax: +972-3-6897230
----------------------------------------
From: "João Valverde via Wireshark-dev" <wireshark-dev@xxxxxxxxxxxxx>
To: wireshark-dev@xxxxxxxxxxxxx
Cc: "João Valverde" <joao.valverde@xxxxxxxxxxxxxxxxxx>
Date: 04/01/2021 12:33 AM
Subject: [EXTERNAL] Re: [Wireshark-dev] Failed pipeline for nvmeof_getlog_page | wireshark | 3a8e09ef
Sent by: "Wireshark-dev" <wireshark-dev-bounces@xxxxxxxxxxxxx>
gitlab.com/constg2021/wireshark
On 31/03/21 21:00, Gerald Combs wrote:
> Hi Constantine,
>
> You receivied the failure notice because:
>
> - You pushed a commit to gitlab.com/constg2021/wireshark. Was this for
> a merge request for wireshark/wireshark? From GitLab's perspective it
> dosen't matter. constg2021/wireshark is a separate project.
>
> - CI/CD is enabled in constg2021/wireshark → Settings →
General →
> Visibility, project features, permissions (which is the default as I
> recall).
>
> - The "clang-11" rule in .gitlab-ci.yml didn't have any rules that
> kept it from running.
>
> - The step failed.
>
> We might want to see if we can update .gitlab-ci.yml to only run build
> steps when $CI_PROJECT_NAME == "wireshark" or when triggered manually.
It's worth noting that the failure for constg2021/wireshark would happen
the same way in wireshark/wireshark when the MR is merged onto
Wireshark's master branch.
So those failures do need fixing before the MR is merged (even though
they are not caught by Merge Request CI/CD).
>
>
> On 3/31/21 11:40 AM, Constantine Gavrilov wrote:
>> Ronnie:
>>
>> Thank you for taking your time to reply. I think you entirely missed
>> my point.
>>
>> The question was not regarding how to fix but about significance of
>> this build test.
>>
>> I saw my previous merge requests approved and even merged when this
>> test failed. I then saw it post factum, and voluntarily updated code
>> in next commits.
>>
>> I also get only occasional reminder about this -- I do not understand
>> why it is not linked to MR, or why MR does not indicate build failure.
>>
>> You are asking why core developers shall care? Obviously, this
>> additional build test was implemented by the project, not by me, as
>> well as unique compile options for CLNAG-11 that make the build to
>> fail while other compilers succeed. Obviously, the was some purpose
>> and thought in this. I do not think it is documented anywhere, so it
>> was a reasonable question.
>>
>> I fail to see how this innocuous question can "rub you in a serious
>> way" or rub other "helpful people". You have made it sound very
>> personal and none of my communications were. If you have issues with
>> other communications I would recommend you reply in the context of
>> those threads and not this one.
>>
>> There is no reason to use a context of a technical question as means
>> of a personal "rub".
>>
>> Can someone answer my question regarding additional build pipeline
>> please?
>>
>>
>> --
>> ----------------------------------------
>> Constantine Gavrilov
>> Storage Architect
>> Master Inventor
>> Tel-Aviv Storage Lab IDT Lead
>> Tel-Aviv IBM Storage Lab
>> 1 Azrieli Center, Tel-Aviv
>> ----------------------------------------
>>
>>
>>
>> From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
>> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>> Date: 03/31/2021 10:41 AM
>> Subject: [EXTERNAL] Re: [Wireshark-dev] Failed pipeline for
>> nvmeof_getlog_page | wireshark | 3a8e09ef
>> Sent by: "Wireshark-dev" <wireshark-dev-bounces@xxxxxxxxxxxxx>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>>
>> It seems like you already know what is wrong and how to solve this.
>> Why not just change your patch so it does not trigger this compiler
>> error/warning? Maybe the compiler is overly sensitive here? Who
>> knows. Why is this a problem for wireshark ZjQcmQRYFpfptBannerStart
>> *This Message Is From an External Sender *
>> This message came from outside your organization.
>> ZjQcmQRYFpfptBannerEnd
>> It seems like you already know what is wrong and how to solve this.
>> Why not just change your patch so it does not trigger this compiler
>> error/warning?
>>
>>
>> Maybe the compiler is overly sensitive here? Who knows.
>> Why is this a problem for wireshark developers?
>>
>> Do this:
>> * fix your code so it does not trigger the warnings. Wireshark
>> developers are not supposed to
>> keep track of what are false warnings that are bogus or what are real
>> problems.
>> * if you have a problem with the compiler, bring it up with them. we
>> are not compiler developers or maintainers.
>> * work on your people skills. You are rubbing people that could help
>> you in seriosly the wrong way.
>>
>>
>> On Wed, Mar 31, 2021 at 5:21 PM Constantine Gavrilov
>> <_CONSTG@xxxxxx.com_ <mailto:CONSTG@xxxxxxxxxx>> wrote:
>> I have a question regarding for a special form of automatic builds
>> that I do not understand.
>>
>> Occasionally, I get an email for additional pipeline build that is
>> different from default pipeline linked to the ticket. It is a wider
>> set of compilers and distributions.
>>
>> Several questions:
>> 1. What is the significance of this and when it is triggered?
>> 2. Why it is not linked to MR (meaning I cannot see this
>> failure in MR)?
>> 3. Shall I fix these failures?
>> 4. How do I know that the issue is fixed, since such builds
>> are not linked to MR?
>> I have looked at this particular one, and it is a a bug in compiler:
>>
>> guint64 off =...; /* take from command context, now looking at reply
*/
>> if (off < 40)
>> proto_add_item(...., .... 40-off,.....);
>>
>> So, the error (in CLANG-11) is (40-off) is 64-bit and passing it as
>> 32-bit parameter "looses high-order bits".
>>
>> First, the compiler shall see that no loss of value takes place
>> because of the "IF" statement here. Second, since when passing 64-bit
>> value as a 32-bit parameter shall be a compiler error in C language?
>>
>> I can easily fix this (check the value in saved context, and if it is
>> above possible payload length return, then declare off as 32-bit),
>> but I need to know if CLANG-11 (with draconian compile options) is a
>> MUST to pass.
>>
>>
>> -
>> ----------------------------------------
>> Constantine Gavrilov
>> Storage Architect
>> Master Inventor
>> Tel-Aviv Storage Lab IDT Lead
>> Tel-Aviv IBM Storage Lab
>> 1 Azrieli Center, Tel-Aviv
>> ----------------------------------------
>> ----- Forwarded by Constantine Gavrilov/Israel/IBM on 03/31/2021
>> 10:07 AM -----
>>
>> From: GitLab <_gitlab@mg.gitlab.com_ <mailto:gitlab@xxxxxxxxxxxxx>>
>> To:
>> Date: 03/30/2021 05:37 PM
>> Subject: [EXTERNAL] Failed pipeline for nvmeof_getlog_page |
>> wireshark | 3a8e09ef
>> Sent by: _gitlab@mg.gitlab.com_ <mailto:gitlab@xxxxxxxxxxxxx>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>> Pipeline #278885577 has failed! Project Constantine Gavrilov /
>> wireshark Branch nvmeof_getlog_page Commit
>> ZjQcmQRYFpfptBannerStart*
>> This Message Is From an External Sender *
>> This message came from outside your organization.
>> ZjQcmQRYFpfptBannerEnd
>>
>> Pipeline #278885577 has failed!
>>
>>
>> Project
>>
>> _Constantine Gavrilov _ <https://gitlab.com/constg2021>/ _wireshark _
>> <https://gitlab.com/constg2021/wireshark>
>> Branch
>>
>>
>> _nvmeof_getlog_page _
>> <https://gitlab.com/constg2021/wireshark/-/commits/nvmeof_getlog_page>
>>
>>
>> Commit
>>
>>
>> _3a8e09ef _
>> <https://gitlab.com/constg2021/wireshark/-/commit/3a8e09ef456178d296452a05fa3624a7755820bf>
>>
>> NVMe: Get LogPage: Commands Supported and Effects
>> Commit Author
>>
>>
>> _Constantine Gavrilov _ <https://gitlab.com/constg2021>
>>
>>
>>
>> Pipeline _#278885577 _
>> <https://gitlab.com/constg2021/wireshark/-/pipelines/278885577>triggered
>> by
>>
>> _Constantine Gavrilov _ <https://gitlab.com/constg2021>
>>
>>
>> had 1 failed build.
>> Failed builds
>>
>> build
>>
>>
>>
>> _clang-11 _ <https://gitlab.com/constg2021/wireshark/-/jobs/1140094712>
>>
>>
>>
>>
>>
>> You're receiving this email because of your account on _gitlab.com_
>> <http://gitlab.com>. _Manage all notifications_
>> <https://gitlab.com/-/profile/notifications>· _Help_
>> <https://gitlab.com/help>
>>
>>
>>
>>
>> ___________________________________________________________________________
>>
>> Sent via: Wireshark-dev mailing list
>> <_wireshark-dev@wireshark.org_ <mailto:wireshark-dev@xxxxxxxxxxxxx>>
>> Archives: _https://www.wireshark.org/lists/wireshark-dev_
>> <https://www.wireshark.org/lists/wireshark-dev>
>> Unsubscribe:
>> _https://www.wireshark.org/mailman/options/wireshark-dev_
>> <https://www.wireshark.org/mailman/options/wireshark-dev>
>> mailto:_wireshark-dev-request@wireshark.org_
>> <mailto:wireshark-dev-request@xxxxxxxxxxxxx>?subject=unsubscribe___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> <https://www.wireshark.org/lists/wireshark-dev>
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> <https://www.wireshark.org/mailman/options/wireshark-dev>
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>> <mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe>
>>
>>
>>
>> ___________________________________________________________________________
>>
>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
>
> ___________________________________________________________________________
>
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
- Prev by Date: Re: [Wireshark-dev] [Season of Docs] Congratulations on successfully completing your project
- Next by Date: [Wireshark-dev] Support for searching in FT_BYTES or longer bit fields
- Previous by thread: Re: [Wireshark-dev] [Season of Docs] Congratulations on successfully completing your project
- Next by thread: [Wireshark-dev] Support for searching in FT_BYTES or longer bit fields
- Index(es):