 OK. Well hello everyone for more multi-arch, I'll try and be more exciting this time round. So fortunately for me, Philip has just covered all the really boring technical stuff, so we don't need to do that again. I will try and talk about some slightly more less hardcore aspects of the problem. So there's a couple of things here, there's basically where we're at, what's going on. Philip's covered some of that, I've got a few more things to say, but also particularly if people have problems with their packages and would like to ask questions, this is an opportunity to do that. Unfortunately several of the clever people who know the answers have left, so please don't ask questions that are too difficult. It's quite late in the day and it's kind of stuffy. So first thing, simple point. As has been explained, the interpreter runtime stuff is a little bit tricky. It's not actually broken, it's just some combinations of things you can't install. At least it's not broken for most purposes. So someone said how link, I don't know, app, get, no, okay. Somebody typed a page in the wiki in. So there is a multi-arched python in Ubuntu, it's been there for a while, it basically works. I think, Docher, you said you hadn't uploaded that to Debian or microphones, microphones. Well, I did do the multi-arching of Python because we need Python to build or to cross-build our base system. When cross-building you have two possibilities to build the base system. The first one is to use a staged build, just avoiding to build the Python stuff and modules and packages. The second approach is to make Python ready to cross-build extensions, not just the Python interpreter itself, but to cross-build extensions. That was the thing that was chosen. However, the DPKG maintainer did complain about the approach. So, what you have in Debian is exactly the same as in Ubuntu, but with the multi-arched attributes removed from the binary packages. I think the other problem is that at least some of the Python multi-archification in Ubuntu relies on build depends on colon any, which don't work yet in Debian. I'm still hoping to try to carve out some time to work with Bill Demon's Enters in Debian to finish that off. If I don't manage that, then hopefully it will be relatively shortly afterwards. You mean it's in deep package, but the one-a-build thing goes wrong? One-a-build will just reject any such thing and declare it uninstallable. I can't remember whether quite all of the us-build bits of that is, but it's all very, very, very close. It's just not quite there. Okay. Cool. So, Pearl, Niko, Tini did some fine work to basically work out how to rearrange the Pearl packages to have multi-arch support. That's not actually loaded anywhere yet, apart from my bootstrap archive. And I guess it's not even uploaded in Ubuntu either, is it? In Ubuntu, we did a reword it after we were able to build Pearl natively. Okay. I'm not sure if Pearl already has support to build extensions for... Cross-build extensions, yes. I managed to cross-build some extensions. The make-maker thing that does that is very stupid, so it needs quite a good kicking, but I did get it to build a couple of examples. Specifically, make-maker, or did you manage to try any that uses a rather newer and rather less crap module build? No, so I haven't tried that. I think that would be worth a shot, because if anything... A lot of stuff still uses make-maker, but there'd be things moving over to module build. Right, okay. And that explicitly has cross-support? I have no idea. So make-maker just doesn't really understand the concept, so it's a bit of a manual. But it wasn't... For simple modules, I think it's okay, but it probably breaks anything more complicated. So the Pearl stuff, so it was doing the Pearl multi-arching that we realized there's this transitive dependency thing that we weren't quite sure what to do about. So we all kind of went... So I used that Pearl for the ARM64 bootstrap. It turned out that you could cross-build Pearl, or you could multi-arch Pearl, but I couldn't get a multi-arch Pearl to cross-build. Well, it did, but lots of things were in the wrong places. It's kind of hacky, but, you know, as Doco says, you could use that to get started, and then you could just build one natively again at which point it comes out better. TCL, we've done... I started... Is that all right? Just having the headers and the libraries in the multi-arch locations, not being able to build ticker extensions or cross-build ticker extensions. OK. So we have the... because of the config script thing. Yes. But we have links to the config script. There's a little shim. Where's Dimitri gone? Is this all what's needed? Yeah, I think so, apparently. OK. So the set of programs which are mostly old, which predate package config, so package config just works in multi-arch. You tell it, ask it where stuff's installed. It tells you where stuff's installed. But old-fashioneder things tend to have a shell script you run in userlib tclconfig.sure, right? All stupid. Yeah, exactly, which all just give you the path of the thing I was built with, not like the path of things I need to build for now, which is the question you were trying to ask it. So they're all crap and broken. And so some modification apparently works OK for most TCL stuff by just installing the multiple versions in the multi-arch locations, and then everything calls what it believes to be the canonical script, which looks up what architect you asked for and gives you the answers from the appropriate thing. But mostly we should probably just move all these things to use package config. That's the right way to do it. But some hackery with shell wrappers seems to get us a reasonable way with other things that have crappy scripts. So far as I know, that works for, including for building TCL, things which build depend on TCL. But I have no idea what the status is for Java, Mono and Ruby. Does anyone in this room know? Of course, the Ruby man. So Ruby 2 comes with multi-arch support upstream. King. That should work. I'm managing the final bits to make sure that you can co-install two different architectures of the Ruby interpreter itself. Actually, the binary is already co-installable. The lib package is not, because some stupid thing but it should be easy to fix. And then when that's done, maybe that can be back ported for Ruby 192. Okay. So that sounds like progress. Does Java has JNI, doesn't it? So I guess those things would need to be, are you saying? Right. I think you're saying that the OpenJDK does look in multi-arch locations for JNI things, but upstream Oracle doesn't. So that won't work. So yeah, so we're making progress. We have this general problem of transitive dependencies to do something about to make everything work properly. But it's coming along. Pils, a bit of a blocker because that's part of the base system. We really do need that fixed. So the moment there isn't even anywhere to file bugs about it, there's basically a very long thread on the pearl list about what fun this has been. So at the moment, the version experimental is part of the 5.18 transition. That should happen soon. I'm not quite sure when soon is. Is Niko here, or is he? 5.18 transitions should be in a week or two or something. Right, really soon. Okay. So then we'll upload our slightly broken multi-arch pearl for people to experiment with and see what all bugs are about. One thing I'll say is that for once we would be able to be ahead and have been to the 5.18 transition is I think probably going to be a bit for our next release, so we'll have to hold it off for a while. Go ahead. How cool are we? So one thing that's interesting about pearl is that we've had to split it into two pieces. Pearl was carefully one thing so that when you upgraded it whilst doing stuff, installing core stuff, you couldn't end up with a broken one. But now we've got two parts. So if we managed to upgrade one or not, the other things could go wrong during pre-installed scripts that use pearl and other. So there's potential for breakage. I don't think we'll get to find out until we try it, really. Okay. Let's discuss that and reason about it before we upload it. I'd rather not have the central mechanism. Put it in experimental, right, so that we can try stuff. No, experimental is not useful for getting user testing. Okay. If you're trying to find bugs in your stuff, experimental, effectively, you only get, that's only useful for having a coordinated group of people to test things. What you need is you need eyeballs on a problem. Don't upload it experimental and ask for eyeballs. You need to talk to people and the upload to experimental is irrelevant. But I'm saying it shouldn't go to unstable at all until we've actually thought through and reasoned about the maintainer scripts and not just counted on people to find bugs in them for us. Okay. Yeah, it's definitely not going to unstable before they also looked at properly. I just thought it's easier to test if it's in experimental because you can just get it and then you can try stuff. Yeah, but then you found there was a problem. Well, sure, but you know, you should think about it first and make sure that it works before you upload it anywhere. We thought about it a reasonable amount and believe it will work. I'm happy to put it somewhere else if it's too broken for experimental. I'm going to test it that much before uploading it. Sure. My point is just that not that it's too broken for experimental but that uploading it to experimental is not a good safety net to rely on and that if you haven't thought about it enough that you're happy uploading it to unstable we should think about it some more. Okay. Please do that, people. And people like Steve who knows what he's talking about. So there's the whole chain of arch-independent all-dependent things which we've covered so I wrote all that up. There's a nice wiki page now which I don't think Philip mentioned which basically covers the discussion so far and Colin has a nice shiny piece of paper which was produced during lunchtime. We'll get to argue about it a bit more. But it's pretty esoteric stuff so unless you've been taking interest in this you probably just want to wait for someone to provide you with an answer. One thing we have discovered is a helmet wrote a nice handy little script to work out just how many instances are there of something which is arch any depending on something which is arch all depending on something which is arch any and it isn't just a false positive. So there were 640 packages in unstable with that property. We're down to 500 excluding my view. Okay. Because that was about 100. Down to 540 packages with some false positives excluded. So a reasonable number and from the languages we expect including and node as Colin says it's possible that in fact in Pearl this isn't really a problem. But that will be quite a lot of packages to just make arch any and have 13 copies off. I think from the discussion with Helmut at lunchtime I think my feeling is that Helmut's proposal to basically propagate up the architecture proposal is basically right. The refinement that this stuff I was thinking about would introduce is we think probably doing something with multi-arch lod and having additional things that look a bit like how you're handling arch all additional worlds where you have to have the same set of architectures but you can have multiple demands. So this is for the Perlin, Python scripts in the same package problem. But I don't think any of this should be a blocker to going ahead with Helmut's idea and it seems basically right to me. So the main problem with that actually is somebody doing some deep package work. We're always short of enthusiastic people to go and hack on deep package and argue with Guillem. And he's not here for us to argue with him in person, which is a pity. We'll see how that goes. Sorry? No. Sorry. So other aspects, the multi-arch cross spec has existed for a long time and the docs are all full of this isn't specified and don't do that and don't move your headers and this only covers library transitions. That was true. It's really quite out of date now. Actually we've been using the multi-arch cross spec for ages in Ubuntu. It seems to work. It doesn't seem to have caused any real problems. So basically unless anyone has any massive objections I think we should just declare that part of the spec. No fundamental objections. It seems very solid. All of the dependency level stuff is working just fine. The one thing I'd say is that it's very easy for people to miss the kiss where their headers are not in fact as multi-arch as they look. Particularly with, let's say, where headers happen to depend on the endianness of your build machine but you only test on AMD64 and i386, you won't notice that it's really multi-arch or if they depend on it being Linux and then suddenly FreeBSD differs. So I think it would be helpful to have some kind of checker script that can best look at an archive and check whether the allegedly multi-arch same things in it are in fact multi-arch. Someone asked that very question outside saying how do I check whether my package is actually which ones really differ between architectures? I don't know. I mean I don't think it's desperately hard but I'm not sure I wasn't really certain such a thing. Jackup will script, sorry. Jackup has these kind of scripts but I don't know where you can find them. I'm not sure how a maintainer can use those so I think we need to find that out and write it down for people. As a maintainer of D-Dub deviannet, I came to this idea during the stepcon and I will investigate whether I can just pull in two architectures into D-Dub and then do comparisons that way. Okay, cool. I've got the issue of what is arch and depth. Yes, welcome to that in a minute. That's another item further down the list, is what is the definition of matching. It would be terribly useful if perhaps a package tracking system told me that had just scanned our development packages and said these are all identical. I think this should be marked multi-arch same. Well, I mean you can't just do it straight away because you ideally want all of your dependencies to be multi-arched first because you cannot multi-arch this library dev and then you can't co-install it because its dependencies are not co-installable. That's not true. Yeah, it just doesn't do anything. Things don't have to be multi-arched in tree order. You don't have to start from the bottom. Okay, that's not an issue then. But the other bit that I did hit was that you have to deal with a fallout where things and configure scripts don't look at the multi-arch locations. If you move stuff to multi-arch locations, you should ideally look at your reverse build dependencies and make sure they don't start looking into embedded copies of libraries because there wasn't one found in this system location. That's quite important advice. If things build depend on your stuff, then you need to check that that stuff still builds preferably correctly because we know that there are problems, especially if you've got one of these stupid config script things which is very likely to give the wrong answers without some work. What else do we have? So there's this thing about arch all build dependencies being assumed to be MA foreign. So again, this was done at Ubuntu a while ago because it turns out that whilst you can't do this for dependencies, you can do this for build dependencies and just say, if it's arch all, I can assume it's foreign, which means that every maintainer doesn't have to put a one line, this package is MA foreign, i.e. I can just use it as a tool and it should work. Now, the fix we're about to do for the transitive problem makes this go away, so we don't need to. But in the meantime, given that there might be a fair amount of meantime, again, this is stalled on are the deep package maintainers going to complain. Has Steve gotten around to actually presenting it to the deep package maintainers? Well, I asked on the list actually a while back this very question. Sorry, who? I did. As you haven't. Oh. And I don't think I got an answer. Okay. Well, I can re-ask maybe. But just to give the two line summary of why this is okay for build dependencies and not for dependencies, it's because the only place this ever comes up in build dependencies is when you are trying to cross compile, and that was never possible previously in the packaging system anyway. Therefore, we're not breaking anything that previously worked by assuming all architecture, all dependencies are actually multi-arch foreign, and we can just get on with it, and if it doesn't work, then we do something different. In fact, it's a good enabler because we don't have to worry about breaking compatibility by thinking an architecture, all package satisfies a dependency that it really doesn't. Yes, because the docs at the moment, I think, tell developers not to multi-arch their dev packages, which is actually a bit unhelpful and we should fix that. The docs are wikis, right? Yeah, I know, I know. That's why I asked this question today. Is anyone going to complain if we... Do you think we should combine the two specs into a spec, or should we just leave it? Mike, back again. Sorry, with regards to combining the specs, the existing spec that you're referring to is... it was written as the implementation spec, which is this is how we put together the package managers to do what we want to do, and multi-arch cross, I believe, primarily documents, this is how you want to put together your packages, and I think we should have documentation of this is how you should put together your packages, and I don't think merging the specs, the two as they exist is a sensible thing to do. Okay, well, I was thinking of trying to, as you say, have one thing which is a specification, as opposed to a discussion and implementation and explanation that are different things. So my only objection to having dev packages being multi-arched foreign is that we'll have to remove those headers again after the fact. So we need to put careful thought into that to come up with an Indian tag that enables us to remove them later on. What do you mean remove them? No, remove. But multi-arched foreign headers don't make any sense on dev packages. They don't provide the boundary. I think that this is talking about architecture all, which is not for dev packages. Oh, there might be a small handful. Right. He said something about templates. So regarding the specs, it's mostly indeed true that multi-arched costs more of a high two, however it also has some... It's got some spurious stuff about tool chains which I think are just taken out because that was kind of irrelevant really. There's that, but it also has an extension to multi-arched spec in terms of the behaviour of, it depends on colon any, and I think that should be folded back in because it's pretty confusing to have them separate. So, yes. Maybe it would be a good idea to comb through the multi-arched cross file again and really take out the stuff that is usable as a spec as it is where we have actual implementation experience. Put that in a separate document and I don't know if it should be a DEP or whatever. It was started as a discussion document and it's acquired bits of actual spec as things have firmed up, but it's not really a very good document as it stands. I guess I should have a look at those doing that. We could have an action. I'll never get actions out of my boffs. Turns out I can't talk and write. I don't know. I know, I know. Turns out... Yes. Turns out they've gone full of pedants. So, we should have some multi-arched related goals. The goal last time was make the libraries co-installable and get rid of I32 Libs. Dash Dev co-installable and... All Dash Dev packages? Yes, all. It's a good goal. Okay, our goal is supposed to be... I like achievable bills. I would like to see some means for some QA criterion for cost-buildable packages. Currently it's very difficult to look at the result of a cost-build demon and decide is it intended to fail? Is it intended to build? I would like to have us to add some attributes maybe to the control file. This is the package which is supposed to cost-build and maybe something like this is a package which the maintainer has checked that it does cost-build correctly. Is that really something that should go in the control file? I think you're right that we should have QA and include the concept of is expected to work, is not expected to work, has never been tested. Well, maybe we can add more jobs to Jenkins to see that they just fetch the package and cross-build it and if it succeeds it should succeed and not regress. Yeah, if it ever built once before then it should carry on working. Just throw away the results. I mean, we don't care about the cross-build results. We proposed a field about the package being cross-buildable like maintainer saying it should cross-build and then it being a bug if it's not or at least having a flag like you said in an email that Wogan I wrote to a devian devil in the beginning of the year and there were some reasons of some people who don't remember now why that's not a good idea so if you look up that thread you can maybe respond and say why you think it's a good idea. We have the access test you'd field already in the package file and currently it's only used for auto package test but we can add comma cross-buildable which is a test. Yeah, might work. So yeah, I don't know if somebody needs to think about that really. Yes, it would definitely be useful if maintainers had better. My idea was that we'd run a cross-build demon and put the output of that into the package tracking system to say your package does or doesn't cross-build and basically if it had never done it before it wouldn't be a failure for it to not work now but if it ever had worked then we'd moan that it used to work and now it's broken. Philip wants to talk. So yeah, okay, that would be good. Any more suggested goals, Steve? Well actually I was going to respond to this question of tracking what builds and what doesn't. I think the goal is everything should be buildable and we get as far as we can with that as long as people are caring about cross-building so like when somebody is actively doing a bootstrap they worry about these things and it's always going to regress in between and I don't think it's reasonable or realistic to require Debian maintainers to for instance regard those as release critical bugs because they're not release critical for Debian but I think all of this worrying about documenting what does or doesn't cross-build is actually to a certain degree it's wasted effort when you don't actually need to get it cross-built right now and right then and there and when you do, the fact that it was a failure or not that you knew about is not the point the point is you now have this thing that you need to get cross-building OK, fair enough I think it's actually, the idea was that by running some QA that people get told about we're quite likely to keep it in a good state because of course without any QA or CI it's quite likely to get broken again I think one thing I would say is that it's useful to know whether a package when you're in that position of trying to bootstrap something it's useful to know whether something ever built before because then you have some notion of whether the problem might be tractable or not if you're just staring at a C of 600 build failures it's quite hard to see what's sensible to work on first and similarly the information that the maintainer thinks this works because it's in the control fire is actually quite important you know I think I've fixed it if it's broken then you'll like it to get a better response then no, this is never going to be cross-build but I'm not interested get lost well I don't think that's a reasonable response from a maintainer and that's why NMUs exist and such and such although some things are a bit scary some things are difficult to cross-compile and I guess I take Colin's point that it's useful to have that information but I don't think it belongs in the control file I think it's just something we should be running QA outside to document this for our own purposes rather than pushing it on the maintainer I agree with that there seems to be two aspects of it there's what do we want to force developers to do and what are we ready to take on as stuff that we need to do as NMUs or whatever when we're trying to cross-build and this is very important to if we start doing partial archers which is the next stage so if we ever end up with stuff that's in a partial arch that's only ever cross-built then is it like me, MinGW guy the only responsible person for actually doing all the patching work or can we force DDs to do the cross-build stuff for some stuff if it's ever been done before so that's what's nice about having something in the control file because that means that the the maintainer of the package is sort of committing in a sense to keeping the package cross-buildable the low threshold NMU wiki page is DDs committing to something and that's very simple so it's just a list of people so we could just do that and say will you help do you undertake we do already have a long tradition of low threshold NMUs being permitted across the archive for porting work and this is just a kind of porting work so yeah the acceptance across compiling is increasing slowly and we may find of course once everyone's got really fast arm machines there'll be less of it again we'll see how things go and it's fair to say at the moment we only really care for a fairly base system but it will be nice to spread that further of the I think the Ubuntu particularly would quite like to have a nice dev system for the phone dev thing so if everything in that tree cross-built nicely that would be cool can we agree on a target for cross-builds so I think it doesn't make sense to well to choose ten different targets for cross-builds but maybe as a first goal well agree on one or two targets which we want to you mean target architectures well supposedly something which well the majority of developers can actually run so for example armhf there aren't very many if you made it work it should work everywhere shouldn't it how often is it but how can you test that yes okay well in practice maybe we'd only test for a target and that's what people get told about so yeah armhf is a good one at the moment I'm happy with that but in general if you fixed it to cross it should just cross for everything modulo I don't know strange java dependencies that are broken for some architectures or whatever okay so yes just to get through things we'll come back to release goals possibly but Mingyu presents an interesting case because our current assumption about what is a different package is a different file sorry is it's libc but just the small subset of headers which are different between architectures but as soon as you go no no Mingyu is an architecture as well that has a completely different libc it's not a posix libc so in fact the set of headers that change just got much bigger so the question becomes what is your definition of the same now it's actually fairly easy to fix in the case of Mingyu you just go okay well all the c headers change between some of our architectures so we'll put them all in the multi arch locations except for maybe the three there are actually the same between windows and linux I don't know how crazy is that how violently do we object because it's also the same for the linux non super embedded people I suspect and android exactly yes which is another useful so maybe we should start to actually put all the c library stuff out of user include pretty much and then we can have a wider range of architectures supported well for starters I would just declare a MingW libc def package arch all and that puts its stuff into the sub tier so I don't see a reason for for it not to be parallel and leave all the linux stuff there and hope that nothing accidentally includes that Steven can respond about that's pretty much what's happening just now there's already a MingW cross compiler in the archive with the c library it uses the old style user triplet stuff and it only uses that so it never picks anything up from user include so that works fine if you're doing the equivalent of bare metal builds that only target the c library on windows if you start to extend things so I've got there are users who'd like to have libraries other libraries for GTK yeah like GTK for windows and they're even in Debian packages that need other stuff like for this Python needs zlib and whenever we get around to packaging and when mono's gonna need a whole stack of stuff and so we either duplicate all the packaging which is what fedora have done or we try to do a multi arch stuff and because we're saying that arch independent stuff can go into just user include that means that the MingW GCC has to look there as well to pick stuff up like nothing that's driven by package config but zlib for instance has its headers in user include so this GCC MingW needs to look in there which means you can't have anything in there that's going to confuse other stuff so basically he has to move out if we go down that route because you then get configure scripts that look around for stuff and they pick up stuff that's in user include that they can use to build but they won't actually it won't match anything when they're running I think well to move gilipsy to the multi arch include you would have to do it first and then do a test rebuild of the whole archive see how much break you get and I think we we can't stop with gilipsy because there are many linux specific headers then in usr include in other packages gilipsy will be the worst one there will be a bunch of incend configure scripts in the dawn of time that do stupid things and it will be hell for a bit it would probably be helpful to do some kind of test rebuild against a test archive with gilipsy and file a bunch of bugs so that we don't have everything so that we don't have 2,000 packages instantly failing to build and then it's becoming impossible to do anything for a while it might be nice to stay at that a little bit I mean the case for moving lipsy headers is of course good but Ming W partial architecture in itself is currently still blocked by d-package not having a Ming W triplet and that's the bugs been open for a long time ago and I don't know how to push a consensus on it considering there are people who would want to do the port and cross build a lot of packages which are useful that's relatively trivial amount of work compared to the lipsy so my feeling is that there is general support for that so I think we should probably kick a bit harder to push people here as it maintain there is an open bug to include Ming W triplet into the arch table and the arch table so we'll have to try and push that I think a bit more complaining it's a trivial patch I'm not quite sure what the objection would be it's not that trivial it tends to be quite picky on having triplets upstream first and stuff like that so it double checks everything and I think there's some disagreement on the naming of the ports I'm not sure it's thought nowadays is that fixed even it's probably easy to add in all the people who do the port agreed on a triplet but the rest of the world seems seems that it's inconsistent what's been done before on Linux yeah there's a sort of disagreement between what should be done but things are a bit too late now because everybody uses what's already been done and there's another new fact that's just broken out between Ming W 32 besides the point okay so alright we'll see how that goes I'd just like to get to the actual questions from people at the bottom of this thing can someone explain what it is they were asking there's a Ben over there so for several architectures we have kernels built for 64 bits that the userland is all those two bits the kernel that's used is or maybe actually 64 bit essentially belongs to a different architecture so if you currently if you install the headers package for this or the dev package for building after your modules that's although for example you have a dev package for a m64 kernel image you're actually installing this on your I8386 system right and that sort of works with the assumption that you that GCC is actually or it'll be GCC-4.7 because we do specify the compiler version I would rather like to get rid of the pseudo native the foreign kernel packages so you can just install the you make your system multiarch and install the kernel from the from the foreign architecture package now I'm actually installing the kernel itself works but the headers package, the dev package doesn't work because that has a dependency on a particular compiler version right, so the problem is that we're getting our dev headers package we don't care about libc the kernel libc dev that package right the linux headers package which is what you do for building after your modules that package, right okay I don't know so do you know how to fix this well I've just been trying doing and what seems to maybe work but it's kind of disgusting is to change the dependency on the compiler to say for example it depends on GCC-4.7-936 or GCC-4.7-AMB64 this is assumed of course that the compiler is not actually multiarch, it's multilib but it does sort of work in a multiarch installation need a microphone to be able to work I don't know what for example DAC or Brittany might think of that Brittany I'm pretty sure it doesn't handle at the moment I thought that was disliked back at the moment but maybe Steve can okay so after you can think about that we have two minutes for one more question so I'd just like to bring that up is this you asking about so help never mind that we'll come back to that I follow up question on that Ben can you comment on whether the foreign interface to the GNU-C compiler would address that need it would mean that the package has the target architecture in the name to depend on so you might get a cross compiler but you may get the native compiler so you would say it depends on GCC-4.7-1.6 yes would that address your need yes I think it would so that might happen after we have cross compilers in the archive so yes so Antoni so is this about whether we want we need or is it useful to have triplet-interpreter in-path like most of the interpreter language you run the interpreter against a configure script with metadata to generate a make file stuff so is that the way to go for enabling cross building of C extension so at the moment we put triplet on the front if the output is if it operates on foreign architecture stuff is that the right definition if the target is the file architecture so you're thinking about having triplet Ruby I don't know triplet Ruby sounds wrong to me because it's not really a cross compiler I think but I'm not sure I quite understand what you're achieving I don't know sorry there's one question I'd like to squeeze in I think the answer is no so the thing I did with Python is you need the Python interpreter for the build machine to build extensions for the host and what I'm doing is well using this interpreter but prepending the module path for the host specific modules so the interpreter for the built things it's the interpreter for the host and does the right thing so that's ugly but you can compare notes one last thing in the five seconds we have remaining should we enable i386 on Jesse MB64 extensions by default i386 is a foreign architecture so they've tested it in Ubuntu and not too many things went wrong but our time is over well hands up should we enable i386 by default on MB64 any nos right well there you are sounds like a yes we decided something genius thank you very much for sitting here sweating and listening to all this tedium I suggest we all go and do something else for a bit