Re: [Dev] Developer Reference Platform 16.03 differences compared to Debian
On Fri, Apr 29, 2016 at 11:05 AM, Nicolas Dechesne <nicolas.deche...@linaro.org> wrote: > On Fri, Apr 29, 2016 at 3:56 PM, Ricardo Salveti > <ricardo.salv...@linaro.org> wrote: >> >>> wcnss-config: 1.8 >>> optee-client: 1.0.1+git5+g89f25ce-1.linarojessie.1 >>> glshim: 0.41+git20150911.42a7739-0.linarojessie.1 >> >> We should be able to get these in debian. > > wcnss-config shouldn't go upstream, imho. at least not in its current > form. it does 2 things: > 1. create a single WLAN mac address based on some pseudo unique ID > available on the board > 2. loads/starts WLAN and BT > > #1 is not strictly needed, as the driver would default to using a > random MAC. and I don't think what we do is nice enough to be > upstream... we can discuss more.. > > #2 we at least need to wait for the underlying kernel drivers to reach > mainline before we upstream (which should be soon), the method to > start/load the firmware will change. That is true, forgot this package was mainly responsible for setting up the mac address for the board. >>> Changed packages: >>> >>> alsa-lib: 1.0.28-1+linaro1.linarojessie.1 >>>* add UCM config file for HDMI and HiFi on DB410c >>>* add UCM config file for HDMI on IFC6410 >> >> Good one for upstreaming. >> >> Nico, did you get to send those to the upstream alsa/ucm project? > > yeah, we talked about that. Fathi said he will take care of it, he was > planning to submit the config files for Bugglegum, we will do them at > the same time. We might need some clean up first though. Great, thanks for the update. Cheers, -- Ricardo Salveti ___ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Dev] Developer Reference Platform 16.03 differences compared to Debian
On Fri, Apr 29, 2016 at 10:21 AM, Nicolas Dechesne <nicolas.deche...@linaro.org> wrote: > On Fri, Apr 29, 2016 at 3:06 PM, Riku Voipio <riku.voi...@linaro.org> wrote: >> One of the goals of RPB is to follow that our changes go back >> upstream. For the next RPB release, a more polished report is planned. >> But to get things started, here's a sample - and to use as baseline to >> compare progress for the 16.06 release. The list of packages is >> collected from db410/alip image with distrodelta script[1]. This lists >> the packages that do not become from Debian (Jessie release) or Debian >> backports: > > good stuff. Can this be added to Jenkins as part of the images builds? > or does it have to run on the target after the fact? That would indeed be quite cool to have! Cheers, -- Ricardo Salveti ___ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Dev] Developer Reference Platform 16.03 differences compared to Debian
On Fri, Apr 29, 2016 at 10:06 AM, Riku Voipio <riku.voi...@linaro.org> wrote: > One of the goals of RPB is to follow that our changes go back > upstream. For the next RPB release, a more polished report is planned. > But to get things started, here's a sample - and to use as baseline to > compare progress for the 16.06 release. The list of packages is > collected from db410/alip image with distrodelta script[1]. This lists > the packages that do not become from Debian (Jessie release) or Debian > backports: Thanks for doing and publishing the report. > New packages not in Debian: > > 96boards-artwork: 0.6-0linaro1 > 96boards-tools: 0.5 > linaro-artwork: 0.6-0linaro1 > linaro-default-settings: 0.3-0linaro1 > linaro-overlay: 1112.8 Expect these ones to be in our repo for a bit more. Tools might be useful outside of it, but the others are custom related artwork and settings. > wcnss-config: 1.8 > optee-client: 1.0.1+git5+g89f25ce-1.linarojessie.1 > glshim: 0.41+git20150911.42a7739-0.linarojessie.1 We should be able to get these in debian. > Changed packages: > > alsa-lib: 1.0.28-1+linaro1.linarojessie.1 >* add UCM config file for HDMI and HiFi on DB410c >* add UCM config file for HDMI on IFC6410 Good one for upstreaming. Nico, did you get to send those to the upstream alsa/ucm project? > chromium-browser: 47.0.2526.16-1.6.linarojessie.1 >* seccomp and namespace fixes >* patches to compile on arm64/armhf What is the upstreaming state here? > firmware-nonfree: 20160110-1.linarojessie.1 >* ti-connectivity (updates for HiKey): > - Include wl18xx-fw-4 firmware https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816350 > - Add TIInit_11.8.32.bts for bluetooth support Got in contact with the maintainer, and there is no interest in pushing this to the upstream linux-firmware tree. We could try doing that, otherwise it might need to end up in a different package. > isc-dhcp: 4.3.3-8~linaro1 >* Reverting requirement for debhelper >= 9.20151220 >* Upload to make it work with latest systemd: > - https://bugs.96boards.org/show_bug.cgi?id=271 > > linux: 4.4.0.linaro.104-1.linarojessie.1 >* See kernel changes report (TBD) This will always be around, used for development. > No-changes Backports: > > apparmor: 2.10-2.linarojessie.1 > binutils: 2.25.90.20160101-1.linarojessie.1 > gdb: 7.10-1.linarojessie.1 > gyp: 0.1+20150913git1f374df9-1.linarojessie.1 > java-common: 2:1.8-53.linarojessie.1 > nodejs: 4.2.2~dfsg-1.1.linarojessie.1 > openssl: 1.0.2d-1.linarojessie.1 > systemd: 228-2.4.linarojessie.3 > sysvinit: 2.88dsf-59.2.linarojessie.1 > util-linux: 2.27.1-1.linarojessie.1 > x265: 1.7-4~bpo8+1.linarojessie.1 > xorg: 1:7.7+11.linarojessie.1 > xorg-server: 2:1.17.3-2.linarojessie.2 > xserver-xorg-video-fbdev: 1:0.4.4-1.linarojessie.1 > xserver-xorg-video-freedreno: 1.4.0-1.linarojessie.1 Thanks, -- Ricardo Salveti ___ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Dev] Reference platform kernel on github
On Wed, Mar 2, 2016 at 9:11 AM, Amit Kucheria <amit.kuche...@linaro.org> wrote: > Hi Zoltan, > > We've already enabled DRM on the 4.4 kernel with the framebuffer Xorg > driver. What do you need on top of that to enable you do run > Wayland/Weston? A link to a patchset would allow me to evaluate > whether we can incorporate these into the next release. Right, I know the version that will probably be merged quite soon had a few extra changes, so wonder if everything you need is included there (https://lists.freedesktop.org/archives/dri-devel/2016-February/101784.html). But please give us a link to the patch series used, and we can review the changes required. We are also going to discuss how we will maintain this kernel over time, including when to move to newer versions, so please also make sure to join the 96boards sessions in BKK16. Thanks, -- Ricardo Salveti ___ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Planning topcs for inclusion in linux-linaro
On Fri, Oct 5, 2012 at 2:03 PM, Andrey Konovalov andrey.konova...@linaro.org wrote: On 10/05/2012 12:12 PM, Jon Medhurst (Tixy) wrote: On Thu, 2012-10-04 at 23:02 +0400, Andrey Konovalov wrote: don't we need some kind of notification system where you announce a plan to rebuild linux-linaro and give us a version of llct to base our LT branches off? Andrey, let's make sure this is properly communicated over time for the maintainers and linaro-dev, so everyone can understand and see the progress done (to prepare any kind of rebase/pull). Yes, this makes sense. Would the following plan be OK: (N should normally be 0, but may be a small positive number) * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N * October 23: ll rebuild based on llct-20121019.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Is this month following the normal release cycle? If so, isn't the release day Oct 24th, and release candidates are built from the previous Thurday's code, i.e. Oct 18th. I.e. the freeze for the release should be Oct 16th not 23rd? Oops.. Your are right. Why don't we have the Thursday, October 32 this year? :-) So the correct plan is the following: * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Also, I assume we're not going to try to move to Linux 3.7 this month? That's correct. We didn't have the kernel.org release based (vs -rc based) ll release for quite a while. And the plan is to stick to v3.6 for 12.10 release unless someone needs to move to v3.7-rc* by all means this cycle. After October 19 the llct tree will move to v3.7-rc*, but the ll tree will be frozen till the 12.10 is out. There are some advantages already about using v3.7 (like aarch64 support), but as it's a quite short cycle, and the we'll probably not have enough RCs to produce a useful tree for the release, v3.6 would be the best option. Let's also make sure we have a session at Connect to discuss the tree maintenance as usual, then we can better announce/propose any changes you're doing for the following cycles. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Release 12.09 Postmortem Summary
On Fri, Oct 5, 2012 at 4:36 PM, David Zinman david.zin...@linaro.org wrote: Postmortem and lessons learned for Linaro's release 2012.09 https://wiki.linaro.org/Cycles/1209/Release/Review Is there any specific reason why we're missing the postmortem for so many teams? Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] linaro/configs: ubuntu: Disable support for generic OHCI platform driver
On Fri, Sep 14, 2012 at 12:41 AM, Tushar Behera tushar.beh...@linaro.org wrote: OHCI-HCD driver does not support multiple SoC drivers during the compile time. Hence the generic driver should be disabled in ubuntu.conf and related OHCI Soc drivers should be enabled in respective board config files. Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- linaro/configs/ubuntu.conf |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/linaro/configs/ubuntu.conf b/linaro/configs/ubuntu.conf index 5d0a372..88e58df 100644 --- a/linaro/configs/ubuntu.conf +++ b/linaro/configs/ubuntu.conf @@ -1556,7 +1556,6 @@ CONFIG_USB_OXU210HP_HCD=m CONFIG_USB_ISP116X_HCD=m CONFIG_USB_ISP1760_HCD=m CONFIG_USB_OHCI_HCD=y -CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_U132_HCD=m CONFIG_USB_SL811_HCD=m -- 1.7.4.1 Pushed to config-core-tracking. Thanks! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Test Result Summary for Calendar Week 37.
On Fri, Sep 14, 2012 at 6:12 AM, Botao Sun botao@linaro.org wrote: Calendar Week 37: Here is test result summary for Linaro ubuntu platform on following boards: 1) ARM Versatile Express A9; 2) Samsung Origen; 3) TI Panda Board 4430; 4) TI Panda Board 4460. Synopsis: Power Management test lets Panda 4430 crashed, but works well on Panda 4460. Device tree is still unavailable on Versatile Express A9. YouTube backs to work on Origen but Power Management test hangs the board. Application debug in DS-5 is unavailable on all boards. Thanks for the report and feedback. 1. vexpress A9 + ubuntu (Column Y): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFNmV3gyZWRGVS12YUhqeW9rdkVZdmc#gid=0 reboot works. This is the only difference between last week and this week test result. Device tree blob files have disappeared for more than 1 month, and DS-5 application debug is still unavailable. 480p video totally can't be played back, and this issue has exists for 8 weeks. In past, the video can be played, but not smoothly; now it doesn't work at all. Known issue, probably a side effect of the multimedia enablement for Panda. 2. Origen + ubuntu (Column U): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEowNWhZRi1zbDNNVUw1amhXTUdPcVE#gid=0 YouTube works, although the FPS is low but it's at least acceptable now. All the other features status remain the same as last week. The power management test still hangs system, and this issue has been there for 5 weeks. Also, WiFi has been unavailable for 3 weeks. For more details, please click above link. We should get a new kernel based on 3.6 next week, let's see how that performs comparing with the current 3.5 based one. 3. Panda 4430 + ubuntu (Column V): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZkhrZ1VYUEg2LTlQZzR0RlhzM3c#gid=0 YouTube starts to work, after video buffering completed, it can play video well. 1080p video now can be played well too, with this extra codec package - ubuntu-omap4-extras-multimedia. Power management starts to let system crash but it worked well in last week. DS-5 data streaming works with this package installed - gator-module-dkms. For suspend / resume test, the board can't be woken up. All the others remain the same as last week. 4. Panda 4460 + ubuntu (Column V): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZkhrZ1VYUEg2LTlQZzR0RlhzM3c#gid=1 Although file transfer via Bluetooth is still unavailable, the other features works well, such like device pairing, Bluetooth headset, etc. Power management test fully passed in this image. For DS-5, after install gator-module-dkms, data streaming works well too, although application debug feature is still unavailable. All the other features remain the same, please refer to above test result spreadsheet to find more. For the previous week (Calendar week 36) summary, please refer to attachment. Thanks! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: boot fail with omap4-panda.dts release 12.08
On Mon, Sep 10, 2012 at 1:27 AM, Viresh Kumar viresh.ku...@linaro.org wrote: On 9 September 2012 14:11, Amit Kucheria amit.kuche...@linaro.org wrote: I believe Viresh has tried mainline as well. But some DT bits might be missing from there. Without DT, things start working and that is the route we'll take if we're unable to get help with LEB u-boot command-line parameters and 3.6 kernels on Pandaboard. We're coming up on 3.6 soon. Do we know when we'll have updated OMAP support? Actually mainline image was working with DT, but i wanted to work on Linaro tree to get latest patches on various topics... That's interesting. Which rev from upstream did you use? I know Andrey is updating linux-linaro this week, which should be on top of 3.6-rc5. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] Android fixes w.r.t. 3.6 kernel
On Tue, Sep 11, 2012 at 2:22 AM, Tushar Behera tushar.beh...@linaro.org wrote: Ping !!! Can we get them at least included at linux-linaro's android topic? Thanks, Ricardo On 08/31/2012 09:57 AM, Tushar Behera wrote: Required for android-3.6 tree. Tushar Behera (2): netfilter: xt_quota2: Move away from NLMSG_PUT() netfilter: xt_quota2: Update parameter list in netlink_kernel_create net/netfilter/xt_quota2.c | 25 - 1 files changed, 16 insertions(+), 9 deletions(-) Without these patches, build of LT kernel based on llct(v3.6-rc5) fails with following error message. net/netfilter/xt_quota2.c: In function ‘quota2_log’: net/netfilter/xt_quota2.c:85:2: error: implicit declaration of function ‘NLMSG_PUT’ [-Werror=implicit-function-declaration] net/netfilter/xt_quota2.c:85:6: warning: assignment makes pointer from integer without a cast [enabled by default] net/netfilter/xt_quota2.c:110:1: warning: label ‘nlmsg_failure’ defined but not used [-Wunused-label] net/netfilter/xt_quota2.c: In function ‘quota_mt2_init’: net/netfilter/xt_quota2.c:353:12: warning: passing argument 3 of ‘netlink_kernel_create’ makes pointer from integer without a cast [enabled by default] In file included from include/linux/if_link.h:5:0, from include/linux/netdevice.h:31, from include/linux/netfilter/x_tables.h:188, from net/netfilter/xt_quota2.c:21: include/linux/netlink.h:185:21: note: expected ‘struct module *’ but argument is of type ‘int’ net/netfilter/xt_quota2.c:353:12: error: too many arguments to function ‘netlink_kernel_create’ In file included from include/linux/if_link.h:5:0, from include/linux/netdevice.h:31, from include/linux/netfilter/x_tables.h:188, from net/netfilter/xt_quota2.c:21: include/linux/netlink.h:185:21: note: declared here -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: how to update kernel image on panda board?
On Fri, Sep 7, 2012 at 6:47 AM, Viresh Kumar viresh.ku...@linaro.org wrote: Hi Guys, I have flashed my SD card with linaro-media-create with precise-devel and latest h/w pack (12.08) Now i have two requirements: - Always use my copy of devel instead of the new devel everytime from the latest release As i do install a lot of stuff on it. Will apt-get update would be enough to get the latest things from linaro? apt-get update/upgrade is not 100% safe, but we always try to make the transition to work so our users can still update their images based after flashing it. So feel free to upgrade it with apt and report us any issue you might find later. - Update kernel image, with my kernel, from mainline or linaro I have tried a lot of combinations... but always some issues You could update the kernel based on the latest packages that might end up at the Overlay PPA or build your own, it all depends on your needs. I went through this too: https://wiki.linaro.org/Resources/HowTo/KernelDeploy If you want to build your kernel by hand you can just follow the instructions to update the uImage and kernel modules, and it should work just fine. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: boot fail with omap4-panda.dts release 12.08
On Fri, Sep 7, 2012 at 6:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote: Hi, I am trying to boot kernel on panda board. I got the source from: http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;h=refs/heads/linux-linaro Following is my branch HEAD: commit 7f39bb7ab9591c6254e5930a00d762e4b37f08b2 Merge: 1d10459 8b29cd5 Author: Andrey Konovalov andrey.konova...@linaro.org Date: Mon Sep 3 17:10:24 2012 +0400 Merge branch 'tracking-ll-last-minute-fixes' into merge-linux-linaro I am using following for compilation: omap2plus_defconfig, omap4-panda.dts When i try to boot, kernel hangs after uncompressing linux... If i just remove the 0x815f from bootm command.. i.e. boot without dtb... it boots fine. Earlier i have flashed my card using linaro-media-create. Got, H/w package and devel rootfs from 12.08 release. Replaced uImage and board.dtb in /dev/mmcblk0p1 Unfortunately Panda is not supported by the LT at this tree yet, so the best thing to do is to try just the latest upstream kernel (from git.kernel.org) and see if you're able to reproduce the same issue with it (or just use the old 3.4 based tree from the LT). Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: llct stable trees
On Wed, Sep 5, 2012 at 7:55 AM, Andy Green andy.gr...@linaro.org wrote: On 09/05/12 17:19, the mail apparently from Andy Green included: On 09/04/12 12:13, the mail apparently from Ricardo Salveti included: Hi - 1) Can we have linux stable point release content in tilt-3.4? Rather than my doing it, isn't it better to add it to llc-3.4 and merge it on the lt history tree periodically? That way every lt can get them from one place. I don't see why merging the stable release contents would be an issue. We could keep updating the tree based on stable-only releases, as long as we still have at least one Landing Team interested on consuming it. This would be another job that would probably be automated by Andrey's scripts. Right it should usually be simple, although don't forget there is quite a lot of avant garde content in llct, such as Androidization. Just today I saw Xavier at TI find that merging of stable had a patch conflicting with llct Androidization content. So, it turns out that is a good example. I researched the conflict and found a thread from RMK rejecting the patch 96714b5dfe283cd8ab13aac1f9ccb565064af152 that seems to have come in by Androidization series via llct. http://lists.infradead.org/pipermail/linux-arm-kernel/2010-May/014116.html We decided to take the kernel.org stable version of the patch 6019ae78aa65afe273da8c0dfeed8e89fb5edf8f which removes some locking evil in the Androidization version, which RMK noted opened up a horrible race. Xavier then found a ghastly bug that had previously been impossible to track down disappeared. So we now know that 96714b5dfe283cd8ab13aac1f9ccb565064af152 we had been happily pushing out on everyone in llct-3.4 is a terrible idea, not just for TILT but any kernel that has it in will suffer from very hard to reproduce mm instability under stress, and needs reverting in favour of the version that went in kernel.org stable. But now we know about that flaw in llct-3.4 should we not do something about it? Yeah, at least for stable related changes I believe it'd make a lot of sense to push those to llct-3.4. Andrey, let's also coordinate the stable updates for llct-3.4 during this cycle, and then review the issues, if we get any, after the first merge/update. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: boot fail with omap4-panda.dts release 12.08
On Sun, Sep 9, 2012 at 5:41 AM, Amit Kucheria amit.kuche...@linaro.org wrote: On Sun, Sep 9, 2012 at 12:56 PM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Fri, Sep 7, 2012 at 6:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote: Hi, I am trying to boot kernel on panda board. I got the source from: http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;h=refs/heads/linux-linaro Following is my branch HEAD: commit 7f39bb7ab9591c6254e5930a00d762e4b37f08b2 Merge: 1d10459 8b29cd5 Author: Andrey Konovalov andrey.konova...@linaro.org Date: Mon Sep 3 17:10:24 2012 +0400 Merge branch 'tracking-ll-last-minute-fixes' into merge-linux-linaro I am using following for compilation: omap2plus_defconfig, omap4-panda.dts When i try to boot, kernel hangs after uncompressing linux... If i just remove the 0x815f from bootm command.. i.e. boot without dtb... it boots fine. Earlier i have flashed my card using linaro-media-create. Got, H/w package and devel rootfs from 12.08 release. Replaced uImage and board.dtb in /dev/mmcblk0p1 Unfortunately Panda is not supported by the LT at this tree yet, so the best thing to do is to try just the latest upstream kernel (from git.kernel.org) and see if you're able to reproduce the same issue with it (or just use the old 3.4 based tree from the LT). I believe Viresh has tried mainline as well. But some DT bits might be missing from there. Without DT, things start working and that is the route we'll take if we're unable to get help with LEB u-boot command-line parameters and 3.6 kernels on Pandaboard. We're coming up on 3.6 soon. Do we know when we'll have updated OMAP support? I think the LT started working on the 3.6 series already, but that would probably contain tons of patches and not the ones we might need for proper DT support. Andy, do you know if we could get a topic/branch with enough support for at least booting with proper DT support? It might be that we need to update the dtb file to reflect what is currently supported, and I believe that would help even more if we could fix upstream while 3.6 is not yet released. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: llct stable trees
Hey, On Thu, Aug 30, 2012 at 7:55 AM, Andy Green andy.gr...@linaro.org wrote: Hi - We've been getting some good mileage from the llct-based tilt-3.4 history tree the last months. However a couple of points have been raised by TI which really boil down to being about the deal with llct post-release. We know that it goes on mutating and tracking as it should, but the release-specific version, like linux-linaro-3.4 just sits there afaik. The points raised were: 1) Can we have linux stable point release content in tilt-3.4? Rather than my doing it, isn't it better to add it to llc-3.4 and merge it on the lt history tree periodically? That way every lt can get them from one place. I don't see why merging the stable release contents would be an issue. We could keep updating the tree based on stable-only releases, as long as we still have at least one Landing Team interested on consuming it. This would be another job that would probably be automated by Andrey's scripts. 2) What's the deal with things that were the latest and greatest at that time, ie, the best CMA or whatever series was in tracking, but after it got copied out to be linux-linaro-core-3.4, horrible bugs were fixed in linux-linaro-tracking? What's happening is that TI are sticking with these releases for a fair time as the basis for their release to customers. The problem is that the main goal of pushing new content and branches at the linux-linaro-tracking is mainly to help people getting their own stuff at upstream (by providing an unified tree which can then be used for QA and such). So, from the maintainer perspective, he'll always be moving his own stuff based on the latest upstream available, and that's why they are always integrated at the latest linux-linaro-tracking as well (mostly following upstream). If we decide to keep updating the older tree, that would probably need a substantial and not necessarily trivial work on backporting the new features and updates. Guess at least bugfixes would be ok, but I don't think would be trivial to identify just the fixes at the latest series. I can see there's tension between tracking-style fix it for the future, and backport to old and crusty things, there's also issue of testing, but there must be some cases where this makes some sense. Again people looking after the feature tree for llct are best placed to make those calls about, hm, that looks like it should maybe also go on the last couple of llc release trees. What do you think about this? I believe we can go on case by case, if we have people requesting us to backport new features or branches over previous releases. If you have any this point (or at least from TI), we can look and see what would be needed to update at the 3.4 based trees, but would also be nice if we can also get them involved on testing, so we know things are working properly. Do you have any idea about how long TI will keep this 3.4 based tree maintained and supported? I saw you were about to move on working at the 3.6 based tree, but don't know if that's just to keep things sane (and near upstream), or because TI wants to have another well supported tree. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Changing QA images to pre-built ones
Hey, Lately we've been producing and using the pre-built images for most of the use cases we have at Linaro. Seems that now that we finally got it working the way we expected, it'd also make sense to move the Ubuntu QA to start using the pre-built images instead of a combination of hwpack + rootfs. A few advantages about using pre-built images: - Single ID for the hwpack + rootfs combination - Less time to download, if you use zsync with a previous image as base - A lot faster to flash, as it'll use the maximum from your SD card into one single shot (dd) We're producing them daily nowadays, so I think we should just go and change the process. You can find all the pre-built images at http://snapshots.linaro.org/precise/pre-built/ Fathi, Paul, would that work for you both? Thanks! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Ubuntu Developer Week
Hey, Amber just reminded me about the the Ubuntu Developer Week, and pointed out that we'll have another one from Tue 28th Aug to Thu 30th Aug. Here's the blog post with more details: http://ubuntuclassroom.wordpress.com/2012/07/17/ubuntu-developer-week-planning-starts/ As we're also involved with topics involving Ubuntu development, it'd be nice if we could also be part of it, or at least request a few topics to be covered. In case you want to learn things specifically with Ubuntu, also let us know, so we can try to have someone to cover such topic. The sessions happens at IRC, and they are quite useful for people wanting to know more about how the development of Ubuntu happens. Now for the Dev Plat team, anything specifically you want to cover? Package cross build and multi-arch would be interesting to have. John, guess you could also demonstrate how we're packaging up our kernels, and how people can easily generate debian packages for any tree they want. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop][PATCH v3] conditionally disable pci if not supported
On Fri, Jul 13, 2012 at 2:02 AM, Rajagopal Venkat rajagopal.ven...@linaro.org wrote: Can someone consider this patch for merge? As we will have libpci available at most distros by default, isn't there a way of doing run-time detection instead of disabling it at build time? This is just because we'll be getting more and more ARM boards which have PCI-e as well, so we'll need to handle systems with and without any PCI available. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Ubuntu config fragment
On Wed, Jul 4, 2012 at 7:01 AM, Jon Medhurst (Tixy) t...@linaro.org wrote: Adding in Linaro Dev list for more visibility... On Tue, 2012-07-03 at 14:08 -0300, Ricardo Salveti wrote: On Tue, Jul 3, 2012 at 10:22 AM, Jon Medhurst (Tixy) t...@linaro.org wrote: Hi Ricardo I notice the new ubuntu.conf seems to contain everything including the kitchen sink. It has things which (as people found out at release time) breaks networking and MMC on vexpress (CONFIG_REGULATORS) and it contains drivers and other support for loads of hardware which isn't present on any Linaro supported device; and if it was, should go in the board specific config fragments, not the Ubuntu one. This config is basically provided by the official ubuntu kernel packages. We just removed a few specific devices, and some which would not make much sense, but other then that it's basically the same one you can find at your desktop. It's useful to enable all these additional configs for a bunch of reasons, like sharing with Ubuntu, enabling additional usb-based devices and such. We have tons of bugs requesting us to add stuff to the kernel config, and having this config fragment solves them all. If there's any hardware specific thing that could be disabled, we could just move to the board config. Regarding CONFIG_REGULATORS, I just decided to disable it at the vexpress.conf, as it only breaks stuff at vexpress (and makes sense to track it there). Well, the other boards which need regulators already enable it, so there's not really any need for Ubuntu to have this config. This particular issue isn't worth worrying about - we'll be adding regulators to vexpress to enable the single kernel image initiative - but it does seem to show up a general issue of the blurring of the purpose of config fragments; if Ubuntu enables a bunch of hardware support, what is the roll of the board config fragments? As we're currently using, the board config fragments would be the basic input for any hardware specific config set for that flavour. I agree here that we'd need to move the most we can from the ubuntu.conf to the boards config, so we could try to remove any hw specific config from there. This is currently done at this way as it was basically a copy from the current Ubuntu packages + a few removals. Unfortunately the list of configs are just huge to look at each and then update all the fragments later, as it'd require at least a kernel build for all flavours. Hopefully this will improve once we start building it daily, and cleaning it up even more. I noticed that the Ubuntu config was patched to remove ATH6KL with the commit title should be platform dependent. What was the reasoning for singling that driver out? That's a bug at the driver, which breaks the kernel build in case you're selecting something that you don't have available at your system. I don't remember the details, but we were forced to remove the module for now and just enable it at origen. I think that for vexpress at least, you have used ubuntu-minimal.conf for the 12.06 release and the current CI jobs. What is the plan going forward? To me, it would seem to make more sense to start with the minimal config and add things as they are found to be missing. We tried in the past, but that's just too painful. This time we decided to give the Ubuntu config a try, and then just disable what we know will not be used. If possible, we'd like to continue using it, and change as needed to disable whatever you think it shouldn't be there. OK, lets see how it goes. I would like to keep the ubuntu-minimal.conf around and supported, if for no other that selfish reasons as it produces a much smaller (quicker to load) kernel and quicker builds, which is useful for anyone wanting to basic kernel development and testing. (In an ideal world it could be used on nano and developer images but that isn't worth the complexity of a second kernel package and hwpack.) Yup, this config will still be maintained as well, basically for the same reasons you described :-) Let's see how it goes, but the goal is to clean the ubuntu.conf a bit, and update ubuntu-minimal.conf in case we're missing something there. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Ubuntu config fragment
On Wed, Jul 4, 2012 at 11:45 AM, Christian Robottom Reis k...@linaro.org wrote: On Wed, Jul 04, 2012 at 11:01:20AM +0100, Jon Medhurst (Tixy) wrote: I notice the new ubuntu.conf seems to contain everything including the kitchen sink. It has things which (as people found out at release time) breaks networking and MMC on vexpress (CONFIG_REGULATORS) and it contains drivers and other support for loads of hardware which isn't present on any Linaro supported device; and if it was, should go in the board specific config fragments, not the Ubuntu one. This config is basically provided by the official ubuntu kernel packages. We just removed a few specific devices, and some which would not make much sense, but other then that it's basically the same one you can find at your desktop. It's useful to enable all these additional configs for a bunch of reasons, like sharing with Ubuntu, enabling additional usb-based devices and such. We have tons of bugs requesting us to add stuff to the kernel config, and having this config fragment solves them all. If there's any hardware specific thing that could be disabled, we could just move to the board config. Regarding CONFIG_REGULATORS, I just decided to disable it at the vexpress.conf, as it only breaks stuff at vexpress (and makes sense to track it there). Well, the other boards which need regulators already enable it, so there's not really any need for Ubuntu to have this config. This particular issue isn't worth worrying about - we'll be adding regulators to vexpress to enable the single kernel image initiative - but it does seem to show up a general issue of the blurring of the purpose of config fragments; if Ubuntu enables a bunch of hardware support, what is the roll of the board config fragments? Generally, I'd like it that the distribution flavor avoided specifying hardware support config, as Tixy says. I realize this clashes with the goal to stay as close as possible to the stock distro configuration, but that's also not a end-goal in itself -- ideally, Ubuntu adopts config fragments themselves and leaves the hardware-specific configs to be enabled by board frags. That's our goal. Currently it's yet perfect because it's actually a pain to update all those config sets, as it'd require at least a kernel build (which could cause failures and other extra bugs). From my personal experience, working on updating configs is a PITA, as once you enable a few other configs, things can break heavily (as the config combinations are not properly tested still). Is there a way we can achieve this without causing more problems than we are solving? We're getting there. If you see the amount of bugs we were able to close but just using the current config sets you'd be surprised how useful it was for the previous cycle :-) This was the first time we used it, so not getting it perfect at first is expected ;-) Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Unable to build linux-linaro-tracking (3.4) with CPU_IDLE
Hey Andrey, While looking on publishing the kernel packages for Ubuntu based on llt, we noticed that it's unable to build in case CPU_IDLE is enabled. This is basically because it seems one patch is applied twice, and both adding the same content at the cpuidle.h file: $ git blame drivers/cpuidle/cpuidle.h 78bb15d5 (Colin Cross 2012-05-03 10:23:24 +0800 35) #ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED ... b667844d (Colin Cross 2012-05-03 10:37:35 +0800 65) #ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED Looking further, it seems that the culprit is b667844d, as you can see at http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=commitdiff;h=b667844d;hp=c92f149c5538a24b61673e5d09283b9e7d54eb05 Guess that we should not only revert it, but maybe fix on the tree that actually pulled the patch in. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: panda linaro kernel source code link
On Mon, Jun 25, 2012 at 9:57 AM, maqsood khan maqsoodkha...@gmail.com wrote: Hello Please send me the panda linaro kernel source code link, If possible to send source code please sende it otherwise send link only. We have a few different kernel trees that we use for Panda: 1 - http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=summary (tree produced by the TI Landing Team) 2 - http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;h=refs/heads/linux-linaro-tracking (tree with content from TI LT and Samsung LT) Is there any specific need from your side? Want pointers for kernel used at our LEBs? Ubuntu or Android? Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] New boot loader on Snowball
On Tue, May 15, 2012 at 10:21 AM, Mathieu Poirier mathieu.poir...@linaro.org wrote: On 12-05-15 01:04 AM, Ricardo Salveti wrote: On Mon, May 14, 2012 at 5:24 PM, Mathieu Poirier mathieu.poir...@linaro.org wrote: All, In our ongoing effort to move to an upstream-supported code base and booting the snowball with a device tree (DT) I have change the boot loader in the following android builds [1][2][3] to u-boot-linaro-stable [4]. Once the linaro-uboot is installed in a system it won't be able to boot images that were created at an earlier time. Say that build #500 has the new linaro-uboot and the image has been installed on the emmc. Once powered this uboot will not be able to boot build #499 that is installed on the mmc. To fix the problem, simply install build #500 on the mmc. This is because the mmc commands in the IK-uboot and the linaro-uboot differ. To install the linaro-uboot you *must* use the latest android-linaro-media-create found here [5] until the changes get merged in the official repository [6]. Something like: $ bzr branch lp:~mathieu.poirier/linaro-image-tools/linaro-image-tools Last but not least, the linaro-uboot is currently not able to save the environment variable block to the emmc card. That work is ongoing and the functionality expected to be part of 12.05. That's awesome, great work together with John! Did you have any issue on the kernel/userspace side with the new boot loader? Would be nice to test the ethernet support as well, so we could start supporting PXE booting :-) Thanks! I have not faced any issues other than having to lower the DT address in memory - Linux and Anddroid came up properly from thereon. I must specify that we currently don't boot using a DT. I updated the latest Snowball hwpacks to use u-boot-linaro, and it seems it's working nicely (didn't yet stress the system). To flash the boot loader (even when using with the SD card), be aware that you first need to generate the image for snowball_emmc and flash it with riff. You'll also notice that currently it'll not boot when using just the emmc, mostly because of https://bugs.launchpad.net/igloocommunity/+bug/1002099. Andy, seems the boot loader is good enough to be changed at the Snowball boards at the LAVA lab. If you generate a master image based on the latest hwpacks you should already get the latest u-boot-linaro for snowball by default. Let me know if you need any help coordinating the update there. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On Thu, May 10, 2012 at 10:43 PM, Andy Green andy.gr...@linaro.org 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 like two trees with conflicting versions of, I dunno, Mali driver, that needs planning to resolve. Or if people aren't using linux-linaro-core-tracking to get their CMA and so on, we need to know and start that migration. So, if I understood correctly, the llct would be the branch used to actually start producing a valuable path to get the unified tree in place. As you said, it seems we should start trying to experiment merging everything together and deciding what can actually be moved or not to the core-tracking branch. This way we'd probably move to the direction of having one real unified tree, instead of just maintaining linux-linaro over the time. So these are the useful branches I believe we'd end up having: - Linux Linaro Core Tracking: main tree used to develop the common changes across the different LTs/WGs and board flavours - Linux Linaro: tree with llct that is stabilised between rc releases, that's part of the LEB releases. This tree would also have additional topics from the LTs and WGs, in case they want to release it all into one single tree (releasing together with Linux Linaro is useful in a way we'll share QA and also helping identifying what other improvements might be needed in case of conflicts) - Linux Linaro Tracking/Unified: a tree that could contain llct + all the sauce maintained by all the LTs, to be used just for testing to help understanding what should be shared between LTs and be moved to core-tracking. This would help us getting to a position where we could identify early what are the conflicts, and work on getting a common solution with core-tracking before actually starting to send upstream. Would this fit your needs? Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: thermal issue on panda
On Wed, May 16, 2012 at 8:51 AM, Andy Green andy.gr...@linaro.org wrote: On 16/05/12 19:49, Somebody in the thread at some point said: On 14 May 2012 16:12, Andy Greenandy.gr...@linaro.org wrote: On 14/05/12 20:53, Somebody in the thread at some point said: On 14/05/12 20:45, Somebody in the thread at some point said: Hi Aneesh, Adding linaro-dev in the loop as someone else could be also interested I have reproduced my thermal error with a lava test so you can have a complete log available here: http://validation.linaro.org/lava-server/scheduler/job/18564/log_file As a summary of the problem, the panda board turns off during some sysbench tests because the SDRAM has exceeded its temperature limit Recently Sebastien Jan at TI found that on tilt-3.3, cpu_idle is interacting badly with smartreflex and the wrong Vcore can be selected for 4460. At the moment we disabled 1.2GHz on tilt-3.3, we think we have a fix + workaround and I'll update with it tomorrow. tilt-3.3 is updated with the fixes and workaround of disabling CPU_IDLE, please give that a try. Hi Andy, Is there any daily build hwpack that is available with this version on tilt-3.3 so I will be easier for me to test it? The Linaro Panda hwpack is based on tilt-3.3, but I don't know if it has taken in the latest patches yet (it should). The latest kernel packages are always published at our Kernel PPA, that is manually copied to the Overlay at least once a week. Check https://launchpad.net/~linaro-maintainers/+archive/kernel/+packages?field.name_filter=lt-omapfield.status_filter=publishedfield.series_filter=precise for the latest lt-omap kernel, based on the latest changes from Andy. Unfortunately the config changes are not propagated automatically yet, so I had to update the package config by hand to properly disable it. The new build should be available at the PPA in a few hours, and you can follow the progress at https://ci.linaro.org/jenkins/view/Ubuntu%20Packaged%20Kernels/job/create-packaged-linux-linaro-lt-omap-3.3/38/ and https://code.launchpad.net/~jcrigby/+recipe/linux-linaro-3.3-lt-omap-daily. Please check the package changelog to confirm the hash from the LT's tree. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: new IRC channel: linaro-lava
On Wed, May 9, 2012 at 7:36 AM, Andy Doan andy.d...@linaro.org wrote: We have a new channel on FreeNode for LAVA specific discussions: #linaro-lava This channel allows participants who are working with Linaro to join and just follow progress on LAVA. We should be using the same guidelines for deciding whether something belongs on #linaro or not as channels like #linaro-android currently do. Do we really need another extra channel? I believe the current list is already too much, and the lava folks are the ones that are the most active at #linaro currently (which is good :-). Seems that now we have the following IRC channels (could be even more): - #linaro - #linaro-lava - #linaro-android - #linaro-armhf - #linaro-kernel - #linaro-big.little - #linaro-multimedia Which is a bit too much, at least for me. -- Ricardo Salveti de Araujo ___ 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...
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. If you really need to send it to linaro-dev, would you mind at least giving more information and writing the email properly to avoid just using the subject? Thanks. -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-build's are failing, we're on it...
On Thu, May 10, 2012 at 1:20 PM, Christian Robottom Reis k...@linaro.org wrote: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. Well, just saying it's broken doesn't help much either. If you really want a better and more up-to-date place to show this info even IRC would be better. Is Twitter really that much better to inform us it's broken? I would have missed the news entirely, for one random data point. Better than email at least :-) While it it's useful, did it actually help you in any front? Twitter is the general place used by most of projects for status update, that's why I thought that it'd be the best way to go. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: pointless mail, (was Re: android-build's are failing...)
On Thu, May 10, 2012 at 1:37 PM, Wookey woo...@wookware.org wrote: +++ Christian Robottom Reis [2012-05-10 17:20 -0300]: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. I don't like subject-only content-free mails either, but this one wasn't entirely useless so I guess it's fair enough. Sure, I just think there are better places for it :-) Based on issues we had with LAVA and Jenkins at the previous cycle, if I had one email for every issue, I'd send at least 20 of them, which is useful but that still doesn't make me send them to the list. But as Ricardo's started an email-moan thread I'll just get something off my chest that's been bugging me for a while. Everytime we get a new person arriving a load of people send pointless mails to us _all_ saying 'hi there'. Those mails are great to send to the actual newbie, but not to everyone, _please_. Call me a miserable bastard, but really, we all get more than enough mail (especially from bloody launchpad :-), please try not to send this sort of spam to all - just people who will finds it useful. Ah, that's better... ++1 :-) Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: pointless mail, (was Re: android-build's are failing...)
On Thu, May 10, 2012 at 3:30 PM, Alexander Sack a...@linaro.org wrote: On Fri, May 11, 2012 at 12:24 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Thu, May 10, 2012 at 1:37 PM, Wookey woo...@wookware.org wrote: +++ Christian Robottom Reis [2012-05-10 17:20 -0300]: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. I don't like subject-only content-free mails either, but this one wasn't entirely useless so I guess it's fair enough. Sure, I just think there are better places for it :-) Based on issues we had with LAVA and Jenkins at the previous cycle, if I had one email for every issue, I'd send at least 20 of them, which is useful but that still doesn't make me send them to the list.] Actually, I think LAVA outage was announced. I poked for getting more status updates, so more mails would have been great. Same goes for ci.linaro.org ... if our CI service used for everything but android is not available, I want to get a mail that this is the case. Sure, but then I believe it'd be better to have another mailing list for such purposes. Linaro-dev is used for development related discussion, and it's the first most folks first subscribe to. I don't have the current number of folks participating at this list, but I'd prefer to still keep it dev-focused, and avoid off-topic discussions to try to keep it sane. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
On Tue, Apr 24, 2012 at 7:17 PM, Deepak Saxena dsax...@linaro.org wrote: On 24 April 2012 03:22, David Rusling david.rusl...@linaro.org wrote: All, I've created and shared the Connection Sessions spreadsheet, you can find it here - https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnK-Uyci_D20dFlUX1ZOVm5LWDVudkxJM1B0aS1FWWc#gid=0. Arwen is happy that that spreadsheet will be used for the session planning. I've added some topics and champions, please contact me to arrange more / discuss how best to organise things moving forward. If you want a hint, see what Amit's done... What are the responsibilities of the champion vs those of the session lead? Nothing, we're just creating some extra naming for the same things :-) Tiger, champion, all funny. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro-core-tracking tree created
On Tue, Apr 24, 2012 at 11:22 PM, Andy Green andy.gr...@linaro.org wrote: On 04/25/2012 03:43 AM, Somebody in the thread at some point said: Hi Andrey - I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what core implies). This Nice job, thanks for the new branch which definitely solves the chicken-and-egg. In fact it's going to be a great tracking fake future upstream staging point for all the good stuff being worked on that is not ready for upstream yet. It'll help the LT trees look more consistently like future upstreams where the vendor content is already in too, and let people use technologies like UMM easily long before they appear upstream. In that way hopefully we will provide +1, hopefully that will make the LT life easier (specially yours, as you're maintaining tons of patches). I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 - #24) and other little bits like Panda dt I could remove from our tree and use these common versions for. Otherwise it made very few conflicts compared to yesterday's Linus HEAD we were already on and the tree is as workable as it was. http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=summary Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional? We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing. However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree. We could just have the fragments per topic, and then the LT can decide either to add another fragment, or simply creating an entire different config to be used by default. Having everything in config fragments may help automating the builds, but I understand that having one defconfig might also help people that are consuming the tree directly. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
On Thu, Apr 19, 2012 at 12:53 PM, Christian Robottom Reis k...@linaro.org wrote: On Wed, Apr 18, 2012 at 10:43:56AM -0500, Zach Pfeffer wrote: While we're planning for connect, I'd like to suggest that we do away with team tracks all together and just have topic tracks. This would align with our topic based approach to things now, and would be a way to breakdown our silo's. The topic track would be lead by a topic champion. What do people think? I ask myself whether in practice it makes a difference. In practice, at Connect, you want somebody to own a certain set of sessions. Splitting this by team or by topic seems to have equal drawbacks on either side. I share the same opinion, as I'm that sure if it'll actually make a difference at the end of the day. Currently we were organising ourselves based on tracks (teams), and most tracks had their own projects, without shared effort with other teams. Even when we had shared sessions, they all went well, as most of the time people knew what had to be done (as we also had sessions and tracks that were cross teams, like most summits we had). Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
On Thu, Apr 19, 2012 at 4:47 PM, Deepak Saxena dsax...@linaro.org wrote: On 19 April 2012 12:15, Zach Pfeffer zach.pfef...@linaro.org wrote: On 19 April 2012 13:21, Deepak Saxena dsax...@linaro.org wrote: On 19 April 2012 08:53, Christian Robottom Reis k...@linaro.org wrote: On Wed, Apr 18, 2012 at 10:43:56AM -0500, Zach Pfeffer wrote: While we're planning for connect, I'd like to suggest that we do away with team tracks all together and just have topic tracks. This would align with our topic based approach to things now, and would be a way to breakdown our silo's. The topic track would be lead by a topic champion. What do people think? I ask myself whether in practice it makes a difference. In practice, at Connect, you want somebody to own a certain set of sessions. Splitting this by team or by topic seems to have equal drawbacks on either side. I'm not really sure if it makes a difference at the end of the day. Also, are we really talking about topic tracks or sessions here? W/o a CFP asking for externally developed presentations, I'm not sure we can end up with many talks about the same topics. We're planning on some training sessions for Linaro noobs and also for what I hope will be a large contingent of member engineers from China, India, and Korea offices. Should Training be a separate track? Also to clarify, regardless of whether we go down this path or not, we will still have time for hacking sessions? I think its actually makes the hacking sessions better. Why have team hacking rooms? We should have topic hacking rooms where each tiger team meets each other and starts to solve the problems they've talked about in the topic planning session. I dunno. I think a lot of the work we are doing in the groups does not directly overlap, and when it does (i.e, platform integration level) it's as easy as grabbing the right person. From my experience at prior connects, a lot of the decisions around common infrastructure happened in the hacking rooms where folks could gather around there computers and boards in a shared space. Spreading us across rooms by topic areas would loose that cohesiveness that I think is really key to the work that happens at Connect. +1 -- Ricardo Salveti de Araujo ___ 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
/WGs. You need to remember that this tree will be used and tested by mostly everyone working on kernel development inside Linaro. This will also be part of the LEBs and tested/verified by the QA team later on. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: won't someone please think of the users!?
Hey Rob, On Thu, Apr 5, 2012 at 11:10 PM, Clark, Rob r...@ti.com wrote: just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time Thanks for bringing this up here. There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge, the question is, should I upgrade?, what is fixed and what is now broken?. Linaro is doing some great upstream work, and enabling features on these boards, and it is good to showcase that, but I'm not really sure the best way to do this is rush that into the next monthly release and break things for all the new users of their shiny new xyz-board. I tend to think that part of the problem is that the cadence of monthly releases is too fast for any sort of stability. Perhaps we should think more along the lines of releases roughly every quarter (potentially with betas in between). I don't think we should strictly adhere to a time based release cycle, but we should call it a final/stable release when it actually is so. There is a reason that the linux kernel uses an approx 3 month release cycle, but doesn't stick to that dogmatically when things aren't really at release quality yet. I think the main problem here is the constant change of direction from the platform group. Initially the Android/Ubuntu LEB (Linaro Evaluation Builds) were meant to be somehow stable, always delivering the best working components, even if they were not reflecting the latest upstream. On example of that is that we were still releasing the Pandaboard hwpacks based on the old tilt-linux-linaro-3.1, because it was the only one that was stable enough and had multimedia working out of the box. With this model, we attracted quite a few users, we presented our builds at numerous places (ELC, Connect, UDS, etc), got people at Linaro just to deal with community and always pointed the users to use them as reference, because it would always be somehow stable and working. Then at previous Connect Linaro decided that we would not worry about stabilising our LEBs any more, and start delivering just the latest components available, even if they would not be working with any other hw acceleration piece, which naturally made all of our users unhappy about it, getting us to the current situation. This is why I also thought we should go back and rethink how we would be dealing with our releases. The email I sent last week about stable/unstable LEBs is basically to cover the same issue. One thing we should do, if we're planning on working with *users*, is to always provide a working (stable) LEBs together with a unstable one, so if they decide to help and contribute to Linaro, they would always have the possibility to grab the latest stuff from the unstable PPA (on Ubuntu side). Now about the monthly releases I don't really have a strong opinion. I believe releasing the LEBs at every quarter might improve things, if we decided to get working (stable) LEBs out of the door. Doing it quarterly would give us have enough time to think about which components we'd be working on, and prepare the enablement properly (one thing we need to think about is that most of the builds require some sort of binary blob, and a one month-time frame is almost impossible for the Vendor to respin a newer version if needed). But, we do still need a place for latest-and-greatest bleeding edge for folks who want to check out what we are working on. One approach, for example for ubuntu releases, we could have a release and trunk PPA for bleeding-edge.. that way folks looking for bleeding-edge can get it, and folks looking for it just works are not screwed. I'm not quite sure what android equivalent would be, but I guess we could figure something out. This gives folks in board specific channels like #pandaboard who are trying to help new users something to reliably point them at without having to worry if they are giving bad advice to recommend a linaro filesystem. And updates do not have to be tied to a time-based schedule. If something is broken for feature x for board y in the release PPA, then as soon as it is fixed (and if it doesn't break board z), then push an update to the release PPA. But maybe big new features shouldn't immediately go to the release PPA without some soak time first in the trunk PPA. It is great to be enabling new features, but for someone new to the arm platform I don't want to just frustrate and scare them off. This unstable/development place needs to be around, because that's also our main baseline when we're developing and testing our components. That's why for me the stable release would basically be a snapshot of a working unstable one, in a way we could later protect the users to avoid total breakage with a simple update. Cheers, -- Ricardo Salveti de Araujo
Re: won't someone please think of the users!?
On Fri, Apr 6, 2012 at 6:05 AM, Wookey woo...@wookware.org wrote: +++ Clark, Rob [2012-04-05 21:10 -0500]: just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge, You make some good points. The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things. It might be the same thing, but for me the question is really do we care about users and we want people to use our LEBs?. If we assume the LEBs are just a bunch of evaluation images to be used internally to help improving the development and testing, then you could simply say that we're not any kind of distro. Now if we decide to have people using and consuming our LEBs (what I believe we do), then we need to think a bit further, and assume some extra responsibilities. We don't want to be a full distro, as we want to be flexible enough to break things once a while, but we really need to be aware that once we get users running our images, they will *expect* some sort of stability, putting us back as we were a distro :-) Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC] Stable/Development Overlay for Ubuntu LEB
Hi, Following some complains and issues with the way we're currently maintaining our main Overlay PPA, I'd like to propose a new way to produce the Ubuntu LEBs, by generating Stable and Unstable/Development focused images. At the moment all the development work for the Ubuntu LEB happens at 2 different repositories: - Staging PPA (https://launchpad.net/~linaro-maintainers/+archive/staging-overlay): test and development related builds, usually broken but a common place to share the packages before making them official at the LEB. - Overlay PPA (https://launchpad.net/~linaro-maintainers/+archive/overlay): main overlay repository, and common location for hardware enablement packages and released components by Linaro (e.g. Linux Linaro, glmark2, etc). Using just one single main repository seems fine until you have at least one board fully enabled, with dependencies going from Kernel to user space, as the enablement usually doesn't keep up with the latest development and updates produced by the Landing Teams and Working Groups. One simple case is what happened with Pandaboard, that had a fully enabled userspace (OpenGL ES2.0 and HW Decode), but needed to be locked down with an specific kernel and user space packages. Differently than what we have with Android images, we don't just produce one single tarball where the user is unable to change or extend. At our side we're maintaining a real distro, and updating/upgrading packages is expected. Once we release a fully enabled build, we can't simply break it down with newer updates because will make all users unhappy, which is bad for the users and for Linaro (as it's hard to compare hw enablement, produce demos and such). At the same time, we don't want to be locked down into specific versions, because one of our goals is to make sure the hardware enablement is always matching the latest kernel/components available. Working with upstream based components helps us with development and validation, and also identifying what is still needed to get everything working from time to time. Looking at the problem, here's what I think it'd help to fix the situation: 1 - Overlay PPA becomes the main repository for basic platform development, without having any hardware specific package (not even the kernel): This PPA would be used by all the images we're producing (stable/unstable), as all the changes would be just related with the distribution. Once we get newer components that are not related with hardware enablement, and not critical enough to break compatibility across images, we would be integrating them at this repository (e.g. powertop, glmark2, libpng, libjpeg-turbo, etc). 2 - We create the Development Overlay PPA, to be the main place carrying the hardware related pieces, like kernel, drivers and multimedia: This would be the main PPA used during our own development, always containing the latest kernel packages from the Linux Linaro and Landing Team trees. Here we could also integrate components related with hardware enablement that are not for prime use yet, but would help people that are always looking for the latest stuff available. 3 - Create a set of Stable PPAs for every board we're officially supporting: Here the goal would be to have a single place where we can push the enablement related changes that are known to be working. At the Pandaboard case this PPA would contain the 3.1 based kernel with SGX and HW video decoding working out of the box. Once a new snapshot based on the development release is known to work in a satisfactory way, we would simply just copy them over the Stable PPA for the respective board. This would also help the cases where we have packages with hw enablement changes that conflict with other boards. So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway. I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA. Please let me know what you all think, as we could have this model working with the 12.04 Ubuntu Precise based images already. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Stable/Development Overlay for Ubuntu LEB
On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria amit.kuche...@linaro.org wrote: On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway. I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA. What would the monthly release be based on? The stable PPA? We'd be producing the release based on both the stable and dev/unstable PPA. Stable for users that just want to have the latest userspace working with an enabled kernel, and unstable for brave users and linaro developers that are mainly concerned about upstream support and enablement there. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Stable/Development Overlay for Ubuntu LEB
On Tue, Apr 3, 2012 at 10:30 AM, Amit Kucheria amit.kuche...@linaro.org wrote: On Tue, Apr 3, 2012 at 3:40 PM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria amit.kuche...@linaro.org wrote: On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway. I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA. What would the monthly release be based on? The stable PPA? We'd be producing the release based on both the stable and dev/unstable PPA. Stable for users that just want to have the latest userspace working with an enabled kernel, and unstable for brave users and linaro developers that are mainly concerned about upstream support and enablement there. This will certainly be useful for a certain category of users and increase our community size. However, I worry about a situation where everybody settles down on the stable release and the unstable versions don't get much testing. Can there be some commitment from those responsible for HW enablement (kernel porting, binary blobs, etc.) to provide periodic refreshes of these components? e.g. every 3 months. IOW, some predictable forward momentum for the stable releases instead of continuing divergence similar to internal BSPs. Yeah, that's the goal. Our effort inside Linaro is to always enable and test the unstable release, so we can make sure our development is progressing properly, and that the vendor is also publishing the blogs at a useful schedule. The stable would be initially a working snapshot of the unstable PPA, to be used by end users. We would not spend resources validating it over the cycles, as I'd expect the maintenance to be more a community driven effort, that can be owned by the vendor itself, or just by community users/developers. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Release 12.03 Postmortem Summary
On Mon, Apr 2, 2012 at 8:29 PM, David Zinman david.zin...@linaro.org wrote: Postmortem and lessons learned for Linaro's release 2012.03 https://wiki.linaro.org/Cycles/1203/Release/Review Any reason why we just have the post-mortem notes for the platform group? Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Ubuntu LEB 12.03 RC images
On Tue, Mar 27, 2012 at 10:37 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hi, A little bit later than usual, but here it goes the announcement of the 12.03 RC images. This time we got a bit delayed because we're finally generating and maintaining all the kernel packages ourself, and getting them in sync with Launchpad is something that still needs some improvement. This release should be the last one based on Ubuntu Oneiric (and ARMEL), including the latest XBMC release and the usual kernel and package updates. From 12.04 on we will be supporting only builds based on Ubuntu Precise (12.04, ARMHF), so we should see quite many nice improvements there (for early access, check the builds at https://ci.linaro.org/jenkins/view/Ubuntu%20Build%20Service/). You can find our current test cases at https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu, and the 12.03 RC builds (for all boards and image flavors) at http://snapshots.linaro.org/oneiric/, with build id 20120327-1 for hwpacks and 20120327-0 for the rootfs (nano, developer, alip, ubuntu-desktop and linaro-tv-xbmc). For our main boards we also have a testing spreadsheet, were we publish the official release testing, done by the dev platform engineers. You can find the links at https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you can find the bug reports from the test cases by looking at the QA page tag links). Fathi will be coordinating all respin requests in the next following days at linaro-release m-l, and the final image will be published this thursday, at releases.linaro.org. Ok, after a few rounds of testing, issues with ci.linaro.org and Launchpad, I'm finally able to publish the current status of the RC images, and the respin requests for tomorrow. RC Images that worked as expected, without needing extra fixes: - Ubuntu Desktop: http://snapshots.linaro.org/oneiric/linaro-o-ubuntu-desktop/20120327/0/images/tar/ - Nano: http://snapshots.linaro.org/oneiric/linaro-o-nano/20120327/1/images/tar/ (1 as 0 didn't build due archive instabilities) - Alip: http://snapshots.linaro.org/oneiric/linaro-o-alip/20120327/0/images/tar/ - Developer: http://snapshots.linaro.org/oneiric/linaro-o-developer/20120327/1/images/tar/ (1 as 0 didn't build due archive instabilities) RC Hwpacks that also worked as expected, without needing extra fixes: - 3.3 LT Snowball: http://snapshots.linaro.org/oneiric/lt-snowball-oneiric/20120327/1/images/hwpack - 3.3 LT Vexpress A9: http://snapshots.linaro.org/oneiric/lt-vexpress-a9-oneiric/20120327/1/images/hwpack - 3.3 Linux Linaro Pandaboard: http://snapshots.linaro.org/oneiric/lt-panda-oneiric/20120327/1/images/hwpack - 3.3 Linux Linaro Pandaboard X11 Base: http://snapshots.linaro.org/oneiric/lt-panda-x11-base-oneiric/20120327/1/images/hwpack RC Hwpacks that weren't tested yet: - 3.1 Linux Linaro EfikaMX: http://snapshots.linaro.org/oneiric/efikamx-oneiric/20120327/1/images/hwpack/ - 3.1 Linux Linaro iMX51: http://snapshots.linaro.org/oneiric/imx51-oneiric/20120327/1/images/hwpack/ - 3.1 LT MX5: http://snapshots.linaro.org/oneiric/lt-mx5-oneiric/20120327/1/images/hwpack/ - 3.3 Linux Linaro Igep: http://snapshots.linaro.org/oneiric/igep-oneiric/20120327/1/images/hwpack/ - 3.3 Linux Linaro Overo: http://snapshots.linaro.org/oneiric/overo-oneiric/20120327/1/images/hwpack/ RC Hwpacks currently broken without a solution yet: - 3.3 Linux Linaro Vexpress A9: http://snapshots.linaro.org/oneiric/vexpress-a9-oneiric/20120328/1/images/hwpack/ - 3.3 Linux Linaro Beagleboard (John Rigby is still debugging): http://snapshots.linaro.org/oneiric/omap3-oneiric/20120327/1/images/hwpack/ Respin request for images: - LinaroTV-XBMC: http://snapshots.linaro.org/oneiric/linaro-o-linarotv-xbmc/20120328/3/images/tar/ - Reason: Fixes at the XBMC package, update to the final 11 Eden release. Respin requests for hwpacks: - 3.2 LT MX6: http://snapshots.linaro.org/oneiric/lt-mx6-oneiric/20120329/1/images/hwpack/ - Reason: Fixes to improve the booting experience, but still not yet fixing it completely :-( - 3.1 LT Pandaboard: - http://snapshots.linaro.org/oneiric/lt-panda-oneiric/20120329/0/images/hwpack/ - http://snapshots.linaro.org/oneiric/lt-panda-x11-base-oneiric/20120329/0/images/hwpack/ - Reason: Kernel updates, config updates and working hw video decoding again. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Ubuntu LEB 12.03 RC images
On Thu, Mar 29, 2012 at 7:14 AM, Tushar Behera tushar.beh...@linaro.org wrote: On 03/29/2012 12:58 PM, Ricardo Salveti wrote: On Tue, Mar 27, 2012 at 10:37 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hi, A little bit later than usual, but here it goes the announcement of the 12.03 RC images. This time we got a bit delayed because we're finally generating and maintaining all the kernel packages ourself, and getting them in sync with Launchpad is something that still needs some improvement. This release should be the last one based on Ubuntu Oneiric (and ARMEL), including the latest XBMC release and the usual kernel and package updates. From 12.04 on we will be supporting only builds based on Ubuntu Precise (12.04, ARMHF), so we should see quite many nice improvements there (for early access, check the builds at https://ci.linaro.org/jenkins/view/Ubuntu%20Build%20Service/). You can find our current test cases at https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu, and the 12.03 RC builds (for all boards and image flavors) at http://snapshots.linaro.org/oneiric/, with build id 20120327-1 for hwpacks and 20120327-0 for the rootfs (nano, developer, alip, ubuntu-desktop and linaro-tv-xbmc). For our main boards we also have a testing spreadsheet, were we publish the official release testing, done by the dev platform engineers. You can find the links at https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you can find the bug reports from the test cases by looking at the QA page tag links). Fathi will be coordinating all respin requests in the next following days at linaro-release m-l, and the final image will be published this thursday, at releases.linaro.org. Ok, after a few rounds of testing, issues with ci.linaro.org and Launchpad, I'm finally able to publish the current status of the RC images, and the respin requests for tomorrow. RC Images that worked as expected, without needing extra fixes: - Ubuntu Desktop: http://snapshots.linaro.org/oneiric/linaro-o-ubuntu-desktop/20120327/0/images/tar/ - Nano: http://snapshots.linaro.org/oneiric/linaro-o-nano/20120327/1/images/tar/ (1 as 0 didn't build due archive instabilities) - Alip: http://snapshots.linaro.org/oneiric/linaro-o-alip/20120327/0/images/tar/ - Developer: http://snapshots.linaro.org/oneiric/linaro-o-developer/20120327/1/images/tar/ (1 as 0 didn't build due archive instabilities) RC Hwpacks that also worked as expected, without needing extra fixes: - 3.3 LT Snowball: http://snapshots.linaro.org/oneiric/lt-snowball-oneiric/20120327/1/images/hwpack - 3.3 LT Vexpress A9: http://snapshots.linaro.org/oneiric/lt-vexpress-a9-oneiric/20120327/1/images/hwpack - 3.3 Linux Linaro Pandaboard: http://snapshots.linaro.org/oneiric/lt-panda-oneiric/20120327/1/images/hwpack - 3.3 Linux Linaro Pandaboard X11 Base: http://snapshots.linaro.org/oneiric/lt-panda-x11-base-oneiric/20120327/1/images/hwpack RC Hwpacks that weren't tested yet: - 3.1 Linux Linaro EfikaMX: http://snapshots.linaro.org/oneiric/efikamx-oneiric/20120327/1/images/hwpack/ - 3.1 Linux Linaro iMX51: http://snapshots.linaro.org/oneiric/imx51-oneiric/20120327/1/images/hwpack/ - 3.1 LT MX5: http://snapshots.linaro.org/oneiric/lt-mx5-oneiric/20120327/1/images/hwpack/ - 3.3 Linux Linaro Igep: http://snapshots.linaro.org/oneiric/igep-oneiric/20120327/1/images/hwpack/ - 3.3 Linux Linaro Overo: http://snapshots.linaro.org/oneiric/overo-oneiric/20120327/1/images/hwpack/ RC Hwpacks currently broken without a solution yet: - 3.3 Linux Linaro Vexpress A9: http://snapshots.linaro.org/oneiric/vexpress-a9-oneiric/20120328/1/images/hwpack/ - 3.3 Linux Linaro Beagleboard (John Rigby is still debugging): http://snapshots.linaro.org/oneiric/omap3-oneiric/20120327/1/images/hwpack/ Respin request for images: - LinaroTV-XBMC: http://snapshots.linaro.org/oneiric/linaro-o-linarotv-xbmc/20120328/3/images/tar/ - Reason: Fixes at the XBMC package, update to the final 11 Eden release. Respin requests for hwpacks: - 3.2 LT MX6: http://snapshots.linaro.org/oneiric/lt-mx6-oneiric/20120329/1/images/hwpack/ - Reason: Fixes to improve the booting experience, but still not yet fixing it completely :-( - 3.1 LT Pandaboard: - http://snapshots.linaro.org/oneiric/lt-panda-oneiric/20120329/0/images/hwpack/ - http://snapshots.linaro.org/oneiric/lt-panda-x11-base-oneiric/20120329/0/images/hwpack/ - Reason: Kernel updates, config updates and working hw video decoding again. Thanks, Status of Origen is missing in the list :( Sorry, forgot to add it as it was working fine, so still using the RC image as base: RC Hwpacks that also worked as expected, without needing extra fixes: - 3.3 LT Origen: http://snapshots.linaro.org/oneiric/leb-origen-oneiric/20120327/1/images/hwpack/ Thanks! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev
Another Friday, another ARM Porting Jam!
Hello, Continuing on the ARM Porting effort to fix the remaining issues with Precise, we'll be having the ARM Porting Jam this friday as well! The main focus for this Friday, besides the usual FTBFS issues described at http://people.linaro.org/~rsalveti/arm-porting-queue/arm-porting-queue-report.html, is porting the most packages we can to be multi-arch compatible. This will allow us to increase the list of packages we can easily cross-compile using multi-arch. Wookey got a quite long list of things to do at https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/MultiarchCrossBuildStatus, so please have a look and make sure to get in touch with him at #linaro @ freenode if you need any extra help. Happy porting! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ARM Porting Jam this Friday again!
Hello, Once again Linaro will be having the the ARM Porting Jam, which will happen during this friday. We had quite a good feedback and quite many folks working on FTBFS related issues last Friday, but we still have a long list to fix before the release. If you're interested on helping fixing FTBFS issues and other porting bugs related with ARM, please check the bug list at http://people.linaro.org/~rsalveti/arm-porting-queue/arm-porting-queue-report.html and join us at #linaro/#ubuntu-motu at freenode today! Thanks! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro embedded Linux distro?
On Tue, Feb 21, 2012 at 7:37 AM, Wookey woo...@wookware.org wrote: +++ Kalle Vahlman [2012-02-21 11:06 +0200]: 2012/2/21 Amit Kucheria amit.kuche...@linaro.org Well minimal is all I care... not buildroot. But I would expect it to be 20M in size. Does that make sense or am i speaking gibberish :-) ? Doesn't the nano flavour take care of this? Nano rootfs is 33M compressed tarball which expands to 95M. That's small, not embedded ;) quite. You can get a debian-based distro down to about 56MB uncompressed: http://www.emdebian.org/grip/index.html (using the grip bloat-removal tools), or 90Mb without (corresponds to 'nano'). I guess something we can work on at the Nano image is to try to at least use the same grip tools to make it at least a bit smaller. Guess something we can work during 12.04, once we switch officially to armhf and Ubuntu precise-based builds. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ARM Porting Jam this Friday!
Hello, Together with Fix Friday and Ubuntu Global Jam, Linaro will be also having the the ARM Porting Jam today, to help addressing the current issues on Ubuntu related with the ARM port. If you're interested on helping fixing FTBFS issues and other porting bugs related with ARM, please check the details at http://rsalveti.wordpress.com/2012/03/02/arm-porting-jam-this-friday/ and join us at #linaro/#ubuntu-motu at freenode today! Thanks! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Ubuntu LEB 12.02 RC images
On Tue, Feb 21, 2012 at 4:08 AM, Ricardo Salveti
ricardo.salv...@linaro.org wrote:
Fathi will be coordinating all respin requests in the next following
days at linaro-release m-l, and the final image will be published this
thursday, at releases.linaro.org.
Respin request for:
linaro-o-ubuntu-desktop:
Link:http://snapshots.linaro.org/oneiric/linaro-o-ubuntu-desktop/20120223/1/images/tar/linaro-o-ubuntu-desktop-tar-20120223-1.tar.gz
(still building)
Bugs fixed:
* Ubuntu Audio doesn't work on snowball:
https://bugs.launchpad.net/linaro-ubuntu/+bug/932076
Comment: Needed to have sound working by default at Snowball (with jack).
Changelog for linaro-maintainers's overlay PPA (series oneiric) since
2012-02-21 00:00:00
pulseaudio (1:1.1-0ubuntu4~linaro8) oneiric; urgency=low
* debian/patches/0101-Adding-profile-config-for-snowball.patch:
- Fixing invalid channel map
-- Ricardo Salveti de Araujo ricardo.salv...@linaro.org Thu, 23
Feb 2012 00:53:27 -0300
Debdiff (low risk, doesn't affect any other platform):
diff -u pulseaudio-1.1/debian/patches/series
pulseaudio-1.1/debian/patches/series
--- pulseaudio-1.1/debian/patches/series
+++ pulseaudio-1.1/debian/patches/series
@@ -11,6 +11,9 @@
0016-nodisplay-autostart.patch
0017-Hack-around-a-bug-in-the-core-causing-volumes-not-to.patch
+# Linaro specific board config/fixes
+0101-Adding-profile-config-for-snowball.patch
+
# Jack detection patches
0601-Introduce-available-concept-for-ports-and-communicat.patch
0602-Turn-device-ports-into-reference-counted-objects.patch
only in patch2:
unchanged:
---
pulseaudio-1.1.orig/debian/patches/0101-Adding-profile-config-for-snowball.patch
+++ pulseaudio-1.1/debian/patches/0101-Adding-profile-config-for-snowball.patch
@@ -0,0 +1,96 @@
+commit 023e9f5c24d0c4721b5c33e49f8b4a3d699ba249
+Author: Ricardo Salveti de Araujo ricardo.salv...@linaro.org
+Date: Wed Feb 22 19:08:43 2012 -0300
+
+Adding profile config for snowball
+
+Patch provided by Lee Jones lag
+
+Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@linaro.org
+
+diff --git a/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
b/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
+index 45a146b..1688f34 100644
+--- a/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
b/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
+@@ -33,4 +33,7 @@ SUBSYSTEMS==usb, ATTRS{idVendor}==045e,
ATTRS{idProduct}==02bb, ENV{PULSE_
+ ATTRS{vendor}==0x10de, ENV{PULSE_PROFILE_SET}=extra-hdmi.conf
+ ATTRS{vendor}==0x8086, ENV{PULSE_PROFILE_SET}=extra-hdmi.conf
+
++# Specific config for ST-Ericsson's Snowball board
++ATTR{id}==U8500card, ENV{PULSE_PROFILE_SET}=snowball.conf
++
+ LABEL=pulseaudio_end
+diff --git a/src/modules/alsa/mixer/profile-sets/snowball.conf
b/src/modules/alsa/mixer/profile-sets/snowball.conf
+new file mode 100644
+index 000..ffafc00
+--- /dev/null
b/src/modules/alsa/mixer/profile-sets/snowball.conf
+@@ -0,0 +1,54 @@
++# This file is part of PulseAudio.
++#
++# PulseAudio is free software; you can redistribute it and/or modify
++# it under the terms of the GNU Lesser General Public License as
++# published by the Free Software Foundation; either version 2.1 of the
++# License, or (at your option) any later version.
++#
++# PulseAudio is distributed in the hope that it will be useful, but
++# WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
++# General Public License for more details.
++#
++# You should have received a copy of the GNU Lesser General Public License
++# along with PulseAudio; if not, write to the Free Software Foundation,
++# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
++
++; ST-Ericsson Snowball based board generic static setup
++;
++; See default.conf for an explanation on the directives used here.
++
++[General]
++auto-profiles = no
++
++[Mapping default-mapping-output]
++description = : headset output for Snowball (default)
++device-strings = hw:%f,1
++channel-map = front-left,front-right
++direction = output
++
++[Mapping mapping-output-hdmi]
++description = : av8100 HDMI output for Snowball
++device-strings = hw:%f,0
++channel-map = front-left,front-right
++direction = output
++
++[Mapping default-mapping-input]
++description = : headset input for Snowball (default)
++device-strings = hw:%f,2
++channel-map = front-left,front-right
++direction = input
++
++[Profile output:default-mapping-output+input:default-mapping-input]
++description = Headset profile for Snowball (default)
++output-mappings = default-mapping-output
++input-mappings = default-mapping-input
++priority = 50
++skip-probe = yes
++
++[Profile output:mapping-output-hdmi+input:default-mapping-input]
++description = HDMI profile for Snowball
++output-mappings = mapping-output-hdmi
++input-mappings = default-mapping-input
++priority = 50
++skip-probe = yes
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 254b7bf..37115f3
Ubuntu LEB 12.02 RC images
Hey, As usual, here it goes the announcement of the 12.02 RC images. This time it's later than usual because we had an issue with our builder (offspring), but seems to be all solved now (thanks to Fathi). This release includes a newer version of Unity (2d and 3d), XBMC and for Pandaboard's OpenGL ES drivers. Other than that we also had minor fixes for other boards, with improvements at the audio support as well. You can find our current test cases at https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu, and the 12.02 RC builds (for all boards and image flavors) at http://snapshots.linaro.org/oneiric/, with build id 20120221-1 for hwpacks and 20120221-0 for the rootfs (nano, developer, alip, ubuntu-desktop and linaro-tv-xbmc). For our four main boards we also have a testing spreadsheet, were we publish the official release testing, done by the dev platform engineers. You can find the links at https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you can find the bug reports from the test cases by looking at the QA page tag links). Fathi will be coordinating all respin requests in the next following days at linaro-release m-l, and the final image will be published this thursday, at releases.linaro.org. Please also be sure to publish any bug report with the RC images against https://launchpad.net/linaro-ubuntu, or just contact us at #linaro @ freenode (https://wiki.linaro.org/MeetTheTeam#Developer_Platform). Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Developer Platform, Plans and Goals for Connect
Hey, Additionally to the sessions we'll have over the week, here are another 2 important links for our group: - Plans and Goals for Linaro Connect Q1.12: https://wiki.linaro.org/Platform/DevPlatform/Connect/Q1.12/Plans - Hacking Sessions: https://wiki.linaro.org/Platform/DevPlatform/Connect/Q1.12/HackingSessions If you're interested on having a 'hands-on' at any topic described at this wiki pages, please visit room Salon 4. We have all needed hardware there, from boards to monitors, so we can easily get on hacking. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Connect Sessions from the Developer Platform Team
Another important one :-) Maximizing the usefulness of the LEB for customers and members https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-maximizing-usefulness-leb Goal is to get feedback from people consuming our LEBs, so we can understand better what we need to improve to make them even more useful. Thanks, On Tue, Jan 31, 2012 at 1:11 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hey folks, As usual, follows a list of the sessions the Developer Platform Team will lead at this Connect: Ubuntu LEB and LAVA: Current status and future planning for proper image testing and validation https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-lava-and-ubuntu-leb-testing-validation Improvements and future discussions for LTs and the Ubuntu LEB https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-lt-platform-discussions Packaged Kernel CI: Current Status and Next Steps https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-packaged-kernel-ci-next-steps Sysroots: Automation, Maintenance and Future Work https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-sysroots-automation-maintenance U-Boot-Linaro Future Planning https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-u-boot-linaro-future-future-planning Developer Platform: Future Planning https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-dev-plat-future-planning Cross Build with Multi-Arch: Current state and future planning https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-cross-multi-arch-support Please make sure you subscribe to the ones you'd like to attend, and also add yourself as 'essential' to the ones you really like to participate (so the scheduler can find a free spot that's also available for you). This is not yet the final list, as we'll probably have additional ones until the end of the week, but you can always look for all the sessions related with the Developer Platform Team at https://blueprints.launchpad.net/linaro-ubuntu?searchtext=linaro-platforms-q112 Thanks, -- Ricardo Salveti de Araujo -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What our customers want from Android
On Wed, Feb 1, 2012 at 6:00 AM, Bharathi Subramanian bharathi.l...@gmail.com wrote: Hi, I feel, Linaro should maintain only 2 versions - stable and unstable external source. instead of maintain staging, tracking, landing, mainline etc .. I understand internally lot of activities may happen with partners. But for external people, it is should be simple. As of now, only people who are closely tracking the Linaro development can start using the code quickly. Others cannot and it is not the case with AOSP. While I see that it's useful for people to use the outcome of the Android team to create products, I believe it's quite hard to keep both stable and unstable with the goals and the resources we have. As Zack said, these costumers don't actually care much if they are running the latest stuff available, as long it behaves similarly as AOSP. I believe we might have only two options here: have something awesome to show that everybody will want no matter what (even Google), or improving the user/developer experience a lot, making it even better and easier than just grabbing the sources from AOSP. But one thing is clear for me, If we think that we can't reach any of these goals, for me it'd make sense to drop the whole stable discussion, and focus even more on trying to get stuff at upstream, so when people decide to use AOSP, they will already consume what Linaro helped producing (what is the *real* stuff IMHO, as it'll improve the *whole* thing). Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Bugs report for Freescale i.MX53 Loco board run Android and Ubuntu with Linaro 11.1212.01
2012/2/1 Haitao Zhang haitao.zh...@linaro.org: 宋超，你好 2012/2/1 orientsusong orientsus...@126.com: Dear Linaro Dev Team, Thanks a lot for your kindly and attentions, firstly! i test the Linaro Version 11.1212.01 for MX53 Loco board this two months in Shenzhen, China. Bug 1: Boot Time too long, it needs 1 minutes past 53 seconds for Ubuntu on Linaro Version 11.1212.01. and Android 4.0.1 and 4.0.3 boot time needs 2 minutes past 55 seconds. Yes, we already working on those bootup time issues. That's interesting, Android taking more time to boot than Ubuntu. Does this boot means having something available at the UI level, or having the system useful for the users? Bug 3: HDMI sound interrupt. Bug 4: HDMI Display not fine and some noise signal on the monitor with Ubuntu 11.10 over Linaro 12.01. For enable HDMI display, you will need to modify your u-boot parameter manually, and for audio output from HDMI, we only supported for limited device. So please let me know what kind of display you'd like to test with. I don't remember having to set up the u-boot env manually to make it to work with HDMI (at least with Ubuntu). If this is still an issue, is it also happening with latest upstream? Don't see it'd be too hard to probe and enable the display at runtime. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: potentially bug list
On Tue, Jan 31, 2012 at 5:39 PM, Mario marietto2...@gmail.com wrote:
I forgot to say that I've installed Linaro Ubuntu Desktop 3.1.1.8 on a
Pandaboard ES.
2012/1/31 Mario marietto2...@gmail.com:
Hello.
Since I'm not experienced,I would like to talk with you about this
potentially bug list :
1) I can't use another desktop manager except Unity.
I made 3 modifications to accomplish the task,but with no success :
a) I ran update-alternatives --config x-session manager and I chosen
lxde or xfce as default DM
b) I modified the file : ~/.xinitrc adding exec startlxde/xfce4
c) When Unity starts automatically,I choose lxde or xfce4,but my
choice is not remembered for the next login.
In theory when you do the login at another session, and then logout,
it'll save your previous session.
Maybe lightdm is confused and not getting the previous session name
from your user.
Try this to enable Unity-2d, for example (as root):
rm -f /home/linaro/.dmrc
rm -rf /var/cache/lightdm
rm -rf /var/lib/AccountsService/users
dbus_user_path=`dbus-send --system --type=method_call --print-reply
--dest=org.freedesktop.Accounts /org/freedesktop/Accounts
org.freedesktop.Accounts.FindUserByName string:$DEFAULT_USER | awk -F
\ {'print $2'}`
dbus-send --system --type=method_call --print-reply
--dest=org.freedesktop.Accounts ${dbus_user_path}
org.freedesktop.Accounts.User.SetXSession string:ubuntu-2d
And also remove the 'user-session' line from /etc/lightdm/lightdm.conf/
Reboot, and see if that works for you. Here's a way to check if you're
running unity-3d or 2d:
https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu#Unity_3D
3) I think there are graphic problems,the mouse pointer does not
disappear correcly. On the picture attached you can see three
pointers.
Yeah, that's a known issue and I'm still working on getting it fixed.
Hopefully this will be done in the next few days.
Cheers,
--
Ricardo Salveti de Araujo
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: potentially bug list
On Wed, Feb 1, 2012 at 11:44 PM, Ricardo Salveti
ricardo.salv...@linaro.org wrote:
On Tue, Jan 31, 2012 at 5:39 PM, Mario marietto2...@gmail.com wrote:
I forgot to say that I've installed Linaro Ubuntu Desktop 3.1.1.8 on a
Pandaboard ES.
2012/1/31 Mario marietto2...@gmail.com:
Hello.
Since I'm not experienced,I would like to talk with you about this
potentially bug list :
1) I can't use another desktop manager except Unity.
I made 3 modifications to accomplish the task,but with no success :
a) I ran update-alternatives --config x-session manager and I chosen
lxde or xfce as default DM
b) I modified the file : ~/.xinitrc adding exec startlxde/xfce4
c) When Unity starts automatically,I choose lxde or xfce4,but my
choice is not remembered for the next login.
In theory when you do the login at another session, and then logout,
it'll save your previous session.
Maybe lightdm is confused and not getting the previous session name
from your user.
Try this to enable Unity-2d, for example (as root):
rm -f /home/linaro/.dmrc
rm -rf /var/cache/lightdm
rm -rf /var/lib/AccountsService/users
dbus_user_path=`dbus-send --system --type=method_call --print-reply
--dest=org.freedesktop.Accounts /org/freedesktop/Accounts
org.freedesktop.Accounts.FindUserByName string:$DEFAULT_USER | awk -F
\ {'print $2'}`
Sorry, here $DEFAULT_USER should be 'linaro', or any other user you
created at your image.
Cheers,
--
Ricardo Salveti de Araujo
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Bug Management with Linaro Ubuntu Project
Hi, After working on generating a bug report web page for our arm-porting-queue effort (mostly my wife actually), I decided to create a similar bug report web page to make the life easier for people managing the bugs affecting the Linaro Ubuntu project. The link: http://people.linaro.org/~rsalveti/linaro-ubuntu-bugs/linaro-ubuntu-bugs-report.html There you can easily find all the bugs that are currently opened against the 'linaro-ubuntu' project, and also check which ones are related with a Landing Team (or Igloo Community for ST-E). Besides being able to easily sort any column, you can also find the test cases tags that are produced when executing our release tests. For people wanting to understand better the test tags, and which test cases we're maintaining, please check at https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu (mostly manual atm, but we're working on porting them to LAVA asap). For the LT projects, please also make sure you open a bug task (also affects project at Launchpad) against 'linaro-ubuntu' if it's related with our Ubuntu LEB images in any sort. That way we can also have your bug at our radar. Thanks! -- Ricardo Salveti de Araujo ___ 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
Hey, On Wed, Feb 1, 2012 at 1:54 PM, Guilherme Salgado guilherme.salg...@linaro.org wrote: Hi folks, 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? Awesome, that looks a lot better from what we have now, and easier to read. Just a few questions and comments: 1 - Are we tracking bugs that are not assigned to a milestone? 2 - What will happen when the cycle is finished, but there are still WIs to be done? 3 - While I see that is useful to see what was already done for a cycle, for me I believe this view should behave similarly as a TODO list, that once something is done, it's either removed from the view, or changed in a way it'll not get much attention as the ones that are still to be done. 4 - Do you know if a similar page, but for a team, will also be available? Thanks -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Connect Sessions from the Developer Platform Team
Hey folks, As usual, follows a list of the sessions the Developer Platform Team will lead at this Connect: Ubuntu LEB and LAVA: Current status and future planning for proper image testing and validation https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-lava-and-ubuntu-leb-testing-validation Improvements and future discussions for LTs and the Ubuntu LEB https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-lt-platform-discussions Packaged Kernel CI: Current Status and Next Steps https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-packaged-kernel-ci-next-steps Sysroots: Automation, Maintenance and Future Work https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-sysroots-automation-maintenance U-Boot-Linaro Future Planning https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-u-boot-linaro-future-future-planning Developer Platform: Future Planning https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-dev-plat-future-planning Cross Build with Multi-Arch: Current state and future planning https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-cross-multi-arch-support Please make sure you subscribe to the ones you'd like to attend, and also add yourself as 'essential' to the ones you really like to participate (so the scheduler can find a free spot that's also available for you). This is not yet the final list, as we'll probably have additional ones until the end of the week, but you can always look for all the sessions related with the Developer Platform Team at https://blueprints.launchpad.net/linaro-ubuntu?searchtext=linaro-platforms-q112 Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Initial list of Blueprints for 12.02, from the Developer Platform Team
Hi guys, As we're almost done with 12.02 planning, I'd like to share the current blueprints we intend to work during the 12.02 cycle: https://launchpad.net/linaro-dev-platform/+milestone/12.02 I know this is a quite short cycle, as we'll have the Linaro Connect, Android Builders and ELC, but I really hope to get most of the blueprints done during Connect's hacking sessions. Some interesting topics we'll cover this month: * Adding the USB-Host enablement test cases at LAVA * Start testing and validating the daily Linaro Native and Cross GCC packages * Enable ARMHF Precise based builds * Update XBMC to the latest 11.0 Beta release (currently Beta 2) * Sysroot build automation * Backporting of Unity 5, bringing the latest development from the GWG * Finalizing the Cross Buildd with Multi-Arch support And a few other bug fixes :-) Hope you enjoy ;-) Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announcing Linarotv-xmbc image
On Wed, Jan 25, 2012 at 11:55 PM, Hui Zhang son...@gmail.com wrote: Hi Tom, Can Linarotv-XBMC work well on boards with hardware video acceleration but WITHOUT hardware OpenGL ESv2 acceleration? (BTW, the board has 2D hardware acceleration) Thanks in advance! Not right now, as our initial goal was to get it working fully accelerated at Panda. We're planning on updating it to Eden beta2 in the next few weeks, and I hope we get it at least generic enough for other use cases. Problem right now is that using or not opengles is a build-time decision, so we might need some tweaks at the packaging side (to provide both), or enabling run-time detection. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Ubuntu LEB 12.01 RC images
On Tue, Jan 24, 2012 at 9:46 PM, John Rigby john.ri...@linaro.org wrote: the panda results page it view only for me, I'm sure I must be doing something wrong Could be the multiple login issue with the google services. The first time I tried opening the origen spreadsheet I was logged as rsalv...@gmail.com instead of ricardo.salv...@linaro.org, so I had to switch accounts to have write access. Another thing you could do is to request write access again, and we could simply authorize you, if that's the issue (but I just confirmed that you should have access). Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Ubuntu LEB 12.01 RC images
Hey folks, Just like to announce the Ubuntu LEB 12.01 RC images, and the pointers for people that want to check the testing progress and such (or even helping testing them). Currently we're tracking our test cases at https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu (most of them requires manual effort at the moment, but we're improving that with LAVA in the following weeks). If you think about any other important test case that we might be missing here, please let me know and we can add it at our testing cycle. You can find all the 12.01 RC builds (for all boards and image flavors) at http://snapshots.linaro.org/oneiric/, with build id 20120123-1. For our four main boards we also have a testing spreadsheet, were we publish the official release testing, done by the dev plat engineers. You can find the links at https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you can find the bug reports from the test cases by looking at the QA page tag links). Fathi will be coordinating all respin requests in the next following days at linaro-release m-l, and the final image will be published this thursday, at releases.linaro.org. Please also be sure to publish any bug report with the RC images against https://launchpad.net/linaro-ubuntu, or just contact us at #linaro @ freenode (https://wiki.linaro.org/MeetTheTeam#Developer_Platform). Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: PulseAudio / ARM NEON
On Thu, Jan 12, 2012 at 2:42 PM, Peter Meerwald pme...@pmeerw.net wrote: Hello, I've just posted some patches with ARM NEON code to the pulseaudio-discuss mail list (http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-January/012611.html) -- this might be of interest to Linaro a stand-alone version of the code is in a Mercurial repo at http://pmeerw.net/hg/pa-neon -- feedback and testing welcome That's great, thanks for the heads up. We'll see what we can do, but I'd really like to make these patches available at our LEB, so we can use your customizations and also help testing them for you. Thanks! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
On Wed, Jan 11, 2012 at 2:24 AM, Amit Kachhap amit.kach...@linaro.org wrote: Hi Zach/Ricardo, All the thermal Kconfigs are enabled in https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig. Great, thanks. Guess we just need to make sure we're in sync with every LT tree (android and package level too). Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Monthly Release Thoughts
On Wed, Jan 11, 2012 at 1:09 AM, Andy Green andy.gr...@linaro.org wrote: On 01/11/2012 03:34 AM, Somebody in the thread at some point said: Hi - I had some thoughts and a suggestion this morning about the monthly release cycle that I'd like to share. Perhaps I'll get booed off the stage, perhaps not. I'm sure it can be improved on. There is a great deal of stress around what blueprints fit into what monthly release boundary. For deliveries like the LEB that combine the fruits of our Linaro labors this makes great sense. Outside of the process for LEB creation and release, I'd like to suggest it's less than efficient and creates a bit of stress as we have the monthly rush to make the release dates. PMs and TLs continually have to be watching for what will and what won't be making dates that fit with the LEB. This passes on the stress to the engineering team, causes some late night hack-a-thons which in turn I believe caused us to rush software what was less than ready to be included in a LEB. I'm sure we all have examples we could point to. It seems there's some confusion here. The WGs/LTs deliveries aren't tight to LEB monthly releases, you have your own goals. It's fine to skip a monthly release (like many have done) or provide a snapshot of your current work (like LTs have done). I think there is confusion inside Linaro about what these releases are. What you're saying is correct, but it doesn't always reflect what's happening on the ground. For LT the 'beat' we work to is kernel cycle and as you say monthly release is something downstream of what we are anyway doing for us, it should just be a staging post for what popped out of our sausage machine recently. However people responsible for making the releases feel under pressure to maximize what's in there for a deadline that's not inherently meaningful, when at times when we may be dedicated to having to do something else do to lack of sync with our underlying 'beat'. At its worst, the drama of having a release leads to a false sense of urgency and bad decisions that are not in Linaro's overall interest. Once we agree that with CI we'll always try to avoid having regressions (bugs on new features and development is expected), I don't see why the LEBs would not just follow the LT trees directly. But, unfortunately, when the features are closely related with binary blobs from the vendor, that is not always the truth, and things can be quite broken over the time. Guess we should probably thing better on how we're integrating the content produced by the LTs and the LEBs. While I agree that we want to the release snapshot to be something stable and working without critical regressions, that's not the case atm, and fighting against this situation will for sure just add a lot of pressure at folks all around. For other projects than Kernel, I don't see our cycle as an issue, as once something is released (or in a shape we can merge at our LEBs), we can then plan the integration work and work on getting them available at our images (by staging PPA and such, as described by Tom). Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Initial support of HW video decode and XBMC at the Ubuntu LEB on a Pandaboard
Hey folks, Just to point out my post about the work we've been doing to have hw video decode and XBMC to work with a Pandaboard, using the Ubuntu Linaro Evaluation Builds. http://rsalveti.wordpress.com/2012/01/06/hw-video-decode-and-xbmc-ubuntu-linaro/ If you follow the instructions you should have hw video decode support and XBMC without any other step. At the moment there's still and annoying sink issue with XBMC, but we hope to get it fixed soon (at least once Rob Clark get a few spare cycles ;-). We hope to also have a set-top box image by the end of this cycle, that should use XBMC by default. Please give it a try and let us know about any other issue you may find. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Initial support of HW video decode and XBMC at the Ubuntu LEB on a Pandaboard
On Fri, Jan 6, 2012 at 9:33 AM, Avik Sil avik@linaro.org wrote: On Friday 06 January 2012 04:59 PM, Amit Kucheria wrote: On Fri, Jan 6, 2012 at 6:22 AM, Ricardo Salveti rsalv...@rsalveti.net wrote: Hey folks, Just to point out my post about the work we've been doing to have hw video decode and XBMC to work with a Pandaboard, using the Ubuntu Linaro Evaluation Builds. http://rsalveti.wordpress.com/2012/01/06/hw-video-decode-and-xbmc-ubuntu-linaro/ If you follow the instructions you should have hw video decode support and XBMC without any other step. At the moment there's still and annoying sink issue with XBMC, but we hope to get it fixed soon (at least once Rob Clark get a few spare cycles ;-). We hope to also have a set-top box image by the end of this cycle, that should use XBMC by default. Please give it a try and let us know about any other issue you may find. Wow! Awesome work. Looks like I might just be able to retire my old XBOX. Can it do 1080p videos too? It can, but the playback is not smooth at the moment. I'm pushing a newer version at the repository with one extra patch from Rob that should improve things a bit. At least I'm now able to play most of the videos just fine :-) Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Updated Pulse Audio + alsa-lib for 11.12
On Sun, Dec 18, 2011 at 10:05 PM, Andy Green andy.gr...@linaro.org wrote: On 12/19/2011 12:17 AM, Somebody in the thread at some point said: Hi Ricardo, With working HDMI output on the original panda board, and Wei's new release of patches to alsa-lib and pulseaudio, I've updated both alsa-lib and pulseaudio for 11.12 in ppa:linaro-maintainers/overlay. Sound on the panda over HDMI from my testing works out of the box. It's not perfect but it works. I will repeat this same test with my imx53 shortly. For all on the dev list, be aware that audio is in a state of flux and while we'd like to avoid defects they are likely. The Multimedia WG is putting substantial effort into having a just works level of quality for supported boards. A very bit thank you is in order for Wei Feng for his hard work on 11.12! Good job! One small sound for an ARM board, but a big noise for Linaro when we can say, It just works. That's cool, still want to test the support, but nice to know that it's working at Panda. That is indeed good news, thanks a lot guys. About Panda UCM, last week I noticed though that there is different wiring on input side between 4430 Panda (line in goes to analogue headset mic inputs on twl6040) and 4460 Panda (line in goes to FM analogue inputs). So this week I plan to make changes to the onboard audio driver to change its alsa card name based on what board it's on, with a view to elaborating out the UCM directories so the recording case is handled correctly depending on the board. At the moment, the two recording cases in UCM for Panda anyway are broken so hopefully there'll be fixes for that too. Do you have any idea when you'll be pushing the new patches? Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: lava-deployment-tool is now (also) on github
On Wed, Dec 7, 2011 at 6: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. I'm not much concerned about you moving the code hosting to github, as we already have quite a few projects using git instead of bzr (just check git.linaro.org). What I just didn't understand much is the relation with git.linaro.org, as now it sees we have 2 official git hosting places for projects. I know that technically using github is a lot easier, as setting up a git repository at git.linaro.org can be a real pain. Are we taking any official position on this front? Are we going to support both? Why can't we just use one single place for codehosting? We also need to thing that this is quite confusing for our users, as the code most of the time is what we end up delivering, and trying to have it all in one place makes things a lot easier for our consumers :-) Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Cross compiling chromium-browser the multiarch way
Hi, On Wed, Dec 7, 2011 at 1:04 PM, Riku Voipio riku.voi...@linaro.org wrote: Hi, Another package that was requested to be able to cross-compiled was chromium. Now this is possible also, following the instructions at: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/ChromiumCrossCompile The starting point was chromium not building on arm at all, fortunately it was quite easy to fix. While easy, it was time consuming as I had to build chrome a few times natively. With builds taking around 20h on panda. Meanwhile, on dual-core (hypertheaded, so kinda 4-core) Intel i5 M 520, cross-compile took around 1.5h. When the native builds were failing at the final linking stage, the value of cross-compiling was surely becoming clear ;) That's nice, thanks for making it to work :-) I just had one issue while installing all the dependencies, that is with the package libglib2.0-0:armel: Setting up libglib2.0-0:armel (2.30.0-0ubuntu4linaro6) ... /var/lib/dpkg/info/libglib2.0-0:armel.postinst: 37: /usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas: not found /var/lib/dpkg/info/libglib2.0-0:armel.postinst: 40: /usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules: not found /var/lib/dpkg/info/libglib2.0-0:armel.postinst: 40: true: not found dpkg: error processing libglib2.0-0:armel (--configure): subprocess installed post-installation script returned error exit status 127 For some reason it seems that the || true statement didn't work as expected at the postinst script. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Master images are a mess
On Wed, Dec 7, 2011 at 4:36 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: W dniu 07.12.2011 18:44, Paul Larson pisze: On Wed, Dec 7, 2011 at 10:01 AM, Zygmunt Krynicki zygmunt.kryni...@linaro.org mailto:zygmunt.kryni...@linaro.org wrote: Hi, sorry for the topic, I wanted to catch your attention. This is a quick brain dump based on my own observations/battle with master images last week. 1) Unless we use external USB/ETH adapters then cloning a master image clones the mac address as well. This has serious consequences and I'm This doesn't ring true. We do have different mac addresses, even on boards without flash and on-board ethernet. How does it work? As far as I know mac address is burned in boot.scr, if you copy that (and tell me we don't) then we get duplicates. Update: after a quick discussion on #linaro it seems that the mac address is actually burned into the hardware pack and lmc does not make one (at least not for panda). I have not verified this yet but if true then _all_ pandas with a given hwpack build get the same mac. As I said at #linaro, there's no default mac address at any hwpack we produce. If you have a boot.scr with a mac address pre-defined, then you either customized your own hwpack or it's a bug. I believe we already have a valid and unique mac address for all the boards we currently support, even if they rely on being calculated during boot time (like the hack that Andy did for panda). Let me know if you're still having issues with random mac address every time you boot your board. The process isn't *that* hard. It's essentially just a nano image, a couple of extra packages installed, and add a few partitions. However, I do agree with the sentiment that this should be automated as much as possible. 2) Running code via serial on the master image is a mess. It is very fragile. We need an agent on the board instead of a random master image+serial shell. The agent will expose board identity, capabilities and standard APIs to LAVA (notably the dispatcher). The same API, if done sensibly, will work for software emulators and hardware boards. Agent API for a software emulator can do different things. Dispatcher should be based on agent API instead of ramming the serial line. This sounds like a good connect topic. It has some advantages, but also a lot of things to address. While I agree that a different implementation might be a nice thing, I also see that it can be quite complicated and still not yet sure if this will actually help much. I know serial is not the best interface you have, but it's the only one that we know it works for all the boards we have :-) Once you start relying on ethernet or such, then you can easily be blocked by issues at the kernel/userspace side. Unfortunately it seems that serial is the most reliable interface you may have with these boards. 3) The master image, as we know it today, should be booting remotely. The boot loader can stay on the board until we can push it over USB. em The problem is getting it to a state that we can push it over usb for every board. Not all boards support this, and the ones that do sometimes have issues with the tools to make it possible. I don't want to push 100% over usb but pushing 99.9 (all except to boot loader) works for all boards as far as I know. This would give us controllable master image (hell we could install tests before turning the power on). I guess this will only be an issue with Origen, as to make ethernet to work at the boot loader you also need to have USB support (kind of similar as Panda). For the others I believe it should just work (if not, it's a bug). Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Master images are a mess
On Thu, Dec 8, 2011 at 12:49 AM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: W dniu 08.12.2011 02:54, Ricardo Salveti pisze: On Wed, Dec 7, 2011 at 4:36 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: I don't want to push 100% over usb but pushing 99.9 (all except to boot loader) works for all boards as far as I know. This would give us controllable master image (hell we could install tests before turning the power on). I guess this will only be an issue with Origen, as to make ethernet to work at the boot loader you also need to have USB support (kind of similar as Panda). For the others I believe it should just work (if not, it's a bug). Getting it to work with panda would be a major milestone. I don't treat boards as equal as they are not equal. Last time I checked uboot has lots of USB and ethernet support so we might be able to eventually do it assuming actual bugs in both linux kernel and uboot for origen are fixed. For Panda at least you should have everything you need: 1 - USB booting for SPL/U-Boot with USB SPL support; 2 - Ethernet support at U-Boot with TFTP and PXE support; 3 - Unique mac address at both u-boot and kernel (same one, same code to calculate it); Once you make it work with Panda, we can later then try to have the same support at the other boards we have. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Master images are a mess
On Thu, Dec 8, 2011 at 2:16 AM, Andy Green andy.gr...@linaro.org wrote: On 12/08/2011 10:56 AM, Somebody in the thread at some point said: On Thu, Dec 8, 2011 at 12:49 AM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: W dniu 08.12.2011 02:54, Ricardo Salveti pisze: On Wed, Dec 7, 2011 at 4:36 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: I don't want to push 100% over usb but pushing 99.9 (all except to boot loader) works for all boards as far as I know. This would give us controllable master image (hell we could install tests before turning the power on). I guess this will only be an issue with Origen, as to make ethernet to work at the boot loader you also need to have USB support (kind of similar as Panda). For the others I believe it should just work (if not, it's a bug). What is a bug, bootloader not supporting Ethernet? USB support (ehci) at the bootloader and then the driver for the device you want to use. u-boot supports quite a few ethernet devices, so I believe making usb to work would probably be the only thing needed. Getting it to work with panda would be a major milestone. I don't treat boards as equal as they are not equal. Last time I checked uboot has lots of USB and ethernet support so we might be able to eventually do it assuming actual bugs in both linux kernel and uboot for origen are fixed. For Panda at least you should have everything you need: 1 - USB booting for SPL/U-Boot with USB SPL support; 2 - Ethernet support at U-Boot with TFTP and PXE support; 3 - Unique mac address at both u-boot and kernel (same one, same code to calculate it); Once you make it work with Panda, we can later then try to have the same support at the other boards we have. Do all the supported SoC ROMs support USB booting, or workable alternative? Even if not fully able to boot from USB, we can have at least a minimal u-boot/SPL that would deliver DFU support, this way you could still push another boot loader later on. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Developer Platform UDS/Connect sessions
Hi, As part of the UDS/Connect planning, we got quite a few blueprints that I believe will probably be useful for both Linaro and Ubuntu. If you're interested in any blueprint, just please make sure you're subscribed before the end of this week, so you can have higher changes to avoid any conflict. Blueprint List: Ubuntu kernel packages across flavors - current issues and future planing https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-ubuntu-kernel-packages-across-flavors Linaro release process improvements https://blueprints.launchpad.net/linaro-project-management/+spec/linaro-general-release-process-improvements-lcq4.11 Training: Working, developing and contributing with the Ubuntu Linaro Evaluation Builds https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-training-lc4.11-ubuntu-working-with-leb LJT integration optimization - LJT vs jpeg v8 https://blueprints.launchpad.net/libjpeg-turbo/+spec/linaro-gfxmm-libjpeg-turbo U-Boot-Linaro future planning https://blueprints.launchpad.net/u-boot-linaro/+spec/linaro-platforms-lc4.11-u-boot-linaro-future-planning Linaro Ubuntu LEB: Improving the relationship with Ubuntu https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-improving-ubuntu-upstream-relationship Ubuntu LEB: Improving demo experience (use cases and examples) https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-improving-demo-experience Ubuntu LEB: How to support dbg packages like ubuntu does with ddebs https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-ubuntu-leb-dbg-pkgs-support Ubuntu LEB: extend LAVA usage https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-extend-lava-usage Ubuntu LEB: creating a multitouch enabled demo https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-ubuntu-leb-multitouch-demo Remaining work for a fully functional toolchain CI loop at Ubuntu LEB https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-toolchain-ci-remaining-work Simplifying the image beyond ubuntu core https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-simplify-image-beyond-ubuntu-core How to improve the work between the Android and Dev Platform teams https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-ubuntu-and-android Future planning and brainstorming for the developer platform team https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-dev-platform-future-planning See you all at Orlando! :-) Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [REMINDER] Linaro 11.10 release dates and deliveries
On Mon, Oct 10, 2011 at 12:47 PM, David Zinman david.zin...@linaro.org wrote: Hi, This is a mail sent to remind you the coming release dates: * Linaro 11.10 components release is October 20nd, 2011. * Linaro 11.10 RC images is October 24th, 2011. * Linaro 11.10 release is October 27th, 2011. Components release will be announced this week. As we have people working all around the world, would be good to have a common UTC time for the releases, so the platform can coordinate the integration with the component releases. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Oneiric image directory on snapshots.linaro.org
On Fri, Oct 7, 2011 at 3:17 PM, James Westby james.wes...@canonical.com wrote: On Fri, 7 Oct 2011 13:09:23 -0500, Paul Larson paul.lar...@linaro.org wrote: On Fri, Oct 7, 2011 at 11:35 AM, James Westby james.wes...@canonical.comwrote: Note that Paul requests keeping the suffixes, but I guess that's predicated on renaming the top level. The main reason I like having a suffix of some kind is so that it's obvious which series it's from by the filename. If someone includes that filename (without path) in a bug, or just has it lying around their system, it's good to be able to determine that kind of information having just the name of the file. Ah, changing the directory names on snapshots.linaro.org doesn't change the filenames of the images/hwpacks, so that's ok. Having said that though, if they are different then it means that we have to keep the requests to IS for new syncs to snapshots.linaro.org. Another thing that this brings up is landing team hwpacks. Am I correct in assuming that those kind of exist outside of any series? Would it, perhaps, make more sense to separate hwpacks and images out at the top directory, and break it down by series under that? They do exist at a series, but the series isn't really important (the same is true to some extent for non-LT hwpacks too.) The series is important as it can also contain normal packages, like drivers and any other that would help enabling the platform. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: All recent hwpack builds on snapshots.linaro.org are failing...
On Fri, Oct 7, 2011 at 3:22 PM, James Westby james.wes...@canonical.com wrote: On Fri, 7 Oct 2011 17:40:42 +0100, Dave Martin dave.mar...@linaro.org wrote: Hi all, does anyone know why all the hwpack builds have started failing? See, for example: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/panda/20111006/0/build-log.txt ...a similar problem seems to have affected the recent builds for every hwpack. Looks like some build-depends package is not getting installed properly. There was a problem with an OS upgrade on the slaves, which led to that one package failing to configure, which then prevented the build from even starting (crashing as it was installing the build tool.) That was fixed yesterday, but no-one triggered rebuilds, so they all were fixed with the rebuild that started an hour or so ago. There is now just one failure: http://snapshots.linaro.org/build/lt-s5pv310-natty/20111007/0/build-log.txt which is a problem with the config or the packages, as it's asking for a package that doesn't exist, so this is not a systemic problem, but a problem with that Samsung LT hwpack. AFAIK this hwpack is not supported anymore, so it should be fine to just disable the build. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)
On Thu, Oct 6, 2011 at 7:28 AM, Mans Rullgard mans.rullg...@linaro.org wrote: On 6 October 2011 06:44, Fathi Boudra fathi.bou...@linaro.org wrote: On 6 October 2011 00:43, Mans Rullgard mans.rullg...@linaro.org wrote: On 5 October 2011 18:35, Christian Robottom Reis k...@linaro.org wrote: On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote: Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future. Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more. There is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option, left out of earlier versions due to patent issues. Since nobody uses this mode, supporting it is irrelevant. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. What is relevant is, however, that v8 is significantly slower than v6 in the default configuration. I don't remember if this slowdown was present already in v7. According to Bill Allombert, v8 support more image format Yes, v8 (and v7) supports the arithmetic coding mode defined in the JPEG spec. Since nobody ever uses this, it is not important. If you mean more non-JPEG formats are supported by the cjpeg/djpeg tools, that is of little importance since nobody uses those in production either. and provide a higher image quality. Maybe. I have not seen any tests to substantiate this claim. When *decoding* v8 actually produces poorer results in some cases due to using dct-based upscaling of chroma planes (this is also the cause of the slowdown). There's probably benefit to v8 if a distribution switch from v6 to v8. Distributions sometimes do things without good reasons. And it seems it's not yet clear for distro maintainers which libjpeg is the best one to use. A few projects already use it by default, like Firefox, Chromium, Fedora, but it seems we still need to prove the benefits by showing the numbers across platforms. Would like to have at least one session for this topic at UDS, comparing the results and discussing Debian's plans, so we can agree and try the transition as soon P cycle starts. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)
On Thu, Oct 6, 2011 at 1:06 PM, Kurt Taylor kurt.tay...@linaro.org wrote: On 6 October 2011 09:38, Christian Robottom Reis k...@linaro.org wrote: On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote: There are only 3 left from the list that are bounded enough to consider: 1) Compressed data api into ALSA - driver specific kernel work and ALSA/ASoC plumbing, prob not a good fit for mmwg yet I think this is worth sketching out. Who could actually sit down and write a good description (even if without AC) so I can share the topic. 2) ALSA port of ST-E drivers - also prob not a good fit for mmwg, already proposed as a possible requirement for the new STG team in that mail thread They don't use ALSA at all? And wouldn't this be better done within the ST-Ericsson LT? As I understand it, they do not use ALSA. I had originally proposed it be done in the ST-E LT, but Lee proposed that it be moved to the STG team (full email thread). Hm, it also sounds more related with the ST-E LT than STG, even now that the LT is fully back. 3) End to end audio tests for integration - new proposal by Alexander, blueprints are already created, investigation underway, but I can write up a papyrs page for it if we need to take it in front of the TSC Hmm, this is actually already represented inside a drafted blueprint: https://linaro.papyrs.com/page/4119/LINUX2011-ENABLEMENT-TESTING/# Excellent, I will delete my papyrs page for it then. Great, and this is something we'll need to work together (Platform, MMWG and Validation), but it's ok for the Platform to lead it. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.09 Release Candidate
On Tue, Sep 27, 2011 at 3:17 AM, Alexander Sack a...@linaro.org wrote: On Tue, Sep 27, 2011 at 5:23 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hi Fathi, Sorry for the top post. Any specific reason why using the build from 0926 as the RC instead of 0927? This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release. Due to release manager timezone etc. we aim for cutting ready to RC images by 1600 UTC on Monday. Can't we do the base-files update on Friday. Are there any other packages like kernel that need more up-front integration time? The base-files package was just one example, but it's also common to integrate other components, mostly from the landing teams. This time, for example, we were just able to push the TI LT kernel after the 0926 build, as the tree was properly rebased and tagged at friday. Cheers, -- Ricardo Salveti de Araujo ___ 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
staging for Snowball: https://android-build.linaro.org/builds/~linaro-android/staging-snowball-11.09-release/#build=1 * Installation Instructions: https://wiki.linaro.org/Platform/Android/ImageInstallation Known Issues * ARM SMP scheduler performance bug (Ubuntu/PandaBoard) https://launchpad.net/bugs/709245 * Snowball USB not working (Android/Ubuntu/Snowball) https://launchpad.net/bugs/804091 * fails to mount system and user partition interminttently (Android/Snowball) https://launchpad.net/bugs/823313 * Combined V2/V3 Snowball hwpack (20110905) fails with l-m-c (Ubuntu/Snowball) https://launchpad.net/bugs/842973 * GLK3.0 allows processes to overwrite page frame data (Ubuntu/Snowball) https://launchpad.net/bugs/849005 You can find the complete list of known issues for the 11.09 release at: https://launchpad.net/linaro-android/+milestone/11.09 https://launchpad.net/linaro-ubuntu/+milestone/11.09 When filling new bugs, please check if it's not yet reported. You can use: https://bugs.launchpad.net/linaro-android/+bugs?orderby=-datecreated https://bugs.launchpad.net/linaro-ubuntu/+bugs?orderby=-datecreated -- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Kernel WG Weekly Status report for week ending 2011-09-02
On Thu, Sep 1, 2011 at 6:53 PM, Mounir Bsaibes mounir.bsai...@linaro.org wrote: Enclosed please find the link to the Weekly Status report for the kernel working group for the week ending 2011-08-26. == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-08-29 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-09-01 == Summary, for details see the Status Report == ... * John Stultz Implemented the proposed config tooling for config fragments, as will be presented at Plumbers conference John S, can you give more details or at least pointers to your talk, so we can see if this can be useful for our kernel packaging maintenance in some sort? Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: CFP : Have a Beagle or Beagle XM with a USB wifi?
On Wed, Aug 31, 2011 at 2:56 PM, Tom Gall tom.g...@linaro.org wrote: What we want to do for the next linaro release 11.09 is have working USB wifi support out of the box on beagle/beagle xm with the developer image. Tho you won't have to twist my arm hard at all to include BT in that goal as well Tony :-) We like to keep the developer image as small as possible so the fun part is keeping this to the minimal number of packages to make it work. For wifi I BELIEVE we just need to add wireless-tools. So here's what I'd like you to do. Grab the developer rootfs - http://snapshots.linaro.org/11.05-daily/linaro-developer/20110831/0/images/tar/ grab the omap3 hwpack - http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/omap3/20110831/0/images/hwpack/ Install to sd with linaro-media-create. If you can apt-get install wireless-tools and see if that's enough to get your wifi working. If not what else did you need? For bluetooth, same Q if you want to have that as a goal as well. It's optional. Either way I don't have a wifi USB device or BT so your help is essential! I have a 3COM (0ace:1215 ZyDAS ZD1211B 802.11g) around here, will also test with it. Guess the module for this adapter is zd1211rw, and is probably not enabled by default either, but need to check. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: CFP : Have a Beagle or Beagle XM with a USB wifi?
On Wed, Aug 31, 2011 at 6:08 PM, Robert Nelson robertcnel...@gmail.com wrote: On Wed, Aug 31, 2011 at 4:02 PM, John Rigby john.ri...@linaro.org wrote: On Wed, Aug 31, 2011 at 2:41 PM, Robert Nelson robertcnel...@gmail.com wrote: On Wed, Aug 31, 2011 at 12:56 PM, Tom Gall tom.g...@linaro.org wrote: What we want to do for the next linaro release 11.09 is have working USB wifi support out of the box on beagle/beagle xm with the developer image. Tho you won't have to twist my arm hard at all to include BT in that goal as well Tony :-) We like to keep the developer image as small as possible so the fun part is keeping this to the minimal number of packages to make it work. For wifi I BELIEVE we just need to add wireless-tools. So here's what I'd like you to do. Grab the developer rootfs - http://snapshots.linaro.org/11.05-daily/linaro-developer/20110831/0/images/tar/ grab the omap3 hwpack - http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/omap3/20110831/0/images/hwpack/ Install to sd with linaro-media-create. If you can apt-get install wireless-tools and see if that's enough to get your wifi working. If not what else did you need? Looks like we need to add the config's for a bunch of usb wifi drivers.. Robert, could you send me a list of CONFIGs we should have on for wireless? Will do, just be a sec.. BTW, panda also needs this patch, to enable wl12xx regulator (only for 3.0.x, for 3.1-rc's it's moved to twl-common, yet still needs a simlar tweak): 3.0 panda wl12xx regulator patch: (docs) http://elinux.org/Panda_How_to_kernel_3_0_rel (patch) http://elinux.org/images/8/87/0001-omap4-pandaboard-wlan-fix.patch Andy, don't know if this is at your radar already, but it seems we don't have a similar fix at the TILT tree, but I could be wrong. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: CFP : Have a Beagle or Beagle XM with a USB wifi?
On Wed, Aug 31, 2011 at 8:26 PM, Alexander Sack a...@linaro.org wrote: On Wed, Aug 31, 2011 at 7:56 PM, Tom Gall tom.g...@linaro.org wrote: What we want to do for the next linaro release 11.09 is have working USB wifi support out of the box on beagle/beagle xm with the developer image. Tho you won't have to twist my arm hard at all to include BT in that goal as well Tony :-) We like to keep the developer image as small as possible so the fun part is keeping this to the minimal number of packages to make it work. For wifi I BELIEVE we just need to add wireless-tools. WIFI without wpasupplicant is really incomplete in my terms. I don't think you get around including that if you want to claim wifi support. Yup, we should just include wireless-tools and wpasupplicant, otherwise depending on the network type it's quite a pain to configure. Just tested with my 3com wifi dongle after recompiling the kernel with CONFIG_ZD1211RW=m (also included at Robert Nelson's config file), and was able to easily configure my network with wpasupplicant. My config (WPA2): root@linaro-developer:~# cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo usb0 eth0 wlan0 iface lo inet loopback iface eth0 inet dhcp iface usb0 inet dhcp iface wlan0 inet dhcp wpa-driver wext wpa-ssid domonet # hexadecimal psk is encoded from a plaintext passphrase (generated with wpa_passphrase) wpa-psk 3eb95c07d2bcb79599318b239cbf5aefb741ecb66d46d31d95770d926f7e2ad6 Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Suggestion for ARM related summits at Linaro Connect Q4.11 (co-hosted with UDS-P)
Hey all, As we're having the Linaro Connect Q4.11 together with UDS-P, would like to know if there is any special topic it'd be useful to cover as a summit there. Any ARM related topics that might be related with cross-distro collaboration or just related with Ubuntu/Debian should fit. Some suggestions: - Arm Hard Float Port - Next steps for Multiarch at Ubuntu/Debian - Ubuntu ARM images discussion (Linaro hwpacks and Ubuntu spice seeds) - Minimal image support (Ubuntu core discussions) - 3D Support at ARM (GL ES x OpenGL) I know Steve McIntyre is trying to have an ARM summit at Plumbers, so we can also propose a similar summit to continue the discussions at Connect/UDS too, depending on the feedback from Plumbers. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What would you like to cross-compile?
Cross posting at ubuntu-devel. On Mon, Aug 29, 2011 at 11:22 AM, Riku Voipio riku.voi...@linaro.org wrote: Hi, We (Developer Platform) are looking into making Ubuntu/Debian more cross-compile friendly. In order to decide what to focus on on first, I'd like to ask from input from you - what would you like to be able to cross-compile for the Linaro Ubuntu evaluation builds? We know a lot of people (everyone?) cross-compiles kernels already, and don't need help from distribution. What else do people compile often enough that cross-compiling would help? From previous experience I remember there were a lot of people wanting to be able to cross build Qt, as it takes almost one day to build it at Launchpad's builders. Besides that being able to cross build the deliverables from other Linaro WGs would also be a good start, like: * glcompbench * glmark2 * powertop * powerdebug * libjpeg-turbo Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What would you like to cross-compile?
On Mon, Aug 29, 2011 at 3:54 PM, Jani Monoses j...@ubuntu.com wrote: On 08/29/2011 08:17 PM, Ricardo Salveti wrote: Cross posting at ubuntu-devel. On Mon, Aug 29, 2011 at 11:22 AM, Riku Voipioriku.voi...@linaro.org wrote: Hi, We (Developer Platform) are looking into making Ubuntu/Debian more cross-compile friendly. In order to decide what to focus on on first, I'd like to ask from input from you - what would you like to be able to cross-compile for the Linaro Ubuntu evaluation builds? We know a lot of people (everyone?) cross-compiles kernels already, and don't need help from distribution. What else do people compile often enough that cross-compiling would help? From previous experience I remember there were a lot of people wanting to be able to cross build Qt, as it takes almost one day to build it at Launchpad's builders. Any of the other packages that take long to build on ARM - LibO, chromium-browser, firefox, especially since they have their own de-facto maintainers who then would not need to ask for ARM hw just to debug failed builds - assuming the build issues are reproduced just as accurately as the build-results on a cross setup :) Yeah, those are all huge projects and probably also a good test case for the cross-toolchain in general :-) Out of curiosity does focusing on a set of packages mean making all their build-deps multiarch/cross build friendly? Yup, that's the idea. Riku helped porting a bunch of packages to multiarch, but we'd also like to use and test the common use cases so we can show that this actually work ;-) Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What would you like to cross-compile?
On Mon, Aug 29, 2011 at 5:45 PM, Dechesne, Nicolas n-deche...@ti.com wrote: On Mon, Aug 29, 2011 at 7:17 PM, Ricardo Salveti ricardo.salv...@linaro.org wrote: We (Developer Platform) are looking into making Ubuntu/Debian more cross-compile friendly. In order to decide what to focus on on first, I'd like to ask from input from you - what would you like to be able to cross-compile for the Linaro Ubuntu evaluation builds? We know a lot of people (everyone?) cross-compiles kernels already, and don't need help from distribution. What else do people compile often enough that cross-compiling would help? i would add GST as well as it's usually customized/patched. i would also like to be able to 1- use systemtap with a cross compiled .deb kernel 2- use dkms with a cross compiled .deb kernel (see https://bugs.launchpad.net/dkms/+bug/666267 which has been set as won't fix recently...) the point is that using a cross compile .deb kernel is nice since we very often rebuild kernel, but we have out-of-tree modules (like for graphics acceleration) that are using dkms... honestly i am not too sure about what the exact problem is, but since you are asking for intputs ;-) i think both 1 and 2 are related since using systemtap requires to build a kernel module on the target (like dkms). Yeah, we should work to get this bug fixed, it's been around for quite a while already =\ This month we'll spend time making Systemtap to work out-of-the-box with the Linaro images, so will also put this bug as a requirement, so we can try to get it fixed for the 11.09 release. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Graphics WG status report - wk33.2011 (20110815-20110819)
On Tue, Aug 23, 2011 at 7:23 PM, Christian Robottom Reis k...@linaro.org wrote: On Wed, Aug 24, 2011 at 01:07:07AM +0300, Ilias Biris wrote: How can we get consistent vendor support to get 3d acceleration working for the Linaro officially supported platforms? If we are targeting last version Ubuntu-based evaluation builds and some of the code we work on (and goes upstream) is going through a transition (like unity/nux have moved on to oneiric now) then we may be unable to provide meaningful releases for the components in question. The real issue we have in GWG is 3d acceleration driver support for the next version of ubuntu - we don't have any at the moment (AFAIK) for oneiric AIUI this is something which all vendors struggle with, but at least for the OMAP4 we should be in reasonably good shape as TI are committed to providing the necessary binaries for Oneiric. I raised this with Ricardo and he was confident it would be okay, so I'm surprised to still see this in the report. We already got SGX working with Oneiric at our Overlay PPA, and should also be able to make that available directly at Ubuntu in the next few days. So we can already start validating and using Oneiric based images right now, if you're fine with SGX and Pandaboard. I also don't quite understand why the updated Unity/Nux packages wouldn't Just Work if installed on Natty -- is the issue that they require updated X11 and Mesa? Nux is not API compatible, requiring Unity to be updated, which also requires a bunch newer libraries, making the backport not so trivial. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Graphics WG status report - wk33.2011 (20110815-20110819)
On Tue, Aug 23, 2011 at 7:57 PM, Jesse Barker jesse.bar...@linaro.org wrote: On Tue, Aug 23, 2011 at 3:23 PM, Christian Robottom Reis k...@linaro.org wrote: On Wed, Aug 24, 2011 at 01:07:07AM +0300, Ilias Biris wrote: How can we get consistent vendor support to get 3d acceleration working for the Linaro officially supported platforms? If we are targeting last version Ubuntu-based evaluation builds and some of the code we work on (and goes upstream) is going through a transition (like unity/nux have moved on to oneiric now) then we may be unable to provide meaningful releases for the components in question. The real issue we have in GWG is 3d acceleration driver support for the next version of ubuntu - we don't have any at the moment (AFAIK) for oneiric AIUI this is something which all vendors struggle with, but at least for the OMAP4 we should be in reasonably good shape as TI are committed to providing the necessary binaries for Oneiric. I raised this with Ricardo and he was confident it would be okay, so I'm surprised to still see this in the report. The point is that we _really_ need to have all of our member hardware fully enabled. For all of our evaluation builds. This is a huge pain point for the graphics working group. That's why it is in the report. I believe a lot of people are trying to make this happen, but most of the time they are blocked by the vendor's legal department, that's why Asac even suggested creating a Legal WG at Connect ;-) Not everyone involved with Unity/Nux/Compiz has a working pandaboard. Not everyone working on other projects has a working pandaboard. For some projects (e.g., cairo-gles), OMAP4 doesn't support all of the functionality involved, so even a working pandaboard is of limited use. For the first point I believe we should just make sure a Pandaboard is available for everyone, don't know why this is still not the case. For the second point I don't believe we'll have a common solution, even when we get more boards with 3D drivers available, as each vendor can support a specific range of extensions. I believe working with mesa is probably the way to go here. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android Tools
On Thu, Aug 25, 2011 at 4:04 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: One thing to keep in mind is that developers will get these tools from Google during their SDK install. Are we going to wrap that install? The idea was to make some of the tools available at Ubuntu directly, so that's why it'd be good to know which tools are the most important ones first. But sure, we need a way to make it work together with the SDK, but personally I don't know much about how they are shipping their own tools (if is deployed at the system path or just at the user's home and then setting PATH and so on with eclipse). Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [frederik.lot...@arm.com: [UBUNTU] linaro-media-create failing]
On Wed, Aug 17, 2011 at 8:07 PM, Christian Robottom Reis k...@linaro.org wrote: On Tue, Aug 16, 2011 at 03:20:17PM +0100, Frederik Lotter wrote: I am using 32-bit Ubuntu 11.04. Just here in my office everyone is running into the same issue. We are all Ubuntu users (11.04) and both 32-bit and 64-bit machines. Hey Frederik, Did you figure out what the issue was? I wonder if this could be something related with the way the host is configured. I was able to run l-m-c with the same images at both 32 and 64-bits machines. I know that if you have scratchbox installed, or any other software that changes the qemu-arm-static path at your binfmt config, l-m-c will fail, but I don't believe you'd end up with a segfault. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root filesystem to ext4
On Fri, Aug 12, 2011 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 12 August 2011 21:12:54 Fathi Boudra wrote: At the last release meeting, the switch to ext4 by default has been mentioned. My understanding is that we reach an agreement on the switch to ext4 [1] but it still not clear if it will happen this month. To make it happen, it will require several bug fixes: https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/817148 https://bugs.launchpad.net/linaro-image-tools/+bug/821479 https://bugs.launchpad.net/linaro-ubuntu/+bug/822593 https://bugs.launchpad.net/linux-linaro/+bug/824545 Also, it's worth mentioning that changing the default will break previous releases if they don't have ext4 support. The workaround is linaro-media-create --rootfs option to specify the filesystem. I think it's also worthwhile to look at the results of Tixy's file system simulation before we switch. If there are significant performance regressions over ext3 or if btrfs turns out to be much better than ext4, we should probably not move to ext4 at this point but rather try to get btrfs fully supported. My understanding is that there are other bugs that would need to be fixed to make that happen. Yeah, if we're doing this change it seems it would make more sense to jump directly to the btrfs, unless we can demonstrate that the performance is not that superior and have any kind of blocker issues. Do we have any kind of benchmark results comparing each filesystem when using them with SD cards around? Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[Pull Request][tilt-master] Adding support for SGX platform device, to work properly with the external module
Hy Andy, These are the required changes to make SGX to work with the external module, as we had for 2.6.38. These patches are just a forward port of the same patches from 2.6.38, will try to ping the original authors to see why this is still not upstream. Cheers! The following changes since commit 5b14e370cca884fa86471e909512f65b06dcaec2: config non drm sgx (2011-07-18 11:52:26 +0100) are available in the git repository at: git://git.linaro.org/people/rsalveti/linux-linaro-3.0.git rsalveti-tilt-for-andy Hemant Hariyani (1): Kernel changes for hwmod and omap_device initialization for GPU. Vikram Pandita (1): OMAP4: SGX-KM: Enable SGX initialisation arch/arm/mach-omap2/devices.c | 59 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 84 arch/arm/plat-omap/include/plat/gpu.h | 33 +++ 3 files changed, 176 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/gpu.h -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Please tag commits referred to by pinned and release manifests in Android builds
On Mon, Jul 11, 2011 at 6:18 PM, Alexander Sack a...@linaro.org wrote: On Mon, Jul 11, 2011 at 4:11 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: In-order to make reproducible builds we create pinned manifests with each commit explicitly listed. We also use this method to create a release. We depend on these pinned commits - if they don't exist the released builds can no longer be reproduced. One amend: the commits need to exist AND need to be reachable through a head. In other words: due to how the repo tool work, tagging and then rebasing will not be good enough. For me this seems to be quite fragile, as you're expecting the upstream tree for a component to not rebase the tree. At least when looking at what happened with u-boot-linaro, where a rebase is expected by the way John is maintaining his tree, this method will fail unless you're building against a tag (as I believe git will respect the tag even if the tree was rebased in some way). Is there other way to fix this at the tool instead of forcing the component tree owner to not rebase the tree? Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Switch to ubuntu-build.linaro.org
On Fri, Jun 24, 2011 at 11:19 AM, James Westby james.wes...@linaro.org wrote: On Thu, 23 Jun 2011 12:06:46 +0200, Alexander Sack a...@linaro.org wrote: can we somehow smoke test the infrastructure continuously till tomorrow and then reassess tomorrow afternoon? We didn't add any extra stress, but all everything has been built twice now with no builder issues. Do we have the confidence to switch now? I've being following the builds and even requesting some more extra ones, and all seems to be working fine at the moment. Guess it'll be OK for the switch and release, unless something else breaks and burn :-) Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Switch to ubuntu-build.linaro.org
On Tue, Jun 21, 2011 at 6:04 AM, Fathi Boudra fathi.bou...@linaro.org wrote: Hi, On 20 June 2011 16:10, James Westby james.wes...@linaro.org wrote: Hi Fathi, Given the results of last week's weekly testing, do you think we should now flip the switch to move to using the images built by ubuntu-build.linaro.org (offspring.linaro.org as was)? I tend to say -1. If not, what are the blockers to doing so? Today, the builders are unstable. It requires: 1. check the build status everyday as the notifications are broken. 2. manual intervention to reboot the builders when they're stuck (only IS can do it). 3. trigger manually a rebuild. I can live with this manual steps in the short term but it should be fixed ASAP. It isn't a hard blocker as we have a (manual) workaround. Any other opinion? Are we expecting to use our Offspring instance to make the 11.06 release? If so, I believe this will end up as a blocker, as the builders are not reliable at all atm. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Switch to ubuntu-build.linaro.org
On Tue, Jun 21, 2011 at 10:56 PM, James Westby james.wes...@linaro.org wrote: On Tue, 21 Jun 2011 09:04:41 +, Fathi Boudra fathi.bou...@linaro.org wrote: If not, what are the blockers to doing so? Today, the builders are unstable. It requires: 1. check the build status everyday as the notifications are broken. Notifications are now working. I can live with this manual steps in the short term but it should be fixed ASAP. It isn't a hard blocker as we have a (manual) workaround. Any other opinion? IS are looking in to this problem. It is not confined to our slaves (at least they have found plenty of problems with unstable ARM boards.) The only info I have currently on it is the following kern.log snippet: Jun 13 23:10:01 miraclefruit kernel: [67719.667022] Unhandled fault: external abort on non-linefetch (0x1018) at 0x4000 Jun 14 23:10:01 miraclefruit kernel: [23044.748687] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40313000 Jun 15 10:39:07 miraclefruit kernel: [64388.888458] usb 1-2.3: reset high speed USB device using ehci-omap and address 4 The unhandled fault shouldn't be related with the usb errors. From my experience with Beagle xM the USB port will trigger the reset once the disk is consuming more power than beagle can provide. As I know this is probably a powered USB disk, it'd be good to check the same hardware on another beagle to see if we're able to reproduce the problem, as in the end it could be just a normal hardware failure. I've heard a rumour that the problems are related to the USB subsytem and the USB hard disks, but nothing more concrete than that. They are running beagleXMs for what it is worth. Do you know why we're using beagle xM and not panda for the builders? It'd also be good to have the correct board revision ID to know if the xM is a prototype or a final release (A, A2, B or even C now). Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
New Time for Linaro Developer Platform Weekly IRC Meeting
During our last IRC meeting we decided to change the usual time and date for our weekly IRC meetings, to avoid conflict with the ARM porting jam. The meeting will now happen on every Thursday at 14UTC, and it should take 1 hour. The calendar for this week is already pointing the new date at https://wiki.linaro.org/Platform/DevPlatform Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
