Re: Failure to generate beagle_sd.img using linaro-media-create
: Failed to fetch http://ports.ubuntu.com/dists/maverick/main/binary-armel/Packages.gz 404 Not Found W: Failed to fetch http://ports.ubuntu.com/dists/maverick/universe/binary-armel/Packages.gz 404 Not Found W: Failed to fetch http://ports.ubuntu.com/dists/maverick-security/main/binary-armel/Packages.gz 404 Not Found W: Failed to fetch http://ports.ubuntu.com/dists/maverick-security/universe/binary-armel/Packages.gz 404 Not Found W: Failed to fetch http://ports.ubuntu.com/dists/maverick-updates/main/binary-armel/Packages.gz 404 Not Found W: Failed to fetch http://ports.ubuntu.com/dists/maverick-updates/universe/binary-armel/Packages.gz 404 Not Found W: Failed to fetch http://ports.ubuntu.com/dists/maverick-proposed/main/binary-armel/Packages.gz 404 Not Found W: Failed to fetch http://ports.ubuntu.com/dists/maverick-proposed/universe/binary-armel/Packages.gz 404 Not Found E: Some index files failed to download, they have been ignored, or old ones used instead. Cleaning up .../bin/mv: cannot stat `/sbin/start-stop-daemon.REAL': No such file or directory proc umounted Traceback (most recent call last): File /usr/bin/linaro-media-create, line 202, in module verified_files, extract_kpkgs, *hwpacks) File /usr/lib/pymodules/python2.6/linaro_image_tools/media_create/chroot_utils.py, line 89, in install_hwpacks hwpack_force_yes or hwpack_verified) File /usr/lib/pymodules/python2.6/linaro_image_tools/media_create/chroot_utils.py, line 129, in install_hwpack cmd_runner.run(args, as_root=True, chroot=chroot_dir).wait() File /usr/lib/pymodules/python2.6/linaro_image_tools/cmd_runner.py, line 100, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_image_tools.cmd_runner.SubcommandNonZeroReturnValue: Sub process ['chroot', '/tmp/tmpaR5Ly6/rootfs/binary', 'linaro-hwpack-install', '--hwpack-version', '20101109-1', '--hwpack-arch', 'armel', '--hwpack-name', 'linaro-omap3', '/hwpack_linaro-omap3_20101109-1_armel_supported.tar.gz'] returned a non-zero value: 1 Regards, Amar Shankar DISCLAIMER: This email may contain confidential information and is intended only for the use of the specific individual(s) to which it is addressed. If you are not the intended recipient of this email, you are hereby notified that any unauthorized use, dissemination or copying of this email or the information contained in it or attached to it is strictly prohibited. If you received this message in error, please immediately notify the sender at Infotech and delete the original message. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Alexander Sack Director, Linaro Platform Engineering http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Failure to generate beagle_sd.img using linaro-media-create
On Tue, Feb 19, 2013 at 2:53 PM, James Tunnicliffe james.tunnicli...@linaro.org wrote: Good point! I would be pleasantly surprised if an image + hwpack from 2010 worked with our current tools. Actually, I am surprised if they do not work. Our official promise on lit has always been that: 1. all hwpacks and rootfs ever produced before a lmc release will work with that lmc 2. lmc will work well on most recent Ubuntu release as well as on all Ubuntu LTS still supported by Canonical So moving forward let's do this: + find out if latest lmc works with the hwpack/rootfs stuff above - maybe it is all good actually - the wiki instructions refer to an old lmc version. + ensure that we have hwpack rootfs version as old as the above in our CI + use this opportunity to review if our CI tests have other gaps that we need to fill to know whether we are green wrt 1. and 2. above + fix failures including removing online requirement when they come up. Guess a blueprint about lmc legacy support investigation and resurrection might be the way to go. Thanks! James On 19 February 2013 12:02, Alexander Sack a...@linaro.org wrote: Hmm. I think you are trying to install a very, very old hardware pack based off maverick - for which the ubuntu repositories have been deleted... You might have out of luck if that hwpack really needs packages from the archives, but if you are lucky it has everything it needs included and you might be able to hack around the fact that lmc bails out... CCing a few folks to see if they have an idea on how to hack/workaround. On Tue, Feb 19, 2013 at 6:31 AM, Amar Shankar amar.shan...@infotech-enterprises.com wrote: Hi All, I am trying to create beagle_sd.img for beagle board using linaro-media-create, by referring the procedure in http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=BeagleBoardPkg#How_to_build_UEFI_for_the_BeagleBoard But I am getting the below error. Could someone please help resolve the issue. kiran@kiran-desktop:~/beagle_image$ sudo linaro-media-create --image_file beagle_sd.img --dev beagle --binary linaro-m-headless-tar-20101101-0.tar.gz --hwpack hwpack_linaro-omap3_20101109-1_armel_supported.tar.gz /usr/lib/pymodules/python2.6/argparse.py:1576: DeprecationWarning: The version argument to ArgumentParser is deprecated. Please use add_argument(..., action='version', version=N, ...) instead instead, DeprecationWarning) Searching correct rootfs path Installing (linaro-hwpack-install) hwpack_linaro-omap3_20101109-1_armel_supported.tar.gz in target rootfs. Unpacking hardware pack ...Done Updating apt package lists ... Ign file: ./ Release.gpg Ign filetmp/tmp.PybN7nuXq3/unpacked/pkgs/ ./ Translation-en Ign file: ./ Release Ign file: ./ Packages Get:1 http://ppa.launchpad.net maverick Release.gpg [316B] Ign http://ppa.launchpad.net/linaro-maintainers/overlay/ubuntu/ maverick/main Translation-en Ign http://ports.ubuntu.com maverick Release.gpg Ign http://ports.ubuntu.com/ maverick/main Translation-en Ign http://ports.ubuntu.com/ maverick/universe Translation-en Ign http://ports.ubuntu.com maverick-security Release.gpg Ign http://ports.ubuntu.com/ maverick-security/main Translation-en Ign http://ports.ubuntu.com/ maverick-security/universe Translation-en Ign http://ports.ubuntu.com maverick-updates Release.gpg Ign http://ports.ubuntu.com/ maverick-updates/main Translation-en Ign http://ports.ubuntu.com/ maverick-updates/universe Translation-en Ign http://ports.ubuntu.com maverick-proposed Release.gpg Ign http://ports.ubuntu.com/ maverick-proposed/main Translation-en Get:2 http://ppa.launchpad.net maverick Release [9762B] Ign http://ports.ubuntu.com/ maverick-proposed/universe Translation-en Ign http://ports.ubuntu.com maverick Release Ign http://ports.ubuntu.com maverick-security Release Get:3 http://ppa.launchpad.net maverick/main armel Packages [11.7kB] Ign http://ports.ubuntu.com maverick-updates Release Ign http://ports.ubuntu.com maverick-proposed Release Ign http://ports.ubuntu.com maverick/main armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick/universe armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-security/main armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-security/universe armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-updates/main armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-updates/universe armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-proposed/main armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-proposed/universe armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick/main armel Packages Ign http://ports.ubuntu.com maverick/universe armel Packages Ign http://ports.ubuntu.com maverick-security/main armel Packages Ign http://ports.ubuntu.com maverick-security/universe armel Packages Ign http://ports.ubuntu.com
Re: Failure to generate beagle_sd.img using linaro-media-create
On Tue, Feb 19, 2013 at 6:03 PM, James Tunnicliffe james.tunnicli...@linaro.org wrote: On 19 February 2013 16:08, Alexander Sack a...@linaro.org wrote: On Tue, Feb 19, 2013 at 2:53 PM, James Tunnicliffe james.tunnicli...@linaro.org wrote: Good point! I would be pleasantly surprised if an image + hwpack from 2010 worked with our current tools. Actually, I am surprised if they do not work. Our official promise on lit has always been that: 1. all hwpacks and rootfs ever produced before a lmc release will work with that lmc 2. lmc will work well on most recent Ubuntu release as well as on all Ubuntu LTS still supported by Canonical So moving forward let's do this: + find out if latest lmc works with the hwpack/rootfs stuff above - maybe it is all good actually - the wiki instructions refer to an old lmc version. + ensure that we have hwpack rootfs version as old as the above in our CI + use this opportunity to review if our CI tests have other gaps that we need to fill to know whether we are green wrt 1. and 2. above + fix failures including removing online requirement when they come up. Guess a blueprint about lmc legacy support investigation and resurrection might be the way to go. Interesting. We have had a blueprint about dropping Hardware Pack v1 support ready to go for a while. There is a lot of if v1, else code in Linaro Image Tools that we would like to get rid of. In the original case we have an image based on an unsupported Ubuntu version, which no longer has packages on http://ports.ubuntu.com/dists/, so there is no way to support it since it can't be installed. It isn't useful to have non-functioning OS It's not a given thing that it can't be installed. Actually, except for corner cases ALL the bits you need should be in rootfs and hwpack combined. For me all hwpack/rootfs that don't have all the bits are actually BUGGY and I would like to kill online support from lmc just for the sake to ensure that our hwpacks/rootfs really have everything. binaries on releases.linaro.org, so we should either delete them/move them to an archive location or perhaps put them behind a warning page. We could use BUILDINFO.txt to implement the warning. That's an independent discussion. Right now LMC is buggy as it cannot install stuff without the upstream archives still being there. Let's fix that first and then go and talk about a policy how to phase out old stuff (even though right now I believe all releases should stay around forever). Our CI jobs for image tools only go back to Linaro 11.06. I don't know when our releases switched to use Ubuntu 11.04 but it would be around then. We could try going back further, but it may only get us 6 months of testing a release that very few people are using. Yes, please go back to the oldest we have, treat them as bugs and systematically discuss case by case if we really don't support it. Binaries from ports.ubuntu.com will vanish after their support window has expired, so it seems likely that 11.04 and 11.10 based images will be unusable in a years time. As from above: our hwpacks should have everything they need in them. If not, its a hwpack bug and we want to know about them (through lmc hwpack-create and create failing unless you pass --download-missing-anyway or something). James -- Alexander Sack Director, Linaro Platform Engineering http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Test Result Summary of Linaro 12.12 Release for Linux Linaro ubuntu Quantal.
On Thu, Dec 20, 2012 at 11:35 AM, Amit Kucheria amit.kuche...@linaro.org wrote: Hi Botao, 2. Samsung Origen + Linux Linaro Quantal (Column E): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEowNWhZRi1zbDNNVUw1amhXTUdPcVE#gid=1 Exactly same test result as last week: network connection is unavailable, reboot halt test failed.. Power Management test would hang system when run test cpuhotplug_02. PM-QA tests are documented here: https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts Are any bugs filed against the kernel or pm-qa after analysis of what is wrong? For all bugs, except a kernel hang/oops/panic, we should be able to establish a procedure that bugs get sanitized by distro engineers to rule out the majority of platform induced problems and give more details. However, we don't have strong kernel know how, so if we see a hang or oops, filing a but with clear instructions on how to reproduce it, is more or less where our ability to help debugging ends. We could try to make an even more minimal test case, but I would assume that in this case the unit tests in PMQA are minimal enough for you to act on? 3. TI Panda 4430 + Linux Linaro Quantal (Column E): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZkhrZ1VYUEg2LTlQZzR0RlhzM3c#gid=3 ARM DS-5 backs to work. All 3 tests, data streaming, remote SSH connection and on target application debug passed. Device Tree is unavailable, the directory /proc/device-tree is empty. A new issue here is power management test cpuhotplug_07 failed. However, this test passed on TI Panda 4460. Ditto. ___ linaro-release mailing list linaro-rele...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-release -- Alexander Sack Director, Linaro Platform Engineering http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] IPv6
OK, In general it feels like this is a bit lower priority than many other topics ... I propose: let's create a LAVA lab IPv6 support roadmap card where we collect the elements of IPv6 support. Milestone forecast for delivery would be April or May 2013 for now I guess. Anyone volunteers to create the roadmap card stub? On Tue, Dec 11, 2012 at 4:09 AM, Michael Hudson-Doyle michael.hud...@linaro.org wrote: Alexander Sack a...@linaro.org writes: On Mon, Dec 10, 2012 at 9:46 AM, Dave Pigott dave.pig...@linaro.org wrote: Hi all, I was just discussing IPv6 with Philip Colmer, our new IT Services Manager (cc'd on this mail), and it strikes me that we should at least be considering dual running at some point in the future, i.e. providing both v4 and v6. I'm not clear what the ramifications are, or as yet whether Zen will support it. Philip has experience with this, and seems to remember that Zen do support it, but I'll bang an e-mail out to them to check. The reason for this e-mail is to start a discussion as to whether we think it's worth raising a BP, or if we can ignore this issue. Thoughts, comments and brickbats welcome. I am quite sure that supporting IPv6 inside the LAVA lab is a worthwhile thing to do... What does this mean? FWIW, the ethernet interfaces on machines in the lab appear to have IPv6 addresses: eth0 Link encap:Ethernet HWaddr 68:b5:99:be:54:8c inet addr:192.168.1.10 Bcast:255.255.0.0 Mask:255.255.0.0 inet6 addr: fe80::6ab5:99ff:febe:548c/64 Scope:Link - HERE UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20176938 errors:0 dropped:0 overruns:0 frame:0 TX packets:37330059 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11878897411 (11.8 GB) TX bytes:50409227661 (50.4 GB) Interrupt:31 Memory:f800-f8012800 but I don't know if that means very much (I can't even get ping6 to talk to the address of eth0 on the host I'm running it on -- but I know very little about IPv6 in general). One thing that mybe we'll have to watch for is that until we have an IPv6 internet address we don't end up preferring records over A records when trying to connect to hosts that have both. Whether we need public IPv6 or not, I don't have any strong feelings. I see that IPv6 is probably modern; so if it comes more or less for free I would say: let's think through this, make a plan and decide. It seems Zen don't really support this yet. We can do 6in4/6to4 or whatever it's called if we want -- I guess the advantage of this would be being able to route to devices in the lab without having to bounce through linaro-gateway[0] but I don't know if that would be useful really[1]. [0] This is also a risk if we don't configure things correctly! We currently assume that various admin interfaces with weak passwords are not directly routeable. I presume that configuring this sort of thing is part of setting up 6in4 though. [1] The person doing the routing would need to have access to the IPv6 internet too presumably, which I certainly don't have currently. Cheers, mwh -- Alexander Sack Director, Linaro Platform Engineering http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] IPv6
On Mon, Dec 10, 2012 at 9:46 AM, Dave Pigott dave.pig...@linaro.org wrote: Hi all, I was just discussing IPv6 with Philip Colmer, our new IT Services Manager (cc'd on this mail), and it strikes me that we should at least be considering dual running at some point in the future, i.e. providing both v4 and v6. I'm not clear what the ramifications are, or as yet whether Zen will support it. Philip has experience with this, and seems to remember that Zen do support it, but I'll bang an e-mail out to them to check. The reason for this e-mail is to start a discussion as to whether we think it's worth raising a BP, or if we can ignore this issue. Thoughts, comments and brickbats welcome. I am quite sure that supporting IPv6 inside the LAVA lab is a worthwhile thing to do... Whether we need public IPv6 or not, I don't have any strong feelings. I see that IPv6 is probably modern; so if it comes more or less for free I would say: let's think through this, make a plan and decide. Thanks Dave ___ linaro-validation mailing list linaro-validat...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation -- Alexander Sack Director, Linaro Platform Engineering http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] LAVA: Jobs submitted to vexpress device type
could we keep deprecated backward compatibility mapping on LAVA side for a while? On Sep 24, 2012 10:01 AM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: Hello, On Mon, 24 Sep 2012 08:30:34 +0100 Dave Pigott dave.pig...@linaro.org wrote: Hi All, I notice that there are still some jobs being submitted to LAVA with the device-type vexpress. This device type is now deprecated and has been replaced by the more specific device type vexpress-a9. The jobs seem to be coming from CI and Android. Could someone amend these submissions? Tracked as https://bugs.launchpad.net/linaro-ci/+bug/1055354 (Critical). Thanks Dave -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-validation mailing list linaro-validat...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] LAVA: Jobs submitted to vexpress device type
On Mon, Sep 24, 2012 at 12:48 PM, Dave Pigott dave.pig...@linaro.org wrote: Unfortunately, not as easy as it sounds. We'd have to actually change the dispatcher to intercept submissions to vexpress, and then re-route them to vexpress-a9, because we can'\t have two device instances talking to the same device. I'll look into it, but it would be quite a nasty bodge. right. guess would justify an alias feature for device-types in LAVA framework before we can do that. For now let's move our builds over to use vexpress-a9 1. android-build should be fixed now (at least the code got submitted); if you still see it tomorrow let me know. 2. for ci.linaro.org I have to talk to fabo; will not bother him until he has worked around the android-build git timeout issues currently blocking release. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: how to update kernel image on panda board?
On Fri, Sep 7, 2012 at 11:47 AM, Viresh Kumar viresh.ku...@linaro.org wrote: Hi Guys, I have flashed my SD card with linaro-media-create with precise-devel and latest h/w pack (12.08) Now i have two requirements: - Always use my copy of devel instead of the new devel everytime from the latest release As i do install a lot of stuff on it. Will apt-get update would be enough to get the latest things from linaro? What do you install on top? We would like to deliver images that are best suited for direct use by our kernel engineers. Getting input on what is missing in developer image would be very helpful to improve the out of the box experience we deliver. Thanks! -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mumble server having issues?
On Wed, Jun 20, 2012 at 10:28 PM, Christian Robottom Reis k...@linaro.org wrote: On Wed, Jun 20, 2012 at 12:40:29PM -0700, John Stultz wrote: So I've been having trouble with the mumble server and the behavior is odd enough that I don't think its a problem just on my end. I'm seeing cases where: * Only one of two members in a room can hear me talk * One member could hear both parties talking * I can't hear either of them talk As well as other cases where neither parties can hear each other. In all the cases, my talk-indicator (the red lips) has been lighting up properly, but the other sides isn't (so its not just an audio playback issue on my side, my mumble client isn't getting any input from other members). I know Joey's out, but does anyone else have the ability to check in and debug the mumble server? I'll forward this on to the IS team to take a look into it. Has anyone else run into similar issues with Mumble? We experienced very odd issues (think similar to that) a few month back. I ended up asking IS to restart the server as noone was able to figure out what was going on and it helped :). Maybe worth a try. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Release 12.05 Postmortem Summary
On Wed, Jun 13, 2012 at 8:51 PM, David Zinman david.zin...@linaro.org wrote: Regretfully this summary is very late. The Linaro 12.05 delivery cycle was fast and furious with Connect Q2.12, end of quarter and delivery all occurring in the same week. During this 2012.05 Linaro Connect, much of the effort was focused on: * ARM big.LITTLE implementation and testing * Performance improvements * Linaro-linux baseline * Release process streamlining Delivery highlights can be seen at http://www.linaro.org/downloads/1205#tab1 Platform Blueprints The number of blueprints that missed the cycle: Android 18 out of 30 Developer Platform 6 out of 18 Infrastructure 5 out of 10 Lava 5 out of 18 Here, I am currently not sure what to do with those numbers. Basically, I am not so much worried about low/medium blueprints that didn't get delivered. Any way we could get those numbers broken down by priority? Or just a view on our delivery rates for essential and high blueprints? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: clone speed on jenkins
On Wed, May 23, 2012 at 11:30 PM, Michael Hudson-Doyle michael.hud...@linaro.org wrote: Alexander Sack a...@linaro.org writes: On Wed, May 23, 2012 at 8:37 AM, Deepti Kalakeri deepti.kalak...@linaro.org wrote: On Wed, May 23, 2012 at 4:17 AM, John Rigby john.ri...@linaro.org wrote: I believe from experience on a local host that having a precloned tree of for example current upstream linus on jenkins to use with --reference could be a huge win. We can discuss this in the kernel-ci session at connect. Yes, having a precloned repository on master would help the faster builds. CI Maintainers job https://ci.linaro.org/jenkins/view/Linux%20Maintainers/job/linux-maintainers-kernel_build-Andrey/ already makes use of this. We have a clone available on master @ http://ci.linaro.org/kernel_git_repo/kernel/linux.git. Please let me know your requirement so that I can make the improvements further if required. Right now you cannot access http://ci.linaro.org/kernel_git_repo/kernel/linux.git as it needs apache restart and I cannot do that instantly as there are jobs running on jenkins . I will fix it as soon as the jenkins have no further jobs running. --john remember that our http: proxy is set up in a way that it should not make much of a diff... The thing is that we have to transfer a complete linux tree to the slave node no matter what. One could make an AMI that contained some version of Linus tip that you could use with --reference. It's a bunch of work though, and larger AMIs are slower to boot so I don't know if it's worth persuing. Ack. I sent the same idea to Danilo etc. outside of the thread. I believe it makes sense, especially since we found that custom AMIs will be helpful and probably useful for other issues. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA android tests should be working again
On Thu, May 24, 2012 at 6:40 AM, Michael Hudson-Doyle michael.hud...@linaro.org wrote: As some of you know, we had a problem today which caused all android tests to fail in LAVA. This is now fixed (basically, the version of adb we had installed in the lab was too old), and if you need to you should be safe to resubmit your jobs now. Great. I guess this means we should resubmit our release candidate builds now? If that wasn't done yet, can someone of LAVA team provide a helping hand for that? If so, please ping me :). -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Lava images improvement idea
On Thu, May 24, 2012 at 2:26 PM, Loïc Minier loic.min...@linaro.org wrote: On Wed, May 23, 2012, Alexander Sack wrote: Assuming we want to do this, would we really make a -lava variant? Why not include the tests in the LEB directly? Android already ships the tests in the image, so it wouldn't be something entirely new. +1; the test helpers should just be installed by default; I don't think having separate -lava images is a good idea, it's a lot of maintenance and direct costs when we can do it directly in our main images for little overhead. Yeah I think one can even argue that this is in line with the LEB purpose of being a demo system. Some of the test helpers probably have some nice demo effects :). Anything we miss here? I guess we wouldn't need to prevent installing lava tests in general ... just ensure that all our main tests are installed by default. If noone sees a reason against it, let's start by adding the tests we recently identified as daily tests for Ubuntu LEBs to the seed and see what we get... -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: clone speed on jenkins
On Wed, May 23, 2012 at 8:37 AM, Deepti Kalakeri deepti.kalak...@linaro.org wrote: On Wed, May 23, 2012 at 4:17 AM, John Rigby john.ri...@linaro.org wrote: I believe from experience on a local host that having a precloned tree of for example current upstream linus on jenkins to use with --reference could be a huge win. We can discuss this in the kernel-ci session at connect. Yes, having a precloned repository on master would help the faster builds. CI Maintainers job https://ci.linaro.org/jenkins/view/Linux%20Maintainers/job/linux-maintainers-kernel_build-Andrey/ already makes use of this. We have a clone available on master @ http://ci.linaro.org/kernel_git_repo/kernel/linux.git. Please let me know your requirement so that I can make the improvements further if required. Right now you cannot access http://ci.linaro.org/kernel_git_repo/kernel/linux.git as it needs apache restart and I cannot do that instantly as there are jobs running on jenkins . I will fix it as soon as the jenkins have no further jobs running. --john remember that our http: proxy is set up in a way that it should not make much of a diff... The thing is that we have to transfer a complete linux tree to the slave node no matter what. Whether you --reference something on master or use the master hosted squid shouldn't make any significant net difference. So bottom line: I don't think you will win much, but I am happy to be proofen wrong. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: clone speed on jenkins
On Wed, May 23, 2012 at 5:03 PM, John Rigby john.ri...@linaro.org wrote: Lets discuss this next week. I understand your point about the squid proxy. Sounds good. Is there a particular session where this could fit in? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Lava images improvement idea
On Wed, May 23, 2012 at 6:21 PM, Marcin Juszkiewicz marcin.juszkiew...@linaro.org wrote: Hi LAVA is good for doing some tests but every time I use it I wonder why it is so slow. So I looked more at problem. Job which I started is going on pandaboard for 48 minutes already. So far it did nothing related with tests which I want to run. Instead if fetched some image, booted and started installing lot of Python packages... This got me to idea - why not make *-lava variants of images which would have all packages needed by LAVA infrastructure preinstalled? It would take some minutes of Jenkins but less then LAVA one probably. Especially when bigger set of jobs is to be run. FWIW, we had considered to do something similar to make big.LITTLE testing more convenient. So, I guess this is indeed a worthwhile idea to explore. Assuming we want to do this, would we really make a -lava variant? Why not include the tests in the LEB directly? Android already ships the tests in the image, so it wouldn't be something entirely new. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On Tue, May 22, 2012 at 8:10 AM, Deepti Kalakeri deepti.kalak...@linaro.org wrote: On Thu, May 17, 2012 at 8:29 PM, Andrey Konovalov andrey.konova...@linaro.org wrote: On 05/17/2012 06:40 PM, Andy Green wrote: On 17/05/12 17:41, Somebody in the thread at some point said: On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. What happened to this? I had some minor conflicts and build failures, so kept the updated tree locally for a while. linux-linaro hasn't changed for 4 weeks now, so our vexpress 'tracking' builds of Android and Ubuntu are in fact the same kernels as the 12.04 release. It doesn't matter as long as llct is moving - and it has been, Andrey is doing a really nice job. If we can get all the LTs to base on llct, and get all the important things standardized in llct, then everything will come right. Actually, it (not moving linux-linaro forward for too long) was my fault.. Have pushed to the linux-linaro some time ago (no Samsung LT topics added yet). BTW, for llct I've added the linux-linaro-core-tracking-v3.4-rc7 tag just in case the v3.4-rc7 tree is needed. As llct tip has moved beyond v3.4-rc7. Nobody cares that we glued a couple dozen patches from ARM LT on one other LT tree as a one-off. linux-linaro tree is used by some CI jobs. To have the 12.05 stuff being tested in LAVA and such, I should have updated the linux-linaro tree as early as possible. Should we stop to build linux-linaro and switch to llct or continue to build linux-linaro and include llct builds as well? llct is a convenience tag used by LTs that have their own tree. We always said we won't validate and test that alone also because it does not include enablement and testing/validating it properly is not possible. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Golly, is that the dual SD card you and David from tincantools have been working on?
On Tue, May 15, 2012 at 1:44 PM, Ramana Radhakrishnan ramana.radhakrish...@linaro.org wrote: On 15 May 2012 12:38, Loïc Minier loic.min...@linaro.org wrote: On Mon, May 14, 2012, Zach Pfeffer wrote: https://plus.google.com/u/0/104422661029399872488/posts/3KpdBSzW4FK awesome!! how expensive is it to build in the end? Will we build some for LAVA folks to play with? It sounds very nice and useful - but what is it and why is this so exciting :) ? I gave a bit background as a comment to my post: - https://plus.google.com/u/0/117775935412882278033/posts/8JTBhQSkUdS Basically a gadget that allows you to use one sd card shared by two computers. Power off computer A and computer B will see the sdcard. Power on computer A and sd card will get unplugged from computer B; computer A can use it exclusively until it gets powered off again. ... In short: good stuff ... -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On Fri, May 11, 2012 at 8:51 AM, Jon Medhurst (Tixy) t...@linaro.org wrote: On Fri, 2012-05-11 at 02:27 +0200, Alexander Sack wrote: On Fri, May 11, 2012 at 1:43 AM, Jon Medhurst (Tixy) t...@linaro.org wrote: On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If the current one performs best and is on a random HEAD commit, we certainly shouldn't wind it backwards to last -rc that performs worse just because that's easier to communicate. I agree, I wasn't envisioning winding backwards, more that we stop winding forwards at a chosen -rc, or stop merging topics on a Friday, bring the common tree up-to-date with the weekends Torvalds -rc, then build, test and fix this ready for Linaro RC on the Friday. I think we agree ... here is how I thought so far should linux-linaro could be driven forward: 1. we have an automated -tracking baseline running that always reflects how your topics look like on tip 2. linux-linaro moves forward on the day a new RC comes around. 3. linux-linaro will not wait for topics to be ready before doing the RC jump 4. in between RCs, we only move mainline on our linux-linaro release baseline forward if we see a working tracking build that wouldn't drop any topics that already made it into this RC cycle. I'm not sure this differs much from linux-linaro == last good automated -tracking baseline, which might be simpler to understand. But I thought linux-linaro was meant to be this tracking baseline anyway? It's a good rule of thumb ... however, in order to ensure that we will not be stuck with non-good builds forever, I was saying that we should move to next RCs and kill topics until we are good again :), while we would only move forward in between RCs if we don't need to drop topics in such a move. Does that explain the subtle difference better? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-build's are failing, we're on it...
On Fri, May 11, 2012 at 12:21 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Thu, May 10, 2012 at 1:20 PM, Christian Robottom Reis k...@linaro.org wrote: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. Well, just saying it's broken doesn't help much either. If you really want a better and more up-to-date place to show this info even IRC would be better. Is Twitter really that much better to inform us it's broken? I would have missed the news entirely, for one random data point. Better than email at least :-) While it it's useful, did it actually help you in any front? Twitter is the general place used by most of projects for status update, that's why I thought that it'd be the best way to go. I would have preferred to get a bit more context as well, but as kiko said, getting an notification is definitely better than nothing. Especially if you are in the mids of a firedrill you might not have the time to explain the context, nor might you understand whats going on at all etc. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: pointless mail, (was Re: android-build's are failing...)
On Fri, May 11, 2012 at 12:24 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Thu, May 10, 2012 at 1:37 PM, Wookey woo...@wookware.org wrote: +++ Christian Robottom Reis [2012-05-10 17:20 -0300]: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. I don't like subject-only content-free mails either, but this one wasn't entirely useless so I guess it's fair enough. Sure, I just think there are better places for it :-) Based on issues we had with LAVA and Jenkins at the previous cycle, if I had one email for every issue, I'd send at least 20 of them, which is useful but that still doesn't make me send them to the list.] Actually, I think LAVA outage was announced. I poked for getting more status updates, so more mails would have been great. Same goes for ci.linaro.org ... if our CI service used for everything but android is not available, I want to get a mail that this is the case. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On Fri, May 11, 2012 at 12:09 AM, Jon Medhurst (Tixy) t...@linaro.org wrote: On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote: Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. I may have misunderstood but Doesn't this mean on next Wednesday you be tracking Wednesdays tip, then on Thursdays move back in time to this Sundays rc7 release? Yeah, I wondered about the same. In general I am very suspicious if we say we would have to go back and feel we might duplicate work in a direction where we shouldn't invest... How bad is the tip revision you aim for Andrey? Maybe we can check how well that works and if there are problems collaboratively try to fix that with the goal to release from tip? e.g. with help from ARM and Samsung LT? Is that a bad idea? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: checksum file for LEB images
On Fri, Apr 20, 2012 at 4:33 AM, Akira Tsukamoto akira.tsukam...@linaro.org wrote: Hi, Currently Linaro is not providing checksum file for LEB images. For example, http://releases.linaro.org/12.**03/android/leb-panda/http://releases.linaro.org/12.03/android/leb-panda/ has MD5SUM files but it contains value for only boot.tar.bz2, system.tar.bz2 and userdata.tar.bz2. There is no equivalent for the most important file which is LEB image: panda-ics-gcc46-tilt-tracking-**blob.img.gz It would be more user friendly if we have md5 or sha1 checksum file for LEB image since not all people have good Internet connection and would likely to check integrity of large downloaded file after taking very long time. My preference of the name convention of the checksum file is: panda-ics-gcc46-tilt-tracking-**blob.img.gz - original binary image panda-ics-gcc46-tilt-tracking-**blob.img.gz.md5sum - md5sum hash file Yes, I agree that our prebuilt images should get checksums (both android and ubuntu) Looped in Andy and Fathi for that. They worked on this pretty pretty new distribution feature offered by platform. Thanks for your suggestion! I hope we might be able to do this manually for this month release (Fathi?); properly landing this in our automation infrastructure might take more than a couple of days and I wouldn't commit that we get there by 12.04 milestone. But let's see... -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Preliminary 12.04 linux-linaro kernel tree
On Thu, Apr 19, 2012 at 5:27 AM, Andy Green andy.gr...@linaro.org wrote: On 04/19/2012 08:53 AM, Somebody in the thread at some point said: OK, so this is a major change to what linux-linaro was before. While this is different, it's not entirely different from what we had before. The major change here is that we're accepting a broader range of topics, but in the end it'll also depend a lot on what is currently being worked on by each LT and WG. I think you find it will have been better to stick with generating a separate flavouring tree without unification content, because you have created a chicken-and-egg situation now. I think that will depend a lot of the topic list and the respective content. While some topics are easy to identify as enablement, and with good possibilities to have conflicts or broken/bad solution, there's no simple way to classify topic types/groups. In the past we also wanted to publish most branches we could at linux-linaro, even from all the LTs, but unfortunately that didn't happen as expected and we ended up just with core changes. I'm not sure I made the problem clear enough. If you guys decide to include CMA series try #999 in your combined tree, the LTs have to make sure their kernels work with CMA #999 before you can combine them. Because if LT#1 has CMA #1234 and LT#2 has CMA #4567, you can't combine them, they'll conflict all over with mutually exclusive resolutions. There's no way to solve the conflict that satisfies both kernels (and any on the CMA #999 you actually want). Bearing that in mind, the LTs need access to a flavouring tree with CMA #999 in it (along with any other mandatory series) beforehand so they can work on aligning and testing their kernel to your mandated version, so they will all offer kernels with CMA#999, and you can combine them and get them all coming on CMA #999. This kind of conflicts will for sure happen once we start merging topics from different LTs. I believe we just need to make a clear statement on how we're planning to deal with conflicts, and how the LTs can use the current linux-linaro as based when checking for such conflicts, problems. It's not hard to solve - just publish the flavouring tree, it anyway exists as part of Andrey's flow. I talked to Andy and I agree that pushing the state of our linux-linaro tree _after_ the WG topics were merged but _before_ all the LT topics go in as a mandatory branch would offer a nice option to consume just our core subset of changes. So far I thought the topics alone would be good enough, but I understand the value of having a one shot core tree for some of the participants in the linux-linaro effort. Also, I agree that we already have that state while merging topics anyway, so making that available should be really cheap - especially if we are OK that that mandatory branch (linux-linaro-tracking-core) will not be validated and released independently, but only be made available to make consuming our linaro core kernel work easier. Andy and me seem to be aligned on that point and there was agreement that validating just the core set without enablement wouldn't be expected. Ultimately I like the idea of establishing all or a subset of WG topics as the linaro mandatory set that the LTs have to converge around... this includes making decisions on what CMA version everybody should use. With that I would say: let's do it. Andrey/Ricardo: do you agree? Can we make such a linux-linaro-tracking-core branch (and a tag accordingly) available that basically reflects the state we have after merging WG topics and before LT topics? At best we could sneak that service in for todays release candidate? Happy to talk offline if there are questions/doubts etc. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Preliminary 12.04 linux-linaro kernel tree
On Thu, Apr 19, 2012 at 4:21 PM, Andrey Konovalov andrey.konova...@linaro.org wrote: On 04/19/2012 03:07 PM, Alexander Sack wrote: On Thu, Apr 19, 2012 at 5:27 AM, Andy Green andy.gr...@linaro.org mailto:andy.gr...@linaro.org** wrote: On 04/19/2012 08:53 AM, Somebody in the thread at some point said: OK, so this is a major change to what linux-linaro was before. While this is different, it's not entirely different from what we had before. The major change here is that we're accepting a broader range of topics, but in the end it'll also depend a lot on what is currently being worked on by each LT and WG. I think you find it will have been better to stick with generating a separate flavouring tree without unification content, because you have created a chicken-and-egg situation now. I think that will depend a lot of the topic list and the respective content. While some topics are easy to identify as enablement, and with good possibilities to have conflicts or broken/bad solution, there's no simple way to classify topic types/groups. In the past we also wanted to publish most branches we could at linux-linaro, even from all the LTs, but unfortunately that didn't happen as expected and we ended up just with core changes. I'm not sure I made the problem clear enough. If you guys decide to include CMA series try #999 in your combined tree, the LTs have to make sure their kernels work with CMA #999 before you can combine them. Because if LT#1 has CMA #1234 and LT#2 has CMA #4567, you can't combine them, they'll conflict all over with mutually exclusive resolutions. There's no way to solve the conflict that satisfies both kernels (and any on the CMA #999 you actually want). Bearing that in mind, the LTs need access to a flavouring tree with CMA #999 in it (along with any other mandatory series) beforehand so they can work on aligning and testing their kernel to your mandated version, so they will all offer kernels with CMA#999, and you can combine them and get them all coming on CMA #999. This kind of conflicts will for sure happen once we start merging topics from different LTs. I believe we just need to make a clear statement on how we're planning to deal with conflicts, and how the LTs can use the current linux-linaro as based when checking for such conflicts, problems. It's not hard to solve - just publish the flavouring tree, it anyway exists as part of Andrey's flow. That's why I've changed the topics merge order last night: On 04/19/2012 12:22 AM, Andrey Konovalov wrote: Changes to the previous version: * topics merge order changed: generic topics first, LT's topics last: I talked to Andy and I agree that pushing the state of our linux-linaro tree _after_ the WG topics were merged but _before_ all the LT topics go in as a mandatory branch would offer a nice option to consume just our core subset of changes. So far I thought the topics alone would be good enough, but I understand the value of having a one shot core tree for some of the participants in the linux-linaro effort. Also, I agree that we already have that state while merging topics anyway, so making that available should be really cheap - especially if we are OK that that mandatory branch (linux-linaro-tracking-core) will not be validated and released independently, but only be made available to make consuming our linaro core kernel work easier. Andy and me seem to be aligned on that point and there was agreement that validating just the core set without enablement wouldn't be expected. Ultimately I like the idea of establishing all or a subset of WG topics as the linaro mandatory set that the LTs have to converge around... this includes making decisions on what CMA version everybody should use. With that I would say: let's do it. Andrey/Ricardo: do you agree? Can we make such a linux-linaro-tracking-core branch (and a tag accordingly) available that basically reflects the state we have after merging WG topics and before LT topics? Sure :) With just one difference probably. Shouldn't this linux-linaro-tracking-core branch be mainline tip based, not just the most recent -rc? (So it would be the real tracking tree.) I also planned to have a linux-linaro-tracking branch to be exactly the same linux-linaro-tracking-core branch plus the current LT's topics for the next linux-linaro release. The linux-linaro-tracking* branches would be for new work being done (like moving to new CMA version), while the linux-linaro branch would be used mostly for testing and bug fixing. When we see that the linux-linaro-tracking is good enough, we move linux-linaro to it (rebasing to the nearest -rc if necessary). This implies that two versions of the topics must be supported: the current
Re: Preliminary 12.04 linux-linaro kernel tree
On Wed, Apr 18, 2012 at 3:04 AM, Andy Green andy.gr...@linaro.org wrote: On 04/18/2012 06:16 AM, Somebody in the thread at some point said: Hi - I've pushed the current linux-linaro tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch. This is still work in progress, and it misses few topics. But due to limited access to hardware at the moment it would be good to try it sooner than later on vexpress and origen at least. (I have only panda on hand). Minimal boot test has been passed on the panda, though I had to disable CPUFREQ for the board to boot (haven't looked deeper yet). Not included are the following topics present in the 12.03 release: * tracking-linaro_cpuidle: there are conflicts when rebasing it to v3.4-rc3. The topic owner has been notified, and should tell me how to proceed. * tracking-umm-3.3-wip: this one seems to be in v3.4-rc3 mainline tree, correct? * tracking-linaro-android-3.4: I've tried it with a smaller subset of the topics (w/o LT's ones), and it merged ok, but there are some conflicts with the LT's stuff as it seems. Will have a deeper look tomorrow. No action from John is required at the moment. Here is the list of the topic included into this tree currently: # integration name base topic1 topic2 ... topicN # - the merge order is topic1 to topicN. integration linux-linaro v3.4-rc3 ufs emmc thermal_exynos4_imx6 linaro-configs-3.4 armlt-hdlcd armlt-mmc armlt-arm-arch-fixes armlt-misc-fixes armlt-ubuntu-config armlt-android-config armlt-gator samslt-base samslt-core samslt-bl samslt-dt samslt-fb samslt-pd samslt-rtc samslt-s2ram samslt-asv_cpufreq thermal_exynos4_imx6 samslt-led samslt-dummy_reg samslt-gadget samslt-touch samslt-wlan samslt-audio samslt-hdmi samslt-mali samslt-cma_v24 unsorted Where the topics are: # topic local branch remote/branch topic base # - base must be another topic # Example1: tracking-armlt-gator lt_arm/tracking-armlt-gator #- missing topic base here assumes the mainline Linus tree. # # ARM LT topics: topic armlt-hdlcd lt_arm/tracking-armlt-hdlcd ... # Samsung LT topics: topic samslt-base lt_samsung/topic/base topic samslt-asv_cpufreq lt_samsung/topic/asv_cpufreq samslt-base ... What's the plan for this new linux-linaro approach of putting LT trees in there? Previously, until 3.2 when I tried to change base to it anyway, linux-linaro was like flavouring, it had a bunch of goodies we could add to our vanilla LT trees and we got Has it changed approach to be the combined tree now? So there is no longer a flavouring tree we can use to get the goodies from without having to deal with an increasing number of LT trees merged as well? (Or if it changed name to another branch, fine, but what is it) If so that will make things complicated to synchronize the LT trees you intend to bind here, to ensure they're all working with same UMM revision you mandate, etc before the binding. linux-linaro combines all topics that are registered and in our manifest. We don't restrict ourselves to non-enablement topics. Actually, we always wanted enablement to be part of it and since we want to learn what that means we decided to pick up a few pilot enablement topics. I guess the pure WG flavored tree you are looking for is not produced in a direct manner, but you can probably just pull in the topics from our linux-linaro manifest by stripping the other LT topics. Andrey will also produce a pinned manifest that gives you concrete info which commit from the individual topic branches got merged into the linux-linaro tree. This should make it feasible to extract just the subset you care about. On the general point of conflicts through putting multiple hw enablement together: We have discussed a feature of conflicting topics that would mitigate the problem by producing a tree for each topic that has conflicts that leaves out the conflicting topics. At this point in time, we cannot handle conflicting topics yet ... our tools have to get in shape for that first and we expect to be closer to such a point by Connect. Last: ultimately we hope that putting things together will ensure that we figure out how to stay aligned and non conflicting. I think it's an important exercise to go through and learn from. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
On Wed, Apr 18, 2012 at 7:45 PM, David Rusling david.rusl...@linaro.orgwrote: Hmmm.I prefer Kiko's topics, these can also be grouped under the TL's. Each time we've tried this, we've ended up with WG / team driven tracks as before... where are kikos topics? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Getting from a CI report to a hardware pack
On Sat, Apr 14, 2012 at 2:41 PM, Christian Robottom Reis k...@linaro.orgwrote: I think there's a standard link missing from CI pages such as https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ to the output directory at http://snapshots.linaro.org/kernel-hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ Is that right? For some background, we got this inquiry on IRC: slado rsalveti: are there prebuilt linaro kernels for ubuntu that have hdmi fixes described in bug 919378? I went to look at the bug and then figured the latest CI build might have the code included. Indeed it does: https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/4/changes#detail2 However, I couldn't find a way of getting the binary generated from the build, and had to actually use my rapidly deteriorating memory to get to snapshots.linaro.org, where I had to also go through a confusing set of directories to get to what I think is the actual build. We don't export the .deb package itself. What we export is the complete hwpack for such pure upstream CI jobs: http://ci.linaro.org/kernel_hwpack/(in this case: http://ci.linaro.org/kernel_hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/) ... can you find that build there? (I don't know about the retention policy on that place atm.) Short term I see two things that would be really important: 1. a really easy to find link to the LAVA job submitted 2. good display of the meta information of the build/lava job submitted which would include the link to the hwpack (as that is what is passed to LAVA as one artifact) as well as information about the git source and commit (and we could make a link to gitweb out of it when visualizing this job). Ultimately, we want to have a way to have all meta-information for all steps of a CI job nicely visualized (e.g. automerging, auto buiding, validating, etc.). Anyway, we should start thinking about visualizing CI jobs and make them navigatable soon. I don't want to see us making the mistake again to wait for a nice UI until all the plumming is done. That approach just leave lots of value on the floor! I am sure Andy, Ricardo and Danilo are already thinking about this though :). -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Getting from a CI report to a hardware pack
On Sat, Apr 14, 2012 at 4:29 PM, Alexander Sack a...@linaro.org wrote: On Sat, Apr 14, 2012 at 2:41 PM, Christian Robottom Reis k...@linaro.orgwrote: I think there's a standard link missing from CI pages such as https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ to the output directory at http://snapshots.linaro.org/kernel-hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ Is that right? For some background, we got this inquiry on IRC: slado rsalveti: are there prebuilt linaro kernels for ubuntu that have hdmi fixes described in bug 919378? I went to look at the bug and then figured the latest CI build might have the code included. Indeed it does: https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/4/changes#detail2 However, I couldn't find a way of getting the binary generated from the build, and had to actually use my rapidly deteriorating memory to get to snapshots.linaro.org, where I had to also go through a confusing set of directories to get to what I think is the actual build. We don't export the .deb package itself. What we export is the complete hwpack for such pure upstream CI jobs: http://ci.linaro.org/kernel_hwpack/ (in this case: http://ci.linaro.org/kernel_hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/) ... can you find that build there? (I don't know about the retention policy on that place atm.) And yes, this location is definitely not the real one: consider it an unofficial place until we have figured how we want to generally map the ci output into a reasonable snapshots hierarchy for ubuntu rootfs, hwpacks and hwpacks coming out of our mainline CI job types. BTW, this is already happening on the ubuntu rootfs/hwpack side: we are moving our rootfs production and hwpack production for our Ubuntu LEB to ci.linaro.org and as part of that I am sure we are inventing such a hierarchy mapping as we speak. I can imagine that whatever we do there for the official LEB hwpacks should be easily adaptable for our pure mainline focused CI jobs. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Call for testing Linaro Android 12.04 candidates
On Tue, Apr 10, 2012 at 6:56 PM, anmar.ou...@linaro.org anmar.ou...@linaro.org wrote: Hello Fathi: On 9 April 2012 11:15, Fathi Boudra fathi.bou...@linaro.org wrote: We have prepared Linaro Android 12.04 candidates. Spreadsheets have been updated. Please, run the tests that have a 'w' after them. Thanks! Testers, builds and spreadsheets Jon https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc46-armlt-stable-open-12.04-release/ https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadExQdHNxTnR5SFZCQzJnN1ZtQ2ZhWkE Amit Pundir has a VE board for exactly that reason so I suggest he is tasked with the testing next to the RTSM stuff as well. AFAIK, Amit Pundir is the ARM LT POC on the android team side and the main reason getting him the board was for that and not for testing. Jon: I am sure if you talk to Amit you can strike a deal with him to help you out on the weekly testing (e.g. every other week). -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: jenkins really broken right now
On Wed, Mar 28, 2012 at 01:05:21PM +0300, Paul Sokolovsky wrote: Hello, On Tue, 27 Mar 2012 17:06:53 -0600 John Rigby john.ri...@linaro.org wrote: On Tue, Mar 27, 2012 at 4:55 PM, Loïc Minier loic.min...@linaro.org wrote: On Tue, Mar 27, 2012, John Rigby wrote: Looks like initial git clones always fail. I tried a simple job that just trys to run git and it fails. Alexander noticed too; new ci.linaro.org setup was launching jobs which were actually pointing at old ci.linaro.org setup as web proxy. When the old instance was shut down, it exposed the problem. Problem is that new instance doesn't have squid installed/configured. We need to restore the config and any other missing bits. My jobs seem to be working again, I guess without the proxy for now but working none the less. Thanks to all for fixing this. Oh my, that's why I wanted Deepti to have another look before stopping the old instance. But as she went on a leave, I had a look myself, noted the squid difference and explicitly wrote it off as not in use. But well, new instance couldn't automatically use squid on the old - old had his IP/domain name changed, so stale config wouldn't explain it. I also thought that Loic might have restarted the old instance, bit it wasn't, so doesn't explain why builds went thru. So, maybe it's not squid after all. We'll be looking into the issue immediately. The builds went through _after_ i disabled the git proxy setting. Before that kernel_cloud builds failed after we shut down the old instance. -- Alexander Sack a...@linaro.org Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage and KVM
On Sun, Mar 4, 2012 at 11:02 PM, Michael Hope michael.h...@linaro.orgwrote: I'd like to have one KVM kernel image which is suitable for the real hardware host and the virtio based guest. The single zImage plus Device Tree work seem like a great way to do this. We're currently using the vexpress-a15 on a Fast Model as the host and a vexpress-a15 as the guest. Device Tree support is required to describe the virtio-mmio devices. As a bonus, the vexpress-a9 and vexpress-a15 are the same hardware with a different memory map and can help demonstrate the Device Tree support. What are the plans for single zImage? Where does the vexpress-a15 fit in with that? Could I bump it to the front of the list? single zImage is already used for describing our final goal of having a single zImage for all boards... I think there is some way to go for that (especially since we do not yet have a single source tree). For stuff that can be tweaked through DT right now, I don't see why we couldn't have a single zImage ... e.g. like in your case having ability to boot vexpress-a15 in two different setups through different device tree... Most likely would require some platform plumming to ship two or more DTs for one kernel. What do we need for that? I guess we need a way to have two different device trees produced into the same image/hwpack and make it easy to decide at deploy time what u-boot is supposed to select? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANN] Support for fetching build configs from git for Android Builds
On Mon, Feb 20, 2012 at 5:11 PM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: Hello, As the result of implementation of https://blueprints.launchpad.net/linaro-android-infrastructure/+spec/build-config-in-git, android-build.linaro.org now can indirectly fetch build config stored in a git repository. To achieve that, bootstrap config (as specified in android-build.linaro.org) should contain reference to config's repo/branch/file (configuration variables are modeled on the similar MANIFEST_* ones), e.g.: BUILD_CONFIG_REPO=git:// git.linaro.org/people/pfalcon/android/linaro/build-configs.git BUILD_CONFIG_BRANCH=masterhttp://git.linaro.org/people/pfalcon/android/linaro/build-configs.git%0ABUILD_CONFIG_BRANCH=master BUILD_CONFIG_FILENAME=panda-ics-gcc46-tilt-tracking-blob.conf http://android.git.linaro.org/gitweb?p=linaro/build-configs.git;a=summary was created to store configs for the official builds in the Gerrit tree. Sample job is available here: https://android-build.linaro.org/builds/~pfalcon/git-build-config/ (it uses personal repo as a test). That's a great feature ... I see a dev now could retrieve that config from git to then reproduce an exact build using the same configs and toolchain etc. What kind of tools can we offer to make that easy? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro blocking issue
Hi, the third way is to go to the keyserver.ubuntu.com website, search for your keyid and copy the key to a text file for import locally... 1. go to http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0xF1FCBACA7BE1F97B 2. copy the GPG block to a text file: key.txt 3. sudo apt-key add key.txt now things might work... On Thu, Feb 16, 2012 at 10:32 AM, Amit amit@tieto.com wrote: ** Hi Christian, I tried the alternative command, but I am getting error in that for connecting to the host. The error logs are as follows gpg: directory `/home/bagggami/.gnupg' created gpg: new configuration file `/home/bagggami/.gnupg/gpg.conf' created gpg: WARNING: options in `/home/bagggami/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/home/bagggami/.gnupg/secring.gpg' created gpg: keyring `/home/bagggami/.gnupg/pubring.gpg' created gpg: requesting key 7BE1F97B from hkp server keyserver.ubuntu.com gpgkeys: HTTP fetch error 7: couldn't connect to host gpg: no valid OpenPGP data found. gpg: Total number processed: 0 Can you tell me whats going wrong here. Regards, Amit Bag On 16/02/12 12:57, Christian Robottom Reis wrote: On Thu, Feb 16, 2012 at 12:49:21PM +0530, Amit wrote: I am not able to install any packages related to linaro for example when I tried that below command sudo add-apt-repository ppa:linaro-maintainers/toolchain I am getting error like Error readinghttps://launchpad.net/api/1.0/~linaro-maintainers/+archive/toolchain: https://launchpad.net/api/1.0/%7Elinaro-maintainers/+archive/toolchain: urlopen error [Errno 111] Connection refused But when I use a direct INTERNET connection without proxy its working fine. The problem you're running into is that add-apt-repository is fetching a GPG key from the Ubuntu keyserver, which is running on port 11371. You can indeed punch a hold in the firewall, but you can also just issue sudo gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 7BE1F97B since this is a one-time operation -- once the key is set up transferring packages is done over regular http. -- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Upcoming work view for individual engineers
On Fri, Feb 3, 2012 at 11:32 AM, Christian Robottom Reis k...@linaro.org wrote: On Wed, Feb 01, 2012 at 12:54:29PM -0300, Guilherme Salgado wrote: We're trying to make status.l.o more useful to engineers and the first thing we're planning to do is a new page listing the upcoming work assigned to a given person. I'm attaching a mockup of that view here and we'd like to know what you think of it... Do you think that would be useful to you? Is there any other information you'd like to see there, or maybe a different way to present/group them? Crazy idea to expand on: why not merge the p.l.o patch queues into the status.linaro.org view? Indeed an interesting idea. Let's add this to our status topics to be discussed at connect! -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Sources for 11.11 kernel release
On Wed, Jan 25, 2012 at 7:14 PM, Christian Robottom Reis k...@linaro.org wrote: On Tue, Jan 24, 2012 at 10:50:51AM -0500, Chris Lalancette wrote: 1) Attempt to reduce the number of trees on git.linaro.org. I understand that there is probably a lot going on, but the sheer number of trees makes it confusing. It might be a good idea to remove some of the very stale or no longer active trees. What do Deepak and Loďc think of this in general? I would propose to: * hide people/ trees and show them on people.git.linaro.org instead of main git.linaro.org. At best git:// urls would be valid still aftterwards * hide the android/ trees and don't show them anywhere else; keep git:// urls and/or http:// clone urls wprking too This would definitely air to breath and we can continue to improve things from there. 2) Document on the wiki where the releases are built from, so there is a running record per release Where would we record this, Deepak, Alexander, Loďc? I am thinking ... If it's about documenting released bits it's something that should come out of our release process. The release team can bring that together. For that the information needs to be shipped along- or inside the source artifact. As one example, ubuntu packages having a vcs-bzr field and a reasonable tagging/versioning scheme could probably work, but we have to look case by case. Where are we putting it? One place that comes to my mind is obviously the release wiki page: https://wiki.linaro.org/Cycles/1201/Release/? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Sources for 11.11 kernel release
On Fri, Jan 27, 2012 at 11:40 AM, Loïc Minier loic.min...@linaro.org wrote: On Fri, Jan 27, 2012, Alexander Sack wrote: * hide people/ trees and show them on people.git.linaro.org instead of main git.linaro.org. At best git:// urls would be valid still aftterwards * hide the android/ trees and don't show them anywhere else; keep git:// urls and/or http:// clone urls wprking too This would definitely air to breath and we can continue to improve things from there. The arago-project layout seems nicer, effectively just hiding subtrees Yeah. That makes sense. Happy if we get that. As one example, ubuntu packages having a vcs-bzr field and a reasonable tagging/versioning scheme could probably work, but we have to look case by case. Problem is that a Vcs-* field is not consistently applied :-/ Right. But I don't think it matters much, no?. Release Team will work with folks to sort out the details. And if they decide that release team will track Vcs- fields for mining the source info for ubuntu packages, we probably would ensure that it's consistently applied for the packages we care about :). Sometimes it's not set, or doesn't point at the right repo, or points at a repo with a special tree where people have to do magic to get things done. I see three main problems to solve: 1. How do I find the vcs component for this source component? 2. How can I hack on this tree and how does this tree work? 3. What trees/tags/components are in the LEB? Point 1. can be solved through the release team working with component owners and sourcing the location of the tree used to produce a component/package Point 2. can be solved by the tree owner through maintaining good documentation on the git repo main gitweb page that explains in simple instructions how things work. For example: a. how the trees are produced b. what tag/branch syntax rules apply c. how to hack and contribute to this tree d. how to participate in meetings where this baseline is on topic to discuss Point 3. could be addressed by providing an explicit list of integrated/improved components alongside the LEB (on top of the usual android repo info etc.) to make this easier. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Linaro kernel tree for A15 for daily builds
On Wed, Jan 25, 2012 at 9:33 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? We can do builds on ci.linaro.org - as soon as we have a branch/tag of a public git tree and a defconfig we would be ready to go. Might require a few minor tweaks if the LAVA job for A15 needs different input parameters, so if that's the case let Deepti and Danilo know about the details. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: DisableSuspend.apk
On Mon, Jan 16, 2012 at 12:45 PM, yong qin yongqin@linaro.org wrote: Hi, all The command below seems can also disable suspend. adb shell service call power 1 i32 26 this command only seems not works well. I write a shell script (see the attachment), and run it as following will disable the suspend: 1. execute the script 2. restart android 3. execute the script again I don't know why should execute twice, but doing twice do disable the suspend:( The shell service call power ... is probably just a runtime setting? so we have to run it on every boot, no? Can we add this to a generic place in lava-android-test (or dispatcher) to ensure we call this first thing every time when booting up a unit? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Architectures to support when releasing binaries
On Mon, Jan 16, 2012 at 3:32 AM, Michael Hope michael.h...@linaro.org wrote: Hi there. I have a style question. For the pre-built versions of gcc-linaro, should we release a i686 version that also runs on x86_64, or do separate i686 and x86_64 builds? If we do just an i686 version then: * There's less to test * There's one 'linux' binary so less confusion on what to download and a simpler download page * Most end users will already have the 32 bit libraries due to Skype or Flash but it has some downsides: * May not work 'out of the box' * Cryptic failures if you don't have the 32 bit libraries installed Can we improve error reporting for those? Or maybe shipping a check-install script that probes for proper 32-bit libs? * Some users can't install extra packages and may not be allowed the 32 bit libraries What libs are potentially missing? How many of those could get linked in statically? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: DisableSuspend.apk
On Mon, Jan 16, 2012 at 6:24 PM, Paul Larson paul.lar...@linaro.org wrote: The shell service call power ... is probably just a runtime setting? so we have to run it on every boot, no? Can we add this to a generic place in lava-android-test (or dispatcher) to ensure we call this first thing every time when booting up a unit? I shoved it temporarily into my dispatcher running locally. A better solution going forward is to probably allow for some board-defined extra setup steps that run right after boot. In this case, I also had to add a My understanding is that this is not a board specific feature and we have to disable suspend on all boards that run android in LAVA. It does work great though, and I'm able to keep the board up and running with it! Thanks for figuring this out Yongqin! cool... -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: lava-deployment-tool is now (also) on github
On Wed, Dec 7, 2011 at 9:15 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: Hi folks. So there's been some justified uproar about me moving some stuff to github without asking. I wanted to let you all know that we have a Linaro organization on github (ping danilos to get your github account included there). I've created the validation team there and allowed it to push/pull to https://github.com/Linaro/lava-deployment-tool I also have my own fork. LAVA is hosted on launchpad. unless you can convince the whole team to move everything to git, please don't do one man shows like this and put this to bzr as well... Thanks for applying common sense. On the question whether we have everything on git.linaro.org or if github.com/linaro is ok as well, we have not yet developed a strong feeling. Default is saying that it's odd that we do that. But stay tuned. Everybody: what are the benefits you see from github/Linaro versus using git.linaro.org? Happy to collect points on this one. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Phasing out Ubuntu packages for LAVA
On Tue, Dec 6, 2011 at 9:46 AM, Alexandros Frantzis alexandros.frant...@linaro.org wrote: On Tue, Dec 06, 2011 at 10:16:22AM +0200, Fathi Boudra wrote: The deployment of LAVA using Ubuntu packages is deprecated in favor of the dedicated LAVA deployment tool [1]. LAVA installation is tested and supported on Ubuntu host from version 10.10 to 11.10 (Maverick to Oneiric) [2]. From 11.12 cycle, the following conditions will be applied: * Linaro Validation PPA [3] won't be updated with latest LAVA releases. * Bugs affecting packages won't be fixed. We plan to provide LAVA deployment tool from Linaro Validation PPA. [1] http://launchpad.net/lava-deployment-tool [2] Ubuntu 10.04 LTS (Lucid) isn't supported due to a bug with upstart [3] http://launchpad.net/~linaro-validation/+archive/ppahttp://launchpad.net/%7Elinaro-validation/+archive/ppa Does this affect all LAVA packages (eg lava-test, lava-dashboard-tool), or just the ones pertaining to the server? I would hope that client side tools that have reached a certain degree of maturity (read: you don't need to SRU stuff to ubuntu released version regularly due to changes on server side) would be still be made available in packaging form. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Beagle will not go EOL in January! (Was: Re: [EOL] Request for End Of Life - Beagleboard and Beagleboard-xM)
Hi all, this mail did not follow the proper EOL process that is currently discussed. In particular, this notice should not have been send out without explaining and discussing our new (RFC) EOL that explicitly encourage community maintenance of boards first. So, please consider this mail void and stay tuned for future mails on this topic. To make things clear: this means that beagle will not go EOL in January. Sorry for any confusion and have a great christmas time and a happy new year. On Thu, Dec 1, 2011 at 8:14 PM, David Zinman david.zin...@linaro.orgwrote: A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware. The following conditions will be applied for the 2012.01 release cycle: * There will be no more LEB or Linaro Developer builds. * No more testing will be applied by Linaro to the boards at all, and no quality assurance will be performed. * No more bugs will be filed against these boards assigned to Linaro resources. * All currently filed bugs will be re-targeted to the appropriate community resource. * Landing team support is no longer needed or expected. * Linaro Release notes will no longer refer to Beagleboard. -- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Phasing out Ubuntu packages for LAVA
On Tue, Dec 6, 2011 at 3:24 PM, Paul Larson paul.lar...@linaro.org wrote: This mostly affects the server side components, yes. I'm open to the idea of continuing packages for the client-side tools, if it would be useful to others. At best we would continue packaging for the ubuntu development releases, but not need to do SRUs regularly to keep them working with new servers... you think that's possible to maintain at this point? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Proposal : New Linaro Desktop Wallpaper
On Fri, Dec 2, 2011 at 10:58 AM, Riku Voipio riku.voi...@linaro.org wrote: On 2 December 2011 00:56, Tom Gall tom.g...@linaro.org wrote: one of the blueprints we have for 11.12 is to modify the LEB/ALIP images so they include more linaro branding. A linaro wallpaper, maybe a linaro image as the system is booting, that kind of thing. And android images as well? I created it in gimp. http://people.linaro.org/~tgall/LinaroDesktop-1920x1080-1.png Cool. Perhaps antialising the Linaro logo would be a nice addition? Assuming it is not hard to do in gimp. 1. Looks good as a start. We can always improve from there. 2. For android I have this awesome idea to make an active wallpaper edition out of this ... kind of the green lines pumping a bit or having a few flaring dots moving through the background maze. Anyone in the android team knows how to do such an active wallpaper? How much effort is that? 3. And yes, having a cool bootscreen animation for android and ubuntu would be nice as well :). Note, that Steve had a branding effort on his plate, so please talk to him first before putting more effort into tuning these to avoid duplication... -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA validation status
On Fri, Nov 11, 2011 at 3:53 PM, Dave Pigott dave.pig...@linaro.org wrote: Hi Paul, On 11 Nov 2011, at 10:56, Paul Sokolovsky wrote: Hello Dave, On Fri, 11 Nov 2011 10:36:45 + Dave Pigott dave.pig...@linaro.org wrote: [] look and feel!), we're asking that you hold off submitting jobs to LAVA until we give the go-ahead. Hold-off as in please don't submit jobs now - they disrupt us, or if you submit now, be prepared to not get expected results? Mostly the first, in that we need a pipeline to be able to submit jobs and check them. Problem is that with CI we cannot really hold off submitting jobs because that happens ad-hoc when a build finishes. I understand the need to have a clean lab pipe. However, for that we need to work on a mechanism that allows you to put submitted jobs into a queue that isn't processed etc. Would also be useful to put jobs there during maintenance so the frontend doesn't fail submitting it's job. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [REMINDER] Jenkins and Ec2 plugin upgrade on Linaro CI [ ci.linaro.org]
Hi Deepti, On Tue, Oct 18, 2011 at 8:23 AM, Deepti Kalakeri deepti.kalak...@linaro.org wrote: Hello, This is a reminder note to inform that jenkins and Ec2 plugin on ci.linaro.org will be upgraded tomorrow UTC *06:00:00 a.m. Wednesday October 19, 2011*. Thanks for the reminder. Do you have an estimate on how long the ci.linaro.org will be down? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro-overlay: auto-serial-console clobbers bootup serial port configuration
Hi, On Fri, Oct 14, 2011 at 7:52 PM, Dave Martin dave.mar...@linaro.org wrote: Filing this bug report on linaro-dev for now, so I don't forget it. I can't figure out how to file a but against linaro-overlay on launchpad. (Any suggestions?) the overlay ppa is used for our ubuntu LEB effort. Bugs should go here: https://launchpad.net/linaro-ubuntu/+filebug -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Android Platform Team 2011-10-03 to 2011-10-09
On Thu, Oct 13, 2011 at 1:12 PM, Tony Mansson tony.mans...@linaro.orgwrote: * Strict-aliasing violations in 2.3.5 have been fixed. I remember that we disabled -Werror because of various issues ... with those strict-aliasing fixes, what is left before we can turn that on again? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: sneak preview of kernel ci views
On Thu, Oct 13, 2011 at 2:20 PM, Dave Martin dave.mar...@linaro.org wrote: On Thu, Oct 13, 2011 at 01:16:30PM +1300, Michael Hudson-Doyle wrote: Hi all, I've done a stealth deploy (stealth as in no links point to this page) of the first cut of the kernel ci view I've been working on: http://validation.linaro.org/lava-server/kernel-ci-views/index It's very much an alpha-style view at the moment -- in particular the computation of the new passes and failures is a bit wonky -- but I've been working away for a while on this and it seemed like time to actually get a live page out to the public and stop emailing screenshots to slightly randomly chosen people. If you see problems, you can file bugs at: https://bugs.launchpad.net/lava-kernel-ci-views or make more general comments here. What's there looks OK; I have a couple of suggestions, though: * Display the total number of tests, passes and failures as well as the delta. The delta is certainly useful and we should have it, but without the absolute numbers, misleading conclusions may be drawn about the health of a branch. lp:873292 * I think we should display the branch that was tested as well as the commit. This is valuable context, and there's no easy way to reconstruct it just from the commit. maybe lp:873294 * Link the branch and commit directly to gitweb (as discussed the the mail I sent a short time ago) -- this should be pretty easy; we just need a rule for manufacturing the appropriate web link per git server. created lp:873297 for this one. Filed a bunch more. Check: https://bugs.launchpad.net/lava-kernel-ci-views/ -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro CI hwpack name improvements
On Mon, Oct 10, 2011 at 4:41 PM, Dave Martin dave.mar...@linaro.org wrote: For convenience only, we can put the job name and build ID into the URL and/or the hwpack filename, and possibly in the hwpack metadata, but it's important to remember that this is only a convenience and is not the authoritative source of the information. Personally, I'd recommend not putting the ID in too many places -- we would just end having to many different mechanisms for querying it, instead of having just one, robust, mechanism. Thoughts? Right. All this is for convenience only! Personally I would like to be able to find the hwpack for a build easily by going to http://ci.linaro.org/kernel_hwpack/ and eyeballing the filenames/directories there. Currently you don't have a way to find out which job/tree the hwpack is coming from nor do you get any hint which build ID in that job to look at. So given all this, how about this scheme: http://ci.linaro.org/kernel_hwpack/$CI_JOBNAME/hwpack_linaro-panda_MMDD-HHMM.b$BUILD_NUMBER.tar.gz Example: http://ci.linaro.org/kernel_hwpack/linux-next_beagle-omap2plushttps://ci.linaro.org/jenkins/view/Linux%20Next%20CI%20Builds/job/linux-next_beagle-omap2plus/ /hwpack_linaro-panda_20110927-0545.b160.tar.gz would refer to the hwpack coming out of this build: - https://ci.linaro.org/jenkins/view/Linux%20Next%20CI%20Builds/job/linux-next_beagle-omap2plus/160/ Sounds good? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro CI hwpack name improvements
On Tue, Oct 11, 2011 at 3:42 PM, Dave Martin dave.mar...@linaro.org wrote: Also, what timezone is used to determine the date and time? I think we should use UTC, not any local timezone. agreed on the UTC time. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.10 image changes
On Tue, Oct 11, 2011 at 7:08 PM, Tom Gall tom.g...@linaro.org wrote: The change in format of the tarball also means that the rootfs tarballs will appear to be larger. Don't panic. Once installed with linaro-media-create the installed image sizes are close to what they were in natty. The reason for the extra size is live-build is putting a copy of all the installed .debs into the tarball. Is inclusion of .debs a wanted feature or a side-effect from the new live-build version? What's the expected average growth in size of the download artifacts? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro CI hwpack name improvements
On Mon, Oct 10, 2011 at 2:08 PM, Loïc Minier loic.min...@linaro.org wrote: On Mon, Oct 10, 2011, Deepti Kalakeri wrote: 1) The board on which the hwpack can be booted 2) The hwpack creation timestamp includes the date in mmdd format along with the time in hhmm format. The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack name ? Is there any other information you would like to include in the hwpack name ? Or do we need to continue with the current hwpack names ? We rarely use a defconfig alone; however in the case of kernel .debs, you should find the corresponding config under boot/config-`uname -r` in the .deb (dpkg-deb -x the kernel .deb to find the config). (note that in the case of kernel CI we currently use pure defconfig configurations) What I asked deepti to work on is to make the CI hwpacks exported through http://ci.linaro.org/kernel_hwpack/ to be better backtrack-able to the actual CI job they are coming from. Instead of exploding the hwpack name with more info, we could also introduce a new directory level in the kernel_hwpack directory like: kernel_hwpack/ci_job_name/HWPACK1,2,3 ... and then leave the hwpack names as they are now. Maybe improve the version to rather use the git describe version of the kernel tree and not the kind of meaningless timestamp. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Oneiric image directory on snapshots.linaro.org
On Thu, Oct 6, 2011 at 11:29 PM, Paul Larson paul.lar...@linaro.org wrote: I know this has come up before, but I'd like to raise it again: Is there any reason for the lack of consistency between directory layouts for: http://snapshots.linaro.org/oneiric/ vs. http://snapshots.linaro.org/11.05-daily/ Would it be possible to rename the oneiric directory to 11.11-daily and split the hwpacks off into a linaro-hwpacks directory like the 11.04 images? Also, keeping some kind of -oneiric or -11.11 on the image/hwpack dirs probably makes sense, but are we planning on changing anything after these become the default LEB images? So my take is that the term 11.05 11.11 and so on is legacy as we are on a monthly cadence without big/meta cycles. Also, it strikes me that we only use snapshots.linaro.org for ubuntu and I don't think we will move to a centralized hosting place for our various daily artifacts anytime soon. So here is what I propose: 1. move to ubuntu-build.linaro.org namespace for the ubuntu file hosting 2. use directory structure matching the project group names used on offspring.linaro.org; e.g. natty-hwpacks, natty-images, oneiric-hwpacks, oneiric-Images, etc. Thoughts? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Oneiric image directory on snapshots.linaro.org
On Fri, Oct 7, 2011 at 12:45 PM, Fathi Boudra fathi.bou...@linaro.orgwrote: On 7 October 2011 13:23, Alexander Sack a...@linaro.org wrote: On Thu, Oct 6, 2011 at 11:29 PM, Paul Larson paul.lar...@linaro.org wrote: I know this has come up before, but I'd like to raise it again: Is there any reason for the lack of consistency between directory layouts for: http://snapshots.linaro.org/oneiric/ vs. http://snapshots.linaro.org/11.05-daily/ Would it be possible to rename the oneiric directory to 11.11-daily and split the hwpacks off into a linaro-hwpacks directory like the 11.04 images? Also, keeping some kind of -oneiric or -11.11 on the image/hwpack dirs probably makes sense, but are we planning on changing anything after these become the default LEB images? So my take is that the term 11.05 11.11 and so on is legacy as we are on a monthly cadence without big/meta cycles. Also, it strikes me that we only use snapshots.linaro.org for ubuntu and I don't think we will move to a centralized hosting place for our various daily artifacts anytime soon. So here is what I propose: 1. move to ubuntu-build.linaro.org namespace for the ubuntu file hosting 2. use directory structure matching the project group names used on offspring.linaro.org; e.g. natty-hwpacks, natty-images, oneiric-hwpacks, oneiric-Images, etc. No objections. To illustrate: ubuntu-build.linaro.org `-- build |-- natty-hwpacks |-- natty-images |-- oneiric-hwpacks `-- oneiric-images on the same front I see we still redirect ubuntu-build to offspring ... can we flip that around? e.g. make offspring.l.o redirect to ubuntu-build? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announce: TILT tracking Androidization trees
On Tue, Oct 4, 2011 at 5:33 PM, Andy Green andy.gr...@linaro.org wrote: On 10/04/2011 10:36 PM, Somebody in the thread at some point said: Hi - The second branch is tilt-android-tracking. This is our main tracking branch tilt-tracking for Panda enablement we have been running for some months combined with linaro-androidization-__**tracking above. Sounds like an interesting approach to me. Will you try keep this running as a pilot for one linus head cycle? I think that would give us good initial data to decide how to do all this officially across the organization in future. Yes that's my plan. It should be at its worst after 3.1 release in terms of conflicts needing fixing for tracking, then at its worst around 3.2-rc7 or whatever when next common shows up in terms of refreshing against its 'upstream' so to speak. My experience with the TILT patchset and tracking suggests we can probably cope, but well we have to see what happens during that cycle. One thing that isn't entirely clear from what you describe is whether we would do the forward porting for new linus HEAD versions on our own or if we would wait until we get a first androidization from either google or our members? You're right it's a good question. What I have in mind is not to leave the patchset as the current pile of semi-history patches all intermingled but impose topic-branch ordering on them. So for example, I was quite surprised to see so many patches on net core subsystem, lots on net / wireless subsystem too all through the series. It would be interesting to re-order the patches so we had all the net core stuff in one layer, wireless-related stuff in another layer all together and so on, same way tilt-tracking is composed. We don't have to get OCD about it and do everything, we can have a topic at the end with stuff contaminated from all directions and leave it like it is for now. But I guess most patches will go into a topic if it is ordered correctly. Thats an interesting idea. We should not miss the opportunity to discuss the idea of reordering the patches with AOSP to see if they would be willing to take/collaborate on such an effort. Can you kick off such discussion on AOSP mailing lists? What is holding you back from using the build service atm? Nothing on our side, in fact I have requested it. It just needs somebody to cut-and-paste the panda-LEB XML and change the kernel branch name to 'tilt-android-tracking'. There was no ETA for it so I have rolled our own because I can't get official ones as it stands. Ongoing official Linaro ones will be very welcome. OK good. It's set up but we seem to have build issues; guess android team will fix that later today: https://android-build.linaro.org/builds/~linaro-android/tracking-panda/. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announce: TILT tracking Androidization trees
Hi Andy, On Tue, Oct 4, 2011 at 1:23 PM, Andy Green andy.gr...@linaro.org wrote: Hi - TI Landing Team has added a couple of new trees to our git repo over the weekend http://git.linaro.org/gitweb?**p=people/andygreen/kernel-** tilt.git;a=summaryhttp://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary Both of them track Linus HEAD, currently at 3.1-rc8. First is linaro-androidization-**tracking, this is Linus HEAD plus a set of Androidization patches formed from common-3.0 and common-3.1. common-3.1 you say?, yes, TI needed a tracking Androidization tree and have made their own public one using pieces from common-3.1. You can find TI's tree that was an ingredient in this here if you're interested, it's public http://git.omapzoom.org/?p=kernel/omap.http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-android-3.1 git;a=shortlog;h=refs/heads/p-android-3.1http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-android-3.1 Due to android.git.kernel.org down, AFAIK there's no public access to common-3.1 direct otherwise at the moment. So what's this tree good for? If you have a kernel for any arch or board that is based on Linus HEAD, 3.1-rc8 at the moment, you can merge or rebase a copy of it with linaro-androidization-tracking to create an Android version of the same kernel. That's very handy if you did your work to get stuff looking good on Vanilla Linus HEAD and don't want to repeat the effort to get the same features coming in an Android kernel. Until now there was no way to casually Androidize a Linus HEAD basis tree unless it happened common-3.x was tracking it, which it only does for a short period at the end. It meant that you had to use old release to start integrating and adding drivers for Android and backport from HEAD anything nice that was coming. Now with this tree, you can do your work on Linus HEAD and fork off working release trees when Linus HEAD goes through a release. This Androidization tree is generic and should be usable for any arch or board, there's nothing TI specific in there. Why then is TI Landing team announcing it / TI go to the effort of creating their original one we based off? Nobody else in Linaro wanted to do the work to create and maintain it, so we own it at the moment. We'll have to see how tough it is to keep tracking Linus HEAD through the post-release patchstorm but reviewing the Androidization patchset I'm cautiously optimistic. I don't have any connection to Google guys who are basically doing the same work on common-3.x, but it would be very cool to be able to cooperate with them on bringing this Androidization patchset forward for everyone's benefit. The second branch is tilt-android-tracking. This is our main tracking branch tilt-tracking for Panda enablement we have been running for some months combined with linaro-androidization-**tracking above. Sounds like an interesting approach to me. Will you try keep this running as a pilot for one linus head cycle? I think that would give us good initial data to decide how to do all this officially across the organization in future. One thing that isn't entirely clear from what you describe is whether we would do the forward porting for new linus HEAD versions on our own or if we would wait until we get a first androidization from either google or our members? This gets you an effective Panda enabled 3.1 preview kernel that we have had for a while on Vanilla also on Android in an ongoing way. Current status of it is + 1080p SGX acceleration - Suspend borked - WLAN borked But we only generated it Sunday, we are working on those issues now. Lastly TILT is also providing tracking versions of the Android autobuilt Panda-LEB tarballs that are ready to use. These are the Autobuilt tarballs with the kernel replaced with a tracking one by us. You can find them linked from our git repo in tilt-android-tracking column of the status table there. Mid term I would very much like to see those builds coming out of the android build system, going through LAVA, with results as part of our kernel CI in the dashboard and so on... What is holding you back from using the build service atm? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: BUGREPORTED work item state
On Mon, Oct 3, 2011 at 4:48 AM, Zach Pfeffer zach.pfef...@linaro.orgwrote: On 30 September 2011 13:22, Fathi Boudra fathi.bou...@linaro.org wrote: Hi Zach, I noticed that you introduced BUGREPORTED on Android blueprints for the work items. It raised a couple of questions: 1. what does BUGREPORTED means ? When David Zinmann and I were going through each WI and closing out 11.09, a few BPs were done, except for one or two issues. These issues were bugs, so instead of filing a new WI in 11.10 we just marked the WI as BUGREPORTED and linked the bug to the 11.09. BUGREPORTED seemed to unambiguously mark a hand off between the BP tracking and the bug system. 2. do we need to update https://wiki.linaro.org/Process/WorkItemsHowto#Work_items_in_the_whiteboard ? I think we should. BUGREPORTED seemed to fill a void as David and I were going through each item that the other fields didn't. For reference: TODO empty string, INPROGRESS Item is expected to be done by the end of the cycle INPROGRESS By default, this is an alias for TODO, but teams can choose to track it separately. BLOCKED Item is still expected to be done by end of cycle, but cannot move forward due to issues outside assignees control DONE POSTPONED POSTPONE item will not be done this cycle Do we really need this kind detail encoded in the the state of a WI itself? Alternatively, we could always add a comment to the white board to document what happened with POSTPONED work items. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Reboot not working with the newly built upstream custom kernel
On Wed, Sep 28, 2011 at 7:10 AM, Deepti Kalakeri deepti.kalak...@linaro.org wrote: Hello Paul, On Wed, Sep 28, 2011 at 7:05 AM, Paul Larson paul.lar...@linaro.orgwrote: Just out of curiosity, have you tried building an image locally using this hwpack and booting it? I have not tried this specifically, but I have tried other hwpacks coming out of the same job. Can you please try and report if this issue is reproducible locally? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Reboot not working with the newly built upstream custom kernel
On Wed, Sep 28, 2011 at 5:35 PM, Deepti Kalakeri deepti.kalak...@linaro.org wrote: On Wed, Sep 28, 2011 at 8:43 PM, Alexander Sack a...@linaro.org wrote: On Wed, Sep 28, 2011 at 7:10 AM, Deepti Kalakeri deepti.kalak...@linaro.org wrote: Hello Paul, On Wed, Sep 28, 2011 at 7:05 AM, Paul Larson paul.lar...@linaro.orgwrote: Just out of curiosity, have you tried building an image locally using this hwpack and booting it? I have not tried this specifically, but I have tried other hwpacks coming out of the same job. Can you please try and report if this issue is reproducible locally? Did you mean to say to use the hwpack and try to boot it locally on the board and verify if the reboot fails. If yes, then I have tested the hwpack locally. I created the SD image using the lmc and then booted the board with the image. Once the system was up and running I tried to reboot it. And it stalled at the error I pointed in the first mail. Right. that's a good confirm that this is a real bug/regression in the upstream kernel trees :). \o/ Deepak, where do we file/track such issues seen in the lab? Will you take this over from here? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.09 Release Candidate
On Tue, Sep 27, 2011 at 5:23 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hi Fathi, Sorry for the top post. Any specific reason why using the build from 0926 as the RC instead of 0927? This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release. Due to release manager timezone etc. we aim for cutting ready to RC images by 1600 UTC on Monday. Can't we do the base-files update on Friday. Are there any other packages like kernel that need more up-front integration time? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.09 Release Candidate
On Tue, Sep 27, 2011 at 9:23 AM, Fathi Boudra fathi.bou...@linaro.orgwrote: On 27 September 2011 09:59, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Tue, Sep 27, 2011 at 3:19 AM, Fathi Boudra fathi.bou...@linaro.org wrote: Hi Ricardo, On 27 September 2011 06:23, Ricardo Salveti ricardo.salv...@linaro.org wrote: Any specific reason why using the build from 0926 as the RC instead of 0927? According to the schedule, RC images are delivered 3 days before the release, Monday at 16:00 UTC. That's why for Linaro 11.09 RC, it's the the build 20110926. This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release. For your specific example, base-files should be updated on Thursday, with Linaro components release. This changes doesn't affect the testing. Don't know if updating it on thursday would be the best case, but sure, it can be done at least at friday. And it doesn't change the testing, but we need an image respin. IMO, we should stick to Monday for the RC images and call for testing. It gives 3 full days to collect the reports and fixes critical issues. Though, using autobuilt images isn't optimal. What about triggering a manual rebuild on Monday at 16:00 UTC to get the RC images? This way it gives some extra time for integration, but not a full day. Unfortunately, the schedule is tight on a monthly release cadence... so we don't have much flexibility. We could just have a build job scheduled at 16 UTC at offspring, so we avoid requiring manual builds. I believe this would be our best option (and it usually takes around 3 hours to build all images). sounds a good compromise. Then the other question is how are you tracking an image respin during the call for testing, as you're pointing the image links and not just the directory containing the images? An image respin is tracked with bugs and is handled by the release response team. The point of contacts are in charge of testing the new images. Sure, but I also believe we should have a better way to communicate the community and others about an image respin, so we avoid people testing the images provided by the call for testing email when another one is already available. I'll try to better communicate to our wider community on the testing progress on linaro-dev ml by doing follow-up on the call for testing mail. I got this idea to setup a linaro-release twitter/google+ feed to update folks about RC, release progress, critical bugs discovered during testing, respins etc. You would probably announce one time before release week on linaro-dev that detailed release updates go there there and folks can then opt-into following the release team. Next, we can also write a bot that auto posts respins during release week there. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Multimedia WG status report - wk38.2011 (20110919-20110923)
On Mon, Sep 26, 2011 at 2:56 PM, Dechesne, Nicolas n-deche...@ti.comwrote: On Mon, Sep 26, 2011 at 2:21 PM, Ilias Biris ilias.bi...@linaro.orgwrote: - UMM Camera Demo - https://linaro.papyrs.com/page/4156/MMWG2011-1/# - UCM for Android - https://linaro.papyrs.com/page/4157/MMWG2011-2/# how can we access this? i am asked for a login, not sure what to use. I think s/linaro/linaro-public/ and s/page/public/ So: https://linaro-public.papyrs.com/public/4156/MMWG2011-1/# https://linaro-public.papyrs.com/public/4157/MMWG2011-2/# -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [REMINDER] Linaro 11.09 release dates and deliveries
On Wed, Sep 21, 2011 at 12:31 AM, James Westby james.wes...@linaro.orgwrote: On Mon, 19 Sep 2011 10:03:08 +0300, Fathi Boudra fathi.bou...@linaro.org wrote: Hi, This is a mail sent to remind you the coming release dates: * Linaro 11.09 components release is September 22nd, 2011. * Platform Teams: [...] linaro-image-tools [...] Hi, Ricardo is currently working on https://blueprints.launchpad.net/linaro-ubuntu/+spec/hwpacks-v2-trasition targetting 11.09. This testing may uncover bugs in linaro-image-tools, and completing the transition would mean having a fixed linaro-image-tools released as part of 11.09. Given that we are two days away and don't have a complete set of tested hwpacks this may not make the release. Also, there is an implication for our infrastructure, as producing those hwpacks may require setting up new projects on ubuntu-build.linaro.org, or deploying a new version of linaro-image-tools to the slaves ( https://wiki.linaro.org/Platform/Infrastructure/NewOffspringBuildToolVersion ) which may be another step in getting hwpacks available and tested for the release. Therefore I request the release team to pay special attention to this interdependence and aid in getting a quality release out the door (without 16 hour working days :-) That may mean pushing off the transition to 11.10, but I will leave that up to you, Ricardo and Mattias to call based on the results of the testing. I would like to see this happening this month, but I don't want to see new builds for hwpacksv2 being set up during release week in offspring or after RC. That just calls for troubles and we have been through enough pain with offspring in the past releases that we know better. Ricardo, can we get those hwpackv2 trees and offspring builds setup today? This will give us time to work with james on getting those things sorted before he is on vacation and in time for RC. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: where is the graphics git ?
On Tue, Sep 20, 2011 at 9:35 AM, Patrik Ryd patrik@linaro.org wrote: Hi, If you are looking for any of the Android gits they have been moved to... http://android.git.linaro.org/gitweb Maybe we can change description of the android/ gits on git.linaro.org to read like MOVED: http://android.git.linaro.org;? Jello, would you have spotted that? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OpenMax survey presentation
Hi Benjamin, On Wed, Sep 14, 2011 at 9:48 AM, Benjamin Gaignard benjamin.gaign...@linaro.org wrote: Hi all, MMWG has done a survey about how OpenMax is used by SoC vendors. A presentation of this survey is now available here : https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs//OpenMaxIntegration?action=AttachFiledo=viewtarget=OpenMax_Survey.pdf This presentation will be shared with Khronos on September 19th. Thanks! Comments: + not sure, but maybe your findings could be summarized in a table/matrix that is visualiy easier to digest? + you mention that quirks are used a lot for different SoCs; for me this seems to indicate that is something that should get discussed/addressed eventually. Maybe giving overview of the quirks used and the why would help such discussion? + one review round by a native speaker to check language, grammar, etc. would be good -- Alexander Sack Technical Director, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 11.08 released
On Thu, Sep 8, 2011 at 1:05 PM, Christian Robottom Reis k...@linaro.orgwrote: On Wed, Sep 07, 2011 at 08:53:06AM +0300, Fathi Boudra wrote: http://www.linaro.org/downloads/ had received some lifting. It's still a work in progress but it should resolved some of the issue raised. Please, take a look. feedback is welcome. I know. The feedback I gave below was from the updated page, so it applies right now. ;-) Finally, can we please not have a dead Select a release... menuitem? It's trivial to leave selected in the menu the release currently being displayed. kiko: all the input provided to me has been forwarded and is being worked on -- including this. fabo: should we update the blueprint or add a new one to reflect the initial improvements we agreed with ian? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Non-FOSS license acceptance by robots
On Wed, Sep 7, 2011 at 3:48 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Wed, Sep 07, 2011 at 11:39:08AM +0200, Loïc Minier wrote: On Wed, Sep 07, 2011, Tony Mansson wrote: The Snowball s/w design team decided to use the debian mechanism for license acceptance of h/w-pack binaries, so there are pop-ups when you run Linaro-Media-Create. Is this a debconf note or prompt? When Validation creates new images all the time, the conscious action click through must be replaced by the conscious action I am the maintainer of this Validation farm, I hereby accept the license once and for all and from now on l-m-c will not pop up the licenses in any of *these* packages that are automatically installed in my lab. if it's debconf based, you want to preseed the debconf database with debconf-set-selections to set the relevant flag before installing the packages. Image creation tools could be patched to allow running a custom script before installing hwpacks; you would pass a script which would run debconf-set-selections. See also debconf-get-selections to dump your debconf question db. Then couldn't this preseeding operation be considered the conscious action? Much depends on exactly which legal department we are talking about... I agree that this is one way to lay it out. One thing discussed/requested was that for human users/engineers the decision about accepting a license is remembered on the host so they dont get asked for the next install. This would involve copying certain keys off the target after install and preseeding those next time you use lmc and we would have one solution suitable for humans and non-humans. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Non-FOSS license acceptance by robots
On Wed, Sep 7, 2011 at 11:39 AM, Loïc Minier loic.min...@linaro.org wrote: On Wed, Sep 07, 2011, Tony Mansson wrote: The Snowball s/w design team decided to use the debian mechanism for license acceptance of h/w-pack binaries, so there are pop-ups when you run Linaro-Media-Create. Is this a debconf note or prompt? When Validation creates new images all the time, the conscious action click through must be replaced by the conscious action I am the maintainer of this Validation farm, I hereby accept the license once and for all and from now on l-m-c will not pop up the licenses in any of *these* packages that are automatically installed in my lab. if it's debconf based, you want to preseed the debconf database with debconf-set-selections to set the relevant flag before installing the packages. Image creation tools could be patched to allow running a custom script before installing hwpacks; you would pass a script which would run debconf-set-selections. See also debconf-get-selections to dump your debconf question db. I think they might want the validation owner to explicitly/manual accept the license once instead of just hard coding accepting it in a script. I think one way to do that is to assume that the same license has been accepted on the control node manually by the admin and then lmc grows feature to preseed certain debconf keys on the target by taking their current values from the host machine. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Releasing Linaro-patched repo tool, was: Re: Tracking Android kernel tips and Android builds
On Tue, Sep 6, 2011 at 4:25 PM, Fathi Boudra fathi.bou...@linaro.orgwrote: On 6 September 2011 08:28, Fathi Boudra fathi.bou...@linaro.org wrote: On 6 September 2011 00:15, Alexander Sack a...@linaro.org wrote: On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: On Mon, 5 Sep 2011 14:36:48 +0300 Paul Sokolovsky paul.sokolov...@linaro.org wrote: Ok, patched repo is available as: http://android.git.linaro.org/gitweb?p=tools/repo.git;a=blob_plain;f=repo;hb=refs/heads/linaro-stable that file should be downloaded and named as repo. Apparently, it should be mirrored at download servers. Right. where shall we put it? i think for AOSP you get it from an android.git.k.o URL. do we want to do something equivalent (e.g. android.git.l.o) or just put it on releases.linaro.org? It should be treated as a released components: releases.l.o, update release wiki/website download links. If it could be provided as upstream does (on android.git.l.o), +1. the patched version is available on: http://releases.linaro.org/platform/linaro-n/android/11.08/repo/repo-linaro-1.7.5-2011.08.tar.bz2 http://launchpad.net/linaro-android/11.11/11.08/+download/repo-linaro-1.7.5-2011.08.tar.bz2 and linked from: http://www.linaro.org/downloads/ http://wiki.linaro.org/Cycles/1108/Release#Android_Components hmm. the AOSP repo can be wgetted without unpacking ...you basically just download the lightweight wrapper script instead of a tarball. IMO we should offer the same on top of the whole tarball as a component. Also this is not a 1108 component. it's 11.09 if anything. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Releasing Linaro-patched repo tool, was: Re: Tracking Android kernel tips and Android builds
On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: On Mon, 5 Sep 2011 14:36:48 +0300 Paul Sokolovsky paul.sokolov...@linaro.org wrote: Ok, patched repo is available as: http://android.git.linaro.org/gitweb?p=tools/repo.git;a=blob_plain;f=repo;hb=refs/heads/linaro-stable that file should be downloaded and named as repo. Apparently, it should be mirrored at download servers. Right. where shall we put it? i think for AOSP you get it from an android.git.k.o URL. do we want to do something equivalent (e.g. android.git.l.o) or just put it on releases.linaro.org? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Code review request.
On Fri, Sep 2, 2011 at 2:06 PM, Vishal Bhoj vishal.b...@linaro.org wrote: Hi, Bluetooth is working now on pandaboard now.I could scan and pair with my phone.I have not tried file transfer yet. Thats really great news Vishal. Well done! These are multiple commits to gerrit to enable single feature i.e bluetooth on pandaboard. I had question, Can we commit multiple projects into gerrit in a single commit so that review would be easy ? I thought thats possible. Now waiting for an answer as well :) -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Tracking Android kernel tips and Android builds
On Thu, Sep 1, 2011 at 1:05 PM, Christian Robottom Reis k...@linaro.orgwrote: On Wed, Aug 31, 2011 at 02:19:08PM +0300, Paul Sokolovsky wrote: Hello Christian, On Tue, 30 Aug 2011 12:43:40 -0300 Christian Robottom Reis k...@linaro.org wrote: On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote: Yeah, I have patch for that. But we cannot use before upstream accepts it (because people will get errors checking out tree) and I don't hold my breath for that at all. Why wouldn't we provide our own version of repo that worked around this issue? By the same reason we don't fork entire Android itself and fixing it to work right? ;-) Either I'm missing the point or you are. We fork Android and everything else all the time; we then proceed to send the patches upstream and help them through the process, and so for me the fork is more like a cooperative branch. Look, this is a weird conversation and I want to get out of it as soon as I can. But you guys are overblowing the issue -- I'm just suggesting that if the patch will take a while to go upstream, you can ship a separate repo tool. We do this all the time in Linaro (just look at www.linaro.org/downloads). I agree with kiko here. If the repo patch would have a clearer indication in gerrit by now that this is not acceptable upstream I would have agreed to think about a solution on the git branch policy side. But if the lack of --tag hurts us now badly we should work around somehow by patching repo etc. until that patch discussion gives us more assurance that adopting everyone's workflow is not just for the sake of a temporary bandaid. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: edge.validation.linaro.org
On Wed, Aug 31, 2011 at 1:12 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: W dniu 31.08.2011 01:30, Alexander Sack pisze: On Tue, Aug 30, 2011 at 6:55 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: Hi there. The validation team has a new edge website, http://edge.validation.linaro. **org/http://edge.validation.**linaro.org/http://edge.validation.linaro.org/ that reflects the development trunk of all of our components. This site can be used to check latest development effort, test bug fixes and, to some degree, use new features. This website mimics the concept of now-defunct edge.launchpad.net. That is, it allows for new code to run on top of the production database. This has important ramifications: 1) Unsafe code could cause data loss 2) New features that depend on database schema modifications cannot be tested this way. 3) Non-website features such as dispatcher and part of the scheduler cannot be tested this way. For addressing those we will soon deploy staging.validation.linaro.**orgthat works on a periodic snapshot of the production database. I will be posting an update with instructions on how to replicate this setup if necessary and details about the periodic automatic roll out/upgrade procedure. Thanks for the heads up. I wonder, once we have staging.v.l.o, do we really need edge anymore? Perhaps not. We will see once we have both. What problems does edge protect us from that we really care about? Maybe we can avoid running 3 instead of two instances and have 3 instead of 2 code rollout stages? What do you mean by rollout stages? my understanding is that with staging and edge you have three rollout steps/stages: 1. daily trunk 2. edge testing 3. production i wondered about what risks the edge stage protects us from and if we can avoid that step as it comes with additional overhead on maintenance, process and time-to-production. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: CFP : Have a Beagle or Beagle XM with a USB wifi?
On Wed, Aug 31, 2011 at 7:56 PM, Tom Gall tom.g...@linaro.org wrote: What we want to do for the next linaro release 11.09 is have working USB wifi support out of the box on beagle/beagle xm with the developer image. Tho you won't have to twist my arm hard at all to include BT in that goal as well Tony :-) We like to keep the developer image as small as possible so the fun part is keeping this to the minimal number of packages to make it work. For wifi I BELIEVE we just need to add wireless-tools. WIFI without wpasupplicant is really incomplete in my terms. I don't think you get around including that if you want to claim wifi support. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: A really awesome job, thank you!
On Tue, Aug 30, 2011 at 6:57 PM, Zach Pfeffer zach.pfef...@linaro.orgwrote: I just wanted to make everyone aware of the fantastic job that the infrastructure team and the validation team are doing to ensure that our builds are extremely easy to use. With the inclusion of test results on the build page: https://android-build.linaro.org/builds/~linaro-android/panda/ yes, this looks very good!!! it was really an ambitious project and what came out is a neat pragmatic solution! Well done. Now on to populate lava with more useful android tests so that the test results become even more meaningful and reduce the amount of manual testing we have to do :). -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: edge.validation.linaro.org
On Tue, Aug 30, 2011 at 6:55 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: Hi there. The validation team has a new edge website, http://edge.validation.linaro. **org/ http://edge.validation.linaro.org/ that reflects the development trunk of all of our components. This site can be used to check latest development effort, test bug fixes and, to some degree, use new features. This website mimics the concept of now-defunct edge.launchpad.net. That is, it allows for new code to run on top of the production database. This has important ramifications: 1) Unsafe code could cause data loss 2) New features that depend on database schema modifications cannot be tested this way. 3) Non-website features such as dispatcher and part of the scheduler cannot be tested this way. For addressing those we will soon deploy staging.validation.linaro.orgthat works on a periodic snapshot of the production database. I will be posting an update with instructions on how to replicate this setup if necessary and details about the periodic automatic roll out/upgrade procedure. Thanks for the heads up. I wonder, once we have staging.v.l.o, do we really need edge anymore? What problems does edge protect us from that we really care about? Maybe we can avoid running 3 instead of two instances and have 3 instead of 2 code rollout stages? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Tracking Android kernel tips and Android builds
On Tue, Aug 30, 2011 at 12:46 PM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: On Mon, 29 Aug 2011 18:42:29 +0200 Alexander Sack a...@linaro.org wrote: On Mon, Aug 29, 2011 at 3:22 PM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: It's not enough if you still want to refer to it via SHA, due to repo peculiarities. It should be also reachable from one of the live branches (so, instead of a tag, a branch can be created right away). Paul, what happened to the repo patch we had that would also fetch tags? was that ever submit this to gerrit? on the mailing list we didn't receive any resistance to fix this. If its an easy landing upstream I would prefer that over adding create branch for everything policy. It waited its turn in queue. Well, now here it is: https://review.source.android.com/25843 fantastic! Seems it's going well so far. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Tracking Android kernel tips and Android builds
On Wed, Aug 31, 2011 at 2:09 AM, James Westby james.wes...@canonical.comwrote: On Tue, 30 Aug 2011 11:10:10 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: There's no reason to do it now, because its solving the wrong problem. The problem is sha's disappear. We use sha's because the provide immovable references to the state of a set of git trees so that people can reproduce builds exactly. We don't need the change to tag a build after its been deemed correct, we just need to implement a function to tag across the gits so that all the shas continue to exist. I'm sorry, but I'm not sure what course of action you are advocating here? It sounds like you are advocating using a model where we use tags to ensure that the referenced revisions are reachable from a head, and then refer to the sha ids of the revisions in the manifest. Is that correct? I think what he is saying is that everytime we produce a pinned-manifest.xml we would at best be able to prevent those revisions from getting garbage collected. I think thats a reasonable vision in general. My main concern to start with is about tag inflation. Is there a thing like a 'hidden' tag in git that would allow that folks looking at a tree to still spot the 'real' tags and only see all the pinned/manifest tags upon request? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.08 Pre-built Images
On Mon, Aug 29, 2011 at 9:56 AM, Jani Monoses j...@ubuntu.com wrote: Hello, On 08/26/2011 05:36 PM, Andy Doan wrote: The 11.08 release includes some commonly used pre-built images. This mean you can now download a single file and dd it to your SD card without having to use linaro-media-create. this is great. The images just use the l-m-c defaults. ie, there's no pre-built image that uses BTRFS. The downloads are: - Nano: http://releases.linaro.org/**images/linaro-n/nano/11.08/http://releases.linaro.org/images/linaro-n/nano/11.08/ - ALIP: http://releases.linaro.org/**images/linaro-n/alip/11.08/http://releases.linaro.org/images/linaro-n/alip/11.08/ - Ubuntu Desktop: http://releases.linaro.org/**images/linaro-n/ubuntu-**desktop/11.08/http://releases.linaro.org/images/linaro-n/ubuntu-desktop/11.08/ What kind of testing do the published images go through? Is there something like release candidates? we are mostly investing into automatic testing. Thats why we brought up lava. Nowadays, we have our images go through boot testing and we run a couple of benchmarks. More automation is planned and we are happy to have you help grow that test base. If you are interested in general or in a particular test area let me know. Anyway, before we release at the end of the month we have those images undergo some more manual testing. This is not super extensive, but besides checking that the general UI experience works, we go through a list of hardware features and note down if enablement of those is fine or missing. A slightly outdated list of the features we check is here: https://wiki.linaro.org/Platform/DevPlatform/BoardSupportStatus/ComponentTestCases -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Tracking Android kernel tips and Android builds
On Mon, Aug 29, 2011 at 3:22 PM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: It's not enough if you still want to refer to it via SHA, due to repo peculiarities. It should be also reachable from one of the live branches (so, instead of a tag, a branch can be created right away). Paul, what happened to the repo patch we had that would also fetch tags? was that ever submit this to gerrit? on the mailing list we didn't receive any resistance to fix this. If its an easy landing upstream I would prefer that over adding create branch for everything policy. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 11.08 released
On Fri, Aug 26, 2011 at 12:20 PM, Fathi Boudra fathi.bou...@linaro.orgwrote: Hi, On 26 August 2011 12:18, Dave Martin dave.mar...@linaro.org wrote: Hi there A few questions-- a) Is the omission of the Developers and Community Builds links from http://www.linaro.org/downloads/ intentional? Yes, it is. We made the choice to promote only the officially supported builds on the downloads page. Developers and Community Builds (DCBs) are not officially supported. the new download page will include the developer and community builds similar to the wiki page with a prominent warning. I anticipate that we get there in the next week or two. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 11.08 released
On Fri, Aug 26, 2011 at 12:20 PM, Fathi Boudra fathi.bou...@linaro.orgwrote: The wiki release page itself is not easily findable without going to the wiki. Really? It's clearly mentionned on the release announcement, posted on planet. Obviously, if somebody miss the announce and goes directly to the website downloads page, he won't get the DCBs. Is it your point? b) The release page on the wiki contains important information like the list of known issues.Shouldn't this page be linked from http://www.linaro.org/downloads/ or some other prominent location? It can probably be added to the block on the right. IMO the known issues are part of the release notes, I don't see them on the downloads page. new download page will be more release focussed and as that will also link to the release announce wiki. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ANN: ASTER - Android System Testing Environment and Runtime
Hi Jim, sounds interesting. Would be cool to have this integrated/available in linaro android. I guess this would help us design and execute testcases for android to be run in LAVA? wonder how much overlap this has with the testrunner framework discussed/developed in pauls team for android+lava. On Thu, Aug 25, 2011 at 2:56 PM, Jim Huang js...@0xlab.org wrote: Hello list, 0xlab announced the new system testing utility for Android. -- Forwarded message -- From: Kan-Ru Chen ka...@0xlab.org Date: 2011/8/24 Subject: [0xlab-discuss] [ANN] ASTER System Testing Environment and Runtime To: 0xlab-disc...@googlegroups.com Hi everyone, I am glad to announce our new project, ASTER System Testing Environment and Runtime, an automated functional testing tool. This is a tool aimed for testers, it includes an easy to use IDE for generating UI test cases and a script runner for batch running test cases. The tool is built upon the concept of Sikuli desktop automation tool and the Android monkey runner engine. We gave a talk at COSCUP[1] introducing this project and demonstrated the capability of the tool. You can grab the slides from here[2]. The project page is here[3] and you can also download the prebuilt preview binary at the download page[4]. The documentation is currently lacking but I hope the IDE is simple enough for everyone to figure out how to use it. In the other hand you always can checkout the source code and explore the underlying implementation. [1]: http://coscup.org/2011/en/ [2]: http://0xlab.org/~kanru/COSCUP_aster.svg [3]: https://code.google.com/p/aster [4]: https://code.google.com/p/aster/downloads/list Cheers, -- http://0xlab.org Kanru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 11.08 released
On Fri, Aug 26, 2011 at 2:17 PM, Amit Kucheria amit.kuche...@linaro.orgwrote: On Fri, Aug 26, 2011 at 3:07 PM, Fathi Boudra fathi.bou...@linaro.org wrote: It assumes you know l-m-b and know where/how to get it. At this point, you reached the step 3: step by step instructions to flash the board, including how to get the tools. True. I guess we'll reach a day where all that would be need is a pointer to L-M-B. It's already looking really useful. :) That would be fantastic, indeed!! -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Android Mainline Builds for Beagle/XM and Panda (Re: [CALL FOR TESTING] Linaro 11.08 Release Candidate (without QA Tracker!!!))
Hi, one thing this announce was not clear enough about was that - on top of our android LEB candidate builds - we provide Android MAINLINE builds for panda and beagle/XM. If you are interested in linaro android for beagle or panda running on top of linaro mainline focused kernel, please follow the instructions included in the developer/community feedback forms for beagle/XM and panda. (see below). On Tue, Aug 23, 2011 at 12:02 PM, Fathi Boudra fathi.bou...@linaro.orgwrote: Developers and Community Build == On top of our officially supported Linaro Evaluation Build candidate images from above, the Linaro Platform Team is proud to also provide additional images and additional board support bits that were prepared by Linaro developers and community for a more specific target audience. Note that the Developers and Community bits are provided on a best-effort basis and in the hope that they can be useful. We release last reported known to be working images. If you are interested in running Nano, ALIP or Developer image _or_ want to try our LEB on one of the board support packs maintained by our community, please help and test by following the download and installation instructions included in the questionaire linked from below your board: * BeagleBoard-xM: http://bit.ly/qzZz9U ... * PandaBoard: http://bit.ly/o3SjZJ -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: QA tests for Android
OK, I filled out the form based on Zach's input. One can go and see an example here: + https://docs.google.com/a/linaro.org/spreadsheet/viewform?hl=en_USformkey=dGhYQ3lwdzZvRHRSWDBoT1ZETVNtMlE6MA#gid=0 Next: to help testers we want to fill out https://wiki.linaro.org/Platform/Android/BoardSupportStatus/ComponentTestCaseswith details on what to do to test each feature. On Thu, Aug 18, 2011 at 12:32 PM, Alexander Sack a...@linaro.org wrote: what about usb device storage (e.g. mounting my phone sd from my computer)? similar I think usb also is supposed to work for tethering in android. On Wed, Aug 17, 2011 at 8:00 PM, Zach Pfeffer zach.pfef...@linaro.orgwrote: Sure. I didn't list it because Android doesn't really support generic USB (it will in Ice Cream Sandwich through a new USB device layer) Alexander, Would you add: * USB * Keyboard * Mouse On 17 August 2011 01:46, David Gilbert david.gilb...@linaro.org wrote: On 16 August 2011 23:09, Zach Pfeffer zach.pfef...@linaro.org wrote: Here's the proposed QA list. Comments and additions welcome. This list is based off the Ubuntu Origen list at: https://wiki.linaro.org/Cycles/1107/BoardSupportStatus/Samsung/Origen/Ubuntu Hi Zach, I don't see USB testing in general in there; I'd have USB keyboard/mouse as a basic test for boards that support it and I'd make sure I'd test that on all USB controllers on the board where the board has more than one. Dave -- - Alexander -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: issues benchmarking 11.08 toolchain
On Mon, Aug 22, 2011 at 10:47 PM, Alexander Sack a...@linaro.org wrote: That looks suspiciously close to the code that we patched out in platform a while back to get 4.5/4.6 going in external/elfcopy/: http://android.git.linaro.org/gitweb?p=platform/external/elfcopy.git;a=commitdiff;h=c13687fefcc8034de3c4d4a8cd02abdf96a951b4 This seems to be still used in our linaro_android_2.3.5 builds still. maybe the benchmark has a copy of that code and needs the same patch? or its pulling in external/elfcopy and just needs to pull the linaro_android_2.3.5 branch? turned out that benchmark.git has copies of soslim and elfcopy from a random AOSP eclair build that were build with an unpatched elfcopy.c. Replacing them with binaries from a fresh linaro build that has the patch from above applied makes this work again. Since we hit this problem with our platform builds earlier my guess would be that we just have been lucky when building benchmarks so far. andy will work around for now and will submit updated binaries to gerrit once release is out. On Mon, Aug 22, 2011 at 10:33 PM, Andy Doan andy.d...@linaro.org wrote: I'm hitting an issue building some of the tests in benchmark.git for this cycle. The python test is a good example: http://pastebin.com/e7XeLrMd: LINK SHARED LIBRARY: obj/libpython2.6.so obj/Modules/posixmodule.o: In function `posix_tempnam': /home/doanac/linaro/android/benchmarks/bmarks-bins-2011-08/linaro-4.6/benchmark/python/src/Modules/posixmodule.c:7167: warning: warning: tempnam() possibly used unsafely; consider using mkstemp() obj/Modules/posixmodule.o: In function `posix_tmpnam': /home/doanac/linaro/android/benchmarks/bmarks-bins-2011-08/linaro-4.6/benchmark/python/src/Modules/posixmodule.c:7214: warning: warning: tmpnam() possibly used unsafely; consider using mkstemp() MAP SHARED LIBRARY: out/SYMBOL/libpython2.6.so ASSERTION FAILURE external/elfcopy/elfcopy.c:2457: [!(shdr_info[sym-st_shndx].shdr.sh_flags SHF_ALLOC)] make: *** [out/SYMBOL/libpython2.6.so] Error 1 anyone have a workaround so I can complete the benchmarking? -andy -- - Alexander -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: QA tests for Android
On Mon, Aug 22, 2011 at 4:17 PM, Christian Robottom Reis k...@linaro.orgwrote: On Mon, Aug 22, 2011 at 02:03:45PM +0200, Alexander Sack wrote: I filled out the form based on Zach's input. One can go and see an example here: + https://docs.google.com/a/linaro.org/spreadsheet/viewform?hl=en_USformkey=dGhYQ3lwdzZvRHRSWDBoT1ZETVNtMlE6MA#gid=0 Next: to help testers we want to fill out https://wiki.linaro.org/Platform/Android/BoardSupportStatus/ComponentTestCaseswith details on what to do to test each feature. And link each section in the form to the appropriate test description? That would make the form even more useful. Good job! Is the intention to unforunately i didnt find a way to make a link there :/ ... happy about suggestions. include an updated header in the actual form? yes, we create an instance of the form for each concrete build we do a call for testing on. There the install instructions and urls in the header will be filled out to have all the right values. So tester just needs to copypaste for downloading and installing the build. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.08 Android toolchain RC is ready
On Sat, Aug 20, 2011 at 8:47 AM, Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote: Hi, the 11.08 Android toolchain RC is ready: https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.08/#build=6 https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-2011.08/6/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-6-2011-08-19_20-41-31-linux-x86.tar.bz2 The good news is that this build has been tested and seems to work fine for everything so far. This is remarkable Bernhard. Thanks for that! The bad news is that we did that by reverting the switch from the arm-eabi to the arm-linux-androideabi target, losing support for OpenMP and friends. My theory is that the combination of an That's OK! We have latest Linaro toolchain and afaik you also updated binutils and friends which might give us more goodies/optimizations on top of what we got from TCWG gcc update. Remember to talk to Andy about benchmarking these builds and maybe give some hints what he should pay extra attention to. arm-linux-androideabi toolchain and the mess in the Android build system that works around the toolchain not knowing anything about the OS simply don't go well together. We should investigate this further for the next release. ++ I agree that the magic they do for using bare-metal for whole platform might contribute to that. Another idea I had is that there seem to be two ways to build androideabi: one is the way we use; the other is to use the NDK method of building TC. Maybe we tried to use the wrong one? Other than that, this toolchain build seems to be ready for release. Let me know if you run into any problems. I kicked off a build for leb-panda and panda tip with the new toolchain to see if that succeeds in the validation lab. If that works I will move the release builds for panda and leb-panda as well. Unfortunately, beagle isn't really set up properly in the validation lab it seems; even deploy fails, look here: http://validation.linaro.org/lava-server/dashboard/streams/anonymous/android-daily/bundles/ddb00a2e971f96750664ce9752a2b12969d75525/56db8596-ca05-11e0-9729-68b599be548c/ And all other tip builds we run seem to be not hooked up with the lab (or dont have support in the lab yet). I will move those to new toolchain once I see green light on panda/leb-panda hoping that that means they won't regress. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.08 Android toolchain RC is ready
so following up: panda tip build succeeded and the android test results showed up as expected and all looks fine (manually eyeballed the serial.log and 0xbench results seem to show up nicely). here where the results show up: - android results: http://validation.linaro.org/lava-server/dashboard/reports/android-runs/ - panda result: http://validation.linaro.org/lava-server/dashboard/permalink/test-run/e843ef08-cb38-11e0-9729-68b599be548c/(for build https://android-build.linaro.org/jenkins/job/linaro-android_panda/237/) leb-panda succeeded build as well, I can also see that LAVA was run with it when going to the job ( http://validation.linaro.org/lava-server/scheduler/job/599) but I cannot figure what happened after that. Is there any way to find out what happened to that job (maybe serial.log for a scheduler job?)? - On Sat, Aug 20, 2011 at 8:47 AM, Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote: Hi, the 11.08 Android toolchain RC is ready: https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.08/#build=6 https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-2011.08/6/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-6-2011-08-19_20-41-31-linux-x86.tar.bz2 The good news is that this build has been tested and seems to work fine for everything so far. The bad news is that we did that by reverting the switch from the arm-eabi to the arm-linux-androideabi target, losing support for OpenMP and friends. My theory is that the combination of an arm-linux-androideabi toolchain and the mess in the Android build system that works around the toolchain not knowing anything about the OS simply don't go well together. We should investigate this further for the next release. Other than that, this toolchain build seems to be ready for release. Let me know if you run into any problems. ttyl bero -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.08 Android toolchain RC is ready
On Sat, Aug 20, 2011 at 7:32 PM, Alexander Sack a...@linaro.org wrote: so following up: panda tip build succeeded and the android test results showed up as expected and all looks fine (manually eyeballed the serial.log and 0xbench results seem to show up nicely). here where the results show up: - android results: http://validation.linaro.org/lava-server/dashboard/reports/android-runs/ - panda result: http://validation.linaro.org/lava-server/dashboard/permalink/test-run/e843ef08-cb38-11e0-9729-68b599be548c/(for build https://android-build.linaro.org/jenkins/job/linaro-android_panda/237/) leb-panda succeeded build as well, I can also see that LAVA was run with it when going to the job ( http://validation.linaro.org/lava-server/scheduler/job/599) but I cannot figure what happened after that. Is there any way to find out what happened to that job (maybe serial.log for a scheduler job?)? the fact that panda tip showed up as working in LAVA gave me enough comfort to move the panda 11.08-release builds to new toolchain as well. Builds will show up as: - https://android-build.linaro.org/builds/~linaro-android/panda-11.08-release/#4 - https://android-build.linaro.org/builds/~linaro-android/leb-panda-11.08-release/#4 Let's see if they get properly tested in lava etc. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: l-m-c: Increase default image size?
On Thu, Aug 18, 2011 at 3:56 PM, Dirk Behme dirk.be...@googlemail.comwrote: Using linaro-media-create (version linaro-image-tools_0.4.8-**0ubuntu1~lucid1_all) to create an image the default image size seems to be 2GB if no --image_size is given. this was mentioned in known issues section of july release. see https://wiki.linaro.org/Cycles/1107/Release#Known_Issues so seems that lp:813296 https://launchpad.net/bugs/813296 bug probably has good discussion on what is the plan here ;). -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announcement:Linaro Android 2.3.5
On Wed, Aug 17, 2011 at 1:40 PM, Christian Robottom Reis k...@linaro.orgwrote: On Wed, Aug 17, 2011 at 12:16:36PM +0300, Paul Sokolovsky wrote: On Wed, 17 Aug 2011 11:00:32 +0200 Patrik Ryd patrik@linaro.org wrote: Hi, Linaro Android has now moved up to 2.3.5. The daily builds (https://android-build.linaro.org/index) are now based on the linaro_android_2.3.5 branch of the manifest. Please rebase any dev_branches you have to 2.3.5. The linaro_android_2.3.4 branch will no longer be supported. And another quick reminder just in case somebody missed it before - Linaro Android tree has moved to http://android.git.linaro.org/ , so if you're still using old checkout, this is good timing to do fresh checkout for 2.3.5 upgrade. Will the old checkout break if you try and update it? If not, maybe we should make it break so people are aware of the tree moving around. yeah, we did that for a couple of days ( i think a week); at the point we said we probably catched most (important) consumers and decided to bring back the old URLs, to make instructions of past releases etc to work again. We will keep reminding in announcements for a while though. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro libjpeg-turbo roadmap
On Wed, Aug 10, 2011 at 3:45 PM, Tom Gall tom.g...@linaro.org wrote: Hi All, I thought I would clarify what is in store for the next few linaro cycles from a libjpeg-turbo perspective. 11.08 1.1.2 libjpeg-turbo (featuring cleaned up patches) upstreaming and support of what could be a late august upstream 1.2 release Does this involve adding easy/automatic benchmarks so we can track a) improvements turbo gives over plain and b) improvements we do to turbo over time? If not, I would very much like to see that that's part early phases of the plan. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro libjpeg-turbo roadmap
On Wed, Aug 10, 2011 at 4:18 PM, Tom Gall tom.g...@linaro.org wrote: On Wed, Aug 10, 2011 at 9:05 AM, Alexander Sack a...@linaro.org wrote: On Wed, Aug 10, 2011 at 3:45 PM, Tom Gall tom.g...@linaro.org wrote: Hi All, I thought I would clarify what is in store for the next few linaro cycles from a libjpeg-turbo perspective. 11.08 1.1.2 libjpeg-turbo (featuring cleaned up patches) upstreaming and support of what could be a late august upstream 1.2 release Does this involve adding easy/automatic benchmarks so we can track a) improvements turbo gives over plain and b) improvements we do to turbo over time? If not, I would very much like to see that that's part early phases of the plan. 1.1.1 includes in cjpeg and djpeg (encode and decode respectively) timing code for measurement. Make test also includes timing code. It's less than perfect but it's there. Upstream 1.2's make test is improved and more fleshed out. Could it be better? When can code never be improved or have more and better test? ;-) Cool. Is hooking this up into lava-test framework for daily runs in the lab part of the current plan? If not, could you try to include that somehow? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Why are our Android toolchains 32bit?
On Wed, Aug 10, 2011 at 4:29 PM, Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote: Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than we inherited it from AOSP)? While it doesn't matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly? If nobody complains, I'll remove the -m32 flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it... That's a good question. It was an explicit decision from the past as we said we don't want to deviate from AOSP best practices unless we have very good arguments. Also our binary toolchain will probably become more useful for 32-bit once we start talking about shipping NDK/SDK. Then, having just one binary to verify could turn out to be a smart thing. If you feel strongly this should be changed in future, let's discuss during this month so we can work eventual changes into our 11.09 plan preparations. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
