Re: [fedora-arm] arm@lists.fedoraproject.org
On 03/02/2011 07:31 AM, omall...@msu.edu wrote: I will give you my concerns :) Is there a way to strip out What one you aren't using? IE i don't have an fpu, therefore I want to strip out the hardfpu code for a smaller binary. Just to clarify, this script and its resulting binaries are to assist bootstrapping armv7l. I don't think anybody is considering it for anything beyond a one time rebuild of all the packages. What vfpu are the target? I thought the main reason why we didn't want hard fpu's was because of the differences, between them. Number of registers varied, etc. You can't really optimize for each of them and have any sanity. This does bring up an interesting point- right now the flag difference is simply '-mfloat-abi=hard'. Is this the right flag for all armv7 concerns? Is this going into the compiler? ie you compile for arm and you get the resulting fat binaries? That's pretty much the idea. It's just to get armv7 built without having to tackle circulator dependency chains during bootstrap. If I have to run a script that changes the objects in the binaries, it screws up checksums and can cause all sorts of issues. It would definitely alter checksums. What other issues do you foresee? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 15 - ARM v5 and v7 plan of attack
On 09/21/2011 01:59 PM, Henrik Nordström wrote: We will hold a review session tomorrow (Thursday September 22) on IRC that will be announced as a VFAD.[snip] At what time? Per Chris Tyler's recent email ([fedora-arm] Triage for Remaining armv7hl Packages): When: Sep 22 2011, 1600 UTC (1200 EDT) Where: irc.freenode.net:#fedora-arm Would really be nice if these things gets planned a couple of days ahead. Agree... As you and others have pointed out, many of the build failures are now in need of manual intervention. That makes this subject a good recurring VFAD topic so lets discuss making this a regular event if the time generally works for those who want to participate. TARGET: October 14th or sooner for remaining packages/ready for Koji. That's 3 weeks away. At current investment level in solving build issues that's a way optimistic date imho. But obviously depends on what the target functionality level is. The goal would be to get it up to par with the ARMv7 rather than be complete finished. Given sufficient builders this should be achievable as the path has been paved with the work done for ARMv7. The simple brute-force model is not really suitable for this as-is. If you use this then two full rounds will be needed (f14-stage4, stage4-stage4.1), and a fair bit of manual actions inbetween to solve package mismatches. At least if you want a reasonably smooth koji run or any form of reproducible quality level on the packages that comes out of koji. Yes, hopefully there will be ordered builds... phone is not really an option for me, and also very poor medium for making any form of decisions or working over any forms or task lists or even keeping correct notes of what was said. normal Fedora meetings is #fedora-meeting. It looks like Chris suggested using #fedora-arm rather than a phone, If some people prefer to use the phone we can provide a bridge. I am currently rsyncing the F15 updates SRPM repository to arm-temp.ausil.us. Once it's done we can copy select packages from this directory into the build queue to give the ARMv7 builders something to work on. Lets start with FTBFS (excluding dependency failures) and see how far we can get that way. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F15-arm7hl bootstrap with gcc / make?
On 10/03/2011 03:02 PM, Martin Langhoff wrote: DJ pointed me recently to the bootstrap environment at http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ whoever, it doesn't have gcc / make. there is a newer one at http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110918/ -- is it expected to work? and does it have make gcc? Not sure if it has make gcc. The idea behind these rootfs images is to provide what is needed to run mock- which will itself install gcc and make when used. If that doesn't work for you, you can always install one image or the other, then install gcc, etc with yum. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On 10/13/2011 12:22 PM, Henrik Nordström wrote: Should Fedora for ARM officially support for some well known boards? I would like to see Fedora ARM installable on popular ARM boards by conventional installation mechanisms (IE, anaconda) without any additional steps necessary. Do you think Fedora should provide the bootloader for well known boards where the required board support is merged mainline? If the bootloader is in flash, lets use the bootloader that is provided. If the bootloader needs to come from the OS install, the OS install should provide it. As an example using today's hardware that would mean using the Trimslice's built-in uboot, but providing a uboot for the Pandaboard during install-time. This will hopefully increase Fedora ARM adoption. Assuming somebody is willing to take this maintainership role, is there any objection to the above? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On 10/13/2011 02:32 PM, Jon Masters wrote: Thanks for asking it. I thought we'd already pretty much decided to support TrimSlice and PandaBoard/BeagleBoard for example. That's certainly what we've done with the kernel so far. Let me precede the following by saying I don't think anybody is advocating updating the uboot in flash, so the following is exclusively with regard to systems which store their uboot where Anaconda will want to overwrite. Let's break down the possibilities for how to handle that: 1. Provide no uboot under any circumstances as part of the install. 2. Provide a mechanism that pulls uboot images from a non-Fedora location during install-time if needed for the intended installation target. 3. Provide a mechanism that pulls uboot images from a non-Fedora location during installer image composition, if needed for the intended installation target. 4. Provide certain u-boots as a piece of some firmware package that get put in place at install time, if needed. 5. Provide uboot-panda (etc) rpms that get put in place at install time, if needed. Any of 2-5 are an improvement. What do people favor? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On 10/14/2011 07:20 AM, Derek Atkins wrote: Do we have a list of popular (and easy to support) ARM platform? Would this include e.g. the SheevaPlug, GuruPlug, and/or DreamPlug kirkwood-based devices? In the context of the discussion, it appears the Dreamplug (And presumably earlier plugs) keep their uboot in flash, so they are a non-issue for uboot inclusion. They're certainly popular devices and if somebody wants to add kirkwood support to the kernel we're working with that would be a wonderful addition. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On 10/14/2011 10:54 AM, Chris Tyler wrote: Note that the GuruPlug ships with a broken uboot, which uses the wrong machine identifier. To use a mainline kernel, you must munge the kernel machine ID or update the GuruPlug's uboot. Ooh, good to know. The phrase the kernel we're working with caught my eye. Which kernel are we talking about? I'm specifically thinking of David Marlin's kernel as referenced here: http://fedoraproject.org/wiki/Architectures/Fedora_ARM_Kernels (I've heard but have not verified that the Kirkwood and OMAP patch sets used to be pretty much mutually-exclusive; I haven't tried to build a unified kernel and hope this has been fixed). Yuck. I know David has been endeavoring to make his changes mesh easily with additional parties adding their own pet board to the SRPM. Most of our systems are omap and tegra based so we haven't seriously looked into kirkwood support. If somebody wants to add kirkwood support they should bear in mind your warning about the broken uboot. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F15 armv5tel update
On 10/25/2011 11:52 AM, DJ Delorie wrote: We can host on Australia -- send me an ssh public key for access. Will do. What sort of information do we want this new chart to convey? Packages only in armv7hl build (latest version) Packages only in armv5tel build (latest version) Changes only in armv7hl build Changes only in armv5tel build -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F15 armv5tel update
On 10/25/2011 04:06 PM, DJ Delorie wrote: http://djdelorie.fedorapeople.org/armv5tel-vs-armv7hl.html Cool! What is the plan for reconciling the differences? A few packages stand out as being particularly concerning: gcc: There are patches in the armv7hl build that affect volatile bitfields and memory consumption. The lack of the volatile bitfield patch may result in a few broken packages on armv5tel while the absence of the memory consumption patch may result in some packages failing to build. glibc: Both have arm patches, but are they the same patches? rpm: Special armv7hl handling was required. Is this as upstream acceptable as it's going to be for the foreseeable future? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 16
On 10/26/2011 10:34 AM, omall...@msu.edu wrote: Can we get away with taking a snapshot of the F15 base and F15 Updates trees, and merge them and call that F15 base? Keeping F15 updates spinning during the F17 work is a sensible thing to do as we could really use a stable ARM Fedora release to work from. This would hopefully look like F15 plus some updates (i.e., what koji produces from an F15 mass rebuild) as GA, then a seperate updates repository. Hopefully any changes that go into F17 during development will end up as updates in F15 since F15 will still be supported until F17 is released. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] VFAD Monday for armv5tel/armv7hl reconcilliation and prep for koji startup
On 11/08/2011 02:44 PM, Henrik Nordström wrote: There is about 20 or so packages which need to get merged mainline somehow, with some notably core ones such as gcc, glibc java. Are we comfortable with not having these merged mainline before doing the koji build? It could be weeks before the last gcc patches filter down to F15, if ever. I suggest we start koji with a custom srpm and move on to an update once it becomes available. In addition to this there is one more gcc patch that should be evaluated, relating to incorrect code generation in volatile bitfields resulting in various subtle runtime errors (bad builds). Not yet included in the gcc in our repositories but test results so far looks very promising. Not entirely comfortable with doing the official mass rebuild without having this fixed first. Unfortunately it is unknown which packages this issue hits. See GCC PR #50521 gcc.gnu.org/bugzilla/show_bug.cgi?id=50521. This issue need some help pulling the right GCC people to evaluate the proposed patch. This issue hits mainly arm architecture due to ABI differences to x86 and presumably the other secondary arches as well. Per our IRC conversation, the second patch in 50521, patch to honour STRICT_ALIGNMENT, breaks the gcc build. Midway through, xgcc is used to generate an executable which segfaults. The build works with 50521's proposal patch however. I have not tested the result. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Koji status update
On 11/17/2011 11:04 AM, Chris Tyler wrote: I agree with going with what we've currently got package-wise. But saying we should start building today or get Koji running...tomorrow is missing the point. We're ready to go the moment we have finished these tasks: - the gcc/glibc issues are resolved - we've pruned the package sets back to the same core - every change/patch in those package sets has been upstreamed - the hub and builders have been successfully set up and tested with patched koji/rpm/yum etc. Work on all these pieces is proceeding in parallel (assuming that someone's on the gcc/glibc piece (who?)). We're not blocking on any one piece, but we have to finish these four before hitting 'Go'. The final patch for gcc, for instance, may never make it into F15. Even the armv7hl spec file changes we pushed upstream are only in .fc16 koji builds at this point. If these changes are in FC16 or rawhide but not F15, isn't that good enough? Why not build packages in parallel too? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Linaro toolchains and Fedora
On 11/23/2011 06:59 PM, Michael Hope wrote: Hi Jon. I've cc'ed Marcin and Ricardo who are working on the Linaro platform side. Hi Michael, Marcin and Ricardo. I'm working with Jon on or ARM endeavors and thought I'd follow-up since compilers are one of the few areas where I have more expertise than he. Comments inline below. We have a mix of pre-built cross and native compilers that ship with Ubuntu or come in a PPA and it would be great to have something similar for Fedora. Indeed, we'd love to see the Linaro package set become available to Fedora as well. Currently we have a Linaro + Ubuntu sauce cross compiler, plain Linaro cross compiler, and plain Linaro native compiler. We're working on a plain tarball cross compiler that runs on generic Linux or Windows as well. Fedora sauce is essentially the rpm packaging. It's actually quite straight-forward to turn a basic build script (configure; make all install) into an rpm, so the technical effort needed in this endeavor may be minor. The Linaro + Ubuntu sauce cross compiler is in the Ubuntu archive from at least Natty onwards and Marcin is working on making these available in Debian. The plain Linaro compilers are in a PPA, don't include the Ubuntu specific patches, and are more up to date. You probably want your default cross compiler to be the same as the native compiler to reduce surprises so you'll probably want both a FSF and Linaro cross compiler. One of the more complicated elements of Fedora Linaro integration that Fedora maintains its own gcc. This is essentially FSF stable plus rpm sauce. There is definitely room for a Linaro cross compiler. There might be room for a Linaro native compiler. There are a few avenues we would like to explore: 1. Making the Linaro cross package set available for i686, x86_64, armv7hl and possibly armv5tel rpm-based distributions such as Fedora and RHEL. These same packages would likely work on SuSE, Mandriva, etc. The end goal is to get a wider audience able to use the same tool set, regardless of their Linux distribution. This wouldn't need to be limited to gcc and binutils- any package that makes sense to run on a non-arm system might be a valid candidate including qemu, cross-gdb, etc as you mentioned below. My general assumption is that this would be a pure-Linaro set of packages so that the libc linaro-gcc links with would be linaro-libc, rather than Fedora-arm libc- that sort of thing. 2. Making the Linaro native package set available on Fedora ARM. This is tricky and will be both technically interesting and perhaps controversial. Questions to be answered include things like: Should linaro gcc replace the system gcc? Whose libc should be used? Regarding next steps, I'm afraid we don't have much Fedora packaging knowledge in Linaro but are happy to help when you run into problems and do any bug triage. Any thoughts on where the scripts or binaries would be hosted, or who would keep it up to date? That's the big question- who would support this endeavor? We have precedent for #1 in Fedora with the mingw cross compiler, but that is very Fedora-centric. To bring in the wider rpm-based community, Linaro is the logical place to host as it is the source. With that in mind, what would we need to do to make rpms automagicaly build any time debs are produced? Once packages are in rpm format it's very straight-forward for anybody to start using them, pulling updates, etc. You might want Linaro GDB, QEMU, and the work that's going on into libjpeg-turbo as well. We do the changes in Ubuntu to demonstrate the improvements, but I wonder if there's a way of sharing the whats and whys so other distros can consider making the same changes. Fedora generally pulls from the official upstream so anything that gets pushed there trickles back down eventually. It's not exactly ideal for cooperating on multi-package architecture-specific distribution such as Linaro produces, but the changes do make their way eventually. In Fedora ARM we've reinvented the wheel a few times, as it were, and would like to bridge the upstream gap wherever feasible. Would you all be interested in a conference call to discuss? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Linaro toolchains and Fedora
On 11/29/2011 05:17 PM, Michael Hope wrote: Sounds good. Note that Linaro produce a drop in replacement for FSF GCC so we should be able to re-use your existing packaging. How about splitting things up, such as gcc vs g++ vs Fortran vs binutils packages? We have a concept of source rpms and binary rpms. A source rpm is (typically) composed of a source tarball, 0 or more patches to be applied to it, and a recipe that turns building the sources and patches into one or more binary rpms. In the case of gcc we split out binary rpms by language. On my desktop at home for instance I have these installed: gcc-java-4.6.2-1.fc16.x86_64 gcc-gfortran-4.6.2-1.fc16.x86_64 gcc-c++-4.6.2-1.fc16.x86_64 gcc-4.6.2-1.fc16.x86_64 gcc-gnat-4.6.2-1.fc16.x86_64 But they all came from the same source rpm. Binutils, being a different project, gets its own source and binary rpm. We don't have a libc as there hasn't been the need. The cross compiler could either target the Fedora ARM port or the Linaro LEBs. This is interesting. Typically if you have an arm-linux-* compiler, it's been built with sysroot support. I'd just assumed you are providing a standard sysroot that accompanied gcc. Last I looked this was necessary for building target libraries (libgcc_s, libstdc++, etc). Is the Ubuntu libc being brought in for this purpose? If that were the case then sure, we'd want the Fedora libc to be used. On the other hand, let's say we're talking about ARMv8 where there is not yet a Fedora or Ubuntu build, as such, what's the plan there? I guess I better look at your total package list to understand what is and isn't included. Marcin is working on a gcc-linaro package that you can install alongside the native compiler. The other question of 'could Fedora switch to Linaro GCC' is a big one but we do support ARMv7, ARMv5, x86_64, and i386, will investigate bugs found on other platforms, and have been used by Ubuntu for some time. Those should help calm some nerves :) Yeah, an along-side package will be a good start. I can't see Fedora itself diverging from FSF-upstream, but enabling end-users to pick the right compiler for the job is very desirable (This is actually part of my group's day job with GNUPro). That's the big question- who would support this endeavor? We have precedent for #1 in Fedora with the mingw cross compiler, but that is very Fedora-centric. To bring in the wider rpm-based community, Linaro is the logical place to host as it is the source. With that in mind, what would we need to do to make rpms automagicaly build any time debs are produced? Once packages are in rpm format it's very straight-forward for anybody to start using them, pulling updates, etc. I'd have to bring that up with management. We'll support you if you use it but producing and maintaining the packaging is an overhead. This could be handled in a number of ways, depending on how builds are triggered and what external interfaces are available. Let's say, hypothetically, that we created a build system that poked Linaro's servers once an hour looking for package updates and automatically downloaded source updates, did builds, and pushed the results somewhere accessible. While the setup for such a system is heavy, ongoing maintenance would generally be lighter. Now, what if instead of an automated spider, there was instead a mechanism wherein if a build was initiated by Linaro, it triggered that same mechanism? We're very interested in collaboration and looking to understand the boundaries in which we can work together. Since your experience to-date doesn't have any Fedora-ness in it, I'm assuming RH would need to lay foundation for this sort of multi-distro build idea. That would be good. I'm travelling next week so the week of the 12th is best. Let's see where we go over email and organise a call past that. Okay, let's stick with e-mail for now. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] builder io isue
On 12/24/2011 09:25 PM, Dennis Gilmore wrote: Just throwing out what im seeing. lets see what ideas we can come up with. performance is better than before. and seneca has done a great job and put a lot of hard work into the reorg and im thankful for that. We just have another bottleneck to address. Allocating builders to individual rather than a single raid volume will help dramatically. Since hfp/sfp F15 builds happen at the same time, having 2 hfp disks and 2 sfp disks is a good start. Split it up again by some other criteria- you want to try to ensure that any one builder only causes one spindle to be used and any 2 builders each only cause 2 spindles to be used (1-to-1), and so forth. As long as any single spindle isn't doing multiple simultaneous mock inits it should scale pretty well. Allocate the large files the builders are using all at once (no sparse files) to ensure large read/writes don't require seeks. Use the async nfs export option if it isn't already in use. Disable fs journaling (normally dangerous, but this is throw-away space). Use noatime mounts if that won't break package builds checking filesystem conformance. Once all that is done, tweak the number of nfsds such that there are as many as possible without most of them going into deep sleep. Perhaps somebody else can suggest some optimal sysctl and ext4fs settings? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] builder io isue
On 12/25/2011 03:47 AM, Gordan Bobic wrote: On 12/25/2011 06:16 AM, Brendan Conoboy wrote: Allocating builders to individual rather than a single raid volume will help dramatically. Care to explain why? Sure, see below. Is this a proper SAN or just another Linux box with some disks in it? Is NFS backed by a SAN volume? As I understand it, the server is a Linux host using raid0 with 512k chunks across 4 sata drives. This md device is then formatted with some filesystem (ext4?). Directories on this filesystem are then exported to individual builders such that each builder has its own private space. These private directories contain a large file that is used as a loopback ext4fs (IE, the builder mounts the nfs share, then loopback mounts the file on that nfs share as an ext4fs). This is where /var/lib/mock comes from. Just to be clear, if you looked at nfs mounted directory on a build host you would see a single large file that represented a filesystem, making traditional ext?fs tuning a bit more complicated. The structural complication is that we have something like 30-40 systems all vying for the attention of those 4 spindles. It's really important that each builder not cause more than one disk to perform an operation because seeks are costly, and if just 2 disks get called up by a single builder, 50% of the storage resources will be taken up by a single host until the operation completes. With 40 hosts, you'll just end up thrashing (with considerably fewer hosts, too).. Raid0 gives great throughput, but it's at the cost of latency. With so many 100mbit builders, throughput is less important and latency is key. Roughly put, the two goals for good performance in this scenario are: 1. Make sure each builder only activates one disk per operation. 2. Make sure each io operation causes the minimum amount of seeking. You're right that good alignment and block sizes and whatnot will help this cause, but there is still greater likelihood of io operations traversing spindle boundaries periodically in the best situation. You'd need a chunk size about equal to the fs image file size to pull that off. Perhaps an lvm setup with strictly defined layouts with each lvcreate would make it a bit more manageable, but for simplicity's sake I advocate simply treating the 4 disks like 4 disks, exported according to expected usage patterns. In the end, if all this is done and the builders are delayed by deep sleeping nfsds, the only options are to move /var/lib/mock to local storage or increase the number of spindles on the server. Disable fs journaling (normally dangerous, but this is throw-away space). Not really dangerous - the only danger is that you might have to wait for fsck to do it's thing on an unclean shutdown (which can take hours on a full TB scale disk, granted). I mean dangerous in the sense that if the server goes down, there might be data loss, but the builders using the space won't know that. This is particularly true if nfs exports are async. Speaking of dangerous tweaks, you could LD_PRELOAD libeatmydata (add to a profile.d file in the mock config, and add the package to the buildsys-build group). That will eat fsync() calls which will smooth out commits and make a substantial difference to performance. Since it's scratch space anyway it doesn't matter WRT safety. Sounds good to me :-) Build of zsh will break on NFS whateveryou do. It will also break on a local FS with noatime. There may be other packages that suffer from this issue but I don't recall them off the top of my head. Anyway, that is an issue for a build policy - have one builder using block level storage with atime and the rest on NFS. Since loopback files representing filesystems are being used with nfs as the storage mechanism, this would probably be a non-issue. You just can't have the builder mount its loopback fs noatime (hadn't thought of that previously). Once all that is done, tweak the number of nfsds such that there are as many as possible without most of them going into deep sleep. Perhaps somebody else can suggest some optimal sysctl and ext4fs settings? As mentioned in a previous post, have a look here: http://www.altechnative.net/?p=96 Deadline scheduler might also help on the NAS/SAN end, plus all the usual tweaks (e.g. make sure write caches on the disks are enabled, if the disks support write-read-verify disable it, etc.) Definitely worth testing. Well ordered IO is critical here. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] builder io isue
On 12/25/2011 09:06 PM, Gordan Bobic wrote: Why not just mount direct via NFS? It'd be a lot quicker, not to mention easier to tune. It'd work for building all but a handful of packages (e.g. zsh), but you could handle that by having a single builder that uses a normal fs that has a policy pointing the packages that fail self-tests on NFS at it. I'm not acquainted with the rationale for the decision so perhaps somebody else can comment. Beyond the packages that demand a local filesystem, perhaps there were issues with .nfsXXX files, or some stability problem not seen when working with a single open file? Not sure. 512KB chunks sound vastly oversized for this sort of a workload. But if you are running ext4 on top of loopback file on top of NFS, no wonder the performance sucks. Well, 512KB chunks is oversize for traditional NFS use, but perhaps undersized for this unusual use case. Sounds like a better way to ensure that would be to re-architect the storage solution more sensibly. If you really want to use block level storage, use iSCSI on top of raw partitions. Providing those partitions are suitably aligned (e.g. for 4KB physical sector disks, erase block sizes, underlying RAID, etc.), your FS on top of those iSCSI exports will also end up being properly aligned, and the stride, stripe-width and block group size will all still line up properly. I understand there was an issue with iSCSI stability about a year ago. One of our engineers tried it on his trimslice recently and had no problems so it may be time to reevaluate its use. But with 40 builders, each builder only hammering one disk, you'll still get 10 builders hammering each spindle and causing a purely random seek pattern. I'd be shocked if you see any measurable improvement from just splitting up the RAID. Let's say 10 (40/4) builders are using one disk at the same time- that's not necessarily a doomsday scenario since their network speed is only 100mbps. The one situation you want to avoid is having numerous mock setups at one time, that will amount to a hammering. How much time on average is spent composing the chroot vs building? Sure, at some point builders will simply overwhelm any given disk, but what is that point? My guess is that 10 is really pushing it. 5 would be better. Using the fs image over loopback over NFS sounds so eyewateringly wrong that I'm just going to give up on this thread if that part is immutable. I don't think the problem is significantly fixable if that approach remains. Why is that? I don't see why you think that seeking within a single disk is any less problematic than seeking across multiple disks. That will only happen when the file exceeds the chunk size, and that will typically happen only at the end when linking - there aren't many cases where a single code file is bigger than a sensible chunk size (and in a 4-disk RAID0 case, you're pretty much forced to use a 32KB chunk size if you intend for the block group beginnings to be distributed across spindles). It's the chroot composition that makes me think seeking across multiple disks is an issue. And local storage will be what? SD cards? There's only one model line of SD cards I have seen to date that actually produce random-write results that begin to approach a ~5000 rpm disk (up to 100 IOPS), and those are SLC and quite expensive. Having spent the last few months patching, fixing up and rebuilding RHEL6 packages for ARM, I have a pretty good understanding of what works for backing storage and what doesn't - and SD cards are not an approach to take if performance is an issue. Even expensive, highly branded Class 10 SD cards only manage ~ 20 IOPS (80KB/s) on random writes. 80KB/s? Really? That sounds like bad alignment. Strictly speaking, journal is about preventing the integrity of the FS so you don't have to fsck it after an unclean shutdown, not about preventing data loss as such. But I guess you could argue the two are related. Right, sorry, was still thinking of async. I'm still not sure what is the point of using a loopback-ed file for storage instead of raw NFS. NFS mounted with nolock,noatime,proto=udp works exceedingly well for me with NFSv3. I didn't think udp was a good idea any longer. Well, deadline is about favouring reads over writes. Writes you can buffer as long as you have RAM to spare (expecially with libeatmydata LD_PRELOAD-ed). Reads, however, block everything until they complete. So favouring reads over writes may well get you ahead in terms of keeping he builders busy. It really begs the question: What are builers blocking on right now? I'd assumed chroot composition which is rather write heavy. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] rawhide status update
On 01/20/2012 08:37 AM, Ilyes Gouta wrote: Awesome! Are we targeting hardfp as ABI for armv7? For Cortex A8 or A9 - like class SoCs? For Fedora purposes hardfp refers to the triplet armv7hl-redhat-linux-gnueabi. Specifically, gcc is configured with the following flags: --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a \ --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Primary architecture proposal alpha draft
It's a little disjoint and out of order, but the first draft of the primary architecture proposal is available for some serious editing at: https://fedoraproject.org/wiki/Architectures/ARM/Planning/Primary This is based on notes from FUDcon and a couple cell phone shots of chalk boards. If I've missed anything feel free to add, or send me additional chalk board jpegs containing the areas that I missed :-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Possible File Formats for a Fedora ARM release
On 02/02/2012 02:41 PM, Gordan Bobic wrote: Not going to happen, sadly. The rootfs is common across all the devices (armv5tel for soft-float, armv7hl for hard-float). Hold up, there's a middle ground that we can shoot for here, even prior to everybody getting onboard with FDT. Kernels are SoC specific. Not quite as narrowly specialized as device specific, but it's still not going to be a one-size-fits all, at least not any time soon (probably years). What it really comes down to is getting the bootloader (typically uboot) to load a kernel and initramfs. Maybe it's an OMAP or a Tegra kernel, maybe it's Kirkwood or Highbank or Armada or or or... but you can squeeze all that onto one tarball. The support grid is really just 2x2: You're either armv5tel or armv7hl. You either need a separate partition for bootloader bits (omap, etc scenario) or you don't (tegra scenario). Putting together tarball that has everything a person needs for most systems is doable. A couple paragraphs per board type for how to get the specific board type is all it will take in the way of specialized documentation. In most cases it will simply be a matter of a couple setenv commands. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] heavybuilders
On 02/27/2012 02:25 PM, Dennis Gilmore wrote:
[snip]
I wanted to get others thoughs before i went and made the change
Just to be clear, these two systems are the same machines:
hsv-trimslice-9-v5telN N0.0/2.0 arm -
hsv-trimslice-9-v7hl Y N2.0/2.0 armhfp
2012-02-27 22:04:45
We just provision them as v5 or v7 according to what it looks like is
needed. That's the idea anyway- we aren't doing enough builds at once
that we've had to balance anything.
FYI, the HSV pandas also have dedicated sata disks on them and are
roughly the performance equivalent of the trimslices because of it. The
actual tally of heavybuilders (defined as having dedicated usb-sata
storage) is:
hsv-panda-1-v5tel
hsv-panda-2-v5tel
hsv-panda-3-v5tel
hsv-panda-5-v5tel
hsv-panda-6-v5tel
hsv-panda-8-v5tel
cdot-trimslice-13-1
cdot-trimslice-14-1-v7hl
hsv-trimslice-10-{v5tel,v7hl}
hsv-trimslice-9-{v5tel,v7hl}
hsv-trimslice-8-{v5tel,v7hl}
hsv-trimslice-7-{v5tel,v7hl}
hsv-trimslice-6-{v5tel,v7hl}
We can make all the HSV trimslices into v7 builders and that will give
us a 6/6 split, which seems reasonable.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F17 runtime issue web page
Hi folks, If you're thinking about taking the F17 alpha1 rootfs for a test drive this message is for you. A few weeks ago Peter added a section to the Fedora ARM page that detailed important packages that were failing to build. Today the majority of those build failures marked as FIXED so this has been working quite well. So well, infact, that Peter was able to make a root filesystem exclusively using Fedora 17 packages, a major milestone. The next thing to be addressed are runtime failures that people are running into as they try out the alpha1 rootfs. If IRC and the mailing list are any indication, we've all hit a few issues with F17 ARM alpha, though generally after a couple changes it's been working *really* well for me. Peter and I talked about it and the logical conclusion was to add a runtime issue section to the problem page, which I've done. Thus, if you're trying out the F17 ARM alpha 1 and run into any trouble, please visit: https://fedoraproject.org/wiki/Architectures/ARM/Fedora17_rawhide If you don't see your problem, please add it to the list. If you do see your problem and know the solution, please make sure the solution is in the list. We'll do our best to keep the list current and get the status of every item to FIXED And while you're there, if you happen to see a broken package you'd like to work on, please do! Thanks everybody. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Primary Architecture - VFAD proposal for tomorrow (Wed Mar 14th 2012 afternoon EST)
On 03/13/2012 12:02 PM, Jon Masters wrote: Hi Folks, I would like to propose that we have a VFAD tomorrow to get the Primary Architecture stuff moving forward, prior to our status phone call, and rolling on into it. What say you? Yes please. Any time after 1900 UTC is good for me. For those who would like to take part please have a look at: https://fedoraproject.org/wiki/Features/FedoraARM The How To Test, User Experience, and so forth sections need plumping. The rest needs trimming :-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Primary Architecture - VFAD proposal for tomorrow (Wed Mar 14th 2012 afternoon EST)
On 03/13/2012 12:02 PM, Jon Masters wrote: Hi Folks, I would like to propose that we have a VFAD tomorrow to get the Primary Architecture stuff moving forward, prior to our status phone call, and rolling on into it. What say you? Let's go with 20:00 UTC (1PM Pacific, 4PM Eastern). Please join #fedora-arm and if possible dial in at: Toll Free Dial-In Number (US Canada): (800) 451-8679 International Dial-In Number: +1-(212) 729-5016 Conference code: 617-759-1337 Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Primary Architecture - VFAD proposal for tomorrow (Wed Mar 14th 2012 afternoon EST)
On 03/14/2012 10:26 AM, Chris Tyler wrote: $0.02 Added- thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] ARM Primary Feature page updated
Hi folks, I have made further updates to the ARM Primary Feature page and think it is now good enough for FESCO. If you would like to give it a look before it is reviewed, now is the time. https://fedoraproject.org/wiki/Features/FedoraARM -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/19/2012 09:30 PM, Brendan Conoboy wrote: Being a PA carries the obligation that all packages in Fedora will be available. The proposed avenue of making broken packages temporarily excludearch is questionable and needs work. The thing that worries me about the excludearch is that there is no mechanism forcing ultimate resolution on packages which could be made to work on ARM. Right now the goal of PA is a strong motivator for fixing packages. If we make it to PA, how will we stay motivated? We're only ever going to asymptotically approach the complete x86 package set so we're going to have to strike a middle ground. What that is is open for discussion, but basically it breaks down into 3 categories: 1. Packages that are truly x86 specific do not need to be made to work on ARM. And the packages that depend upon them hopefully don't either, but there's going to be some issues there. 2. Packages that FTBFS on x86 do not need to be made to work on ARM until they're also made to work on x86. 3. Anything left can and should be made to work on ARM. How many packages are in this set? If it's down to a few dozen let's just fix them up and be done with it. If it's a few hundred we need a plan that involves getting to primary before we're at 100%. So, basically, we need data. What packages fit where in the above 3 categories? How close are we? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/19/2012 04:46 PM, Brendan Conoboy wrote: How do packagers test and resolve failures on ARM if they don't own an ARM device? I like Chris's suggestion of the simulator- that's good coverage. I'd also support providing login hosts to... somewhere. Seneca? Spare systems in PHX? I'm not sure, but it seems like a good idea to me. When will server hardware be available? During the discussion I said 2-5 months. Notting said 2 was good, 5 was bad. I'll just extrapolate that 3 is not as good and 4 isn't as bad, but ultimately it's going to be when the hardware is available. Hopefully it'll be closer to the 2 than the 5. Why isn't being a secondary architecture good enough? Greater stability in PHX, faster infrastructure, wider mirror selection, greater credibility as a distribution. Why not wait for 64 bit ARM? The mainstay of 64 bit ARM hardware won't be available for a couple years. Incredible ARM systems will be available in the interim that Fedora can run on with comparatively little effort. Additionally, much of what's needed on 64 bit ARM can be done in the 32 bit space (Virtualization support for instance). With there being so many different kernel variants, how will a kernel build complete in a reasonable period of time? Beats me- every proposal is a bit hackish. The builds being done in Koji are great, but what is the plan for composes, QE and installation? This part of the plan really needs some work. Even our discussions about how to compose images isn't quite the same as how to handle QE when it comes time to do an alpha/beta/rc/etc. If Anaconda isn't used to do installations, what will be doing the things Anaconda does which just installing a bunch of packages doesn't? (I don't know what these are) I would hope the standard image builders handle this sort of thing, but do not know. Will there be extra patches in the kernel to enable new vendors' ARM processors or will upstream continue to be the way? Jon answered that it will be upstream only. I agree. Same policy as x86. What does the kernel team think about the the time required to build kernels on ARM? How will it affect their workflow? I suspect Jon is going to discuss with kernel@. The proposal suggests building just a versatile express kernel by default (to save time), then using koji flags to support alternate kernels. Is this possible? According to Dennis: No. So, let's figure out how to get reasonable build times and good breadth on kernel builds. In the event that kernels are built separately per the above, what mechanism will be used to keep the kernels in sync? We may need to have a less ambitious list of kernels. Perhaps keep omap, tegra, highbank, but drop IMX, armada, etc. We'll see where this goes. Assertions from the meeting: There must be a commitment of hardware both for build systems and test systems for PA. In light of qemu+versatile the general test systems might be optional, but in principle if we have systems to spare and appropriate access mechanisms I don't see why not. Being a PA carries the obligation that all packages in Fedora will be available. The proposed avenue of making broken packages temporarily excludearch is questionable and needs work. The thing that worries me about the excludearch is that there is no mechanism forcing ultimate resolution on packages which could be made to work on ARM. Right now the goal of PA is a strong motivator for fixing packages. If we make it to PA, how will we stay motivated? FTBFS issues should simply be fixed (That's not an ARM problem, but we're definitely impacted by it). Suggest presenting the FTBFS list and subtracting it from the list of packages we need for ARM task list. The changes to QE, particularly because of Anaconda, will be substantial. This is not addressed in the proposal. Agree. Help! Installability doesn't necessarily mean Anaconda (See EC2), but it does mean something. A real plan is called for. We just need to formalize our plan for image generation using standard tools (Hopefully whatever was used for EC2 is valid here). All PA kernels must be derived from the same source rpm. Yes. ... Regarding mail to the 4 groups, What do we want to ask each of them? Releng: Do you have any concerns about moving ARM to PA? What are the things you need to see in place? What do you not want to own? Infrastructure: Do we have the hardware/budget ready? What do you need in place that isn't now? What do you not want to own? QE: What do you need to do proper QE on arm? How much load will this add? How can we help? Kernel: ARM will introduce build time delays, but x86 builds will still finish as fast as ever. Is this sufficient? What do you need to see to be okay with ARM on PA? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/20/2012 02:48 AM, Gordan Bobic wrote: Are alignment problems not considered bugs? It's not just that this will break code on ARM v7 and IIRC SPARC, but alignment issues also cause cache line straddling which has a performance impact. I took this question to be a case of knowing-just-enough-about-ARM-to-be-harmful. It's really a non-issue, particularly since later ARM chips don't have the problem. Is there any actual reason why Anaconda cannot be used? What is to stop booting a suitable installation kernel for the target platform and having that fetch/mount an installation rootfs that takes over, same as it does in x86? Granted the amount of RAM is an issue, but that's just a case of dieting the installer back to a saner size (de-lobotomizing the text mode installer back to how it was before F11, for example). Anaconda isn't *quite* ready to go yet. And you don't actually gain much by using Anaconda for many devices- you still have to write an image to a removal storage device. Which you then run boot... and it writes a new image to a storage device. You've just made more work for yourself when you could have installed a working image directly. On the server side, PXE abilities mean there's more to be said about Anaconda support. The only issue is, they don't exist yet :-P I found that if the kernel has support for the right SoC, it is simply a case of adding a suitable SoC merge config file and plumbing it in for the build based on a build flag. I have somewhere a 2.6.32-220.something kernel src.rpm that builds for both x86 and Marvell Kirkwood, and it was reasonably straightforward to achieve (even if it did require fixing a few bugs that were introduced by upstream vendor patches that didn't manifest on the primary arch). Yes, using one kernel source rpm is working fine for us. It's the long build time which needs to be overcome. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/21/2012 05:22 AM, Chris Tyler wrote: https://bugzilla.redhat.com/show_bug.cgi?id=673691 Agreed, alignment fixups must be enabled early. Ah, I thought this was already resolved. So, er, we just need to followup on this BZ until it's resolved in rawhide? I see it's already in ARMTracker. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] (late notice) Fedora-ARM weekly call on in 15 minutes
Hi folks, Let's get together on the phone and/or online and have a chat. There's been a lot of activity in the last couple weeks and it'd be good to discuss next steps, strategy, etc. Conference code: 617-759-1337 (no passcode required) Toll Free Dial-In Number (US Canada): (800) 451-8679 International Dial-In Number: +1-(212) 729-5016 Also join #fedora-arm on Freenode -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Soliciting feedback on Fedora ARM primary arch proposal
Hi everybody. This Monday FESCo did an initial review of the ARM team's ARM PA Feature proposal. As part of that review, they requested we get in touch with affected groups including releng. While Dennis Gilmore has some specific plans in mind and was even involved in creating the feature page, I'd like to solicit your (including Dennis) feedback on what's been written and what still needs to be written as it pertains to release engineering. The feature page in question is: https://fedoraproject.org/wiki/Features/FedoraARM As you might have already ready on fedora-devel, this is a work in progress and has some known deficits (EG, That multiple-kernel koji-flag thing is going away). We'll keep updating it based on the feedback we receive until we have a plan that works for all the stakeholders. If you have some feedback that you haven't already shared on fedora-devel, or that you want to share again because it's really important and releng related please reply to this message and let us know. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 ARM Build Error Stats
On 03/21/2012 05:43 PM, Jonathan Chiappetta wrote: Number of unbuilt/cancelled/building pkgs = 469 Can you describe this one a little better? Is that unique packages or if there are two versions of a single package built does it add 2 to the number? Is it just a count of the latest in arm.koji.fp.o vs PA? Just some temporary stats for F17 thus far! Thanks as always, This is great by the way- would love to see it on a nightly basis. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 Build Times For All Pkgs Built By Trimslices (x86 vs x64 vs sfp vs hfp)
On 03/22/2012 11:45 AM, Jonathan Chiappetta wrote: So I'm sorry if some of the columns are blank, I'm not sure why some of the x86 and x64 columns are missing as they should have all their logs. Maybe its my script and curl is failing somewhere? I'm sorry about the formatting here but if there are is anyone out there who was a data analyzer in a past life maybe someone could help average out our total times vs theirs? Anyway, I'm sure someone might find something useful in the data below assuming all my numbers are correct... It looks like we only have data for sfp or hfp, but never both. Can you check that? Also, if you could put this on the wiki and send a pointer to the list that'd be great. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F17 snapshot images
Hi folks, I've put together a script to create up-to-date F17 snapshot images and am storing the result on my people page. These are based on Peter's F17 alpha1 images with the following changes: There is a tarball without any kernels included. There is a tarball with uBoot-wrapped kernels included (should have everything you need without messy mkimage commands). The armhfp version includes tegra, omap and imx kernels. The arm version includes kirkwood. There are bzcat+dd images for Tegra and OMAP- no partitioning necessary to get started. These decompress to 8GB- if you have a larger storage device resize2fs is your friend. The files are currently uploading and will be entirely there in a few more minutes. You can get the latest at: http://blc.fedorapeople.org/fedora-arm/f17/ This is very much a work in progress, completely unofficial, largely untested, but hopefully useful. Feel free to send me feedback. Enjoy, -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 snapshot images
On 03/29/2012 11:20 PM, Brendan Conoboy wrote: There is a tarball with uBoot-wrapped kernels included (should have everything you need without messy mkimage commands). The armhfp version includes tegra, omap and imx kernels. The arm version includes kirkwood. Oh, and the kernels are 2.6.4x.fc15 kernels which are known to work. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 snapshot images
On 03/30/2012 05:35 PM, Andy Green (林安廸) wrote: It's great that you're doing this, but I don't think dding partition + filesystems is a good idea. It's definitely tricky to get right. The number of possible configurations makes it tricky to do an efficient selection of images. I may end up doing a combination tegra+omap+etc image to cut down the waste. We found that various 8GB SD cards have different absolute numbers of available sectors, it can lead to eventual filesystem corruption if your image is slightly large than someone else's card. Well, the image is being created out of a sparse file with 8000 1048576 byte sectors. If that proves too many it would be little trouble to drop it down to 7900 or something. We'll see how it goes in practice. If someone's going to try this they're probably OK running fdisk and using tarballs. Yeah, the uboot enabled kernel tarball will probably be the most universally useful. I personally had plenty of trouble marking working uboot files so leveraging David Marlin's work on grubby will hopefully spare others that trouble. Meanwhile, a number of people have asked for images they can dd, so I'm trying to fulfill both needs. I've been using Peter's F17 alpha1 image and following progress with updates, it's been very good. It's stuck as of last week with gnome-shell problems though. But generally package completeness has been increasing really well last few weeks, great job. What are the gnome-shell problems? Perhaps they're well known but I'm not acquainted with them. If we're missing a package that will help things out let me know and I'll put it in the next snapshot. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 snapshot images
On 03/31/2012 08:10 AM, Chris Tyler wrote: On the Raspberry Pi Fedora Remix I'm shrinking the image as much as possible by shortening the last (root) partition. The partition is resized to fill the SD card on first boot (fdisk, reboot, resize2fs). This results in a small image size, minimizes unnecessary writes to the SD card, works on any card size, and lets you take full advantage of the space on the card. Perhaps we should adopt that approach for the images? Would be happy to add this- with that sort of functionality I'd have no reservation about creating a 1.990GB image. Send me a pointer to how you're doing this during the first boot and I'll integrate it into the rootfs image generator. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Quick update on prelink
On 04/04/2012 02:24 AM, Jon Masters wrote: Try this trivial patch to src/get.c that educates prelink about our linker (so it won't try to prelink the linker itself). This will then pass the testsuite. On the one hand, if this is all it is it's almost annoying that I went to the lengths to understand how it works before looking at it in detail, but on the other Jakub has told me there's not a lot of good data on prelink-on-arm so I need to do more code review /anyway/. Please try this patch and see what happens. I've installed the prelink package from arm.koji on an armv5tel rootfs, let prelink run its cron job, and the resulting system appears to be working normally. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 snapshot images
Hi everybody, Based on the feedback on these images I've gone through a few more iterations of the build scripts and they've had some testing (thanks dmarlin, pbrobinson and smooge!). There are now images for: Trimslice (hard float, mmc and sda) Panda (hard float, mmc, and sda) Beagle (hard/soft, mmc) To install the image a command just use a command like: xzcat f17arm-latest-armhfp-trimslice-mmcblk0.img.xz /dev/device For reasons I'm not acquainted with using dd with a large bs value sometimes results in bad writes, so if you use dd keep bs small. Each image decompresses to 1900MB. Upon first boot it will begin the process of auto-resize the / partition to its full capacity. A second boot will complete the process (This is done using a modified version of Chris Tyler's raspberry pi remix resize script). All scripts used to generate the images is included in the same directory. Next up will likely be a unified trimslice/panda image. Fun! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/23/2012 08:06 AM, Dan Horák wrote: the main problem no only in ARM land is that many software developers like to develop their own atomic ops implementations in their project instead of using some standard one eg. from GCC :-( I fight with this problem again and again on s390 ... Are the fixes you're introducing s390 specific? Would love to reuse existing solutions if they're not already in use. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Some comments on bconoboy's trimslice images
On 04/27/2012 05:51 AM, Richard W.M. Jones wrote: In general pretty good - they work well. However there are a few problems I encountered: Hey, thanks for taking them for a test drive! (1) There's no source for the boot scripts. I think you should put the source along side the binaries, in /boot/uboot. I ended up using 'strings' and reconstructing them. Yeah, I end up using strings a lot myself. Next update I'll throw the generator/boot.cmd template into /boot/uboot for easier tinkering. Long term goal is to move to uEnv.txt, but that won't help systems with built-in uboots that don't support it (trimslice). (2) The sda boot script works fine, however the mmc boot script fails. 'fatload mmc 0:1 ...' should be 'fatload mmc 1:1 ...' (in both places). As mentioned elsewhere in the followups this is because there are two sd readers on a trimslice and you're using the mmc1 location. Perhaps for trimslice there should be an mmc0 and mmc1 image? Once I merge trimslice/panda images that might follow. (3) If you have both images installed, then it boots one of them at random, because it boots from 'root=LABEL=rootfs' which picks one of the labelled root devices at random. Earlier images used root=/dev/someplace, but using root=LABEL=rootfs means fewer boot.scrs are (and less editing is) necessary. The right answer probably is a randomly generated UUID per image. I'll consider adding this next, unless David Marlin gets his lorax images all set before I get to it. They're the real plan. Thanks again! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Updated Fedora ARM qemu images?
On 04/28/2012 08:21 AM, Richard W.M. Jones wrote: I still can't get any Fedora 17 kernel (soft or hard FP) to boot on qemu-system-arm, on either F17/x86_64 or F17/arm host. On x86-64 it just consumes 100% of CPU, no console, no video, never touches the disk image. On ARM host, qemu-system-arm crashes in TCG. In fact, I have never once got qemu-system-arm to do anything useful, despite trying over many years. Peter is currently cleaning up the kernel configurey which will ultimately result in a versatile express kernel. We'll be testing with it and use it with qemu for producing a new image, documentation, etc. Suggest waiting a few days while this gets worked out. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Pixie Case, - Was ARMv5 and atomic operations
On 04/27/2012 04:38 AM, Nicolas Chauvet wrote: For the record, Pixie is an image renderer engine and requires massive CPU load which worth to have optim enabled. This is also a 'Final component' so it will not be triggered by something that could run on a armv5 only CPU. So my question is how can I opt-out armv5tel to force armv7l compilation instead ? There isn't really an opt-out. We build packages for both armv5tel and armv7hl. If it can't possibly be made to work for armv5tel you can excludearch it. If it can be made to work with some help let's do that. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Debugging our kernels under qemu + gdb
On 05/11/2012 01:50 PM, Richard W.M. Jones wrote: Thanks, I will. Are these going to replace the current Fedora kernel config at some point? Yes, in a few days I would expect the default Fedora ARM kernel to be vexpress oriented. We're still working on integrating the necessary vexpress configuration options. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM VFAD - May 11th - 12pm (EDT)
On 05/09/2012 03:32 PM, Paul Whalen wrote: As per our meeting today, we would like to have a VFAD on Friday May 11th at 12pm (EDT) to run through the modified Fedora ARM release criteria (http://etherpad.proximity.on.ca:9001/p/k8c7SAPEhA ) in preparation for the Fedora 17 ARM Beta release. Please take a moment before the VFAD to review the release criteria and provide feedback in #fedora-arm rather then editing the document directly. Hi Everybody, Thanks to everybody who took part testing images during today's VFAD! Here is a summary of what was covered: The following images (At http://scotland.proximity.on.ca/arm-nightlies/) are booting and operating correctly: Trimslice for serial console with SD Card Trimslice for serial console with USB Sata Raspberry Pi for serial console with SD Card (Non-F17 kernel) Raspberry Pi for X console with SD Card (Non-F17 kernel) Versatile Express for serial console with qemu-system-arm (Non-F17 kernel Versatile Express for X with qemu-system-arm (Non-F17 kernel) The following images did boot successfully, but some people observed network issues: Beagleboard XM for serial console with SD Card (Hard Float) Beagleboard XM for serial console with SD Card (Soft Float) I'm rebuilding the Beagle XM images now with a new uboot and an old (known good) kernel. We'll be looking for testers on these- let me know if you plan on trying out either configuration and I will let you know when the new image is in place. The following images did not boot successfully: Pandaboard for serial console with SD Card Pandaboard for serial console with USB SATA The Pandas had problems with the uboot environment (It had never been tested), as well as a kernel panic during boot. Like the Beagle XMs, these are being regenerated. Let me know if you plan on retesting. Additionally, the USB SATA image will require a companion SD image to provide MLO/UBoot. This is not currently provided. The following image was not tested: iMX51 for serial console with SD Card. This image might work with an Efika smarttop (?), but nobody had a chance to test it out. Please note if you're planning on testing this, this is not going to give you a groovy Efika F17 GUI experience- they're still working on the kernel drivers, as I understand it. It's a serial console only image. With regard to release criteria: Alpha Release Criteria: o Each image is accompanied by an MD5 sum. o No known file conflicts exist. o Firstboot: Is not currently operable, but the images do automatically resize and a guest account is available for the X images. Todo. o Virtual consoles: Unknown. Todo. o Default web browser: A web browser is not installed in any image. Suggestions for a suitable browser welcome. Todo. o Update status: Images are up-to-date at generation time. Yum update works. o Graphics: Base X, XFCE Desktop are installed and provide artwork. Graphical bootloader was not tested (rhgb?). Graphical login and xfce work. o Syslog: Is installed, functional. o Shutdown: Reboot reboots or halts, halt halts. Beta Release Criteria: o Alpha release criteria met? Not quite, see above. o Bugs in beta tracker were not checked today. o All images are under 4G in size when uncompressed. X images are 3800MB. Serial images are 1900MB. o Unaware of virtual console testing. Todo. o Unaware of any audio testing performed. Todo. o Desktop testing was minimal but breadth is incomplete (no web browser). Todo. o Removable media was not automatically mounted (or detected) on at least 1 Trimslice. Todo. o Default update manager testing indicates gnome-packagekit is needed. New X images will include this package. o Desktop reboot/shutdown/suspend untested. Plans for what's next: o jonmasters to track down the OMAP (Panda/Beagle) issue. o bconoboy to regenerate images with OMAP workarounds and other VFAD feedback fixes. o pbrobinson to integrate Versatile Express kernel configuration into official kernel-3.3.x.fc17 tree. o Much more testing (It's happening even now). Thanks to jcapik, pbrobinson, dmarlin, dgilmore, pwhalen, pbrobinson, jskarvad, djdelorie, jonmasters, jsmith, jmontleon, ctyler, maxam, and the rest of the Seneca crew for testing images, providing feedback, and making today a great success. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM VFAD - May 11th - 12pm (EDT)
On 05/11/2012 04:54 PM, DJ Delorie wrote: I did install and test firefox, it worked fine, including installing add-ons, downloading files, and logging in to FAS. Right- followup question: Is Firefox what we want in the X images? o Desktop reboot/shutdown/suspend untested. I tested this in qemu, it worked. Great! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 17 GA blocker
On 05/15/2012 01:05 PM, Jon Masters wrote: Hi Folks, Not a beta blocker, but please make sure we add new linker path to the final requirements before GA. Since we'll have a compat symlink there will not be any impact to users. What's left to be done on this? Do we need a glibc update? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Unable to boot 3.3.6-3.fc17.armv5tel with qemu-system-arm
On 05/22/2012 12:54 PM, Alex Villacís Lasso wrote: If I specify -M vexpress-a9, I can sort of boot the kernel. However no block device matching the disk image appears anywhere, so the boot process drops to an debug shell, like this: The 3.3.6 kernels are exclussively versatile express so you must use -M vexpress-a9 [snip] [ 50.760153] dracut Warning: Unable to process initqueue dracut Warning: Unable to process initqueue [ 50.773711] dracut Warning: /dev/disk/by-label/rootfs does not exist dracut Warning: /dev/disk/by-label/rootfs does not exist This is because your initramfs does not contain the mmci driver. There is a workaround installed in the current set of images being generated right now. I just booted and tested this one: http://scotland.proximity.on.ca/arm-nightlies/vault/f17arm-20120522-192910-armhfp-vexpress-mmcblk0.img.xz You might find the 'boot-vexpress' and 'boot-vexpress+x' scripts, not to mention the prebuilt initramfs in this archive to be helpful: http://scotland.proximity.on.ca/arm-nightlies/vault/f17arm-20120522-192910-armhfp-vexpress-mmcblk0-kernel.tar.xz -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Discussion - F17 GA release for ARM
On 05/30/2012 11:52 AM, Paul Whalen wrote: http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Final_Release_Criteria Let's begin the discussion on the list - What do you foresee blocking us from our final release of F17? There's one addition I would like to see to the final release criteria: Updated linker path in gcc and glibc. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Discussion - F17 GA release for ARM
On 05/31/2012 01:03 AM, Steve McIntyre wrote: 2 reasons: * it would be nice if people using Fedora create binaries using the right path for the future * the compat symlink on its own isn't enough, changing the filename means the soname has changed too. There's a (quick and very dirty) glibc patch to make things work regardless - see [1] In addition to the glibc and gcc patches we will likely need to update prelink as well. It has some hard-coded strings for what to avoid mangling. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [PATCH] arm: fixes for Calxeda ECX-1000 from testing
On 06/01/2012 11:26 AM, Mark Langsdorf wrote: I'll submit a 3.4 and a 3.5 patch later today or Monday, then. Hi Mark, To be explicit, what we'd like to see is the 3.4 patch concurrent with an upstream submission. Once you've submitted the patch to upstream we'll carry it in the Fedora kernel until such time as it's accepted upstream and filters down again. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Agreed linker path changes still not in Fedora
On 06/08/2012 09:51 AM, Steve McIntyre wrote: Since then, distros have done the work necessary to use the linker path that was agreed, making changes in gcc and glibc packages. Some people went with the initial patches that were proposed for the sake of urgency, e.g. Ubuntu built using these initial patches for their 12.04 release. Given the all-party agreement on the meat of the problem (the linker path itself), the finer details of the final patches didn't matter so much. Others (Fedora) wanted to wait for the patches to be accepted upstream before accepting them. That's also understandable and reasonable. However, those patches have been upstream for several weeks now and it seems nobody has cared enough to pull them into Fedora yet. Steve, We pulled in the glibc as soon as it went upstream, but for some reason the glibc patch did not actually activate. We're looking into it. FYI, if you support prelink it is likely you will need to add a patch there as well. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 17 ARM Release Candidate VFAD results - Follow up VFAD on Monday June 18th
On 06/15/2012 05:25 PM, Paul Whalen wrote: New images for RC2 are being created now! Due to the overwhelming success of today, we are holding another VFAD next week: Fedora 17 - RC2 image validation VFAD Monday June 18th - 12pm EDT #fedora-arm on Freenode If anybody wants to get a jump on Monday's testing the latest nightlies have fixes for all blockers from yesterday's RC1. The images can be retrieved from: http://scotland.proximity.on.ca/arm-nightlies/ Cheers, -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] beaglebone?
On 07/12/2012 08:08 AM, Dr. Michael J. Chudobiak wrote: Hi all, Is a ready-to-go F17 image available for testing the BeagleBone yet? Is there an ETA? I am making an experimental image right now. I will send a followup email when it is ready for testing. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] New Fedora-ARM Kernel Built -- Check it out and test it!
On 09/13/2012 07:04 PM, jon.chiappe...@senecacollege.ca wrote: [ http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=93466 kernel-3.6.0-0.rc4.git2.1.fc18 ] Boots with some soft lockups on my trimslice using sda, original uboot and modified (higher up) uInitramfs load address. Full log: http://fpaste.org/pQaq/ Boot commands: setenv bootargs mem=384M@0M mem=512M@512M nvmem=128M@384M vmalloc=248M video=tegrafb console=ttyS0,115200n8 ro root=/dev/sda2 nohdparm rootwait earlyprintk ext2load usb 0:1 408 uImage-tegra ext2load usb 0:1 840 uInitrd-tegra bootm 408 840 -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora hangs on my TrimSlice
On 09/21/2012 09:23 AM, Petr Machata wrote: Anyone has seen this sort of error? Any ideas how to resolve it? Are you using the latest uboot? We've had trouble with F17 GA on the recently released uboot. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
On 10/06/2012 06:50 AM, Peter Robinson wrote: Of course none of this is set in stone, it's a discussion and just me putting my ideas into words. FWIW, I likewise think we should shoot for promotion of armv7hl to primary, leaving armv5 (or armv6) secondary. Numerous packages with atomics issues magically begin working this way. Additionally, in the timeframe we're talking about v7 is going to be the overwhelming majority of systems out there. One extra thought: If we move from armv5tel to armv6hl for the Pi's sake, there's still a big gain: A single koji builder can be used for both armv7hl and armv6hl builds. Supporting armv5tel means we need to provide separate builders for the alternate ABI, raising the overall number of builders required. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Just in case you don't read Slashdot :)
On 10/06/2012 07:19 AM, Peter Robinson wrote: We're planning on a 3.7 update in F18. The thing is that this is likely to be a disruptive upgrade as certain platforms (even without a unified kernel) will need to have a working device tree. Hence, the moment there is an -rc1 to poke at, we'll make sure this is lined up. We will when mainline goes to 3.7 as mentioned in the thread. In the interim we'll be building at testing the 3.7 kernel in rawhide. Depending upon how far behind we are releasing F18 ARM GA we might just include 3.7 from the start. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] BUG: scheduling while atomic: swapper/0/0/0x40000100
On 10/25/2012 04:10 PM, Jon Masters wrote: Here's the upstream ACK: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/127317.html The patch in question: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/124041.html -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Regarding Seneca Issues
On 11/28/2012 12:45 PM, Jon Chiappetta wrote: - repo issues (the generally perl based build failures due to repo issues). I reported I thought I had found the offending host but the issue appears to have come back. Was the host re-enabled, what testing has Seneca done? * Could you please provide the specific task links as examples or names of hosts that are causing the problem so we could diagnose the problem and look into resolving it? - builder issues, seeing issues with things like the disk space on the large builders without a resolution, or a resolution being reported. What is the status, is it fixed? * What are the problems with the large builders? Are there RAM issues, permission issues, low space issues? Which builders need to be looked at specifically because it's hard to solve this without the needed info. There's a common theme here: Issues are coming up and there isn't an obvious way to report them, track them, or otherwise make sure they're resolved, much less documented. We need to fix that. - Some people have remote access to the builders via a ssh key but it appears that not all build hosts are configured for this. What's the steps to resolution so that people can support the platform? * We specifically setup bcfg2 across all builders which helps to distribute our keys to them. If you would like access as you are describing then please contact one of us and we can generate an ssh key on hongkong so that you can login to the builders without a password. I believe this option was offered by one of my co-workers but was denied by a certain person so ya. :/ Don't really understand this. I'm sorry if it seems like I'm not following along here in close detail but our team has various other projects that we are working on simultaneously and sometimes we don't have time to monitor in close detail what exactly is happening in the farm. If you're able to point out specific examples of something failing and highlight all of our names in channel, I will at least definitely be able to see who it is and what is happening, hopefully. This doesn't scale well. The contact names change on a somewhat regular basis and #fedora-arm and #seneca are not support trackers- they're chat channels running 24/7, hours we do not any of us keep. What's needed is a consistent point of contact, whether it be a bot, a web tracker, a separate mailing list, or some other mechanism. Suggestions welcome! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Issue Tracker for Seneca Infra/RPFR
On 11/29/2012 12:14 PM, Jordan Cwang wrote: I've set up a trac instance at Seneca for people to file issues with our Koji, infrastructure, or any other problems that may arise. You can check it out at http://trac.proximity.on.ca/projects/fedoraarm Additonally, I've set up a RPFR Trac instance as well. That is at http://trac.proximity.on.ca/projects/rpfr. If you have any questions, comments or suggestions regarding these instances, let me know. Please put links to this on the Fedora ARM wiki. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 17 v6hl First Compose Image
On 12/10/2012 10:31 AM, Jon Chiappetta wrote: I realize that these numbers seem very minor but I did notice a much faster drawing performance when firstboot was started compared to the v5 version of Fedora. Also, it takes away any excuses or doubt that we're slower than raspian because we're not v6hl. In addition, if v7hl gets moved over to primary one day, then Seneca can still run a farm that has v5 and v6 releases of Fedora. Thanks for your time and testing, I appreciate it as always. It looks like only bzip2 ran for long enough to make a valid comparison. I'd be interested in reproducing any of the benchmarks used here: http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/ The above shows the difference between armv4 soft float vs armv6 hard float. Presumably armv5 soft float to armv6 hard float will end up somewhere in-between these two points. The big question is where will it end up? If armv6 hard float is substantially similar to armv5 soft float that tells us that the raspbian benchmarks primarily benefited from the move off of armv4. If on the other hand we get significant benefit from armv6 hard float, we know either the hard float or the v5-v6 move was very important. Appreciate all the hard work you've put into bringing armv6hl online. We're just on the cusp of knowing how important it is to continue its pursuit. Keep going! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 ARM Beta Test Candidate 2
On 12/13/2012 07:40 AM, Peter Robinson wrote: No Beagle? Or is blc doing them later today? It's unofficial, but try: http://scotland.proximity.on.ca/arm-nightlies/vault/tmp/beagle.img.bz2 I'm about to get on a plane but will resume beagle dev upon my return Monday. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fwd: Re: Soft-float chroot on hard-float distro and vice versa
On 12/17/2012 07:57 PM, Jon Masters wrote:
Bind mount /proc, /dev, /sys, and then it'll work just fine. You need
cpuinfo visible for e.g. rpm to determine you are on a hard float system.
Here's some handy shell script to do everything you'll need:
bindmount()
{
mount --bind /dev $1/dev
mount --bind /dev/pts $1/dev/pts
mount --bind /dev/shm $1/dev/shm
mount --bind /proc $1/proc
mount --bind /sys $1/sys
}
bindumount()
{
umount $1/dev/pts
umount $1/dev/shm
umount $1/dev
umount $1/proc
umount $1/sys
}
This will let you bindmount /someroot; chroot /someroot; bindumount
/someroot with ease.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Working on Fedora-arm port for Allwinner A10 based devices
On 12/20/2012 02:40 AM, Hans de Goede wrote: My work is based on: -f18arm-latest-armhfp-xfce.tar.xz This is probably the source of your /var/run vs /run problem. The f18arm-latest tarball is based on a series of yum upgrades from f17, meaning there was plenty of room for things to go wrong with the /usr move. I'd suggest working from the latest F18 Versatile Express image instead- pull the rootfs out of it as a foundation. For these latest builds I'll be dumping the old scripts and starting over properly with David Marlin's kickstarts and lorax work. It should produce more reliable builds and provide a better foundation. Meanwhile, go with the TC3 image we're doing a VFAD on today: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc3/F18-vexpress-xfce-20121218.tar.xz Very cool that you're doing this BTW! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM F18 Beta VFAD - Test Images posted
On 01/04/2013 07:01 AM, Lukas Zapletal wrote: Pardon my ignorance, but where can I find the kernel images? These are just root systems, right? I'd love to try Kirkwood on NSA-310. If you want to test the kernel used in the F18 ARM Beta release candidate the best option is to download the kirkwood image then extract the kernel and initramfs. Here's a link to the image: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-rc1/F18-kirkwood-20121220.img.xz Ucompress and as root use kpartx to expose the partitions as loopback devices: xz -d F18-kirkwood-20121220.img.xz kpartx -av F18-kirkwood-20121220.img From here you can mount the partition with the files you need. I'm not sure which one it is so you'll have to experiment: mount /dev/mapper/loop0p1 /somewhere Good luck, and don't forget to umount and kpartx -d that image when you're done. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
On 01/03/2013 10:14 AM, Jared K. Smith wrote: Are there janitor level tasks that folks can start on to get their feet wet and start contributing? Is there specific documentation that needs to be written? Tools that need to be tested? Scripts that need to be written? Thanks for starting this thread! There are basically 3 things that we really need help with (off the top of my head): 1. Democratizing ARM support. Right now we have a relatively small set of supported targets in the ocean of ARM devices. The raspberry pi is one example where non-core contributors are making this unsupported platform viable, if only in remix format. The chromebook is the next stellar example. And the allwinner-a10 devices. We need to make the Fedora ARM tent bigger, if it means remixes due to upstream issues. As kernels are unified and drivers are sent upstream the effort that goes into these remixes can then be made mainstream in Fedora. 2. New architecture bootstrap support. We'll be in a position where many hands make light work in aarch64 soon. Likewise, Seneca is proceeding with armv6hl, perhaps they could use a hand? 3. Anything that advances ARM's promotion to Primary Architecture status. As a reminder, the FESCo guidance for this is at: https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements Item #10 is is great need of attention: We really need to merge as much as possible with the main Fedora wiki pages. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
On 01/09/2013 10:34 AM, Tom Callaway wrote: On 01/08/2013 07:32 PM, Brendan Conoboy wrote: 2. New architecture bootstrap support. We'll be in a position where many hands make light work in aarch64 soon. Likewise, Seneca is proceeding with armv6hl, perhaps they could use a hand? Is there a current status on this? This was a very popular item in my recent Reddit What should Fedora do in 2013 post. Assume you mean the Pi/armv6hl question- expect this will be a topic discussed at FUDCon extensively. We have the future of armv[5678] to discuss! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM weekly status meeting 2013-01-16 (Results)
Hi everybody, Thank you for joining today's meeting. Here are links to its minutes and log: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-16/fedora-meeting-1.2013-01-16-21.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-16/fedora-meeting-1.2013-01-16-21.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-16/fedora-meeting-1.2013-01-16-21.00.log.html -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F18 ARM Final plan from this morning's hackfest discussion
F18 ARM Final - Will use 3.6 kernel (3.7 will appear as an update) - Blockers for F18-ARM Final - Summarized in BZ #901840 o Graphical updates not working on XFCE desktop - js is broken, this may be the only issue. - hack fest should fix this afternoon - other possible issues? o Eclipse not building - BZ #863801 - Assigned to kdaniel - latest update is that it's building again - Does an arm.koji.fp.o build simply need to be kicked off? - build resubmitted (prior build failed due to bad mock gid) o GHC not building - Was on Peter Robinson's todo list. No status. o V5 images: We will add armv5tel versatile express and panda for final. - Plan is to fix blockers, make RC1 - target ship date is Jan 29. - Seneca to make unofficial ARM tarballs of F18 GA for Remix purposes -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Fedora ARM Roadmap from this morning's hackfest discussion
During this morning's hackfest we discussed and agreed to a tentative road-map for armv5, v6, v7, and v8. Part of this is in the context of moving build infrastucture to the PHX colocation facility. Part of this is in the context of pushing ARM to Primary architecture status. The following is a summary of what we agreed to: Any release we do as part of Fedora ARM will be supported according to PA life cycle (IE, end of life between PA and SA ARM release will be the same day). Any release we do as a secondary architecture will continue to be supported by the secondary architecture koji instance, even if later releases are done as a primary architecture. For example, F18-ARM will always be secondary because it was built on the secondary koji hub. In a couple weeks' time we will have 96 Calxeda Highbank servers in PHX. There is already a new koji hub and database in PHX ready to take over. Once the ARM systems are running smoothly we will migrate armv5tel and armv7hl builds to these machines. Dennis Gilmore will take the lead in migrating koji to the new systems. Here is the plan on an architecture-by-architecture basis: armv5: F19 will be the last release we build on armv5tel. We will continue to support F19 armv5tel throughout the supported lifecycle of F19. This means packages in f19-testing, f19-updates, etc will continue until they're shut down in prmiary. armv6: Seneca will continue their development of armv6hl on the hardware at Seneca college. The systems currently working on armv5tel and armvhl will be redirected to this effort once those architectures are migrated to PHX- allowing them to make faster progress. armv7: The goal is to push armv7hl as a primary architecture in the Fedora 20 or 21 timeframe. Once accepted some of the builders in PHX will be moved to the primary network infrastructure, but a sufficient number will be left as secondary builders to continue support for F19 and earlier throughout their lifecycles. armv8: The aarch64 bootstrap effort continues to progress and is now at the early portion of stage 3: Rebuilding packages natively with rpmbuild. To follow will be a prolonged stage 4 in which most packages are built with mock. When we bootstrapped armv7hl stage 4 was a significant group effort and will hopefully be so again. It is likely we will reach stage stage 4 before v8 hardware is generally available, so every person's assistance will be especially welcome. The hope is to have v8 support in koji as a secondary architecture shortly after hardware becomes available. Our educated guess is that we will be somewhere between F20 and F21 development when v8 is ready to be guided by koji as an official secondary architecture. That's it! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Issues on Trimslice with F18 beta
On 01/21/2013 03:39 AM, Peter Robinson wrote: Has anyone else seen issues booting on the Trimslice? Basically it boots through but seems unable to fine the rootfs so just hangs. http://www.fpaste.org/itUt/ I've seen this when booting a trimslice with usb sata and updated firmware. Works fine with mmc, just not usb sata. The root= thing is a red herring. Am hoping 3.7 with an updated dtb will work. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
On 01/25/2013 08:22 AM, Dennis Gilmore wrote: Hi all, I wanted to kick off a discussion, I think that with the work that Seneca is doing for armv6hl to support the Raspberry Pi most of the need for building sfp has gone away. I would like us to drop support for sfp in F19 that means that anyone running a kirkwood based system would get supported software updates for approximately 13 months from now. with cubie boards and other devices coming around that are cheap and more powerful and similar options I think there is little benefit to continuing to support sfp. I've been thinking the same thing. This still gives people on kirkwood plugs over a year of active support, and Pi users will continue to have support via armv6hl. Another added benefit is that this will free up rawhide build systems which can be used by other Fedora communities who want to run projects on the ARM boxes (COPR, infra, etc). Ive put in a request to get numbers of people using the arm and armhfp portions of mirrormanager to get some idea of the number of users out there, though i suspect most arm are raspberry pi and people building in mock. That'll be some great information to have. It would be interesting to know Seneca's Pi download stats, too. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Distributing DTB's for Fedora 18 RC1
On 01/27/2013 08:51 AM, Peter Robinson wrote:
Basically when you do a make dtbs it makes the dtbs that match the
kernel config. So we end up with the following with the 3.7.x kernels
that we have in F-18 and they're in /boot/dtb-%{uname}. Note this
scheme can be tweaked but I figured getting something there to start
with was better than nothing.
Note: This will require changes to grubby's new-kernel-pkg similar to
what was necessary to run mkimage for uboot. The principle benefit of
having a separate package is that the dtbs land somewhere with a
consistent name, enabling grubby, boot.scr and uEnv.txt to remain static.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
On 01/31/2013 07:21 AM, Quentin Armitage wrote: I guess it's too late now, but I got a few days behind on my list emails. I use 2 * Sheevaplugs and 2 * Dreamplugs with Fedora, and would be very disappointed to see support for them being dropped from Fedora. For me, I still see quite a lifetime in them for what they are doing. Remember the plugs will be supported throughout the F18 lifecycle, so you still have over a year of support. Others are welcome to pick up the torch and run an armv5tel koji server/builds. We're all volunteers on this project, pursuing our individual interests. If v5 is yours, feel free to chip in. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Update on F18 RC?
On 02/02/2013 09:04 AM, Jonathan Masters wrote: Hi folks, Any update on RC images? Working their way to the mirrors as final. Announcement Tuesday as planned. Let's discuss release-notes Monday in #fedora-arm. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Yum offers kernel-3.7.3-101.fc17.armv7l.rpm for armv5tel F17 install, does not boot on qemu vexpress-a9
On 02/08/2013 10:19 AM, Alex Villacís Lasso wrote: A few days ago, I updated my qemu virtual machine, which runs F17 with -M vexpress-a9. The yum update installed kernel-3.7.3-101.fc17.armv7l.rpm . Today I got around to rebooting the machine with the provided vmlinuz and initramfs. However, the boot process stalls with no messages. Not even Uncompressing Linux I reverted to the previous kernel, kernel-3.5.6-1.fc17.armv5tel . What am I doing wrong? Should I use a different qemu emulation? The strange thing is that the vexpress-a9 emulation reports armv7l, so the instruction set is supposed to be OK. You need to use a device tree blob with the 3.7 kernels on versatile express. The latest f18 3.7 kernel includes the device tree you need under /boot. Not sure about f17. Don't worry about the armv7l bit, that's the right arch for armv5tel on versatile express. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] supporting boot configuration for 32 bit arm
Thanks for sending this- some comments below. On 02/27/2013 12:47 PM, Dennis Gilmore wrote: ** Resending with the right lists ** after talking at devconf with David Cantrell about the best way to support setting up uboot on arm devices in anaconda, the best approach going forward is pretty clear, ill get to it in a bit first i want to describe things as I see them. Unified kernel while solving many issues introduces some. platform detection was kinda simple with separate kernels. unified kernel means that while we dont need to worry about having the right kernel, we do need to worry about loading the right dtb. Yes, though during the transition we have to worry about both! This includes loading a device specific kernel at the start of a release, but loading a unified kernel during the support cycle of the same release. As an example, we have kernel-highbank-3.6.x in Fedora 18 GA, but it's a unified kernel in 3.8. platform detection is also needed to know where in ram we should load the kernel and offsets for initramfs and dtb to be loaded. anaconda can tell us the filesystem and device that we are installing to, but depending on the exact way support is done in uboot we may need to put in different values, SCSI vs SATA vs USB etc we also need to ensure we use the right dtb file. for instance a pandaboard ES can use a pandaboard dtb but will be 1ghz vs the 1.2ghz its capable of. some systems like the highbank ones have the dtb in their uboot. while others need to load an external file. It's important that anaconda have this information, but this data needs to be available outside of anaconda as well, suggesting a library so as i see it we need a library that anaconda can import and use to work out the right values for the system we are installing to. probably the library should write out the uboot template and run mkconfig on it. we could then reuse the library in a tool to say setup a boot sdcard to run the installer on a system. we have an issue where it is really not possible to make the equivilent of a boot.iso that will be bootable everywhere. Agree. As I mentioned in private emails, I favor in-uboot auto-detection with hush scripts in a combined /etc/uboot.d, but this might be too limited to support some eccentricities (Your panda vs panda-es example is tricky). If you do most of the dirty work inside uboot itself you have a better chance of making a unified Fedora image. Do you see this library as a new package or an extension to an existing package? Right now we have some uboot information embedded in grubby in a not-entirely-satisfactory way. I think a new package that grubby and anaconda require on arm on would be preferable. I think we should take this up to the cross distro list at linaro and ideally have the distros work on a database at the least of platforms and the values and types needed. if not the whole library that can be used in different places to set things up. The Ubuntu guys have (had?) flash-kernel (https://launchpad.net/flash-kernel), but it's not entirely satisfactory IMHO. Seems a bit dated though- perhaps they've moved on to some other db. this is only needed for 32 bit arm, 64 bit will have UEFI, ACPI and grub2. potentially we also want to consider if we can implement http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec since we need to implement something anyway. Agree. One other thought I've been kicking around is to get grub2 configuration management up and running (without actually installing the bootloader), then reparse the grub.cfg to create a viable boot.scr. This would make transitioning to UEFI easier. The goals for this endeavor that I can see: 1. Seamless handling of kernel updates on ARM for any Fedora release. The end user should be able to update (or remove) a released kernel and have their system continue to function assuming at least 1 kernel is installed. 2. Ship a single unified prebuilt image for the widest range of systems possible: In Fedora 19, provide a single prebuilt image that supports vexpress, highbank, trimslice and panda, with and without X (Subject to kernel support for X of course). Beagle* would require manual MLO replacement. If MVEBU (Armada XP) support lands in time that'd be nice too. 3. Ship a single unified prebuilt anaconda installer image: In Fedora 19, provide a single prebuilt anaconda installer image to support anaconda-style installations on Highbank, Trimslice, and MVEBU (if kernel support lands in time). -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Patching aarch64 support into Fedora
Hi everybody, Fedora 19 has many of the enablers for native aarch64 in core packages such as glibc and gcc. Many more packages would compile if config.guess and config.sub recognized aarch64 as a valid architecture, but only the latest version of autoconf knows about aarch64. At last week's fedora-arm meeting we talked about the viability of automatically patching such packages. The outcome of that discussion was that we should first identify how many packages need such a patch, then decide what to do based on that number. Red Hat's Al Stone has written a script which automatically generates patches for each package that needs it (And updates its spec file). After a complete run we can say that ~1850 packages need such a patch. The number may be larger, but it is definitely not smaller, as his only considers autoconf-using packages. If another auto configuration system is in use by a number of packages it too many need updating (cmake?). Now that we have this number, what do we want to do? I see a few options: 1. Do nothing, trip over this issue at least 1850 times during bootstrap. 2. Mail all package owners asking for action. 3. Proven packager commits the patches, package owners take them out once unnecessary. 4. Run autoconf during build, incurring wrath of any packager whose package isn't compatible with the latest autoconf. 5. Your much more sensible idea goes here. What say you? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] 3.8.x. kernel for F-18/17
On 03/05/2013 12:37 PM, Peter Robinson wrote:
* Trimslice - DTS tested working with uboot v2012.04-1.01 [3] (the one
with half the RAM)
Boots okay with a Fedora 18 rootfs, but there is an issue: Trying to run
mock build results in an out of memory error. This works fine with the
3.7 series.
Mock Version: 1.1.28
INFO: Mock Version: 1.1.28
INFO: calling preinit hooks
INFO: enabled root cache
Start: unpacking root cache
ERROR: Exception(/home/blc/fedpkg/grubby/grubby-8.22-3.fc19.src.rpm)
Config(fedora-rawhide-armhfp) 0 minutes 0 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-armhfp/result
Traceback (most recent call last):
File /usr/sbin/mock, line 539, in module
def do_buildsrpm(config_opts, chroot, options, args):
File /usr/sbin/mock, line 856, in main
do_rebuild(config_opts, chroot, args)
File peak.util.decorators.rewrap wrapping __main__.do_rebuild at
0x01A71930, line 3, in do_rebuild
File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py,
line 70, in trace
result = func(*args, **kw)
File /usr/sbin/mock, line 510, in do_rebuild
chroot.init()
File peak.util.decorators.rewrap wrapping mockbuild.backend.init at
0x01A68230, line 3, in init
File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py,
line 70, in trace
result = func(*args, **kw)
File /usr/lib/python2.7/site-packages/mockbuild/backend.py, line
279, in init
self._init()
File peak.util.decorators.rewrap wrapping mockbuild.backend._init
at 0x01A684B0, line 3, in _init
File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py,
line 70, in trace
result = func(*args, **kw)
File /usr/lib/python2.7/site-packages/mockbuild/backend.py, line
316, in _init
self._callHooks('preinit')
File peak.util.decorators.rewrap wrapping
mockbuild.backend._callHooks at 0x01A66AF0, line 3, in _callHooks
File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py,
line 70, in trace
result = func(*args, **kw)
File /usr/lib/python2.7/site-packages/mockbuild/backend.py, line
843, in _callHooks
hook()
File peak.util.decorators.rewrap wrapping
root_cache._rootCachePreInitHook at 0x01A68070, line 3, in
_rootCachePreInitHook
File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py,
line 70, in trace
result = func(*args, **kw)
File
/usr/lib/python2.7/site-packages/mockbuild/plugins/root_cache.py, line
108, in _rootCachePreInitHook
shell=False
File peak.util.decorators.rewrap wrapping mockbuild.util.do at
0x01A40770, line 3, in do
File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py,
line 70, in trace
result = func(*args, **kw)
File /usr/lib/python2.7/site-packages/mockbuild/util.py, line 323,
in do
preexec_fn = preexec,
File /usr/lib/python2.7/subprocess.py, line 679, in __init__
errread, errwrite)
File /usr/lib/python2.7/subprocess.py, line 1143, in _execute_child
self.pid = os.fork()
OSError: [Errno 12] Cannot allocate memory
Would the people testing the kernel on other devices also try a mock
build to see if this occurs on other devices?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] 3.8.x. kernel for F-18/17
On 03/05/2013 02:04 PM, Brendan Conoboy wrote: On 03/05/2013 12:37 PM, Peter Robinson wrote: * Trimslice - DTS tested working with uboot v2012.04-1.01 [3] (the one with half the RAM) Boots okay with a Fedora 18 rootfs, but there is an issue: Trying to run mock build results in an out of memory error. This works fine with the 3.7 series. Appears to be an issue with mock 1.2.28. Updating the 1.2.29 (in updates testing) resolves the issue. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Patching aarch64 support into Fedora
On 03/06/2013 06:37 AM, Dennis Gilmore wrote: I say we need the list of packages effected. then we can evaluate how critical it is that we take action. Here is the initial list: http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs I think it may actually be much larger. Al and I are going back and forth on fixing up patchify to identify more cases. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F19: uImage load addresses with unified kernel
Through Fedora 18 GA we've had a one-to-one mapping between the SoC and the kernel rpm. Likewise, we produced a different filesystem image for each SoC (EG, a highbank image, a panda image, a trimslice image, etc). Since then the unified kernel in 3.7 and beyond has introduced the ability to use a single kernel for multiple SoCs. This introduces the pleasant prospect of having a single filesystem image that boots on multiple ARM platforms. In fact, the standard unified kernel for F19 (3.9) may support highbank, omap, and versatile express all from the same vmlinuz. Doing this still requires loading the right dbt, but I have a plan for that. Doing this also requires creating a uImage with the right load address, IE: mkimage -A arm -O linux -T kernel -C none -a $ubootAddress The trouble is, there is no unified $ubootAddress available. The pandaboard uses 0x80008000, highbank and tegra use 0x8000, a10 and exynos5 use 0x40008000, and so forth. Not sure about beaglebone. If we want to realize the dream of having a unified F19 release we need a solution to this problem. I see three options: 1. Use the 0x8000 address for highbank/tegra, demand bootz support for everybody else. Since we control the panda/beagle/beaglebone uboots they would be covered. Not clear on what this means for exynos5, but exynos5 will use an LPAE kernel so that's a separate uimage already. 2. Generate multiple uImage files from a single kernel, then load the appropriate uImage on boot. 3. Split up images to cope. All 3 are viable, none are desirable. Is there a 4th option? If not, what do want to go with? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19: uImage load addresses with unified kernel
On 03/26/2013 04:49 PM, Graeme Russ wrote: 4. Relocatable kernel (like x86) If I understand correctly it already is relocatable. This is simply the address that uboot is instructed to load the kernel into memory at. 5. Have U-Boot process uImage to adjust for load location (U-Boot already does a similar thing for itself) Likewise, this is the address uboot is instructed to load the kernel at. My naive understanding is that uboot loads the header, analyzes it, then loads the rest of the file based on the content of that header. If the header instructs uboot to load the kernel into non-existent memory it not operate correctly. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19: uImage load addresses with unified kernel
On 03/26/2013 05:04 PM, Graeme Russ wrote: Hi Brendan, On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy b...@redhat.com wrote: On 03/26/2013 04:49 PM, Graeme Russ wrote: 4. Relocatable kernel (like x86) If I understand correctly it already is relocatable. This is simply the address that uboot is instructed to load the kernel into memory at. So why worry? Just have the load address in the U-Boot environment. Because uboot's bootm does not handling the relocation? Not 100% sure the mechanics of U-Boot loading an ARM kernel but I think it just loads it blindly where it is told to (i.e. does not analyse the header) That would make more sense (This was my understanding as well, actually), but we're still having an issue: The uImage header, stored in RAM, has a load address that is wrong for some platforms. Unless we're going to change that with an in-uboot memory editor, bootm will honor the address in that header and the boot will fail. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19: uImage load addresses with unified kernel
On 03/26/2013 05:26 PM, Graeme Russ wrote: I just realised I got this a bit wrong - mkimage make a U-Boot image with a header which contains the kernel load address. Not sure what mkimage does to the Linux kernel binary itself The kernel binary is left intact. Only a 64 byte header is prefixed. That would make more sense (This was my understanding as well, actually), but we're still having an issue: The uImage header, stored in RAM, has a load address that is wrong for some platforms. Unless we're going to change that with an in-uboot memory editor, bootm will honor the address in that header and the boot will fail. I think this is worth raising on the U-Boot ML Perhaps so. Meanwhile, your message did get me thinking. Here is a hypothetical mkimage command line: mkimage -A arm -O linux -T kernel -C none -a 11223344 -e 55667788 -n VERSION -d vmlinuz-3.9.0-0.rc3.git1.4.fc19.armv7hl uKernel Running hexdump on the kernel shows the uboot header: hexdump -C uKernel | head 27 05 19 56 97 0b b9 5e 51 52 3c 77 00 47 e8 f0 |'..V...^QRw.G..| 0010 11 22 33 44 55 66 77 88 f2 d9 f3 9c 05 02 02 00 |.3DUfw.| 0020 56 45 52 53 49 4f 4e 00 00 00 00 00 00 00 00 00 |VERSION.| 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 17-20: The value from -a 21-24: The value from -e (Typically we use the same -a and -e) 32-64: The value from -n We could create a number of uboot headers. Then after loading the default uImage, load a separate uboot header overwriting the first 64 bytes of RAM. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19: uImage load addresses with unified kernel
On 03/26/2013 08:38 PM, Nicolas Pitre wrote: If uImage is a problem, just don't use it, period. Problem solved. All the targets supported by the unified kernel are recent enough to have bootz support in their U-Boot source. Please use that. Is bootz supported everywhere we need? I was under the impression not, but let's take tally: Highbank has it. Trimslice (2012 firmware) has it VExpress doesn't have uboot OMAP/Beaglebone? Dennis? Arndale? Armada XP does *not* have it Anything else? If Armada XP is the only board that doesn't support bootz we can make a uImage for it then use bootz on everything else. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] supporting boot configuration for 32 bit arm
On 03/04/2013 04:40 PM, Brendan Conoboy wrote: Agree. As I mentioned in private emails, I favor in-uboot auto-detection with hush scripts in a combined /etc/uboot.d, but this might be too limited to support some eccentricities (Your panda vs panda-es example is tricky). If you do most of the dirty work inside uboot itself you have a better chance of making a unified Fedora image. Do you see this library as a new package or an extension to an existing package? Right now we have some uboot information embedded in grubby in a not-entirely-satisfactory way. I think a new package that grubby and anaconda require on arm on would be preferable. For those who are interested I've put together a proof of concept of the above at placed it on my people page: http://people.fedoraproject.org/~blc/fedora-arm/gruboot/ There is a readme in the tarball, but briefly: Running gruboot will regenerate your boot.scr with a significantly more sophisticated version using hush scripting. The new version autodetects the kind of system you are using and generates menus for all the kernels and dtbs you have installed. While it nominally provides support for trimslice, panda*, beagle*, highbank, and armadaxp I've only tested it on trimslice with both bootm and bootz. Feel free to try it out and send feedback. If this is a path we want to go down we will need to integrate with either the kernel or grubby package such that it is called after every kernel is installed or uninstalled. And a new name would be nice, too. Anybody who finds a bug or makes an enhancement is welcome to suggest a better name ;-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Trimslice with 1GB of RAM and DTB now working
Hi folks, The people at Compulab sent me a pointer for how to fix the problem with the trimslice not booting using the latest kernel. It's as simple as setting a couple new uboot environment variables. See: http://www.trimslice.com/wiki/index.php/Trim-Slice_Firmware_Updater#U-Boot_environment_variable This works for me! My trimslice is now running 3.8.5-201.fc18.armv7hl.tegra with 1GB of memory. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Trimslice with 1GB of RAM and DTB now working
On 04/15/2013 11:53 AM, Peter Robinson wrote: On Mon, Apr 15, 2013 at 4:04 PM, Brendan Conoboy b...@redhat.com wrote: Hi folks, The people at Compulab sent me a pointer for how to fix the problem with the trimslice not booting using the latest kernel. It's as simple as setting a couple new uboot environment variables. See: http://www.trimslice.com/wiki/index.php/Trim-Slice_Firmware_Updater#U-Boot_environment_variable This works for me! My trimslice is now running 3.8.5-201.fc18.armv7hl.tegra with 1GB of memory. Is it a persistent setting or one that needs to be set in the boot.cmd on each boot? If you run saveenv as they suggest it will be persistent. I'm adding the setting to gru-boot to ensure it's always there. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Trimslice with 1GB of RAM and DTB now working
On 04/15/2013 11:50 AM, David A. Marlin wrote: Since this work-around was noted for v2010.09-1.01, but v2010.09-1.03 is the latest (that I see on their website), has this been addressed in the newer versions (variables pre-defined in the firmware release)? If not, will it be addressed in the next release? If these settings are required, there should be no need for every user to add them manually. Yes, I would hope they will issue an updated uboot, but do not know their plans. We shouldn't count on them doing this, though. If somebody else will confirm this fixes it for them as well I will update the wiki with the advice (gru-boot will use it as well). -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Introducing the vArch tool to assist with aarch64
On 05/03/2013 02:26 AM, Peter Robinson wrote: I don't believe this is suitable for this list. It's not open source. I asked Dan to post to the list. There is no open source aarch64 simulator at this time. Until there is one, or hardware is readily available, this seems very useful. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Running autoreconf for aarch64 support, why ?
On 05/04/2013 12:19 PM, Hans de Goede wrote: Hmm, I can clearly remember rpmbuild doing the same thing in the past (way back in the past I must admit). But given that this is clearly a way better fix then modifying a gazillion packages, I'm glad we've it back! Yes, evidently this feature was around a long time ago but was turned off for some number of years. That does mean I've likely done the work on the 22 packages where I've already added autoreconf calls for nothing, ah well. I guess it is best to probably revert the changes there ? Not exactly- it would be preferable if all packagers ran autoreconf as a matter of course. This will ensure future changes to autoconf are picked up, even when building without redhat-rpm-config installed. Are there any cases where this is expected to not be fixed by the new redhat-rpm-config ? Anywhere that %configure isn't used will still need to be updated. It's a much smaller list! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Automatic AArch64 bootstrap daily update for May 8, 2013
Number of candidate source rpms: 13348 Number of source rpms built in stage 4: 8207 Number of packages built in stage4 with aarch64 components: 1857 Currently building packages atlas-3.8.4-8.fc19.src.rpm kismet-0.0.2013.03.R1-1.fc19.src.rpm mpir-2.6.0-5.fc19.src.rpm openscap-0.9.6-1.fc19.src.rpm p7zip-9.20.1-5.fc19.src.rpm python-4Suite-XML-1.0.2-16.fc19.src.rpm python-pycurl-7.19.0-15.1.fc19.src.rpm sblim-cmpi-base-1.6.2-2.fc19.src.rpm vegastrike-data-0.5.1-3.r1.fc19.src.rpm xorg-x11-font-utils-7.5-13.fc19.src.rpm Packages building since previous report (which might be stuck or crashed) atlas-3.8.4-8.fc19.src.rpm kismet-0.0.2013.03.R1-1.fc19.src.rpm sblim-cmpi-base-1.6.2-2.fc19.src.rpm vegastrike-data-0.5.1-3.r1.fc19.src.rpm Total current build failure count: 526 failed Build failures from unsatisfied dependencies: 334 failed-dep-rpms See http://arm-temp.ausil.us/pub/fedora-arm/data/failed-dep-rpms for complete list. Build failures after dependency resolution: 192 failed-build-rpms See http://arm-temp.ausil.us/pub/fedora-arm/data/failed-build-rpms for complete list. Naive Top 10 dependency issues 18 doxygen 5 java-devel 4 java-devel = 1:1.6.0 4 ghostscript-fonts-5.50-30.fc19.noarch (stage4) urw-fonts-2.4-14.fc19.noarch (stage4) xorg-x11-font-utils 3 libc.so.6(GLIBC_2.16)(64bit) perl(Net::SSLeay) = 1.21 perl-HTML-Parser-3.69-9.x1.aarch64 (stage3) perl-IO-Socket-SSL-1.82-1.fc19.noarch (stage3) perl-Net-LibIDN-0.12-13.x1.aarch64 (stage3) perl-XML-Parser-2.41-8.x1.aarch64 (stage3) 3 gtk2-devel 3 groff 3 gpm-1.20.6-29.fc19.aarch64 (stage4) linuxconsoletools 3 gobject-introspection-devel 3 doxygen graphviz Previously broken builds that are now fixed: alltray-0.71b-5.fc19 anchorman-0.0.1-4.fc19 athcool-0.3.12-8.fc19 bacula2-2.4.4-14.fc19 bluez-hcidump-2.5-2.fc19 Canna-3.7p3-38.fc19 cdrkit-1.1.11-17.fc19 cmpi-bindings-0.5.2-6.fc19 feh-2.7-2.fc19 fluxbox-1.3.5-1.fc19 foghorn-0.1.6-5.fc19 font-manager-0.5.7-7.fc19 gcolor2-0.4-6.fc19 gdigi-0.4.0-1.fc19 ghostscript-9.07-2.fc19 glglobe-0.2-16.fc19 glib-networking-2.36.1-1.fc19 gnonlin-0.10.17-4.fc19 kdelibs3-3.5.10-52.fc19 ladspa-caps-plugins-0.4.2-9.fc19 ladspa-fil-plugins-0.3.0-6.fc19 libdb4-4.8.30-6.x1.fc19 libEMF-1.0.7-2.fc19 libeXosip2-3.6.0-6.fc19 libgcal-0.9.6-8.fc19 libgnome-media-profiles-3.0.0-6.fc19 libieee1284-0.2.11-13.fc19 libofa-0.9.3-22.fc19 libQtGTL-0.9.2-4.fc19 librsync-0.9.7-20.fc19 libsemanage-2.1.10-2.fc19 libUnihan-0.5.3-9.fc19 libX11-1.5.0-3.x1.fc18 libXdmcp-1.1.1-4.fc19 libXext-1.3.1-4.fc19 libXfont-1.4.5-4.fc19 libXNVCtrl-169.12-8.fc19 loki-lib-0.1.7-7.fc19 mpdas-0.3.0-6.fc19 mupdf-1.1-3.fc19 opencc-0.4.0-1.fc19 openslide-3.3.3-1.fc19 ORBit-0.5.17-36.fc19 perl-Encode-2.49-1.fc19 perl-Socket-2.009-2.x1.fc19 perl-Tk-804.030-4.fc19 perl-XML-Parser-2.41-8.x1.fc19 poly2tri-0.0-4.20120407hgacf81f1f1764.fc19 python-gd-0.56-5.fc19 python-vorbis-1.5-0.12.a quvi-0.4.2-3.fc19 rubberband-1.8.1-2.fc19 sugar-settings-manager-0.87.2-7.fc19 udev-browse-0.3-2.fc19 w_scan-20120605-1.fc19 zziplib-0.13.62-2.x1.fc19 Newly attempted builds that failed: Canna-3.7p3-38.fc19 ORBit-0.5.17-36.fc19 athcool-0.3.12-8.fc19 bti-032-3.fc19 deltarpm-3.6-0.12.20110223git.fc19 glib-networking-2.36.1-1.fc19 kdelibs3-3.5.10-52.fc19 libEMF-1.0.7-2.fc19 libQtGTL-0.9.2-4.fc19 libUnihan-0.5.3-9.fc19 libX11-1.5.0-3.x1.fc18 libXNVCtrl-169.12-8.fc19 libXdmcp-1.1.1-4.fc19 libXext-1.3.1-4.fc19 libdb4-4.8.30-6.x1.fc19 libeXosip2-3.6.0-6.fc19 libgnome-media-profiles-3.0.0-6.fc19 lout-3.38-7.fc19 nasm-2.10.07-3.fc19 opencc-0.4.0-1.fc19 perl-Encode-2.49-1.fc19 perl-Tk-804.030-4.fc19 perl-XML-Parser-2.41-8.x1.fc19 prelink-0.4.9-1.fc19 w_scan-20120605-1.fc19 wimax-1.5.2-8.20110419git6718941c.fc19 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Automatic AArch64 bootstrap daily update for May 9, 2013
Number of candidate source rpms: 13348 Number of source rpms built in stage 4: 8246 Number of packages built in stage4 with aarch64 components: 1895 Currently building packages asio-1.4.8-5.fc19.src.rpm atlas-3.8.4-8.fc19.src.rpm bs-groff-base-1.0-1.fc19.src.rpm cmconvert-1.9.6-4.fc19.src.rpm icu-50.1.2-5.x2.fc19.src.rpm perl-5.16.3-262.x2.fc19.src.rpm srecord-1.61-2.fc19.src.rpm vegastrike-data-0.5.1-3.r1.fc19.src.rpm Packages building since previous report (which might be stuck or crashed) atlas-3.8.4-8.fc19.src.rpm vegastrike-data-0.5.1-3.r1.fc19.src.rpm Total current build failure count: 528 failed Build failures from unsatisfied dependencies: 335 failed-dep-rpms See http://arm-temp.ausil.us/pub/fedora-arm/data/failed-dep-rpms for complete list. Build failures after dependency resolution: 193 failed-build-rpms See http://arm-temp.ausil.us/pub/fedora-arm/data/failed-build-rpms for complete list. Naive Top 10 dependency issues 18 doxygen 5 java-devel 4 java-devel = 1:1.6.0 3 libc.so.6(GLIBC_2.16)(64bit) perl(Net::SSLeay) = 1.21 perl-HTML-Parser-3.69-9.x1.aarch64 (stage3) perl-IO-Socket-SSL-1.82-1.fc19.noarch (stage3) perl-Net-LibIDN-0.12-13.x1.aarch64 (stage3) perl-XML-Parser-2.41-8.x1.aarch64 (stage3) 3 gtk2-devel 3 groff 3 gpm-1.20.6-29.fc19.aarch64 (stage4) linuxconsoletools 3 gobject-introspection-devel 3 ghostscript-fonts-5.50-30.fc19.noarch (stage4) urw-fonts-2.4-14.fc19.noarch (stage4) xorg-x11-font-utils 3 doxygen graphviz Previously broken builds that are now fixed: boost-1.53.0-6.x1.fc19 groff-1.22.2-2.fc19 guile-2.0.9-1.fc19 perl-Compress-Raw-Bzip2-2.060-2.fc19 perl-Data-Dumper-2.139-1.x1.fc19 powerman-2.3.5-6.fc19 python-pycurl-7.19.0-12.fc19 -0.5-10.fc19.2 synergy-1.4.10-1.fc19 wimax-1.5.2-8.20110419git6718941c.fc19 ykclient-2.7-3.fc19 Newly attempted builds that failed: autoconf-2.69-8.fc18 autogen-5.12-2.fc17 bison-2.6.4-2.fc19 dlm-4.0.1-1.fc19 gcc-4.8.0-4.x1.fc19 libdbi-drivers-0.8.3-12.fc19 perl-HTML-Parser-3.69-9.x1.fc19 rsyslog-7.2.6-1.x1.fc19 sysprof-1.2.0-2.fc19 tboot-1.7.3-3.fc19 texlive-2012-22.20130427_r30134.fc19 x3270-3.3.12ga12-2.fc19 xsd-3.3.0-15.fc19 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19 Alpha RC5 compose
On 05/09/2013 02:28 PM, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, there is a Release Candidate compose for Alpha at http://armpkgs.fedoraproject.org/mash/stage/19-Alpha-RC5/ I've tested arm-boot-config with this image and it boots fine with it on trimslice. There is one bug to be resolved that will prevent it working perfectly with anything but tegra. Currently it will boot with the last kernel installed, even if it's a platform mismatch. The last kernel installed was tegra so it works in this case, but that's hardly reliable. I'll have an update shortly. Trimslice users might give it a try anyhow: http://people.fedoraproject.org/~blc/fedora-arm/arm-boot-config/ -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19 Alpha RC5 compose
On 05/09/2013 09:08 PM, David A. Marlin wrote: Is there any special U-Boot version requirement for Trim Slice, and if so, what version(s)? It requires one of the 2012 uboots which include dtb support. Works fine with the 1GB firmware as long as those extra environment variables are set. Coincidentally, Compulab tells me there will be a -3 release which resolves the need to set those variables, sometime in June. Also, will this image work for OMAP, and if so, are there any special instructions for Panda? The image I saw doesn't have a vfat partition 1, so without a great deal of manual intervention it would not work on OMAP. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19 Alpha RC5 compose
On 05/10/2013 09:22 AM, David A. Marlin wrote: Any chance of getting a 'preview release' for testing? Don't know what else is planned. Their uboot source tree is publicly available if anybody wants to go investigate though. http://www.trimslice.com/wiki/index.php/Trim-Slice_U-Boot_Development So what are the 'blocker' images on F19? For F18 it was vexpress, highbank, and panda. Is it now just vexpress and highbank? Does not appear to be documented on http://fedoraproject.org/wiki/Architectures/ARM/F19_Alpha_Release_Criteria so I'm not sure. I believe we minimally need something with graphics support. Perhaps we can take this RC5 compose and figure out what is working. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Automatic AArch64 bootstrap daily update for May 11, 2013
Number of candidate source rpms: 13348 Number of source rpms built in stage 4: 8503 Number of packages built in stage4 with aarch64 components: 2114 Currently building packages ClanLib-2.3.6-9.fc19.src.rpm atlas-3.8.4-8.fc19.src.rpm drgeo-1.1.0-24.fc19.src.rpm dump-0.4-0.19.b44.fc19.src.rpm e16-1.0.11-2.fc19.src.rpm fence-agents-4.0.0-3.fc19.src.rpm freenx-server-0.7.3-31.fc19.src.rpm gdb-7.6-28.fc19.src.rpm gpsd-3.8-1.fc19.src.rpm isns-utils-0.93-2.fc19.src.rpm jansson-2.4-2.fc19.src.rpm liblouis-2.5.2-3.fc19.src.rpm mariadb-5.5.30-1.fc19.src.rpm mate-polkit-1.6.0-1.fc19.src.rpm mingw-binutils-2.23.52.0.1-1.fc19.src.rpm nano-2.3.1-7.fc19.src.rpm nas-1.9.3-6.fc19.src.rpm nc6-1.0-16.fc19.src.rpm perl-B-Utils-0.21-4.fc19.src.rpm perl-PDF-Haru-1.00-9.fc19.src.rpm perl-Socket-GetAddrInfo-0.19-4.fc19.src.rpm perl-Sys-Syslog-0.32-1.fc19.src.rpm perl-Taint-Runtime-0.03-18.fc19.src.rpm perl-XML-LibXML-2.0014-2.fc19.src.rpm perl-mecab-0.996-1.fc19.src.rpm python-ethtool-0.8-1.fc19.src.rpm python-mwlib-0.14.3-1.fc19.src.rpm python-simplejson-3.1.3-1.fc19.src.rpm rubygem-krb5-auth-0.7-9.fc19.src.rpm sombok-2.2.1-3.fc19.src.rpm trac-xmlrpc-plugin-1.2.0-0.4.r10183.fc19.src.rpm trytond-account-invoice-line-standalone-2.6.0-2.fc19.src.rpm ucarp-1.5.2-8.fc19.src.rpm urlwatch-1.15-4.fc19.src.rpm usermode-1.111-2.fc19.src.rpm vim-command-t-1.4-4.fc19.src.rpm wiggle-0.8-5.fc19.src.rpm wmpager-1.2-1.20130401git88ece7e5.fc19.src.rpm wqy-bitmap-fonts-1.0.0-0.5.rc1.fc19.src.rpm xkeyboard-config-2.8-1.fc19.src.rpm xorg-x11-fonts-7.5-8.fc19.src.rpm Packages building since previous report (which might be stuck or crashed) atlas-3.8.4-8.fc19.src.rpm drgeo-1.1.0-24.fc19.src.rpm gdb-7.6-28.fc19.src.rpm mariadb-5.5.30-1.fc19.src.rpm usermode-1.111-2.fc19.src.rpm wiggle-0.8-5.fc19.src.rpm Total current build failure count: 606 failed Build failures from unsatisfied dependencies: 371 failed-dep-rpms See http://arm-temp.ausil.us/pub/fedora-arm/data/failed-dep-rpms for complete list. Build failures after dependency resolution: 235 failed-build-rpms See http://arm-temp.ausil.us/pub/fedora-arm/data/failed-build-rpms for complete list. Naive Top 10 dependency issues 18 doxygen 8 gpm-1.20.6-29.fc19.aarch64 (stage4) linuxconsoletools 6 asciidoc-8.6.8-1.fc19.noarch (stage4) graphviz vim-filesystem 5 java-devel 5 cim-server sblim-cmpi-base-1.6.2-2.fc19.aarch64 (stage4) 4 java-devel = 1:1.6.0 4 fakeroot rpmdevtools-8.3-3.fc19.noarch (stage4) 4 /usr/include/pcap.h 3 gtk2-devel 3 ghostscript-fonts-5.50-30.fc19.noarch (stage4) urw-fonts-2.4-14.fc19.noarch (stage4) xorg-x11-font-utils Previously broken builds that are now fixed: dlm-4.0.1-1.x1.fc19 libaccounts-glib-1.8-1.fc19 libgtop2-2.28.4-4.fc19 liblangtag-0.4.0-3.fc19 librcc-0.2.10-1.fc19 libwiimote-0.4-13.fc19 libyuv-0-0.19.20121221svn522.fc19 perl-version-0.99.02-1.fc19 Newly attempted builds that failed: archimedes-2.0.0-3.fc18 cddlib-094g-8.fc19 cln-1.3.2-6.fc19.1 compat-gcc-296-2.96-145 ctdb-2.1-2.fc19 curlpp-0.7.3-13.fc19 device-mapper-persistent-data-0.1.4-3.fc19 dracut-027-36.git20130418.fc19 flint-1.6-6.fc19 fontconfig-2.10.92-3.fc19 gappa-0.16.6-1.fc19 globus-core-8.9-3.fc19 jack-audio-connection-kit-1.9.9.5-2.x1.fc19 krb5-appl-1.0.3-4.fc19 ladvd-1.0.4-3.fc19 libindicator-0.4.94-4.fc19 ltrace-0.7.2-5.fc19 lua-event-0.4.3-2.fc19 mailman-2.1.15-12.fc19 mate-conf-1.4.0-22.fc19 pari-2.5.3-2.fc19 perl-Class-Load-XS-0.06-2.fc19 perl-Crypt-OpenSSL-Bignum-0.04-17.fc19 perl-Crypt-OpenSSL-X509-1.800.2-6.fc19 perl-Crypt-Rijndael-1.11-2.fc19 perl-Crypt-SMIME-0.10-4.fc19 perl-Digest-JHash-0.07-6.fc19 perl-FileHandle-Fmode-0.09-17.fc19 perl-HTML-Strip-1.06-11.fc19 perl-JSON-XS-2.33-2.fc19 perl-Mail-Box-Parser-C-3.007-1.fc19 perl-Math-FFT-1.28-12.fc19 perl-Math-Random-MT-Auto-6.22-2.fc19 perl-PAR-Packer-1.014-2.fc19 perl-Params-Util-1.07-5.fc19 perl-PerlIO-eol-0.14-16.fc19 perl-Perlbal-XS-HTTPHeaders-0.20-10.fc19 perl-YAML-LibYAML-0.41-1.fc19 perl-autovivification-0.11-1.fc19 pp3-1.3.3-7.fc18 python-cheetah-2.4.4-4.fc19 python-pysctp-0.3.1-14.fc19 rubygem-gherkin-2.11.6-2.fc19 sectool-0.9.5-10.fc19 ssldump-0.9-0.7.b3.fc19 system-config-audit-0.4.21-2.fc19 tig-1.0-3.fc19 tlomt-orbitron-fonts-1.000-7.fc19 trac-iniadmin-plugin-0.2-5.20120808svn11914.fc19 trac-mercurial-plugin-1.0.0.1-1.fc19 trac-xmlrpc-plugin-1.2.0-0.4.r10183.fc19 tryton-2.6.1-3.fc19 trytond-analytic-purchase-2.6.1-2.fc19 trytond-stock-location-sequence-2.6.0-2.fc19 typemade-josefinsansstd-light-fonts-1.000-7.fc19 v8-3.14.5.8-1.fc19 vegastrike-data-0.5.1-3.r1.fc19 vollkorn-fonts-2.1-2.fc19 weld-parent-17-7.fc19 werken-xpath-0.9.4-10.beta.12.4.fc19 wine-docs-1.4-2.fc18 wmclock-1.0.14-3.fc19 ws-commons-util-1.0.1-26.fc19 xorg-x11-twm-1.0.7-4.fc19 xorg-x11-xsm-1.0.2-21.fc19 xpp2-2.1.10-15.fc19 xpp3-1.1.3.8-8.fc19 zhcon-0.2.6-22.fc19 zsh-5.0.2-2.fc19 ___ arm mailing list arm@lists.fedoraproject.org
