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