Synaptic is reading state information for a minute or so

Of course the bug is only present when using gnome session (gnome-shell).
I have also tested this by fully installing Gnome-Staging PPA, and the bug is present there too.
This bug is possibly related to the bug #1322834.

Status changed to 'Confirmed' because the bug affects multiple users.

Further info on this bug:

Like I mentioned I can reproduce this bug with the Gnome3 Staging PPA fully installed (Utopic).
As this bug is very present also with only official Utopic repos used, the following is true.

This is definitely an issue with the latest synaptic and gnome-shell + mutter 3.12.
It can be verified with gnome-desktop 3.8 / 3.10 / 3.12, so it seems the desktop is not the problem.

While the bug is present and synaptic keeps reading the state information, it seems it takes increased power from processors.
After the synaptic is completely started, it is much slower and sluggish tha normal.
If closed or stopped (killall synaptic) and restarted, it begins the long state reading again.

However, this bug is not present with each and every boot.
And when not present, synaptic can be started and closed repeatedly with no issues.

Harry,
  can you try running synaptic through perf, and see if you can find what is blocking the startup? you will need to install debug symbols to get a useful profile

This bug is very present even if proposed repos are not enabled and only official Utopic repos used.
Also, if Trusty + Gnome Staging PPA (trusty branch) is used, the bug is present there too.

Tim,
I haven't done debugging, so that is not familiar to me.

Feedback from utopic i386 booted with systemd and logged as gnome-shell 3.12

- looks like an apt issue: switching from small packages list tabs in synaptic (installed or upgradable or new) is 'normal' but 'all' is freezing ~ 60s, same if switching from 'status' 'custom' or 'origin' in the bottom left pane.
- so when there is too much packages to handle, we get a minute freeze

so its related to built/use index as i see it: maybe libapt-pkg4.12
but there is no warning/error logged or from a terminal

note: also need some guidance to perform a debugging before sending something usefull.

Looks like related to lp:1274466

I can confirm that very likely the bug is related to reading index information.
I usually use "status" from the bottom left pane.
At startup, synaptic seems to spend a minute or so reading the information (all packages).
When a limited number of packages is chosen from the left pane (installed or local), the application is faster, but not normal.

Like I said, synaptic startup and functioning is normal on some boot-ups (perhaps 10-20 % of all).
At that time, closing the application is also normal.
But, when the bug is "on", the application will also hang a while at closure.
So there is some kind of freezing too.

Here is what i've found into /var/log/apt/term.log:

(Reading database ... 234000 files and directories currently installed.)

wow now i understand why it takes a so long time for loading into synaptic main lists.
It cant be true: synaptic says 46000 total files listed, and around 2200 installed.
So that database seems corrupted.
Doing some cleaning again (i run bleachbit once a week):

sudo rm /var/lib/apt/lists/* -vf

and then update: still that unreal huge files list of 235000 that time. And sysnaptic still so long to resume.

Added apt bug lp:1329760

It may very well be this bug is not about possible issues with apt (apt-ftcarchive).

I point out again that this bug is not present when using gnome-shell and mutter versions 3.10 or even lower.
It can be experienced only using gnome-shell 3.12 or newer.

Another thing to remember is that apt itself works just fine from terminal and at the same session when synaptic is frozen.
Commands like apt-get update and apt-get upgrade are working all the time.

So an upstream fix is pushed to master and gnome-3-12 branch.
I hope this is released in Ubuntu Utopic soon.

As per the latest comments from the upstream bug, its mainly about a atspi issue here.

This bug was fixed in the package gnome-shell - 3.12.2-1ubuntu3

---------------
gnome-shell (3.12.2-1ubuntu3) utopic; urgency=medium

  * debian/patches/git_a11y_init_on_demand.patch: git patch to fix
    slow loading of gtkTreeViews (LP: #1328586)
 -- Tim Lunn <email address hidden> Sat, 21 Jun 2014 09:43:58 +1000

Right, this seems to be fixed now for synaptic as well.

It is only half fixed, users of the shell's magnifier will see the exact same problem when starting synaptic.

Will review and upload the proposed branch now if its ok.

This bug was fixed in the package at-spi2-atk - 2.12.1-1ubuntu2

---------------
at-spi2-atk (2.12.1-1ubuntu2) utopic; urgency=medium

  * Add git-c8cda37e28307ad195996ad54b9ee1680cca3ec3.patch. LP: #1328586
 -- Jackson Doak <email address hidden> Mon, 13 Oct 2014 18:47:05 +1100