Re: armel qualification for Wheezy
On 25.05.2012 08:53, Riku Voipio wrote: On Wed, May 23, 2012 at 09:02:33PM +0100, Tixy wrote: So ideally I'd prefer ARM hardware targetted for servers - where the current memory and IO bandwidth issues wouldn't be the problem it is in the current mobile-targetted hardware. http://www.h-online.com/open/news/item/Dell-to-create-its-own-ARM-server-ecosystem-1586206.html Something along these lines? Regards Stefan Peter -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc612db.5040...@gmail.com
Re: armel qualification for Wheezy
On Wed, May 30, 2012 at 02:30:19PM +0200, Stefan Peter wrote: http://www.h-online.com/open/news/item/Dell-to-create-its-own-ARM-server-ecosystem-1586206.html Something along these lines? Hmm, does Dell want to sponsor one of those for Debian. :) I might have to start liking Dell servers if they start making stuff like that. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530150515.gj32...@csclub.uwaterloo.ca
Re: armel qualification for Wheezy
On Tue, May 22, 2012 at 09:16:34AM +0100, Tixy wrote: On Mon, 2012-05-21 at 16:39 +0100, Steve McIntyre wrote: Then again, the imx53s are not as stable as I had hoped. Of the 9 I set up, 1 is just about dead and another is dying. They're also really unhappy with the pl2303 USB serial adapters I've got, which is a PITA. I've always had trouble with Prolific serial adaptors but FTDI based ones have always worked a treat on my ARM boards and PCs. Now I've found a convenient source for those [1] I stick with them. -- Tixy [1] http://www.usbnow.co.uk/p48/USB_to_RS232_with_FTDI_Chipset_(1.8M_Cable)/product_info.html Ah, OK... I've ordered one to play with, thanks for the link. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com C++ ate my sanity -- Jon Rabone -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529004726.ga32...@einval.com
Re: armel qualification for Wheezy
On Thu, 2012-05-24 at 15:36 -0400, Lennart Sorensen wrote: On Thu, May 24, 2012 at 07:12:25PM +0100, Tixy wrote: On Thu, 2012-05-24 at 12:22 -0400, Lennart Sorensen wrote: How are you doing the build using qemu's cpu emulator? I remember last I played with it I had issues with shared libraries where the command i wanted to run needed to find its shared libraries, but if I set the LD_LIBRARY_PATH, then qemu tried to use the other CPUs libraries and wouldn't run. Has this been fixed somehow? Static binaries were fine of course. Here is the crib sheet I wrote when I set this up, it was on a Debian Wheezy system, but my ARM chroot contains Ubuntu Precise as that is what I am targeting in my day job. (Hopefully Debian will work too.) # in these instructions /arm is the directory where I installed my # chroot and tixy is my linux username, replace as appropriate... # # /data is where I have all my source code and other files so I add that # to schroot fstab below, do similar with directories where you have # files you want to access inside the chroot. (Note, home directories # are already available.) su apt-get install debootstrap qemu-user-static binfmt-support schroot debootstrap --foreign --arch=armhf --variant=buildd precise /arm \ http://ports.ubuntu.com/ubuntu-ports cp /usr/bin/qemu-arm-static /arm/usr/bin chroot /arm /debootstrap/debootstrap --second-stage exit # Add to /etc/schroot/schroot.conf [arm] description=ARM Chroot type=directory directory=/arm users=tixy groups=tixy root-groups=root aliases=default # Edit /etc/schroot/default/fstab to add /data /data nonerw,bind 0 0 /run/runnonerw,bind 0 0 # Edit /arm/etc/apt/sources.list to have deb http://ports.ubuntu.com/ precise main universe deb-src http://ports.ubuntu.com/ precise main universe deb http://ports.ubuntu.com/ precise-security main universe deb-src http://ports.ubuntu.com/ precise-security main universe deb http://ports.ubuntu.com/ precise-updates main universe deb-src http://ports.ubuntu.com/ precise-updates main universe schroot -c arm adduser tixy usermod -a -G sudo tixy # As above doesn't seem to work, edit /etc/sudoes to add tixyALL=(ALL:ALL) ALL exit exit # Any time you want to enter the chroot do schroot -c arm OK, so the qemu is actually static. That probably solves the problem I had with it a few years ago. Where does anything tell the system to use qemu to run stiff? I could understand if binmisc was setup for it, but I see nothing that should make it get used. Magic? ;-) Something in the packaging of binfmt-support and/or qemu-user-static? I was just following instructions I picked up on the web. I can assure you the work because I had a disk crash a while back and did a system re-install including following these instructions to setup my ARM chroot again. (That's one of the reasons I write my own crib sheets when I do a task like this :-) -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337927699.2953.7.ca...@computer2.home
Re: armel qualification for Wheezy
On Wed, May 23, 2012 at 09:02:33PM +0100, Tixy wrote: I may be being naive, but could an X86 PC be used with an ARM chroot and qemu-arm-static to emulate ARM instructions? Or is qemu not stable enough, or the emulated environment different enough that package building would fail (e.g. through use of uname)? It has been discussed before. Qemu linux-user is generally stable enough these days as long as package being built doesn't try to anything fancy (eg. run testsuites). That said when you hit problems, 1) they might slip under the radar and users end up hitting them much later 2) debugging and fixing them might be timeconsuming - we still have deadlocks in qemu threading code which have been hunted for years. So ideally I'd prefer ARM hardware targetted for servers - where the current memory and IO bandwidth issues wouldn't be the problem it is in the current mobile-targetted hardware. Riku -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120525065327.ga11...@afflict.kos.to
Re: armel qualification for Wheezy
On Fri, May 25, 2012 at 07:34:59AM +0100, Tixy wrote: Magic? ;-) Something in the packaging of binfmt-support and/or qemu-user-static? I was just following instructions I picked up on the web. I can assure you the work because I had a disk crash a while back and did a system re-install including following these instructions to setup my ARM chroot again. (That's one of the reasons I write my own crib sheets when I do a task like this :-) Ah package magic. I like package magic. Better than having to do it myself. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120525162324.gh32...@csclub.uwaterloo.ca
Re: armel qualification for Wheezy
On Wed, 2012-05-23 at 17:45 -0400, Lennart Sorensen wrote: On Wed, May 23, 2012 at 09:02:33PM +0100, Tixy wrote: I may be being naive, but could an X86 PC be used with an ARM chroot and qemu-arm-static to emulate ARM instructions? Or is qemu not stable enough, or the emulated environment different enough that package building would fail (e.g. through use of uname)? It is _horribly_ slow. Not that horrible. I just did a kernel build on my laptop in an ARM chroot and it took 19m43s, doing it as a cross-build took 1m14s. I haven't got my Pandaboard setup to do a comparison, but I suspect it wouldn't be much faster than my emulated ARM run. PCs have the advantage of RAM (assuming QEMU can handle 2GB+), fast hardware and multiple cores. Yes, but qemu doesn't really use more than one cpu, can't (last I checked) emulate more than one cpu core, and since it is emulating is rather slow (although it is fast as emulators go). I'm not talking about using QEMU as a system emulator, just an instruction set emulator. So ARM processes are running and scheduled as native X86 PC processes, just using QEMU to interpret the instructions in ARM ELF files. (There may be other magic going on, all I really know about QEMU is how to make use of it following cut'n'paste instruction from the web). In the kernel building example I mentioned I was using make -j8 and that went a _lot_ faster than -j1; I didn't wait to get final timings for a single threaded build. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337846397.2859.4.ca...@computer2.home
Re: armel qualification for Wheezy
On Thu, May 24, 2012 at 08:59:57AM +0100, Tixy wrote: Not that horrible. I just did a kernel build on my laptop in an ARM chroot and it took 19m43s, doing it as a cross-build took 1m14s. I haven't got my Pandaboard setup to do a comparison, but I suspect it wouldn't be much faster than my emulated ARM run. Well complete system emulation is very very slow, which is what I have used in qemu. I had forgotten it did the instruction emulation only as well. I'm not talking about using QEMU as a system emulator, just an instruction set emulator. So ARM processes are running and scheduled as native X86 PC processes, just using QEMU to interpret the instructions in ARM ELF files. (There may be other magic going on, all I really know about QEMU is how to make use of it following cut'n'paste instruction from the web). That would probably be faster. I haven't tried that method. In the kernel building example I mentioned I was using make -j8 and that went a _lot_ faster than -j1; I didn't wait to get final timings for a single threaded build. OK, using the instruction emulation, then you could do that. That's a pretty good idea. I will have to play with that some more some time. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120524150630.gf32...@csclub.uwaterloo.ca
Re: armel qualification for Wheezy
Tixy wrote: [...] Not that horrible. I just did a kernel build on my laptop in an ARM chroot and it took 19m43s, doing it as a cross-build took 1m14s. I haven't got my Pandaboard setup to do a comparison, but I suspect it wouldn't be much faster than my emulated ARM run. I'm interested to see you say this, because on an 1GHz Cortex A8 with about 400MB of RAM, a 3.0 kernel build takes me about two hours! (uImage and modules.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ Parents let children ride bicycles on the street. But parents do not │ allow children to hear vulgar words. Therefore we can deduce that │ cursing is more dangerous than being hit by a car. --- Scott Adams signature.asc Description: OpenPGP digital signature
Re: armel qualification for Wheezy
On Thu, May 24, 2012 at 11:06:30AM -0400, wrote: On Thu, May 24, 2012 at 08:59:57AM +0100, Tixy wrote: Not that horrible. I just did a kernel build on my laptop in an ARM chroot and it took 19m43s, doing it as a cross-build took 1m14s. I haven't got my Pandaboard setup to do a comparison, but I suspect it wouldn't be much faster than my emulated ARM run. Well complete system emulation is very very slow, which is what I have used in qemu. I had forgotten it did the instruction emulation only as well. I'm not talking about using QEMU as a system emulator, just an instruction set emulator. So ARM processes are running and scheduled as native X86 PC processes, just using QEMU to interpret the instructions in ARM ELF files. (There may be other magic going on, all I really know about QEMU is how to make use of it following cut'n'paste instruction from the web). That would probably be faster. I haven't tried that method. In the kernel building example I mentioned I was using make -j8 and that went a _lot_ faster than -j1; I didn't wait to get final timings for a single threaded build. OK, using the instruction emulation, then you could do that. That's a pretty good idea. I will have to play with that some more some time. How are you doing the build using qemu's cpu emulator? I remember last I played with it I had issues with shared libraries where the command i wanted to run needed to find its shared libraries, but if I set the LD_LIBRARY_PATH, then qemu tried to use the other CPUs libraries and wouldn't run. Has this been fixed somehow? Static binaries were fine of course. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120524162253.ga2...@csclub.uwaterloo.ca
Re: armel qualification for Wheezy
On Thu, 2012-05-24 at 12:22 -0400, Lennart Sorensen wrote: How are you doing the build using qemu's cpu emulator? I remember last I played with it I had issues with shared libraries where the command i wanted to run needed to find its shared libraries, but if I set the LD_LIBRARY_PATH, then qemu tried to use the other CPUs libraries and wouldn't run. Has this been fixed somehow? Static binaries were fine of course. Here is the crib sheet I wrote when I set this up, it was on a Debian Wheezy system, but my ARM chroot contains Ubuntu Precise as that is what I am targeting in my day job. (Hopefully Debian will work too.) # in these instructions /arm is the directory where I installed my # chroot and tixy is my linux username, replace as appropriate... # # /data is where I have all my source code and other files so I add that # to schroot fstab below, do similar with directories where you have # files you want to access inside the chroot. (Note, home directories # are already available.) su apt-get install debootstrap qemu-user-static binfmt-support schroot debootstrap --foreign --arch=armhf --variant=buildd precise /arm \ http://ports.ubuntu.com/ubuntu-ports cp /usr/bin/qemu-arm-static /arm/usr/bin chroot /arm /debootstrap/debootstrap --second-stage exit # Add to /etc/schroot/schroot.conf [arm] description=ARM Chroot type=directory directory=/arm users=tixy groups=tixy root-groups=root aliases=default # Edit /etc/schroot/default/fstab to add /data /data nonerw,bind 0 0 /run/runnonerw,bind 0 0 # Edit /arm/etc/apt/sources.list to have deb http://ports.ubuntu.com/ precise main universe deb-src http://ports.ubuntu.com/ precise main universe deb http://ports.ubuntu.com/ precise-security main universe deb-src http://ports.ubuntu.com/ precise-security main universe deb http://ports.ubuntu.com/ precise-updates main universe deb-src http://ports.ubuntu.com/ precise-updates main universe schroot -c arm adduser tixy usermod -a -G sudo tixy # As above doesn't seem to work, edit /etc/sudoes to add tixyALL=(ALL:ALL) ALL exit exit # Any time you want to enter the chroot do schroot -c arm -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337883145.2945.12.ca...@computer2.home
Re: armel qualification for Wheezy
Where does anything tell the system to use qemu to run stiff? I could understand if binmisc was setup for it, but I see nothing that should make it get used AIUI the magic is supplied by binfmt-support and the debian qemu packages -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbeaafb.9090...@p10link.net
Re: armel qualification for Wheezy
I just found this: http://boundarydevices.com/products-2/sabre-lite-imx6-sbc/ Highlights of the platform include: o Quad-Core ARM Cortex A9 processor at 1GHz Nice :) o 1GByte of 64-bit wide DDR3 @ 532MHz This is better than the average arm board but it's the same as debian's current armhf buildds and lower than most of debian's current armel buildds. o Serial ATA 2.5 (SATA) at 3Gbps :) o Dual SD 3.0/SDXC card slots Pretty irrelevent for a buildd o PCIe port (1 lane) On a propietry connector so you'd need a weird adaptor to connect anything to it. o 10/100/Gb IEEE1588 Ethernet And importantly it's NOT usb based. o 3 High speed USB ports (2xHost, 1xOTG) Pretty irrelevent for a buildd $299, LEAD TIME IS CURRENTLY 4-6 WEEKS :/ A couple of other things I noticed: The manual seems to be really lacking. No instructions for loading an OS on there, acceptable input voltage range marked as TBD. Finally I notice that the serial connections are on a tiny connector and they don't seem to sell a breakout cable for it (I also suspect it's logic level serial and not RS-232 though the manual isn't clear on that). -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbd3091.1040...@p10link.net
Re: armel qualification for Wheezy
peter green wrote (ao): I just found this: http://boundarydevices.com/products-2/sabre-lite-imx6-sbc/ Highlights of the platform include: o Quad-Core ARM Cortex A9 processor at 1GHz Nice :) o 1GByte of 64-bit wide DDR3 @ 532MHz This is better than the average arm board but it's the same as debian's current armhf buildds and lower than most of debian's current armel buildds. o 10/100/Gb IEEE1588 Ethernet And importantly it's NOT usb based. Exactly. $299, LEAD TIME IS CURRENTLY 4-6 WEEKS :/ A couple of other things I noticed: The manual seems to be really lacking. No instructions for loading an OS on there Here are some instructions: https://wiki.linaro.org/Boards/MX6QSabreLite Note the ethernet issue at the bottom of that page, which requires a hardware mod atm. While we're on it, keep an eye on this topic: http://www.powerdeveloper.org/forums/viewtopic.php?t=2226 Efika i.MX 61 Project Update And Samsung is rumored to come with a tablet (and a chromebook?) based on the Exynos 5250 2GHz dual core Cortex A15 at the very end of this year, or early 2013. Maybe Android can be replaced on those. Sander -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120523200036.GA10618@panda
Re: armel qualification for Wheezy
On Mon, 2012-05-21 at 17:15 +0300, Riku Voipio wrote: If we really want to replace ancina quickly, we could get some i.mx53 quick start boards like the ones currently used as armhf buildd's. I'd like not to introduce new hardware models as buildd's unless they are significantly faster as the old ones. I may be being naive, but could an X86 PC be used with an ARM chroot and qemu-arm-static to emulate ARM instructions? Or is qemu not stable enough, or the emulated environment different enough that package building would fail (e.g. through use of uname)? PCs have the advantage of RAM (assuming QEMU can handle 2GB+), fast hardware and multiple cores. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337803353.2862.7.ca...@computer2.home
Re: armel qualification for Wheezy
W dniu 23.05.2012 22:02, Tixy pisze: On Mon, 2012-05-21 at 17:15 +0300, Riku Voipio wrote: If we really want to replace ancina quickly, we could get some i.mx53 quick start boards like the ones currently used as armhf buildd's. I'd like not to introduce new hardware models as buildd's unless they are significantly faster as the old ones. I may be being naive, but could an X86 PC be used with an ARM chroot and qemu-arm-static to emulate ARM instructions? Or is qemu not stable enough, or the emulated environment different enough that package building would fail (e.g. through use of uname)? I do not know how it looks now but in past qemu did not emulated unaligned memory access which were not possible on armv5 hardware - so you could have binaries which work in qemu but fail on real hw. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbd4356.8020...@linaro.org
Re: armel qualification for Wheezy
On Wed, May 23, 2012 at 09:02:33PM +0100, Tixy wrote: I may be being naive, but could an X86 PC be used with an ARM chroot and qemu-arm-static to emulate ARM instructions? Or is qemu not stable enough, or the emulated environment different enough that package building would fail (e.g. through use of uname)? It is _horribly_ slow. PCs have the advantage of RAM (assuming QEMU can handle 2GB+), fast hardware and multiple cores. Yes, but qemu doesn't really use more than one cpu, can't (last I checked) emulate more than one cpu core, and since it is emulating is rather slow (although it is fast as emulators go). -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120523214527.gc32...@csclub.uwaterloo.ca
Re: armel qualification for Wheezy
On Mon, 2012-05-21 at 16:39 +0100, Steve McIntyre wrote: Then again, the imx53s are not as stable as I had hoped. Of the 9 I set up, 1 is just about dead and another is dying. They're also really unhappy with the pl2303 USB serial adapters I've got, which is a PITA. I've always had trouble with Prolific serial adaptors but FTDI based ones have always worked a treat on my ARM boards and PCs. Now I've found a convenient source for those [1] I stick with them. -- Tixy [1] http://www.usbnow.co.uk/p48/USB_to_RS232_with_FTDI_Chipset_(1.8M_Cable)/product_info.html -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337674594.2845.5.ca...@computer2.home
Re: armel qualification for Wheezy
On Mon, May 21, 2012 at 04:39:04PM +0100, Steve McIntyre wrote: Then again, the imx53s are not as stable as I had hoped. Of the 9 I set up, 1 is just about dead and another is dying. They're also really unhappy with the pl2303 USB serial adapters I've got, which is a PITA. Yes pl2303's are just crap. If possible find a FTDI based serial adapter. Unfortunately most that are easy to find use the crappy pl2303 chip. They're in a bigger version of the mini-rack kit that the armhf machines live in; this was the inspiration for that setup. I didn't get a photo before I installed them, unfortunately. Imagine a double-height (i.e. 6U) version of what's in the photo at http://blog.einval.com/2011/09/05#armhf_buildds. It wouldn't be hard to set up something similar again, but almost definitely not worth it for just a single board. The new imx6 boards look like they might be helpful, but again they're designed as dev boards and I'm not sure of the exact specs for what we might be able to get hold of. Highbank is where I want to go, and I'm hoping to talk to some Calxeda folks next week in HK so I can pester them again for hardware... :-) Do they have imx6 dev boards now? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120522151414.ga32...@csclub.uwaterloo.ca
Re: armel qualification for Wheezy
On 05/19/2012 05:00 PM, Riku Voipio wrote: Hi, On Sat, May 19, 2012 at 10:57:03AM +0200, Luk Claes wrote: As everyone keeps claiming there is no armel buildd location redundancy, I don't have much motivation to keep ancina running. It's ignored anyway. Would you mind packaging ancina and posting it to another hosting location? IIRC Mark Hymers was interested and he already hosts a bunch of armhf buildd's. ancina is a developer's board, so what components should be in the shipping if we go that route? How long would it take to have better machines than ancina so it could just get fased out btw? On another note, the only reason ancina cannot get OOB access is because it's not rack mountable. We can easily provide OOB access for rack mountable things and probably could even provide more rackspace for Debian things (have to get that confimed though if it's something worth considering?). Cheers Luk -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb9f635.9050...@ugent.be
Re: armel qualification for Wheezy
On Mon, May 21, 2012 at 10:00:53AM +0200, Luk Claes wrote: ancina is a developer's board, so what components should be in the shipping if we go that route? The board, memory at least, hard drive would be great as it would save the pain of reinstall. The rest (PSU, cables) I think Steve and Mark can source if you have other uses for the ones currently in ancina. How long would it take to have better machines than ancina so it could just get fased out btw? Sigh, I year ago when armhf buildd's were being chosen, I was expecting to see significantly faster HW available by now. But things like ARM servers seem always to be at least half year in future... If we really want to replace ancina quickly, we could get some i.mx53 quick start boards like the ones currently used as armhf buildd's. I'd like not to introduce new hardware models as buildd's unless they are significantly faster as the old ones. On another note, the only reason ancina cannot get OOB access is because it's not rack mountable. We can easily provide OOB access for rack mountable things and probably could even provide more rackspace for Debian things (have to get that confimed though if it's something worth considering?). I think ancina should fit in a rack case just fine - Just can't be attached to standard ATX screw locations. I believe the mv78x00 boards like ancina at ARM are installed into a rack somehow. Steve knows details I think? Riku Riku -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521141541.gb22...@afflict.kos.to
Re: armel qualification for Wheezy
On Mon, May 21, 2012 at 05:15:41PM +0300, Riku Voipio wrote: On Mon, May 21, 2012 at 10:00:53AM +0200, Luk Claes wrote: ancina is a developer's board, so what components should be in the shipping if we go that route? The board, memory at least, hard drive would be great as it would save the pain of reinstall. The rest (PSU, cables) I think Steve and Mark can source if you have other uses for the ones currently in ancina. Yup, shouldn't be too hard. If we really want to replace ancina quickly, we could get some i.mx53 quick start boards like the ones currently used as armhf buildd's. I'd like not to introduce new hardware models as buildd's unless they are significantly faster as the old ones. ACK. Then again, the imx53s are not as stable as I had hoped. Of the 9 I set up, 1 is just about dead and another is dying. They're also really unhappy with the pl2303 USB serial adapters I've got, which is a PITA. On another note, the only reason ancina cannot get OOB access is because it's not rack mountable. We can easily provide OOB access for rack mountable things and probably could even provide more rackspace for Debian things (have to get that confimed though if it's something worth considering?). I think ancina should fit in a rack case just fine - Just can't be attached to standard ATX screw locations. I believe the mv78x00 boards like ancina at ARM are installed into a rack somehow. Steve knows details I think? They're in a bigger version of the mini-rack kit that the armhf machines live in; this was the inspiration for that setup. I didn't get a photo before I installed them, unfortunately. Imagine a double-height (i.e. 6U) version of what's in the photo at http://blog.einval.com/2011/09/05#armhf_buildds. It wouldn't be hard to set up something similar again, but almost definitely not worth it for just a single board. The new imx6 boards look like they might be helpful, but again they're designed as dev boards and I'm not sure of the exact specs for what we might be able to get hold of. Highbank is where I want to go, and I'm hoping to talk to some Calxeda folks next week in HK so I can pester them again for hardware... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521153904.gb5...@einval.com
Re: armel qualification for Wheezy
On Thu, 17 May 2012, Steve McIntyre wrote: On Thu, May 17, 2012 at 06:00:18AM +0100, Adam Barratt wrote: On Thu, 2012-05-17 at 00:59 +0100, peter green wrote: The statement that all but one armel buildd is at the same location disagrees with the debian machines database. [...] Metropolitan Area Network Darmstadt : arcadelt DG-i: argento They may still be physically located there, but: wanna-build= select username, max(last_seen) as last_seen from armel.users group by username having username like '%arcadelt' or username like '%argento' order by 2; username|last_seen ---+ buildd_armel-arcadelt | 2011-04-17 21:14:11.291825 buildd_armel-argento | 2011-10-23 00:12:31.850723 (2 rows) iirc they're only still hosted in case e.g. the ARM hosting falls over for a prolonged period, but I'm happy to be corrected on that. AFAIK it's something like that, yes. Again, we're expecting to add more v7 machines to the cluster in York soon-ish to help with this. We (DSA) have been told by the buildd people to kill argento and arcadelt. We just haven't gotten around to doing it yet. So effectively armel does not have buildd location redundancy. cf. RT#3490, RT#3694, RT#3699. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519082812.gp1...@anguilla.noreply.org
Re: armel qualification for Wheezy
Hi As everyone keeps claiming there is no armel buildd location redundancy, I don't have much motivation to keep ancina running. It's ignored anyway. Cheers Luk On 05/19/2012 10:28 AM, Peter Palfrader wrote: On Thu, 17 May 2012, Steve McIntyre wrote: On Thu, May 17, 2012 at 06:00:18AM +0100, Adam Barratt wrote: On Thu, 2012-05-17 at 00:59 +0100, peter green wrote: The statement that all but one armel buildd is at the same location disagrees with the debian machines database. [...] Metropolitan Area Network Darmstadt : arcadelt DG-i: argento They may still be physically located there, but: wanna-build= select username, max(last_seen) as last_seen from armel.users group by username having username like '%arcadelt' or username like '%argento' order by 2; username|last_seen ---+ buildd_armel-arcadelt | 2011-04-17 21:14:11.291825 buildd_armel-argento | 2011-10-23 00:12:31.850723 (2 rows) iirc they're only still hosted in case e.g. the ARM hosting falls over for a prolonged period, but I'm happy to be corrected on that. AFAIK it's something like that, yes. Again, we're expecting to add more v7 machines to the cluster in York soon-ish to help with this. We (DSA) have been told by the buildd people to kill argento and arcadelt. We just haven't gotten around to doing it yet. So effectively armel does not have buildd location redundancy. cf. RT#3490, RT#3694, RT#3699. Cheers, -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb7605f.7040...@debian.org
Re: armel qualification for Wheezy
On Sat, 19 May 2012, Luk Claes wrote: As everyone keeps claiming there is no armel buildd location redundancy, I don't have much motivation to keep ancina running. It's ignored anyway. It's been down for a week or longer now. I sent you email, you didn't answer. We have no out of band management, no serial console, no remote power. And even if it worked, it alone would not be able to keep up. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519090130.gt1...@anguilla.noreply.org
Re: armel qualification for Wheezy
* Peter Palfrader (wea...@debian.org) [120519 11:18]: On Sat, 19 May 2012, Luk Claes wrote: As everyone keeps claiming there is no armel buildd location redundancy, I don't have much motivation to keep ancina running. It's ignored anyway. It's been down for a week or longer now. I sent you email, you didn't answer. We have no out of band management, no serial console, no remote power. And even if it worked, it alone would not be able to keep up. Looking at stats now, it seems that armel doesn't behave better than mipsel currently. If however both arches have a buildd down, that would fit. Andi -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519092828.gd2...@mails.so.argh.org
Re: armel qualification for Wheezy
Hello Luk, 2012/5/19 Luk Claes l...@debian.org: As everyone keeps claiming there is no armel buildd location redundancy, I don't have much motivation to keep ancina running. It's ignored anyway. I sent you an email about it as well, ancina is doing d-i armel builds and currently armel is lagging a bit behind, we (armel buildd maintainers) would like to get the machine back to its builds unless there is some major reason for not doing that. Regarding redundancy, I think its something armel porters could work on, and Steve has said many times, he is planning to add armel buildds to the York cluster as soon as time allows. And if the worst happens, I am pretty sure Debian project is able to acquire ARM buildds easily as well as Debian developers interested on ARM might have enough machines to keep up with the builds. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAODfWeESmoRFV8bjHUd1-1_dZ=g0g1xmjsgxvaeqcv-kgca...@mail.gmail.com
Re: armel qualification for Wheezy
On Sat, May 19, 2012 at 10:57:03AM +0200, Luk Claes wrote: As everyone keeps claiming there is no armel buildd location redundancy, I don't have much motivation to keep ancina running. It's ignored anyway. buildd location redundancy involves having enough capacity to deal with security updates and other urgent updates. One armel buildd alone is a tad on the fringe of keeping up with that. (One fast s390 box for example, can basically keep up for that use case, even if it's not able to keep up with two architectures, s390 and s390x, both having unstable.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: armel qualification for Wheezy
Hi, On Sat, May 19, 2012 at 10:57:03AM +0200, Luk Claes wrote: As everyone keeps claiming there is no armel buildd location redundancy, I don't have much motivation to keep ancina running. It's ignored anyway. Would you mind packaging ancina and posting it to another hosting location? IIRC Mark Hymers was interested and he already hosts a bunch of armhf buildd's. Riku -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519150024.ga12...@afflict.kos.to
Re: armel qualification for Wheezy
On Thu, May 17, 2012 at 06:00:18AM +0100, Adam Barratt wrote: On Thu, 2012-05-17 at 00:59 +0100, peter green wrote: The statement that all but one armel buildd is at the same location disagrees with the debian machines database. [...] Metropolitan Area Network Darmstadt : arcadelt DG-i: argento They may still be physically located there, but: wanna-build= select username, max(last_seen) as last_seen from armel.users group by username having username like '%arcadelt' or username like '%argento' order by 2; username|last_seen ---+ buildd_armel-arcadelt | 2011-04-17 21:14:11.291825 buildd_armel-argento | 2011-10-23 00:12:31.850723 (2 rows) iirc they're only still hosted in case e.g. the ARM hosting falls over for a prolonged period, but I'm happy to be corrected on that. AFAIK it's something like that, yes. Again, we're expecting to add more v7 machines to the cluster in York soon-ish to help with this. -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120517121833.ga9...@einval.com
armel qualification for Wheezy
Hi, With the sound of the ever approaching freeze ringing loudly in our ears, we're (somewhat belatedly) looking at finalising the list of release architectures for the Wheezy release. Comments on / additions and corrections to the content of http://release.debian.org/wheezy/arch_qualify.html would be appreciated, as would any other information you think is relevant to helping us determine armel's status for the release. Regards, Adam pp the Release Team -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sudck-00057f...@kaa.jungle.funky-badger.org
Re: armel qualification for Wheezy
Comments on / additions and corrections to the content of http://release.debian.org/wheezy/arch_qualify.html would be appreciated, as would any other information you think is relevant to helping us determine armel's status for the release. The statement that all but one armel buildd is at the same location disagrees with the debian machines database. That claims arm ltd: alain, alwyn, arne, arnold Universiteit Gent: ancina Metropolitan Area Network Darmstadt : arcadelt DG-i: argento More worryingly all the armel buildds outside of arm are listed as only having 512mb of ram. Can anyone confirm if the information in the machines database is correct? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb43f50.1040...@p10link.net
Re: armel qualification for Wheezy
On Thu, 2012-05-17 at 00:59 +0100, peter green wrote: The statement that all but one armel buildd is at the same location disagrees with the debian machines database. [...] Metropolitan Area Network Darmstadt : arcadelt DG-i: argento They may still be physically located there, but: wanna-build= select username, max(last_seen) as last_seen from armel.users group by username having username like '%arcadelt' or username like '%argento' order by 2; username|last_seen ---+ buildd_armel-arcadelt | 2011-04-17 21:14:11.291825 buildd_armel-argento | 2011-10-23 00:12:31.850723 (2 rows) iirc they're only still hosted in case e.g. the ARM hosting falls over for a prolonged period, but I'm happy to be corrected on that. Regards, Adam -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337230818.28758.2.ca...@jacala.jungle.funky-badger.org
