Re: AArch64 planning BoF at DebConf
On Jul 21, 2012, at 04:10, Luke Kenneth Casson Leighton wrote: On Fri, Jul 20, 2012 at 4:12 PM, Steve McIntyre st...@einval.com wrote: 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. @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) I'm assuming you're talking about Yocto/OE/bitbake/poky -- can you confirm? 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. Pejorative poetry aside, I think there are some reasonable choices made by Debian with regards to the build system, particularly building directly on the hardware. Is there a case to be made that using qemu and cross-compiling is somehow better? What are the trade offs? Regards, Jeremiah -- 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/0b0089ec-5cc3-4bce-aee9-a2eaba676...@jeremiahfoster.com
Re: AArch64 planning BoF at DebConf
On Sat, Jul 21, 2012 at 07:47:01AM +0100, Lars Wirzenius wrote: 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. It's not clear how much out there *is* actually broken like this, to be honest. But it was one of the concerns raised about the new triplet for armhf, and for a totally new architecture people are/were very worried about the possibility of breakage. There is already historical precedent for breakage in triplet naming... -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer -- 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/20120723144742.gc27...@einval.com
Re: AArch64 planning BoF at DebConf
Lars Wirzenius wrote: How much of the arm* silliness is there actually? There's already quite significant changes between various arm sub-architectures, While there have been some changes they have been gradual and afacit it is possible to write inline assembler that will work on pretty much any arm linux system. Still some upstreams do the wrong thing (which reminds me, I need to go file a bug against gnuradio). Wheras AIUI from steeves talk aarch64 assembler will be totally incompatible with 32-bit arm assembler. So any build system that ends up treating aarch64 the same as 32-bit arm will almost certainly be doing the wrong thing. so matching on arm* can already be considered a bad idea. -- 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/500db696.3040...@p10link.net
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, 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
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: 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: AArch64 planning BoF at DebConf
On Fri, Jul 20, 2012 at 4:12 PM, Steve McIntyre st...@einval.com 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
