July 2011 - arm - Fedora mailing-lists

Fedora ARM 12 on IGEPv2 (Beagle Board clone)
by Matthew Wilson 01 Jan '16

01 Jan '16

Hi all, I would like to introduce myself to the group. I have recently received an IGEPv2 board [1], which is based on the Beagle Board, but with wifi, bluetooth, ethernet, and more RAM. I'm still at the "wow, it's tiny and it runs Linux" stage. I should get a bit more time over the next month and Christmas to play around properly with it. I'm new to embedded development, but neither new to Linux nor ARM (writing my first ARM assembly some 15 years ago). However, for the past 6 years I've not even built a Linux kernel, preferring to use the default kernel in Fedora for simplicity :) Firstly, a thank you to those involved in Fedora ARM for getting it to this stage. If I get the time, I'd really like to contribute some (probably small) effort to help get Fedora ARM working well on the IGEPv2 and Beagle Board. As I progress, I'd like to know what I can do to help. In the meantime, I have some questions. Apologies in advance if these seem simple. 1) There are various different kernels from different sources. I'm used to there being a small set of "right" kernels (that is, Fedora's idea of "right") for x86. I fully appreciate that different ARM-based boards are quite different in capabilities (like different instruction set variants). a) Is there likely to be some standardised vanilla Fedora ARM kernel source? (Or is that simply the source RPM available for Fedora?) Then patches /could/ be offered for the more common systems (e.g. Beagle Board & clones, SheevaPlug). b) Would it then make sense to offer these as pre-built RPMs for common systems? c) Is there any guidance on which version is good to use as a base? I've seen quite different kernel versions being used (from 2.6.27 to 2.6.31). 2) I understand a little bit about the different calling conventions, FP differences (e.g. soft FPU versus VFP), and instruction set differences (v5 versus v7). a) Can the kernel can be safely built with a different instruction set targeted? (I know there are different optimisation options passed to GCC. Apologies if this seems a bit newbie-ish.) b) For FP-heavy programs (e.g. ogg encoding), is it possible to build the packages with VFP/NEON but still get them to work in a soft FPU system? I'd imagine any call to an external library would have to somehow be defined to use a different calling standard. 3) There seem to be some missing dependencies in the packages in the current Fedora ARM repository. For example, emacs is requiring libotf, which doesn't seem to be there in the repository. And likewise with the xorg-x11-font* packages needing ttmkdir. I'm confused as to how the RPM could have been successfully built without it. What am I missing? 4) I see there has been some discussion over unaligned data access. (Oh, I remember that from the ARM2 days.) It seems as if the Cortex-A8 cores allow unaligned data access when set up to do so [2]. Does this, in any way, help with the compatibility of packages targetting Cortex-A8? 5) I've managed to get various source packages missing from the Fedora ARM repositories to compile successfully (natively). I guess there is a reason why there are not in the repos right now -- is that reason down to time and priorities, or is there some blocking bugs with many of these packages? I look forward to being able to contribute something back into Fedora! Kind regards, Matthew [1] http://www.igep-platform.com/index.php?option=com_content&view=article&id=4… [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Beihgi…

11 15

Pogoplug Pro/OXNAS
by Callum Lerwick 24 Nov '11

24 Nov '11

Hi. I've been looking for a way to get a very power efficient, but still full featured Fedora server for a while, and the recent influx of "plug computers" finally provides the answer. Long story short, I ended up snagging a Pogoplug Pro on sale at Micro Center for $50, before I learned that the Pro is NOT derived from the Kirkwood reference design, but is a completely different architecture called OXNAS from Oxford Semiconductor/PLX. As far as my googling can tell, the recent "black" generation of Pogoplug hardware seems to be the only product in the world using the OXNAS 820 SoC right now. It looks like the WD MyBook uses/used an earlier OXNAS 810 chipset. http://www.plxtech.com/products/consumer/nas7820 http://www.linuxfordevices.com/c/a/News/PLX-Technology-NAS-7800/ It is also "cost reduced" from earlier Pogoplugs, having only 128mb RAM and 128mb of flash. Its a bit slower at 700mhz but is somewhat compensated for by being dual-core. On the up side, there is in fact a SATA port hidden inside the Pogoplug Pro. It also has some interesting features like TCP offload and supposedly an encryption engine. (but I haven't seen any sign of support for the encryption engine in the Cloud Engines source so far) There's also a mini-PCIe slot containing the Pro's wireless card. Anyway, I managed to get Fedora 13 beta3 running on it by first installing PlugApps on it, then I just swapped in a Fedora root FS: http://archlinuxarm.org/platforms/armv6/pogoplug-provideov3 Make sure to copy /lib/modules and /usr/local over from the PlugApps FS. The network driver is compiled as a module, and it will not auto load. Especially if you don't have a serial console set up, before booting you'll need to pop in a script at /etc/sysconfig/modules/oxnas-gmac.modules : #!/bin/sh exec /sbin/modprobe gmac >/dev/null 2>&1 Make sure it is chmod 755 Also the driver wants firmware for the TCP offload, and seems to have a bug where it will just lock up the system if it can't find it. You'll find it at /lib/modules/2.6.31.6_SMP_820/gmac_copro_firmware , just move it to /lib/firmware/ and you should have working ethernet. There's some weirdness with the MAC address, the driver just sets it to a hardwired default of "00:30:E0:00:00:00" as there does not seem to be in-kernel infrastructure to read uboot variables. The PlugApps install script writes the MAC into /usr/local/mac_addr and the network scripts change it before bringing the interface up. I don't understand why they don't just read it directly from NVRAM using /usr/local/cloudengines/bin/blparam . But currently my Pogoplug Pro is just using the default MAC. Setting the MAC properly should be a simple matter of scripting... Unfortunately the PlugApps kernel is very minimal. It does not have any NFS server support enabled, and for some reason ext4 is compiled as a module, so your root FS has to be ext2 or ext3. I managed to successfully compile the Cloud Engines kernel source and write it to flash just past the original PlugApps kernel, so the original PlugApps kernel and even the stock Pogoplug OS can still be booted in a pinch using the uboot console. (But I may have overwritten a backup Pogoplug kernel...) http://www.pogoplug.com/developers-open-source.html If you do not have a serial console set up, do NOT mess with the flash! If you screw up the boot sequence, there is no way to un-brick these things without one. There is NO "reset nvram to defaults" button. I'd really like to run btrfs on this, but the stock kernel is 2.6.31, and my research indicates you want at least 2.6.33 for stable btrfs. Also, support for the wireless card was merged in 2.6.34. I have successfully upgraded the kernel through the incredibly awkward and time consuming (but educational) method of applying the Cloud Engines changes to 2.6.31 in a git branch, then rebasing 2.6.32 on top of it. So my Pogoplug Pro has been running 2.6.32 for the last few months with no problem. I'll see about pushing forward further once I have some time to kill. (Pretty much takes a full day for my old secondary laptop to chew through the whole rebase...) So now I have my Pogoplug Pro working nicely as a Samba server for my windows machines, and a NFS4 server for my Fedora machines. I originally wanted to run a MythTV backend on it, but that may be pushing it a bit with only 128mb RAM. Not to mention the fun of getting MythTV compiled for Fedora arm in the first place...

2 1

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
by Jon Masters 26 Aug '11

26 Aug '11

Folks, We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 15th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Last week, we succeeded in reaching a point where we had yum running natively, and after that rapidly went from just under 100 native binary RPMs built to 793 right now! We still do not have all of the dependencies for mock, but we hope to be there soon. We need your help, if you have the time, hardware, and interest in doing so. Together, we can reach a point of running mock, then rebuild all of the packages we have so far natively within a mock, and ultimately have a Koji buildroot sufficient to officially rebuild everything within the standard Fedora ARM Koji infrastructure. You can find a lot more detail here about the stages involved in bringup (we are at stage 3), along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_… For general bootstrapping series information: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch on the Fedora ARM git repo so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. Jon.

2 3

Stable kernel 2.6.37.6 for Fedora on Toshiba AC100 and Question
by intersolar-direct 05 Aug '11

05 Aug '11

2 2

Re: [fedora-arm] Centos rootfs
by Donald Gullett 03 Aug '11

03 Aug '11

Compiling the packages is not a problem as i am compiling a load of f14 and f15 packages now. Chris Tyler <chris(a)tylers.info> wrote: >On Sun, 2011-07-31 at 01:32 -0400, Donald Gullett wrote: >> Can anyone point me in the direction of information on building a centos rootfs? > >You'd have to compile a substantial portion of the CentOS package >collection for ARM, then create a rootfs based on that. > >> How was the fedora rootfs setup derived? Was it a posted redhat >> document or procedure or an existing fedora installed system? > >It's a hackish script that runs against the ARM package repo. A >kickstart-based solution will get written in due course, I'm sure. > >-Chris > >_______________________________________________ >arm mailing list >arm(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/arm >

2 1

Re: [fedora-arm] Advice for tablets to run Fedora ARM on?
by Stuart Mumford 02 Aug '11

02 Aug '11

Hello, I have an Advent Vega, which costs 200 GBP and has a NVidia tegra and a full size USB A port and HDMI port. I would be willing to test / work on a Fedora bulid for such a device. Stuart

3 5

[F15] NFS boot [howto]
by Zoran Pericic 02 Aug '11

02 Aug '11

This is how I configured NFS root on my pandaboard. There is also complete boot partition in [1] 1) Install grubby, u-boot and dracut-network from my repo [2] 2) Install kernel-omap. This kernel have path that allow you to set mac address for smsc95xx with smsc95xx.macaddr kernel boot argument. 3) Change KERNEL_ARG in /etc/sysconfig/uboot for dracut network boot [3] KERNEL_ARGS="ro vram=32M root=dhcp fixrtc console=ttyO2,115200 mem=460M@0x80000000 mem=512M@0xA0000000 omapdss.def_disp=dvi smsc95xx.macaddr=5A:3E:83:2D:BA:41 selinux=0" 4) Add option "root-path=SERVER:PATH" to dhcp server host pandaboard1 { hardware ethernet 5a:3e:83:2d:ba:41; fixed-address 10.21.38.31; option root-path "10.21.38.4:/nfs/pandaboard1-fc15"; } 5) Run "flash-kernel --update-bootscript 2.6.38.8-36.06.fc15.armv7hl.omap" [1] http://zpericic.fedorapeople.org/boot/ [2] http://zpericic.fedorapeople.org/RPMS/ [3] http://fedoraproject.org/wiki/Dracut/Options#Network

3 5

About arm choice of toolchain options
by Paulo César Pereira de Andrade 02 Aug '11

02 Aug '11

Hi, Sorry for the cross post and long email :-) Currently I am working on a very initial state build of Mandriva for arm. Thanks to Jeff Johnson for giving me ssh access to armv7 hosts, and Matthew Dawkins for building several Mandriva/Unity linux armv5 packages. What I am trying to understand now is about choice of float abi. I understand that the IHI0042D_aapcs.pdf file I donwload says to use vfp registers for float/double arguments, but softfp seems too good to miss, as armv5 should be around for some time yet. So, I have two chroots, running: softfp# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: /home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure --prefix=/usr --build=i586-mandriva-linux-gnu --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --enable-languages=c,c++ --enable-threads=posix --disable-libssp --disable-libmudflap Thread model: posix gcc version 4.6.1 20110722 (Mandriva) (GCC) thumb# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: /home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure --prefix=/usr --build=i586-mandriva-linux-gnu --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-mode=thumb --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --enable-languages=c,c++ --enable-threads=posix --disable-libssp --disable-libmudflap Thread model: posix gcc version 4.6.1 20110722 (Mandriva) (GCC) This is unmodified upstream gcc, and using a set of bootstrap scripts from a git branch I made on a checkout of git clone git://fedorapeople.org/~djdelorie/bootstrap.git Since I am still very "arm noob" :-) and just yesterday did the thumb build to learn about thumb, so far, my impression is that the best approach should be to use thumb+softfp. Just so you know I am running thumb and arm builds, with thumb using hard float and the softfp with arm instructions set: softfp# objdump -d /usr/lib/libm.so | less [...] 00008d30 <__ieee754_atan2>: 8d30: e3a0c000 mov ip, #0 8d34: e347cff0 movt ip, #32752 ; 0x7ff0 8d38: e92d4030 push {r4, r5, lr} 8d3c: ed2d8b10 vpush {d8-d15} 8d40: e3a05000 mov r5, #0 8d44: ec432b18 vmov d8, r2, r3 8d48: e3475ff0 movt r5, #32752 ; 0x7ff0 8d4c: e003c00c and ip, r3, ip 8d50: e15c0005 cmp ip, r5 8d54: e24dd02c sub sp, sp, #44 ; 0x2c 8d58: e1a04003 mov r4, r3 8d5c: ec410b19 vmov d9, r0, r1 8d60: e1a05002 mov r5, r2 8d64: 0a000022 beq 8df4 <__ieee754_atan2+0xc4> [...] thumb# objdump -d /usr/lib/libm.so | less [...] 00007884 <__ieee754_atan2>: 7884: 2100 movs r1, #0 7886: 2000 movs r0, #0 7888: f6c7 71f0 movt r1, #32752 ; 0x7ff0 788c: ec53 2b11 vmov r2, r3, d1 7890: f6c7 70f0 movt r0, #32752 ; 0x7ff0 7894: 4019 ands r1, r3 7896: 4281 cmp r1, r0 7898: e92d 03f0 stmdb sp!, {r4, r5, r6, r7, r8, r9} 789c: ed2d 8b10 vpush {d8-d15} 78a0: 461c mov r4, r3 78a2: b08a sub sp, #40 ; 0x28 78a4: eeb0 8b41 vmov.f64 d8, d1 78a8: 4616 mov r6, r2 78aa: eeb0 9b40 vmov.f64 d9, d0 78ae: d03c beq.n 792a <__ieee754_atan2+0xa6> [...] I am kind of trying to figure what "The Industry" says about it, and just checked the linaro gcc-4.6 relevant changes for me right now, that are... + --with-arch=armv7-a --with-tune=cortex-a8 \ + --with-float=$(float_abi) --with-fpu=neon \ +# check if we're building for armel or armhf +ifeq ($(DEB_TARGET_ARCH),armhf) + float_abi := hard +else ifneq (,$(filter $(DEB_TARGET_ARCH), arm armel)) + float_abi := softfp +endif If I understand correctly, neon will have better support for simd instructions right? Either way, I used two simple benchmarks to try to sell myself the idea of breaking compatibility with armv5 or older binaries, but still not convinced, but, as I said, we should use whatever "The Industry" chooses :-) I used for benchmark http://www.tux.org/~mayer/linux/bmark.html and http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Why-ARMs-EABI… and also compared with my home computer (quad)core i5 x86_64, and attached results... Thanks and again sorry for cross posting and long email, Paulo

5 9

Configuring mock
by Jon Masters 01 Aug '11

01 Aug '11

Dennis, I suspect I just need a few hours doing something else (like sleeping), but I hit a small bump configuring mock. I can see that you use several repos - including on i386 for group deps (cool). However, my mock refuses to recognize the Scotland armv7hl repo. I will look at it in a few hours, should be easy to fix but just annoying. If you have something I don't, like a patch to mock, let me know. Jon. -- Sent from my phone - message formatted and/or shortened accordingly.

3 6

Centos rootfs
by Donald Gullett 31 Jul '11

31 Jul '11

Can anyone point me in the direction of information on building a centos rootfs? How was the fedora rootfs setup derived? Was it a posted redhat document or procedure or an existing fedora installed system?

2 1

Mandriva and Unity Linux work on armv7 port
by Paulo César Pereira de Andrade 30 Jul '11

30 Jul '11

Hi, In the past few days I made some changes to djdelorie's bootstrap scripts to adapt it to mandriva, so, I believe I should at least give some feeback :-) I have built two chroots on two panda boards, one with hardfp that should match current fedora, and another using --with-float=softfp, as at least for now I think it would be wiser for me, and available resources to be able to use a large amount of armv5 packages made by Matthew Dawkins, for Unity Linux. Currently I am connecting to remote panda boards at jbj.org, so, Jeff is providing the infrastructure (currently I do not have access to armv7 hardware). The boards are running: Linux panda3.jbj.org 2.6.38.8-32.01.fc13.armv7l.omap #1 SMP PREEMPT Tue Jun 14 22:12:54 EDT 2011 armv7l armv7l armv7l GNU/Linux [root@panda3 /]# cat /etc/fedora-release Fedora release 13 (Goddard) So, for example (and sorry for long email) in fedora, and my other bootstrap chroot, with objdump I see the pattern: 00008b68 <__ieee754_atan2>: 8b68: e3a01000 mov r1, #0 8b6c: e3471ff0 movt r1, #32752 ; 0x7ff0 8b70: ec532b11 vmov r2, r3, d1 8b74: e3a00000 mov r0, #0 8b78: e0031001 and r1, r3, r1 8b7c: e3470ff0 movt r0, #32752 ; 0x7ff0 8b80: e1510000 cmp r1, r0 8b84: e1a0c003 mov ip, r3 8b88: e92d0030 push {r4, r5} 8b8c: ed2d8b10 vpush {d8-d15} 8b90: e1a05002 mov r5, r2 8b94: e24dd028 sub sp, sp, #40 ; 0x28 8b98: eeb08b41 vmov.f64 d8, d1 8b9c: eeb09b40 vmov.f64 d9, d0 8ba0: 0a000023 beq 8c34 <__ieee754_atan2+0xcc> arguments in d0, d1 And in the alternate build I see the pattern: 00008d30 <__ieee754_atan2>: 8d30: e3a0c000 mov ip, #0 8d34: e347cff0 movt ip, #32752 ; 0x7ff0 8d38: e92d4030 push {r4, r5, lr} 8d3c: ed2d8b10 vpush {d8-d15} 8d40: e3a05000 mov r5, #0 8d44: ec432b18 vmov d8, r2, r3 8d48: e3475ff0 movt r5, #32752 ; 0x7ff0 8d4c: e003c00c and ip, r3, ip 8d50: e15c0005 cmp ip, r5 8d54: e24dd02c sub sp, sp, #44 ; 0x2c 8d58: e1a04003 mov r4, r3 8d5c: ec410b19 vmov d9, r0, r1 8d60: e1a05002 mov r5, r2 8d64: 0a000022 beq 8df4 <__ieee754_atan2+0xc4> arguments in r0,r1,r2,r3 I did not do any performance measures so far, so forgive me if the extra "vmov d#, r#,r#" or "vmov r#,r#, d#" is too costly, but I think it should be worth the compatibility with rpms for armv5 or earlier. It should have been already discussed at fedora, but I really do not know the real reason :-) Also, as I am still in very early stages, and doing experiments, so far I am using only the cross compiled gcc, i.e.: bash-4.2# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: /home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure --prefix=/usr --build=i586-mandriva-linux-gnu --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --enable-languages=c,c++ --enable-threads=posix --disable-libssp --disable-libmudflap Thread model: posix gcc version 4.6.1 20110722 (Mandriva) (GCC) But have already rebuilt some of the "bootstrap" mandriva packages, rpm5, etc, as well as have packages built for armv5 installed. This way, rebuilding for armv7 is an "optimization", and have something to start with... Thanks, Paulo

2 2

gcc status for F15
by Andrew Haley 30 Jul '11

30 Jul '11

gcj still doesn't work because, for some reason I don't yet understand, backtraces are broken. When backtrace is called from a thread, it wanders off the end of the stack and segfaults. This doesn't happen with F13. When I find out what's broken it, I'll let you know. To compile the example, use gcc thread.c -lpthread -fexceptions Andrew.

2 2

update on today's VFAD
by Jon Masters 29 Jul '11

29 Jul '11

Folks, We're at the point of beginning mock builds. I'm currently trying to get the rootfs updated to assist with this, but I need a bit longer. I'll send out an email later about that. Meanwhile, if you want to help out in the short term, we need help getting a working qt4 build. Jon.

1 0

New F14-arm build os31
by Martin Langhoff 28 Jul '11

28 Jul '11

[ This is for folks with XO-1.75 prototypes. Please feel free, or rather -encouraged- to request one! See http://wiki.laptop.org/go/Contributors_program#FAQ ~ cheers, martin ] The "Switch to Fedora-14" build. Download from: http://build.laptop.org/F14-arm/os31/ Use with OFW Q4B05 - http://wiki.laptop.org/go/OLPC_Firmware_q4b05 Changes and notes: - Fedora version bump! - Note that we are using dist-14 packages, no updates repo yet. - Sugar v 0.90 as per dist-14 - Only xorg-x11-xkb-utils from f14-updates due to a bug that seems to hit on s390x... and XO-1.75 ;-) https://bugzilla.redhat.com/show_bug.cgi?id=653436 Big thanks to Peter Robinson for pushing on the F-14 rebuild! Now I'm hoping the F14 updates stream gets underway asap so we can converge with dsd's 11.3.0 builds... m -- martin(a)laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff

1 0

Re: [fedora-arm] Confusion with arm koji
by Donald Gullett 28 Jul '11

28 Jul '11

2 1

Re: [fedora-arm] Confusion with arm koji
by Donald Gullett 27 Jul '11

27 Jul '11

1 0

Re: [fedora-arm] Confusion with arm koji
by Peter Robinson 26 Jul '11

26 Jul '11

Hi Martin, On Mon, Jul 25, 2011 at 9:02 PM, Martin Langhoff <martin.langhoff(a)gmail.com>wrote: > Peter, Fedorans, > > I'm playing with test builds using F14 for arm. And I get strange > errors of f14 python packages that depend on python 2.6. And yet, when > I look at koji, it clearly has newer RPMs... > > So for example, see python-decorator: > http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=7698 > > Right now, it lists > python-decorator-3.2.0-2.fc14 pbrobinson 2011-07-23 10:55:56 > python-decorator-3.2.0-3.fc14 pbrobinson 2011-05-25 19:47:30 > > The -3 package is newer, but was build earlier than the -2 package. > Looking at the changelog, the -3 rev is where the Python 2.7 rebuild > happened. > > Now if I grab the pkg list, it offers python-decorator-3.2.0-2.fc14 > http://arm.koji.fedoraproject.org/repos/dist-f14-build/latest/arm/pkglist > > I've had similar problems with other Python packages. Anybody can help > me understand why? Any fixes? Workarounds? > > Its a known problem. Mash (or what ever it is that generates the koji build repo) uses some very random criteria for tagging packages into the build repo. This is causing problems for noarch packages that are just imported by build-previous as opposed to rebuilt esp for python. The problem is that some of the packages, like the one you mention, were rebuilt/imported explicitly to get the build root for koji up to a F-14 level. It should hopefully just disappear once we have build-previous go to completion. The real fix it to add a check for the script to check if a later release is already in the tree. Peter

3 3

Bogus "hongkong" host entries in F14 ARM koji repo
by Martin Langhoff 26 Jul '11

26 Jul '11

Steps to repro 1 grab http://arm.koji.fedoraproject.org/repos/dist-f14-build/latest/arm/repodata/… 2 bzip2 -d primary.sqlite.bz2 3 sqlite 3 primary.sqlite 4 select location_base, location_href from packages where location_base not like 'http://arm.koji%' ; You'll be greeted by a longish list (432) of packages with a bogus url, all of them on "http://hongkong/yum/base/12/arm". Perhaps these could be purged? They aren't entries built in koji - and it breaks the OLPC image build :-/ thanks! m -- martin.langhoff(a)gmail.com martin(a)laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff

5 5

[F15] ehci + gcc 4.6.0
by Zoran Pericic 25 Jul '11

25 Jul '11

New gcc 4.6.0 behavior breaks USB support. Problem is in some packed structures in kernel ehci. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45819 Attached patch resolves this issue. Zoran Pericic

1 0

Fwd: Contributors program - test and develop on XO-1.75 B1 prototypes
by Peter Robinson 25 Jul '11

25 Jul '11

Hey All, This invitation is open to Fedora people who want to help Martin, I and the rest of the team out on Fedora ARM on OLPC XO 1.75 :-) In the short term we're working to get Fedora 14 working for the current release, looking down the road we're also working with the Fedora group that's doing the hardfp bringup so we can maximise the performance of the device :-) I've already poked a few people about them. Any queries about it feel free to ask me. Cheers, Peter ---------- Forwarded message ---------- From: Martin Langhoff <martin.langhoff(a)gmail.com> Date: Mon, Jul 25, 2011 at 5:33 PM Subject: Contributors program - test and develop on XO-1.75 B1 prototypes To: OLPC Devel <devel(a)lists.laptop.org>, fedora-olpc-list < fedora-olpc-list(a)redhat.com>, Sugar-dev <Sugar-devel(a)lists.sugarlabs.org> Hello developers! Are you programming on XO hardware today? Working on Sugar core or activities? Porting Fedora or other distros to ARM? As I write this, XO-1.75 B1 prototypes are being assembled 20 meters away from me. These are engineering samples -- some will go to drop tests and mechanical and electrical torture tests. Luckier units will go to the hands of passionate developers interested in helping us with XO-1.75. To request one, please follow the instructions at http://wiki.laptop.org/go/Contributors_program#FAQ Be aware -- we cannot guarantee every request will be satisfied -- unfortunately, we have a limited number of units and we may have to turn some requests down. These units will be early samples: expect hardware and software bugs, and be prepared to report them and help us in the diagnosis and fixing (it wouldn't be fun otherwise!). We will be asking recipients to be very proactive in reporting bugs and using the latest software for them. And to remember that these machines are /on loan/: offer to pass on your prototype if it is not being used. It will be a fun 2011 -- our goal is to have a new hardware platform and OS: XO-1.75 running XO OS-11.3.0, and there is a lot to do between now and the end of the year. hoping to hear from you - martin -- martin.langhoff(a)gmail.com martin(a)laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list Devel(a)lists.laptop.org http://lists.laptop.org/listinfo/devel

1 0

Re: [fedora-arm] Advice for tablets to run Fedora ARM on?
by Donald Gullett 23 Jul '11

23 Jul '11

1 0

No specific armv7hl VFAD today
by Jon Masters 22 Jul '11

22 Jul '11

Hello, I'm traveling this week, so didn't make any specific plans to host the VFAD earlier today. Sorry for not announcing that. Of course, there's no reason to not build and contribute bits by joining us on #fedora-arm at any time, and by following the instructions: http://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Good progress has been made recently. Dennis has succeeded in making a minimal rootfs using the packages built so far, and it even boots :) I don't think it will be too long before we can get a useful buildroot. Unless it proves redundant due to insanely cool rate of progress, there will be another VFAD next week. We may (hopefully) soon be able to transition over to just a standard package building exercise, once we've got the standard Koji infrastructure up and running. Jon.

1 0

Kernels
by Jon Masters 19 Jul '11

19 Jul '11

On Mon, 2011-07-18 at 14:38 +0000, Peter Robinson wrote: > ---begin log--- > jonmasters [14:38:01] <pbrobinson:#fedora-arm> might be worthwhile > seeing what kernel versions that dgilmore or jonmasters are running > on their pandas > ---end of log--- Hey folks, So I'm traveling to a friend's wedding and missed the context, but FYI I am running David Marlin's kernel mostly for good test coverage. I will be building up a new kernel of my own to debug a network driver problem I am tracking down that is also biting DJ (I can confirm with a Flyswatter that it is the network IRQ where we wind up hanging). Let me know if you need anything, but email might be easier this side of Thursday due to the traveling. Jon.

3 3

Re: [fedora-arm] Kernels
by Donald Gullett 19 Jul '11

19 Jul '11

1 0

Re: [fedora-arm] ARMv5tel Fedora 14 alpha 1 rootfs
by Donald Gullett 19 Jul '11

19 Jul '11

1 0

ARM: new cross-distro@ list
by Steve McIntyre 18 Jul '11

18 Jul '11

Hi folks, Many GNU/Linux distributions are doing some ARM porting; this tends to result in work duplication, and there doesn't seem to be a general purpose forum to bring ARM porters together. We're inviting developers of GNU/Linux distributions with an interest in ARM to join a new "cross-distro" list, hosted at Linaro: http://lists.linaro.org/mailman/listinfo/cross-distro Any ARM Linux / Free Software discussion is welcome on the list, for instance porting software to build on ARM, toolchain problems, dealing with new ABIs, Thumb-2, NEON, kernel problems, announcement of new tools etc. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs _______________________________________________ cross-distro mailing list cross-distro(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro

1 0

Re: [fedora-arm] ARMv5tel Fedora 14 alpha 1 rootfs
by Donald Gullett 17 Jul '11

17 Jul '11

1 0

emacs-nox rpms pushed to armv7hl-jkcox
by Ken Cox 15 Jul '11

15 Jul '11

I have just pushed the following to the armv7hl-jkcox branch: emacs-23.2-19.fc15.src.rpm emacs-common-23.2-19.fc15.armv7hl.rpm emacs-el-23.2-19.fc15.armv7hl.rpm emacs-filesystem-23.2-19.fc15.armv7hl.rpm emacs-nox-23.2-19.fc15.armv7hl.rpm emacs-terminal-23.2-19.fc15.armv7hl.rpm -- Ken Cox

2 1

Is a recent arm cross compiler available?
by William Cohen 14 Jul '11

14 Jul '11

Hi all, I have an Efika MX smartbook running the Fedora 13 images on http://ausil.us/smartbook/. I would like to build kernels using a cross compiler as described on http://fedoraproject.org/wiki/Architectures/ARM/CrossToolchain because the workstation is much faster than the 800MHz arm in the smartbook. However, the cross compiler suggested (http://mirrorlist.fedora-arm.wantstofly.org/?repo=cross&arch=x86_64) is relative old (April 2008) and does not understand the the "-mcpu=cortex-a8" option required to build the newer kernel. Is there a newer cross compiler packages somewhere? -Will

5 7

gcc RPMs
by DJ Delorie 14 Jul '11

14 Jul '11

ftp://ftp.delorie.com/pub/armv7hl/ I have not tested these yet, just built them. Total build time about 5 hours :-) 3,831,592 RPMS/armv7hl/cpp-4.6.0-6.fc15.armv7hl.rpm 10,209,544 RPMS/armv7hl/gcc-4.6.0-6.fc15.armv7hl.rpm 4,805,360 RPMS/armv7hl/gcc-c++-4.6.0-6.fc15.armv7hl.rpm 4,458,652 RPMS/armv7hl/gcc-gfortran-4.6.0-6.fc15.armv7hl.rpm 3,768,084 RPMS/armv7hl/gcc-java-4.6.0-6.fc15.armv7hl.rpm 3,955,964 RPMS/armv7hl/gcc-objc++-4.6.0-6.fc15.armv7hl.rpm 3,736,476 RPMS/armv7hl/gcc-objc-4.6.0-6.fc15.armv7hl.rpm 633,756 RPMS/armv7hl/gcc-plugin-devel-4.6.0-6.fc15.armv7hl.rpm 264,384 RPMS/armv7hl/libgcc-4.6.0-6.fc15.armv7hl.rpm 32,094,460 RPMS/armv7hl/libgcj-4.6.0-6.fc15.armv7hl.rpm 1,604,076 RPMS/armv7hl/libgcj-devel-4.6.0-6.fc15.armv7hl.rpm 12,646,548 RPMS/armv7hl/libgcj-src-4.6.0-6.fc15.armv7hl.rpm 567,920 RPMS/armv7hl/libgfortran-4.6.0-6.fc15.armv7hl.rpm 247,616 RPMS/armv7hl/libgfortran-static-4.6.0-6.fc15.armv7hl.rpm 137,280 RPMS/armv7hl/libgomp-4.6.0-6.fc15.armv7hl.rpm 148,748 RPMS/armv7hl/libmudflap-4.6.0-6.fc15.armv7hl.rpm 37,936 RPMS/armv7hl/libmudflap-devel-4.6.0-6.fc15.armv7hl.rpm 75,624 RPMS/armv7hl/libmudflap-static-4.6.0-6.fc15.armv7hl.rpm 138,972 RPMS/armv7hl/libobjc-4.6.0-6.fc15.armv7hl.rpm 1,326,920 RPMS/armv7hl/libstdc++-4.6.0-6.fc15.armv7hl.rpm 1,406,796 RPMS/armv7hl/libstdc++-devel-4.6.0-6.fc15.armv7hl.rpm 374,388 RPMS/armv7hl/libstdc++-static-4.6.0-6.fc15.armv7hl.rpm 101,147 SPECS/gcc.spec (official) 101,421 SPECS/gcc-java.spec (no AWT or GTK) 101,300 SPECS/gcc-java-nobuild.spec (no %prep, %build, or %check) 66,134,053 SRPMS/gcc-4.6.0-6.fc15.src.rpm Note sure if these are important (for this build), but... Checking for unpackaged file(s): /usr/lib/rpm/check-files /root/rpmbuild/BUILDROOT/gcc-4.6.0-6.fc15.arm warning: Installed (but unpackaged) file(s) found: /usr/bin/aot-compile /usr/bin/gc-analyze /usr/bin/gnatgcc /usr/bin/rebuild-gcj-db /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include-fixed/README /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include-fixed/X11/Xw32defs.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include-fixed/linux/a.out.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include-fixed/nss3/secport.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include-fixed/openssl/bn.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include/arm_neon.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include/ffi.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include/ffitarget.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include/mmintrin.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include/ssp/ssp.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include/ssp/stdio.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include/ssp/string.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/include/ssp/unistd.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/install-tools/fixinc_list /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/install-tools/gsyslimits.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/install-tools/include/README /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/install-tools/include/limits.h /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/install-tools/macro_list /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/install-tools/mkheaders.conf /usr/lib/libgcc_s.so /usr/lib/libgcj-tools.so (I bet these are the "should be script" /usr/lib/libgcj.so bugs previously noted) /usr/lib/libgfortran.so /usr/lib/libgij.so /usr/lib/libgomp.so /usr/lib/libmudflap.so /usr/lib/libmudflapth.so /usr/lib/libobjc.so /usr/lib/libstdc++.so /usr/libexec/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/install-tools/fixinc.sh /usr/libexec/gcc/armv7hl-redhat-linux-gnueabi/4.6.0/install-tools/mkinstalldirs /usr/share/gcc-4.6.0/python/libjava/aotcompile.py /usr/share/gcc-4.6.0/python/libjava/aotcompile.pyc /usr/share/gcc-4.6.0/python/libjava/aotcompile.pyo /usr/share/gcc-4.6.0/python/libjava/classfile.py /usr/share/gcc-4.6.0/python/libjava/classfile.pyc /usr/share/gcc-4.6.0/python/libjava/classfile.pyo /usr/share/info/dir /usr/share/locale/de/LC_MESSAGES/libstdc++.mo /usr/share/locale/fr/LC_MESSAGES/libstdc++.mo /usr/share/man/man1/aot-compile.1.gz /usr/share/man/man1/gappletviewer.1.gz /usr/share/man/man1/gc-analyze.1.gz /usr/share/man/man1/gjdoc.1.gz /usr/share/man/man1/rebuild-gcj-db.1.gz /usr/share/man/man3/ffi.3.gz /usr/share/man/man3/ffi_call.3.gz /usr/share/man/man3/ffi_prep_cif.3.gz /usr/share/man/man7/fsf-funding.7.gz /usr/share/man/man7/gfdl.7.gz /usr/share/man/man7/gpl.7.gz

1 0

Advice for tablets to run Fedora ARM on?
by Niels de Vos 12 Jul '11

12 Jul '11

Hi all, I'm looking for advise on some tablets that are likely able to run Fedora ARM. There seems to be some some interest in making a Fedora ARM for Tablets installation/rootfs. Any ideas on which devices are suitable would be much appreciated. It would be nice if the drivers are all provided upstream, if not, that should not be a huge issue either, as long as the drivers a are open source. Hardware modifications (even breaking and bricking) in order to attach debuggers seem to trigger interest as well ;-) I guess that OMAP tablets will be usable, but what models can be advised? Many thanks to anyone with advise or ideas! Cheers, Niels

5 5

armv7hl: Latest packages being pushed
by Jon Masters 12 Jul '11

12 Jul '11

Folks, The rootfs continues to grow and now has the latest packages built by myself, Dennis, and others. We're rapidly approaching the point wherein we can run mock. If you have some cycles and want to help, please assist us in building the dependencies for "userspace" so that we can have all of the bits in place that mock requires. We still need to build more packages before we have everything we need to build things in mock - including a complete build of audit, glibc, and so on that we skipped before or had built into the stage1/2 rootfs as a non-packaged item. At this point, you can use regular rpm and yum tools to help you figure out what deps are broken, missing, etc. It won't tell you everything, but it should be sufficient to search for dependencies to build :) Ping me with URLs to new packages. The rootfs contains copies of packages, and is configured with a yum repo containing them all. Jon.

1 0

ARMv5tel Fedora 14 alpha 1 rootfs
by Peter Robinson 11 Jul '11

11 Jul '11

Hi All, The tar file pretty much says it all http://fedora.roving-it.com/rootfs-f14-alpha1.tar.bz2 The same instructions that were used for the F-13 rootfs are relevant. I'm tested it on a beagleboard XM and it seems to work OK. Note you will need at least a 2.6.32 kernel. Enjoy! Peter

2 1

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
by Jon Masters 10 Jul '11

10 Jul '11

Folks, We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. Last week, we succeeded in reaching a point where we have a native RPM (and therefore rpmbuild) running, and we are therefore now entering what we call "stage3" (stage1 was cross-compilation, stage2 was limited native building from the sources) in which we can build packages natively. Dennis has made some progress building python and a priority will be to get native packages built sufficient to have a python RPM. Once we have python, we then get to yum, mock, and finally Koji. At that point, we just have to rebuild everything twice more (once in rpmbuild, then use those bits in a full koji) before we can build the many more packages we will require for a self-hosted system! Lots of fun! :) You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_… That page contains links to the general instructions on (note that documentation on "stage3" is being updated, by me, at the moment - the above link has some notes sufficient for Friday, but these will be incorporated into the generic instructions I link to below): https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. Jon.

2 2

yum available in armv7hl
by Jon Masters 10 Jul '11

10 Jul '11

Folks, I would like to let you know that there is now an install of yum in the armv7hl branch of the Fedora ARM git repo. You can pull this down (following the bootstrap instructions from the VFAD if you have not done this bit before) and chroot into it (bind mound /proc also first). We still need a few things before we can get to mock: - a build of the perl XML parser. I started, but it's late and I promised I wouldn't work on the weekend but did anyway. The build I did wound up installing in an incorrect prefix because our RPM doesn't know about the perl macros. I thought I had fixed but I'll get to it later. - a build of "usermode". Unfortunately, this package follows the growing trend of bloated dependency on lots of stuff for core packages (I hope to $DIETY that we don't have to bootstrap an architecture from scratch 10 years from now). I think we can do a hacked up build without any of the subpackages that just has the bare minimum for mock. Or rebuild mock in whatever way we need to remove usermode from it. I /hope/ after we have those two, we get a working mock next week. That's still far from being able to rebuild everything properly since we're missing dependencies left, right, and center, but we progress. Jon. --- begin obligatory quote --- bash-4.2# yum Failed to set locale, defaulting to C You need to give some command Usage: yum [options] COMMAND List of Commands: check Check for problems in the rpmdb check-update Check for available package updates clean Remove cached data deplist List a package's dependencies distribution-synchronization Synchronize installed packages to the latest available versions downgrade downgrade a package erase Remove a package or packages from your system groupinfo Display details about a package group groupinstall Install the packages in a group on your system grouplist List available package groups groupremove Remove the packages in a group from your system help Display a helpful usage message history Display, or use, the transaction history info Display details about a package or group of packages install Install a package or packages on your system list List a package or groups of packages load-transaction load a saved transaction from filename makecache Generate the metadata cache provides Find what package provides the given value reinstall reinstall a package repolist Display the configured software repositories resolvedep Determine which package provides the given dependency search Search package details for the given string shell Run an interactive yum shell update Update a package or packages on your system upgrade Update packages taking obsoletes into account version Display a version for the machine and/or available repos. Options: -h, --help show this help message and exit -t, --tolerant be tolerant of errors -C, --cacheonly run entirely from system cache, don't update cache -c [config file], --config=[config file] config file location -R [minutes], --randomwait=[minutes] maximum command wait time -d [debug level], --debuglevel=[debug level] debugging output level --showduplicates show duplicates, in repos, in list/search commands -e [error level], --errorlevel=[error level] error output level --rpmverbosity=[debug level name] debugging output level for rpm -q, --quiet quiet operation -v, --verbose verbose operation -y, --assumeyes answer yes for all questions --version show Yum version and exit --installroot=[path] set install root --enablerepo=[repo] enable one or more repositories (wildcards allowed) --disablerepo=[repo] disable one or more repositories (wildcards allowed) -x [package], --exclude=[package] exclude package(s) by name or glob --disableexcludes=[repo] disable exclude from main, for a repo or for everything --obsoletes enable obsoletes processing during updates --noplugins disable Yum plugins --nogpgcheck disable gpg signature checking --disableplugin=[plugin] disable plugins by name --enableplugin=[plugin] enable plugins by name --skip-broken skip packages with depsolving problems --color=COLOR control whether color is used --releasever=RELEASEVER set value of $releasever in yum config and repo files --setopt=SETOPTS set arbitrary config and repo options Plugin Options:

1 2

armv7hl Koji Builders
by Chris Tyler 09 Jul '11

09 Jul '11

I'm starting to prepare for the armv7hl koji builders... a few thoughts: - I don't think we can have builders that do both armv5tel and armv7hl, because the mock environment is populated with packages from outside the chroot (i.e., mock populates the directory and then does the chroot). Thus, any scriptlets will execute in the wrong environment. This should be a rare occurrence, but since hardfp and softfp happily link together and *do the wrong thing*, we need to avoid this scenario. - We haven't planned to do multiarch for arm, but it might be desired in some contexts, particularly if proprietary software is available only with a particular ABI (e.g., Flash in softfp only?). Multiarch might also permit builders to do both armv5tel and armv7hl. I think the cost (effort, storage space) probably outweighs the benefits but the discussion is worthwhile. - It would be really nice to get ld patched so that attempting to link hardfp and softfp would produce an error, instead of silently producing undefined results. - I'd like to build F15 on both armv5tel and armv7hl at the same time, i.e., submitting to a.k.fo.o with a target of dist-f15 will kick off a build on both variants by default (like 32-/64-bit builds on other archs). To this end, Paul Whalen is looking at putting together an armv5tel seed package set that matches the emerging armv7hl seed package set as closely as possible. -- Chris

3 2

Bootstrapping python
by Jon Masters 08 Jul '11

08 Jul '11

Hi Dennis, I hope your travels go well. Happy 4th, too :) I'm interested in collectively helping to solve the python bootstrap, since it might take some effort, and it doesn't need to all be your burden to solve. Therefore, can you let us know what you're doing so far, what your suggested tack is, and so on. We can figure out who should help build packages, or we can help with patches, etc. Perhaps we should have our next Fedora Activity Day earlier this coming week - perhaps Wednesday? We could spend the whole day fixing python. Jon.

2 6

F15 RPM rpm w/ lua support
by DJ Delorie 07 Jul '11

07 Jul '11

I've pushed updates to the NSS and NSPR stage2 recipies to install pkg-config files (armv7hl-djdelorie branch). I've build RPMs of RPM with lua support (see below). I also built nss-util RPMs as RPM depended on them. I included the spec file as I disabled a few things (python, selinux, libcap). I also built with "--without check" as the testsuite fails (likely due to the disabled things). For fun, I also rebuild the SRPM to make sure I could. ftp://ftp.delorie.com/pub/armv7hl/ RPMS/armv7hl: -rw-r--r-- 1 dj games 109912 Jul 6 23:13 nss-util-3.12.9-2.armv7hl.rpm -rw-r--r-- 1 dj games 59024 Jul 6 23:13 nss-util-devel-3.12.9-2.armv7hl.rpm -rw-r--r-- 1 dj games 996332 Jul 6 23:39 rpm-4.9.0-6.armv7hl.rpm -rw-r--r-- 1 dj games 131172 Jul 6 23:39 rpm-build-4.9.0-6.armv7hl.rpm -rw-r--r-- 1 dj games 186536 Jul 6 23:39 rpm-build-libs-4.9.0-6.armv7hl.rpm -rw-r--r-- 1 dj games 88692 Jul 6 23:39 rpm-devel-4.9.0-6.armv7hl.rpm -rw-r--r-- 1 dj games 620188 Jul 6 23:39 rpm-libs-4.9.0-6.armv7hl.rpm -rw-r--r-- 1 dj games 29868 Jul 6 23:39 rpm-sign-4.9.0-6.armv7hl.rpm RPMS/noarch: -rw-r--r-- 1 dj games 1011828 Jul 6 23:39 rpm-apidocs-4.9.0-6.noarch.rpm -rw-r--r-- 1 dj games 23896 Jul 6 23:39 rpm-cron-4.9.0-6.noarch.rpm SPECS: -rw-r--r-- 1 dj games 35423 Jul 6 23:52 rpm-np.spec SRPMS: -rw-r--r-- 1 dj games 275776 Jul 6 23:55 nss-util-3.12.9-2.fc15.src.rpm (unchanged F15) -rw-r--r-- 1 dj games 3449257 Jul 6 23:39 rpm-4.9.0-6.src.rpm (rebuild)

1 0

nspr ARM patches
by Jon Masters 06 Jul '11

06 Jul '11

Hi Elio, We are currently building up armv7hl packages to enable support for the "hard float" ABI change we are making on ARM systems and simultaneous update to ARM v7 (you may have seen the Fedora Activity Days). NSPR contains some broken assumptions that all ARM v7 systems also always build with Thumb2 instructions (think of this as similar to a second alternative instructions set supported by modern ARM CPUs). This is not true, and we are generally not building in this way. Upstream are going to fix this, but in the interim, can you take the following trivial spec-file change into the F15 nspr package? At some point, we'll want to remove this when they fix the upstream build scripts not to make those wrong assumptions, but it is harmless, and ok for the moment. Thanks, Jon.

1 0

Re: [fedora-arm] armv7hl packages and repo
by Jon Masters 05 Jul '11

05 Jul '11

Nope. However basically nobody uses it (very rare feature) but please do rebuild now we have lua. I will pull when back at 3. On phone now. -- Sent from my phone - message formatted and/or shortened accordingly. -----Original Message----- From: DJ Delorie [dj(a)redhat.com] Received: Tuesday, 05 Jul 2011, 11:34 To: Jon Masters [jcm(a)redhat.com] CC: arm(a)lists.fedoraproject.org Subject: Re: [fedora-arm] armv7hl packages and repo > There are currently 81 RPMs for armv7hl at the following location: Did we get lua support into rpm yet?

1 0

permissions on /dev/null
by Jon Masters 05 Jul '11

05 Jul '11

DJ, The permissions on /dev/null needed fixing, so I did. You'll need to change your initial seed filesystem to reflect that anyone can write into that file. Jon.

2 1

armv7hl packages and repo
by Jon Masters 05 Jul '11

05 Jul '11

Folks, There are currently 81 RPMs for armv7hl at the following location: http://scotland.proximity.on.ca/fedora-arm/armv7hl/ I'll sync up more as we go...on the way to a buildroot! Jon.

2 3

Fedora 13 ARM RC1 - Breathing new life into EOL
by Paul Whalen 04 Jul '11

04 Jul '11

We are pleased to offer a new and perhaps final release of Fedora 13 ARM. If your upgrading from beta3, run a yum update and you will pull in a new fedora-release package that will include the new key for RC1 as well as new repository files. You will need to do some small house keeping in order to use the new repo: mv /etc/yum.repos.d/fedora.repo.rpmnew /etc/yum.repos.d/fedora.repo You may also need to run: yum clean all The RC1 repository has been rsync’d to the mirrors to improve bandwidth and take some of the load off the ARM Koji hub. For those who would like to start fresh, the RC1 root filesystem is available at: http://scotland.proximity.on.ca/fedora-arm/rootfs/f13-rc1/rootfs-f13-rc1-20… Packages are currently building for the f13-updates repository and it should come online next week. It will also be rsync’d to the mirrors and will be updated as packages are built successfully. If you would like to read more about the new tool being used to build updates you can visit Jon Chiappetta’s blog (http://fossjon.wordpress.com/2011/06/28/finally-getting-to-really-test-styr…) for details. If you would like to provide feedback on the release, have questions on usage or comments, please feel free to drop by #fedora-arm on Freenode, or to the Fedora ARM Mailing list – arm(a)lists.fedoraproject.org. -Paul

5 4

Re: [fedora-arm] RPM available in the rootfs
by Dennis Gilmore 03 Jul '11

03 Jul '11

> On Sat, 2011-07-02 at 13:59 -0400, Jon Masters wrote: >> On Sat, 2011-07-02 at 05:15 -0400, Jon Masters wrote: >> > On Thu, 2011-06-30 at 18:47 -0400, Jon Masters wrote: >> > >> > > Thanks to the hard work of many people (including Stefan's >> contribution >> > > this morning to get some of the final nss bits and RPM in place, and >> of >> > > course the groundwork put in place by DJ Delorie), we are now very >> close >> > > to having rpm and rpmbuild. I fixed a problem with digest support >> > > earlier, we're just waiting on fixing the RPM macros/teaching RPM >> about >> > > armv7hl vs. armv7l, etc. in patches Dennis already has and will send >> me. >> > > >> > > I'm hoping to get the remaining bits in place so that tomorrow's >> VFAD >> > > can be spent building actual RPMs. We'll need to start by rebuilding >> > > what we have but in real RPM format, then work toward slowly getting >> a >> > > buildroot that we can use to rebuild everything again, and finally >> do >> > > one more build to have a full featured build environment. It would >> be >> > > awesome to get to a point tomorrow where we've got an armv7hl >> binutils >> > > binary RPM and its deps at least, with anything else being a bonus. >> > >> > Just as a head's up. I've changed the default build for all v7 systems >> > such that we'll target armv7hl, unless it's otherwise set at build. I >> > committed the change to redhat-rpm-config, and pushed up to F15. >> >> Since this came up on IRC, and I need to run, let me note: >> >> Note. I changed this for a *very specific reason*. Without this, and if >> you don't have /proc explicitly mounted, RPM will default to armv5tel. >> Since (at least for now), we have no business building armv5tel on armv7 >> systems, it's better to make sure nobody is building armv5tel. > > Really have to run...but just to add... > > I know it's good to bind mount /proc, it's probably a good idea anyway. > I'm also not against agreeing to drop this patch, but I'm not in favor > of dropping it just to support some theoretical ARM v7 system without > hardfp. There is really, in reality, no such thing as non-hardfp v7 (as > long as you do -d16, which we do). Therefore, I can see no harm in > assuming armv7 means hardfp for the moment. > > Finally, I know sparc parses /proc/cpuinfo, so I see where the idea > comes from, but as I mentioned in this case before, the correct thing to > do is to use something intrinsic from the filesystem, such as the ELF > sectional data on the RPM binary itself that says it was build hardfp. I > would rather fix the patch not to rely on /proc information, however it > is actually done. Anyway, we can debate, but I need to run! > > For now, at least, just cloning the repo on an armv7hl system will do > the right thing for all actual systems that (will ever) exist. As i said on irc making the change in the git tree for this would be ok, but the change is wrong for general consumption, parsing /proc/cpuinfo as my patch does is used to check for the existance of cpu flags to determine capability, i.e. can we run a neon optimised binary etc. though that should be in an ideal world detected at run time and not at build time. there is possibly many ways to skin the cat. what i see as wrong here is that if you end up with rpm saying your on softfloat and the internal copy of uname -m that rpm uses hasnt been rewritten to something indicating that you are running with hardfp i t will try to build a hardfp binary. we should be trying for softfp binaries the route we have gone with rpm has been to keep hard and softfp separate and not parallel installable, what this means is that in practice you can not install hardfp rpms on softfp systems and vice versa. with this change we then limit our building of softfp binaries to armv5tel and armv6l systems only, i am sure we will want to use some armv7 machines in the build pool for armv5tel binaries, users may also want to do the same thing. while you can install either stream of binary rpms into a chroot and it will work as you want it to and expect it to. it would require special work in rpm to detect these cases and allow the transaction to happen. maybe thats easier to do than i expect. im happy to be proven wrong. i dont disagree that having thins as you patched them in the git chroot is ok. but i do disagree with making that change upstream in fedora as its not going to help and will confuse those who do run softfp installs on v7 hardware for whatever reason. except in limited cases i do agree that v7 hardware should be running a hardfp install. Dennis

2 1

Re: [fedora-arm] armv7hl packages
by Dennis Gilmore 02 Jul '11

02 Jul '11

> On Sat, 2011-07-02 at 08:23 -0400, Jon Masters wrote: >> On Sat, 2011-07-02 at 08:01 -0400, Jon Masters wrote: >> >> > I've uploaded the first package I've built using the rootfs: >> > >> > http://scotland.proximity.on.ca/fedora-arm/armv7hl/ >> > >> > (follow the instructions in stage3/README to disable debuginfo for now >> - >> > there are many different ways to do this, I've just covered one there) >> >> DJ Delorie also built a few packages so far: >> >> ftp://ftp.delorie.com/pub/armv7hl/ >> >> We'll reconcile them, probably onto the scotland server as it's hosted >> along with everything else. If anyone cares to build more, go for it! > > Just to add, I wouldn't bother/prioritize building any of the noarch > packages. I've copied the ones DJ built over, but we can just install > the primary arch versions for "noarch" pacakges for the moment. I did > that for autoconf/make on my test box already, etc. > > Jon. > http://ausil.us/fedora-arm/ has the packages ive built today.

1 0

RPM available in the rootfs
by Jon Masters 02 Jul '11

02 Jul '11

Folks, Thanks to the hard work of many people (including Stefan's contribution this morning to get some of the final nss bits and RPM in place, and of course the groundwork put in place by DJ Delorie), we are now very close to having rpm and rpmbuild. I fixed a problem with digest support earlier, we're just waiting on fixing the RPM macros/teaching RPM about armv7hl vs. armv7l, etc. in patches Dennis already has and will send me. I'm hoping to get the remaining bits in place so that tomorrow's VFAD can be spent building actual RPMs. We'll need to start by rebuilding what we have but in real RPM format, then work toward slowly getting a buildroot that we can use to rebuild everything again, and finally do one more build to have a full featured build environment. It would be awesome to get to a point tomorrow where we've got an armv7hl binutils binary RPM and its deps at least, with anything else being a bonus. Jon.

2 5

armv7hl packages
by Jon Masters 02 Jul '11

02 Jul '11

Folks, I've uploaded the first package I've built using the rootfs: http://scotland.proximity.on.ca/fedora-arm/armv7hl/ (follow the instructions in stage3/README to disable debuginfo for now - there are many different ways to do this, I've just covered one there) More after I sleep, etc. Jon.

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm July 2011