Closed
Bug 528431
Opened 15 years ago
Closed 14 years ago
Provide GTK and QT builds for Maemo5
Categories
(Release Engineering :: General, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dougt, Assigned: jhford)
References
Details
Attachments
(3 files, 5 obsolete files)
2.02 KB,
patch
|
mozilla
:
review+
|
Details | Diff | Splinter Review |
43.39 KB,
patch
|
mozilla
:
review+
jhford
:
checked-in+
|
Details | Diff | Splinter Review |
13.10 KB,
patch
|
mozilla
:
review+
jhford
:
checked-in+
|
Details | Diff | Splinter Review |
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
Comment 1•15 years ago
|
||
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.
Comment 3•15 years ago
|
||
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
Comment 5•15 years ago
|
||
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")
Reporter | ||
Comment 6•15 years ago
|
||
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.
Updated•14 years ago
|
Assignee: nobody → jhford
Component: Release Engineering: Future → Release Engineering
Summary: Provide builds/unittest/talos for Maemo5 ("QT") → Provide builds for Maemo5 ("QT")
Updated•14 years ago
|
Summary: Provide builds for Maemo5 ("QT") → Provide QT- and non-QT- builds for Maemo5
Reporter | ||
Comment 7•14 years ago
|
||
Update please?
Comment 8•14 years ago
|
||
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
Reporter | ||
Comment 9•14 years ago
|
||
Update please? ( I do not see it listed in the schedule )
Reporter | ||
Comment 10•14 years ago
|
||
Update please?
Assignee | ||
Comment 11•14 years ago
|
||
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.
Reporter | ||
Comment 12•14 years ago
|
||
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.
Assignee | ||
Comment 13•14 years ago
|
||
I am going to be working on this today.
Status: NEW → ASSIGNED
Priority: -- → P2
Assignee | ||
Comment 14•14 years ago
|
||
gah, my temporary vm was invalid. I am asking for it to be recreated
Blocks: 544042
Assignee | ||
Comment 15•14 years ago
|
||
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.
Reporter | ||
Comment 16•14 years ago
|
||
we should not need any.
Assignee | ||
Comment 17•14 years ago
|
||
(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
Reporter | ||
Comment 18•14 years ago
|
||
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!
Assignee | ||
Comment 19•14 years ago
|
||
it wasn't any of the libqt4-* packages, but their low level dependencies
Comment 20•14 years ago
|
||
there are libqt* packages 4.6.2 available in maemo extras-devel repository
Assignee | ||
Comment 21•14 years ago
|
||
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
Reporter | ||
Comment 22•14 years ago
|
||
I am not having this problem on my CentOS VM nor am I having it on Ubuntu 9.10 (yet).
Assignee | ||
Comment 23•14 years ago
|
||
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.
Assignee | ||
Comment 24•14 years ago
|
||
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.
Reporter | ||
Comment 25•14 years ago
|
||
(also looking to see if we can drop chinook and only support fremantle)
Comment 26•14 years ago
|
||
Not sure how that would work for repo updates, though we can possibly softlink or something.
Assignee | ||
Comment 27•14 years ago
|
||
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
Assignee | ||
Comment 28•14 years ago
|
||
Also, i am going to try |unset PYTHONPATH| before trying to install the sdk
Assignee | ||
Comment 29•14 years ago
|
||
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.
Assignee | ||
Comment 30•14 years ago
|
||
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
Assignee | ||
Comment 31•14 years ago
|
||
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 ]
Assignee | ||
Comment 32•14 years ago
|
||
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.
Assignee | ||
Comment 33•14 years ago
|
||
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!
Comment 34•14 years ago
|
||
Shouldn't that be /scratchbox/users/cltbld/builds/slave ? But, awesome!
Assignee | ||
Comment 35•14 years ago
|
||
(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?
Comment 36•14 years ago
|
||
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/
Assignee | ||
Comment 37•14 years ago
|
||
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
Reporter | ||
Comment 38•14 years ago
|
||
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.
Assignee | ||
Comment 39•14 years ago
|
||
(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.
Assignee | ||
Comment 40•14 years ago
|
||
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
Assignee | ||
Comment 41•14 years ago
|
||
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.
Assignee | ||
Comment 42•14 years ago
|
||
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.
Comment 43•14 years ago
|
||
(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.
Comment 44•14 years ago
|
||
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.
Assignee | ||
Comment 45•14 years ago
|
||
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
Assignee | ||
Comment 46•14 years ago
|
||
we need to run rm /tmp/cputransp_cltbld.log on the slave before we do any builds
Assignee | ||
Comment 47•14 years ago
|
||
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)
Assignee | ||
Comment 48•14 years ago
|
||
Buildbotcustom changes needed to make Maemo5 GTK + QT builds go.
Attachment #435084 -
Flags: review?(aki)
Comment 49•14 years ago
|
||
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 50•14 years ago
|
||
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.
Assignee | ||
Comment 51•14 years ago
|
||
(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.
Assignee | ||
Comment 52•14 years ago
|
||
unbitrot
Attachment #435083 -
Attachment is obsolete: true
Attachment #435210 -
Flags: review?(aki)
Attachment #435083 -
Flags: review?(aki)
Assignee | ||
Comment 53•14 years ago
|
||
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)
Assignee | ||
Comment 54•14 years ago
|
||
v2 has required changes
Attachment #435084 -
Attachment is obsolete: true
Attachment #435245 -
Flags: review?(aki)
Attachment #435084 -
Flags: review?(aki)
Updated•14 years ago
|
Attachment #435245 -
Flags: review?(aki) → review+
Comment 55•14 years ago
|
||
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+
Assignee | ||
Comment 56•14 years ago
|
||
(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
Reporter | ||
Comment 57•14 years ago
|
||
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.
Assignee | ||
Comment 58•14 years ago
|
||
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.
Assignee | ||
Comment 59•14 years ago
|
||
a sample electrolysis-qt4.6.2 build is up at http://people.mozilla.org/~jford/n900-test-builds/electrolysis-qt/fennec-1.1a2pre.en-US.linux-gnueabi-arm.tar.gz
Assignee | ||
Comment 60•14 years ago
|
||
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.
Assignee | ||
Comment 61•14 years ago
|
||
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
Assignee | ||
Comment 62•14 years ago
|
||
Attachment #435754 -
Flags: review?(aki)
Comment 63•14 years ago
|
||
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+
Assignee | ||
Comment 64•14 years ago
|
||
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
Assignee | ||
Comment 65•14 years ago
|
||
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?
Assignee | ||
Comment 66•14 years ago
|
||
Updated, unbitrotted.
Attachment #435244 -
Attachment is obsolete: true
Attachment #435799 -
Flags: review?(aki)
Assignee | ||
Comment 67•14 years ago
|
||
Updated, unbitrotted.
Attachment #435245 -
Attachment is obsolete: true
Attachment #435800 -
Flags: review?(aki)
Assignee | ||
Comment 68•14 years ago
|
||
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 69•14 years ago
|
||
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+
Updated•14 years ago
|
Attachment #435800 -
Flags: review?(aki) → review+
Comment 70•14 years ago
|
||
(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.
Assignee | ||
Comment 71•14 years ago
|
||
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.
Assignee | ||
Comment 72•14 years ago
|
||
Comment on attachment 435799 [details] [diff] [review] buildbot-configs v3 http://hg.mozilla.org/build/buildbot-configs/rev/c3728284bf88
Attachment #435799 -
Flags: checked-in+
Assignee | ||
Updated•14 years ago
|
Attachment #435800 -
Flags: checked-in+
Assignee | ||
Comment 73•14 years ago
|
||
Comment on attachment 435800 [details] [diff] [review] buildbotcustom v3 http://hg.mozilla.org/build/buildbotcustom/rev/bdebbdf1e60d
Assignee | ||
Comment 74•14 years ago
|
||
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
Assignee | ||
Comment 75•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Summary: Provide GTK builds for Maemo5 → Provide GTK and QT builds for Maemo5
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•