On Sun, 05 Aug 2018 14:12:31 +0100 Francois-Xavier Le Bail
wrote
> On 05/08/2018 14:46, Denis Ovsienko wrote:
> > On Sat, 04 Aug 2018 08:41:10 +0100 Francois-Xavier Le Bail
> > wrote
> > > On 04/08/2018 09:03, Guy Harris wrote:
> >
On Sun, 05 Aug 2018 18:21:47 +0100 John Hawkinson wrote
> Denis Ovsienko wrote on Sun, 5 Aug 2018
> at 17:05:20 +0100 in
> <1650ad5fd29.b5d2798f311917.536858429581803...@ovsienko.info>:
>
> > It works in an interactive session; but as soon as the
On Mon, 06 Aug 2018 09:51:36 +0100 John Hawkinson wrote
> Denis Ovsienko wrote on Mon, 6 Aug 2018
> at 09:42:16 +0100 in
> <1650e66b5ad.12b3ab99e15597.8336631397456496...@ovsienko.info>:
>
> > When a network protocol has a timestamp and defines i
o in ts_date_hmsfrac_print() as well, if time_flag isn't
> LOCAL_TIME?
Looks like so.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
capture each time they need a different mask
length.
I agree in some cases it is best to mask the endpoints right at the capture
time, but do you see the use case for offline masking (as in "tcpdump -r
infile.pcap -w outfile.pcap ")?
--
Denis Ovsienko
___
+ u_int hdrlen, len;
> +
> +hdr = (const struct ieee80211_radiotap_header
> *)p;
> +len =
> EXTRACT_LE_16BITS(&hdr->it_len);
> +
> + hdrlen = ieee802_11_radio_print(ndo, p, h->len,
&g
; It can bring errors (forgetting...).
>
> Could we do things differently ?
With things done this way it looks like this issue could happen, although it
would result in incorrect labeling, not incorrect behaviour.
A possible solution could be some stack structure and a macro to call th
e to remove --enable-smb/--disable-smb (enable possibly-buggy SMB
> printer) code ?
To me the flag mainly serves as a reminder to merge tcpdump pull request #518.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
k you.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
f-libraries=LDIR
Myricom SNF library directory, if not DIR/lib
Do you think the same would work best for cross-compiling with bluetooth
support?
On a related note, since libpcap now uses both configure and cmake, the change
to the options should be made in a si
is someone looking at it?
Both the report and the CVE allocation are duplicate. The reporter decided to
jump ahead. The problem will be fixed.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
ted
> the "pickle" file from the mailman2 installation.
Thank you Michael.
--
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(
On Mon, 30 Jan 2023 21:30:50 +
Denis Ovsienko via tcpdump-workers
wrote:
> The changes to detect printf() issues (which now correctly fails the
> build on Solaris 9 instead of masking the post-build test failures)
> are now tcpdump draft pull request #1031. Please treat this as a
reasonable requirement for tcpdump 5.
--
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
and please remember to keep
the published specification up to date.
--
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slisti
respective logistics in Autoconf and CMake and would
make OS IPv6 support a nice-to-have, but not an essential dependency.
1:
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
--
Denis Ovsienko
___
tcpdump-workers
users
ever reads any documentation that comes directly with the software. It
would be better to have some other problems solved before looking at
this discrepancy again.
Specifically, I wonder if it would be practicable to process all
remaining longj
ielmiessler.com/study/tcpdump/.
> ...
> Thus, the problem already exists in reverse.
It has been this way for 32 years, so let's either fix this properly
with backward compatibility notes, or not at all. And in any case,
with a clear understanding which is the right thing.
--
Denis Ovs
nt also the
> calling function name with file name and line number. There may be a
> small shift in the line number.
>
> To use it:
> (There will be a doc entry based on this topic later.)
Thank you for putting this together. Does the FAQ look the best place
fo
sources to enable such support, please shout before long. Otherwise
notions of Tru64/Digital/OSF will be removed where they get in the way
of present day development and maintenance. The OS vendor finished
Tru64 support 10 years ago.
--
Deni
unused DSOs
helpdisplay this help message and exit
To direct the debugging output into a file instead of standard output
a filename can be specified using the LD_DEBUG_OUTPUT environment
variable.
--
Denis Ovsienko
___
tcpdump-workers mailin
tually will be gone too.
In tcpdump README.md now includes a more or less complete list of
retired OSes, please improve what you find in need of improvement.
--
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.o
icense in libpcap, tcpdump, and tcpslice.
I suppose this did not work. Let's put the
"3-clause-plus-one-unnumbered-clause LBL license" into a LICENSE file
then?
--
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lis
he patches and running
./configure, so there is a config.h with (or without) the various
HAVE_ macros.
The binary packages also include description of changes applied before
building, perhaps some of that could be up-streamed.
--
Denis Ovsienko
_
ponse as necessary, including the action from the pull request:
--sigusr2=rotate_savefile
1: https://github.com/the-tcpdump-group/tcpdump/pull/570
--
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To un
file --sigusr2=ignore" and then to use killall
remembering only the correct signal to use for the group, but not which
group comprises which PIDs.
This feature would only need to detect the set of user-configurable
signals at build time, to show the set and its default actions on
request, and
On Thu, 28 Mar 2024 15:28:00 -0700
Guy Harris wrote:
> On Mar 28, 2024, at 2:19 PM, Denis Ovsienko
> wrote:
>
> > Yes, AIX and Haiku sometimes make portability issues manifest.
>
> And, in this case, Solaris doesn't have SIGINFO, either; SunOS
> 0.x-4.x didn&#x
n actually works as
expected after it has been implemented?
9. What is the rollback plan, in case the solution did not work?
10. How is the proposed solution supposed to work long-term and
what is the impact on backward compatibility, if any?
Thank you.
--
Denis Ovsienko
_
he signed tarballs at their end, another could run "make releasetar"
at their end and let a script compare the contents and verify the
signatures.
This would be a bit of additional work, but security and confidence are
usually at the opposite ends of the same scale.
--
De
> This would be a bit of additional work, but security and confidence
> are usually at the opposite ends of the same scale.
s/confidence/convenience/
I knew what I meant, of course.
--
Denis Ovsienko
___
tcpdump-workers mailing list -- t
ivate(); those first appeared in libpcap 1.0, which was
> released in 2008, almost 16 years ago.
>
> Is there any reason not to require libpcap 1.0 or later? If there
> is, is there any reason not to require libpcap 0.7 or later?
Such use cases may exist, but I am not aware of any.
are going to
remain for historic purposes.
--
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
On Fri, 19 Apr 2024 11:18:47 -0700
Guy Harris wrote:
> On Apr 19, 2024, at 5:49 AM, Denis Ovsienko
> wrote:
>
> > On Fri, 12 Apr 2024 18:49:05 -0700
> > Guy Harris wrote:
>
> ...
>
> > Since tcpdump is the reference implementation of a program tha
ed changes in one complete commit).
* Add a change log entry and update the man page.
* Run ./build_matrix.sh and fix any warnings/errors (currently the
build fails with CMake with "libcryptopANT header not found",
obviously, not all build environmen
uot;host N.N.N" works exactly as "net N.N.N"
This way, to me it would make the most sense either to declare
inet_aton() IPv4 address format the nominal syntax (and to implement
that in the parser for N.N and N.N.N) or to declare N.N and N.N.N
invalid syntax and to return an appr
stead of using the
Makefile.
To simplify the use of "make install", would it be a reasonable
trade-off to install the additional binary only when the .devel file
exists?
--
Denis Ovsienko
___
tcpdump-workers mailing list --
c has been upgraded from
2024Q2 to 2024Q3, which among other things upgraded GCC from 13.3 to
14.2 and Clang from 17.0 to 18.1 on netbsd-aarch64.
Cheers.
1: https://www.digitalocean.com/open-source/credits-for-projects
--
Denis Ovsienko
___
tcpdump-worke
On Mon, 09 Sep 2024 15:13:49 -0400
Michael Richardson wrote:
> Denis Ovsienko wrote:
> > Let me suggest making tcpslice 1.8 release in 1-2 weeks to
> > avoid yet another oversized change log section. If anyone sees
> > a good reason not to, please make y
On Mon, 18 Nov 2024 12:30:22 -0800
Guy Harris wrote:
> On Nov 18, 2024, at 11:54 AM, Denis Ovsienko
> wrote:
>
> > The current approach in libpcap is such that an application at some
> > point tries to activate a device, and if the device does not support
> > captu
x in
case a filter uses the old-style VLAN keyword), but otherwise things
by default would work as before. Let's suppose the 1.11.x series
lasts a few years and provides a sufficient migration window even
after libpcap 2.0.0 has stabilised.
4. In the master branch the to-be-libpc
ement and user support,
* various minor fixes to code and documentation,
* preparing a few draft prototypes that yet remain to be completed,
* minor updates to the web site,
* manual testing on less common OSes as required, and
* sysadmin chores (mostly reconfigurations, upgrades and churn in the
vir
On Tue, 7 Jan 2025 16:38:30 +
Denis Ovsienko wrote:
> 4. The "enable/disable IPv6" build option, when non-standard IPv6
> stacks were commonplace and libpcap depended on these, had a purpose
> and managed the optional dependency. After quite some development in
>
kgsrc from 2024Q4 to 2025Q1 on
three NetBSD worker hosts), and
* various sysadmin chores (VM churn, OS and package updates).
--
--
Denis Ovsienko
___
tcpdump-workers mailing li
* developing code that is still work in progress or is waiting to be
merged,
* resolving/updating/opening a number of bug reports,
* various updates to the web site, and
* sysadmin chores (updates/reinstalls/troubleshooting).
nse in making the latter two options more granular and/or arranging
the source such that assigning a specific dissector to a specific group
would be a matter of one #define. But this may be over-engineering.
--
Denis Ovsienko
___
tcpdump-workers ma
cpdump-group/tcpdump/issues/810
--
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
d design quirks allowed)
* as much test coverage as is practicable
* no C code duplication without a good reason
* no BPF instruction duplication without a good reason
* what the C code looks is what it actually does, and vice versa
* no known discrepancies in pcap-filter(7)
Overall the parse
'text' => 'edsa.out',
},
'edsa-e' => {
'pcap' => 'edsa.pcap',
'text' => 'edsa-e.out',
'args' => '-e',
},
'isakmp4' =
--- Begin Message ---
On Wed, 29 Jan 2020 10:59:14 +0100
Francois-Xavier Le Bail wrote:
> On 28/01/2020 23:17, Denis Ovsienko via tcpdump-workers wrote:
> > The new dependency makes it more difficult to run tests and will
> > break package builds downstream (thus penalising pe
, and to say it in a LICENSE file for clarity?
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
ause of the error. AFAIK the cipher
name finally can be anything that OpenSSL recognises as such.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
two functions are
similar. Would it be the right thing to do?
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
" branch so it does not mislead
whoever is looking into this history next.
Cheers.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
two functions are
similar. Would it be the right thing to do?
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
" branch so it does not mislead
whoever is looking into this history next.
Cheers.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
them.
[...]
I have prepared changes that include headers from /usr/include/netinet
instead and am going to commit it tomorrow after proof-reading and
confirming it builds on different systems.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-worker
id grounds to stop within 24 hours, tcpslice 1.3 by
The Tcpdump Group will be out.
Thank you.
1: https://github.com/the-tcpdump-group/tcpslice/blob/master/CHANGES
2: https://github.com/the-tcpdump-group/tcpslice/issues/7
--
Denis Ovsienko
--- E
documentation), please remember to skip the CI build with [skip ci] as
described here:
https://docs.travis-ci.com/user/customizing-the-build/#skipping-a-build
The service is free for us to use, but it is not free for somebody else
to provide.
--
Denis Ovsienko
--- End Message
--- Begin Message ---
On Wed, 19 Aug 2020 00:51:11 +0100
Denis Ovsienko via tcpdump-workers
wrote:
[...]
> Also, the current Travis CI build matrix expands to 108 (!) jobs, so
> if you are making a trivial commit (such as in the man pages or the
> documentation), please remember to sk
of cnt.)
Would it make sense to move this paragraph to a BACKWARD COMPATIBILITY
section and to tell which specific version started to recognise 0 as a
valid value?
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump
--- Begin Message ---
> That's where other "some of what this manual page says doesn't apply
> to older versions of libpcap" items go, so it'd make sense.
Alright, that's done now, thanks!
--
Denis Ovsienko
--- End Message ---
___
t should probably define ND_MIN() and ND_MAX() instead.
Alright, that's done now.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
t, or to keep
it around for as long as it compiles?
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
)
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
0f0f 0f0f
> 0x0040: 0f0f 0016 88
I confirm the patch changes the hex output exactly as described.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
--- Begin Message ---
On Mon, 7 Sep 2020 17:26:28 +0200
Francois-Xavier Le Bail wrote:
> On 07/09/2020 16:43, Denis Ovsienko via tcpdump-workers wrote:
> > On Sat, 5 Sep 2020 18:20:42 +0200
> > Thank you for posting a detailed explanation and making the first
> > round of
b/the-tcpdump-group/tcpdump/jobs/724717360
2: https://travis-ci.org/github/the-tcpdump-group/tcpdump/jobs/721706654
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
--- Begin Message ---
On Thu, 27 Aug 2020 12:58:10 +0100
Denis Ovsienko via tcpdump-workers
wrote:
> Hello list.
>
> tcpslice master branch now installs the binary into bindir instead of
> sbindir, see [1]. Guy had suggested to make the same change in
> tcpdump.
[...]
The a
ng allows a human to make a mistake, mistakes
will happen, if not in one implementation then in another. So it would
make sense to look into this with attention if the goal is to produce a
good design.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-w
flag will work as the -xx flag below.)
or
-x ... (In this version of tcpdump this flag always works as the -xx
flag below.)
Would this help?
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
RUNCATED')
The master branch now has a change along these lines. Whilst preparing
changes to a couple decoders based on that (still work in progress), I
managed to make some observations, will post as soon as it all looks
good and makes sense.
t other reason requires a
different handling in pretty_print_packet(), then that would be a
straightforward way to do that, yes.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
/* for invalid cases (bad
> length, etc.) */
That could be another way of doing the same thing. In some programs that
could be the best or the only way to tell the reason for returning in a
thread-safe manner, but in this case struct netdissect_options makes it
really easy.
--
Denis Ovsie
ND_IS_TRUNCATED')
[...]
It could be simpler and more reliable to reset or to ignore
ndo->ndo_ll_hdr_len in pretty_print_packet() after "returning" from
setjmp for the second time (longjmp() can happen in many different
places, but there is only one
print */ }
[...]
The switch block should also have a default case, which ideally should
never happen, but if it somehow happens, it should either fail the
current packet safe or just call ndo_error().
--
Denis Ovsienko
--- End Message ---
--- Begin Message ---
On Thu, 17 Sep 2020 15:15:25 +0100
Denis Ovsienko via tcpdump-workers
wrote:
> On Sat, 5 Sep 2020 18:20:42 +0200
> Francois-Xavier Le Bail via tcpdump-workers
> wrote:
>
> > 2) Process all the truncated cases with:
> > ndo->ndo_ll_h
--- Begin Message ---
On Fri, 25 Sep 2020 03:04:21 +0100
Denis Ovsienko via tcpdump-workers
wrote:
[...]
> == Summary: the method seems to work well, there is a clean reference
> implementation, it should be easy to apply to other printers that
> implement similar encodings, the
u mean to introduce a function like pcap_error(), which the
developers would be able to interrogate if they need in use cases like
this? Then existing functions could be slowly updated as needed to store
the fault details somewhere for that function.
--
Denis Ovsienko
--- En
n details. Could you
figure out which keywords and which parameters this problem seems to
need and post that to the list first?
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
d "invalid", maybe something
else.
Only later I figured out out that the current edition of github.com
displays closed issues counter for a label in a separate place (cannot
remember if this is the same as how it used to be before). Please
excuse me for that, this damage was not intenti
> truncated the link layer header is printed.
The man page now explains this, albeit in a slightly different wording.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelm
erhaps it would be a
good time to review that.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Windows is pretty much dead, so people are unlikely to get
> confused and say "OK, how do I build this 16-bit?", the answer to
> which is "we don't even support that on UN*X...".
I never thought about it, now that you pointed it out the bit
w people need to coordinate now. That said, a
weekly/fortnightly status update on the list could be a useful addition.
Cheers.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
cmake is
too old, instead of failing the build outright?
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
|yes |no | 1741 | yes
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
ere's a control register bit to indicate whether to
> fault or allow unaligned accesses, and I haven't checked whether
> Linux enables them or not);
>
> s390x (a/k/a z/Architecture, i.e. S/3x0-64) - a big-endian
> platform, so we can do some testing of operation on
--- Begin Message ---
On Thu, 21 Jan 2021 08:15:33 +0100
Dagobert Michelsen wrote:
> Hi folks,
>
> Am 21.01.2021 um 04:24 schrieb Denis Ovsienko via tcpdump-workers
> :
> >>s390x (a/k/a z/Architecture, i.e. S/3x0-64) - a big-endian
> >> platform, so we can d
--- Begin Message ---
On Wed, 9 Sep 2020 17:07:25 +0100
Denis Ovsienko via tcpdump-workers
wrote:
> Here are my steps to reproduce:
>
> libpcap$ ./configure --enable-remote --prefix=/tmp/libpcap
> libpcap$ make
> libpcap$ make install
> tcpdumpbuild$ cmake
is imminent. If anybody
has useful input to make, please do not delay.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
amount.
I had requested a renewable OSS allowance on 29 January, got the
template response and confirmed the details. Let's see where it goes.
The account is at 3790/1 credits as of today, in other words, three
more builds of libpcap or at most one tcpdump build, if/when the latter
migra
ocess. That said, if you have suggestions in addition or
instead of that, please make them on the list to be considered.
Thanks.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
--- Begin Message ---
On Fri, 12 Feb 2021 16:18:10 +
Denis Ovsienko via tcpdump-workers
wrote:
[...]
> The Travis CI subscription will cease in early March (unless there is
> a sponsor willing to pay 82.80 USD per month). At this time the
> impact of that would be the following:
>
--- Begin Message ---
On Thu, 4 Mar 2021 00:42:23 -0800
Guy Harris wrote:
> On Mar 3, 2021, at 2:30 PM, Denis Ovsienko via tcpdump-workers
> wrote:
>
> > A partial replacement for that service is ci.tcpdump.org, which is a
> > buildbot instance doing Linux AArch64 buil
t any of the following buildbot workers
long-term?
* linux-aarch64 (currently on a RPI4B running in 64-bit mode)
* linux-armv7l (currently on a RPI4B running in 32-bit mode)
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcp
can do it yourself.
Let me know which ARM workers look feasible to you. If you can host
PowerPC workers instead or in addition to that, it would help too.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-work
--- Begin Message ---
On Mon, 22 Mar 2021 19:00:31 +0100
Harald Welte wrote:
> Dear Denis,
>
> On Sun, Mar 21, 2021 at 11:08:44PM +0000, Denis Ovsienko via
> tcpdump-workers wrote:
> > Thank you for the offer. For the operating systems specifics please
> > see belo
--- Begin Message ---
On Wed, 24 Mar 2021 00:52:00 +0100
Harald Welte wrote:
> Hi Denis,
>
> On Tue, Mar 23, 2021 at 12:35:06AM +0000, Denis Ovsienko via
> tcpdump-workers wrote:
> > That's great, three worker types are ready to go anytime soon, just
> > decide
issues should manifest. It would be great if someone
could look into these issues, identify the reasons for failure and tell
what can be fixed easily.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers
--- Begin Message ---
On Mon, 5 Apr 2021 10:42:39 +0100
Denis Ovsienko via tcpdump-workers
wrote:
> Hello list.
>
> I hope you have a great day. Please find below a brief overview of
> some current continuous integration matters.
Please find below a few recent developments si
101 - 200 of 285 matches
Mail list logo
