745702 - GTK 2.10.* not being blocked

Status: RESOLVED FIXED

(AUS Graveyard :: General, defect, P2)

Description

[Mark Banner (:standard8)]

I've been made aware of this via bug 735637 - bug 666735 should have blocked Firefox 7 and later users from getting updates if they are using a Linux version which uses GTK 2.10.* because there's a too old version of freetype.

The blocking was implemented here:

bonsai.mozilla.org/cvsblame.cgi?file=mozilla/webtools/aus/xml/inc/config-dist.php&rev=1.202#263

According to the update urls, this blocking is no longer happening:

https://aus3.mozilla.org/update/3/Firefox/10.0.2/20120215223356/Linux_x86-gcc3/en-GB/release/Linux%202.6.18-238.19.1.el5%20%28GTK%202.11.4%29/default/default/update.xml?force=1
https://aus3.mozilla.org/update/3/Firefox/10.0.2/20120215223356/Linux_x86-gcc3/en-GB/release/Linux%202.6.18-238.19.1.el5%20%28GTK%202.10.4%29/default/default/update.xml?force=1

Thunderbird has the same config, and this is working:

http://viewvc.svn.mozilla.org/vc/mozillamessaging.com/sites/aus.mozillamessaging.com/trunk/config.php?revision=103759&view=markup#236

https://aus2.mozillamessaging.com/update/3/Thunderbird/11.0/20120312195326/Linux_x86-gcc3/en-GB/release/Linux%202.6.18-238.19.1.el5%20%28GTK%202.10.4%29/default/default/update.xml?force=1
https://aus2.mozillamessaging.com/update/3/Thunderbird/11.0/20120312195326/Linux_x86-gcc3/en-GB/release/Linux%202.6.18-238.19.1.el5%20%28GTK%202.11.4%29/default/default/update.xml?force=1

(note, the release notes also haven't been updated yet, but that's bug 708103).

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

This is a problem since we started using the new format of snippet files, sometime after bug 459972 landed on 2011-09-30 and we did the first release using the new format. 

The fallout, from a quick read of 
 http://mxr.mozilla.org/mozilla/source/webtools/aus/xml/inc/config-dist.php
and knowing that we only use the new attributes for updates *from* FF 4.0 and higher, is only that we're not blocking GTK 2.10 for FF7 and higher.

We will need to fix this before FF13 hits beta, where serving Win2k and XP RTM/SP1 users and update would be a bigger deal. We're OK with 13 in Aurora because the nightly updates use the older style of snippets.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: WIP

Here's the problem:
* the version=1 snippets have appv and extv for versioning
* the version=2 snippets have displayVersion, appVersion, platformVersion
* AUS has a bunch of usage of appv and extv baked in
* having done all the work of reading snippets etc and just prior to returning an update we check if the OS is de-supported for the version to be offered, 
 http://mxr.mozilla.org/mozilla/source/webtools/aus/xml/index.php#316
* updateExtensionVersion isn't set when you have a version=2 style snippet
* isSupported returns true by default
 http://mxr.mozilla.org/mozilla/source/webtools/aus/xml/inc/patch.class.php#727

So this is a bandaid to go on top to make sure the needed var is set. I need to sort out my VM with fitnesse to add some tests for this, but could you take a look at bug 702084 too ?

Comment 3

[Robert Helmer [:rhelmer]]

Comment on attachment 615296 [details] [diff] [review]
WIP

Looks ok to me, and does not introduce any new test failures (ran fitnesse in https://github.com/rhelmer/aus-vagrant based VM until we get the jenkins tests going again)

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Code change as before, with tests

The code change is the same as the earlier feedback+ patch. I've looked for other usage of updateVersion or updateExtensionVersion and couldn't see any.

The new tests are a copy of v2-style snippets in 
  tests/data/3/Synthetic/1.0/platform/2000000001
with versions bumped to 2.0 so the deprecation comes into play. Verify.txt is a merge of params for OS deprecation and v2 snippets.

Aiming to have this deployed by mid-week, so that we're ok for Firefox 13 hitting the beta channel.

Comment 5

[Robert Helmer [:rhelmer]]

Comment on attachment 617431 [details] [diff] [review]
Code change as before, with tests

Patch and tests look good to me; new tests fail w/o patch and pass with it in a local vagrant VM (as expected)

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

$ cvs ci ...
Checking in tests/Verify.txt;
/cvsroot/mozilla/webtools/aus/tests/Verify.txt,v  <--  Verify.txt
new revision: 1.26; previous revision: 1.25
done
RCS file: /cvsroot/mozilla/webtools/aus/tests/data/3/Synthetic/1.0/platform/2000000003/locale/channel/complete.txt,v
done
Checking in tests/data/3/Synthetic/1.0/platform/2000000003/locale/channel/complete.txt;
/cvsroot/mozilla/webtools/aus/tests/data/3/Synthetic/1.0/platform/2000000003/locale/channel/complete.txt,v  <--  complete.txt
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/aus/tests/data/3/Synthetic/1.0/platform/2000000003/locale/channel/partial.txt,v
done
Checking in tests/data/3/Synthetic/1.0/platform/2000000003/locale/channel/partial.txt;
/cvsroot/mozilla/webtools/aus/tests/data/3/Synthetic/1.0/platform/2000000003/locale/channel/partial.txt,v  <--  partial.txt
initial revision: 1.1
done
Checking in xml/inc/patch.class.php;
/cvsroot/mozilla/webtools/aus/xml/inc/patch.class.php,v  <--  patch.class.php
new revision: 1.32; previous revision: 1.31
done

$ cd xml
$ cvs tag AUS2_PRODUCTION
W inc/patch.class.php : AUS2_PRODUCTION already exists on version 1.31 : NOT MOVING tag to version 1.32
$ cvs tag -F AUS2_PRODUCTION
T inc/patch.class.php

$ cvs tag -f AUS2_RTM_`date +%Y%m%d%H%M`

which was AUS2_RTM_201204261548

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

Fixed, even if it's not what the reporter of bug 735637 had in mind.

Comment 8

[Alex Keybl [:akeybl]]

Untracking for FF13 since the fix was done server side.