openSUSE ARM December 2011

arm@lists.opensuse.org

10 participants
13 discussions

[opensuse-arm] OBS ARM build discussion I would like to start

by Joop Boonen

Hi all, Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu. Because qemu is much slower them native ARM builds the external build is way behind. So for people outside of suse.com it's not really possible to fix packages as you don't know if the current status is still valid. I would like to know how the people in charge of OBS think about this? Can the current situation be changed or is this due to a security policy? Can we help to solve this issue? If so what are the problems we are facing and which security should be met? Did I leave something out or is something now correct? Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

10 years

[opensuse-arm] "dead lock" between autoyast2 and yast2-schema

by Joop Boonen

All, Currently there is a "dead lock" between package autoyast2 and yast2-schema (for the openSUSE:Factory:ARM build). The thing is that autoyast2 Requires yast2-schema. Because of this yast2-schema is blocked. I got around this by removing the autoyast2 requirement. Until yast2-schema has been build. When this package was build I added the Requirement again. I wonder if there is a better "mechanism" in OBS that solves such "lock issue" automatically? Otherwise someone has to handle this by hand. Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

10 years, 1 month

[opensuse-arm] yast2-all-packages patch

by Joop Boonen

Hello YaST development, I understood that all YaST changers aren't handled via the build server? Can the attached patch please be applied to yast2-all-packages. It now has the line: %ifnarch ia64 ppc ppc64 s390 s390x %arm Wouldn't it be better to replace it by: %ifarch %ix86 x86_64 In the patch it's in the syntax as currently is in the spec file. Regards, Joop.

10 years, 1 month

[opensuse-arm] yast2-country patch in openSUSE:Factory:ARM needed

by Joop Boonen

Dear all, Can someone please apply the attached patch to: openSUSE:Factory:ARM yast2-country It's quite urgent as this one should build yast2 . The problem is that I cant create a submit request against openSUSE:Factory:ARM, this package is a unique openSUSE:Factory:ARM version. Regards, Joop.

10 years, 1 month

[opensuse-arm] yast2-country patch in openSUSE:Factory:ARM urgently needed

by Joop Boonen

Dear all, Can someone please apply the attached patch to: openSUSE:Factory:ARM yast2-country It's quite urgent as this one should build yast2 . Regards, Joop.

10 years, 1 month

[opensuse-arm] Factory:ARM Status

by Dirk Müller

Hi, I worked this afternoon a bit more on build failures and various other package build issues. Meanwhile we have over 4200 packages that have succeeded building, which is almost the complete distribution. We're so far missing all dependencies behind libwebkit* as it fails to build for both a compiler bug and then running out of memory during linking later. We have worked around both issues in libQtWebKit, which succeeds to build, and the same fixes could be applied to libwebkit. Volunteers are welcome :-) Some other packages are failing due to general Factory brokenness, like yast2 and its dependencies. Hopefully this will cleanup automatically, but to avoid running into non-arm-specific issues, I've written a script to ignore build errors that also happen on openSUSE:Factory. I guess I need to polish that a bit more and make it pretty print a webpage that people can refer to (not yet done). Third, I merged the bits we still need into gcc46 and submitted this to the devel project. Luckly it got accepted today, so while the overlay is still there, it hopefully can be removed completely as soon as that version hits Factory. Looking forward to that! Also, I noticed that some of the packages were branched for reasons that are no longer current, so I deleted them. Most prominent example is glibc. Note this triggers some rebuilds. to have a clean native build, I've triggered a complete rebuild in the internal copy of openSUSE:Factory:ARM that builds on native hardware (not on OBS). Hopefully we then find issues that we would otherwise also run into at some point in the future in OBS. OBS is currently far too slow to handle a complete rebuild, so I try to let it minimally rebuild only. I've also updated hwinfo(1) to work better with native and with qemu, and it is now good enough to pass yast2-hardware-detection testsuite, which means that we're one step closer to having yast2 building. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

10 years, 1 month

[opensuse-arm] kiwi arm build

by Joop Boonen

Hi, I have been checking out the kiwi build (kiwi --debug --build suse-SLE12-JeOS --destdir /var/tmp/arm_JeoS.raw) on openSUSE. Most of it is OK. I've added a patch. It's also build in home:worldcitizen:armv7l kiwi . There are still a few issues in some packages (u-boot). I'm sending in a submit request for this. The kernel-omap2plus doesn't seem to support omapfb yet. I've also tested with the linaro Android 4.0 kernel. This one is OK it also has the omapfb and can be used with The kiwi patch is attached, it are basically configuration and spec file changes. Marcus can you please apply this one if you agree with it? Regards, Joop.

10 years, 1 month

[opensuse-arm] New repos pushed out, debug packages seperated

by Adrian Schröter

JFYI, the new armv5 and v7 repos the OBS pushed out yesterday are using a new OBS feature. All the *-debug* packages are in their own repo beside the "standard" one. This is to reduce the meta data a lot in the standard repo, so not everybody has to download the large meta data amount. On the other hand, you have to add another repo now if you need -debug packages. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

10 years, 1 month

[opensuse-arm] Java related package build on ARM

by Dirk Müller

Hi, after we have bootstrapped java-1_6_0-openjdk, now most of the stuff is blocked by "ant-junit" (subpackage of ant-antlr). That one fails to build due to running OOM during building javadocs. I've quickly checked, and it seems building javadocs is not really necessary, as the tarball has already javadocs included. So we could skip that step, which already helps. It seems the spec file had a %build_javadocs define that is not really functional anymore (ant distribution includes ant javadocs, which is run unconditional, so the spec file actually builds javadocs twice I think). The alternative solution, which seems to work as well and reduces build differences is this small patch: --- build.xml +++ build.xml @@ -1358,7 +1358,7 @@ <target name="-javadocs.do" if="jdk1.5+" unless="javadoc.notrequired"> <mkdir dir="${build.javadocs}"/> <javadoc useexternalfile="yes" - maxmemory="1000M" + maxmemory="512M" destdir="${build.javadocs}" author="true" version="true" which finishes building javadocs target successfully after a chewing for 160 minutes under qemu (53 minutes on native hardware). Currently I went for this solution (patch is only applied on %arm), any comments, ideas appreciated. I guess it would help overall build speed by only building "ant jars " and maybe "ant test-jars" and not also javadocs? Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

10 years, 1 month

[opensuse-arm] low-cost EOMA-PCMCIA CPU Card initiative (allwinner cortex a8)

by Luke Kenneth Casson Leighton

folks, hi, apologies for the wide distribution of this message, reasons will become clear: please do subscribe to arm-netbooks(a)lists.phcomp.co.uk and respond there (subscription required) rather than to all these lists. the short version of the story is that Rhombus Tech (a CIC company - not a not-for-profit or a Ltd Company) is now taking preorder committments - pledges - to buy EOMA-PCMCIA-compliant CPU cards using a low-cost but feature-rich ARM Cortex A8 CPU called the Allwinner A10. http://http://rhombus-tech.net//allwinner_a10/orders/ some bullet-points: * this initiative is similar to the openpandora, the openmoko, ben nanonote etc. except that the lessons have been learned from these projects, to keep it very very simple, low-risk and modular, but still functional and useful (to Software Libre Developers) as a module. the goal is also different in that the plan is to leverage mass-volume pricing and opportunities, to the direct benefit of the Software (Libre) Community. more info on http://rhombus-tech.net main page. * the A10 has (at least) HDMI, SATA-II, 10/100 Ethernet, takes up to 1gb of 800mhz DDR3 RAM, has a superb 32-bit-wide 8-way concurrent DMA-driven NAND Flash interface, MALI 400MP 3D Graphics, does 2160p (2x 1080p) Video, has 4 SD 3.0 Ultra-High-Speed interfaces, 2x 24-pin RGB/TTL LCD interfaces, IDE (PATA)... i'm repeating what's on the rhombus tech web site so will stop here (link below) * the price of the allwinner CPU is so low in mass-volume ($USD 7) that in mass-volume (100k pricing) a PCB that is comparable to the raspberrypi would only be $USD 15 instead of $25, yet the A10 would be 3x faster processing speed (the rbpi's CPU is only a 700mhz ARM11 yet is more expensive). * the CPU card will be able to operate as a stand-alone (USB-OTG powered) computer, with HDMI output, boot from Micro-SD, and stereo headphones/mic, yet due to EOMA-PCMCIA compliance it will plug into a wide range of future devices. * unlike the beagleboard, origen, IMX53QSB etc. this is not a SoC-fabless-semiconductor-company-driven or a Linaro-driven initiative, it is a commercial initiative with an absolute top priority focus on GPL compliance and involving Software (Libre) Developers every step of the way, hence the reason for using a CIC not a Ltd Company. * GPL Kernel Source code has been obtained from allwinner: RHT has the full support of allwinner's Board of Directors, and the Reference Platform source code is available on alioth.debian.org. * as the primary focus of this initiative is, at this stage, to invite Software (Libre) Developers to be involved, it has not been widely announced. this is therefore the 1st reason why these lists are specifically being contacted. * as the CPU cards are designed to be in legacy PCMCIA form-factor, motherboards and devices such as tablets, laptops, plug computers, NAS boxes, IPTVs, are all possible, including embedded and other industrial purposes. the only other thing is that we are actively seeking "Admins" for the Rhombus Tech web site, from a wide range of different communities. the responsibilities are very small - they're a bit like those of slashdot meta-moderation. primarily we need people to be able to vet sponsorship for receipt of developer boards, using the profits raised by the CIC, for the direct strategic benefit of the Software (Libre) Community. this is similar in effect to the beagleboard sponsorship programme, but unlike the beagleboard sponsorship programme, if sufficient profits are raised by the CIC it will be possible for Admins to decide to donate boards taking up the entire years' remaining profits in one go, to worthwhile causes. clearly, to find such people it is necessary to reach an appropriate audience, hence the 2nd reason why this message is going specifically to ARM lists in each of the major gnu/linux distros. there are at present 4 people who have agreed to be Admins, including phil hands, alain williams, wookey and james vasile, each in "unofficial" capacities with no relation to any other duties or roles that they fulfil. ideally we could do with one or two more from each of the other gnu/linux distros. lastly: there *is* the possibility of adapting something like the beaglebone, which would, if the AM3357 was used, mean that the resultant hardware could potentially be FSF-Hardware-Endorsed: if this is something of interest to you please do speak up (on the arm-netbook(a)lists.phcomp.co.uk list) or likewise if you would prefer any other "Open Schematics" board such as IMX53QSB, pandaboard etc. to be adapted please do say so. ok i'll leave it at that. it's worth repeating - discussion please contact me either privately, directly, or subscribe to arm-netbook(a)lists.phcomp.co.uk, list instructions below. many thanks. links here: EOMA-PCMCIA spec: http://www.elinux.org/Embedded_Open_Modular_Architecture/PCMCIA allwinner page: http://http://rhombus-tech.net//allwinner_a10/ preorders page: http://http://rhombus-tech.net//allwinner_a10/orders/ accidental slashdot article: http://goo.gl/M7YQH rhombus-tech web site: http://rhombus-tech.net arm-netbooks: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook beaglebone idea: http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-December/001155.html am335x page: http://rhombus-tech.net/am335x -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

10 years, 1 month

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM December 2011