On Mon, Apr 16, 2018 at 5:32 AM, Anders Broman wrote:
>
> I followed the way I do it on Windows, which I think is the recommended
> way there :-)
>
>
The cmake instructions I found always suggest to have the build dir under
the source. For instance the openSUSE %cmake macro is an alias for "cmake
On Mon, Apr 16, 2018 at 09:02:18AM +0200, Dario Lombardo wrote:
> On Mon, Apr 16, 2018 at 5:32 AM, Anders Broman wrote:
>
> >
> > I followed the way I do it on Windows, which I think is the recommended
> > way there :-)
> >
> >
> The cmake instructions I found always suggest to have the build dir
Hi,
Building the RPMs works for me now - Thanks Dario!!!
Regards
Anders
-Original Message-
From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of
Peter Wu
Sent: den 16 april 2018 10:22
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] RPM genera
Good! We can move forward autotools removal I guess. I'm working on it.
On Mon, Apr 16, 2018 at 10:57 AM, Anders Broman
wrote:
> Hi,
> Building the RPMs works for me now - Thanks Dario!!!
> Regards
> Anders
>
> -Original Message-
> From: Wireshark-dev [mailto:wireshark-dev-boun...@wiresh
On Mon, Apr 16, 2018 at 10:22 AM, Peter Wu wrote:
>
> Which instructions? I looked for "cmake -" in the source tree, and all
> documentation in docbook/ suggest a build dir next to the source dir.
> The only example that creates a build dir in the source tree is the
> Gitlab CI configuration.
>
On Mon, Apr 16, 2018 at 12:13:09PM +0200, Dario Lombardo wrote:
> I was just pointing out that sometimes (like the openSUSE %cmake
> macro) there is the general assumption that the build dir is under the
> source dir. This assumption can be found in wireshark/CMakeLists.txt,
> under the rpm-package
On Mon, Apr 16, 2018 at 12:53 PM, Peter Wu wrote:
>
> This seems to limit the rpm-package target to git trees, source tarballs
> seems unsupported, is that intentional? The autotools config did not
> have this limitation from what I can tell.
>
It _was_ limiting. Anders merged my last patch that
On Fri, Apr 13, 2018 at 4:33 AM, Anton Glukhov
wrote:
> Hi all,
>
> I wonder what's the best choice to represent CRC32 little-endian checksum?
> Should It be represented "as is"(exactly how it goes on wire) or I should
> flip it to show it in correct number form. Example: I have valid crc32 for
>
Hi,
Filter names were so far limited to alphanumeric, underscore ('_'),
hyphen ('-') and period ('.') characters. I intend to introduce
additional restrictions:
- Forbid ".foo" (leading dots)
- Forbid "foo..bar" (double "..")
- Forbid "foo." (trailing dots)
The second restriction is needed to su
