**** BEGIN LOGGING AT Thu Mar 21 02:59:58 2013 Mar 21 11:13:30 ogra_: FWIW, i sent the rename patch, if you can't work on flash-kernel i can give it a look Mar 21 11:14:38 ogra_: and here is a kernel with the new name Mar 21 11:14:40 ogra_: http://people.canonical.com/~ppisati/linux-image-3.8.0-13-multiarm_3.8.0-13.24~musb3_armhf.deb Mar 21 11:14:48 ogra_: omap3/4, imx6 and vexpress Mar 21 11:14:56 ppisati, right, the DBB structure needs some changes for this Mar 21 11:15:01 *DB Mar 21 11:15:25 yuo didnt by chance talk to debian about it ? Mar 21 11:15:34 ogra_: nope Mar 21 11:15:43 so that we dont have to carry our own patch for an incompatibel naming scheme ? Mar 21 11:15:48 hmm, k Mar 21 11:16:08 they are just implementing the same but still discuss the naming afaik Mar 21 11:16:32 would really have been good to coordinate on that Mar 21 11:16:40 since the f-k changes wont be small Mar 21 11:17:54 (thires neither ... but we will have to rip out their naming and replace it with ours on eery merge now) Mar 21 11:18:47 ogra_: i didn't look at the code, but isn't an s/omap/multiarm/ change? Mar 21 11:19:04 no, since you can use both Mar 21 11:19:42 theh DB needs an additional field that tells f-k that you can do that and the code needs to manage both types Mar 21 11:20:16 else upgrades wont work and third party vendor kernels wouldnt either Mar 21 11:21:15 (and especially for omap there is an endless amount of BSP and vendor kernels) Mar 21 11:21:39 ogra_: i really don't get it Mar 21 11:21:49 ogra_: i mean, we imported the new debian flash-kernel Mar 21 11:22:04 ogra_: that changed our habits and made impossible to install previous kernel Mar 21 11:22:09 yes, to minimize the delta with debian Mar 21 11:22:18 which is a bug Mar 21 11:22:30 you can blame me for not having gotten to it yet Mar 21 11:22:36 ogra_: no no Mar 21 11:22:43 yes, you can :) Mar 21 11:22:53 ogra_: it's just, we can't wait for debian for evrything Mar 21 11:22:54 i promised it ages ago and forgot about it Mar 21 11:23:02 we dont Mar 21 11:23:36 we usually patch stuff proactively ... but patches need to be able to flow back somehow, else we need to maintain the delsta Mar 21 11:23:37 ogra_: anyhow, if you can work on that ok Mar 21 11:23:49 i plan to ... today actually Mar 21 11:23:54 ogra_: else, i'll tackle it Mar 21 11:24:04 ogra_: don't want to step on your feet Mar 21 11:24:04 but it would have been good to coordinate the naming with debian in advance Mar 21 11:24:20 so we dont have to carry a huge patch that renames the world Mar 21 11:24:51 i think they are aiming for something like armmp Mar 21 11:25:05 lool, any comment ^^ Mar 21 11:25:44 unfortunately, tegra will only support multiarch in 3.10 or so Mar 21 11:25:48 * lool reads up Mar 21 11:26:50 ogra_: topic is installing old kernels or multiarm kernels? Mar 21 11:26:59 multiarm Mar 21 11:27:16 for older i'll just add a --force-version that overrides the check Mar 21 11:27:27 thats trivial Mar 21 11:27:42 for multiarm we'll need a new DB field and code rthat uses it i think Mar 21 11:28:01 MultiPlatformCapable=true ... or some such Mar 21 11:28:33 and then match against that in the code to allow -multiarm vs -$flavour if its available on disk Mar 21 11:29:03 lool, what bothers me is that we dont use a consitent naming with debian that would save us a delta Mar 21 11:31:39 marvin24, well, 3.10 isnt far :) Mar 21 12:14:02 ogra_: if it helps, we can split the dbs and change the rules with dpkg-vendor to have Debian and Ubuntu dbs Mar 21 12:14:27 we'll see, let me come up with some code Mar 21 12:14:51 ogra_: for multiarch, I'm not quite sure a new field is the way to go; you could just list multiarch as the kernel flavor for all hardware supported by this kernel Mar 21 12:15:07 k Mar 21 12:15:20 basically just listing multiarch in Kernel-Flavors might just work Mar 21 12:15:27 k Mar 21 12:15:38 s/multiarch/multiarm/g sorry Mar 21 12:15:45 these words are too close in my brain :-) Mar 21 12:15:51 yup Mar 21 12:16:05 multiarm should be sheeva or something Mar 21 12:16:14 heh Mar 21 13:45:41 lool, ppisati, http://paste.ubuntu.com/5634079/ Mar 21 13:45:57 for a quick way to skip the version check Mar 21 13:48:52 lool, so regarding your mail you seem to suggest to enforce -multiarm only i.e. so -omap kernels wouldnt work at all anymore ... i dont think i like that idea it makes using a BSP or vendor kernel thats not from mainline impossible ... i'd rather see us supporting both, the old flavour name and multiarm here ... Mar 21 14:11:12 ogra_: So the flash-kernel $version is just for backwards compat Mar 21 14:11:27 ogra_: But you could implement force-version in a simpler way now, keeping this compat aroun Mar 21 14:11:54 simpler than above ? Mar 21 14:12:01 ogra_: You would add a block just like for --machine, then skip the latest_version check if force_version is set; if force_version is set, just set kvers to it Mar 21 14:12:06 * ogra_ found that fairly simple :) Mar 21 14:12:17 ogra_: Welll, simpler as in more readable Mar 21 14:12:24 it would be more lines Mar 21 14:12:35 yeah i did that first, but it adds extra vars and stuff Mar 21 14:12:41 that's fine Mar 21 14:12:48 k Mar 21 14:12:56 so about the other stuff Mar 21 14:13:03 a) we never remove kernels anywhere Mar 21 14:13:20 and i wouldnt see flash-kernel as a responsible tool to do that if we would Mar 21 14:13:49 b) we should go on supporting the old naming scheme for people rolling their own kernels Mar 21 14:14:21 a) -- yup, I think that's entirely orthogonal though Mar 21 14:14:22 c) i definitely think the packaging conflict/breaks/replaces stuff has to happen in the kernel package if needed Mar 21 14:14:32 c) -- yup Mar 21 14:14:48 and i would actually expect ppisati to already have all that stuff in the new packaging Mar 21 14:15:07 b) -- this should just keep working as it does now, unless they were using the same kernel flavor that we intend to drop Mar 21 14:15:18 there is actually another way to implement this which is completely different Mar 21 14:15:27 OMG I'm not sure I ought to mention this Mar 21 14:15:51 ogra_: Another entirely different pas is superseding Kernel-Flavors with Kernel-Configs Mar 21 14:15:56 this is quite different Mar 21 14:15:57 well, i would really just add a "MultiarmCapable" field to the DB Mar 21 14:16:22 uh Mar 21 14:16:34 and extend the flavour check a bit ... in a way that -multiarm is preferred if existing Mar 21 14:17:00 that way you can still support both Mar 21 14:17:08 I dont think that relates to the db, or then it's another d Mar 21 14:17:09 d Mar 21 14:17:09 db Mar 21 14:17:20 but need to make sure -multiarm is removed when you use your own play around kernel Mar 21 14:17:50 I'm all confused now Mar 21 14:18:09 the requirements in email seemed relatively clear to me: switch from -omap and others to -multiarm Mar 21 14:18:15 I think the plan is fair enough there Mar 21 14:18:36 Now I'm not quite sure what requirement we're discussing Mar 21 14:18:59 i want to keep the ability of being able to use -omap Mar 21 14:19:41 you seem to want that "Kernel-Flavors: multiarm" replaces "Kernel-Flavors: omap" Mar 21 14:20:09 i would like to keep Kernel-Flavors: as is and add a new field that tells us "this machine can also use multiarm" Mar 21 14:20:32 so people rolling their own 3.2 kernel which cant be multiarm can still use -omap Mar 21 14:20:39 (as an example) Mar 21 14:23:32 ogra_: we could have some kind of priority in the database to support multiple cases, but it kind of strikes me as dangerous Mar 21 14:23:54 I'd rather folks add a local db of their own somewhere and have to maintain it Mar 21 14:24:02 why, -multiarm would always be preferred Mar 21 14:24:11 or we define how custom kernels are named (e.g. -custom) and that's it Mar 21 14:24:48 ogra_: I dont get it, do you want them to use -omap or -multiarm Mar 21 14:25:01 if there is no -multiarm binary in /boot we just fall back to "Kernel-Flavors: Mar 21 14:25:10 in the end we support this and that hardware, this is the kernel you're supposed to use, and that's it Mar 21 14:25:35 i want us to use -multiarm (which doesnt need a "Kernel-Flavors:" field at all anymore) Mar 21 14:25:57 and still levae the opportunity to people building from older or BSP branches to have -omap Mar 21 14:26:03 or -omap4 Mar 21 14:26:11 or -armadaxp Mar 21 14:35:23 lool, oh, and looking at your mail ... "we have some dependencies in place which ensure that flash-kernel requiring multiarm is installed immediately after -omap is replaced by -multiarm (not before, not any later)" ... that cant work, nothing depends on flash-kernel anywhere Mar 21 14:35:46 iirc on your request back then Mar 21 14:37:19 * ogra_ sighs ... that whole discussion shoudl have taken place several months ago ... and debian should have been heavily involved Mar 21 14:41:34 hmm, so for the transition and wrt depends, i guess ppisati could add a versioned dep on f-k to his transitional package, that will go away at some later point anyway Mar 21 14:41:54 through clever conflicts/breaks/replaces login Mar 21 14:42:01 *logic Mar 21 14:44:15 hmm, so lets see if that works at all ... Mar 21 14:44:57 ppisati, can you test with editing the db and just change the "Kernel-Flavors:" field in your omap entry ? Mar 21 14:45:17 theoretically that should just make it work Mar 21 14:46:16 (practically i fear that 1.2.3-omap is simply bigger than 1.2.3-multiarm ... which triggets the kver issue) Mar 21 14:46:49 flag@flag-desktop:/usr/share/flash-kernel$ grep Kernel-Flavors db/all.db | grep omap Mar 21 14:46:52 flag@flag-desktop:/usr/share/flash-kernel$ Mar 21 14:47:19 err Mar 21 14:48:18 flash-kernel 3.0~rc.4ubuntu29 Mar 21 14:48:26 yeah i have the source here Mar 21 14:48:32 * ogra_ is baffled Mar 21 14:48:44 there is actually no "Kernel-Flavors:" in the DB Mar 21 14:48:52 so mind adding it for a test ? Mar 21 14:49:18 ogra_: there's actually Mar 21 14:49:28 ogra_: but there's no Kernel-Flavors in it Mar 21 14:49:29 for omap/omap4 ? Mar 21 14:49:46 yes Mar 21 14:49:53 Machine: OMAP3 Beagle Board Mar 21 14:49:55 etcetc Mar 21 14:49:58 and below omap4 Mar 21 14:50:11 doesnt have a Kernel-Flavors: line here Mar 21 14:50:14 ogra_: Of course it can work, you Break flash-kernel << version-that-works Mar 21 14:50:25 lool, from what ? Mar 21 14:50:33 lool, nothing depends on f-k Mar 21 14:50:33 from the kernel package Mar 21 14:50:48 this wouldn't be a Depends but a Breaks Mar 21 14:50:49 yeah thats what i mean, but from the transitional package Mar 21 14:51:06 which will vanish anyway at some point Mar 21 14:51:08 Either from the new binary packages or from the meta pulling the right stuff Mar 21 14:51:23 why not from the transitional one ? Mar 21 14:51:54 ppisati, so whats in the Kernel-Flavors: line you see there for omap/omap4 ? Mar 21 14:51:56 I don't know which one you mean Mar 21 14:52:07 anyway, from some kernel package that ultimately tries to pull -multiarm Mar 21 14:52:11 "we have some dependencies in place which ensure that flash-kernel requiring multiarm is installed immediately after -omap is replaced by -multiarm (not before, not any later)" Mar 21 14:52:15 from your mail Mar 21 14:52:41 ogra_: no no, there's no Kernel-Flavors in those omap3/4 entries Mar 21 14:52:42 "we have some transitional package which pulls in -multiarm when you had e.g. -omap installed" Mar 21 14:52:45 ogra_: ok, i got it Mar 21 14:52:48 ppisati, ah Mar 21 14:52:53 ogra_: i'll add an entry Mar 21 14:53:01 ppisati, so please add one with multiarm Mar 21 14:53:17 then try again, that should make it not fall over in the kver check Mar 21 14:53:51 though looking at the code the version check runs before the flavour check Mar 21 14:54:43 me guesses that needs to move up Mar 21 14:55:24 ogra_: ok Mar 21 14:55:47 ogra_: i guess '3.8.0-13-multiarm' is lexically inferior to '3.8.0-10-omap' Mar 21 14:55:51 ogra_: that's why it fails Mar 21 14:56:00 ogra_: that's the only reason why it fails Mar 21 14:56:08 ogra_: let me do some more testing Mar 21 14:56:15 well, i still dont get how it gets its flavour at all Mar 21 14:56:32 ogra_: i don't know, it works, don't touch it Mar 21 14:56:42 ogra_: ah, and it works on imx6 too! Mar 21 14:56:50 yeah, it worked in the past by a matter of luck and cosmic rays :) Mar 21 14:57:00 * ppisati loves cosmic rays Mar 21 14:57:16 hehe Mar 21 14:57:30 let me build an abi bumper kernel Mar 21 14:57:33 *bumped Mar 21 14:57:48 that wont make m larger than o Mar 21 14:58:08 ogra_: 3.8.0-13-omap vs 3.8.0-14-multiarm? Mar 21 14:58:14 the check logic is pretty screwed up due to the ordering Mar 21 14:58:42 the flavour check actually uses the version ... so the version check comes first all the time Mar 21 14:59:05 hmm, abi bump might work, not sure Mar 21 14:59:14 just cp the binary around ;) Mar 21 14:59:20 that's what i'm doing Mar 21 14:59:25 no need to build Mar 21 15:00:27 :) Mar 21 15:00:37 watch out: Mar 21 15:00:39 flag@flag-desktop:~$ sudo flash-kernel Mar 21 15:00:39 flash-kernel: installing version 3.8.0-14-multiarm Mar 21 15:00:39 Generating kernel u-boot image... done. Mar 21 15:00:39 Taking backup of uImage. Mar 21 15:00:42 Installing new uImage. Mar 21 15:00:44 Generating initramfs u-boot image... done. Mar 21 15:00:46 haha Mar 21 15:00:47 Taking backup of uInitrd. Mar 21 15:00:49 Installing new uInitrd. Mar 21 15:00:52 Taking backup of preEnv.txt. Mar 21 15:00:53 Does ubuntu-arm have a 'virtual mouse' when running on a tablet ( i know its not as good as dedicated touch ui) Mar 21 15:00:54 Installing new preEnv.txt. Mar 21 15:00:57 Taking backup of uEnv.txt. Mar 21 15:01:00 Installing new uEnv.txt. Mar 21 15:01:02 ABI bump FOR THE WIN! :) Mar 21 15:01:39 heh, yeah Mar 21 15:01:59 though i'm still confused about the missing flavour entry in the db Mar 21 15:02:37 but at least it saves us also from having that dependency stuff Mar 21 15:02:53 so, nothing else userspace wise? Mar 21 15:03:01 ogra_: ^ Mar 21 15:03:03 lool: ^ Mar 21 15:03:07 well, i'll add your --force-version now :) Mar 21 15:03:24 but nothing for you to do apart from making sure your version is high enough Mar 21 15:04:09 and indeed the proper debian/control entires to replace -omap stuff and do a clean transition as lool described in his mail Mar 21 15:04:21 (in your kernel package) Mar 21 15:04:37 ogra_: i think i did all the stuff in debian/control Mar 21 15:04:46 * ppisati goes to re-read the email Mar 21 15:04:55 iirc breaks/replaces/provides Mar 21 15:05:37 for the former versions of the kernels ... (omap, armadaxp ? ... do we have omap4 in there yet ? ) Mar 21 15:08:58 * we have some transitional package which pulls in -multiarm when you had e.g. -omap installed Mar 21 15:09:19 yeah Mar 21 15:09:20 isn't enough to point meta to the new -multiarm kernel? Mar 21 15:09:36 well you want to replace meta too ... Mar 21 15:09:49 currently linux-omap is installed Mar 21 15:10:01 ogra_: right Mar 21 15:10:04 and you want that to become linux or linux-multiarm Mar 21 15:10:45 so if i dist upgrade there must be an empty package called linux-omap that makes sure the new nly named one is pulled in Mar 21 15:11:40 right Mar 21 15:11:41 so either linux-omap vanishes from the archive and your new meta provides linux-omap (and all other flavours it replaces) or you have a transitional package Mar 21 15:13:38 else apt wont upgrade your kernel ... Mar 21 15:16:18 ogra_: ok, i'll let someone with more debian packaging knowledge than me handle that Mar 21 15:16:30 ok Mar 21 15:16:43 the abi bump happens anyway if i understood right ? Mar 21 15:16:59 ogra_: i'll ask to bump Mar 21 15:17:06 ogra_: but yes Mar 21 15:17:12 great, i'll add the --force for you :) Mar 21 15:17:22 so we can finally close that old bug Mar 21 15:31:06 ppisati, https://www.svtronics.com/index.php?route=product/product&product_id=33 ... the artist formerly known as "panda" Mar 21 15:33:16 ppisati: Dude, "multiarm"? What? Mar 21 15:33:42 ogra_: it's real! :) can't believe it! :) Mar 21 15:33:49 infinity: arm multiplatform Mar 21 15:34:05 ppisati: I know what it means, I was asking who decided on that ridiculous name for the flavour? Mar 21 15:34:14 infinity: me, thanks Mar 21 15:34:16 ppisati: We all agreed to have a -generic kernel ages ago. Mar 21 15:34:31 infinity: did we? Mar 21 15:34:39 We did. Was in several kernel team specs. Mar 21 15:35:02 Well, generic and generic-pae (or generic-nonpae and generic, we hadn't stopped bikeshedding) Mar 21 15:35:18 Since LPAE on A15 needs a -pae kernel. Mar 21 15:35:37 infinity: we can call it generic Mar 21 15:35:51 infinity: i don't have any atatchment to the flavour name Mar 21 15:36:19 Kay. Sorry for the strong reaction. :P Mar 21 15:36:43 But yeah, we should just have generic and be done with it. Mar 21 15:37:22 ppisati: As for the meta business, we'll do transitional metas. Just hard rename omap to generic, don't try any silly provides. Mar 21 15:37:37 ppisati: We have precedence for this with server->generic and generic-pae->generic, etc. Mar 21 15:38:05 as long as do-release-upgrade works ... Mar 21 15:38:19 which shurely all of our arm users use all the time :) Mar 21 15:38:52 ogra_: It'll work fine, like I said, it'll be the same migration path as x86 kernels in the past. Mar 21 15:39:00 k Mar 21 15:39:18 bah, who always uploads these chromium ftbs to the ppa Mar 21 15:39:23 ogra_: As for "does -generic support omap4", the answer is "yes", but we won't swap the metas around to force that upgrade, since we want PVR to keep working for people. Mar 21 15:39:46 So, omap4/raring will still use the quantal 3.5.0 kernel. Mar 21 15:39:49 well... i wouldnt mind -generic on server Mar 21 15:39:55 but that gets to complex Mar 21 15:40:08 i suppose Mar 21 15:40:13 Not worth the effort, really. Mar 21 15:40:17 yeah Mar 21 15:40:18 And not guaranteed to be an upgrade. :P Mar 21 15:40:39 heh Mar 21 15:41:03 Anyhow, the 3.5.0 Q kernel will be supported longer than R is, so this all magically works out. Mar 21 15:41:21 will be ? Mar 21 15:41:26 won't be you mean Mar 21 15:41:27 Yay for reduced lifecycles having serendipitous side effects. Mar 21 15:41:30 Will be. Mar 21 15:41:34 Q is 18mo, R is 9. Mar 21 15:41:35 ogra_: which ppa? Mar 21 15:41:43 oh, right Mar 21 15:42:16 qengho, canonical-arm-dev :) i'm not moaning about the ppa ... i'm moaning about it failing :P Mar 21 15:42:38 ogra_: Ah, right. Speaking of, can you add me to that team? Mar 21 15:42:43 ~cmiller Mar 21 15:42:49 there should be a rule that every 100 uploads one will magically build :) Mar 21 15:43:35 Well, if we're just legislating reality to our liking, I vote every one builds, without bugs. Mar 21 15:43:43 qengho, done Mar 21 15:43:47 Thx. Mar 21 15:50:47 ogra_: better late than never, if you can mail debian-arm a summary of how you are going multiplatform, it would be nice Mar 21 15:53:32 suihkulokki, yep, planning to Mar 21 16:07:28 ogra_: Where is this mail thread? Mar 21 16:07:42 ogra_: Almost everything I'm seeing in backscroll is wrong. Mar 21 16:07:49 debian-arm Mar 21 16:07:52 ogra_: There's no need for breaks/replaces/provides, or any of that. Mar 21 16:07:58 o which one do you mean Mar 21 16:08:10 ogra_: I mean the one you refer to involving you, Loic, and Paolo? Mar 21 16:08:16 well, its all moot anyway Mar 21 16:08:39 so just ignore Mar 21 16:09:05 It is? :P Mar 21 16:09:28 the whole discussion was based on the assumption that we have the flavour in the DB ... which we dont ... the issue was a simple versioning mistmatch Mar 21 16:09:47 which the abi bump fixes Mar 21 16:09:53 Right. Mar 21 16:10:09 Just hoping no one took the rest to heart. Mar 21 16:10:27 but i guess ppisati wouldnt mind if you give him a hand with the debian/control changes Mar 21 16:10:53 ppisati: The only debian/control* changes required are s/omap/generic/ and you're done. :) Mar 21 16:11:11 hmm /me never notices debian-arm anymore as it still goes to my aleph1 address which ends up on different box due to mail server mysteries Mar 21 16:11:13 ppisati: (Assuming an ABI bump to cover package conflicts) Mar 21 16:11:20 infinity: yep Mar 21 16:11:47 but I am interested in single zimage kernel packaging as it looks like I'll be miugged into making it work for linaro stuff Mar 21 16:12:12 I think I already promised that I'd fix d-i for it in both Debian and Ubuntu. Mar 21 16:12:16 well, debian seemingly will call it armmp Mar 21 16:12:17 I must have been drinking at the time. Mar 21 16:12:26 better go and read thread I suppose. who is ppisati Mar 21 16:12:45 you will likelly endu up with linux-arm64-armmp over there at some point :) Mar 21 16:13:24 ogra_: arm64 shouldn't need such a designation, it should be MP from the start. Mar 21 16:13:49 wookey, ppisati is an italian who missed the pope election and thus still works for us in the kernel team on our arm kernels Mar 21 16:13:56 ogra_: But yes, it would make more sense if Debian went with what they do on other arches and just called it, say, -armv7 or -arm32 or something. Mar 21 16:14:36 wookey: You may have more influence over silly naming in Debian than I would, if you have a better option than armmp. :P Mar 21 16:14:44 ogra_: next time that role will be mine... i swear... Mar 21 16:14:54 Debian kernel flavours are a mess anyway. Mar 21 16:14:55 "Scream for me Vaticaaaaaaannnn!!!!" Mar 21 16:15:18 haha Mar 21 16:15:19 hmm. you're right, he does seem quite italian :-) Mar 21 16:15:30 -686, -amd64, -alpha-generic, there's no consistency. Mar 21 16:16:03 consistency, schmistency Mar 21 16:16:40 Anyhow, I don't really give a crap what Debian names it, I just need to know for the d-i commits. Mar 21 16:16:44 * wookey knows nothing of kernels. Whatever looks good to an unfortunate punter picking from a list is probably good Mar 21 16:16:49 Since it won't have the same name as Ubuntu's similar flavour. Mar 21 16:17:13 we could try and have the same name if there no good reason not to Mar 21 16:17:28 wookey: The good reason is consistency. :P Mar 21 16:17:36 wookey: We have -generic on i386 and amd64 already. Mar 21 16:17:43 I thought there was a plan to make the kernel packaging less gratuitously differrent Mar 21 16:17:44 wookey: Something gratuitously different on ARM is silly. Mar 21 16:18:13 wookey: The kernel packaging ain't converging any time soon. There may be some thought sharing or even some cherry-picking, eventually, but they're not going to converge. Mar 21 16:18:28 (Not unless Debian adopts our naming scheme, cause we're sure not adopting theirs) Mar 21 16:18:36 That statement needs a "nyah nyah" on the end of it, but you get the idea. Mar 21 16:18:48 the naming and the packaging are probably fairly independent Mar 21 16:18:58 True. Mar 21 16:19:17 I know our kernel team just ate a DD who's going through debian* and picking it apart. Mar 21 16:19:28 But I don't think the goal was convergence. Just tidying. Mar 21 16:19:39 separating the tools seems like a good thing to copy from debian for example Mar 21 16:19:46 it would remove half the build-deps Mar 21 16:19:48 Honestly, with our kernels being so wildly different in many ways, I'm not sure convergence matters. Mar 21 16:20:04 except for people like me who have to hack both Mar 21 16:20:05 Breaking out tools would be good, and it's our radar already. Mar 21 16:20:16 s/our/on our/ Mar 21 16:20:53 Realistically, you shouldn't have to touch both much more than you already have. Mar 21 16:20:54 ok, bt there's already a debian.master/control.d/vars.generic Mar 21 16:21:56 And it's pointlessly x86-specific. Fail. Mar 21 16:21:59 (It's also wrong) Mar 21 16:22:01 there cross fixes, tools fixes, bootstrap fixes, multiarch fixes so far and they are mostly not transferrable due to radically different packaging, which is annoying. Mar 21 16:22:23 wookey: Sure, but you've done those fixes, convergence now doesn't get you anything. Mar 21 16:22:39 next there will probably be a pile of single zimage fixes Mar 21 16:23:09 they aren;t all upstream yet so not really 'done' Mar 21 16:23:38 you just like arguing Mar 21 16:23:53 Well, yes. But in this case, convergence is really, really hard. Mar 21 16:23:54 * wookey goes to fix kernel build. Mar 21 16:24:03 So, you're asking people to do a ton of work that they don't actually have to. :P Mar 21 16:24:18 wookey, nahh, he doesnt, hs is a https://lh6.googleusercontent.com/-RGqGhbZCxmI/UUraE5SMbGI/AAAAAAAABWE/IRwgZvae-5c/s707/smooth_canadian.jpg Mar 21 16:24:41 s/hs/he/ Mar 21 16:25:06 canadians dont argue :) Mar 21 16:25:29 the likeness is extraordinary Mar 21 16:25:46 section_image="universe/base" Mar 21 16:25:46 and Mar 21 16:25:46 (like germans arent srcastic) Mar 21 16:25:50 do_debug="Yes" Mar 21 16:25:53 are missing Mar 21 16:25:59 will the world crumble? Mar 21 16:26:20 ppisati: Hrm? Mar 21 16:26:37 if someone is fettling kernels can they put https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1105251 in please Mar 21 16:26:37 Launchpad bug 1105251 in linux "Fix cross- linux-tools build" [Medium,In progress] Mar 21 16:26:38 *grumble Mar 21 16:26:38 ppisati: That section/image was a blatant lie, since omap was in main. Mar 21 16:26:53 I've just had to move it all forward to 3.9 Mar 21 16:27:01 ppisati: However, the bootloaders var is much more troublesome. Mar 21 16:27:43 infinity: becase it'll put a dependency on all those packages, isn't it? Mar 21 16:28:01 ppisati: Well, it could be fixable with [arch] restrictions. Mar 21 16:28:16 ppisati: Since that's ending up in a control stub, which then gets parsed by dpkg-gencontrol. Mar 21 16:28:45 infinity: bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1) | [armhf]flash-kernel" ? Mar 21 16:28:47 ppisati: So, if all the current ones get [i386 amd64 x32] on them, and then you add "flash-kernel [armhf arm64]" Mar 21 16:29:20 bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1) | flash-kernel [armhf arm64]" Mar 21 16:29:36 You need to arch-restrict all the x86 ones too. Mar 21 16:29:51 Or your arm builds will get deps on all of that. Mar 21 16:29:57 infinity: ok Mar 21 16:30:08 (Some day, we'll want grub on arm anyway, but that day isn't today) Mar 21 16:30:45 bootloader="grub-pc [i386 amd64 x32] | grub-efi-amd64 [i386 amd64 x32] | grub-efi-ia32 [i386 amd64 x32] | grub [i386 amd64 x32] | lilo (>= 19.1) [i386 amd64 x32] | flash-kernel [armhf arm64]" Mar 21 16:30:48 ppisati: Anyhow, it's a bit hard to sort out how this will all parse out through the build system, so do a quick smoketest on both x86 and armhf and see what the actual deps on the .deb end up being. Mar 21 16:31:00 infinity: i'll do Mar 21 16:31:14 infinity: and, about the provides='' Mar 21 16:31:23 ppisati: That seems reasonable. (Probably worth rewriting somehow so that can be less messy, but it's a bit of a "who cares", if this works) Mar 21 16:31:25 infinity: i think those are wrong for armhf too Mar 21 16:31:38 provides="kvm-api-4, redhat-cluster-modules, ivtv-modules" Mar 21 16:31:45 ppisati: We surely build the same modules on armhf as x86. If not, we should. Mar 21 16:31:52 ppisati: So, the only lie there is kvm-api-4. Mar 21 16:31:58 ppisati: Which kinda doesn't matter. Mar 21 16:32:12 ok, lemme try to pt it tgether and do a compile Mar 21 16:32:13 ppisati: (And will stop being a lie with A15s) Mar 21 16:32:37 Well, once the kvm/arm code lands upstream. They've not been as awesome as the Xen guys. :P Mar 21 16:33:26 erm, where does that flash-kernel dep come from ? Mar 21 16:33:36 we never had kernels depend on f-k Mar 21 16:33:55 or did i miss omething Mar 21 16:33:57 s Mar 21 16:42:07 * ppisati goes to eat an apple Mar 21 16:42:51 ogra_: https://launchpad.net/ubuntu/raring/armhf/linux-image-3.8.0-13-omap/3.8.0-13.23 Mar 21 16:43:00 ogra_: Sure looks like it recommends flash-kernel currently. Mar 21 16:43:28 hmm, i thought we were denied doing that Mar 21 16:43:46 * ogra_ remembers a heated discussion a few years ago when he wanted it like that for chroots Mar 21 16:44:05 omap4 does as well. Mar 21 16:46:09 well, good then Mar 21 17:29:26 * ogra_ sighs about his discussion in -desktop ... so debconf is dead ... since systemd uses "he POSIX way" of writing timezone data directly to /etc/localtime Mar 21 17:29:36 s/he/the/ Mar 21 18:06:48 ok so Mar 21 18:06:54 dpkg -i works Mar 21 18:07:08 but flash-kernel is not aautomatically called Mar 21 18:07:14 what shall i check? Mar 21 18:07:20 infinity: ^ Mar 21 18:08:51 Erm, was it called with the omap kernel? Mar 21 18:08:56 If so, nothing should have changed. Mar 21 18:09:15 flash-kernel should have poop in /etc/kernel/postinst.d/ that triggers. Mar 21 18:10:50 lemme se if it's called with -omap Mar 21 18:12:36 flash-kernel: deferring update (trigger activated) Mar 21 18:12:41 when does it get called? Mar 21 18:15:09 ppisati: It's called from /etc/kernel/postinst.d/, like I said. Mar 21 18:15:25 infinity: actually it's not called Mar 21 18:15:28 ppisati: Which is called from the kernel postinst. Which shouldn't have changed at all. Mar 21 18:15:33 infinity: flash-kernel: deferring update (trigger activated) Mar 21 18:15:44 infinity: deferred to when? Mar 21 18:15:54 infinity: when i type 'reboot'? don't think so Mar 21 18:15:56 Deferred to when the dpkg run is done, in theory. Mar 21 18:16:10 The trigger could be broken. :P Mar 21 18:16:15 infinity: ah k Mar 21 18:16:22 infinity: that makes more sense Mar 21 18:17:15 infinity: anyhow, same behaviour as with omap Mar 21 18:17:40 Kay. So, if anything's wrong, it's a flash-kernel bug, that's fine. Mar 21 18:17:51 infinity: lol Mar 21 18:17:55 Did you do a build on both armhf and i386? Mar 21 18:18:01 infinity: yep Mar 21 18:18:07 And if so, did you check the Recommends for each? Mar 21 18:18:23 "dpkg-deb -I foo.deb | grep ^Recommends" Mar 21 18:18:23 infinity: lemme see Mar 21 18:19:27 ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_amd64.deb | grep ^Recommends Mar 21 18:19:30 ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_armhf.deb | grep ^Recommends Mar 21 18:20:23 That might need a space. :P Mar 21 18:20:33 "dpkg-deb -I foo.deb | grep '^ Recommends'" Mar 21 18:21:13 ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_armhf.deb | grep "^ Recommends" Recommends: flash-kernel Mar 21 18:21:16 ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_amd64.deb | grep "^ Recommends" Recommends: grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1) Mar 21 18:21:20 looks good Mar 21 18:21:23 Shiny. Mar 21 19:35:36 nice Mar 21 19:49:42 nephew Mar 21 20:17:05 is it expected that I can have libexpat1-dev:armel and libexpat1-dev:amd64 installed at the same time? Mar 21 20:18:44 * Snark would say it's the point of multiarch Mar 21 20:18:46 thats the purpose of multiarch, yes Mar 21 20:29:56 hi guys, may someone have time to help I ve got a pb on my N7 Mar 21 20:30:00 ? Mar 21 20:31:16 what is it ? Mar 21 20:34:21 I made the install following Mar 21 20:34:21 https://wiki.ubuntu.com/Nexus7/Installation#Troubleshooting Mar 21 20:34:21 but on boot there was lots of cmd lines saying unable to write blabla filesystem readonly Mar 21 20:34:40 https://wiki.ubuntu.com/Nexus7/Installation#Troubleshooting_the_Install Mar 21 20:35:41 I wait until cellbatt goes down nothing happened, only scroll of theses lines Mar 21 20:39:56 I just tried to boot it again it is still telling blabla readonly filesystem blabla Mar 21 20:42:16 Is that's meaning my first install went wrong ? Mar 21 20:42:17 It took a long time during the Mar 21 20:42:17 $ fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img command Mar 21 21:01:15 pizzacoca, yes, that means somethign went wrong Mar 21 21:01:38 check the md5sum of the img file Mar 21 21:04:01 ok, so I'll try again the install ... another thing, not really about ubuntu install : wen I listen very close to my N7 I can hear some sound from it (like the hp's always buzzing) knowed issue on N7 ? Mar 21 21:15:51 nope Mar 21 21:25:36 thanks ogra, I'll see that Mar 21 23:04:48 bug 1132439 Mar 21 23:04:50 Launchpad bug 1132439 in touch-preview-images "Android and iOS have majority of the phone market share" [Critical,Confirmed] https://launchpad.net/bugs/1132439 Mar 21 23:09:25 lol Mar 21 23:11:17 this is so funny, because you can't close-wontfix without becoming a joke **** ENDING LOGGING AT Fri Mar 22 02:59:58 2013