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