/srv/irclogs.ubuntu.com/2013/03/21/#ubuntu-arm.txt

=== zz_chihchun is now known as chihchun
=== prp^2 is now known as prpplague
=== chihchun is now known as zz_chihchun
brute-forceHi everyone, i'm having an issue with an ubuntu app, may attach a screenshot of my issue?02:15
=== 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
ppisatiogra_: FWIW, i sent the rename patch, if you can't work on flash-kernel i can give it a look11:13
ppisatiogra_: and here is a kernel with the new name11:14
ppisatiogra_: http://people.canonical.com/~ppisati/linux-image-3.8.0-13-multiarm_3.8.0-13.24~musb3_armhf.deb11:14
ppisatiogra_: omap3/4, imx6 and vexpress11:14
ogra_ppisati, right, the DBB structure needs some changes for this11:14
ogra_*DB11:15
ogra_yuo didnt by chance talk to debian about it ?11:15
ppisatiogra_: nope11:15
ogra_so that we dont have to carry our own patch for an incompatibel naming scheme ?11:15
ogra_hmm, k11:15
ogra_they are just implementing the same but still discuss the naming afaik11:16
ogra_would really have been good to coordinate on that11:16
ogra_since the f-k changes wont be small11:16
ogra_(thires neither ... but we will have to rip out their naming and replace it with ours on eery merge now)11:17
ppisatiogra_: i didn't look at the code, but isn't an s/omap/multiarm/ change?11:18
ogra_no, since you can use both11:19
ogra_theh DB needs an additional field that tells f-k that you can do that and the code needs to manage both types11:19
ogra_else upgrades wont work and third party vendor kernels wouldnt either11:20
ogra_(and especially for omap there is an endless amount of BSP and vendor kernels)11:21
ppisatiogra_: i really don't get it11:21
ppisatiogra_: i mean, we imported the new debian flash-kernel11:21
ppisatiogra_: that changed our habits and made impossible to install previous kernel11:22
ogra_yes, to minimize the delta with debian11:22
ogra_which is a bug11:22
ogra_you can blame me for not having gotten to it yet11:22
ppisatiogra_: no no11:22
ogra_yes, you can :)11:22
ppisatiogra_: it's just, we can't wait for debian for evrything11:22
ogra_i promised it ages ago and forgot about it11:22
ogra_we dont11:23
ogra_we usually patch stuff proactively ... but patches need to be able to flow back somehow, else we need to maintain the delsta11:23
ppisatiogra_: anyhow, if you can work on that ok11:23
ogra_i plan to ... today actually11:23
ppisatiogra_: else, i'll tackle it11:23
ppisatiogra_: don't want to step on your feet11:24
ogra_but it would have been good to coordinate the naming with debian in advance11:24
ogra_so we dont have to carry a huge patch that renames the world11:24
ogra_i think they are aiming for something like armmp11:24
ogra_lool, any comment ^^11:25
marvin24unfortunately, tegra will only support multiarch in 3.10 or so11:25
* lool reads up11:25
loologra_: topic is installing old kernels or multiarm kernels?11:26
ogra_multiarm11:26
ogra_for older i'll just add a --force-version that overrides the check11:27
ogra_thats trivial11:27
ogra_for multiarm we'll need a new DB field and code rthat uses it i think11:27
ogra_MultiPlatformCapable=true ... or some such11:28
ogra_and then match against that in the code to allow -multiarm vs -$flavour if its available on disk11:28
ogra_lool, what bothers me is that we dont use a consitent naming with debian that would save us a delta11:29
ogra_marvin24, well, 3.10 isnt far :)11:31
=== chihchun is now known as zz_chihchun
loologra_: if it helps, we can split the dbs and change the rules with dpkg-vendor to have Debian and Ubuntu dbs12:14
ogra_we'll see, let me come up with some code12:14
loologra_: 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 kernel12:14
ogra_k12:15
loolbasically just listing multiarch in Kernel-Flavors might just work12:15
ogra_k12:15
lools/multiarch/multiarm/g sorry12:15
loolthese words are too close in my brain  :-)12:15
ogra_yup12:15
loolmultiarm should be sheeva or something12:16
ogra_heh12:16
=== txwikinger2 is now known as txwikinger
ogra_lool, ppisati, http://paste.ubuntu.com/5634079/13:45
ogra_for a quick way to skip the version check13:45
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 ...13:48
loologra_: So the flash-kernel $version is just for backwards compat14:11
loologra_: But you could implement force-version in a simpler way now, keeping this compat aroun14:11
ogra_simpler than above ?14:11
loologra_: 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 it14:12
* ogra_ found that fairly simple :)14:12
loologra_: Welll, simpler as in more readable14:12
loolit would be more lines14:12
ogra_yeah i did that first, but it adds extra vars and stuff14:12
loolthat's fine14:12
ogra_k14:12
ogra_so about the other stuff14:12
ogra_a) we never remove kernels anywhere14:13
ogra_and i wouldnt see flash-kernel as a responsible tool to do that if we would14:13
ogra_b) we should go on supporting the old naming scheme for people rolling their own kernels14:13
loola) -- yup, I think that's entirely orthogonal though14:14
ogra_c) i definitely think the packaging conflict/breaks/replaces stuff has to happen in the kernel package if needed14:14
loolc) -- yup14:14
ogra_and i would actually expect ppisati to already have all that stuff in the new packaging14:14
loolb) -- this should just keep working as it does now, unless they were using the same kernel flavor that we intend to drop14:15
loolthere is actually another way to implement this which is completely different14:15
loolOMG I'm not sure I ought to mention this14:15
loologra_: Another entirely different pas is superseding Kernel-Flavors with Kernel-Configs14:15
loolthis is quite different14:15
ogra_well, i would really just add a "MultiarmCapable" field to the DB14:15
looluh14:16
ogra_and extend the flavour check a bit ... in a way that -multiarm is preferred if existing14:16
ogra_that way you can still support both14:17
loolI dont think that relates to the db, or then it's another d14:17
loold14:17
looldb14:17
ogra_but need to make sure -multiarm is removed when you use your own play around kernel14:17
loolI'm all confused now14:17
loolthe requirements in email seemed relatively clear to me: switch from -omap and others to -multiarm14:18
loolI think the plan is fair enough there14:18
loolNow I'm not quite sure what requirement we're discussing14:18
ogra_i want to keep the ability of being able to use -omap14:18
ogra_you seem to want that  "Kernel-Flavors: multiarm" replaces "Kernel-Flavors: omap"14:19
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 -omap14:20
ogra_(as an example)14:20
loologra_: we could have some kind of priority in the database to support multiple cases, but it kind of strikes me as dangerous14:23
loolI'd rather folks add a local db of their own somewhere and have to maintain it14:23
ogra_why, -multiarm would always be preferred14:24
loolor we define how custom kernels are named (e.g. -custom) and that's it14:24
loologra_: I dont get it, do you want them to use -omap or -multiarm14:24
ogra_if there is no -multiarm binary in /boot we just fall back to "Kernel-Flavors:14:25
loolin the end we support this and that hardware, this is the kernel you're supposed to use, and that's it14: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 -omap14:25
ogra_or -omap414:26
ogra_or -armadaxp14:26
=== chuck_ is now known as zul
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 anywhere14:35
ogra_iirc on your request back then14:35
* ogra_ sighs ... that whole discussion shoudl have taken place several months ago ... and debian should have been heavily involved14:37
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 anyway14:41
ogra_through clever conflicts/breaks/replaces login14:41
ogra_*logic14:42
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:44
ogra_theoretically that should just make it work14:45
ogra_(practically i fear that 1.2.3-omap is simply bigger than 1.2.3-multiarm ... which triggets the kver issue)14:46
ppisatiflag@flag-desktop:/usr/share/flash-kernel$ grep Kernel-Flavors db/all.db  | grep omap14:46
ppisatiflag@flag-desktop:/usr/share/flash-kernel$14:46
ogra_err14:47
ppisatiflash-kernel 3.0~rc.4ubuntu2914:48
ogra_yeah i have the source here14:48
* ogra_ is baffled 14:48
ogra_there is actually no "Kernel-Flavors:" in the DB14:48
ogra_so mind adding it for a test ?14:48
ppisatiogra_: there's actually14:49
ppisatiogra_: but there's no Kernel-Flavors in it14:49
ogra_for omap/omap4 ?14:49
ppisatiyes14:49
ppisatiMachine: OMAP3 Beagle Board14:49
ppisatietcetc14:49
ppisatiand below omap414:49
ogra_doesnt have a Kernel-Flavors: line here14:50
loologra_: Of course it can work, you Break flash-kernel << version-that-works14:50
ogra_lool, from what ?14:50
ogra_lool, nothing depends on f-k14:50
loolfrom the kernel package14:50
loolthis wouldn't be a Depends but a Breaks14:50
ogra_yeah thats what i mean, but from the transitional package14:50
ogra_which will vanish anyway at some point14:51
loolEither from the new binary packages or from the meta pulling the right stuff14: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
loolI don't know which one you mean14:51
loolanyway, from some kernel package that ultimately tries to pull -multiarm14: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 mail14:52
ppisatiogra_: no no, there's no Kernel-Flavors in those omap3/4 entries14:52
ogra_"we have some transitional package which pulls in -multiarm when you  had e.g. -omap installed"14:52
ppisatiogra_: ok, i got it14:52
ogra_ppisati, ah14:52
ppisatiogra_: i'll add an entry14:52
ogra_ppisati, so please add one with multiarm14:53
ogra_then try again, that should make it not fall over in the kver check14:53
ogra_though looking at the code the version check runs before the flavour check14:53
ogra_me guesses that needs to move up14:54
ppisatiogra_: ok14:55
ppisatiogra_: i guess '3.8.0-13-multiarm' is lexically inferior to '3.8.0-10-omap'14:55
ppisatiogra_: that's why it fails14:55
ppisatiogra_: that's the only reason why it fails14:56
ppisatiogra_: let me do some more testing14:56
ogra_well, i still dont get how it gets its flavour at all14:56
ppisatiogra_: i don't know, it works, don't touch it14:56
ppisatiogra_: 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:56
* ppisati loves cosmic rays14:57
ogra_hehe14:57
ppisatilet me build an abi bumper kernel14:57
ppisati*bumped14:57
ogra_that wont make m larger than o14:57
ppisatiogra_: 3.8.0-13-omap vs 3.8.0-14-multiarm?14:58
ogra_the check logic is pretty screwed up due to the ordering14:58
ogra_the flavour check actually uses the version ... so the version check comes first all the time14:58
ogra_hmm, abi bump might work, not sure14:59
ogra_just cp the binary around ;)14:59
ppisatithat's what i'm doing14:59
ogra_no need to build14:59
ppisati:)15:00
ppisatiwatch out:15:00
ppisatiflag@flag-desktop:~$ sudo flash-kernel15:00
ppisatiflash-kernel: installing version 3.8.0-14-multiarm15:00
ppisatiGenerating kernel u-boot image... done.15:00
ppisatiTaking backup of uImage.15:00
ppisatiInstalling new uImage.15:00
ppisatiGenerating initramfs u-boot image... done.15:00
ogra_haha15:00
ppisatiTaking backup of uInitrd.15:00
ppisatiInstalling new uInitrd.15:00
ppisatiTaking backup of preEnv.txt.15:00
doomlordDoes ubuntu-arm have a 'virtual mouse' when running on a tablet ( i know its not as good as dedicated touch ui)15:00
ppisatiInstalling new preEnv.txt.15:00
ppisatiTaking backup of uEnv.txt.15:00
ppisatiInstalling new uEnv.txt.15:01
ppisatiABI bump FOR THE WIN! :)15:01
ogra_heh, yeah15:01
ogra_though i'm still confused about the missing flavour entry in the db15:01
ogra_but at least it saves us also from having that dependency stuff15:02
ppisatiso, nothing else userspace wise?15:02
ppisatiogra_: ^15:03
ppisatilool: ^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 enough15:03
ogra_and indeed the proper debian/control entires to replace -omap stuff and do a clean transition as lool described in his mail15:04
ogra_(in your kernel package)15:04
ppisatiogra_: i think i did all the stuff in debian/control15:04
* ppisati goes to re-read the email15:04
ogra_iirc breaks/replaces/provides15:04
ogra_for the former versions of the kernels ... (omap, armadaxp ? ... do we have omap4 in there yet ? )15:05
ppisati* we have some transitional package which pulls in -multiarm when you had e.g. -omap installed15:08
ogra_yeah15:09
ppisatiisn'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 installed15:09
ppisatiogra_: right15:10
ogra_and you want that to become linux or linux-multiarm15: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 in15:10
ppisatiright15: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 package15:11
ogra_else apt wont upgrade your kernel ...15:13
ppisatiogra_: ok, i'll let someone with more debian packaging knowledge than me handle that15:16
ogra_ok15:16
ogra_the abi bump happens anyway if i understood right ?15:16
ppisatiogra_: i'll ask to bump15:16
ppisatiogra_: but yes15:17
ogra_great, i'll add the --force for you :)15:17
ogra_so we can finally close that old bug15:17
ogra_ppisati, https://www.svtronics.com/index.php?route=product/product&product_id=33 ... the artist formerly known as "panda"15:31
infinityppisati: Dude, "multiarm"?  What?15:33
ppisatiogra_: it's real! :) can't believe it! :)15:33
ppisatiinfinity: arm multiplatform15:33
infinityppisati: I know what it means, I was asking who decided on that ridiculous name for the flavour?15:34
ppisatiinfinity: me, thanks15:34
infinityppisati: We all agreed to have a -generic kernel ages ago.15:34
ppisatiinfinity: did we?15:34
infinityWe did.  Was in several kernel team specs.15:34
infinityWell, generic and generic-pae (or generic-nonpae and generic, we hadn't stopped bikeshedding)15:35
infinitySince LPAE on A15 needs a -pae kernel.15:35
ppisatiinfinity: we can call it generic15:35
ppisatiinfinity: i don't have any atatchment to the flavour name15:35
infinityKay.  Sorry for the strong reaction. :P15:36
infinityBut yeah, we should just have generic and be done with it.15:36
=== rsalveti_ is now known as rsalveti
infinityppisati: As for the meta business, we'll do transitional metas.  Just hard rename omap to generic, don't try any silly provides.15:37
infinityppisati: We have precedence for this with server->generic and generic-pae->generic, etc.15:37
ogra_as long as do-release-upgrade works ...15:38
ogra_which shurely all of our arm users use all the time :)15:38
infinityogra_: It'll work fine, like I said, it'll be the same migration path as x86 kernels in the past.15:38
ogra_k15:39
ogra_bah, who always uploads these chromium ftbs to the ppa15:39
infinityogra_: 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
infinitySo, omap4/raring will still use the quantal 3.5.0 kernel.15:39
ogra_well... i wouldnt mind -generic on server15:39
ogra_but that gets to complex15:39
ogra_i suppose15:40
infinityNot worth the effort, really.15:40
ogra_yeah15:40
infinityAnd not guaranteed to be an upgrade. :P15:40
ogra_heh15:40
infinityAnyhow, 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 mean15:41
infinityYay for reduced lifecycles having serendipitous side effects.15:41
infinityWill be.15:41
infinityQ is 18mo, R is 9.15:41
qenghoogra_: which ppa?15:41
ogra_oh, right15:41
ogra_qengho, canonical-arm-dev :) i'm not moaning about the ppa ... i'm moaning about it failing :P15:42
qenghoogra_: Ah, right.  Speaking of, can you add me to that team?15:42
qengho~cmiller15:42
ogra_there should be a rule that every 100 uploads one will magically build :)15:42
qenghoWell, if we're just legislating reality to our liking, I vote every one builds, without bugs.15:43
ogra_qengho, done15:43
qenghoThx.15:43
suihkulokkiogra_: better late than never, if you can mail debian-arm a summary of how you are going multiplatform, it would be nice15:50
ogra_suihkulokki, yep, planning to15:53
infinityogra_: Where is this mail thread?16:07
infinityogra_: Almost everything I'm seeing in backscroll is wrong.16:07
ogra_debian-arm16:07
infinityogra_: There's no need for breaks/replaces/provides, or any of that.16:07
ogra_o which one do you mean16:07
infinityogra_: I mean the one you refer to involving you, Loic, and Paolo?16:08
ogra_well, its all moot anyway16:08
ogra_so just ignore16:08
infinityIt is? :P16: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 mistmatch16:09
ogra_which the abi bump fixes16:09
infinityRight.16:09
infinityJust 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 changes16:10
infinityppisati: The only debian/control* changes required are s/omap/generic/ and you're done. :)16:10
wookeyhmm /me never notices debian-arm anymore as it still goes to my aleph1 address which ends up on different box due to mail server mysteries16:11
infinityppisati: (Assuming an ABI bump to cover package conflicts)16:11
ppisatiinfinity: yep16:11
wookeybut I am interested in single zimage kernel packaging as it looks like I'll be miugged into making it work for linaro stuff16:11
infinityI 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 armmp16:12
infinityI must have been drinking at the time.16:12
wookeybetter go and read thread I suppose. who is ppisati16:12
ogra_you will likelly endu up with linux-arm64-armmp over there at some point :)16:12
infinityogra_: 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 kernels16:13
infinityogra_: 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:13
infinitywookey: You may have more influence over silly naming in Debian than I would, if you have a better option than armmp. :P16:14
ppisatiogra_: next time that role will be mine... i swear...16:14
infinityDebian kernel flavours are a mess anyway.16:14
ppisati"Scream for me Vaticaaaaaaannnn!!!!"16:14
ogra_haha16:15
wookeyhmm. you're right, he does seem quite italian :-)16:15
infinity-686, -amd64, -alpha-generic, there's no consistency.16:15
wookeyconsistency, schmistency16:16
infinityAnyhow, 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 good16:16
infinitySince it won't have the same name as Ubuntu's similar flavour.16:16
wookeywe could try and have the same name if there no good reason not to16:17
infinitywookey: The good reason is consistency. :P16:17
infinitywookey: We have -generic on i386 and amd64 already.16:17
wookeyI thought there was a plan to make the kernel packaging less gratuitously differrent16:17
infinitywookey: Something gratuitously different on ARM is silly.16:17
infinitywookey: 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
infinityThat statement needs a "nyah nyah" on the end of it, but you get the idea.16:18
wookeythe naming and the packaging are probably fairly independent16:18
infinityTrue.16:18
infinityI know our kernel team just ate a DD who's going through debian* and picking it apart.16:19
infinityBut I don't think the goal was convergence.  Just tidying.16:19
wookeyseparating the tools seems like a good thing to copy from debian for example16:19
wookeyit would remove half the build-deps16:19
infinityHonestly, with our kernels being so wildly different in many ways, I'm not sure convergence matters.16:19
wookeyexcept for people like me who have to hack both16:20
infinityBreaking out tools would be good, and it's our radar already.16:20
infinitys/our/on our/16:20
infinityRealistically, you shouldn't have to touch both much more than you already have.16:20
ppisatiok, bt there's already a debian.master/control.d/vars.generic16:20
infinityAnd it's pointlessly x86-specific.  Fail.16:21
infinity(It's also wrong)16:21
wookeythere 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
infinitywookey: Sure, but you've done those fixes, convergence now doesn't get you anything.16:22
wookeynext there will probably be a pile of single zimage fixes16:22
wookeythey aren;t all upstream yet so not really 'done'16:23
wookeyyou just like arguing16:23
infinityWell, yes.  But in this case, convergence is really, really hard.16:23
* wookey goes to fix kernel build.16:23
infinitySo, you're asking people to do a ton of work that they don't actually have to. :P16:24
ogra_wookey, nahh, he doesnt, hs is a https://lh6.googleusercontent.com/-RGqGhbZCxmI/UUraE5SMbGI/AAAAAAAABWE/IRwgZvae-5c/s707/smooth_canadian.jpg16:24
ogra_s/hs/he/16:24
ogra_canadians dont argue :)16:25
wookeythe likeness is extraordinary16:25
ppisatisection_image="universe/base"16:25
ppisatiand16:25
ogra_(like germans arent srcastic)16:25
ppisatido_debug="Yes"16:25
ppisatiare missing16:25
ppisatiwill the world crumble?16:25
infinityppisati: Hrm?16:26
wookeyif someone is fettling kernels can they put https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1105251 in please16:26
ubot2Launchpad bug 1105251 in linux "Fix cross- linux-tools build" [Medium,In progress]16:26
ppisati*grumble16:26
infinityppisati: That section/image was a blatant lie, since omap was in main.16:26
wookeyI've just had to move it all forward to 3.916:26
infinityppisati: However, the bootloaders var is much more troublesome.16:27
ppisatiinfinity: becase it'll put a dependency on all those packages, isn't it?16:27
infinityppisati: Well, it could be fixable with [arch] restrictions.16:28
infinityppisati: Since that's ending up in a control stub, which then gets parsed by dpkg-gencontrol.16:28
ppisatiinfinity: bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1) | [armhf]flash-kernel" ?16:28
infinityppisati: So, if all the current ones get [i386 amd64 x32] on them, and then you add "flash-kernel [armhf arm64]"16:28
ppisatibootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1) | flash-kernel [armhf arm64]"16:29
infinityYou need to arch-restrict all the x86 ones too.16:29
infinityOr your arm builds will get deps on all of that.16:29
ppisatiinfinity: ok16:29
infinity(Some day, we'll want grub on arm anyway, but that day isn't today)16:30
ppisatibootloader="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
infinityppisati: 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:30
ppisatiinfinity: i'll do16:31
ppisatiinfinity: and, about the provides=''16:31
infinityppisati: 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
ppisatiinfinity: i think those are wrong for armhf too16:31
ppisatiprovides="kvm-api-4, redhat-cluster-modules, ivtv-modules"16:31
infinityppisati: We surely build the same modules on armhf as x86.  If not, we should.16:31
infinityppisati: So, the only lie there is kvm-api-4.16:31
infinityppisati: Which kinda doesn't matter.16:31
ppisatiok, lemme try to pt it tgether and do a compile16:32
infinityppisati: (And will stop being a lie with A15s)16:32
infinityWell, once the kvm/arm code lands upstream.  They've not been as awesome as the Xen guys. :P16:32
ogra_erm, where does that flash-kernel dep come from ?16:33
ogra_we never had kernels depend on f-k16:33
ogra_or did i miss omething16:33
ogra_s16:33
* ppisati goes to eat an apple16:42
infinityogra_: https://launchpad.net/ubuntu/raring/armhf/linux-image-3.8.0-13-omap/3.8.0-13.2316:42
infinityogra_: Sure looks like it recommends flash-kernel currently.16:43
ogra_hmm, i thought we were denied doing that16:43
* ogra_ remembers a heated discussion a few years ago when he wanted it like that for chroots 16:43
infinityomap4 does as well.16:44
ogra_well, good then16:46
* ogra_ sighs about his discussion in -desktop ... so debconf is dead ... since systemd uses "he POSIX way" of writing timezone data directly to /etc/localtime17:29
ogra_s/he/the/17:29
=== basiaf_ is now known as basiaf
=== prp^2 is now known as prpplague
ppisatiok so18:06
ppisatidpkg -i works18:06
ppisatibut flash-kernel is not aautomatically called18:07
ppisatiwhat shall i check?18:07
ppisatiinfinity: ^18:07
infinityErm, was it called with the omap kernel?18:08
infinityIf so, nothing should have changed.18:08
infinityflash-kernel should have poop in /etc/kernel/postinst.d/ that triggers.18:09
ppisatilemme se if it's called with -omap18:10
ppisatiflash-kernel: deferring update (trigger activated)18:12
ppisatiwhen does it get called?18:12
infinityppisati: It's called from /etc/kernel/postinst.d/, like I said.18:15
ppisatiinfinity: actually it's not called18:15
infinityppisati: Which is called from the kernel postinst.  Which shouldn't have changed at all.18:15
ppisatiinfinity: flash-kernel: deferring update (trigger activated)18:15
ppisatiinfinity: deferred to when?18:15
ppisatiinfinity: when i type 'reboot'? don't think so18:15
infinityDeferred to when the dpkg run is done, in theory.18:15
infinityThe trigger could be broken. :P18:16
ppisatiinfinity: ah k18:16
ppisatiinfinity: that makes more sense18:16
ppisatiinfinity: anyhow, same behaviour as with omap18:17
infinityKay.  So, if anything's wrong, it's a flash-kernel bug, that's fine.18:17
ppisatiinfinity: lol18:17
infinityDid you do a build on both armhf and i386?18:17
ppisatiinfinity: yep18:18
infinityAnd if so, did you check the Recommends for each?18:18
infinity"dpkg-deb -I foo.deb | grep ^Recommends"18:18
ppisatiinfinity: lemme see18:18
ppisatippisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_amd64.deb | grep ^Recommends18:19
ppisatippisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_armhf.deb | grep ^Recommends18:19
infinityThat might need a space. :P18:20
infinity"dpkg-deb -I foo.deb | grep '^ Recommends'"18:20
ppisatippisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_armhf.deb | grep "^ Recommends" Recommends: flash-kernel18:21
ppisatippisati@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
ppisatilooks good18:21
infinityShiny.18:21
xnoxnice19:35
ogra_nephew19:49
=== prp^2 is now known as prpplague
mjrosenbis it expected that I can have libexpat1-dev:armel and libexpat1-dev:amd64 installed at the same time?20:17
* Snark would say it's the point of multiarch20:18
ogra_thats the purpose of multiarch, yes20:18
pizzacocahi guys, may someone have time to help I ve got a pb on my N720:29
pizzacoca?20:30
ogra_what is it ?20:31
pizzacocaI made the install following20:34
pizzacocahttps://wiki.ubuntu.com/Nexus7/Installation#Troubleshooting20:34
pizzacocabut on boot there was lots of cmd lines saying unable to write blabla filesystem readonly20:34
pizzacocahttps://wiki.ubuntu.com/Nexus7/Installation#Troubleshooting_the_Install20:34
pizzacocaI wait until cellbatt goes down nothing happened, only scroll of theses lines20:35
pizzacocaI just tried to boot it again it is still telling blabla readonly filesystem blabla20:39
pizzacocaIs that's meaning my first install  went wrong ?20:42
pizzacocaIt took a long time during the20:42
pizzacoca$ fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img command20:42
ogra_pizzacoca, yes, that means somethign went wrong21:01
ogra_check the md5sum of the img file21:01
pizzacocaok, 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:04
ogra_nope21:15
pizzacocathanks ogra, I'll see that21:25
=== doko_ is now known as doko
ogra_bug 113243923:04
ubot2Launchpad bug 1132439 in touch-preview-images "Android and iOS have majority of the phone market share" [Critical,Confirmed] https://launchpad.net/bugs/113243923:04
darkfaderlol23:09
darkfaderthis is so funny, because you can't close-wontfix without becoming a joke23:11

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!