[opensuse-buildservice] qemu Cross Compilation Instructions
I'd really like to RTFM, but in this case I can't find it: I'm looking for documentation - How do I configure my OBS 2.3 instance so that I can use qemu to compile packages for the ARM architecture? I've seen a few posts which mention installing qemu as a build dependency, such as: Preinstall: qemu-linux-user ExportFilter: ^qemu-linux-user.*\.x86_64.rpm$ . armv7l armv5el However, this doesn't seem to be all that is required. So far, I've been able to create a repo for the ARM architecture, and get the ARM scheduler running - however, builds are never attempted; they are stuck at "scheduled". So what else am I missing? Also - has qemu cross-compilation been attempted for a distribution other than openSUSE? Thanks. -- Troy Telford -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mon, Jun 11, 2012 at 10:12 PM, Troy Telford <ttelford.groups@gmail.com> wrote:
So far, I've been able to create a repo for the ARM architecture, and get the ARM scheduler running - however, builds are never attempted; they are stuck at "scheduled".
So what else am I missing?
Add something like this to your project config: %ifarch armv7l armv5el HostArch: x86_64 %endif This will tell OBS to schedule jobs from those architectures on x86_64 workers instead of arm workers (that you apparently don't have).
Also - has qemu cross-compilation been attempted for a distribution other than openSUSE?
The principles are always the same, no matter which distribution you build. MeeGo for instance used this technology to build. Robert -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2012-06-12 04:28:48 +0000, Robert Schiele said:
On Mon, Jun 11, 2012 at 10:12 PM, Troy Telford <ttelford.groups@gmail.com> wrote:
So far, I've been able to create a repo for the ARM architecture, and get the ARM scheduler running - however, builds are never attempted; they are stuck at "scheduled".
So what else am I missing?
Add something like this to your project config:
%ifarch armv7l armv5el HostArch: x86_64 %endif
This will tell OBS to schedule jobs from those architectures on x86_64 workers instead of arm workers (that you apparently don't have).
This gets me farther than before. However, I'm still having problems: Distro: Fedora_17 (not my choice - I have to build it) Prjconf: Nearly identical to build.opensuse.org for F17; the diff is: @@ -1,3 +1,11 @@ +%ifarch armv7l armv5el armv7hl +HostArch: x86_64 +Preinstall: qemu-user qemu-system-arm qemu-img qemu-common +%endif +ExportFilter: ^qemu-user.*\.x86_64.rpm$ . armv7l armv5el +ExportFilter: ^qemu-system-arm.*\.x86_64.rpm$ . armv7l armv5el +ExportFilter: ^qemu-img.*\.x86_64.rpm$ . armv7l armv5el +ExportFilter: ^qemu-common.*\.x86_64.rpm$ . armv7l armv5el Preinstall: acl attr bash bzip2 coreutils device-mapper-libs diffutils Preinstall: filesystem glibc grep libacl libattr Preinstall: libgcc m4 ncurses pam nss nspr This seems to match up (fairly) well with the ARM support on openSUSE:Factory:ARM, which is: %ifarch armv5el armv7l armv7hl Hostarch: x86_64 # cross build support for the build hosts Preinstall: qemu-linux-user %endif %ifarch armv7l armv7hl # qemu-accel-arm includes armv7l specific gcc, so we can't install it on armv5 Preinstall: qemu-accel-arm %endif ExportFilter: ^qemu-linux-user.*\.x86_64.rpm$ . armv7l armv5el ExportFilter: ^qemu-accel.*\.x86_64.rpm$ . armv7l armv5el And the build log of a test package: Using BUILD_ROOT=/var/tmp/obs_workers/root_2 Using BUILD_ARCH=armv5el n010 started "build xz.spec" at Tue Jun 19 23:34:48 UTC 2012. Building xz for project 'foo' repository 'Fedora_17' arch 'armv5el' srcmd5 '4e462df4254424f6e9025eb08c050c90' processing specfile /var/tmp/obs_workers/root_2/.build-srcdir/xz.spec ... running changelog2spec --target rpm --file /var/tmp/obs_workers/root_2/.build-srcdir/xz.spec init_buildsystem --configdir /var/run/obs/worker/2/build/configs --cachedir /var/cache/build --clean --rpmlist /var/tmp/obs_workers/root_2/.build.rpmlist /var/tmp/obs_workers/root_2/.build-srcdir/xz.spec build rpmlint-Factory ... registering binfmt handlers Warning: could not register binfmt handlers Warning: mmap_min_addr is != 0. If programs fail at mmap this could be the reason cycle: filesystem -> setup breaking dependency filesystem -> setup cycle: glibc -> nss-softokn-freebl breaking dependency nss-softokn-freebl -> glibc cycle: pam -> coreutils breaking dependency coreutils -> pam cycle: rpm-libs -> rpm breaking dependency rpm -> rpm-libs [1/54] preinstalling filesystem... [2/54] preinstalling libgcc... [3/54] preinstalling setup... . . . [50/56] preinstalling qemu-img... [51/56] preinstalling qemu-common... [52/56] preinstalling rpm... [53/56] preinstalling qemu-system-arm... [54/56] preinstalling qemu-user... [53/54] preinstalling rpm-libs... [54/54] preinstalling rpm-sign... initializing rpm db... chroot: failed to run command `rpm': Exec format error So it appears that while OBS is at least attempting to build the package, I'm not seeing any indication that qemu is being invoked. It seems that the worker is just trying to execute the ARM-architecture 'rpm' as native x86_64 code - and dies.
Also - has qemu cross-compilation been attempted for a distribution other than openSUSE?
The principles are always the same, no matter which distribution you build. MeeGo for instance used this technology to build.
Having run my own OBS instance for ~6 years now, I'm also well aware that while in principle it should work, in practice the behavior doesn't always match perfectly. -- Troy Telford -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wed, Jun 20, 2012 at 2:35 AM, Troy Telford <ttelford.groups@gmail.com> wrote:
So it appears that while OBS is at least attempting to build the package, I'm not seeing any indication that qemu is being invoked. It seems that the worker is just trying to execute the ARM-architecture 'rpm' as native x86_64 code - and dies.
In fact it tries to invoke /usr/bin/qemu-arm-binfmt which likely does not exist in your qemu package. To solve this there are two options: Either you just use the qemu package from openSUSE or if you prefer to use the Fedora qemu you might want to create a separate package in addition that has the qemu-arm-binfmt (taking the source code or binary from the openSUSE package). Robert -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2012-06-20 02:55:06 +0000, Robert Schiele said:
On Wed, Jun 20, 2012 at 2:35 AM, Troy Telford <ttelford.groups@gmail.com> wrote:
So it appears that while OBS is at least attempting to build the package, I'm not seeing any indication that qemu is being invoked. It seems that the worker is just trying to execute the ARM-architecture 'rpm' as native x86_64 code - and dies.
In fact it tries to invoke /usr/bin/qemu-arm-binfmt which likely does not exist in your qemu package.
Yup; qemu-arm exists, but qemu-arm-binfmt does not.
To solve this there are two options: Either you just use the qemu package from openSUSE or if you prefer to use the Fedora qemu you might want to create a separate package in addition that has the qemu-arm-binfmt (taking the source code or binary from the openSUSE package).
That is very helpful! I'm nearly there, I think, but I have a few outstanding issues I don't know how to explain: 1.) My worker nodes (SLES 11SP2) report a warning - I do not get the warning if a user uses 'osc build' (from an openSUSE 12.1 system). registering binfmt handlers Warning: could not register binfmt handlers Warning: mmap_min_addr is != 0. If programs fail at mmap this could be the reason Use of uninitialized value in string eq at /var/run/obs/worker/1/build/Build.pm line 608. (repeated many times) When the build gets past the 'preinst' packages - and tries to execute 'rpm' (using the native ARM rpm binary), it fails as before. I've tried: * updating OBS (I'm using 2.3 stable) * restarting OBS on the server * stopped the workers * removed /var/run/obs and /var/tmp/obs_workers (ie. everything that's stored on the worker's filesystem) * re-started the workers I still get the same problem - the buildroot only partially builds on the worker nodes, but works fine if a 'local' build using 'osc build' is done. 2.) When using 'osc build' to do a local build, instead of installing the compiler to /usr/bin/g++ (which is what rpm -ql gcc-c++ shows the installation path *should* be), the compiler is instead installed to /usr/bin/armv5tel-redhat-linux-gnueabi-c++, with no symlink to the corresponding 'short' compiler name. Does anybody know why this is? It certainly plays havoc with makefiles expecting to call gcc, g++, cc, c++, etc. -- Troy Telford -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Mittwoch, 20. Juni 2012, 16:46:15 schrieb Troy Telford:
On 2012-06-20 02:55:06 +0000, Robert Schiele said:
On Wed, Jun 20, 2012 at 2:35 AM, Troy Telford <ttelford.groups@gmail.com> wrote:
So it appears that while OBS is at least attempting to build the package, I'm not seeing any indication that qemu is being invoked. It seems that the worker is just trying to execute the ARM-architecture 'rpm' as native x86_64 code - and dies.
In fact it tries to invoke /usr/bin/qemu-arm-binfmt which likely does not exist in your qemu package.
Yup; qemu-arm exists, but qemu-arm-binfmt does not.
To solve this there are two options: Either you just use the qemu package from openSUSE or if you prefer to use the Fedora qemu you might want to create a separate package in addition that has the qemu-arm-binfmt (taking the source code or binary from the openSUSE package).
That is very helpful!
I'm nearly there, I think, but I have a few outstanding issues I don't know how to explain:
1.) My worker nodes (SLES 11SP2) report a warning - I do not get the warning if a user uses 'osc build' (from an openSUSE 12.1 system). registering binfmt handlers Warning: could not register binfmt handlers
That looks like a problem. Are you sure that you have binfmtmisc handler available here? Some debugging here may give some insight ..
Warning: mmap_min_addr is != 0. If programs fail at mmap this could be the reason Use of uninitialized value in string eq at /var/run/obs/worker/1/build/Build.pm line 608. (repeated many times)
not nice, but most likely not important here.
When the build gets past the 'preinst' packages - and tries to execute 'rpm' (using the native ARM rpm binary), it fails as before.
I've tried: * updating OBS (I'm using 2.3 stable) * restarting OBS on the server * stopped the workers * removed /var/run/obs and /var/tmp/obs_workers (ie. everything that's stored on the worker's filesystem) * re-started the workers
I still get the same problem - the buildroot only partially builds on the worker nodes, but works fine if a 'local' build using 'osc build' is done.
the setup works in the same way on local build as on the servers. So something must be different on your installations. I have to admit that I have not tested the workers on SP2 yet ...
2.) When using 'osc build' to do a local build, instead of installing the compiler to /usr/bin/g++ (which is what rpm -ql gcc-c++ shows the installation path *should* be), the compiler is instead installed to /usr/bin/armv5tel-redhat-linux-gnueabi-c++, with no symlink to the corresponding 'short' compiler name.
Does anybody know why this is? It certainly plays havoc with makefiles expecting to call gcc, g++, cc, c++, etc.
This must be caused by your project configuration. build is just installing packages. Either your compiler package is not installed or some other other package is messing it up ... -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, Jun 21, 2012 at 8:36 AM, Adrian Schröter <adrian@suse.de> wrote:
Am Mittwoch, 20. Juni 2012, 16:46:15 schrieb Troy Telford:
2.) When using 'osc build' to do a local build, instead of installing the compiler to /usr/bin/g++ (which is what rpm -ql gcc-c++ shows the installation path *should* be), the compiler is instead installed to /usr/bin/armv5tel-redhat-linux-gnueabi-c++, with no symlink to the corresponding 'short' compiler name.
Does anybody know why this is? It certainly plays havoc with makefiles expecting to call gcc, g++, cc, c++, etc.
This must be caused by your project configuration. build is just installing packages. Either your compiler package is not installed or some other other package is messing it up ...
Are you building for a Fedora 17 based system? In that case you probably need to update the build package to at least a version from May 30 2012 to get the following relevant patch: commit ecd7d38b106fb189d12da23b10a0c5ae4cf6e7a6 Author: Frank Lichtenheld <flichtenheld@astaro.com> Date: Wed May 30 21:08:57 2012 +0200 setupccache: remove obsolete rm command $builduserhome is undefined, so that really deletes /bin/gcc etc. Which is a problem on Fedora 17 where /bin is a symlink to /usr/bin. Robert -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2012-06-21 07:25:18 +0000, Robert Schiele said:
On Thu, Jun 21, 2012 at 8:36 AM, Adrian Schröter <adrian@suse.de> wrote:
Am Mittwoch, 20. Juni 2012, 16:46:15 schrieb Troy Telford:
2.) When using 'osc build' to do a local build, instead of installing the compiler to /usr/bin/g++ (which is what rpm -ql gcc-c++ shows the installation path *should* be), the compiler is instead installed to /usr/bin/armv5tel-redhat-linux-gnueabi-c++, with no symlink to the corresponding 'short' compiler name.
Does anybody know why this is? It certainly plays havoc with makefiles expecting to call gcc, g++, cc, c++, etc.
This must be caused by your project configuration. build is just installing packages. Either your compiler package is not installed or some other other package is messing it up ...
Are you building for a Fedora 17 based system? In that case you probably need to update the build package to at least a version from May 30 2012 to get the following relevant patch:
commit ecd7d38b106fb189d12da23b10a0c5ae4cf6e7a6 Author: Frank Lichtenheld <flichtenheld@astaro.com> Date: Wed May 30 21:08:57 2012 +0200
setupccache: remove obsolete rm command
$builduserhome is undefined, so that really deletes /bin/gcc etc. Which is a problem on Fedora 17 where /bin is a symlink to /usr/bin.
I had updated the build scripts on the OBS server (and supposedly this follows to the workers), but not the 'local' host. Updating the build script was the trick. Thanks! -- Troy Telford -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2012-06-21 06:36:56 +0000, Adrian Schröter said:
Am Mittwoch, 20. Juni 2012, 16:46:15 schrieb Troy Telford:
On 2012-06-20 02:55:06 +0000, Robert Schiele said:
On Wed, Jun 20, 2012 at 2:35 AM, Troy Telford <ttelford.groups@gmail.com> wrote:
So it appears that while OBS is at least attempting to build the package, I'm not seeing any indication that qemu is being invoked. It seems that the worker is just trying to execute the ARM-architecture 'rpm' as native x86_64 code - and dies.
In fact it tries to invoke /usr/bin/qemu-arm-binfmt which likely does not exist in your qemu package.
Yup; qemu-arm exists, but qemu-arm-binfmt does not.
To solve this there are two options: Either you just use the qemu package from openSUSE or if you prefer to use the Fedora qemu you might want to create a separate package in addition that has the qemu-arm-binfmt (taking the source code or binary from the openSUSE package).
That is very helpful!
I'm nearly there, I think, but I have a few outstanding issues I don't know how to explain:
1.) My worker nodes (SLES 11SP2) report a warning - I do not get the warning if a user uses 'osc build' (from an openSUSE 12.1 system). registering binfmt handlers Warning: could not register binfmt handlers
That looks like a problem. Are you sure that you have binfmtmisc handler available here? Some debugging here may give some insight ..
the binfmt_misc kernel module is loaded. /proc/sys/fs/binfmt_misc exists, and has the expected 'register' and 'status' files. If I manually register the various binfmt entries (using /usr/lib/build/qemu-reg from an opensuse installation as a guide), it looks like qemu starts running. However - I don't know why the binfmt_misc handlers aren't being configured by the obs worker -- unless, of course, they aren't configured by the worker at all. I also don't know where the binfmt_misc handlers are being setup for a worker. Since running them manually works, I'm yet sure what the problem could be - permissions, maybe, but I'm just guessing at this point. I'll see if I can figure it out, but if I get a pointer in the right direction, I'd be grateful.
the setup works in the same way on local build as on the servers. So something must be different on your installations.
I have to admit that I have not tested the workers on SP2 yet ...
After manually registering the binfmt_misc handlers, the sp2 worker seems to work - at least, it creates a buildroot & starts the build. -- Troy Telford -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2012-06-21 16:21:45 +0000, Troy Telford said:
On 2012-06-21 06:36:56 +0000, Adrian Schröter said:
available here? Some debugging here may give some insight ..
the binfmt_misc kernel module is loaded.
/proc/sys/fs/binfmt_misc exists, and has the expected 'register' and 'status' files.
If I manually register the various binfmt entries (using /usr/lib/build/qemu-reg from an opensuse installation as a guide), it looks like qemu starts running.
However - I don't know why the binfmt_misc handlers aren't being configured by the obs worker -- unless, of course, they aren't configured by the worker at all.
I also don't know where the binfmt_misc handlers are being setup for a worker. Since running them manually works, I'm yet sure what the problem could be - permissions, maybe, but I'm just guessing at this point.
I'll see if I can figure it out, but if I get a pointer in the right direction, I'd be grateful.
It appears that a script 'qemu-binfmt-conf.sh' needs to be installed natively on the machine into /usr/sbin. (It's in the qemu-linux-user pkg)
the setup works in the same way on local build as on the servers. So something must be different on your installations.
I have to admit that I have not tested the workers on SP2 yet ...
It appears that SP2 works fine for F17 & its 'arm' arch (using armv5el as the arch in OBS) I'm not sure if I can build the 'armhfp' arch for F17, but Fedora's 'arm' as arm5el in OBS is a start. The next part of the message is largely a log of what I've done - in case somebody else is trying to figure this out as well. (ie. http://xkcd.com/979/) I'm not familiar with any ARM arch, so the difference between armv5el & armv7l is an unknown. As is the difference between the architectures between distros - for example, I have no idea what ARM flavor should be used for what Fedora calls 'armhfp' - armv7l, armv7hl? I assumed that what Fedora calls 'armhfp' was an ARMv7 flavor; however, when QEMU is fired up & tries to execute RPM, it dies: [51/53] preinstalling rpm... [52/53] preinstalling rpm-libs... [53/53] preinstalling rpm-sign... initializing rpm db... qemu: uncaught target signal 11 (Segmentation fault) - core dumped /usr/lib/build/init_buildsystem: line 233: 14384 Segmentation fault chroot $BUILD_ROOT rpm --initdb I don't know if the segfault is due to a QEMU issue, if I'm emulating the wrong processor arch, or something else entirely at this point. -- Troy Telford -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Donnerstag, 21. Juni 2012, 12:00:28 schrieb Troy Telford:
On 2012-06-21 16:21:45 +0000, Troy Telford said: ...
the setup works in the same way on local build as on the servers. So something must be different on your installations.
I have to admit that I have not tested the workers on SP2 yet ...
It appears that SP2 works fine for F17 & its 'arm' arch (using armv5el as the arch in OBS) I'm not sure if I can build the 'armhfp' arch for F17, but Fedora's 'arm' as arm5el in OBS is a start.
IIRC it should be armv7hl which means armv7l hardware with used hard floating point unit support compiled in (makes ABI incompatible on ARM).
The next part of the message is largely a log of what I've done - in case somebody else is trying to figure this out as well.
(ie. http://xkcd.com/979/)
I'm not familiar with any ARM arch, so the difference between armv5el & armv7l is an unknown.
As is the difference between the architectures between distros - for example, I have no idea what ARM flavor should be used for what Fedora calls 'armhfp' - armv7l, armv7hl?
I assumed that what Fedora calls 'armhfp' was an ARMv7 flavor; however, when QEMU is fired up & tries to execute RPM, it dies: [51/53] preinstalling rpm... [52/53] preinstalling rpm-libs... [53/53] preinstalling rpm-sign... initializing rpm db... qemu: uncaught target signal 11 (Segmentation fault) - core dumped /usr/lib/build/init_buildsystem: line 233: 14384 Segmentation fault chroot $BUILD_ROOT rpm --initdb
I don't know if the segfault is due to a QEMU issue, if I'm emulating the wrong processor arch, or something else entirely at this point.
I would think it was caused by qemu. Do you use the version from openSUSE? Alex did plenty of bugfixes to support arm builds ... -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2012-06-21 19:39:18 +0000, Adrian Schröter said:
I don't know if the segfault is due to a QEMU issue, if I'm emulating the wrong processor arch, or something else entirely at this point.
I would think it was caused by qemu. Do you use the version from openSUSE? Alex did plenty of bugfixes to support arm builds ...
At this point, I'm not sure how to interpret what I'm seeing, so I'll try to be thorough: - I am using the following packages from the openSUSE:Factory:ARM project: (dated today) (http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/standard/x8...) qemu-accel-armv7hl-0.2-84.1.x86_64.rpm qemu-linux-user-1.1.0-89.1.x86_64.rpm I'm building for Fedora 17 'armhfp'; I have no issues with F17 & the 'arm' architecure. The behavior I'm seeing is not something I can explain. It's more or less identical between worker nodes and an 'osc local' build. - the difference being a core dump is generated on the worker nodes. [27/54] preinstalling qemu-linux-user... . . . [45/54] preinstalling qemu-accel-armv7hl... . . . [51/54] preinstalling util-linux... [52/54] preinstalling rpm... [53/54] preinstalling rpm-libs... [54/54] preinstalling rpm-sign... initializing rpm db... qemu: uncaught target signal 11 (Segmentation fault) - core dumped /var/run/obs/worker/1/build/init_buildsystem: line 233: 22581 Segmentation fault chroot $BUILD_ROOT rpm --initdb Now for the strange bit: n003:/ # chroot /var/tmp/obs_workers/root_1/ rpm --initdb warning: read(/proc/cpuinfo) failed warning: read(/proc/cpuinfo) failed n003:/ # echo $? 0 n003:/ # If executed from the build script, I get a core dump. If I run chroot directly, it doesn't. I checked to see if the binary was in fact the ARM binary: n003:/ # file /var/tmp/obs_workers/root_1/bin/rpm /var/tmp/obs_workers/root_1/bin/rpm: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.32, dynamically linked (uses shared libs), stripped So, it is an ARM binary, and it is running just fine. Additionally, I can simply execute "chroot /var/tmp/obs_workers/root_1 bin/bash" and get a bash prompt inside the chroot - and it appears that qemu is being used to run all of the binaries. n003:/ # uname -m x86_64 n003:/ # chroot /var/tmp/obs_workers/root_1/ /bin/bash bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) bash-4.2# uname -m armv7l bash-4.2# I have to say this is pretty slick - kudos to whomever figured that one out! I can easily retrieve core dumps; but I'm not sure if they would be useful at this point - or whom to send them to. -- Troy Telford -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (3)
-
Adrian Schröter -
Robert Schiele -
Troy Telford