tests: replace the LDAP OSS-Fuzz testcase

[evverx]

The original testcase triggers a separate issue on 32-bit machines: #4527 and it should probably be tested separately. The new testcase triggers the issue fixed in 1935723 only:

>>> assert l[0][LDAP].summary() == "LDAP"
Traceback (most recent call last):
  File "<input>", line 2, in <module>
  File "scapy/scapy/packet.py", line 1692, in summary
    return self._do_summary()[1]
           ^^^^^^^^^^^^^^^^^^
  File "scapy/scapy/packet.py", line 1669, in _do_summary
    ret = self.mysummary()
          ^^^^^^^^^^^^^^^^
  File "scapy/scapy/layers/ldap.py", line 736, in mysummary
    self.messageID.val,
    ^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'val'

It was tested in https://download.copr.fedorainfracloud.org/results/packit/evverx-scapy-2/fedora-40-i386/07994883-scapy/builder-live.log.gz

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.58%. Comparing base (867f92a) to head (1f2ce61).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4530      +/-   ##
==========================================
+ Coverage   80.66%   81.58%   +0.92%     
==========================================
  Files         356      356              
  Lines       85278    85278              
==========================================
+ Hits        68787    69577     +790     
+ Misses      16491    15701     -790     

see 24 files with indirect coverage changes

[evverx]

(Also I was going to switch manual_trigger to false to run the tests on all those platforms on PRs automatically but then I remembered that it was discussed in #4355 (comment) and it was decided not to do it at the time. Personally I think it should be OK to run the tests automatically because it's hard to tell how PRs can affect those architectures/packages. If the concern is that it consumes the resources I can ask the Packit folks if it's OK by analogy with, say, packit/packit#2371 (reply in thread). scapy is used extensively to test and find all sorts of issues in systemd-resolved, systemd-networkd, avahi, NetworkManager and things like that so I'm sure it should be convincing enough in terms of why testing scapy is a good idea. Though I don't think it should come up because it doesn't consume a lot resources anyway. I'd personally go as far as to run it all on commits as well to produce packages that folks that can't pull stuff from PyPi for whatever reason can use to test the master branch on RPM-based systems)

[guedou]

@evverx If that's OK for the packit folks, we could test Scapy on other architectures too. That will be super cool.

[gpotter2]

@guedou To clarify, and as pointed out by evverx, we can already do that on all platforms that packit support. (via /packit build)

However my point was that packit is designed to help fedora have a more streamlined upstream/downstream integration, not to be a freely available CI. If I understand it well, we're already kinda "abusing" the way it works to use it as a CI (evverx#1 (comment)). I didn't want to have it triggered on each commit because I felt that would be an abuse, so we currently only trigger it manually once in a while.

I'm not against it, but out of respect that's probably something we should ask permission for.

[gpotter2]

Thanks for the PR anyways!

[evverx]

we're already kinda "abusing" the way it works to use it as a CI

systemd, avahi, dbus-broker and some other projects do that too to run their tests on big-endian and 32-bit machines. systemd doesn't trigger Packit on commits though (because there are already a lot of PRs and force-pushes there triggering a lot of Packit jobs testing a gazillion different components).

packit is designed to help fedora have a more streamlined upstream/downstream integration, not to be a freely available CI

Fedora ships scapy (https://src.fedoraproject.org/rpms/scapy) and all the tests running upstream on Fedora machines help to catch things as soon as possible. From a Fedora perspective It's much better than waiting for releases and then trying to figure out why packages fail to build.

I'm not against it, but out of respect that's probably something we should ask permission for.

Got it. I'll talk to the Packit folks and open a PR once it's confirmed that it's OK to run it on PRs.

[evverx]

I opened packit/packit#2407