Re: [Wireshark-dev] GitLab migration update

2020-04-04 Thread Dario Lombardo
I get Signing in using your Google account without a pre-existing GitLab account is not allowed. Create a GitLab account first, and then connect it to your Google account. I guess this is how gitlab works. I've never tried that before. However, I logged in in via github and then connected my goo

Re: [Wireshark-dev] GitLab migration update

2020-04-04 Thread Gerald Combs
On 4/4/20 9:16 AM, Dario Lombardo wrote: > Hi Gerald > The test server allows me to log in with github and gitlab.com > account. Gerrit allowed google account sso and gitlab.com > itself allows that. > Is that wanted? Can we allow google login as well? I d

Re: [Wireshark-dev] range_string checking

2020-04-04 Thread Martin Mathieson via Wireshark-dev
In the previous message I said " I suspect having a more complicated test probably find many more issues." I meant to say that I doubted it would. Have uploaded https://code.wireshark.org/review/#/c/36708/ for the remaining issues and the checking code itself. Only spec I couldn't find for was

Re: [Wireshark-dev] range_string checking

2020-04-04 Thread Martin Mathieson via Wireshark-dev
Yes, I'm sure I've seen an example where there is a catch-all at the end of each of a number of ranges, then a catch-all covering all ranges after that. I am still only complaining if a later item is completely hidden by a single, earlier one. If I understand what you said, I suppose I could chec

Re: [Wireshark-dev] GitLab migration update

2020-04-04 Thread Dario Lombardo
On Sat, Apr 4, 2020, 01:47 Gerald Combs wrote: > > We also have a self-hosted test server up and running at > https://gitlab-test.wireshark.org. Feel free to create an account, create > merge requests, etc. If you'd like to try out a feature that requires a > configuration change, let me know. >

Re: [Wireshark-dev] range_string checking

2020-04-04 Thread Jaap Keuter
> On 2 Apr 2020, at 23:08, Martin Mathieson via Wireshark-dev > wrote: > > It is common to have a 'catch-all' case for parts or all of the range, which > is Ok if it comes after more specific entries. I'm wondering if its worth > complaining if *part* of an entry is hidden by an earlier one