permissions on /dev/null
by Jon Masters
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.
12 years, 9 months
Fedora 13 ARM RC1 - Breathing new life into EOL
by Paul Whalen
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-...
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-st... 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
12 years, 9 months
Re: [fedora-arm] RPM available in the rootfs
by Dennis Gilmore
> 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
12 years, 9 months
Re: [fedora-arm] armv7hl packages
by Dennis Gilmore
> 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.
12 years, 10 months
RPM available in the rootfs
by Jon Masters
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.
12 years, 10 months
