resending to the list and not just me
>> El Thu, 18 Aug 2011 15:37:59 -0500
>> Dennis Gilmore <dennis(a)ausil.us> escribió:
>>> hi all,
>>>
>>> I have created a f15 rootfs
>>> http://arm-temp.ausil.us/pub/fedora-arm/rootfs-f15-hfp-20110818.tar.bz2
>>> it has installed kernels for omap and tegra boards, the kernel is
>>> known to work on a trimslice though there seems to be some issues
>>> with the ssd dropping out. the omap kernel should work on beagle and
>>> pandaboards. of course you can just chroot into the image after bind
>>> mounting /proc and /dev from the host. this image has mock installed
>>> and a configuration for use in the vfad this week. the server to host
>>> all the bits is up and has the content ready to go.
>>>
>>> If you intend to participate in the vfad contact me and ill get you a
>>> ssh private key for the upload user on arm-temp.ausil.us so your
>>> results can be made available for all.
>>>
>>> I plan to upload the F-15 GA srpms so people can grab them.
>>>
>>> One thing i plan to do is to write a script that people can run
>>>
>>> it would get a srpm down, mv it on the server, build it in mock
>>> locally, upload the results and run createrepo on the results to make
>>> it available to build against. then rinse and repeat. if someone
>>> wanted to help write it that would be awesome. this way building
>>> would be pretty much hands off, distributed and kinda efficient.
>>>
>>> Dennis
>>
>> so if you have the rootfs i provided and either are booting it
>> natively or chrooting into it.
>> http://arm-temp.ausil.us/pub/fedora-arm/arm-rebuild.sh is a script to
>> randomly grab and rebuild a srpm. you will need to be able to
>> ssh content to the host server. please contact me with a ssh public key
>> or ask me for the private key for the upload user. i forgot to make sure
>> yum in the rootfs is pointing at the right place and forgot to install
>> screen ill get some working yum configs posted and send out an update
>> with them. but we can now get some random scripted rpm building going
>> on.
>
> ok so
>
> rm /etc/yum.repos.d/*
> wget http://arm-temp.ausil.us/pub/fedora-arm/fedora-arm.repo -O
> /etc/yum.repos.d/fedora-arm.repo
> yum install screen
>
>
>
will adjust as soon as i get to the house tonight and report back
ty much
Dont fear the penguin!
Paulo César Pereira de Andrade <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
>2011/8/19 <webwillow(a)thewebwillow.com>:
>> already using it and made adjustments for armv5tel and soft float.
>>
>> when i get to the ppl part of the script i get the failure...you scripts
>> have got me this far with only tiny adjustments needed
>>
>> i than try to reproduce the exact same thing manually and adjust from
>> there..
>>
>> although i did notice the prefix of /usr instead of $PREFIX...ill redo
>> gmp/mpfr/ppl again tonight and see if that makes it through.
>>
>> sometimes you make those little mistakes when frustrated and just plain
>> tired in the middle of the night.
>
> In the branch I made to DJ Delorie scripts to test Mandriva bootstraps,
>I did a change to ppl build, and the pseudo patch for stage1 is:
>
>-%<-
>- gmp | mpfr | ppl )
>+ gmp | mpfr )
> L=$1
> srpm $L
> mcd $BUILDDIR/t-$L
>@@ -507,6 +525,16 @@ case "$1" in
> fix_la $L
> ;;
>
>+ ppl )
>+ L=$1
>+ srpm $L
>+ mcd $BUILDDIR/t-$L
>+ $SRC/${L}-*/configure $TCONFIGARGS --with-gmp-prefix=${ROOTFS}/usr
>+ make $J
>+ make $J install DESTDIR=${ROOTFS}
>+ fix_la $L
>+ ;;
>-%<-
>
> I think this is a quirk required for ppl-0.11 bootstrap.
>
>> ../../rpmbuild/BUILD/ppl-0.11.2/configure --prefix=/usr
>> --build=i686-redhat-linux --host=arm-unknown-linux-gnueabi
>> --with-float=softfp --with-abi=aapcs-linux
>> --with-sysroot=/home/mockbuild/stage2/rootfs --enable-threads=posix
>> --disable-libssp --enable-cxx=yes --enable-werror=no
>>
>>
>> -------- Original Message --------
>> Subject: Re: [fedora-arm] ppl cross compile
>> From: DJ Delorie <dj(a)redhat.com>
>> Date: Thu, August 18, 2011 9:02 pm
>> To: <webwillow(a)thewebwillow.com>
>> Cc: arm(a)lists.fedoraproject.org
>>
>>
>> Try my bootstrap scripts at:
>>
>> http://djdelorie.fedorapeople.org/
>
>Paulo
>
It would seem there are updated nss packages in the F13-ARM updates
repository but they aren't signed. Is this an omission or is there foul
play going on?
Gordan
I was looking for a quick status/summary of fedora version-specific and arm
platform-specific packaging bugs. the section Tracker Bugs on
https://fedoraproject.org/wiki/Architectures/ARM/Package_Maintainersreferen…
"Bug f14-armv5" and "a nice overview of open bugs" but the links
resolve to https://bugzilla.redhat.com/show_bug.cgi?id=f14-armv5 with the
bugzilla error message: 'f14-armv5' is not a valid bug number nor an alias
to a bug.
are these obsoleted by the ARMTracker (which does not appear to be fedora
version-specific, and also shows on bugzilla as Platform: arm9 Linux)?
or maybe now replaced by the new "ARM F-14 Branched report: 20110816
changes" (implicit armv5) emails?
thanks for any info
Hi,
On Wed, Aug 17, 2011 at 6:28 PM, letters.random13
<letters.random13(a)gmail.com> wrote:
> Hello,
>
> [i assumed this is too specific for the arm mailing list, my apologies if it
> should have been directed there instead]
Nope, its not, added it to the CC:. Please send all messages to the list.
> as a newbie, i was studying the f14 arm packaging of python (v2.7) (i.e.,
> python.spec), and comparing it to, e.g., f15 ix86 version (v2.7.1), or even
> the meego 1.2 version (v2.6.4) (which must have been forked off fedora not
> too long ago, and is arch-independent (simply because there is no %check /
> make test)). i have also started independently testing / packaging
> python2.7.2 for meego n900ce.
The Fedora arm package is the same as the F-14 mainline version, not
sure why you're comparing it to the F-15 version. The MeeGo version
forked off Fedora 12.
> there are some cosmetic bugs or inconsistences in the fedora spec file i was
> looking to fix in order to gain some packaging skills.
All fixes need to be committed upstream by the Fedora python
maintainers. The fedora bugzilla is your friend there.
> firstly, the mixing/overlap of CFLAGS and OPT is bizarre,
>
> in 2.7:
> export CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE -fPIC -fwrapv"
> export OPT="$RPM_OPT_FLAGS -D_GNU_SOURCE -fPIC -fwrapv"
> make OPT="$CFLAGS" %{?_smp_mflags}
>
> in 2.7.1 it is marginally less ugly via:
> make EXTRA_CFLAGS="$CFLAGS" %{?_smp_mflags}
>
> both of these basically result in a long string of duplicated args to gcc,
> and, i think, issues with differentiating the flags used between the
> optimized and debug (or safer?) builds.
>
> it naively seems to me that this should instead be something like:
>
> export CFLAGS="-D_GNU_SOURCE"
> #configure adds fpic
> #arm is likely sensitive to compiler optimizer bugs (unexpected test
> failures);
> # optflags defaults to ... -g -O2.
> %if %{debug_build}
> export OPT="%{optflags} -O0 -g"
> EXTRA_CONFIGARGS = "--with-pydebug"
> %else
> export OPT="%{optflags}"
> EXTRA_CONFIGARGS = ""
> %endif
>
> make OPT="$OPT" %{?_smp_mflags}
>
> (i think compiler / optimizer bugs may be causing some test failures, so it
> would be safer / preferred to use different OPT flags (if they solve the
> problem) rather than EXCLUDE the complaining tests?)
> #test_float test failed similar to http://bugs.python.org/issue8265
>
> is it of more use to the fedora arm project to do some of this stuff on f14
> & arm-koji, or would it be better to start working on f15 (python2.7.1)?
> i see that last month python made it into arm.git:
> stage3/python/python-2.7.1-8.fc15.src.rpm
Your actually better off looking at rawhide (which will become F-17)
or F-16 and get the fixes in there. By the F-17 time frame we're
looking to be basically in parallel to mainline Fedora.
> i don't have fedora-ready arm hardware, but the meego (osc) build system has
> fedora15 i586 repository in addition to meego i586/armv7el, so at least i
> can sanity-test my package changes there while i wait for f15 to show up on
> arm-koji.
>
> minor related note:
> out of the ~1220 broken pkgs listed in the recent email:
> [fedora-arm] ARM F-14 Branched report: 20110816 changes
>
> about 200 pkgs have this issue:
> django-addons-0.6.3-1.fc13.noarch requires python(abi) = 0:2.6
>
> while 86 pkgs have this issue:
> mod_python-3.3.1-11.armv5tel requires libpython2.6.so.1.0
>
> since f14 default is python(abi) = 2.7, is this issue present because
> (1) no motivated packager (or automatic repackaging script) has hacked thru
> ~100 pkgs to change
> Requires: python-abi = 2.6
> to
> Requires: python-abi = 2.7
> and confirmed the package rebuilds ok.
> or
> (2) no motivated packager (or automatic repackaging script) has hacked the
> pkgs to contain a (temporary?) ExcludeArch / F-ExcludeArch-arm (or
> ARMTracker) bug, until (1) is completed.
There's an auto rebuild happening, most of those will be fixed once
that has finished. Its not as fast as I would like.
Peter