Re: Failure to generate beagle_sd.img using linaro-media-create

[Alexander Sack]

On Tue, Feb 19, 2013 at 6:03 PM, James Tunnicliffe
 wrote:
> On 19 February 2013 16:08, Alexander Sack  wrote:
>> On Tue, Feb 19, 2013 at 2:53 PM, James Tunnicliffe
>>  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: Failure to generate beagle_sd.img using linaro-media-create

[Alexander Sack]

On Tue, Feb 19, 2013 at 2:53 PM, James Tunnicliffe
 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  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
>>  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
&g

Re: Failure to generate beagle_sd.img using linaro-media-create

[Alexander Sack]

> Err http://ports.ubuntu.com maverick-updates/main armel Packages
> 404 Not Found
> Err http://ports.ubuntu.com maverick-updates/universe armel Packages
> 404 Not Found
> Err http://ports.ubuntu.com maverick-proposed/main armel Packages
> 404 Not Found
> Err http://ports.ubuntu.com maverick-proposed/universe armel Packages
> 404 Not Found
> Fetched 21.8kB in 2s (9070B/s)
> W: 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 
> 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: Test Result Summary of Linaro 12.12 Release for Linux Linaro ubuntu Quantal.

[Alexander Sack]

On Thu, Dec 20, 2012 at 11:35 AM, Amit Kucheria
 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

[Alexander Sack]

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
 wrote:
> Alexander Sack  writes:
>
>> On Mon, Dec 10, 2012 at 9:46 AM, Dave Pigott  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

[Alexander Sack]

On Mon, Dec 10, 2012 at 9:46 AM, Dave Pigott  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

[Alexander Sack]

On Mon, Sep 24, 2012 at 12:48 PM, Dave Pigott  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: [Linaro-validation] LAVA: Jobs submitted to vexpress device type

[Alexander Sack]

could we keep deprecated backward compatibility mapping on LAVA side for a
while?
On Sep 24, 2012 10:01 AM, "Paul Sokolovsky" 
wrote:

> Hello,
>
> On Mon, 24 Sep 2012 08:30:34 +0100
> Dave Pigott  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: how to update kernel image on panda board?

[Alexander Sack]

On Fri, Sep 7, 2012 at 11:47 AM, Viresh Kumar  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: New beta LAVA feature: filters and subscriptions

[Alexander Sack]

On Mon, Sep 3, 2012 at 7:12 AM, Michael Hudson-Doyle
 wrote:
> Hi all,
>
> I've just deployed a new feature for LAVA: the ability to filter and
> subscribe (by email) to test results.  You can see, define and
> subscribe to filters at:
>
> https://validation.linaro.org/lava-server/filters/
>
> I've made some effort to make the interface understandable, so I don't
> want to go on and on about all the possibilities here.  Suffice to say
> that it's supposed to be a way to allow one to describe tests that you
> are interested in and receive notifications when tests matching these
> descriptions arrive in the database.  If more criteria are needed,
> then then can be added :-)
>
> The code is new and quite complicated so there is definitely a risk of
> bugs.  I apologize in advance if your filter doesn't match all the
> results it should or you end up getting mailbombed!
>
> Future work will likely include: RSS feeds for filters, allowing
> sorting (and grouping) results by build number, and thinking about
> ways to use filters to drive other views, such as the image status
> view or some kind of interesting benchmark views.
>
> I am _super keen_ on getting feedback on whether this seems to be a
> useful feature.
>

Looks promising. I am previewing a filter for the labhealth bundle and
see all labhealth jobs (failures and passes). Now I would like to
constraint the filter to just show failures.

So question: what attribute to use to select just failures?



-- 
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?

[Alexander Sack]

On Wed, Jun 20, 2012 at 10:28 PM, Christian Robottom Reis
 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

[Alexander Sack]

On Wed, Jun 13, 2012 at 8:51 PM, David Zinman  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: Lava images improvement idea

[Alexander Sack]

On Thu, May 24, 2012 at 2:26 PM, Loïc Minier  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: LAVA android tests should be working again

[Alexander Sack]

On Thu, May 24, 2012 at 6:40 AM, Michael Hudson-Doyle
 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: clone speed on jenkins

[Alexander Sack]

On Wed, May 23, 2012 at 11:30 PM, Michael Hudson-Doyle
 wrote:
> Alexander Sack  writes:
>
>> On Wed, May 23, 2012 at 8:37 AM, Deepti Kalakeri
>>  wrote:
>>>
>>>
>>> On Wed, May 23, 2012 at 4:17 AM, John Rigby  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 images improvement idea

[Alexander Sack]

On Wed, May 23, 2012 at 6:21 PM, Marcin Juszkiewicz
 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: clone speed on jenkins

[Alexander Sack]

On Wed, May 23, 2012 at 5:03 PM, John Rigby  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: clone speed on jenkins

[Alexander Sack]

On Wed, May 23, 2012 at 8:37 AM, Deepti Kalakeri
 wrote:
>
>
> On Wed, May 23, 2012 at 4:17 AM, John Rigby  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: 12.05 linux-linaro kernel tree

[Alexander Sack]

On Tue, May 22, 2012 at 8:10 AM, Deepti Kalakeri
 wrote:
>
>
> On Thu, May 17, 2012 at 8:29 PM, Andrey Konovalov
>  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?

[Alexander Sack]

On Tue, May 15, 2012 at 1:44 PM, Ramana Radhakrishnan
 wrote:
> On 15 May 2012 12:38, Loïc Minier  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

[Alexander Sack]

Hi Tushar,

On Mon, May 14, 2012 at 8:04 PM, Tushar Behera  wrote:
> On 14 May 2012 13:40, Tushar Behera  wrote:
>> On 05/12/2012 11:09 PM, Andrey Konovalov wrote:
>>> Tushar,
>>>
>>> On 05/11/2012 09:04 AM, Tushar Behera wrote:
>>>> On 05/11/2012 01:04 AM, 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. 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.
>>>>>
>>>>> The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus
>>>>> the 7 generic topics currently included into the
>>>>> linux-linaro-core-tracking tree:
>>>>>     ufs (ufs-for-linux-linaro)
>>>>>     emmc (emmc-for-linux-linaro)
>>>>>     thermal_exynos4_imx6 (thermal_exynos4_imx6_work)
>>>>>     linaro-android-3.4
>>>>>     armlt-gator (tracking-armlt-gator)
>>>>>     umm-wip (umm-3.4rc4-wip)
>>>>>     linaro-configs-3.4
>>>>> If you don't see your generic topic in this list, but you think it
>>>>> should be there, please let me know ASAP. If you have a new topic to
>>>>> add, please send me the request before the next Thursday, May 17; the
>>>>> sooner, the better. The requirements for a topic can be found here:
>>>>> https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it
>>>>>
>>>>>
>>>>>
>>>>> The landing teams - please update your topic branches if needed:
>>>>> ARM:
>>>>>     tracking-armlt-hdlcd tracking-armlt-mmc
>>>>>     tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes
>>>>>     tracking-armlt-ubuntu-config tracking-armlt-android-config
>>>>> Samsung:
>>>>>     topic/base topic/core topic/bl topic/dt topic/fb topic/pd
>>>>>     topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg
>>>>>     topic/gadget topic/touch topic/wlan topic/audio topic/hdmi
>>>>>     topic/mali topic/cma_v24 topic/android_config
>>>>>
>>>> Is any other LT using CMA patchset? If so, this topic branch can be
>>>> moved into linux-linaro-core-tracking.
>>>
>>> That's a good idea, thanks!
>>>
>>> The only problem is that your topic/cma_v24 is based on the topic/base,
>>> and thus includes "CONFIG: ORIGEN:" commits and an older version of
>>> linaro-configs-3.4 topic. In particular, the latter recreates
>>> configs/panda.conf file which has been deleted from the current
>>> linaro-configs-3.4. Could you please make topic/cma_v24 mainline based
>>> (drop these "CONFIG: ORIGEN:" and configs/* changes)? And is the
>>> "CONFIG_CMA_SIZE_MBYTES=32" option Origen specific or generic? If it is
>>> generic, it should go into a separate file, e.g. configs/cma.conf.
>>>
>> I didn't mean to include topic/cma_v24 with the patches from topic/base,
>> rather the clean patchset from Marek. But now that we have the umm topic
>> branch in linux-linaro-core-tracking, we don't need topic/cma_v24
>> anymore. If any fixes with respect to Origen are required, I will queue
>> them up in another topic branch.
>>
>> I will shortly send you the list of topic branches for 2012.05 release,
>> now that 3.4-rc7 is already released.
>>
>
> While migrating the Android solution to use linux-linaro-core-tracking, I
> get kernel panic with umm-patchset (haven't dug deep into it though, it
> might be because the multimedia drivers are not yet migrated for using UMM).
> Would it be ok if we only include CMA patchset, but not the dma-buf and
> dma-mapping patches?
>

are you asking whether we would consider to drop dma-mapping from
linux-linaro tree or if it would be a bad idea to do that in your
samsung LT tree?

For linux-linaro, we probably would prefer to try to fix it before
talking about the option to drop such a core topic. Do you have more
info about the kernel panic you 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: 12.05 linux-linaro kernel tree

[Alexander Sack]

On Fri, May 11, 2012 at 8:51 AM, Jon Medhurst (Tixy)  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)  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: 12.05 linux-linaro kernel tree

[Alexander Sack]

On Fri, May 11, 2012 at 3:43 AM, Andy Green  wrote:
> On 11/05/12 08:27, Somebody in the thread at some point said:
>
>>  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.
>
>
> The probability of getting a good unified tree follows the kernel cycle, we
> all have good reasons to have tried to arrive at a good, working, release.
>  Sometimes we only get a reasonably good result a week or two after Linus'
> release.
>
> For that reason maybe you should just be trying to 'release' a release-basis
> unified tree, ie, the 3.4 one targeted now as the deliverable.  It still has
> meaning to make a monthly release of that since it can collect stable
> mainline updates and updates from each LT release tree that happened in the
> meanwhile.
>
> We do need to create these intermediate unified trees so we know what to fix
> on our trees so they can go in smoothly, but it matters less then if one day
> half the LT trees are missing on it since it's of interest only for LTs and
> platform guys to study what else needs solving on the LT trees.
>
> I still think you won't get anywhere useful until we are trying to build the
> unified trees for real.  Then we can start the needed work to make them fit
> together properly, until then we're treading water in "technical debt".
>  Discussing how to run the tree is something to do later after gaining this
> experience.
>
> I had a look at the LT gits
>
> ARM        Merge-managed      integration-linux-vexpress 3.4-rc4
> TI         Rebase-managed     tilt-tracking              3.4-rc4
> Freescale  Merge-managed      lt-3.4                     3.4-rc3
> Samsung    Rebase-managed     tracking                   3.4-rc3
> STE        Merge-managed      integration-linux-ux500    3.4-rc6
>
> (wow STE - on igloocommunity.org - have a LOT of patches!  I thought we were
> leading the way)
>
> Actually locally TILT are on -rc6 but there was almost no conflict coming
> between -rc4 and -rc6.  If you take the approach to merge these trees, I
> found that late in the cycle it's usually pretty forgiving about some
> variation in basis.
>
> So why not give these all a test merge today and see what starts falling
> out?  I am sure we all have something to fix and there may be larger issues

I will check with Andrey/Ricardo if we can do that :) ... would it be
exciting enough if we just try adding TI to the mix this month (and
not all?)?

In any case, you should definitely send Andrey a list of topic
branches you want to register for linux-linaro and things will get
picked up as soon as Andrey can I guess :).

-- 
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

[Alexander Sack]

On Fri, May 11, 2012 at 2:20 AM, Andy Green  wrote:
> On 11/05/12 07:43, Somebody in the thread at some point said:
>>
>> 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.
>
>
> Right... the problem with that would have been though that on a random day -
> and Linaro's monthly release cycle is random for tracking - our tracking may
> be dead.  Right now I have local tracking tree that's considerably ahead of
> last public push but OMAP4 boot dies in a novel and cool way we didn't get
> to the bottom of yet.
>
> We have good local-to-LT reasons for having got ourselves into that
> situation, we took in 70 patches from TI that are fixes or improvements to
> core support we want to have in for 3.4.  That reasoning might occur the day
> or week before this Linaro monthly release and we should again choose to
> temporarily trash the tree.  Sometimes, we get demand to hold tracking for
> other reasons again asynchronous to monthly release.
>
> In short monthly release action will have to make do with "last thing that
> was working best" as a single LT tree and for unified "last unified build
> that was working best for most trees", which sometimes might be weeks old.
>  To facilitate the single LT case we are tagging our pushes we believe are
> worth something, even if they might go backwards sometimes as we integrate
> new drops of stuff.
>
> For ARM LT the situation is a bit simpler, you have largely parallel feature
> trees with new - super valuable, don't get me wrong - content, in our case
> we have 1,000 - 2,000 patches with conflicting content to definitive stuff
> pouring in to mainline all the time.  We usually can't do any special
> planning to converge with the monthly release.  (Nor will it get better in
> medium term, 3.5 has a huge convulsion in hwmod coming that might send us
> back to the Stone Age for a while)
>

>From my (granted high level) perspective keeping good logs/statistics
of patches/topics that cause conflicts and pain over and over again
might serve as good indication to target investment in upstreaming or
frameworks improvements/refactoring.

I assume this idea has been played through? What's the plan forward to
solve this problem? Maybe if we look closely there might be potential
base framework topics hidden that could be tackled by our kernel WG to
help you out mid/long term?

-- 
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

[Alexander Sack]

On Fri, May 11, 2012 at 1:43 AM, Jon Medhurst (Tixy)  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.

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: 12.05 linux-linaro kernel tree

[Alexander Sack]

On Fri, May 11, 2012 at 12:09 AM, Jon Medhurst (Tixy)  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: pointless mail, (was Re: android-build's are failing...)

[Alexander Sack]

On Fri, May 11, 2012 at 12:24 AM, Ricardo Salveti
 wrote:
> On Thu, May 10, 2012 at 1:37 PM, Wookey  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: android-build's are failing, we're on it...

[Alexander Sack]

On Fri, May 11, 2012 at 12:21 AM, Ricardo Salveti
 wrote:
> On Thu, May 10, 2012 at 1:20 PM, Christian Robottom Reis
>  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: linux-linaro-core-tracking tree created / update frequency

[Alexander Sack]

On Thu, May 3, 2012 at 6:10 PM, John Stultz  wrote:
> On 05/03/2012 07:15 AM, Alexander Sack wrote:
>>
>> On Thu, May 3, 2012 at 4:00 PM, Andrey Konovalov
>>   wrote:
>>>
>>> Sorry for the delay.
>>>
>>> I've updated the linux-linaro-core-tracking, but it currently misses the
>>> linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back
>>> after
>>> resolving the merge conflicts; guess later today.
>>
>> Is the resolution simple enough? Otherwise, feels that the better
>> scalable approach is that the topic owner (e.g. John Stultz for the
>> time being) gets notified and asked to fix the merge conflict on his
>> side. Your daily merge scripts would then pick it up automatically  as
>> soon as the merge conflict is resolved.
>
>
> So Andrey mailed me that there was a conflict between Linus' v3.4-rc5 and
> the Android tree, but when I went to updated the tree sort it out,
>  v.3.4-rc5 merged in without any issues. I suspect the collision is with
> something else in the linaro tree, but haven't yet gotten any feedback as to
> what that might be.
>

OK, feels we could benefit from getting Andreys tools out and enable
you to easily fold linux-linaro with your your own local topic?

Would this help you to more easily converge, prepare and maintain
topics that coexist in linux-linaro?


-- 
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: linux-linaro-core-tracking tree created / update frequency

[Alexander Sack]

On Thu, May 3, 2012 at 4:00 PM, Andrey Konovalov
 wrote:
> On 05/03/2012 04:28 AM, Andy Green wrote:
>>
>> On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
>>
>> Hi -
>>
>>>  The plan is to rebase this tree on the
>>> current mainline tip daily.
>>
>>
>> Now we're basing on it, our tracking progress depends on these "daily"
>> rebases, but it's stuck since Friday.  So we're missing -rc5 for 3 days.
>
>
> Sorry for the delay.
> I've updated the linux-linaro-core-tracking, but it currently misses the
> linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back after
> resolving the merge conflicts; guess later today.

Is the resolution simple enough? Otherwise, feels that the better
scalable approach is that the topic owner (e.g. John Stultz for the
time being) gets notified and asked to fix the merge conflict on his
side. Your daily merge scripts would then pick it up automatically  as
soon as the merge conflict is resolved.

Sounds right?


-- 
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

[Alexander Sack]

On Fri, Apr 20, 2012 at 4:33 AM, Akira Tsukamoto  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

[Alexander Sack]

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 > <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
&g

Re: Preliminary 12.04 linux-linaro kernel tree

[Alexander Sack]

On Thu, Apr 19, 2012 at 5:27 AM, Andy Green  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: No group tracks at Connect

[Alexander Sack]

On Wed, Apr 18, 2012 at 7:45 PM, David Rusling wrote:

> 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: Preliminary 12.04 linux-linaro kernel tree

[Alexander Sack]

On Wed, Apr 18, 2012 at 3:04 AM, Andy Green  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 ... 
> > # - the merge order is  to .
> > 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   
> > # -  must be another topic
> > # Example1: tracking-armlt-gator lt_arm/tracking-armlt-gator
> > #- missing  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: Getting from a CI report to a hardware pack

[Alexander Sack]

On Sat, Apr 14, 2012 at 4:29 PM, Alexander Sack  wrote:

>
>
> On Sat, Apr 14, 2012 at 2:41 PM, Christian Robottom Reis 
> wrote:
>
>> 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:
>>
>> 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: Getting from a CI report to a hardware pack

[Alexander Sack]

On Sat, Apr 14, 2012 at 2:41 PM, Christian Robottom Reis wrote:

> 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:
>
> 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: Call for testing Linaro Android 12.04 candidates

[Alexander Sack]

On Tue, Apr 10, 2012 at 6:56 PM, anmar.ou...@linaro.org
 wrote:
> Hello Fathi:
>
> On 9 April 2012 11:15, Fathi Boudra  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

[Alexander Sack]

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  wrote:
> 
> > On Tue, Mar 27, 2012 at 4:55 PM, Loïc Minier 
> > 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 
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

[Alexander Sack]

On Sun, Mar 4, 2012 at 11:02 PM, Michael Hope wrote:

> 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

[Alexander Sack]

On Mon, Feb 20, 2012 at 5:11 PM, Paul Sokolovsky  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=master<http://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

[Alexander Sack]

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=get&search=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  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:>
> 
>
> 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

[Alexander Sack]

On Fri, Feb 3, 2012 at 11:32 AM, Christian Robottom Reis
 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: [Linaro-validation] Linaro kernel tree for A15 for daily builds

[Alexander Sack]

On Wed, Jan 25, 2012 at 9:33 PM, Zygmunt Krynicki
 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: Sources for 11.11 kernel release

[Alexander Sack]

On Fri, Jan 27, 2012 at 11:40 AM, Loïc Minier  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: Sources for 11.11 kernel release

[Alexander Sack]

On Wed, Jan 25, 2012 at 7:14 PM, Christian Robottom Reis
 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: DisableSuspend.apk

[Alexander Sack]

On Mon, Jan 16, 2012 at 6:24 PM, Paul Larson  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: Architectures to support when releasing binaries

[Alexander Sack]

On Mon, Jan 16, 2012 at 3:32 AM, Michael Hope  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

[Alexander Sack]

On Mon, Jan 16, 2012 at 12:45 PM, yong qin  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: lava-deployment-tool is now (also) on github

[Alexander Sack]

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

[Alexander Sack]

On Tue, Dec 6, 2011 at 3:24 PM, Paul Larson  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

Beagle will not go EOL in January! (Was: Re: [EOL] Request for End Of Life - Beagleboard and Beagleboard-xM)

[Alexander Sack]

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 wrote:

> 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

[Alexander Sack]

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/ppa<http://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

Re: Proposal : New Linaro Desktop Wallpaper

[Alexander Sack]

On Fri, Dec 2, 2011 at 10:58 AM, Riku Voipio  wrote:

> On 2 December 2011 00:56, Tom Gall  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

[Alexander Sack]

On Fri, Nov 11, 2011 at 3:53 PM, Dave Pigott  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  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: Some more comments on CI loop interface

[Alexander Sack]

On Wed, Nov 9, 2011 at 5:36 AM, Michael Hudson-Doyle <
michael.hud...@linaro.org> wrote:

> On Tue, 8 Nov 2011 12:56:39 -0800, Deepak Saxena 
> wrote:
>
> > 2) From the main ci-loop page, how do I get to
> > a link for the RSS feed? Are the RSS feeds
> > per-tree or per (tree + defconfig) combination?
> > The later is preferred from the perspective of
> > having upstream sub-arch maintainers who
> > want to watch specific platforms.
>
> The only RSS feeds we have right now are from Jenkins, so start at:
> https://ci.linaro.org
>
>
We have some documentation on how to subscribe to build failures here:

  +
https://wiki.linaro.org/Platform/Infrastructure/LinaroCI/RSSForBuildFailures

This includes subscribing to a complete tree as well as to a particular
tree/defconfig/


-- 
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

[Alexander Sack]

On Tue, Oct 25, 2011 at 12:07 PM, Dave Martin wrote:

> On Mon, Oct 17, 2011 at 01:47:13PM +0200, Alexander Sack wrote:
> > Hi,
> >
> > On Fri, Oct 14, 2011 at 7:52 PM, Dave Martin 
> 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
>
> Does ubuntu-bug know about this (or should we have out own linaro-bug
> script?)  I worry that we mat not get good bug tracking if it's too hard
> to identify where to file a bug.
>
>
As far as I understand we announce where to file bugs for ubuntu and android
in the release announce.

Linaroizing ubuntu-bug sounds like an interesting idea. For our cases we
probably want something more suitable for cross-use-cases (ubuntu-bug needs
to be run on the target). Anyone wants to pick this up, add a blueprint to
backlog
and own discussion 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: [REMINDER] Jenkins and Ec2 plugin upgrade on Linaro CI [ ci.linaro.org]

[Alexander Sack]

Hi Deepti,

On Tue, Oct 18, 2011 at 8:23 AM, Deepti Kalakeri  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

[Alexander Sack]

On Mon, Oct 17, 2011 at 1:47 PM, Alexander Sack  wrote:

> Hi,
>
>
> On Fri, Oct 14, 2011 at 7:52 PM, Dave Martin 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
>
>
... also poked the overlay ppa description/banner a bit to give better
guidance. Check: https://launchpad.net/~linaro-maintainers/+archive/overlay

-- 
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

[Alexander Sack]

Hi,

On Fri, Oct 14, 2011 at 7:52 PM, Dave Martin  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: sneak preview of kernel ci views

[Alexander Sack]

On Thu, Oct 13, 2011 at 2:20 PM, Dave Martin  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: [ACTIVITY] Android Platform Team 2011-10-03 to 2011-10-09

[Alexander Sack]

On Thu, Oct 13, 2011 at 1:12 PM, Tony Mansson wrote:

> * 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: 11.10 image changes

[Alexander Sack]

On Tue, Oct 11, 2011 at 7:08 PM, Tom Gall  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

[Alexander Sack]

On Tue, Oct 11, 2011 at 3:42 PM, Dave Martin  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: Linaro CI hwpack name improvements

[Alexander Sack]

On Mon, Oct 10, 2011 at 4:41 PM, Dave Martin  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-omap2plus<https://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

[Alexander Sack]

On Mon, Oct 10, 2011 at 2:08 PM, Loïc Minier  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

[Alexander Sack]

On Fri, Oct 7, 2011 at 12:45 PM, Fathi Boudra wrote:

> On 7 October 2011 13:23, Alexander Sack  wrote:
> > On Thu, Oct 6, 2011 at 11:29 PM, Paul Larson 
> 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: Oneiric image directory on snapshots.linaro.org

[Alexander Sack]

On Thu, Oct 6, 2011 at 11:29 PM, Paul Larson  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: Announce: TILT tracking Androidization trees

[Alexander Sack]

On Tue, Oct 4, 2011 at 5:33 PM, Andy Green  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: BUGREPORTED work item state

[Alexander Sack]

On Mon, Oct 3, 2011 at 4:48 AM, Zach Pfeffer wrote:

> On 30 September 2011 13:22, Fathi Boudra  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: Announce: TILT tracking Androidization trees

[Alexander Sack]

Hi Andy,

On Tue, Oct 4, 2011 at 1:23 PM, Andy Green  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=summary<http://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.1<http://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: Reboot not working with the newly built upstream custom kernel

[Alexander Sack]

On Wed, Sep 28, 2011 at 5:35 PM, Deepti Kalakeri  wrote:

>
>
> On Wed, Sep 28, 2011 at 8:43 PM, Alexander Sack  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 wrote:
>>>
>>>> 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: Reboot not working with the newly built upstream custom kernel

[Alexander Sack]

On Wed, Sep 28, 2011 at 7:10 AM, Deepti Kalakeri  wrote:

> Hello Paul,
>
> On Wed, Sep 28, 2011 at 7:05 AM, Paul Larson wrote:
>
>> 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: [CALL FOR TESTING] Linaro 11.09 Release Candidate

[Alexander Sack]

On Tue, Sep 27, 2011 at 9:23 AM, Fathi Boudra wrote:

> On 27 September 2011 09:59, Ricardo Salveti 
> wrote:
> > On Tue, Sep 27, 2011 at 3:19 AM, Fathi Boudra 
> wrote:
> >> Hi Ricardo,
> >>
> >> On 27 September 2011 06:23, Ricardo Salveti 
> 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: [CALL FOR TESTING] Linaro 11.09 Release Candidate

[Alexander Sack]

On Tue, Sep 27, 2011 at 5:23 AM, Ricardo Salveti  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: [ACTIVITY] Multimedia WG status report - wk38.2011 (20110919-20110923)

[Alexander Sack]

On Mon, Sep 26, 2011 at 2:56 PM, Dechesne, Nicolas wrote:

>
>
> On Mon, Sep 26, 2011 at 2:21 PM, Ilias Biris wrote:
>
>>  - 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

[Alexander Sack]

On Wed, Sep 21, 2011 at 12:31 AM, James Westby wrote:

> On Mon, 19 Sep 2011 10:03:08 +0300, Fathi Boudra 
> 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 ?

[Alexander Sack]

On Tue, Sep 20, 2011 at 9:35 AM, Patrik Ryd  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

[Alexander Sack]

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=AttachFile&do=view&target=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: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball

[Alexander Sack]

On Fri, Sep 9, 2011 at 7:34 PM, Christian Robottom Reis wrote:

> On Fri, Sep 09, 2011 at 12:09:55PM -0500, Zach Pfeffer wrote:
> > The term "Stage" is used to indicate builds that contain patches that
> > haven't been upstreamed.
>
> That a pretty confusing term. Are we sure we want to call it that?
>

This comes out of me complaining to android team that they titled everything
that didn't use mainline kernel as "LEB", no matter how well that worked, no
matter what level of hardware enablement those builds came with, no matter
if those builds are booting to UI or not.

To avoid that we said that the technical/functional build name shouldn't
include the term leb at all, but rather mark those builds as non-mainline in
a different way. The term LEB would then become a badge (think about
certification) that gets awarded by release team for builds _after_ they
have gone through validation/testing and have been officially confirmed to
meet LEB requirements.

That said, I don't like the name "Stage" much either. Idea: How about we
mark the ones that are not "stage" as "mainline" and drop the "stage" marker
from the other build names?

-- 

 - Alexander

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: Non-FOSS license acceptance by robots

[Alexander Sack]

On Wed, Sep 7, 2011 at 3:48 PM, Paul E. McKenney  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: Linaro 11.08 released

[Alexander Sack]

On Thu, Sep 8, 2011 at 1:05 PM, Christian Robottom Reis wrote:

> 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

[Alexander Sack]

On Wed, Sep 7, 2011 at 11:39 AM, 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.
>
>
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

[Alexander Sack]

On Tue, Sep 6, 2011 at 4:25 PM, Fathi Boudra wrote:

> On 6 September 2011 08:28, Fathi Boudra  wrote:
> > On 6 September 2011 00:15, Alexander Sack  wrote:
> >> On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky
> >>  wrote:
> >>>
> >>> On Mon, 5 Sep 2011 14:36:48 +0300
> >>> Paul Sokolovsky  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

[Alexander Sack]

On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky  wrote:

> On Mon, 5 Sep 2011 14:36:48 +0300
> Paul Sokolovsky  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.

[Alexander Sack]

On Fri, Sep 2, 2011 at 2:06 PM, Vishal Bhoj  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

[Alexander Sack]

On Thu, Sep 1, 2011 at 1:05 PM, Christian Robottom Reis wrote:

> 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  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: CFP : Have a Beagle or Beagle XM with a USB wifi?

[Alexander Sack]

On Wed, Aug 31, 2011 at 7:56 PM, Tom Gall  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: edge.validation.linaro.org

[Alexander Sack]

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: Tracking Android kernel tips and Android builds

[Alexander Sack]

On Wed, Aug 31, 2011 at 2:09 AM, James Westby wrote:

> On Tue, 30 Aug 2011 11:10:10 -0500, Zach Pfeffer 
> 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: Tracking Android kernel tips and Android builds

[Alexander Sack]

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  wrote:
>
> > On Mon, Aug 29, 2011 at 3:22 PM, Paul Sokolovsky
> >  > > 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: edge.validation.linaro.org

[Alexander Sack]

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/  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: A really awesome job, thank you!

[Alexander Sack]

On Tue, Aug 30, 2011 at 6:57 PM, Zach Pfeffer wrote:

> 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: Tracking Android kernel tips and Android builds

[Alexander Sack]

On Mon, Aug 29, 2011 at 3:22 PM, Paul Sokolovsky  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: 11.08 Pre-built Images

[Alexander Sack]

On Mon, Aug 29, 2011 at 9:56 AM, Jani Monoses  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/
>>
>>  - ALIP:
>>
>> http://releases.linaro.org/**images/linaro-n/alip/11.08/
>>
>>  - Ubuntu Desktop:
>>
>> 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: Linaro 11.08 released

[Alexander Sack]

On Fri, Aug 26, 2011 at 2:17 PM, Amit Kucheria wrote:

> On Fri, Aug 26, 2011 at 3:07 PM, Fathi Boudra 
> 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

Re: ANN: ASTER - Android System Testing Environment and Runtime

[Alexander Sack]

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  wrote:

> Hello list,
>
> 0xlab announced the new system testing utility for Android.
>
> -- Forwarded message --
> From: Kan-Ru Chen 
> 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: Please just send things to linaro-dev...

[Alexander Sack]

On Fri, Aug 26, 2011 at 12:38 PM, Botao Sun  wrote:

> Hi Zach,
>
> Although I think "linaro-andr...@linaro.org" is easy to use, especially
> inside the team, but if consider about the development information sharing
> and to avoid duplicate discussion, send message to linaro-dev may be the
> most efficient way.
>
> I don't think we should shut down the #linaro-android because it's an open
> channel rather than the private mailing list "linaro-andr...@linaro.org".
> People can join this channel freely, and the discussion in this channel can
> be seen by everyone, so there is no information sharing and duplicate
> discussion issues.
>
> Just my opinion, thanks.
>
>
I see it the same way as botao.

-- 

 - Alexander
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Linaro 11.08 released

[Alexander Sack]

On Fri, Aug 26, 2011 at 12:20 PM, Fathi Boudra wrote:

> > 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: Linaro 11.08 released

[Alexander Sack]

On Fri, Aug 26, 2011 at 12:20 PM, Fathi Boudra wrote:

> Hi,
>
> On 26 August 2011 12:18, Dave Martin  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