Project

General

Profile

Bug #9095

Bug #8059: Windows Camouflage automated tests sometimes failed due to differently ordered icons in the notification area

Seahorse tests lack robustness

Added by intrigeri almost 5 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Test suite
Target version:
Start date:
05/05/2015
Due date:
% Done:

100%

Feature Branch:
kytv/test/9095-robust-seahorse
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

In a few runs, I've seen:

  Scenario: Fetching OpenPGP keys using Seahorse via the Tails OpenPGP Applet should work and be done over Tor. # features/torified_gnupg.feature:30
    When I fetch the "10CC5BC7" OpenPGP key using Seahorse via the Tails OpenPGP Applet                         # features/step_definitions/torified_gnupg.rb:97
      FindFailed: can not find SeahorseFindKeysWindow.png on the screen.
  Scenario: Syncing OpenPGP keys using Seahorse started from the Tails OpenPGP Applet should work and be done over Tor. # features/torified_gnupg.feature:45
    Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures                                 # features/step_definitions/torified_gnupg.rb:26
    And the GnuPG fetch is successful                                                                                   # features/step_definitions/torified_gnupg.rb:38
    And the "10CC5BC7" key is in the live user's public keyring after at most 120 seconds                               # features/step_definitions/torified_gnupg.rb:50
    But the key "10CC5BC7" has only 2 signatures                                                                        # features/step_definitions/torified_gnupg.rb:7
    When I start Seahorse via the Tails OpenPGP Applet                                                                  # features/step_definitions/torified_gnupg.rb:57
    Then Seahorse has opened                                                                                            # features/step_definitions/torified_gnupg.rb:67
    And I enable key synchronization in Seahorse                                                                        # features/step_definitions/torified_gnupg.rb:72
    And I synchronize keys in Seahorse                                                                                  # features/step_definitions/torified_gnupg.rb:84
      FindFailed: can not find SeahorseWindow.png on the screen.
  Scenario: Syncing OpenPGP keys using Seahorse should work and be done over Tor.         # features/torified_gnupg.feature:34
    Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures   # features/step_definitions/torified_gnupg.rb:26
    And the GnuPG fetch is successful                                                     # features/step_definitions/torified_gnupg.rb:38
    And the "10CC5BC7" key is in the live user's public keyring after at most 120 seconds # features/step_definitions/torified_gnupg.rb:50
    But the key "10CC5BC7" has only 2 signatures                                          # features/step_definitions/torified_gnupg.rb:7
    When I start Seahorse                                                                 # features/step_definitions/torified_gnupg.rb:57
    Then Seahorse has opened                                                              # features/step_definitions/torified_gnupg.rb:67
    And I enable key synchronization in Seahorse                                          # features/step_definitions/torified_gnupg.rb:72
    And I synchronize keys in Seahorse                                                    # features/step_definitions/torified_gnupg.rb:84
      FindFailed: can not find SeahorseWindow.png on the screen.

seahorse.png View (34.6 KB) kytv, 04/12/2015 10:57 PM


Subtasks

Bug #9343: Make seahorse tests more robust by using less keyboard shortcutsResolved

Bug #9344: Sometimes Seahorse's Find keys dialog cannot be found during testsResolved

Bug #9345: Consider switching OpenPGP key serverResolved

Bug #9346: Test if switching to a more stable OpenPGP key server improves the Seahorse testsResolved

Bug #9347: Investigate if Seahorse has hardcoded timeouts causing transient network issuesRejected


Related issues

Related to Tails - Bug #10500: Monitor failure modes of Seahorse Rejected 11/06/2015
Related to Tails - Bug #9970: Seahorse may segfault during key synchronization Rejected 08/11/2015
Blocked by Tails - Bug #9233: Seahorse's configured keyservers are not the same as those in gpg.conf Resolved 04/14/2015
Blocked by Tails - Bug #9258: Accessing systray icons in the test suite is fragile Resolved 04/18/2015

Associated revisions

Revision 9f0692b7
Added by intrigeri about 4 years ago

Merge remote-tracking branch 'kytv/test/9095-robust-seahorse' into stable

Fix-committed: #9095, #10501

History

#2 Updated by intrigeri almost 5 years ago

I've also seen I enable key synchronization in Seahorse fail with FindFailed: can not find SeahorsePreferences.png on the screen. This code feels indeed racy:

  @screen.type("e", Sikuli::KeyModifier.ALT) # Menu: "Edit" ->
  @screen.type("n") # Menu: "Preferences " ->
  @screen.wait("SeahorsePreferences.png", 10)

... because we don't wait for the effects of the first call to type, before going further.

#3 Updated by kytv almost 5 years ago

When seahorse fails to fetch a key the result can be the following:

I'm not sure how this should be addressed. Maybe clicking on the original window will unlock the second one, so perhaps the FindFailed could be rescued to workaround this Seahorse bug which I think is caused by transient network problems, similiar to

Scenario: Fetching OpenPGP keys using GnuPG should work and be done over Tor.           # features/torified_gnupg.feature:20
    When I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI                           # features/step_definitions/torified_gnupg.rb:26
      Command failed: gpg --batch  --recv-key '10CC5BC7'
      error code: 2
      stderr: gpg: requesting key 0x10CC5BC7 from hkps server hkps.pool.sks-keyservers.net
      gpg: no valid OpenPGP data found.
      gpg: Total number processed: 0
      .
      <false> is not true. (Test::Unit::AssertionFailedError)
      ./features/support/helpers/misc_helpers.rb:9:in `assert_vmcommand_success'
      ./features/support/helpers/vm_helper.rb:348:in `execute_successfully'
      ./features/step_definitions/torified_gnupg.rb:33:in `/^I fetch the "([^"]+)" OpenPGP key using the GnuPG CLI( without any signatures)?$/'
      features/torified_gnupg.feature:21:in `When I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI'

and Seahorse isn't dealing with it properly, appearing to freeze instead of displaying something like "Retrieving key failed: Timeout".

I'm looking for other cases, like the one intrigeri noted at #9095#note-2

#4 Updated by kytv almost 5 years ago

  • % Done changed from 0 to 40

#5 Updated by kytv almost 5 years ago

  • Blocked by Bug #9233: Seahorse's configured keyservers are not the same as those in gpg.conf added

#6 Updated by kytv almost 5 years ago

  • Blocked by Bug #9258: Accessing systray icons in the test suite is fragile added

#7 Updated by kytv almost 5 years ago

kytv wrote:

When seahorse fails to fetch a key the result can be the following:

I'm not sure how this should be addressed.

This seems to have been mostly fixed in #9233. I have added a fallback to the test so that if the screen greys out like that it'll click another window to unlock it and hopefully allow the step to complete successfully.

#8 Updated by kytv almost 5 years ago

  • Assignee changed from kytv to anonym
  • QA Check set to Ready for QA
  • Feature Branch set to kytv:bugfix/9095-seahorse-robustness

Note: #9233 isn't strictly needed for this branch but an ISO with it applied will help avoid the 'greyed out' problem from #9095#note-3.

#9 Updated by anonym almost 5 years ago

  • Assignee changed from anonym to kytv
  • QA Check changed from Ready for QA to Info Needed

It's unclear to me what of the reported issues your proposed branch is supposed to fix. I've run torified_gnupg.feature multiple times with this branch checked out, on a recent stable build (so #9233 is solved in it) and I've still seen a lot of errors. I'd say the probability for me to run the complete feature without any issue is about 50%. Here are the issues I've seen:

Seahorse fails to search

  Scenario: Fetching OpenPGP keys using Seahorse via the Tails OpenPGP Applet should work and be done over Tor. # features/torified_gnupg.feature:30
[...]
    When I fetch the "10CC5BC7" OpenPGP key using Seahorse via the Tails OpenPGP Applet                         # features/step_definitions/torified_gnupg.rb:98
      FindFailed: can not find SeahorseFoundKeyResult.png on the screen.
      Line ?, in File ? (RuntimeError)
      features/torified_gnupg.feature:31:in `When I fetch the "10CC5BC7" OpenPGP key using Seahorse via the Tails OpenPGP Applet'

There's a Seahorse error prompt saying "The search for keys failed. Couldn't communicate with server 'pool.sks-keyservers.net': cannot connect to destination (pool.sks-keyservers.net)"

Seahorse fails to import

  Scenario: Fetching OpenPGP keys using Seahorse via the Tails OpenPGP Applet should work and be done over Tor. # features/torified_gnupg.feature:30
[...]
    Then the "10CC5BC7" key is in the live user's public keyring after at most 120 seconds                      # features/step_definitions/torified_gnupg.rb:51
      The '10CC5BC7' key is not in the live user's public keyring (RuntimeError)
      ./features/support/helpers/misc_helpers.rb:22:in `try_for'
      ./features/step_definitions/torified_gnupg.rb:53:in `/^the "([^"]+)" key is in the live user's public keyring after at most (\d+) seconds$/'
      features/torified_gnupg.feature:32:in `Then the "10CC5BC7" key is in the live user's public keyring after at most 120 seconds'

There's a Seahorse error prompt saying "Couldn't import keys. Couldn't communicate with server 'pool.sks-keyservers.net': cannot connect to destination (pool.sks-keyservers.net)"

gpg fails to resolve hkps.pool.sks-keyservers.net

  Scenario: Syncing OpenPGP keys using Seahorse should work and be done over Tor.         # features/torified_gnupg.feature:34
[...]
    Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures   # features/step_definitions/torified_gnupg.rb:26
      Command failed: gpg --batch --keyserver-options import-clean --recv-key '10CC5BC7'
      error code: 2
      stdout: gpgkeys: HTTP fetch error 6: Couldn't resolve host name

      stderr: gpg: requesting key 0x10CC5BC7 from hkps server hkps.pool.sks-keyservers.net
      gpg: no valid OpenPGP data found.
      gpg: Total number processed: 0
      .
      <false> is not true. (Test::Unit::AssertionFailedError)
      ./features/support/helpers/misc_helpers.rb:9:in `assert_vmcommand_success'
      ./features/support/helpers/vm_helper.rb:348:in `execute_successfully'
      ./features/step_definitions/torified_gnupg.rb:34:in `/^I fetch the "([^"]+)" OpenPGP key using the GnuPG CLI( without any signatures)?$/'
      features/torified_gnupg.feature:35:in `Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures'

Seahorse segfaults :S

calling as root: pidof -x -o '%PPID' seahorse
call returned: [0, "5732\n", ""]
[log] CLICK on (467,114)
[log] CLICK on (307,142)
[log] CLICK on (305,198)
[log] Alt+TYPE "s" 
    And I synchronize keys in Seahorse                                                                                  # features/step_definitions/torified_gnupg.rb:85
      FindFailed: can not find SeahorseWindow.png on the screen.
      Line ?, in File ? (RuntimeError)
      features/torified_gnupg.feature:53:in `And I synchronize keys in Seahorse'

From syslog:

[  273.592932] seahorse[5732]: segfault at 0 ip 000000000808c962 sp 00000000ffa401a0 error 4 in seahorse[8048000+bd000]

Let's ignore this for now.

gpg gnutls_handshake() failure

  Scenario: Syncing OpenPGP keys using Seahorse should work and be done over Tor.         # features/torified_gnupg.feature:34
[..]
calling as amnesia: gpg --batch --keyserver-options import-clean --recv-key '10CC5BC7'
call returned: [2, "gpgkeys: HTTP fetch error 35: gnutls_handshake() failed: A TLS fatal alert has been received.\n", "gpg: requesting key 0x10CC5BC7 from hkps server hkps.pool.sks-keyservers.net\ngpg: no valid OpenPGP data found.\ngpg: Total number processed: 0\n"]
    Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures   # features/step_definitions/torified_gnupg.rb:26
      Command failed: gpg --batch --keyserver-options import-clean --recv-key '10CC5BC7'
      error code: 2
      stdout: gpgkeys: HTTP fetch error 35: gnutls_handshake() failed: A TLS fatal alert has been received.

      stderr: gpg: requesting key 0x10CC5BC7 from hkps server hkps.pool.sks-keyservers.net
      gpg: no valid OpenPGP data found.
      gpg: Total number processed: 0
      .
      <false> is not true. (Test::Unit::AssertionFailedError)
      ./features/support/helpers/misc_helpers.rb:9:in `assert_vmcommand_success'
      ./features/support/helpers/vm_helper.rb:348:in `execute_successfully'
      ./features/step_definitions/torified_gnupg.rb:34:in `/^I fetch the "([^"]+)" OpenPGP key using the GnuPG CLI( without any signatures)?$/'
      features/torified_gnupg.feature:35:in `Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures'

Running the command again quickly after the error (via features/scripts/vm-execute) reproduces it but waiting a few minutes fixes it. This makes me think at least one of the pool members has some issue, but I manually tried each pool member (by IP address), and didn't see the issue, and even re-resolved multiple times to get other pool members. Not sure what to make of this.

Thoughts

Ignoring the segfault, to me it seems like pool.sks-keyservers.net isn't working very well, not that the tests are poor (at least with the fixes from your branch). How do these tests behave for you?

#10 Updated by kytv almost 5 years ago

  • Assignee changed from kytv to anonym

anonym wrote:

It's unclear to me what of the reported issues your proposed branch is supposed to fix.

There were three (main) reported problems which I was able to reproduce.

1. Greyed out seahorse, probably taken care of for real by #9233 but also mitigated by 8b906f31f080
2. Failing to open the Preferences in order to enable synchronization (addressed by 3e91a8961f6211a63)
3. Occasionally failing to search for Keys (both in the original tests which I had nothing to do with, and in the new test in which Seahorse is started from the gpgApplet). This was likely fixed by #9233.

While running (and running (and running)) this scenario I stumbled upon another failure when trying to sync or find keys. I think that this could have been mitigated with introducing a static sleep or two, but I opted for clicking through the menus.

Thoughts

Ignoring the segfault, to me it seems like pool.sks-keyservers.net isn't working very well, not that the tests are poor (at least with the fixes from your branch). How do these tests behave for you?

Unfortunately it's about the same for me. When pool.sks-keyservers.net is functioning properly these tests work flawlessly; when it seems to be having "issues" I can see similar results caused by some sort of instability with pool.sks-keyservers.net. 4-5 days ago I didn't have any problems. Today, OTOH, after a couple of runs I saw

stdout: gpgkeys: HTTP fetch error 35: gnutls_handshake() failed: A TLS fatal alert has been received.

once and

There's a Seahorse error prompt saying "Couldn't import keys. Couldn't communicate with server 'pool.sks-keyservers.net': cannot connect to destination (pool.sks-keyservers.net)"

once as well.

With this branch the tests themselves are (IMHO) fine.

#11 Updated by intrigeri over 4 years ago

I've seen that one again while testing 1.4~rc1:

  Scenario: Fetching OpenPGP keys using Seahorse via the Tails OpenPGP Applet should work and be done over Tor. # features/torified_gnupg.feature:30
    When I fetch the "10CC5BC7" OpenPGP key using Seahorse via the Tails OpenPGP Applet                         # features/step_definitions/torified_gnupg.rb:97
      FindFailed: can not find SeahorseFindKeysWindow.png on the screen.
      Line ?, in File ? (RuntimeError)
      features/torified_gnupg.feature:31:in `When I fetch the "10CC5BC7" OpenPGP key using Seahorse via the Tails OpenPGP Applet'

Is it supposed to be fixed by the proposed (but not merged yet) branch?

#12 Updated by kytv over 4 years ago

  • QA Check changed from Info Needed to Ready for QA
<intrigeri> KillYourTV: https://labs.riseup.net/code/issues/9095 should be ready for QA, or?

Yes, Probably so.

intrigeri wrote:

I've seen that one again while testing 1.4~rc1:

[...]

Is it supposed to be fixed by the proposed (but not merged yet) branch?

If it was caused by a transient error, such as the one anonym referenced above, no.

anonym wrote:

There's a Seahorse error prompt saying "Couldn't import keys. Couldn't communicate with server 'pool.sks-keyservers.net': cannot connect to destination (pool.sks-keyservers.net)"

If we are to work around transient errors like this we've got a bit of work to do everywhere.

#13 Updated by intrigeri over 4 years ago

intrigeri wrote:

I've seen that one again while testing 1.4~rc1:
[...]
Is it supposed to be fixed by the proposed (but not merged yet) branch?

If it was caused by a transient error, such as the one anonym referenced above, no.

The way I understand this error, it seems to happen before any attempt to fetch keys, so I don't think it can be caused by a transient networking or keyserver pool error. Note that this is the first error reported in this ticket's description, hence my question: it would be a problem to mark it as fixed, if it's not. Now, if the rest is fixed but this one isn't, then it can be moved to a dedicated ticket of course :)

#14 Updated by anonym over 4 years ago

  • Assignee changed from anonym to kytv
  • Target version changed from Tails_1.4 to Tails_1.4.1
  • QA Check changed from Ready for QA to Dev Needed

intrigeri wrote:

intrigeri wrote:

I've seen that one again while testing 1.4~rc1:
[...]
Is it supposed to be fixed by the proposed (but not merged yet) branch?

If it was caused by a transient error, such as the one anonym referenced above, no.

The way I understand this error, it seems to happen before any attempt to fetch keys, so I don't think it can be caused by a transient networking or keyserver pool error.

You are correct.

Note that this is the first error reported in this ticket's description, hence my question: it would be a problem to mark it as fixed, if it's not. Now, if the rest is fixed but this one isn't, then it can be moved to a dedicated ticket of course :)

Right. Still, the current branch improves things, and it solves one problem => opened #9343, had KillYourTV quickly rewrite the commit messages for that new ticket, and merged it. Still, some issues remain (will open subtickets), but they won't be solved for Tails 1.4. Post-poning to Tails 1.4.1.

#15 Updated by anonym over 4 years ago

  • Feature Branch deleted (kytv:bugfix/9095-seahorse-robustness)

#16 Updated by kytv over 4 years ago

I'm testing my fixes for #9344 against a Tails 1.3.2 ISO, one that didn't have the correct keyserver configured which leads to the ugly greyed out screen shown in #9095#note-7. I'm very happy with the changes that went into #9343 but were originally intended for this ticket. I'm seeing the greyed out window nearly every time but the tests work around it. Yay. (Edit: With Tails 1.4~rc1 I never see it).

(intrigeri should (hopefully) have better luck with torified_gnupg.feature now, and still more successful runs once #9344 lands. :D)

#17 Updated by kytv over 4 years ago

In my workspace, for the case of a keyserver error:

    When the network is unplugged                                                          # features/step_definitions/common_steps.rb:119
    When I fetch the "10CC5BC7" OpenPGP key using Seahorse                                 # features/step_definitions/torified_gnupg.rb:113
      OpenPGPKeyserverError (OpenPGPKeyserverError)
      ./features/step_definitions/torified_gnupg.rb:16:in `rescue in seahorse_wait_helper'
      ./features/step_definitions/torified_gnupg.rb:12:in `seahorse_wait_helper'
      ./features/step_definitions/torified_gnupg.rb:127:in `/^I fetch the "([^"]+)" OpenPGP key using Seahorse( via the Tails OpenPGP Applet)?$/'
      features/torified_gnupg.feature:20:in `When I fetch the "10CC5BC7" OpenPGP key using Seahorse'

#18 Updated by kytv over 4 years ago

This was finally triggered

    And I synchronize keys in Seahorse                                                                                  # features/step_definitions/torified_gnupg.rb:121
      Seahorse aborted with a segmentation fault.
      <false> is not true. (Test::Unit::AssertionFailedError)

so now I have confirmation that what I wanted to test worked. :)

#19 Updated by intrigeri over 4 years ago

This was finally triggered

FWIW, I've seen that one once recently too.

#20 Updated by kytv over 4 years ago

intrigeri wrote:

This was finally triggered

FWIW, I've seen that one once recently too.

Excellent. :)

-------
I found this to be kind of interesting and it's on the topic of 'robustness' but there's nothing for 'us' to do about it:

I don't know if this is 100% reproducible across boots, but ATM I'm working on #9518 and I set my keyserver to localhost. Starting Seahorse from the Gnome menu (or Tails OpenPGP Applet) and trying to sync keys caused Seahorse to segfault within a few seconds. I consistently reproduced this 10 out of 10 times.

When starting Seahorse from a terminal window, the segfault didn't happen until exiting seahorse.

Another interesting (to me) find: Searching for keys while the keyserver is set to localhost didn't bring about a segfault but it failed much more quickly when Seahorse was started from the Gnome menu (or from the Tails OpenPGP Applet).

#21 Updated by kytv over 4 years ago

  • Target version changed from Tails_1.4.1 to Tails_1.5

Will be mostly resolved by #9518.

#22 Updated by kytv over 4 years ago

  • Assignee deleted (kytv)
  • QA Check deleted (Dev Needed)

This ticket still has subtasks which are open but I don't think "Seahorse tests lack robustness" is true anymore.

Now that we are retrying when communicating with the keyservers fails the torified_gnupg feature is stable. Indeed, I don't see it fail anymore, other than the (thankfully) rare times in which Seahorse segfaults :|.

Should this ticket perhaps be closed?

#23 Updated by intrigeri over 4 years ago

  • Assignee set to kytv

This ticket still has subtasks which are open but I don't think "Seahorse tests lack robustness" is true anymore.

If the remaining subtasks don't imply lack of robustness, then they should not be children of this ticket ⇒ please fix that.

Indeed, I don't see it fail anymore, other than the (thankfully) rare times in which Seahorse segfaults :|.

I suggest making the ticket that tracks said segfaults a subtask of this one.

Should this ticket perhaps be closed?

Now that you've pointed to another open robustness issue, I don't think so.

#24 Updated by kytv over 4 years ago

  • Blocked by Bug #9970: Seahorse may segfault during key synchronization added

#25 Updated by kytv over 4 years ago

  • Target version changed from Tails_1.5 to Tails_1.6

#26 Updated by kytv over 4 years ago

  • Target version changed from Tails_1.6 to Tails_1.7

#27 Updated by intrigeri over 4 years ago

intrigeri wrote:

This ticket still has subtasks which are open but I don't think "Seahorse tests lack robustness" is true anymore.

If the remaining subtasks don't imply lack of robustness, then they should not be children of this ticket ⇒ please fix that.

Indeed, I don't see it fail anymore, other than the (thankfully) rare times in which Seahorse segfaults :|.

I suggest making the ticket that tracks said segfaults a subtask of this one.

Ping 3 months later?

#28 Updated by kytv about 4 years ago

  • Target version changed from Tails_1.7 to Tails_1.8

#29 Updated by kytv about 4 years ago

  • Related to Bug #10500: Monitor failure modes of Seahorse added

#30 Updated by kytv about 4 years ago

I've made very good progress on this while working on #9791. In feature/jessie this feature is, dare I say, the epitome of robust1. After I review my code and set #9791 to RfQA. I'll backport the improvements here.


1 It is robust on my hardware. In time we'll find out whether Jenkins will be happy with it.

#31 Updated by kytv about 4 years ago

  • Assignee changed from kytv to anonym
  • QA Check set to Ready for QA
  • Feature Branch set to kytv/test/9095-robust-seahorse

I made quite a few changes here. After several days of running this feature both in wheezy (and with it merged into feature/jessie for #9791) it's been robust without any failures.

I really hope Jenkins will be happy with this but we'll see…

#32 Updated by intrigeri about 4 years ago

After I review my code and set #9791 to RfQA. I'll backport the improvements here.

Once we're there, let's have a break and reconsider if it's worth your time backporting stuff to Wheezy.

#33 Updated by kytv about 4 years ago

intrigeri wrote:

After I review my code and set #9791 to RfQA. I'll backport the improvements here.

Once we're there, let's have a break and reconsider if it's worth your time backporting stuff to Wheezy.

In this case I think it was. The changes (hopefully) made the scenario future-proof. I was able to fix it in a way that required very few changes when merged into Jessie. The main changes required was due to the change of location in the GNOME menus.

I can see how in many cases it would not be worth it. I don't think that applies this time.

#34 Updated by intrigeri about 4 years ago

  • Assignee changed from anonym to bertagaz

#35 Updated by intrigeri about 4 years ago

  • Assignee changed from bertagaz to intrigeri

I'll take #9791 and check this one.

#36 Updated by intrigeri about 4 years ago

  • Blocked by deleted (Bug #9970: Seahorse may segfault during key synchronization)

#37 Updated by intrigeri about 4 years ago

  • Related to Bug #9970: Seahorse may segfault during key synchronization added

#38 Updated by intrigeri about 4 years ago

  • Status changed from In Progress to 11

#39 Updated by intrigeri about 4 years ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#40 Updated by anonym about 4 years ago

  • Status changed from 11 to Resolved

Also available in: Atom PDF