Re: [fedora-arm] Daily F-15/17 ARM-Koji Build Stats
On Mon, 2012-01-23 at 13:05 +, jon.chiappe...@senecac.on.ca (sort of) wrote: > f15stats.html :: Sun Jan 22 13:05:01 UTC 2012 -- Mon Jan 23 13:05:02 UTC 2012 > > * "Different" contains packages that are built but have a varying ENVR to > that of PA-Koji > * "Working" lists any packages currently being built > * The numbers in the brackets show the difference recorded in the counts > since the script was last run > * http://arm.koji.fedoraproject.org/~jchiappetta/fxxstats.html > * https://fedoraproject.org/wiki/Architectures/ARM/F15_Koji_build > ___ The URL http://arm.koji.fedoraproject.org/~jchiappetta/fxxstats.html gives me a 404 Not Found error. Quentin Armitage ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] System won't boot after yum update
I have just installed the latest nightly snapshot that I can find (17
September) of Fedora 18 on one of my Dreamplugs. Once I had discovered
that the orion_nand driver had to be blacklisted, that seemed fine(ish).
It certainly was enough for the system to come up.
One thing I did notice was that the rootfs-resize service failed due
to /usr/sbin/rootfs-resize being missing (it appears that it is
in /usr/bin instead), so as a consequence the system was running without
a resized rootfs. That nightly snapshot has rootfs-resize version 0.4-1.
I then did a yum update followed by a reboot. Part way through
rebooting, the system shut itself down and rebooted. After this, the
system failed to start, reporting that it could not find the rootfs. I
went through this whole process (starting from the nightly snapshot) 3
more times, always with exactly the same result.
Finally, I did the yum update but excluded the rootfs-resize package
from the update. This time the system restarted successfully after the
yum update.
It appears that the problem is in rootfs-resize's use of fdisk, when
rootfs-resize resizes the partition.
Manually doing the same as the rootfs-resize script, I get the
following:
Running fdisk /dev/sdb:
> Command (m for help): p
>
> Disk /dev/sdb: 4102 MB, 4102029312 bytes, 8011776 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x
>
>Device Boot Start End Blocks Id System
> /dev/sdb1 * 63 1044224 522081c W95 FAT32 (LBA)
> /dev/sdb2 1044225 8011775 3483775+ 83 Linux
>
(this has already been resized, so ignore the end block for sdb2).
I now delete the second partition, and recreate it:
> Command (m for help): d
> Partition number (1-4): 2
> Partition 2 is deleted
>
> Command (m for help): n
> Partition type:
>p primary (1 primary, 0 extended, 3 free)
>e extended
> Select (default p): p
> Partition number (1-4, default 2): 2
> First sector (1044225-8011775, default 1044480):
> Using default value 1044480
> Last sector, +sectors or +size{K,M,G} (1044480-8011775, default 8011775):
> Using default value 8011775
> Partition 2 of type Linux and of size 3.3 GiB is set
The problem here is that although the first sector can be from 1044225
upwards, the default is 1044480, which is what the rootfs-resize script
selects. Since the new partition is created starting at a different
sector from the original partition, no filesystem can be found in that
partition.
Instead of letting the rootfs-resize script do the resize, I have done
it manually, entering 1044225 as the start sector, and that works fine.
Does the rootfs-resize script need to be modified to read the start
sector of the partition before it deletes it, and force the new
partition to have the same start sector? I have attached a patch to the
rootfs-resize script that does that.
Quentin Armitage
P.S. My plan is to update my two Dreamplugs and my 2 Sheevaplugs to F18
as soon as possible. I will also install Fedora on my Raspberry Pi(s).
I'm happy to do any testing that would help the project if someone can
point me in the most useful direction.
--- a/rootfs-resize 2012-07-30 13:25:40.0 -0400
+++ b/rootfs-resize 2012-10-21 05:49:32.420972805 -0400
@@ -108,7 +108,8 @@
echo "$0: Phase 1 - Changing the parition size."
echo "$0: Using $PDEV on $DEV for resize"
- echo -e "d\n$PNUM\nn\np\n$PNUM\n\n\np\nw\n"|fdisk $DEV >/dev/null 2>&1 || true
+ START_SECTOR=$(echo "p\nq\n" | fdisk $DEV | grep $PDEV | sed -e "s/[^ ]*[^0-9]*//" -e "s/ .*//")
+ echo -e "d\n$PNUM\nn\np\n$PNUM\n$START_SECTOR\n\np\nw\n"|fdisk $DEV >/dev/null 2>&1 || true
echo "$0: Repartition done, rebooting for next phase of resize."
touch /.rootfs-resize
rm -f /.rootfs-repartition
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Authorisation Manager fails to start
I'm running the latest F18 nightly snapshot that I can find (17 Sept) fully updated via yum, on a Dreamplug. When the system boots, it reports the following: > Oct 21 16:53:12 asenath dbus-daemon[287]: dbus[287]: [system] Activating via > systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service' > Oct 21 16:53:12 asenath dbus[287]: [system] Activating via systemd: service > name='org.freedesktop.PolicyKit1' unit='polkit.service' > Oct 21 16:53:12 asenath systemd[1]: Starting Authorization Manager... > Oct 21 16:53:12 asenath systemd[1]: polkit.service: main process exited, > code=killed, status=4 > Oct 21 16:53:12 asenath systemd[1]: Failed to start Authorization Manager. > Oct 21 16:53:12 asenath systemd[1]: Unit polkit.service entered failed state. > Oct 21 16:53:37 asenath dbus-daemon[287]: dbus[287]: [system] Failed to > activate service 'org.freedesktop.PolicyKit1': timed out > Oct 21 16:53:37 asenath dbus[287]: [system] Failed to activate service > 'org.freedesktop.PolicyKit1': timed out When I manually run /usr/lib/polkit-1/polkitd it immediately reports "Illegal instruction". Running polkitd under gdb, it reports: > Program received signal SIGILL, Illegal instruction. > 0xb699c450 in _GLOBAL__sub_I_jsarray.cpp () from /lib/libmozjs185.so.1.0 Looking at the build log of js on Koji for armv5tel, all the c++ and gcc command lines have the option -march=armv7-a after the option -march=armv5te, so presumably the js package for armv5tel is actually being built for armv7. The problem appears to be in the configure.in script where for any arm architecture, it sets MOZ_ARM_ARCH to armv7-a: > dnl Setup default CPU arch for arm target > AC_MSG_WARN([target cpu is ($target_cpu)]) > case "$target_cpu" in > arm*) > MOZ_ARM_ARCH=armv7 > ;; > esac Attached is a patch that sets MOZ_ARM_ARCH to armv5te if $target_cpu is armv5tel. I have build the modified js package and Authorisation Manager now successfully starts. Should I report this anywhere else, or is this email sufficient for this problem to be resolved. Quentin Armitage --- a/js/src/configure.in 2012-10-22 10:35:05.327947091 +0100 +++ b/js/src/configure.in 2012-10-22 10:12:11.359555981 +0100 @@ -4656,6 +4656,9 @@ dnl Setup default CPU arch for arm target case "$target_cpu" in + armv5tel) +MOZ_ARM_ARCH=armv5te + ;; arm*) MOZ_ARM_ARCH=armv7 ;; ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM VFAD - October 26th, 2012 - F18 ARM Alpha RC1
Hi, I realise this is short notice, but I'd be happy to test on my Dreamplug. It is already running F18, but I'd happy install an RC1 image if one is available. Quentin Armitage On Fri, 2012-10-26 at 00:06 -0400, Paul Whalen wrote: > Good day all, > > Please join us tomorrow (October 26th, 2012) at 11am EDT in #fedora-arm on > Freenode for another Fedora ARM VFAD! > You can greatly assist us by downloading and testing the Fedora 18 ARM Alpha > RC1. > > We have a number of images available for testing including - Pandaboard, > Trimslice and vexpress (QEMU). > Please find testing instructions here: > http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-10-26-VFAD-Fedora_18_Test_Day > > All help is appreciated and we look forward to your participation. If your > device is not listed and you would like > to offer your assistance, please let us know on the list or the IRC. > > Thanks, > Paul > > > > > ___ > arm mailing list > arm@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] building F18 Kirkwood images
David, I'd be very happy to help with building images. I have a Dreamplug currently running F18 from an old nightly snapshot, which has been fully updated via yum. I'd happily put F17 on that and have a go at creating some images, or would it be acceptable to create the images on an F18 system? I have a USB hard drive available, so that's not a problem. You make reference to 1Gb of memory, but my Dreamplugs and Sheevaplugs have 512Mb of memory. Will that be sufficient if there is enough swap space? I've never used kickstart files before but am happy to learn. Would the guys at Seneca College have anything useful to help with this, since I see that the nightly composes of images started again yesterday? With best wishes, Quentin On Wed, 2012-10-31 at 17:09 -0500, David Marlin wrote: > It was brought to my attention that the F18 Alpha lacked a Kirkwood > image, which we had for F17. We have been creating images for F18 using > livemedia-creator (anaconda and lorax), where the F17 images were > manually created using a custom script. > > The process we use is described on the wiki: > >http://fedoraproject.org/wiki/Architectures/ARM/Installer > > All the builders we have used for creating the F18 images are F17 > armv7hl (hard-fp) systems. I personally have no experience with the > Kirkwood devices, so I don't know what is needed to set up the image or > configure the bootloader. > > We would appreciate volunteers running F17 on Kirkwood devices to help > in creating an F18 image for those devices. The only development > involved would be customizing the kickstart file to 1) include any > special packages required for the device, and 2) set up any bootloader > specific files/scripts needed for the device. The remainder of the > effort would be to build and test the image. The hardware requirements > include an ARMv5 device running F17-GA or later with access to external > storage (requires space for the packages being installed and the > resulting image) and swap (requires >1GB total memory). > > We have created v7hl images using a Trim Slice (1GB memory plus 500MB > swap) with external (USB) hard drive, so something similar would > probably work. > > I am willing to provide assistance and answer questions about using the > tools and modifying the kickstart config file, but I have no ARMv5 > hardware on which to build or test these images. > > > Thank you, > > d.marlin > > ___ > arm mailing list > arm@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Problem with / being mounted read only
I'm running F18 beta-tc3 on a Dreamplug. Since memory is tight, I don't want /tmp mounted as tmpfs, but want to have it on a real disk. In order to stop /tmp being mounted as a tmpfs, I have executed "systemctl mask tmp.mount", and then I have an entry in /etc/fstab to mount a real disk partition on /tmp. The problem I have is that after executing "systemctl mask tmp.mount" and rebooting, the root filesystem is mounted read-only, which causes various other services to fail. If I execute "systemctl unmask tmp.mount" and reboot, the root filesystem is again mounted read-write. The above behaviour does not seem intuitive to me; is it correct behaviour? If this is what is expected, how do I stop a tmpfs filesystem being mounted on tmp before I mount another filesystem on /tmp? Quentin Armitage ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Git causing kernel lockup
0x250) [ 3559.456757] [] (hrtimer_interrupt+0x104/0x250) from [] (orion_timer_interrupt+0x24/0x34) [ 3559.466636] [] (orion_timer_interrupt+0x24/0x34) from [] (handle_irq_event_percpu+0x38/0x23c) [ 3559.476949] [] (handle_irq_event_percpu+0x38/0x23c) from [] (handle_irq_event+0x30/0x40) [ 3559.486821] [] (handle_irq_event+0x30/0x40) from [] (handle_level_irq+0xcc/0xdc) [ 3559.495994] [] (handle_level_irq+0xcc/0xdc) from [] (generic_handle_irq+0x28/0x38) [ 3559.505341] [] (generic_handle_irq+0x28/0x38) from [] (handle_IRQ+0x68/0x8c) [ 3559.514171] [] (handle_IRQ+0x68/0x8c) from [] (__irq_svc+0x34/0x78) [ 3559.522219] [] (__irq_svc+0x34/0x78) from [] (__dma_page_dev_to_cpu+0x60/0xcc) [ 3559.531225] [] (__dma_page_dev_to_cpu+0x60/0xcc) from [] (dma_async_memcpy_pg_to_pg+0x198/0x1dc) [ 3559.541802] [] (dma_async_memcpy_pg_to_pg+0x198/0x1dc) from [] (dma_memcpy_pg_to_iovec+0xf0/0x180) [ 3559.552556] [] (dma_memcpy_pg_to_iovec+0xf0/0x180) from [] (dma_skb_copy_datagram_iovec+0x100/0x1d4) [ 3559.563486] [] (dma_skb_copy_datagram_iovec+0x100/0x1d4) from [] (tcp_recvmsg+0x630/0xac0) [ 3559.573536] [] (tcp_recvmsg+0x630/0xac0) from [] (inet_recvmsg+0x48/0x5c) [ 3559.582107] [] (inet_recvmsg+0x48/0x5c) from [] (sock_aio_read+0x100/0x120) [ 3559.590852] [] (sock_aio_read+0x100/0x120) from [] (do_sync_read+0x98/0xd4) [ 3559.599597] [] (do_sync_read+0x98/0xd4) from [] (vfs_read+0xb4/0x184) [ 3559.607810] [] (vfs_read+0xb4/0x184) from [] (sys_read+0x3c/0x70) [ 3559.615675] [] (sys_read+0x3c/0x70) from [] (ret_fast_syscall+0x0/0x2c) And the above keeps repeating until I power off the plug. Is this of interest on this list, or should I report it elsewhere? Quentin Armitage ___ 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 Mon, 2013-01-28 at 22:26 -0600, Dennis Gilmore wrote: > El Fri, 25 Jan 2013 10:22:23 -0600 > Dennis Gilmore escribió: > > 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. > > > > 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. > > since there has been no major objection i will disable building > armv5tel rpms in rawhide before the mass rebuild. > > Dennis 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. Quentin Armitage ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Kernel-kirkwood 3.7.6-201 failing to boot
I have installed kernel-kirkwood-3.7.6-201.armv5tel on three Dreamplugs, and none of them will boot, although they successfully boot 3.7.5-201. The last messages on the console during the boot process are: > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. Is there any way of finding out any more information about what is going on or why it is just hanging? When the Dreamplugs booted the 3.7.5-201 kernel I was a bit surprised since http://www.serverphorums.com/read.php?12,475386 and other web pages suggest that Sheeva/Guru/Dreamplugs won't boot with the factory uboot when kernel configuration parameter CONFIG_ARM_PATCH_PHYS_VIRT=y (I am using the factory u-boot). Could it be that the above is the problem I am experiencing with 3.7.6-201 but for some reason it does not occur with 3.7.5-201? If the answer is to update u-boot, is there a recommended image available to install? Any help with identifying the problem (and better still resolving it!) would be much appreciated. Quentin Armitage ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Kernel-kirkwood 3.7.6-201 failing to boot
My boot partition is VFAT. For some reason the factory u-boot on the Dreamplug does not support EXT; I've always assumed that this was because the Sheevaplug u-boot had problems with EXT (it couldn't load a file if any part of it was more the 2Gb from the start of the partition). Quentin On Wed, 2013-02-13 at 13:47 -0500, Paul Whalen wrote: > > - Original Message - > > > > I have installed kernel-kirkwood-3.7.6-201.armv5tel on three > > Dreamplugs, and none of them will boot, although they successfully > > boot 3.7.5-201. > > > > The last messages on the console during the boot process are: > > > > > > Starting kernel ... > > > > Uncompressing Linux... done, booting the kernel. > > Is your boot partition EXT or VFAT? > Using a GuruPlug Server Plus I have seen that when using some kernels > as well. Oddly some will boot from VFAT '/boot' only, while others will > boot from EXT. They are loaded fine in each case, and only seem to fail > when booting (or no other output is given). > I now use a VFAT partition for '/boot' and have not had an issue since. > > Paul > > > > ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Problems booting Dreamplug on 3.10.10 kernel
I have tried booting a Dreamplug with the 3.10.10 kernel, but it fails to boot successfully, and I would appreciate some guidance as to how to work around the problem. The symptoms are that it drops into dracut, reporting that it cannot find the root filesystem on /dev/sdb3 (another Dreamplug with slightly different config does exactly the same but with /dev/sda2). I think the problem is that the ehci-orion driver is not being loaded. On the Fedora kernel, I get the following messages at boot: [ 18.767308] libphy: Fixed MDIO Bus: probed [ 18.771637] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 18.778214] ehci-pci: EHCI PCI platform driver [ 18.782734] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 18.788992] uhci_hcd: USB Universal Host Controller Interface driver [ 18.795633] usbcore: registered new interface driver usbserial [ 18.801524] usbcore: registered new interface driver usbserial_generic [ 18.808129] usbserial: USB Serial support registered for generic [ 18.814399] mousedev: PS/2 mouse device common for all mice Booting with a kernel from http://www.xilka.com/sheeva/, I get [6.911191] libphy: orion_mdio_bus: probed [6.911386] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4 [6.912865] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address f0:ad:4e:00:84:db [6.914207] mv643xx_eth_port mv643xx_eth_port.1 eth1: port 0 with MAC address f0:ad:4e:00:84:dc [6.914353] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [6.914359] ehci-pci: EHCI PCI platform driver [6.914506] ehci-orion: EHCI orion driver [6.914597] orion-ehci f105.ehci: EHCI Host Controller [6.914621] orion-ehci f105.ehci: new USB bus registered, assigned bus number 1 [6.914754] orion-ehci f105.ehci: irq 19, io mem 0xf105 [6.934742] orion-ehci f105.ehci: USB 2.0 started, EHCI 1.00 [6.935444] hub 1-0:1.0: USB hub found [6.935463] hub 1-0:1.0: 1 port detected [6.936156] usbcore: registered new interface driver usb-storage [6.936293] usbcore: registered new interface driver ums-cypress [6.936436] usbcore: registered new interface driver ums-datafab [6.936572] usbcore: registered new interface driver ums-freecom [6.936708] usbcore: registered new interface driver ums-jumpshot [6.936844] usbcore: registered new interface driver ums-sddr09 [6.936982] usbcore: registered new interface driver ums-sddr55 [6.937450] mousedev: PS/2 mouse device common for all mice and it then successfully goes on to find the SD cards and USB attached disc. (This kernel has other problems such as no console output, and leaving the root filesystem mounted read-only, so using this isn't a solution). One difference relating to this is that the xilka kernel is built with CONFIG_USB_EHCI_HCD_ORION=y whereas the Fedora kernel is built with: CONFIG_USB_EHCI_HCD_ORION=m But I think the problem probably really lies in that there is no usr/lib/modules/3.10.10-100.fc18.armv5tel.kirkwood/kernel/drivers/usb/host/ehci_orion.ko in my uinitrd-3.10.10-100.fc18.armv5tel.kirkwood, which I assume is related to ehci_orion having been moved to device tree support. Is my diagnosis likely to be correct, and if so, is there a simple way that I can fix it by rebuilding a uinitrd file (if so, what commands do I need to do it)? Are there likely to be any other drivers that ehci_orion.ko depends on that would also need to be included? Finally, should a new kernel package be produced that does include the ehci_orion driver? And if so, would it be helpful if I filed a bug. Just to confirm, the kernel is picking up the Dreamplug device tree, since I get the following message at the start of the boot sequence: [0.00] Machine: Marvell Kirkwood (Flattened Device Tree), model: Globalscale Technologies Dreamplug Many thanks, Quentin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Problems booting Dreamplug on 3.10.10 kernel
On Tue, 2013-09-17 at 09:46 -0500, Dennis Gilmore wrote: > On Tue, 17 Sep 2013 10:18:42 -0400 > Jochen De Smet wrote: > > > > > Just add --add-drivers "ehci-orion" to the dracut commandline; I > > actually see the same when > > building the initrd for my mirabox; no idea why it doesn't know to > > include it by default. > > > > J. > > dracut will need patching to support it. what were the last working > kernels? > > > Dennis Just to confirm, adding --add-drivers ehci-orion to the dracut command allows the 3.10.10 kernel to boot successfully. The previous kernel I was using was 3.7.5-201, which worked without any problem. I have now tested the last 3.9 kernel, kernel-kirkwood-3.9.11-200.fc18.armv5tel, which boots successfully. The first 3.10 kernel, kernel-kirkwood-3.10.4-100.fc18.armv5tel fails to boot, in the way described earlier. This does seem to coincide with the addition of CONFIG_USB_EHCI_HCD_ORION=m into the kernel config. Quentin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Kernel lockup on Dreamplug caused by using git
A long time ago (last December) I reported a problem with Dreamplug at least 3.6.10 through to 3.7.5 suffering from the kernel reporting a soft lockup when I doing a git pull when it was anything but a small update over the network - see https://bugzilla.redhat.com/show_bug.cgi?id=910593 . The advice then was to upgrade to a 3.8 kernel, but due to the challenges of trying to get my head around device tree it got pushed to the back of the drawer. Now, I am trying to get Postfix working, and I am finding that it appears to be causing the kernel to hang up too, so I need to get the upgrade done. Although git, and probably Postfix, cause the lockup, I have not experienced any other activity that does; ssh, ftp, yum update for example all appear to work without a problem. Over the last couple of days I have been working on upgrading to the latest Fedora kernel available, so I have been using 3.10.10. Although the kernel is no longer reporting a soft lockup, when I try doing a git pull, just about the moment git reports that it is starting to transfer data the kernel completely stops responding; there is no output on the console, no output on the terminal where I am running git, and it won't respond to any keyboard input or pings. After a minute, the watchdog kicks in and reboots the dreamplug, and I have not managed to find any entries in any logs that relate to the hangup. I had previously assumed that this was a generic problem, but I have tried a different kernel build, from http://www.xilka.com/sheeva/kernel/3/ . I have tried both 3.10.9 and 3.11.1, i.e. kernels both before and after the Fedora kernel 3.10.10 kernel I was trying. Both of the xilka kernels work fine with git. So it seems to me that the problem must be in the Fedora config/patches/build somewhere. What should I do from here? Simply filing it as a bug at this stage probably isn't helpful, due to the lack of information. What can I do to help track down the cause of the problem, and hence get a resolution? PQA ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Cheap ARM devices
On Thu, 2010-03-04 at 12:04 -0600, Adam Miller wrote: > RAM is a really good point, I think it will be in the ballpark of 256 > (plus or minus a bit). Also, I'd like to open up the conversation > about version of ARM we as a SIG want to support as the efforts start > to ramp up while targeting popular devices. I think ARMv9 might be a > little too aggressive but are there any devices that are still > prominent that are ARMv5? Would it be possible (or even feasible) to > maintain ARMv5, ARMv7, and ARMv9 in parallel and treat them as > separate architectures? > The Sheevaplug is ARMv5 I believe, and is quite popular. I'm currently running F-12 on my two plugs. Quentin Armitage ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Building perl-Crypt-OpenSSL-RSA
Hi, I've done a scratch build of perl-Crypt-OpenSSL-RSA which has been successful, although there is no installable package available (it is listed in http://arm.koji.fedoraproject.org/possible_dep_failures.html , but this seems to be for the F-11 build): see http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=101130 . Can a proper build be done of this package, and it made available? I will be working my way through a number of packages to try and get them to build and have a few questions: Can I only do scratch builds, or can I submit full builds? How do built packages get submitted for inclusion in the repo? If I find patches are needed, as are stored in http://ftp.linux.org.uk/pub/linux/arm/fedora/diffs-f12/ , how should I submit them? If a package needs an ARM specific patch, does the koji build have to be submitted with an SRPM? PQA ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] mod_dnssd
I have built mod_dnssd (see http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=28633 ). Could it please be tagged for release. Many thanks, Quentin Armitage ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F13 Beta 3 - wrong yum repos?
F13 Beta 3, at least at http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/arm/os/Packages/ has fedora-release-13-1.2.beta2.noarch.rpm but presumably this should be beta3. Looking at the /etc/yum.repos.d/*repo files in that package, they not surprisingly point to http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-03-23/f13-arm/arm/os/Packages/ which are the Beta 2 packages. Presumably, if Beta 3 is installed, then any additional packages installed via yum will pull in the Beta 2 packages. The only packages that I have installed on Beta2 that are upgraded in Beta3 are thte gcc suite and perl-version. I intend to edit the /etc/yum.repos.d/* files to point to the new location and install them; presumably that's an easy way to get to Beta3. Hope this make sense, Quentin Armtitage. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F13 Beta 3 - wrong yum repos?
On Wed, 2011-05-18 at 22:42 +0100, Quentin Armitage wrote: > The only packages that I have installed on Beta2 that are upgraded in > Beta3 are thte gcc suite and perl-version. I intend to edit > the /etc/yum.repos.d/* files to point to the new location and install > them; presumably that's an easy way to get to Beta3. > I was wrong about perl-version having been updated. Both Beta2 and Beta3 have two versions of the package in the repos, which is what confused me: perl-version-0.80-112.fc13.armv5tel and perl-version-0.82-1.fc13.armv5tel. Is it intentional that both packages are in the repos? Quentin Armitage ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
