Re: OLPC build creation failed
Thanks Martin, I could build bios-crypto from git. It signs and it looks like everything works :) Thanks everybody for the help. On Tue, Oct 2, 2012 at 12:57 PM, Jerry Vonau jvo...@shaw.ca wrote: On Thu, 2012-09-13 at 17:51 -0700, John Gilmore wrote: On Thu, Sep 13, 2012 at 3:57 PM, Jose Prous josepr...@gmail.com wrote: Yes it's a x86 machine, I guess that is the problem. Thanks. Glad that we found the reason. We should add an explicit check in OOB that gives you a more useful error msg. Instead, you should fix OOB so it works to cross-compile. Sorry John, I don't think OOB is fixable without first fixing yum as imgcreater uses yum to resolve dependencies and install the rpms. The problem is that yum deduces what arch yum is running on by calling uname and offers no way to override that variable[1]. The PTB didn't view this behaviour as a bug, which later cropped up in other places in Fedora like anaconda[2]. Even Martin felt the effects of this decision[3]. Jerry 1.https://bugzilla.redhat.com/show_bug.cgi?id=172080 2.https://bugzilla.redhat.com/show_bug.cgi?id=367731 3. http://www.redhat.com/archives/fedora-buildsys-list/2009-February/msg00028.html We at Cygnus spent years making the GNU tools able to cross-compile, and it all works. We built a big test infrastructure and made sure that the resulting executables were bit-for-bit identical no matter what the build host was. It's just your builder script that's unable to do it -- and that is under your control. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Fri, Jul 27, 2012 at 2:51 AM, Jerry Vonau jvo...@shaw.ca wrote: Hi All: I would like to propose a feature for discussion and inclusion in the 0.98 cycle is packaging all control-panel applets as rpms. As this discussion does not impact the UI and more of a packaging issue I'm an not creating a Features page. The discussion can take place here on the mailing-list. The reasoning is that it should make it easier for downstream users of sugar to exclude applets that don't apply to their use case without having to patch them out. For example OLPC removes via their .spec file, the keyboard and updater applets from their builds and uses their own version of an updater supplied as an rpm. Dextrose is using this idea to now to partly split up the what is available to install at rpm generation time[1]. I have found this useful from a deployment perspective by being able to exclude applets that are unwanted or need further development from the final image. The current code base and workflow would not be changed, except a revised sugar.spec file would generate more that just the sugar rpm when run, like how it is done now for sugar-emulator. Deployment level users of sugar would then need to state which applets to include in their image at image creation time. This will allow development of applets to evolve without having to reinstall all of sugar in the field for a change to an applet. Any XO specific user tool like About my Computer and Power should not really be part of sugar but should be available to install on demand like OLPC's sugar-update-control and olpc-switch-desktop that are added to OLPC's sugar installation. SoaS might benefit from not shipping all the applets, omitting the ones that apply to XO hardware. This change might help development of new features in the control-panel area that later be incorporated into sugar once proven to work. Feedback and comments welcome, I've pushed this and it will appear in the next build, feedback welcome. I've left the AboutComputer and AboutMe built in and all the rest are sub packages. There's a meta-package called sugar-cp-all which pulls all the Control Panels packages in as well. Sorry about the delay. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Thu, 2012-10-04 at 21:29 +0100, Peter Robinson wrote: On Fri, Jul 27, 2012 at 2:51 AM, Jerry Vonau jvo...@shaw.ca wrote: Hi All: I would like to propose a feature for discussion and inclusion in the 0.98 cycle is packaging all control-panel applets as rpms. As this discussion does not impact the UI and more of a packaging issue I'm an not creating a Features page. The discussion can take place here on the mailing-list. snip Feedback and comments welcome, I've pushed this and it will appear in the next build, feedback welcome. I've left the AboutComputer and AboutMe built in and all the rest are sub packages. There's a meta-package called sugar-cp-all which pulls all the Control Panels packages in as well. Sorry about the delay. Thank you very much, reviewing now. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Linux 3.7 Kernel To Support Multiple ARM Platforms - Slashdot
Up until now there has been a separate Linux kernel build for each of the ARM platforms or SoCs, which is one of the several problems when it comes to ARM based Linux. The merging of ARM multi-platform support into Linux 3.7 will put an end to this problem, enabling the new kernel to not only target multiple platforms but also be more in line with its x86 counterpart. http://linux.slashdot.org/story/12/10/04/1942201/linux-37-kernel-to-support-multiple-arm-platforms ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
qemu wine experiments on ARM
Just a quick outline of one experiment to see if simple Win32 content-ware apps can be run. Commands may be missing switches, options and steps. Caveat reader. BYO smarts. On x87 host F17 - install livecd-tools spin-kickstarts - copy fedora-live-mini.ks, add wine -- remove some stuff - sudo setarch i686 livecd-creator fedora-live-mini.ks - wait - copy resulting iso to ext disk - yumdownloader sgabios-bin-0-0.20110622SVN.fc17.noarch seabios-bin-1.7.0-1.fc17.noarch -- they are noarch but missing from arm repos. copy to ext disk On ARM XO F17 - install seabios-bin sgabios-bin rpms - yum -ty install qemu-system-x86 qemu-user - qemu-386 -m 512 -cdrom /some/media/fedora-mini.iso inside of the qemu window, in the live cd boot text menu press tab to remove rhbg and quiet. boot slowly. Probably. Eventually. Clearly, qemu can emulate x86 on ARM. Slowly. This is of course impractical, mainly because you need to get through a bootprocess before you can run an app and the app is not in a transparently shared environment (it's in qemu's odd fb window). Qemu's user-mode is a lot more practical. We would need a minimal fedora x86 chroot that has wine, and use qemu over that. After a bit of googling, I found PRoot, which seems to provide the right glue to make qemu's user mode actually usable. http://cedric-vincent.github.com/PRoot/ http://adt.cs.upb.de/quf/quf11/quf2011_13.pdf For a truly minimal rootfs, mock is likely to be more useful than livecd-tools. m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: qemu wine experiments on ARM
On Fri, Oct 5, 2012 at 12:22 AM, Martin Langhoff mar...@laptop.org wrote: Qemu's user-mode is a lot more practical. We would need a minimal fedora x86 chroot that has wine, and use qemu over that. After a bit of googling, I found PRoot, which seems to provide the right glue to make qemu's user mode actually usable. http://cedric-vincent.github.com/PRoot/ http://adt.cs.upb.de/quf/quf11/quf2011_13.pdf proot only offers x86 rpms, so a rebuild for armv7hl/f17 at http://dev.laptop.org/~martin/proot/ - untested For a truly minimal rootfs, mock is likely to be more useful than livecd-tools. On x86 fedora... mock -r fedora-17-i386 --init mock -r fedora-17-i386 --install wine then tar up /var/lib/mock/fedora-17-i386/root, untar on your XO. m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Linux 3.7 Kernel To Support Multiple ARM Platforms - Slashdot
On Fri, Oct 5, 2012 at 1:17 AM, Sameer Verma sve...@sfsu.edu wrote: Up until now there has been a separate Linux kernel build for each of the ARM platforms or SoCs, which is one of the several problems when it comes to ARM based Linux. The merging of ARM multi-platform support into Linux 3.7 will put an end to this problem, enabling the new kernel to not only target multiple platforms but also be more in line with its x86 counterpart. http://linux.slashdot.org/story/12/10/04/1942201/linux-37-kernel-to-support-multiple-arm-platforms It supports basically 3 usable platforms at the moment, and likely not all components of them. It's a marker point in what began just prior to 3.0 with the ARM rant from Linus. There's still along way to go. You should see the first Fedora kernel supporting this in the coming weeks on 3 server platforms. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
