I get this... tries twice to get i/f list.

$ wireshark &
[1] 2518
$ QMetaObject::connectSlotsByName: No matching signal for on_bStart_clicked()
QMetaObject::connectSlotsByName: No matching signal for on_bStop_clicked()
FIX: packet list heading menu sensitivity
19:27:18.003  Dbg  plugin_dir: /usr/lib64/wireshark
19:27:18.004 Main Dbg  Translator en_US
19:27:18.004  Dbg  FIX: timestamp types should be set elsewhere
19:27:18.004 Main Info fill_in_local_interfaces() starts
19:27:18.004 Capture Msg  Capture Interface List ...
19:27:18.004 Capture Dbg  sync_interface_list_open
19:27:18.004 Capture Dbg  sync_pipe_open_command
19:27:18.006 Capture Dbg  read 12 ok indicator: E len: 75 msg: E
19:27:18.006 Capture Dbg  sync_pipe_wait_for_child: wait till child closed
19:27:18.007 Capture Dbg  sync_pipe_wait_for_child: capture child closed after 0.001s
19:27:18.007 Capture Msg  Capture Interface List failed!    <=========
19:27:18.007 Main Info fill_in_local_interfaces() ends, taking 0.003s
19:27:18.007  Dbg  FIX: fetch recent color settings
19:27:18.007 Capture Msg  Capture Interface List ...
19:27:18.007 Capture Dbg  sync_interface_list_open
19:27:18.007 Capture Dbg  sync_pipe_open_command
19:27:18.009 Capture Dbg  read 12 ok indicator: E len: 75 msg: E
19:27:18.009 Capture Dbg  sync_pipe_wait_for_child: wait till child closed
19:27:18.010 Capture Dbg  sync_pipe_wait_for_child: capture child closed after 0.001s
19:27:18.010 Capture Msg  Capture Interface List failed!    <=========
19:27:18.011 Main Info Wireshark is up and ready to go

There aren't major UI changes, other than the initial screen.  The menu is the same, all the same functionality is there, and once you get into the packet analysis screen, the UI is exactly the same as before.  The reason the initial screen looks different is because in 1.12.x, they hadn't yet made the initial screen of the Qt interface exactly the same as the Gtk+ one.  Upstream has switched to Qt because the Gtk+ developers couldn't maintain something that's consistently usable for third-party (non-GNOME) developers and kept breaking things.  In the upcoming Wireshark 2.0, they have done a lot of additional work on the Qt interface, and I wouldn't be surprised if the initial screen will look more like what you're used to.  When 2.0 is available, I am planning to update Mageia 5 to it for this reason.

As for doing captures, it should be the same in Mageia 5 as in previous versions.  If you add your regular user to the wireshark group (and log out and back in), I think that's all that was needed.

Status: NEW => UNCONFIRMED
Ever confirmed: 1 => 0

Ok...  got it to run as a regular user.

BUT...  the feature I use the most, clicking on columns to sort, is completely broken.  Well, not quite... it does display up/down triangles indicating asc/descending sorts; but doesn't do the sorts.

OK, I can look into confirming the sorting issue when I get to work, but that should be reported upstream.  They have a bugzilla.

Confirmed the column sorting not working.

Their bugzilla is at https://bugs.wireshark.org/

Status: UNCONFIRMED => NEW
Summary: wireshark regressions in 1.12.6 => wireshark sorting columns in packet analysis view non-functional
Ever confirmed: 0 => 1

(In reply to David Walser from comment #2)
> There aren't major UI changes, other than the initial screen.  The menu is
> the same, all the same functionality is there,

No, it's not.  There's a *LOT* of functionality in the GTK+ version of 1.12.x that's not in the Qt version of 1.12.x; even in the current development version, there's currently stuff missing, as per the current version of

    https://wiki.wireshark.org/Development/QtShark

> Upstream has switched to Qt because the Gtk+ developers couldn't
> maintain something that's consistently usable for third-party (non-GNOME)
> developers

A lot of that is "non-GNOME and not-{X11,Wayland,Mir}-based", i.e. GTK+ on OS X and Windows was lagging behind.

> In the upcoming Wireshark 2.0, they
> have done a lot of additional work on the Qt interface,

As in "it's a lot closer to being feature complete", but, as of now, it's *still* not feature complete.

> and I wouldn't be
> surprised if the initial screen will look more like what you're used to.

If "what you're used to" is the current Qt version, that's true.  If it's the GTK+ version, I *would* be surprised if the final Wireshark 2.0 Qt version looked more like the current GTK+ version than current Qt versions do.

I would strongly suggest that *NO* distribution go with the Qt version of 1.12.x, and that *ANY* distribution that has done so reconsider that and go back to the GTK+ version.  We're unlikely to devote significant effort to fixing Qt issues with anything other than the development version; in particular, I don't plan to spend any time worrying about columns not sorting in the Qt 1.12.x, as they *do* sort in the Qt trunk, and I doubt anybody else will, either, as they're focused on getting the trunk version feature complete and fixing bugs found there.

(Note that we're still shipping the GTK+ X11-based version of 1.12.x for OS X, with all its problems, because shipping a Qt-based version of 1.12.x would remove a *lot* of functionality.)

CC: (none) => guy

I most certainly will not be switching back to Gtk+3, given all the problems that trying to build with that presented.  It's clear now that we will need to upgrade to Wireshark 2.0 when it's available.

There's always GTK+ 2.

(In reply to Guy Harris from comment #8)
> There's always GTK+ 2.

That would be better than GTK+3, for sure.  I'd rather not move backwards though.  It's just a shame that we're caught in a transitional state with 1.12.  I don't blame the Wireshark developers for that though.

Do you have any insights on when 2.0 might be released?

(In reply to David Walser from comment #9)
> Do you have any insights on when 2.0 might be released?

Not before it's sufficiently feature-complete.  I don't know when that will be.

(In reply to David Walser from comment #9)
> (In reply to Guy Harris from comment #8)
> > There's always GTK+ 2.
> 
> That would be better than GTK+3, for sure.  I'd rather not move backwards
> though.

"Move backwards" from GTK+ 3 to GTK+ 2?  So some earlier version of Wireshark *didn't* cause problems when built with GTK+ 3?

(In reply to Guy Harris from comment #11)
> "Move backwards" from GTK+ 3 to GTK+ 2?  So some earlier version of
> Wireshark *didn't* cause problems when built with GTK+ 3?

Sorry I wasn't more clear.  I just meant backwards from Qt to Gtk+.  Gtk+3 was always problematic once we had switched to it.

I think the developer suggests we switch back to Gtk+2 for the time being, until the Qt version is feature-complete. I have no strong opinion about it, but if it's what upstream recommends, maybe we should switch to it, although I can understand that you don't like to do such a change for a stable version of the distribution.

Yeah, it's just a shame that we got caught in a transitional phase.  I need a correctly functioning Wireshark for my students at work, so I started work on some different things with this last night and I'll keep working on it to try and find a good solution.

(In reply to Samuel VERSCHELDE from comment #13)
> I think the developer suggests we switch back to Gtk+2 for the time being,

I strongly suggest that you switch back to some version of GTK+ for Wireshark 1.12, and don't use Qt until 2.0 is released.

I note that Debian's current Wireshark 1.12 package uses GTK+ 3:

    https://packages.debian.org/stable/wireshark

("libgtk-3-0 (>= 3.7.10)" is one of the dependencies).

(In reply to David Walser from comment #12)
> Sorry I wasn't more clear.  I just meant backwards from Qt to Gtk+.

Given the amount of functionality missing from the Qt version in 1.12.x, going from GTK+ to Qt was a move backwards for at least some members of your user base.

I've upgraded Cauldron to 1.99.7 (column sorting works there).

For Mageia 5, I've pushed a build to updates_testing that adds a wireshark-gtk package that contains the GTK+3 interface.  I don't expect to have the same problems building it as we did in Cauldron where it broke every time Gtk+3 was updated, since it should be getting updated.  If you install wireshark-gtk, you should see a Wireshark-GTK menu entry (in KDE it's in Tools->Other, I guess it'd just be in Tools in GNOME).

Pierre, please let me know how that works for you.

Guy, thanks for your feedback.  It's always nice to hear from upstream developers :o)

Created attachment 6863 [details]
console output

I don't see any difference...  still no sorting...  am I missing something?  See my console output...

Argh...  I get the Qt version when starting from command line.  Just tried Tools->More (not Other :) and I get the GTK version; but I now have to logout first which will take some time because of all the stuff I have running...
[Sigh...  tried to test on a 2nd X session; but that's broke too (bug 16470)]
Should be able to test sometime today...

Fixed the /usr/bin/wireshark symlink to point to gtk version.
All looks good again...
Thanks David!

You don't *need* to change the symlink, as you can just run it as wireshark-gtk, although you're welcome to change it if you want to.  If this was a permanent solution, we could use alternatives for it, but I don't want to overcomplicate things with that for a temporary solution.  Yes, I did mean More instead of Other in the menu, sorry about that :o)

Pierre, am I correct that you tested on x86_64?

Florian, you said on IRC that you had an issue with capturing using filters.  Can you expand on that?

CC: (none) => doktor5000

Florian, I'm curious about your filter issue too.

David, I prefer to change the symlink (or delete it) to avoid confusion since I've used "wireshark &" ever since it changed from ethereal...  :)
Yes, on x86_64...  Do you want me to test on i586 too?  I have an old ThinkPad that's still on mga2 I think...  though I don't know when I could find the time to upgrade it -- I want to since it's in my shop and saves me having to come back to the house to access info.

Pierre, any testing you can do is welcome, but I tested it on i586, so I just wanted to make sure for the purposes of validating it as an update.  We've actually covered it enough to validate it, but I'd like to hear more about Florian's issue before pushing this as an update.

(In reply to David Walser from comment #21)
> Florian, you said on IRC that you had an issue with capturing using filters.
> Can you expand on that?

I didn't use it myself since a long time, tcpdump is sufficient for me ;)
Asked on behalf of a forums user to get some feedback for https://forums.mageia.org/en/viewtopic.php?f=7&t=10055

(In reply to Florian Hubold from comment #24)
> (In reply to David Walser from comment #21)
> > Florian, you said on IRC that you had an issue with capturing using filters.
> > Can you expand on that?
> 
> I didn't use it myself since a long time, tcpdump is sufficient for me ;)
> Asked on behalf of a forums user to get some feedback for
> https://forums.mageia.org/en/viewtopic.php?f=7&t=10055

Management of capture filters is one of the functions not yet implemented in the Qt code as of when the 1.12 branch was created.

OK, so this update should solve the capture filters problem as long as they install wireshark-gtk.

Our students use tcpdump for capture too :o)

It sounds like this one is good to go.

Advisory:
-----------------------

This update adds the Wireshark GTK+3 interface in a wireshark-gtk subpackage,
as an alternative to the default Qt5 GUI, which is feature-incomplete in the
Wireshark 1.12 branch.  This is a temporary measure until it reaches feature
completion in Wireshark 2.0.

Source RPM:
wireshark-1.12.6-2.mga5.src.rpm

Hardware: x86_64 => All
Assignee: bugsquad => qa-bugs
Whiteboard: (none) => MGA5-32-OK MGA5-64-OK

Advisory uploaded, validating.

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

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

http://advisories.mageia.org/MGAA-2015-0076.html

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