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