Closed Bug 528431 Opened 10 years ago Closed 10 years ago

Provide GTK and QT builds for Maemo5

Categories

(Release Engineering :: General, defect, P2, major)

ARM
Linux

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dougt, Assigned: jhford)

References

Details

Attachments

(3 files, 5 obsolete files)

We need a Maemo/QT Tinderbox.

* it must be running the MAEMO 5 SDK:

   http://repository.maemo.org/stable/fremantle/maemo-scratchbox-install_5.0.sh
   http://repository.maemo.org/stable/fremantle/maemo-sdk-install_5.0.sh

* it should also install the follow:

   fakeroot apt-get install libqt4-gui libqt4-dev

* the mozconfig should be identical to what we are using for the current maemo/gtk builds, but we also should add the following:

ac_add_options --enable-default-toolkit=cairo-qt
ac_add_options --disable-plugins
I'm hoping this can coexist with our current scratchbox install.

We'll need to

1) stake out a test box in staging
2) install maemo 5 scratchbox + sdk
3) plus the qt libs
4) test the build w/ above mozconfig options
5) also test switching between the chinook and fremantle sbox envs.  maybe
instead of /scratchbox/moz_scratchbox we'd have /scratchbox/moz_chinook &
/scratchbox/moz_fremantle that run sb-conf explicitly each time?  need to run
current maemo builds/repacks in this env to make sure we're not breaking
anything.
5.4) patches!
5.5) reviews!
6) roll out changes in puppet
7) enable new builds

Unless I'm missing something.

Doug's hoping to have this for post-1.0 work.  Not sure if we can dup the other
QT build bug against this one or not.  We probably need to prioritize/schedule
this.
Duplicate of this bug: 451129
Marking bug 489410 as a blocker, since manually clobbering is already painful without the added Maemo5 builds.  We'll probably have that fixed before we get to this bug, anyway, but this will remind us.
Depends on: 489410
Handing to John for prioritization.
Assignee: nobody → joduinn
aiui, this rates lower priority than our existing maemo4 release prep, and building up WinMO support.

Once these are done (est. end December2009), we can revisit this. Meanwhile, tweaking summary, and moving to Future.
Assignee: joduinn → nobody
Component: Release Engineering → Release Engineering: Future
Summary: Maemo/QT tinderbox → Provide builds/unittest/talos for Maemo5 ("QT")
can we take baby steps and get builds going first and file separate bugs for unit tests and talos?

I do not thing we should wait for many months before getting something as trivial has Qt builds going.  From a standard maemo4 sbox installation, it is only a few extra steps which I documented above.
Assignee: nobody → jhford
Component: Release Engineering: Future → Release Engineering
Summary: Provide builds/unittest/talos for Maemo5 ("QT") → Provide builds for Maemo5 ("QT")
Summary: Provide builds for Maemo5 ("QT") → Provide QT- and non-QT- builds for Maemo5
Update please?
Scheduled for this quarter, but most likely won't happen this week.
Tentatively marked to start this the week of Jan 25, but things are already slipping. https://wiki.mozilla.org/User:Asasaki:2010Q1#Schedule
Update please?  ( I do not see it listed in the schedule )
Update please?
I am nearly done getting tests of n810 builds running on n900s which, as I understand, is my highest priority.  I am wrapping up this work and should be done tomorrow.  I am going to be writing code for builds starting on Monday.

My first task will be to set up scratchbox on slaves.  We will use puppet to deploy the new scratchbox.  One complication to this is that we currently have the chinook scratchbox on the slaves.  

We can either have two scratchbox(-en/-es?) on the same machine and enable/disable the correct one on demand or try to install diablo and fremantle sdks into one scratchbox.  The former will be the quicker to get up but will use a lot of extra disk on the slave (resulting in more free space clobbers for all linux32 builds).  The later is dependent on being able to install diablo sdk into sb5 (i was unable to get chinook sdk into sb5).

If no one has a strong preference, I will be going with two seperate scratchbox.
having separate sboxes is what I do locally and probably is less of a headache.  However, I am not sure of the impact of more free space clobbers for
all linux32 builds.
I am going to be working on this today.
Status: NEW → ASSIGNED
Priority: -- → P2
gah, my temporary vm was invalid.  I am asking for it to be recreated
Blocks: 544042
Blocks: 549975
Blocks: 550945
do we need to install the nokia proprietary binaries?

From sdk installer:

***NOKIA BINARIES***
In order to obtain Nokia-closed binaries, visit
http://tablets-dev.nokia.com/eula/index.php to accept the End User
License Agreement. You will be given a token to access the Nokia
binaries repository with further instructions.
we should not need any.
(In reply to comment #15)
> do we need to install the nokia proprietary binaries?
> 
> From sdk installer:
> 
> ***NOKIA BINARIES***
> In order to obtain Nokia-closed binaries, visit
> http://tablets-dev.nokia.com/eula/index.php to accept the End User
> License Agreement. You will be given a token to access the Nokia
> binaries repository with further instructions.

scratch that, i can't install libqt4-dev without that repository
weird.  libqt4 shoudln't be governed by the Nokia-closed binaries license.  I'll follow up, but for now... do what you gots to do!
it wasn't any of the libqt4-* packages, but their low level dependencies
there are  libqt* packages 4.6.2 available in maemo extras-devel repository
short answer: deleting the giant log file didn't solve the problem


I was able to reproduce the issue I was having with the new VM.  Deleting the log file was not a solution.  One thing that I have noticed is that this fails only on the first time that a script is run.  It is giving me the same error message, but running a different command.  I have found that it is occurring only when running python scripts.  Does anyone know if there is any sort of configuration caching going on within scratchbox?

I am going to try a fresh sb5 + chinook sdk + fremantle sdk again to see if I can get that to work.  If that doesn't work, I could do the recursive hash of the file system, do a build, do another recursive hash to find out which files where modified during the build and see if any are outside of my objdir.  that would be far from ideal imo, as it takes a long time.

forever pastebin: http://pastebin.mozilla.org/707501
I am not having this problem on my CentOS VM nor am I having it on Ubuntu 9.10 (yet).
I have tried a fresh scratchbox installation on our existing ref image and it had the same issue.  I am going to upgrade the kernel and see if the issue is still there with the brand new sb + kernel upgrade.

I also have a vanilla install of CentOS 5.0 on a local machine that is installing scratchbox for maemo5 to test if the OS is at all capable of doing maemo5 builds.
ok, fresh centos 5.0 + fresh scratchbox with fremantle sdk produced a build.  This tells me that vm.mmap_min_addr is *not* the problem (linux 2.6.18-8.el5) as this kernel does not have this setting.

I am going to try a clean scratchbox on the refimage again to ensure that it is absolutely not the problem.
(also looking to see if we can drop chinook and only support fremantle)
Not sure how that would work for repo updates, though we can possibly softlink or something.
lets try using an x86 python inside of scratchbox. We should be able to build python on the host os using ./configure --prefix=/scratchbox/users/cltbld/host_user ; make -j4 ; make altinstall
Also, i am going to try |unset PYTHONPATH| before trying to install the sdk
plan of action for the next few days:

reclone maemo-test01 + maemo-test02 -- underway (thanks Phong!)

unset PYTHONPATH ; unset PYTHONHOME ; export PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/cltbld/bin
su -
/etc/init.d/sbox stop
sh maemo-scratchbox-install_5.0.sh -U -s /scratchbox
/etc/init.d/sbox start
exit
sh maemo-sdk-install_5.0.sh -y -d -s /scratchbox
mkdir -p /scratchbox/builds/slave
mount -o bind /builds/slave /scratchbox/builds/slave
cd /builds/slave
hg clone http://hg.mozilla.org/mozilla-central fremantle-central
hg clone fremantle-central chinook-central
for i in freemantle chinook ; do
  pushd ${i}-central
  wget http://hg.mozilla.org/build/buildbot-configs/raw-file/b8f3edaf2695/mozilla2/linux/mobile-browser/nightly/mozconfig
  hg clone http://hg.mozilla.org/mobile-browser mobile
  popd
done
/scratchbox/moz_scratchbox
sb-conf select FREMANTLE_ARMEL
wget http://www.python.org/ftp/python/2.5.5/Python-2.5.5.tar.bz2
tar jxf Python-2.5.5.tar.bz2
cd Python-2.5.5.tar.bz2
./configure --prefix=/scratchbox/users/cltbld/host_usr
make -j4
make altinstall
cd /builds/slave/fremantle-central
make -f client.mk build
cd objdir
make package
make package-tests
sb-conf select CHINOOK_ARMEL-2007 #or whatever we use
cd /builds/slave/chinook-central
make -f client.mk build
cd objdir
make package
make package-tests
exit

After this I plan to post these builds to people to get verification from QA that these are valid builds.  While they are being validated I am going to test that my plan to deploy the scratchbox will work:

on deployer:
cd ~
/scratchbox/sbin/sbox_ctl stop
/scratchbox/sbin/sbox_umount_all
rm -rf /scratchbox/users/cltbld/home/cltbld/build*
su -c 'tar jcfps /home/cltbld/new-scratchbox.tar.bz2 /scratchbox'

on deployee:
su -
cd /
/scratchbox/sbin/sbox_ctl stop
/scratchbox/sbin/sbox_umount_all
tar jxf new-scratchbox.tar.bz2

At this point, I plan to generate another chinook and fremantle and put them on people again to see if anyone wants to double check them.  Once that is done, I will start working on build automation.
forgot to note that I am going to run the following commands before building

echo deb http://repository.maemo.org/ fremantle/<token removed> nokia-binaries >> /etc/apt/sources.list
fakeroot apt-get update
fakeroot apt-get install python python-dev autoconf2.13 libnotify-dev libIDL-dev
#QT dependencies
fakeroot apt-get install libqt4-gui libqt4-dev


I am using maemo-test01 for the creation of the sb package and maemo-test02 for the testing of deployment
while installing the sdk i noticed:

#
Setting up hildon-update-category-database (2.1.3-1+0m5) ...
#
***
#
* Updating MIME database in /usr/share/mime...
#
* Error in type 'application/andrew-inset'
#
*   (in /usr/share/mime/packages/freedesktop.org.xml):
#
*   Unknown freedesktop.org field 'generic-icon'.
#
* Error in type 'application/epub+zip'
#
*   (in /usr/share/mime/packages/freedesktop.org.xml):
#
*   Unknown freedesktop.org field 'generic-icon'.
[the rest of that error message is at http://pastebin.mozilla.org/707913 ]
While we are looking at the deployment of a new scratchbox, is it worthwhile to do an audit of the targets that we have set up?

sb-menu shows me 

CHINOOK-ARMEL-2007  cs2007q3-glibc2.5-arm6
CHINOOK_ARMEL       cs2005q3.2-glibc2.5-arm
CHINOOK_X86         cs2005q3.2-glibc2.5-i386
FREMANTLE_ARMEL     cs2007q3-glibc2.5-arm7
FREMANTLE_X86       cs2007q3-glibc2.5-i486

We will be using FREMANTLE_ARMEL and CHINOOK-ARMEL-2007

Do we need to keep the CHINOOK_ARMEL, CHINOOK_X86, FREMANTLE_X86 targets there?  I am not sure how much extra space we would free by removing these targets but getting rid of the CHINOOK_ARMEL seems prudent as it could be easily confused with what we actually use.
turns out that instead of mkdir -p /scratchbox/builds/slave we need mkdir -p /scratchbox/users/cltbld/scratchbox/users/cltbld/build/slave

this is going to be used as a bind mount to our current slave directory so that the checkouts live under the buildbot (and thus clobberer) directories.  Having clobberer work with these builds is a major win for us!
Shouldn't that be /scratchbox/users/cltbld/builds/slave ?
But, awesome!
(In reply to comment #34)
> Shouldn't that be /scratchbox/users/cltbld/builds/slave ?
> But, awesome!

yes, that worked.  I don't think scratchbox picked up the folder I tried to bind.  

One error in my list of things to do above is that i enter scratchbox before compiling python,  this should *not* happen


Doug, I remember you saying that the minimum requirement was qt4.6.  I am only getting 4.5.3 from the nokia repository.  Should I be compiling qt4.6 from source for scratchbox + devices?
moving forward without a QT package in the scratchbox as we don't currently know which QT4.6 package to use (or build from source).  We are going to move forward with GTK maemo5 builds and get qt ones as a follow up once a QT package is decided on.

Morphing this bug and creating a new follow up bug for QT builds.
Blocks: 553008
Summary: Provide QT- and non-QT- builds for Maemo5 → Provide GTK builds for Maemo5
No.  We want Qt builds Maemo 5.  If you want a bug for Gtk on Maemo 5, that should be the new bug.  Please reset the summary.
(In reply to comment #36)
> comment #20
> 
> Qt 4.6.2 available from extras-devel repository:
> 
> deb http://repository.maemo.org/extras-devel fremantle free non-free
> http://repository.maemo.org/extras-devel/pool/fremantle/free/q/qt4-maemo5/

Hi Oleg,  I discussed this with Doug this morning and this package does not match the version of QT on the device.  Because of this, we would not be able to produce builds that are able to run on the device using this QT package.
Yep, totally agree Mozilla need QT builds, in addition to GTK builds. Most of this bug has been dealing with work associated with getting GTK builds going, which is why I have it as the GTK bug. As the QT toolchain dependencies are being worked out, I filed a new bug (553008) to track qt builds separately and not confuse the two discussions in one bug. 

per discussion with joduinn and stuart, it seems that completing the last few days of gtk build setup are higher priority, but let me know if that's not your understanding?

Meanwhile, in case you didnt see comment 36, comment 39, it would be really helpful if you can clarify in bug553008 which specific versions of qt libraries are useful for maemo, and *do* work on the n900s
i was able to get a chinook and fremantle build working for both FREMANTLE_ARMEL and CHINOOK-ARMEL-2007.  I am going to verify that these both launch on device, then test my deployment plan.  If you'd like to see these builds I can post them to people.
during my test of deployment I looked into the unused targets.  We currently use CHINOOK-ARMEL-2007 for maemo4 builds, plan on using FREMANTLE_ARMEL for maemo5 builds.  

We also have other targets that are not used and not kept up to date.  I would like to remove them as they represent a significant use of space on the builds filesystem which results in free space clobbers, which slow down dep builds which results in longer end-to-end and wait times for all branches of firefox and mobile on linux32.

Proposing to delete:
CHINOOK_X86 - 412mb
CHINOOK_ARMEL - 397mb
FREMANTLE_X86 - 430mb
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm - 130mb
/scratchbox/compilers/cs2005q3.2-glibc2.5-i386 - 120mb

Definately keeping:
FREMANTLE_ARMEL - 604mb
CHINOOK-ARMEL-2007 - 271mb

Having 1.5gb of extra space on the hard drive means that we can have fewer clobber builds and more incremental builds, which means shorter wait times and quicker builds.  If we wanted to leave FREMANTLE_X86 just in case, I still think it is worthwhile to delete the other two targets and compilers to gain 1.1gb.

People on #mobile seem to agree that these targets are not valuable to us and should not be kept but I'd like to make sure that this is a consensus before i delete them.
(In reply to comment #42)
> Proposing to delete:
> CHINOOK_X86 - 412mb
> CHINOOK_ARMEL - 397mb
> FREMANTLE_X86 - 430mb
> /scratchbox/compilers/cs2005q3.2-glibc2.5-arm - 130mb
> /scratchbox/compilers/cs2005q3.2-glibc2.5-i386 - 120mb
> 
> Definately keeping:
> FREMANTLE_ARMEL - 604mb
> CHINOOK-ARMEL-2007 - 271mb

Sounds fine to me. Let's get Stuart to stamp this before you pull the trigger.
yep, should be fine to remove the targets, using the scratchbox tools.  I'm less sure about removing compilers and what dependencies that has, so should probably test it first.
ok, those targets have been deleted.

Even though i was able to get a successful build last week, my scratchbox stopped working.  I have rebuilt python and openssl for scratchbox using

$ /scratchbox/moz_scratchbox
$ openssl md5 openssl-0.9.8m.tar.gz Python-2.5.5.tar.bz2 
MD5(openssl-0.9.8m.tar.gz)= 898bf125370926d5f692a2201124f8ec
MD5(Python-2.5.5.tar.bz2)= 1d00e2fb19418e486c30b850df625aa3
$ tar jxf Python-2.5.5.tar.bz2
$ tar zxf openssl-0.9.8m.tar.gz
$ cd openssl-0.9.8m
$ CC=host-gcc CXX=host-g++ ./config shared --prefix=/usr/local
$ make -j4
$ make install
$ cd Python-2.5.5
$ CC=host-gcc CXX=host-g++ ./configure --prefix=/host_usr
$ make -j4
$ make altinstall

And to verify that nothing has missing dependencies
find -name "*.so*" -exec ldd {} \; | grep "not found" # should have no output

I have confirmed with dolske that we do not link against openssl in irc (03/22/2010), so this should be safe.
IRC log
jhford: do we link against openssl at all?  i am assuming, but not sure, that we use nss for all of our crypto
dolske: jhford: there's no openssl in the product at all. Weave once used it, but switched to NSS a year or so ago.

We would also be in trouble if we link the build time python into the final product or tests archive.

I am currently building a version of fennec for the fremantle sdk and will post in this bug and retry deployment when that completes successfully
we need to run rm /tmp/cputransp_cltbld.log on the slave before we do any builds
Attached patch buildbot-configs (obsolete) — Splinter Review
config changes needed for the addition of Maemo5 GTK and QT builds.  I have a special case for mozilla-1.9.2 + qt being disabled.  QT is not desired on mozilla-1.9.2 according to #mobile chatter today.  I can easily remove this special case.
Attachment #435083 - Flags: review?(aki)
Attached patch buildbotcustom (obsolete) — Splinter Review
Buildbotcustom changes needed to make Maemo5 GTK + QT builds go.
Attachment #435084 - Flags: review?(aki)
Comment on attachment 435083 [details] [diff] [review]
buildbot-configs

>+hacktionary = {

haha :)

>+        maemo5 = deepcopy(MOBILE_BRANCHES[branch]['platforms']['linux-gnueabi-arm'])
>+        maemo5['base_name'] = "Maemo 5 %s %s" % (toolkit.upper(),
>+                                                 hacktionary.get(branch, branch))

Uh... I don't follow.  HOWEVER,

>+if __name__=="__main__":
>+    print MOBILE_BRANCHES

This is made of awesome.

So I tried to apply this to buildbot-configs so I could run this and take a closer look at the files in full, but got

Hunk #2 FAILED at 37
Hunk #3 FAILED at 111
Hunk #4 FAILED at 181
Hunk #5 FAILED at 208
Hunk #6 FAILED at 252
Hunk #7 FAILED at 325
Hunk #8 FAILED at 370

Sorry for the bitrot.  Could I get a new patch?
Comment on attachment 435084 [details] [diff] [review]
buildbotcustom

Ok, probably going to want to discuss this patch with you to get the reasoning down.

>+                 mobileObjdir='mobile', xulrunnerObjdir='xulrunner',

Assuming this is because maemo4 is xulrunner-based and maemo5gtk is non-xulrunner-based.  Or at least maemo5qt.

In a way, rather than seeing objdir/mobileObjdir, I kinda wanna see mobileObjdir = 'objdir/mobile' or just 'objdir' depending whether it's a xulrunner build or not. 

>+                 debs=True,

What's this for?  I don't think we want any builds without debs.

>+            "echo -n TinderboxPrint: && sb-conf current | sed 's/ARMEL// ; s/_// ; s/-//'"],

the sed is just to shorten things?

>+                     '%s/%s' % (self.objdirRelPath, self.mobileObjdir),

Aha, you went this route so you didn't have to have mobileObjdir{Rel,Abs}Path and xulrunnerObjdir{Rel,Abs}Path ?

This one applied cleanly, so let's discuss in the morning.
(In reply to comment #49)
> Uh... I don't follow.  HOWEVER,

Basically, take whatever we do for Maemo4 and start using that as the basis for Maemo5, since Maemo5 should be nearly identical for a while.

> Sorry for the bitrot.  Could I get a new patch?

sure.

(In reply to comment #50)
> (From update of attachment 435084 [details] [diff] [review])
> Ok, probably going to want to discuss this patch with you to get the reasoning
> down.
> 
> >+                 mobileObjdir='mobile', xulrunnerObjdir='xulrunner',
> 
> Assuming this is because maemo4 is xulrunner-based and maemo5gtk is
> non-xulrunner-based.  Or at least maemo5qt.

correct.  I am building maemo 5 GTK as non-xulrunner until I know that I shouldn't be.
 
> In a way, rather than seeing objdir/mobileObjdir, I kinda wanna see
> mobileObjdir = 'objdir/mobile' or just 'objdir' depending whether it's a
> xulrunner build or not. 

If i called it objdirMobileSubdir and objdirXulrunnerSubdir it would be more explicit as to what it actually is.  I'd rather not get into modifying any of the existing objdir* variables as I don't want to track down all the interdependencies.

> What's this for?  I don't think we want any builds without debs.
agreed, and totally correct.  The problem is that the make deb target was failing for me on QT 100% and I am not sure if it was working on GTK

> the sed is just to shorten things?

yes

> Aha, you went this route so you didn't have to have mobileObjdir{Rel,Abs}Path
> and xulrunnerObjdir{Rel,Abs}Path ?
> 
> This one applied cleanly, so let's discuss in the morning.
Attached patch buildbot-configs unbitrotted (obsolete) — Splinter Review
unbitrot
Attachment #435083 - Attachment is obsolete: true
Attachment #435210 - Flags: review?(aki)
Attachment #435083 - Flags: review?(aki)
Attached patch buildbot-configs v2 (obsolete) — Splinter Review
This patch restores deb uploads for maemo4 work.  The issue with the previous patch is that I was using the default glob list from MobileBuildFactory in mobile_master.py instead of the default glob list from MaemoBuildFactory.

this change doesn't require explicit retesting imo as the scp command is being constructed properly using the list that I did provide.  the issue was that the list was incomplete. but....

I have also enabled debs for Maemo5 GTK builds in this patch as this is a desired thing.  I am going to be retesting this patch as I do not know for sure that non-xulrunner fennec builds work on making debs.
Attachment #435210 - Attachment is obsolete: true
Attachment #435244 - Flags: review?(aki)
Attachment #435210 - Flags: review?(aki)
Attached patch buildbotcustom (obsolete) — Splinter Review
v2 has required changes
Attachment #435084 - Attachment is obsolete: true
Attachment #435245 - Flags: review?(aki)
Attachment #435084 - Flags: review?(aki)
Attachment #435245 - Flags: review?(aki) → review+
Comment on attachment 435244 [details] [diff] [review]
buildbot-configs v2

>+        maemo5['enable_multi_locale'] = False

We're going to want multi_locale on soon.
However, if you want to do that as a next step (since l10n has been bumped to q2) that's fine with me.

>+            maemo5['glob_list'] = ['dist/*.tar.']

Should be dist/*.tar.* or it'll break.

>+            maemo5['glob_list'] = ['dist/*.tar.']

I somehow find it hard to believe that you made the same error in emacs twice ;-)

Anyway, r=me with the glob_list fixed in both production and staging.
Attachment #435244 - Flags: review?(aki) → review+
(In reply to comment #55)
> (From update of attachment 435244 [details] [diff] [review])
> >+        maemo5['enable_multi_locale'] = False
> 
> We're going to want multi_locale on soon.
> However, if you want to do that as a next step (since l10n has been bumped to
> q2) that's fine with me.
> 
> >+            maemo5['glob_list'] = ['dist/*.tar.']
> 
> Should be dist/*.tar.* or it'll break.
> 
> >+            maemo5['glob_list'] = ['dist/*.tar.']
> 
> I somehow find it hard to believe that you made the same error in emacs twice
> ;-)

yah, i made the mistake once, then copy/pasted it ;)

> 
> Anyway, r=me with the glob_list fixed in both production and staging.

yay! already fixed
For Qt:

http://people.mozilla.org/~jford/n900-test-builds/qt/fennec-1.1a2pre.en-US.linux-gnueabi-arm.tar.gz

This above build worked (ignoring a code problem) on the PR1.2 ROM.
As noted in IRC today, Doug has said that the scratchbox that I have been testing with is valid as far as he can tell for gtk and qt builds.  The issues with the builds I gave to Doug last week resembled an issue with scratchbox qt library versions not matching the qt library version on device.  After futher testing, Doug feels confident that this scratchbox is safe to deploy.

Doug also mentioned that we are not currently sure what our status of n900 v1.1 compatibility but that is something we can look at later.  This would only be a concern for GTK builds as QT builds will not work without a rom update.  As nokia does not offer a way to install only the 1.0 rom-compatible development environment I am going to guess that the binaries will work.
Doug, as I understand from past conversations, we do not want to do mozilla-1.9.2 qt builds.

As I have my patch now, We will have the following new builds with FREMANTLE sdk:
mozilla-central/mobile-browser   - gtk -standard gtk mozconfig
mozilla-central/mobile-browser   - qt  -standard qt mozconfig
lorentz/mobile-browser           - gtk -standard gtk mozconfig
lorentz/mobile-browser           - qt  -standard qt mozconfig
addonsmgr/mobile-browser         - gtk -standard gtk mozconfig
addonsmgr/mobile-browser         - qt  -standard qt mozconfig
tracemonkey/mobile-browser       - gtk -standard gtk mozconfig
tracemonkey/mobile-browser       - qt  -standard qt mozconfig
electrolysis/e10s-mobile-browser - gtk -e10s gtk mozconfig
electrolysis/e10s-mobile-browser - qt  -e10s gtk mozconfig

If this is not correct, please let me know as soon as possible.
e10s-mobile-browser should read users/pavlov_mozilla.com/mobile-e10s

As confirmed with Doug on IRC, this is the list of platforms/toolkits I will enable (same as above minus lorentz-qt). 

mozilla-central/mobile-browser   - gtk -standard gtk mozconfig
mozilla-central/mobile-browser   - qt  -standard qt mozconfig
lorentz/mobile-browser           - gtk -standard gtk mozconfig
addonsmgr/mobile-browser         - gtk -standard gtk mozconfig
addonsmgr/mobile-browser         - qt  -standard qt mozconfig
tracemonkey/mobile-browser       - gtk -standard gtk mozconfig
tracemonkey/mobile-browser       - qt  -standard qt mozconfig
electrolysis/mobile-e10s         - gtk -e10s gtk mozconfig
electrolysis/mobile-e10s         - qt  -e10s gtk mozconfig
Comment on attachment 435754 [details] [diff] [review]
proper mozconfig fixes for mobile-e10s

r=me if you get prod too.
Attachment #435754 - Flags: review?(aki) → review+
Stuart has confirmed in IRC that we do not need lorentz builds on mobile at all.

That leaves us with 

mozilla-central/mobile-browser   - gtk -standard gtk mozconfig
mozilla-central/mobile-browser   - qt  -standard qt mozconfig
addonsmgr/mobile-browser         - gtk -standard gtk mozconfig
addonsmgr/mobile-browser         - qt  -standard qt mozconfig
tracemonkey/mobile-browser       - gtk -standard gtk mozconfig
tracemonkey/mobile-browser       - qt  -standard qt mozconfig
electrolysis/mobile-e10s         - gtk -e10s gtk mozconfig
electrolysis/mobile-e10s         - qt  -e10s gtk mozconfig
I just noticed that i left GTK 1.9.2 builds were off the list.  Do we want GTK 1.9.2 builds on maemo5?
No longer depends on: 489410
Updated, unbitrotted.
Attachment #435244 - Attachment is obsolete: true
Attachment #435799 - Flags: review?(aki)
Updated, unbitrotted.
Attachment #435245 - Attachment is obsolete: true
Attachment #435800 - Flags: review?(aki)
Benjamin, There are currently maemo4 builds on the lorentz branch, but as of comment 64 maemo5 gtk/qt builds on lorentz are not planned.

Is this ok?  Do we need to do Maemo4 builds on the lorentz branch either?
Comment on attachment 435799 [details] [diff] [review]
buildbot-configs v3

>+    for branch in MOBILE_BRANCHES.keys():
>+        if 'lorentz' in branch:
>+                continue

Could you double check if addonsmgr should also be a continue?

Other than that, I had some *extremely* minor whitespace nits that I might point out if this edit textarea were semi-80column-friendly, but I'm not even going to bother at this point.

So r=me if addonsmgr is set correctly.
Attachment #435799 - Flags: review?(aki) → review+
Attachment #435800 - Flags: review?(aki) → review+
(In reply to comment #65)
> I just noticed that i left GTK 1.9.2 builds were off the list.  Do we want GTK
> 1.9.2 builds on maemo5?

afaik, yes.  Feel free to doublecheck w/ #mobile.
Blocks: 555327
No longer blocks: 555327
Ok, this has landed and production-master02 is showing maemo 5 gtk and qt builders.  I have forced a dep build of each new type.
Attachment #435800 - Flags: checked-in+
this has landed and I have seen green builds on mozilla-central with GTK.  QT builds are red because of a code issue that Doug T has submitted a patch for.

I am holding off until I see a nightly before I mark as resolved->fixed
This landed with GTK and QT builds being generated.  We don't have debs being generated for QT builds (code issue, bug filed) and we won't have test runs for QT until we get a new firmware image.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Summary: Provide GTK builds for Maemo5 → Provide GTK and QT builds for Maemo5
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.