[fedora-arm] arm F-18 Branched report: 20121214 changes

2012-12-14 Thread arm Fedora Branched Report 
Compose started at Fri Dec 14 11:10:29 UTC 2012

Broken deps for arm
--
[PyX]
PyX-0.11.1-3.fc18.armv5tel requires libkpathsea.so.4
[aeolus-conductor]
aeolus-all-0.10.6-2.fc18.noarch requires mongodb-server
aeolus-all-0.10.6-2.fc18.noarch requires iwhd
aeolus-all-0.10.6-2.fc18.noarch requires imagefactory-jeosconf-ec2-rhel
aeolus-all-0.10.6-2.fc18.noarch requires 
imagefactory-jeosconf-ec2-fedora
aeolus-all-0.10.6-2.fc18.noarch requires imagefactory
[asterisk]
asterisk-fax-10.0.0-2.fc18.1.armv5tel requires libtiff.so.3
asterisk-snmp-10.0.0-2.fc18.1.armv5tel requires 
perl(:MODULE_COMPAT_5.14.2)
asterisk-snmp-10.0.0-2.fc18.1.armv5tel requires librpmio.so.2
asterisk-snmp-10.0.0-2.fc18.1.armv5tel requires librpm.so.2
[audiocd-kio]
audiocd-kio-4.9.4-1.fc18.armv5tel requires kde-runtime >= 0:4.9.4
[blinken]
blinken-4.9.4-1.fc18.armv5tel requires kdebase-runtime >= 0:4.9.4
[bochs]
bochs-2.6-1.fc18.armv5tel requires bochs-bios = 0:2.6-1.fc18
[bootconf]
bootconf-1.4-6.fc18.noarch requires grub
[calligra-l10n]
calligra-l10n-2.5.3-1.fc18.noarch requires calligra-core >= 0:2.5.3
[cantor]
cantor-4.9.4-1.fc18.armv5tel requires kdebase-runtime >= 0:4.9.4
cantor-4.9.4-1.fc18.armv5tel requires kate-part >= 0:4.9.4
[cloud-init]
cloud-init-0.7.1-1.fc18.noarch requires dmidecode
[coccinella]
coccinella-0.96.20-4.fc18.noarch requires iaxclient
[condor-cloud]
condor-cloud-0.1-5.fc18.noarch requires qemu-kvm >= 0:0.14
condor-cloud-0.1-5.fc18.noarch requires condor-vm-gahp >= 0:7.7.0
condor-cloud-node-0.1-5.fc18.noarch requires qemu-kvm >= 0:0.14
condor-cloud-node-0.1-5.fc18.noarch requires condor-vm-gahp >= 0:7.7.0
[condor-ec2-enhanced]
condor-ec2-enhanced-1.3.1-1.fc18.noarch requires condor >= 0:7.4.4-0.9
[condor-ec2-enhanced-hooks]
condor-ec2-enhanced-hooks-1.3.1-1.fc18.noarch requires condor >= 
0:7.2.0-4
[condor-job-hooks]
condor-job-hooks-1.5-6.fc18.noarch requires condor >= 0:7.0.2-4
[condor-low-latency]
condor-low-latency-1.2-2.fc18.2.noarch requires condor >= 0:7.0.2-4
[condor-wallaby]
condor-wallaby-client-5.0.3-1.fc18.noarch requires python-qmf >= 
0:0.9.1073306
condor-wallaby-client-5.0.3-1.fc18.noarch requires condor >= 0:7.4.4-0.9
[cumin]
cumin-0.1.5220-2.fc18.noarch requires python-qpid-qmf
[dragon]
dragon-4.9.4-1.fc18.armv5tel requires kde-runtime >= 0:4.9.4
[dvisvgm]
dvisvgm-1.0.12-1.fc18.armv5tel requires libkpathsea.so.4
[ekiga]
ekiga-3.9.90-1.fc18.armv5tel requires libpt.so.2.10.7
ekiga-3.9.90-1.fc18.armv5tel requires libopal.so.3.10.7
[ember-media]
ember-media-0.6.2.1-3.fc18.noarch requires ember < 0:0.6.3
ember-media-0.6.2.1-3.fc18.noarch requires ember >= 0:0.6.2
[empathy]
empathy-3.6.2-1.fc18.armv5tel requires libtelepathy-logger.so.2
[evince]
evince-dvi-3.6.1-1.fc18.armv5tel requires libkpathsea.so.4
[ghc-blaze-builder-conduit]
ghc-blaze-builder-conduit-devel-0.4.0.2-3.fc18.armv5tel requires 
ghc-devel(transformers-0.2.2.0-f4e1b941e0825c00ee0acf24d73c8a87)
ghc-blaze-builder-conduit-devel-0.4.0.2-3.fc18.armv5tel requires 
ghc-devel(conduit-0.4.2-5f88c11b8a186be06897e40ef93e7de5)
[ghc-network-conduit]
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-prof(transformers-0.2.2.0) = 0:657fc7647251d805ae3451204e506340
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-prof(network-2.3.0.5) = 0:34038874e5d12f3009ad8fd8b9f52207
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-prof(monad-control-0.3.1) = 0:f3e3f907c32d113562259131f225f2ea
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-prof(lifted-base-0.1.0.3) = 0:deb36b76665759cead4491016ba7a72a
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-prof(conduit-0.4.1.1) = 0:13433be90b4b634d078abe45f2db1bfa
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-prof(bytestring-0.9.1.10) = 0:419d4e55fb10fc796517b175674f95b4
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-prof(base-4.3.1.0) = 0:b3793fe455566fd78d98a0fb3859dd84
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-devel(transformers-0.2.2.0) = 0:657fc7647251d805ae3451204e506340
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-devel(network-2.3.0.5) = 0:34038874e5d12f3009ad8fd8b9f52207
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-devel(monad-control-0.3.1) = 0:f3e3f907c32d113562259131f225f2ea
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-devel(lifted-base-0.1.0.3) = 0:deb36b76665759cead4491016ba7a72a
ghc-network-conduit-devel-0.4.0-1.fc17.armv5tel requires 
ghc-devel(conduit-0.4.1.1) = 0:13433be90b4b634d078a

Re: [fedora-arm] F18 ARM Beta Test Candidate 2

2012-12-14 Thread David A. Marlin 

On 12/13/2012 06:57 PM, Sean Omalley wrote:

Update your uBoot?
http://loginroot.com/installing-uboot-to-guruplug-server-plus/


While updating U-Boot is always an option, the images we make _should_ 
work with existing firmware.  We need to look for better ways to make 
the images.



d.marlin
===






*From:* Derek Atkins 
*To:* David A. Marlin 
*Cc:* Fedora ARM 
*Sent:* Thursday, December 13, 2012 5:02 PM
*Subject:* Re: [fedora-arm] F18 ARM Beta Test Candidate 2

David,

"David A. Marlin" mailto:dmar...@redhat.com>> writes:
projects/LinuxCellPhone
> There are a number of pre-created F18 ARM Beta TC2 (Test Candidate 
2) images available for testing, including: PandaBoard, Trim Slice, 
Versatile Express (QEMU) and Kirkwood.

>
> Images can be downloaded from:
>
> http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/

I just tried the Kirkwood image and it didn't work because the 1st
partition is EXT and not FAT.  UBoot on my GuruPlug doesn't support
that.

Also note that I suspect I'm also running into a known kernel bug with
the F17 release: https://bugzilla.kernel.org/show_bug.cgi?id=42680
Unfortunately I don't know if there is a workaround for this, especially
considering that uImage-kirkwood reports that it is not compressed:

/media/boot/uImage-kirkwood: u-boot legacy uImage, 
3.4.2-3.fc17.armv5tel.kirkwood, Linux/ARM, OS Kernel Image (Not 
compressed), 3291832 bytes, Mon Jun 18 00:58:01 2012, Load Address: 
0x8000, Entry Point: 0x8000, Header CRC: 0xCDB8004D, Data CRC: 
0x6C6E299A


Any ideas?

-derek

--
  Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
  Member, MIT Student Information Processing Board (SIPB)
  URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
warl...@mit.edu    PGP key available
___
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] F18 ARM Beta Test Candidate 2

2012-12-14 Thread David A. Marlin 

On 12/13/2012 04:02 PM, Derek Atkins wrote:

David,

"David A. Marlin"  writes:


There are a number of pre-created F18 ARM Beta TC2 (Test Candidate 2) images 
available for testing, including: PandaBoard, Trim Slice, Versatile Express 
(QEMU) and Kirkwood.

Images can be downloaded from:

   http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/

I just tried the Kirkwood image and it didn't work because the 1st
partition is EXT and not FAT.  UBoot on my GuruPlug doesn't support
that.


Ok, we'll have to look at this image some more.  Thank you for testing.

d.marlin
===


Also note that I suspect I'm also running into a known kernel bug with
the F17 release:  https://bugzilla.kernel.org/show_bug.cgi?id=42680
Unfortunately I don't know if there is a workaround for this, especially
considering that uImage-kirkwood reports that it is not compressed:

/media/boot/uImage-kirkwood: u-boot legacy uImage, 
3.4.2-3.fc17.armv5tel.kirkwood, Linux/ARM, OS Kernel Image (Not compressed), 
3291832 bytes, Mon Jun 18 00:58:01 2012, Load Address: 0x8000, Entry Point: 
0x8000, Header CRC: 0xCDB8004D, Data CRC: 0x6C6E299A

Any ideas?

-derek



___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Daily Koji Compare Stats

2012-12-14 Thread jon . chiappetta 
Fri Dec 14 09:05:01 EST 2012


f17-updates : arm vs PA

 Same |Newer |Older |Local |   Remote | 
 Missing |
--
 2655 |0 |  334 |1 |  385 | 
 413 |

http://142.204.133.82/jon/koji/kc.f17-updates.diff.html


f18 : arm vs PA

 Same |Newer |Older |Local |   Remote | 
 Missing |
--
12131 |   10 |  201 |2 |  284 | 
 263 |

http://142.204.133.82/jon/koji/kc.f18.diff.html


f18-updates-testing : arm vs PA

 Same |Newer |Older |Local |   Remote | 
 Missing |
--
 2781 |2 |  225 |1 |  246 | 
 242 |

http://142.204.133.82/jon/koji/kc.f18-updates-testing.diff.html


f19 : arm vs PA

 Same |Newer |Older |Local |   Remote | 
 Missing |
--
10726 |   17 | 1684 |2 |  312 | 
2868 |

http://142.204.133.82/jon/koji/kc.f19.diff.html


ARM Build Status Wiki:
https://fedoraproject.org/wiki/Architectures/ARM
https://fedoraproject.org/wiki/Architectures/ARM/Fedora17_rawhide


Fri Dec 14 11:34:56 EST 2012
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] F18 ARM Beta Test Candidate 2

2012-12-14 Thread Sean Omalley 
That was part of the series, that if you didn't have the correct firmware you 
had to set the arcnumber, and kernels wouldn't work, and a few other issues. I 
think ext2 support and zlib both were buggy straight from the manufacturer. 
Both Arch and Debian, I believe, require updating the firmware, rather then 
trying to program around broken software that has already been fixed. You even 
have to update the firmware on x86 before you can get support from anyone. 

I am not saying the image creation is correct. I know EFI  requires DOS 
partitions, but we aren't talking about x86 either.  The EFI idea was good but 
the implementation is just totally borked. Even Apple had to get stuff changed 
to support HFS which is indicative of a poor design. 






 From: David A. Marlin 
To: Sean Omalley  
Cc: Derek Atkins ; Fedora ARM  
Sent: Friday, December 14, 2012 8:47 AM
Subject: Re: [fedora-arm] F18 ARM Beta Test Candidate 2
 

On 12/13/2012 06:57 PM, Sean Omalley wrote:

Update your uBoot? 
>http://loginroot.com/installing-uboot-to-guruplug-server-plus/
>
While updating U-Boot is always an option, the images we make
_should_ work with existing firmware.  We need to look for better
ways to make the images.


d.marlin
===


>
>
>
>
>
>
>
>
> From: Derek Atkins 
>To: David A. Marlin  
>Cc: Fedora ARM  
>Sent: Thursday, December 13, 2012 5:02 PM
>Subject: Re: [fedora-arm] F18 ARM Beta Test Candidate 2
> 
>David,
>
>"David A. Marlin"  writes:
>projects/LinuxCellPhone
>> There are a number of pre-created F18 ARM Beta TC2
(Test Candidate 2) images available for testing, including:
PandaBoard, Trim Slice, Versatile Express (QEMU) and
Kirkwood.
>>
>> Images can be downloaded from:
>>
>> 
http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/
>
>I just tried the Kirkwood image and it didn't work because
the 1st
>partition is EXT and not FAT.  UBoot on my GuruPlug doesn't
support
>that.
>
>Also note that I suspect I'm also running into a known
kernel bug with
>the F17 release:  https://bugzilla.kernel.org/show_bug.cgi?id=42680
>Unfortunately I don't know if there is a workaround for
this, especially
>considering that uImage-kirkwood reports that it is not
compressed:
>
>/media/boot/uImage-kirkwood: u-boot legacy uImage,
3.4.2-3.fc17.armv5tel.kirkwood, Linux/ARM, OS Kernel Image
(Not compressed), 3291832 bytes, Mon Jun 18 00:58:01 2012,
Load Address: 0x8000, Entry Point: 0x8000, Header
CRC: 0xCDB8004D, Data CRC: 0x6C6E299A
>
>Any ideas?
>
>-derek
>
>-- 
>      Derek Atkins, SB '93 MIT EE, SM '95 MIT Media
Laboratory
>      Member, MIT Student Information Processing Board 
(SIPB)
>      URL: http://web.mit.edu/warlord/    PP-ASEL-IA   
N1NWH
>      warl...@mit.edu                        PGP key available
>___
>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] F18 ARM Beta Test Candidate 2

2012-12-14 Thread David Marlin 


Sean Omalley wrote:
That was part of the series, that if you didn't have the correct 
firmware you had to set the arcnumber, and kernels wouldn't work, and a 
few other issues. I think ext2 support and zlib both were buggy straight 
from the manufacturer. Both Arch and Debian, I believe, require updating 
the firmware, rather then trying to program around broken software that 
has already been fixed. You even have to update the firmware on x86 
before you can get support from anyone.


If guruplug users don't mind updating the firmware, I'm OK with it.  Do 
you know the minimum version that should be good (so people know if they 
need to upgrade)?


Also, please post if you have suggestions for improvement on the boot 
process.  If the new u-boot supports using the boot.scr, or a uEnv.txt 
script, that would be great.



Thank you,

d.marlin
==



I am not saying the image creation is correct. I know EFI  requires DOS 
partitions, but we aren't talking about x86 either.  The EFI idea was 
good but the implementation is just totally borked. Even Apple had to 
get stuff changed to support HFS which is indicative of a poor design.





*From:* David A. Marlin 
*To:* Sean Omalley 
*Cc:* Derek Atkins ; Fedora ARM 


*Sent:* Friday, December 14, 2012 8:47 AM
*Subject:* Re: [fedora-arm] F18 ARM Beta Test Candidate 2

On 12/13/2012 06:57 PM, Sean Omalley wrote:

Update your uBoot?
http://loginroot.com/installing-uboot-to-guruplug-server-plus/


While updating U-Boot is always an option, the images we make _should_ 
work with existing firmware.  We need to look for better ways to make 
the images.



d.marlin
===






*From:* Derek Atkins  
*To:* David A. Marlin  
*Cc:* Fedora ARM  


*Sent:* Thursday, December 13, 2012 5:02 PM
*Subject:* Re: [fedora-arm] F18 ARM Beta Test Candidate 2

David,

"David A. Marlin" mailto:dmar...@redhat.com>> writes:
projects/LinuxCellPhone
> There are a number of pre-created F18 ARM Beta TC2 (Test Candidate 
2) images available for testing, including: PandaBoard, Trim Slice, 
Versatile Express (QEMU) and Kirkwood.

>
> Images can be downloaded from:
>
>  http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/

I just tried the Kirkwood image and it didn't work because the 1st
partition is EXT and not FAT.  UBoot on my GuruPlug doesn't support
that.

Also note that I suspect I'm also running into a known kernel bug with
the F17 release:  https://bugzilla.kernel.org/show_bug.cgi?id=42680
Unfortunately I don't know if there is a workaround for this, especially
considering that uImage-kirkwood reports that it is not compressed:

/media/boot/uImage-kirkwood: u-boot legacy uImage, 
3.4.2-3.fc17.armv5tel.kirkwood, Linux/ARM, OS Kernel Image (Not 
compressed), 3291832 bytes, Mon Jun 18 00:58:01 2012, Load Address: 
0x8000, Entry Point: 0x8000, Header CRC: 0xCDB8004D, Data CRC: 
0x6C6E299A


Any ideas?

-derek

--
  Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
  Member, MIT Student Information Processing Board  (SIPB)
  URL: http://web.mit.edu/warlord/PP-ASEL-IAN1NWH
  warl...@mit.edu 
PGP key available

___
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] Fedora 17 v6hl First Compose Image

2012-12-14 Thread Sean Omalley 
Thank you! That worked!

 Although I got a nice ascii train picture flying by the screen... so Im not 
sure im not hacked..

Just FYI in /lib/modules there is  3.1.9 kruft lying around. 





 From: M A Young 
To: Sean Omalley  
Cc: Jon Chiappetta ; arm 
 
Sent: Thursday, December 13, 2012 5:50 AM
Subject: Re: [fedora-arm] Fedora 17 v6hl First Compose Image
 
On Thu, 13 Dec 2012, Sean Omalley wrote:

> It is all good. I didn't expect it to be perfect by any means. :)
> 
> I may have missed it. But how are you building these? I need the dev tools,
> at least enough to rebuild the kernel. ( I need to hardwire my wireless
> keyboard driver. It makes it less flaky...) Or can i just do it on the armv5
> image with different flags?  i don't have a cross compiler and such set up.
> (and if you have them build already, no sense in redoing it.)

You can install extra v6hl packages that aren't in the image (see the first 
message of this thread) by running
yum install -y --disablerepo=\* --enablerepo=fedora-rpfr packagename

I pulled in gdm to get the graphical login working and gnome-terminal for a 
terminal, but dev packages are probably there as well. Note the kernel used by 
this image is the same kernel as the v5 image.

    Michael Young___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Fedora 17 v6hl First Compose Image

2012-12-14 Thread Jared K. Smith 
On Fri, Dec 14, 2012 at 1:43 PM, Sean Omalley  wrote:
>  Although I got a nice ascii train picture flying by the screen... so Im not
> sure im not hacked..

Is that the steam locomotive that drives by if you type "sl" instead
of "ls" (and have the "sl" package installed), by chance?

--
Jared Smith
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] no /usr/lib in the nfs-root Re: ARMv8 Bootstrap Project

2012-12-14 Thread Guy Streeter 
On 12/06/2012 01:58 PM, Guy Streeter wrote:
> In the process of making sure I understand all this, I gave building nss-util
> a go. It failed because /usr/lib doesn't exist. Should /usr/lib exist, or is
> the correct response to change nss-util so it uses /usr/lib64 ?
> 
> Is responding to this thread the best way to discuss this, or should it happen
> on chat or in the wiki?
> 
> thanks,
> --Guy
> 

So is this project already dead, or what?
--Guy


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] F18 ARM Beta Test Candidate 2

2012-12-14 Thread Jon Masters 
Sean, Derek, others,

On 12/14/2012 12:31 PM, Sean Omalley wrote:
> That was part of the series, that if you didn't have the correct
> firmware you had to set the arcnumber, and kernels wouldn't work, and a
> few other issues. I think ext2 support and zlib both were buggy straight
> from the manufacturer. Both Arch and Debian, I believe, require updating
> the firmware, rather then trying to program around broken software that
> has already been fixed. You even have to update the firmware on x86
> before you can get support from anyone.
> 
> I am not saying the image creation is correct.

I posted notes on how to install onto the non-Plus GuruPlug. Generally
speaking, I strongly disfavor ever touching U-Boot on a device[0]. We
can get it to install using VFAT for the first partition, but that code
isn't currently in Anaconda, so some post-processing is needed for those
devices that can't read the ext3 filesystem. I am not going to advocate
for holding the release or hacking Anaconda further in F18 over this
one. We'll get to it, but for now, David pointed to my notes:

http://lists.fedoraproject.org/pipermail/arm/2012-December/004609.html

If Derek is local to Cambridge, MA, we can even grab a coffee and I can
show you sometime how to get it working.

> I know EFI  requires DOS
> partitions, but we aren't talking about x86 either.  The EFI idea was
> good but the implementation is just totally borked. Even Apple had to
> get stuff changed to support HFS which is indicative of a poor design.

I'm afraid, I'm not getting your point here (unless it's "some other
boot protocols use FAT filesystems too") because U-Boot isn't (U)EFI. I
am actually a fan of the UEFI design as opposed to U-Boot. U-Boot is the
Swiss Army Knife of embedded fanbois (of which I am one elsewhere) but
it doesn't have a multi-thousand page standard manual, or an industry
body driving it, or many of the other good things that UEFI has and
which too many in the Open Source community instantly hate without
realizing that's why their PCs aren't even worse today.

Jon.

[0] Call me stodgy and old but I want a platform provided by the
hardware vendor. I'm not a fan of what other distros do hacking stuff
up. It's why I'm big on the boat of getting us moved to UEFI asap.
Slight caveat in the case that there's easy JTAG - I'm less concerned
about bricking devices then, but I don't want Fedora doing firmware.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] no /usr/lib in the nfs-root Re: ARMv8 Bootstrap Project

2012-12-14 Thread Jon Masters 
On 12/14/2012 03:11 PM, Guy Streeter wrote:
> On 12/06/2012 01:58 PM, Guy Streeter wrote:
>> In the process of making sure I understand all this, I gave building nss-util
>> a go. It failed because /usr/lib doesn't exist. Should /usr/lib exist, or is
>> the correct response to change nss-util so it uses /usr/lib64 ?
>>
>> Is responding to this thread the best way to discuss this, or should it 
>> happen
>> on chat or in the wiki?

> So is this project already dead, or what?

Nope. We're short on cycles. I did two all-nighers this week. One was
fixing the build system, the other was getting Al's filesystem in place
on our in-house ARMv8 FPGA[0] platform for validation. The latter is not
quite done yet. From next week, Mark will have some cycles and will
assist as Al transitions into being one of our two Linaro Enterprise
Group engineers (the other is Fu Wei, who just joined us this wek).
David has done a great job too, he's short on cycles.

I'll have Al's filesystem running on the FPGA next week and get in place
a system to regularly test it. Lots of lifting to do there. That's my
priority, that and fixing the model networking glitches. I'll leave
package bootstrap to a trio of Al/David/Mark - Al is on vacation this
week and Mark isn't free to poke until next week.

Jon.

[0] It's now public knowledge (as of recently). I have an ARMv8 FPGA in
the lab. It's not super fast, but that's not the point. It's "hardware".

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] no /usr/lib in the nfs-root Re: ARMv8 Bootstrap Project

2012-12-14 Thread omalle...@rocketmail.com 
Call me a  dummy  but id say 64 bit chunks should go in lib64 esp if the arch 
supports 32 bit libs as well. 

- Reply message -
From: "Guy Streeter" 
To: 
Subject: [fedora-arm] no /usr/lib in the nfs-root Re: ARMv8 Bootstrap Project
Date: Fri, Dec 14, 2012 15:11


On 12/06/2012 01:58 PM, Guy Streeter wrote:
> In the process of making sure I understand all this, I gave building nss-util
> a go. It failed because /usr/lib doesn't exist. Should /usr/lib exist, or is
> the correct response to change nss-util so it uses /usr/lib64 ?
> 
> Is responding to this thread the best way to discuss this, or should it happen
> on chat or in the wiki?
> 
> thanks,
> --Guy
> 

So is this project already dead, or what?
--Guy


___
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] F18 ARM Beta Test Candidate 2

2012-12-14 Thread Jon Masters 
On 12/13/2012 10:36 AM, David A. Marlin wrote:
> There are a number of pre-created F18 ARM Beta TC2 (Test Candidate 2) images 
> available for testing, including: PandaBoard, Trim Slice, Versatile Express 
> (QEMU) and Kirkwood.
> 
> Images can be downloaded from:
> 
>http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/

Confirm that this works to the same extent as the previous one. With the
existing configuration changes to U-Boot (documented on the wiki, and in
my other email:
http://lists.fedoraproject.org/pipermail/arm/2012-December/004609.html )
and a reformatted boot (vfat) partition, this image is good to go. So,
for final we can post-process the image, or change the kickstart script
to repartition, etc.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm