Testing procedure:
https://wiki.mageia.org/en/QA_procedure:Wireshark

Whiteboard: (none) => has_procedure
Depends on: (none) => 21314

MGA5-32 on Asus A6000VM Xfce
No installation issues.
Trying to run from testprocedure, but something I do not get.
Refer to my previous testing on bug 19535 Comment 8, I quote:
"wireshark -n wiresharktest : creates wiresharktest file with data"
Now the file wiresharktest exist but is empty before the test, and still is after. Testdata saved in wiresharktest.pcapng as per defaults in wireshark after selecting the wifi interface in the capture options.

Similar with second test : now "tshark -nr wiresharktest" just does not return anything, not on the CLI, not in the file.
Subsequent test using the wiresharktest.pcapng file are OK
$ editcap -r wiresharktest.pcapng wiresharktest50 1-50
file created OK
$ mergecap -v -w wiresharkmerged wiresharktest.pcapng wiresharktest50 
mergecap: wiresharktest.pcapng is type Wireshark/... - pcapng.
mergecap: wiresharktest50 is type Wireshark/... - pcapng.
mergecap: selected frame_type Ethernet (ether)
mergecap: ready to merge records
Record: 1
Record: 2
Record: 3
Record: 4
Record: 5
Record: 6
Record: 7
Record: 8
Record: 9
Record: 10
Record: 11
Record: 12
Record: 13
Record: 14
Record: 15
Record: 16
mergecap: merging complete
]$ capinfos wiresharktest50
File name:           wiresharktest50
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  nanoseconds (9)
Packet size limit:   file hdr: (not set)
Number of packets:   8
and some more ......

I asked already in bug 20170 Comment 3 about this wiresharktest file in the QA wiki, but ???????

As I cannot find anything real at fault OK for me.

Whiteboard: has_procedure => has_procedure MGA5-32-OK
CC: (none) => herman.viaene

Testing Mageia 5 64-bit

From the Tshark references in Comment 0, there are a number of sample .pcap files:
 clusterfuzz-testcase-minimized-4504163348119552.pcap
 clusterfuzz-testcase-minimized-5984186735263744.pcap
 clusterfuzz-testcase-minimized-6037307087912960.pcap
 fuzz-2017-04-15-11942.pcap
 fuzz-2017-06-11-30708.pcap ****
 fuzz-2017-06-12-15905.pcap
 udp_busyloop_with_memory_usage.pcap

I ran
 $ tshark -nr <filename> >> <before|after>
for each example before & after the updates to:
 lib64wsutil6-2.0.14-1.mga5
 rawshark-2.0.14-1.mga5
 dumpcap-2.0.14-1.mga5
 lib64wiretap5-2.0.14-1.mga5
 wireshark-tools-2.0.14-1.mga5
 tshark-2.0.14-1.mga5
 lib64wireshark7-2.0.14-1.mga5
 wireshark-2.0.14-1.mga5
Which proved almost nothing! All results were identical except for 30708 which showed 4 different lines in different places. No 'visible' looping anywhere.

So I ran the prescribed series of commands from the procedure. To get a start file, I just used Wireshark to start (then stop) capturing some generated traffic. It picked the Ethernet interface, and created a capture file in /tmp/ whose name & details are given in Statistics-Capture file properties. I changed it to 'wireshark'.

 $ tshark -nr wiresharktest
dumps it to the console.

 $ editcap -r wireshark wireshark50 1-50
creates a subset file, *no console O/P* (as shown in the procedure).
 $ ls -l
 -rw-r--r-- 1 lewis lewis    7792 Gor  24 22:58 wireshark50

 $ mergecap -v -w wsmerged wireshark wireshark50
produced a lot of Record: xxx lines, ending "mergecap: merging complete".
 $ ls -l
 -rw------- 1 lewis lewis  307672 Gor  24 22:42 wireshark
 -rw-r--r-- 1 lewis lewis    7792 Gor  24 22:58 wireshark50
 -rw-r--r-- 1 lewis lewis  315252 Gor  24 22:59 wsmerged
Result viewable with Wireshark.

 $ randpkt -b 500 -t dns wireshark_dns.pcap
No console O/P, but creates the file:
 $ ls -l
 -rw-r--r-- 1 lewis lewis  292801 Gor  24 22:50 wireshark_dns.pcap
of 1000 records viewable with Wireshark, many failures therein, unsure of their significance.

 $ dftest ip
 Filter: "ip"
 Constants:
 Instructions:
 00000 CHECK_EXISTS	ip
 00001 RETURN
similar (not identical) to the example.

 $ capinfos wiresharkt50
File name:           wireshark50
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  nanoseconds (9)
Packet size limit:   file hdr: (not set)
Number of packets:   50
File size:           7792 bytes
Data size:           5984 bytes
...
Capture application: Editcap 2.0.14
Number of interfaces in file: 1
Interface #0 info:
                     Name = enp4s0
...
All looks sensible. See no reason not to OK the update; & validate it.
Advisory to follow.

Whiteboard: has_procedure MGA5-32-OK => has_procedure MGA5-32-OK MGA5-64-OK
Keywords: (none) => validated_update
CC: (none) => lewyssmith, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2017-0219.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

So I guess the updates pushing script doesn't check for blockers anymore...