Re: AArch64 planning BoF at DebConf
On Sat, Jul 21, 2012 at 02:12:41AM +0100, Wookey wrote: > tools POV). The one _good_ reason for using the aarch64 name is avoiding > accidental matches with arm* in various bits of configery so leaving > that alone probably makes sense despite the silly name. How much of the arm* silliness is there actually? There's already quite significant changes between various arm sub-architectures, so matching on arm* can already be considered a bad idea. -- I wrote a book on personal productivity: http://gtdfh.branchable.com/ signature.asc Description: Digital signature
Re: AArch64 planning BoF at DebConf
On Fri, Jul 20, 2012 at 4:12 PM, Steve McIntyre wrote: > [ Please note the cross-post and Reply-To ] noted :) > I'm hoping to get AArch64 bootstrapped and ready for release in Debian > by Wheezy+1, which I acknowledge will take a lot of work in a > comparatively short space of time. We will need to cross-bootstrap as > much as possible, verifying things in the model. Existing bootstrap > work done by Wookey and co. will help a lot here. *scratches head*... um... gah, this is awkward. where do i begin. ok, cast your minds back to when, to begin the armhf port, konstantinous was having a hell of a job getting beyond the circular build dependencies (within even the core packages) that have crept into the debian packaging. not the install dependencies of the core packages, which are known to be circular, but the *build* dependencies. worst-case example: if you want to build a new version of a package, you have to have the old one's header file package installed. but to build that one, you need the previous... and so on, eventually getting back possibly several *years* to a time when that circular build dependency didn't exist, but of course the source code for those older packages and *their* build dependencies could possibly now no longer exist (especially if the cross-over point was isolated in between debian major releases) if you recall, i asked konstantinous if he could best document all of the circular build dependencies that he had encountered, so that the issues that he had encountered could be addressed, or the work-arounds that he created could be duplicated in future, possibly in an automated fashion. he declined to do so, unfortunately. also, a number of people, if i recall, mentioned words to the effect of "new architectures don't come along that often, so don't worry about it". @begin awkward embarrassing moment, feel free to gloss over i also made some recommendations and offered to knock together a build infrastructure which would have augmented the existing debian build system, (which would have leveraged the best free software cross-compiling and qemu-compile-enabled toolchain that there is, and made it debian-aware) but the recommendations were, sadly, viewed as - once again - "oo the fuck's this lkcl telling us what the fuck to do, we've been doing this for years, oo der fuck does ee fink ee is, trying to take over debian, let's vilify him, deliberately misunderstand what he's saying as much as we can as often as we can, make him look a fool so we look good and he'll go away ahhh that's better: we can go back to doing it our way, now, and stay in control ye" rather than being viewed as what they were offered as: an augmentation of and an enhancement of the existing debian build system, offered *without* prejudice and entirely in good faith. @end awkward moment. *rueful*. so, anyway. *shakes head to clear the air*. here we are, only 18 months later, and there's *another* architecture already on the horizon (*1)! whilst this is fantastic news, and very very exciting, i really don't know whether to laugh or cry in sympathy at the task ahead for the key debian developers, especially you, wookey. i just hope that there's some trick that can be pulled, here - something like starting up with an arm64 kernel but running pure 32-bit packages, then being able compile one-by-one each package as well as its 32-bit mapping in /usr/lib64, instead of having to do a complete total laborious "everything-in-one-go" hacked-together bootstrap like konstantinous had to. i'm sure i saw a procedure somewhere, dating back to 2005, which allowed a live 32-bit i386 debian system to be upgraded (without a total reinstall!) live to an amd64 one, but... yeah, iii don't believe it involved having to build every single amd64 package first :) well - good luck: i'm rooting for ya! things are just moving so fast in the ARM world, it's amazing. l. (*1) ... and what happens when there's an arm64 armv9 or armv10 or... arm64-die-hard-with-a-vengeance-float, such that *another* architecture is needed? what happens if the gnu/hurd team get some resources together and want to do an arm-hurd *and* an arm64-hurd architecture? what will it take to make the task of creating new architectures that much easier than it is right now? -- 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/CAPweEDwyzNKmiMUP8GXZR4pQ3wy=t0xr2eyvnhw-8retzpj...@mail.gmail.com
Re: AArch64 planning BoF at DebConf
On Sat, 21 Jul 2012, Wookey wrote: > Arm64 everywhere would have been neater but unless someone is > volunteering for a massive argument and changing upstream gcc and No way. it is difficult to do better at this kind of thing than Linus, and he has already said his piece :-p It won't be aarch64 in the kernel either, AFAIK. > changing it for a while, but have been persuaded, not by ARM, I hasten > to add :-) that we have more important things to do with our time than > bikeshed about upstream's funny naming, which does at least have the > major benefit of being a unique string.) Yeah, but it did make the world a bit uglier. Oh well. It could be worse, it could be an iArm, or an iLeg, instead of an aarch ;-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120721014422.ga2...@khazad-dum.debian.net
Re: arm vfp variants, allowed instructions
peter green wrote: Does anyone know of a document summarising what floating point instructions are in what version of vfp? Answering my own question I found a document linked from the vfp comparision page on the debian wiki. -- 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/500a0818.4090...@p10link.net
Re: modern cheap NAS fully supported by Debian?
+++ Nicola Bernardini [2012-07-20 05:42 +0200]: > > I gave up on my NSLU 2 which seems irremediably broken (my guess is that > the RAM is botched) and I would like to buy another NAS in that price > range or whereabouts. And of course, I would like to be able to run a > full Debian system on it. Debian Squeeze would be fine, but I can > install Woody if need be. What do you think is a good buy? The solidrun Cubox is nice hardware: http://www.solid-run.com/products/cubox/ Available new for $140, with real SATA (external drive) and world-class tiny. Non-free Vivante GPU could be annoying for media purposes but irrelvant for NAS-type activities. 1Gb RAM will be an enjoyable step up from the 32MB of a SLUG :-) - Should keep you going for quite a few years. I've seen one running Ubuntu already so Debian should be fine, but I think at this moment in time you'll need to use a non-stock kernel: http://www.solid-run.com/mw/index.php/Debian_on_CuBox I'd expect that to get fixed reasonably quickly. Others have given plenty of sensible options - it seems we are spoiled for choice these days. If someone wanted to summarise this lot somewhere on the Debian Wiki, that would be useful. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.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/20120721013717.gq26...@dream.aleph1.co.uk
Re: ARM port(s) BoF at DebConf
+++ Luke Kenneth Casson Leighton [2012-07-20 21:27 +0100]: > On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane wrote: > > As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. > > It has 2GB RAM, reliable production use and we can buy it NOW. > > > > *) http://lists.debian.org/debian-arm/2012/07/msg7.html > > hideki, those look superb. I saw one at debconf and it is indeed really nice mini-server hardware in a proper box and everything! Not easily rackable, but nicely stackable. The only catch seems to be the price on the spec sheet which is 79000 yen, which I make to be best part of 750 euro. I'm not sure they'll sell any at that price, so hopefully that'll change. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.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/20120721012207.gp26...@dream.aleph1.co.uk
Re: AArch64 planning BoF at DebConf
+++ Henrique de Moraes Holschuh [2012-07-20 16:55 -0300]: > On Fri, 20 Jul 2012, Steve McIntyre wrote: > > Naming > > == > > > > Naming issues: ARM are calling the new 64-bit architecture > > AArch64. Other people don't like that and various other names have > > been proposed for use elsewhere. Debian/Ubuntu developers have already > > picked the name "arm64" in dpkg and elsewhere. > > Maybe a patch should be sent to GNU config upstream so that arm64 > becomes known to config.sub and config.guess as an alias for aarch64? That's not necessary, because dpkg (-architecture) does the necessary conversions between 'debian arch name' and 'GNU arch/triplet names'. So autotools already has aarch64-linux-gnu and that works fine with Debian (in the same way that 'amd64' is 'x86_64-linux-gnu' from a GNU tools POV). The one _good_ reason for using the aarch64 name is avoiding accidental matches with arm* in various bits of configery so leaving that alone probably makes sense despite the silly name. Arm64 everywhere would have been neater but unless someone is volunteering for a massive argument and changing upstream gcc and glibc and autofoo and volunteering to fix up the configery that will break in numerous places it's best left well alone. (I was all for changing it for a while, but have been persuaded, not by ARM, I hasten to add :-) that we have more important things to do with our time than bikeshed about upstream's funny naming, which does at least have the major benefit of being a unique string.) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.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/20120721011240.go26...@dream.aleph1.co.uk
Re: ARM port(s) BoF at DebConf
On Fri, Jul 20, 2012 at 05:58:45PM -0400, Lennart Sorensen wrote: > > We've been pestered several times by toolchain developers and > > upstreams for various other projects that generate code for ARM > > (e.g. JITs in browsers). It seems that Debian is about the only place > > where anybody still cares about v4t any more, so we'll be the only > > people seeing bugs related to broken (or even missing) v4 support > > now. > > Even Debian moves on, dropping support for older platforms from time > > to time. We don't support actual i386 hardware any more, for example. > I remember Debian had a kernel patch to try and keep i386 going even > after glibc wanted to move to i486+ only. The kernel patch had a fatal security flaw which no one ever fixed. So this patch was never included in a stable release. (http://bugs.debian.org/250468) > So it was not by choice that Debian dropped i386. It was dropped by the unanimous decision of every developer in Debian to not fix the security bug in the i386 emulation patch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Arm-netbook] ARM port(s) BoF at DebConf
Hi,
I have a spec sheet to devices for English.
I ask whether this can be distributed.
Please wait.
Nobuhiro
2012/7/21 Dr. David Alan Gilbert :
> * Luke Kenneth Casson Leighton (l...@lkcl.net) wrote:
>> On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane wrote:
>> > Hi,
>> >
>> > On Thu, 19 Jul 2012 18:35:44 +0100
>> > Steve McIntyre wrote:
>> >> buildds
>> >> ===
>> >>
>> >> Both armel and armhf are doing well, covering ~96% of the archive. We
>> >> don't have any ARM server hardware yet, so we're stuck using
>> >> development boards as build machines. They work, but they're a PITA
>> >> for hosting and they're not designed for 24x7 usage like we're doing
>> >> so they're not that reliable.
>> >
>> > As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem.
>> > It has 2GB RAM, reliable production use and we can buy it NOW.
>> >
>> > *) http://lists.debian.org/debian-arm/2012/07/msg7.html
>>
>> hideki, those look superb. summarising (in case anyone's missed it):
>> they're armv7 compatible because they're using a marvell xp processor;
>> they're up to dual-core 1.4ghz and the company openblocks can do them
>> with up to 3gb of RAM, and i gather the openblocks boxes have a mini
>> pci-e port as well as gigabit ethernet.
>
> ftp://ftp.plathome.co.jp/pub/OBSAX3/Documents/OBSA_UsersGuide_1.0.0.pdf
>
> seems to be the (Japanese) user guide for it. Now, erm I don't know
> any Japanese at all, but there are lots of very pretty diagrams in there.
> But the picture on 4/24, and table 1.4 on section 6/24
> shows the OBSAX3/4/x with an Armada XP, 1.33GHz dual core,
> 1GB SDRAM, a SODIMM that takes 1 or 2GB (more??), SATA2, Mini PCIe,
> 4 () GigE, eSATA, 2xUSB2, and 2xRS-232C.
>
> Very nice! Pity it says available in japan only.
>
>> i'm including arm-netbooks because there may almost certainly be
>> people on that list who would be interested in a group buy. there has
>> been quite a bit of interest in getting hold of modular computing
>> devices for rack-mounted server usage.
>
> Dave
> --
> -Open up your eyes, open up your mind, open up your code ---
> / Dr. David Alan Gilbert| Running GNU/Linux | Happy \
> \ gro.gilbert @ treblig.org | | In Hex /
> \ _|_ http://www.treblig.org |___/
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/20120720222832.GA637@gallifrey
>
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
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/CABMQnVL9qt8_rsuFLNw_+Sp1Dp=guh2ph4drgi6qj+6qfwn...@mail.gmail.com
Re: [Arm-netbook] ARM port(s) BoF at DebConf
* Luke Kenneth Casson Leighton (l...@lkcl.net) wrote: > On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane wrote: > > Hi, > > > > On Thu, 19 Jul 2012 18:35:44 +0100 > > Steve McIntyre wrote: > >> buildds > >> === > >> > >> Both armel and armhf are doing well, covering ~96% of the archive. We > >> don't have any ARM server hardware yet, so we're stuck using > >> development boards as build machines. They work, but they're a PITA > >> for hosting and they're not designed for 24x7 usage like we're doing > >> so they're not that reliable. > > > > As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. > > It has 2GB RAM, reliable production use and we can buy it NOW. > > > > *) http://lists.debian.org/debian-arm/2012/07/msg7.html > > hideki, those look superb. summarising (in case anyone's missed it): > they're armv7 compatible because they're using a marvell xp processor; > they're up to dual-core 1.4ghz and the company openblocks can do them > with up to 3gb of RAM, and i gather the openblocks boxes have a mini > pci-e port as well as gigabit ethernet. ftp://ftp.plathome.co.jp/pub/OBSAX3/Documents/OBSA_UsersGuide_1.0.0.pdf seems to be the (Japanese) user guide for it. Now, erm I don't know any Japanese at all, but there are lots of very pretty diagrams in there. But the picture on 4/24, and table 1.4 on section 6/24 shows the OBSAX3/4/x with an Armada XP, 1.33GHz dual core, 1GB SDRAM, a SODIMM that takes 1 or 2GB (more??), SATA2, Mini PCIe, 4 () GigE, eSATA, 2xUSB2, and 2xRS-232C. Very nice! Pity it says available in japan only. > i'm including arm-netbooks because there may almost certainly be > people on that list who would be interested in a group buy. there has > been quite a bit of interest in getting hold of modular computing > devices for rack-mounted server usage. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _|_ http://www.treblig.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/20120720222832.GA637@gallifrey
Re: ARM port(s) BoF at DebConf
On Fri, Jul 20, 2012 at 09:21:59PM +0100, Steve McIntyre wrote: > Right. I've asked before who's still using v4t machines, and the > common response is "just openmoko". Thanks for mentioning others. > > We've been pestered several times by toolchain developers and > upstreams for various other projects that generate code for ARM > (e.g. JITs in browsers). It seems that Debian is about the only place > where anybody still cares about v4t any more, so we'll be the only > people seeing bugs related to broken (or even missing) v4 support > now. > > Even Debian moves on, dropping support for older platforms from time > to time. We don't support actual i386 hardware any more, for example. I remember Debian had a kernel patch to try and keep i386 going even after glibc wanted to move to i486+ only. So it was not by choice that Debian dropped i386. The lack of the atomic swap instruction seems to be what killed i386 support. > I've asked people for benchmarks to show the improvements (or lack of > them) that might come from a move to v5te. If there isn't a compelling > case for moving, we won't! Certainly no one seems able to state that there is any real advantage to v5te over v4. I don't have any v4 hardware myself, but I do sometimes play with v5te hardware, but mainly I care about the armhf on v7. I don't like to see old hardware die without good cause though. -- 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/20120720215845.gj19...@csclub.uwaterloo.ca
Re: ARM port(s) BoF at DebConf
On Fri, Jul 20, 2012 at 9:30 PM, Steve McIntyre wrote: > On Thu, Jul 19, 2012 at 08:09:53PM +0100, Luke Kenneth Casson Leighton wrote: >>On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre wrote: >> >>> Both armel and armhf are doing well, covering ~96% of the archive. We >>> don't have any ARM server hardware yet, so we're stuck using >>> development boards as build machines. They work, but they're a PITA >>> for hosting and they're not designed for 24x7 usage like we're doing >>> so they're not that reliable. >> >> there was a post on the arm-netbook mailing list about a 7W quad-core >>tegra3-based mini ITX motherboard which could take up to 2gb of RAM. >>whether it's the usual >>"let's-put-something-out-there-see-if-anyone-is-actually-interested" >>style of vapourware or actual reality i'd strongly suggest someone >>gets onto them and considers putting together a group buy / bulk order >>just to make it worthwhile their time making a batch, because it's >>literally the first ARM-based machine i've ever heard about that can >>actually take 2gb of RAM. >> >> oh: also the motherboards have eSATA and uPCI-e, hm let me find the >>post here you go: >> >> http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-July/005127.html > > Cool, sounds interesting maybe... But what's the rest of the system > like? Is it supported already in the kernel, etc.? We really want to > get standard machines where possible. judging by this phoronix article (*1), it looks like nvidia has been creating ubuntu 12.04 images at least for their dev-kits for quite some time. so whether it's mainlined on kernel.org is anyone's guess; chances are the kontron board will run with ubuntu and at least be convertible to debian with minimum pain by one person, and then zero pain by everyone else thereafter. aughh, kontron have finally twigged that maybe it's a good idea to put the actual, like, y'know, availability status? on a page (*2)? and yippee, it says "coming soon exclamation-mark". *sigh*... yet another board to have to wait for [except those openblocks A6 and AX3 ones - thank you for finding those, hideki] >> [... rambling stuff about debug builds...] > That's interesting, but we don't want to be doing non-standard builds > for one architecture. That's not the way we do things in Debian... eyy i didn't say it'd be "standard" :) but then, having debug c++ builds run for 18+ hours and jamming everything else up isn't exactly standard either, neh? /peace. l. (*1) http://www.phoronix.com/scan.php?page=news_item&px=MTA3MjQ (*2) http://us.kontron.com/products/boards+and+mezzanines/embedded+motherboards/miniitx+motherboards/ktt30mitx.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/CAPweEDyiB7M9pCZ_WpKoXet1=spaq5kkfk7tfkuqpxpphj3...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 08:09:53PM +0100, Luke Kenneth Casson Leighton wrote: >On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre wrote: > >> Both armel and armhf are doing well, covering ~96% of the archive. We >> don't have any ARM server hardware yet, so we're stuck using >> development boards as build machines. They work, but they're a PITA >> for hosting and they're not designed for 24x7 usage like we're doing >> so they're not that reliable. > > there was a post on the arm-netbook mailing list about a 7W quad-core >tegra3-based mini ITX motherboard which could take up to 2gb of RAM. >whether it's the usual >"let's-put-something-out-there-see-if-anyone-is-actually-interested" >style of vapourware or actual reality i'd strongly suggest someone >gets onto them and considers putting together a group buy / bulk order >just to make it worthwhile their time making a batch, because it's >literally the first ARM-based machine i've ever heard about that can >actually take 2gb of RAM. > > oh: also the motherboards have eSATA and uPCI-e, hm let me find the >post here you go: > > http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-July/005127.html Cool, sounds interesting maybe... But what's the rest of the system like? Is it supported already in the kernel, etc.? We really want to get standard machines where possible. > btw, steve: it's not the c++ doing linking in swap that's the >problem, it's trying to do *debug* builds of c++ applications that's >the problem. webkit for example requires a minimum of 1.4gb of >resident RAM for the linker phase if you enable debug builds. i have >mentioned a number of times that it's debug builds that are the >problem, and that all you have to do is disable debugging (*1) and the >build will complete within 15 minutes instead of 15 hours, but as >usual because it's that "fucking moron lkcl telling us what the fuck >to do" nobody bothers to listen. well, keep on not listening for as >long as you (plural) find it useful to do so: i'm not the one with a >PITA for having to wait 18 hours for a debug build of a c++ app to >complete, am i, eh? *eyebrows-arched* That's interesting, but we don't want to be doing non-standard builds for one architecture. That's not the way we do things in Debian... >(*1) and if someone _really_ wants a debug build of that particular >problematic package, on a build and distro port that's still >experimental, well, surely they can compile it themselves, using their >own resources, yes? As Adam pointed out, it's far from experimental at this point. In terms of popularity, I'm expecting armhf to overtake most of the other ports once it's been released as stable with Wheezy. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth -- 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/20120720203025.gc...@einval.com
Re: ARM port(s) BoF at DebConf
On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane wrote: > Hi, > > On Thu, 19 Jul 2012 18:35:44 +0100 > Steve McIntyre wrote: >> buildds >> === >> >> Both armel and armhf are doing well, covering ~96% of the archive. We >> don't have any ARM server hardware yet, so we're stuck using >> development boards as build machines. They work, but they're a PITA >> for hosting and they're not designed for 24x7 usage like we're doing >> so they're not that reliable. > > As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. > It has 2GB RAM, reliable production use and we can buy it NOW. > > *) http://lists.debian.org/debian-arm/2012/07/msg7.html hideki, those look superb. summarising (in case anyone's missed it): they're armv7 compatible because they're using a marvell xp processor; they're up to dual-core 1.4ghz and the company openblocks can do them with up to 3gb of RAM, and i gather the openblocks boxes have a mini pci-e port as well as gigabit ethernet. i'm including arm-netbooks because there may almost certainly be people on that list who would be interested in a group buy. there has been quite a bit of interest in getting hold of modular computing devices for rack-mounted server usage. l. -- 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/CAPweEDxB=akchpidonavwvuon9xf0gge9cf2smyjrrgdm3+...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On Fri, Jul 20, 2012 at 10:08:03PM +0200, Martin Guy wrote: >On 19 July 2012 19:35, Steve McIntyre wrote: >> armel >> = >> >> First released with Lenny. Soft-float EABI, Software floating point >> assumed by default. v4t which also runs smaller-size thumb instruction >> set. Targeting old hardware like openmoko. Discussed (again!) moving >> forwards from v4. Declared that v5 is no faster than v4t, but there >> are doubts elsewhere in the community. Later discussion suggests >> moving to v5te would be worth it. Some good benchmarks would help - >> volunteers welcome! > >Actually, supporting less machines is a move backward, not forward. >The speed advantage for standard apps on v5+ machines is less than 1%, >i.e. negligable. > >Of course, I have a vested interest in continued armv4t support, since >my company has an armv4t board on the market that ships with Debian as >its standard distribution. It would also impact Technologic Systems, >Bluewater Systems and other small companies for similar reasons. Right. I've asked before who's still using v4t machines, and the common response is "just openmoko". Thanks for mentioning others. >Who is it that keeps bringing this up? I can see that ARM Ltd would >want this, as it would eliminate Linux distro support for devices from >which they no longer see any royalties., but I don't see any advantage >for anyone else except chronic speed freaks who would kill other >people's boards off to get a half of a percent faster for themselves. We've been pestered several times by toolchain developers and upstreams for various other projects that generate code for ARM (e.g. JITs in browsers). It seems that Debian is about the only place where anybody still cares about v4t any more, so we'll be the only people seeing bugs related to broken (or even missing) v4 support now. >If somebody has a critical need to multiple two shorts with result as >a long in a single instruction (which is what the E in 5TE brings), >surely they can compile their own armel packages changing the cpu >type, rather than making Debian do that and breaking other people's >systems needlessly? > >Isn't Debian supposed to be the "Universal Operating System", where >"Universal" includes running on as many different computers as >possible? Even Debian moves on, dropping support for older platforms from time to time. We don't support actual i386 hardware any more, for example. >And the speed freaks can always build their own v5t and v5te >repositories and use those to install from, leaving everybody happy. I've asked people for benchmarks to show the improvements (or lack of them) that might come from a move to v5te. If there isn't a compelling case for moving, we won't! -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. -- 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/20120720202159.ga...@einval.com
Re: ARM port(s) BoF at DebConf
On Fri, 2012-07-20 at 22:08 +0200, Martin Guy wrote: > On 19 July 2012 19:35, Steve McIntyre wrote: > > armel > > = > > > > First released with Lenny. Soft-float EABI, Software floating point > > assumed by default. v4t which also runs smaller-size thumb instruction > > set. Targeting old hardware like openmoko. Discussed (again!) moving > > forwards from v4. Declared that v5 is no faster than v4t, but there > > are doubts elsewhere in the community. Later discussion suggests > > moving to v5te would be worth it. Some good benchmarks would help - > > volunteers welcome! Upstreams don't seem to care about armv4t anymore. http://code.google.com/p/v8/issues/detail?id=590 (reports in Debian are that this is not fixed, they are only testing with qemu, which cannot be used for this testing) > > Actually, supporting less machines is a move backward, not forward. > The speed advantage for standard apps on v5+ machines is less than 1%, > i.e. negligable. > > Of course, I have a vested interest in continued armv4t support, since > my company has an armv4t board on the market that ships with Debian as > its standard distribution. It would also impact Technologic Systems, > Bluewater Systems and other small companies for similar reasons. > > Who is it that keeps bringing this up? I can see that ARM Ltd would > want this, as it would eliminate Linux distro support for devices from > which they no longer see any royalties., but I don't see any advantage > for anyone else except chronic speed freaks who would kill other > people's boards off to get a half of a percent faster for themselves. > > If somebody has a critical need to multiple two shorts with result as > a long in a single instruction (which is what the E in 5TE brings), > surely they can compile their own armel packages changing the cpu > type, rather than making Debian do that and breaking other people's > systems needlessly? > > Isn't Debian supposed to be the "Universal Operating System", where > "Universal" includes running on as many different computers as > possible? > And the speed freaks can always build their own v5t and v5te > repositories and use those to install from, leaving everybody happy. > > M -- -Shawn Landden -- 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/1342815264.5910.151.camel@shawn-ssd
Re: ARM port(s) BoF at DebConf
Martin Guy writes: > Who is it that keeps bringing this up? At least chromium seems to get much more testing on v5 systems so we expose new bugs when we build it fo v4t. This probably applies to some other upstreams that use hand-written assembler or JIT. -- 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/844np2w5tg@sauna.l.org
Re: ARM port(s) BoF at DebConf
On 19 July 2012 19:35, Steve McIntyre wrote: > armel > = > > First released with Lenny. Soft-float EABI, Software floating point > assumed by default. v4t which also runs smaller-size thumb instruction > set. Targeting old hardware like openmoko. Discussed (again!) moving > forwards from v4. Declared that v5 is no faster than v4t, but there > are doubts elsewhere in the community. Later discussion suggests > moving to v5te would be worth it. Some good benchmarks would help - > volunteers welcome! Actually, supporting less machines is a move backward, not forward. The speed advantage for standard apps on v5+ machines is less than 1%, i.e. negligable. Of course, I have a vested interest in continued armv4t support, since my company has an armv4t board on the market that ships with Debian as its standard distribution. It would also impact Technologic Systems, Bluewater Systems and other small companies for similar reasons. Who is it that keeps bringing this up? I can see that ARM Ltd would want this, as it would eliminate Linux distro support for devices from which they no longer see any royalties., but I don't see any advantage for anyone else except chronic speed freaks who would kill other people's boards off to get a half of a percent faster for themselves. If somebody has a critical need to multiple two shorts with result as a long in a single instruction (which is what the E in 5TE brings), surely they can compile their own armel packages changing the cpu type, rather than making Debian do that and breaking other people's systems needlessly? Isn't Debian supposed to be the "Universal Operating System", where "Universal" includes running on as many different computers as possible? And the speed freaks can always build their own v5t and v5te repositories and use those to install from, leaving everybody happy. M -- 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/CAL4-wQqM-HGUo=zssjweon51i2t8ebsgtzfbopfb9ftl3eq...@mail.gmail.com
Re: AArch64 planning BoF at DebConf
On Fri, 20 Jul 2012, Steve McIntyre wrote: > Naming > == > > Naming issues: ARM are calling the new 64-bit architecture > AArch64. Other people don't like that and various other names have > been proposed for use elsewhere. Debian/Ubuntu developers have already > picked the name "arm64" in dpkg and elsewhere. Maybe a patch should be sent to GNU config upstream so that arm64 becomes known to config.sub and config.guess as an alias for aarch64? If the answer is yes, please do so ASAP and mail me as soon as you get a go from upstream, so that I can fold the change in autotools-dev and request a freeze exception to get the alias in Wheezy. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120720195514.ga6...@khazad-dum.debian.net
arm vfp variants, allowed instructions
Does anyone know of a document summarising what floating point instructions are in what version of vfp? -- 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/5009a9fb.4010...@p10link.net
Re: modern cheap NAS fully supported by Debian?
If you just want a simple and cheap NSLU2 replacement, have you thought about a RaspberryPi? With a simple cardboard case (see their forum), for a small amount you can use it as a NAS. Works fine for me ;-) Regards, Frank Op 20 jul. 2012 05:49 schreef "Nicola Bernardini" het volgende: > > Sorry list, I can imagine this question has been asked many times, but > the answer changes with time and browsing this list and related > resources I cannot find a sufficiently recent (let's say < 1 year) > answer to it. > > I gave up on my NSLU 2 which seems irremediably broken (my guess is that > the RAM is botched) and I would like to buy another NAS in that price > range or whereabouts. And of course, I would like to be able to run a > full Debian system on it. Debian Squeeze would be fine, but I can > install Woody if need be. What do you think is a good buy? To qualify > further my question, I was looking at something like the XTreamer ETrayz > http://www.xtreamer.net/etrayz/specs.aspx, but that machine is no longer > in production and I don't even know if Debian can be installed over it. > > Thank you for all your replies, > > nicb > > -- > Nicola Bernardini > e-mail: nic.b...@tiscali.it > http://www.nicolabernardini.info > GPG fingerprint = 6AE6 AF21 E160 D9B3 396E EBAC 906C CFAE 4D65 D910 > Neither MS-Word nor MS-PowerPoint attachments please. > > > -- > 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/20120720034229.GB6493@eeepc-1215B > >
RE: SS4000E Fan speed, LEDS and power button
Installed lm-sensors. sensors-detect detects the w83792d chip
root@Freestor:~# sensors
w83792d-i2c-0-2d
Adapter: IOP3xx-I2C
VcoreA: +1.28 V (min = +0.00 V, max = +2.04 V)
VcoreB: +0.00 V (min = +0.00 V, max = +2.04 V)
in2: +2.55 V (min = +0.00 V, max = +4.08 V)
in3: +3.30 V (min = +0.00 V, max = +4.08 V)
in4: +0.00 V (min = +0.00 V, max = +4.08 V)
in5: +1.99 V (min = +0.00 V, max = +4.08 V)
+5V: +4.92 V (min = +4.49 V, max = +5.50 V)
5VSB: +4.93 V (min = +4.49 V, max = +5.50 V)
Vbat: +0.00 V (min = +2.69 V, max = +3.30 V) ALARM
fan1: 0 RPM (min =0 RPM, div = 2)
fan2: 0 RPM (min =0 RPM, div = 2)
fan3: 0 RPM (min =0 RPM, div = 2)
fan4: 0 RPM (min =0 RPM, div = 2)
fan5: 0 RPM (min =0 RPM, div = 2)
temp1:+46.0°C (high = +127.0°C, hyst = +0.0°C)
temp2: +127.0°C (high = +80.0°C, hyst = +75.0°C) ALARM
temp3: +127.0°C (high = +80.0°C, hyst = +75.0°C) ALARM
All the fans are zero so presumably it's not reading the fan speed from the
chip.
root@Freestor:~# modprobe -l | grep 83792
kernel/drivers/hwmon/w83792d.ko
root@Freestor:~# modinfo w83792d
filename: /lib/modules/2.6.32-5-iop32x/kernel/drivers/hwmon/w83792d.ko
license:GPL
description:W83792AD/D driver for linux-2.6
author: Chunhao Huang @ Winbond
alias: i2c:w83792d
depends:
vermagic: 2.6.32-5-iop32x mod_unload modversions ARMv5
parm: force:List of adapter,address pairs to boldly assume to be
present (array of short)
parm: force_w83792d:List of adapter,address pairs which are
unquestionably assumed to contain a `w83792d' chip (array of short)
parm: probe:List of adapter,address pairs to scan additionally
(array of short)
parm: ignore:List of adapter,address pairs not to scan (array of
short)
parm: force_subclients:List of subclient addresses: {bus,
clientaddr, subclientaddr1, subclientaddr2} (array of short)
parm: init:Set to one to force chip initialization (bool)
CJW
-Original Message-
From: Arnaud Patard (Rtp) [mailto:arnaud.pat...@rtp-net.org]
Sent: Tuesday, July 17, 2012 3:44 PM
To: Chris Wilkinson
Cc: debian-arm@lists.debian.org
Subject: Re: SS4000E Fan speed, LEDS and power button
"Chris Wilkinson" writes:
Please note that I'm about to talk about em7210 so things may be different
on em7220.
> Has anyone succeeded to control the fan speed according to
> temperature,
the fan is handled by a w83792*.
> control the front panel LEDS and power off with the power button on this
> device?
The leds are handled by the f75111 chip from fintek. There's
a driver here http://git.rtp-net.org/?p=ss4000e.git;a=tree The needed
patches are :
f75111.patch
add_f75111_pdata.patch
em7210_add_missing_leds.patch
I'm using them on top of 3.4 for several weeks now.
For the buttons, there's em7210_add_gpio_keys.patch. It was relying on
custom gpio input driver but there's nowadays needed stuff in mainline.
>
> I built http://lm-sensors.org/ but it couldn't recognize any sensors.
>
> I also haven't been able to figure out how to set up 4 disks in a RAID5.
The
> d-I only prompted to install 1 disk. I can format/mount the other 3 and
but
> don't know how to create the 4-disk RAID.
RAID5 needs only 3 drives, so create the RAID5 on 3 drives and then add
the last one as spare.
Arnaud
--
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/004201cd6690$64aa7970$2dff6c50$@net
AArch64 planning BoF at DebConf
[ Please note the cross-post and Reply-To ] Hi folks, Here's a summary of what we discussed in the AArch64 port planning BoF [1] last week (10th July). Thanks to the awesome efforts of the DebConf video team, the video of the session is already online [2] in case you missed it. I've also attached the Gobby notes that were taken during the session. Again, thanks to the people who took part - we had a very useful discussion. Slides are up on my website [3]. Naming == Naming issues: ARM are calling the new 64-bit architecture AArch64. Other people don't like that and various other names have been proposed for use elsewhere. Debian/Ubuntu developers have already picked the name "arm64" in dpkg and elsewhere. ARMv8 summary = For more details, look at http://arm.com/architecture. Quick summary: * Carries over the ARMv7 feature set. * First 64bit ARM CPU, runs 32bit code too. * ARM Neon SIMD. * VFPv3 as from ARMv7. * Includes ARM proprietary security extensions. * Supports virtualisation and LPAE. New 64-bit (A64) instruction set * Fixed length 32-bit instructions. * 5 bits of register space -> 31 general purpose 64 bit registers. * SIMD 32x128bit registers * Better support for different FP modes * Improved atomic support * Neon required (believed, but confirm!) Roadmap === * ARMv7 will continue. Cortex-A9, Cortex-A15, Cortex-A7 etc. * ARMv8 under development. * Expect to see first v8 hardware late 2013 onwards, specs due later in 2012. Demo I showed an ARM "Fast Model" running AArch64 software: a Linux kernel (3.4) and an Ubuntu (Natty) based userland. The userland AArch64 software was all built using xdeb. Basic-ish LAMP stack for demonstration (as might be expected for a simple server workload): Apache, Postgres, Dropbear ssh, PHP. Not a *quick* machine to run things in, but fast enough for demonstration and verification. Also demonstrated a 32-bit armhf chroot: standard 32-bit software build as provided elsewhere in Debian/Ubuntu, no changes needed. AArch64 will happily run existing ARM software. Showed Xorg, xfce and firefox running. Bootstrapping = Kernel patches for AArch64 have just been sent upstream for comments on Friday 6th July[5]. The toolchain already works (as you can see from the demo). gcc patches are already in a branch upstream[4], binutils etc. coming shortly. People are currently cross-building small systems and testing in the model. ARM and Linaro are going to be helping by working on projects to aid bootstrapping: * Basic OpenEmbedded rootfs * Backporting toolchain changes into gcc 4.7 * Shared bug tracker at Linaro to help sharing issues and patches across distros I'm hoping to get AArch64 bootstrapped and ready for release in Debian by Wheezy+1, which I acknowledge will take a lot of work in a comparatively short space of time. We will need to cross-bootstrap as much as possible, verifying things in the model. Existing bootstrap work done by Wookey and co. will help a lot here. As soon as we can get access to hardware, start building natively and try and get into debian-ports. *If* we can get everything going well, into main archive ASAP after that. It's useful that ARMv8 will happily run existing armhf software, so we can run that as a base on systems for build machines etc. We've learnt the lesson from armhf bringup that using unstable to host buildds is painful! Because of multi-arch, we will also get to use 32-bit armhf software elsewhere where it's useful, e.g. 32-bit openjdk will run out of the box until we get a 64-bit version. Misc There's no support in qemu yet, but many people are interested in it for a variety of reasons. Once sufficient specs are released, I'd expect work to happen quickly. How to help === First things first: make sure your packages cross-build well, and make your Multi-Arch build-dependencies work. There are a lot of patches already in the BTS to help with these. Next: help make more of the archive work for automatic bootstrapping and cross-building. Once we can get hold of models and then hardware, help to test and verify more of the system. Fun places to get involved are language bootstraps - in many cases, the runtime / compiler for a language will be written *in* that language, so there's work to cross-bootstrap the first build and bring things up from there. Get involved on the debian-arm list (and elsewhere) and keep communicating about what you're working on and what you'd like to do. [1] http://penta.debconf.org/dc12_schedule/events/882.en.html [2] http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/high/882_AArch64_planning.ogv [3] http://www.einval.com/~steve/talks/Debconf12-aarch64/ [4] svn://gcc.gnu.org/gcc/branches/ARM/aarch64branch [5] http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/03025.html -- Steve McIntyre, Cambridge, UK.st...@einval.com You r
Re: modern cheap NAS fully supported by Debian?
Hi Martin, Is there any plan to support *officialy* the raidsonic IB 62x0 from IcyBox in Debian ? For now it is already supported by the denx uboot and will be in the next linux kernel. I have already one which runs debian squeeze with few tweaks. I'll soon upgrade another from the stock (fedora) firmware with a fresh install (uboot, debian and custom linux-next). May be it will be a good idea to engage a official support in debian ? How can I help ? -- 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/500940e7.5020...@doukki.net
Re: modern cheap NAS fully supported by Debian?
Nicola, On Fri, Jul 20, 2012 at 05:42:30AM +0200, Nicola Bernardini wrote: > [...] and I would like to buy another NAS in that price range or > whereabouts. And of course, I would like to be able to run a full > Debian system on it. Debian Squeeze would be fine, [...] > Thank you for all your replies, To be complete, perhaps should one mention that the Intel SS4000-E Nas Server is available on ebay in the USA, new without disks, for 125 $. The seller has 90 boxes available. SS4000-E isn't the fastest one (XScale 400 Mhz - it's even a bit slow localy in a LAN), and was an expensive bad joke with the original firmware, but with Debian on it (Squeeze runs fine) it works very well for things like remote backup through the net, were raw speed is not important. The hardware quality is of a good level and, while there is perhaps better choice, you can't go totaly wrong with this box at this price for a four bay nas. Hih, -- JFS. -- 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/20120720111600.ga4...@jones.jfs.dt
Re: SS4000E Fan speed, LEDS and power button
Chris, On Thu, Jul 19, 2012 at 09:41:27PM -0400, Chris Wilkinson wrote: > Thanks for the tips. Next I tried this and had some success but just > why this works escapes me. Well, it's Debian ;) > Loaded initird.gz, zimage > After each load, wrote the image to flash with fis create To make just a comment, IIUC what you are doing, I think that there is no need to write kernel/initrd on flash before booting (get them into RAM is sufficient). > Reboot > d-i starts but not in rescue mode (Normal : rescue/enable=true was not specified.) > ran thru install without incident. So, you did redo a full install. But why not since some bits was missing... > Only snag was that the RAID5 was not set as a root FS, so > backtracked to make it so. All the partitions set up previously were > intact. Normal ; they are written to disks. > d-i continued without further problem > reboot > NAS boots into debian OK. So it should work for now ; very good. It's simply because all the required steps to get an OS on the box have ben done, successfully and in the right order... So the box has no excuse to refuse starting anymore ;) Well, congrats and enjoy your new OS! A+ -- JFS. -- 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/20120720095503.ga5...@jones.jfs.dt
Re: modern cheap NAS fully supported by Debian?
* Nicola Bernardini [2012-07-20 05:42]: > I gave up on my NSLU 2 which seems irremediably broken (my guess is that If you want to replace a NSLU2, I recommend either a SheevaPlug or an eSATA SheevaPlug. They are both supported by Debian squeeze and wheezy: http://cyrius.com/debian/kirkwood/sheevaplug/ If you want a proper NAS that's supported by Debian, I suggest one of the QNAP devices: all TS-11x, TS-21x and TS-41x models are supported by Debian squeeze and wheezy: http://cyrius.com/debian/kirkwood/qnap/ -- Martin Michlmayr http://www.cyrius.com/ -- 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/20120720091706.gc27...@jirafa.cyrius.com
RE: modern cheap NAS fully supported by Debian?
> Sorry list, I can imagine this question has been asked many times, > but > the answer changes with time and browsing this list and > related > resources I cannot find a sufficiently recent (let's say < 1 > year) > answer to it. > > I gave up on my NSLU 2 which seems irremediably broken (my guess is > that > the RAM is botched) and I would like to buy another NAS in that > price > range or whereabouts. And of course, I would like to be able to run > a > full Debian system on it. Debian Squeeze would be fine, but I > can > install Woody if need be. What do you think is a good buy? To > qualify > further my question, I was looking at something like the XTreamer > ETrayz > http://www.xtreamer.net/etrayz/specs.aspx, but that machine is no > longer > in production and I don't even know if Debian can be installed over it. I would be Kirkwood all the way. I currently have a Netgear Stora, which is a Kirkwood device, with 2 internal 2.5" drive bays, only available used currently I think). It's a nice device. It only has 128MB RAM, which is OK for Squeeze (squeeze installer and instructions available at openstora.com), but seems to be tight for Wheezy. I am currently investigating the Zyxel NSA310 which has 256MB RAM and 1x 3.5" bay and an eSATA port, prices look reasonable (£70ish no drive, new). If you can make do with USB only an Iomega iConnect has 256MB RAM but again is only available used (I have one too). Easy to turn into an wireless AP too (internal mini-PCIe slot, which you could repurpose for SATA I suppose), again installer available at openstora.com . Paul -- 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/00a401cd664c$b8ba09c0$2a2e1d40$@co.uk
