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,
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.
The tar file pretty much says it all
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.
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:
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):
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.
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.
--- begin obligatory quote ---
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.
-h, --help show this help message and exit
-t, --tolerant be tolerant of errors
-C, --cacheonly run entirely from system cache, don't update
-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
-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
--disablerepo=[repo] disable one or more repositories (wildcards
-x [package], --exclude=[package]
exclude package(s) by name or glob
disable exclude from main, for a repo or for
--obsoletes enable obsoletes processing during updates
--noplugins disable Yum plugins
--nogpgcheck disable gpg signature checking
disable plugins by name
enable plugins by name
--skip-broken skip packages with depsolving problems
--color=COLOR control whether color is used
set value of $releasever in yum config and repo
--setopt=SETOPTS set arbitrary config and repo options
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
- 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.
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.
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.
-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
-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
-rw-r--r-- 1 dj games 35423 Jul 6 23:52 rpm-np.spec
-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)
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.
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.
From: DJ Delorie [dj(a)redhat.com]
Received: Tuesday, 05 Jul 2011, 11:34
To: Jon Masters [jcm(a)redhat.com]
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?