There are three ways to reuse configuration blobs in .gitlab-ci.yml: The
"extends" keyword, YAML anchors, and "!reference" tags. As noted in
https://gitlab.com/gitlab-org/gitlab/-/issues/322992, only the last
method works for job rules. Clean up our common rules and apply them
using "!reference".
In the MP_REACH_NLRI attribute, break out the Next Hop field into
constituent subfields for different address types. Add a field name
for the NLRI to make it filterable and consistent with the standard
NLRI attribute. Also add a field name for the withdrawn routes for
the MP_UNREACH_NLRI attribute.
Correct a comment about RFC 2545 and the handling of what it allows,
viz. IPv6 next hop addresses being optionally followed by link-local
next hop addresses.
The above has nothing to do with RFC 2283 allowing multiple <afi, safi,
..., NLRI> tuples (which was impossible to implement, and RFC 2858
later explicitly disallowed), so correct the comment about that.
It looks like "extends" and YAML anchors don't work for scheduling
rules, at least for the way we're using them. Use explicit rules for
scheduled jobs.
Move commonly-used rules to their own hidden jobs. Use ".if-merged" to
ensure that our production build and test jobs are run automatically in
wireshark/wireshark and can be run manually in forks.
Note the new manual behavior in the Developer's Guide.
Trying to upload cov-build output on Windows is currently failing
because the file is too large. Expose the build file as an artifact and
submit its URL instead.
Switch the recent analysis builds from only/when to rules.
Switch the API reference and VS Code Analysis builds to daily.
Remove a no-longer-useful URL.
Most of the time, the return value tells us nothing useful, as we've
already decided that we're perfectly willing to live with string
truncation. Hopefully this keeps Coverity from whining that those
routines could return an error code (NARRATOR: They don't) and thus that
we're ignoring the possibility of failure (as indicated, we've already
decided that we can live with string truncation, so truncation is *NOT*
a failure).
Fixed crash when dissecting Type Object larger than 100 elements. Added
protocol option for setting up the maxumun number of Type Object elements to show.
To save space, the value of Partial TSF is stored shifted to the right
by 10. When displaying to the user, shift it back to the left by 10 and
display as microseconds.
The secs field is a time_t, which is not necessarily 32 bits. If it's
not, casting away the upper bits, by casting to guint32, introduces a
Y2.038K bug.
Either cast to time_t or, if you're assigning a time_t to it, don't
bother with the cast.
Fields such as '_ws.expert' have no underlying tvb; they are added
with offset 0 and length 0 and the field's underlying tvb is NULL. FieldInfo__call
passes tvb to tvb_memdup() without checking if the tvb is null and
assumes that a NULL tvb means that the tvb is expired and therefore raises an error:
"epan/tvbuff.c:477: failed assertion "tvb && tvb->initialized"
Fields such as '_ws.expert.group' have no underlying tvb; they are added
with offset 0 and length 0 and the field's underlying tvb is NULL. FieldInfo_get_range
calls push_TvbRange, which assumes that a NULL tvb means that the tvb is expired
and therefore raises a lua error of "expired tvb".
This commit explicitly adds a check to FieldInfo__call() to see if the tvb is null when
attempting to access the underlying tvb.
It also explicitly checks if the tvb is null when attempting to access the range
and if it is, returns nil. This is consistent with how FieldInfo.source also
returns nil for such fields.
This commit should fix issue #13542.
The test:rpm-fedora job is currently failing with:
$ dnf install -y build/packaging/rpm/RPMS/x86_64/*.rpm
Fedora 34 openh264 (From Cisco) - x86_64 6.4 kB/s | 2.5 kB 00:00
Fedora Modular 34 - x86_64 8.4 MB/s | 3.8 MB 00:00
Fedora Modular 34 - x86_64 - Updates 500 kB/s | 754 kB 00:01
Fedora 34 - x86_64 - Updates 11 MB/s | 5.8 MB 00:00
Fedora 34 - x86_64 21 MB/s | 57 MB 00:02
Error:
Problem: conflicting requests
- nothing provides libminizip.so.2.5()(64bit) needed by wireshark-qt-3.5.0rc0_1661_ge2e4b79d0dd3-1.x86_64
It looks like this is due to Fedora 34 and later shipping with
minizip-3.0: https://src.fedoraproject.org/rpms/minizip.
Disable the test:rpm-fedora job for now until we can find a way to make
it more reliable.
Guy Harris
Vadim Yanitskiy