=== zz_chihchun is now known as chihchun | ||
=== prp^2 is now known as prpplague | ||
=== chihchun is now known as zz_chihchun | ||
brute-force | Hi 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 | ||
ppisati | ogra_: FWIW, i sent the rename patch, if you can't work on flash-kernel i can give it a look | 11:13 |
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:14 |
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:15 |
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:16 |
ogra_ | (thires neither ... but we will have to rip out their naming and replace it with ours on eery merge now) | 11:17 |
ppisati | ogra_: i didn't look at the code, but isn't an s/omap/multiarm/ change? | 11:18 |
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:19 |
ogra_ | else upgrades wont work and third party vendor kernels wouldnt either | 11:20 |
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:21 |
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:22 |
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:23 |
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:24 |
ogra_ | lool, any comment ^^ | 11:25 |
marvin24 | unfortunately, tegra will only support multiarch in 3.10 or so | 11:25 |
* lool reads up | 11:25 | |
lool | ogra_: topic is installing old kernels or multiarm kernels? | 11:26 |
ogra_ | multiarm | 11:26 |
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:27 |
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:28 |
ogra_ | lool, what bothers me is that we dont use a consitent naming with debian that would save us a delta | 11:29 |
ogra_ | marvin24, well, 3.10 isnt far :) | 11:31 |
=== chihchun is now known as zz_chihchun | ||
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:14 |
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:15 |
lool | multiarm should be sheeva or something | 12:16 |
ogra_ | heh | 12: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 check | 13: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 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
lool | uh | 14:16 |
ogra_ | and extend the flavour check a bit ... in a way that -multiarm is preferred if existing | 14:16 |
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:17 |
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: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 -omap | 14:20 |
ogra_ | (as an example) | 14:20 |
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:23 |
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:24 |
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:25 |
ogra_ | or -omap4 | 14:26 |
ogra_ | or -armadaxp | 14: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 anywhere | 14:35 |
ogra_ | iirc on your request back then | 14:35 |
* ogra_ sighs ... that whole discussion shoudl have taken place several months ago ... and debian should have been heavily involved | 14: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 anyway | 14:41 |
ogra_ | through clever conflicts/breaks/replaces login | 14:41 |
ogra_ | *logic | 14: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 work | 14: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 |
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:46 |
ogra_ | err | 14:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
ogra_ | me guesses that needs to move up | 14:54 |
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:55 |
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:56 |
* 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:57 |
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:58 |
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 | 14:59 |
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:00 |
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:01 |
ogra_ | but at least it saves us also from having that dependency stuff | 15:02 |
ppisati | so, nothing else userspace wise? | 15:02 |
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:03 |
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: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 installed | 15:08 |
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:09 |
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:10 |
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:11 |
ogra_ | else apt wont upgrade your kernel ... | 15:13 |
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:16 |
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:17 |
ogra_ | ppisati, https://www.svtronics.com/index.php?route=product/product&product_id=33 ... the artist formerly known as "panda" | 15:31 |
infinity | ppisati: Dude, "multiarm"? What? | 15:33 |
ppisati | ogra_: it's real! :) can't believe it! :) | 15:33 |
ppisati | infinity: arm multiplatform | 15:33 |
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:34 |
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:35 |
infinity | Kay. Sorry for the strong reaction. :P | 15:36 |
infinity | But yeah, we should just have generic and be done with it. | 15:36 |
=== rsalveti_ is now known as rsalveti | ||
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: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 |
infinity | ogra_: It'll work fine, like I said, it'll be the same migration path as x86 kernels in the past. | 15:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:50 |
ogra_ | suihkulokki, yep, planning to | 15:53 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
infinity | And it's pointlessly x86-specific. Fail. | 16:21 |
infinity | (It's also wrong) | 16:21 |
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:22 |
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:23 | |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
* 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:42 |
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:43 | |
infinity | omap4 does as well. | 16:44 |
ogra_ | well, good then | 16: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/localtime | 17:29 | |
ogra_ | s/he/the/ | 17:29 |
=== basiaf_ is now known as basiaf | ||
=== prp^2 is now known as prpplague | ||
ppisati | ok so | 18:06 |
ppisati | dpkg -i works | 18:06 |
ppisati | but flash-kernel is not aautomatically called | 18:07 |
ppisati | what shall i check? | 18:07 |
ppisati | infinity: ^ | 18:07 |
infinity | Erm, was it called with the omap kernel? | 18:08 |
infinity | If so, nothing should have changed. | 18:08 |
infinity | flash-kernel should have poop in /etc/kernel/postinst.d/ that triggers. | 18:09 |
ppisati | lemme se if it's called with -omap | 18:10 |
ppisati | flash-kernel: deferring update (trigger activated) | 18:12 |
ppisati | when does it get called? | 18:12 |
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:15 |
infinity | The trigger could be broken. :P | 18:16 |
ppisati | infinity: ah k | 18:16 |
ppisati | infinity: that makes more sense | 18:16 |
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:17 |
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:18 |
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:19 |
infinity | That might need a space. :P | 18:20 |
infinity | "dpkg-deb -I foo.deb | grep '^ Recommends'" | 18:20 |
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. | 18:21 |
xnox | nice | 19:35 |
ogra_ | nephew | 19:49 |
=== prp^2 is now known as prpplague | ||
mjrosenb | is 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 multiarch | 20:18 | |
ogra_ | thats the purpose of multiarch, yes | 20:18 |
pizzacoca | hi guys, may someone have time to help I ve got a pb on my N7 | 20:29 |
pizzacoca | ? | 20:30 |
ogra_ | what is it ? | 20:31 |
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:34 |
pizzacoca | I wait until cellbatt goes down nothing happened, only scroll of theses lines | 20:35 |
pizzacoca | I just tried to boot it again it is still telling blabla readonly filesystem blabla | 20:39 |
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 | 20:42 |
ogra_ | pizzacoca, yes, that means somethign went wrong | 21:01 |
ogra_ | check the md5sum of the img file | 21:01 |
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:04 |
ogra_ | nope | 21:15 |
pizzacoca | thanks ogra, I'll see that | 21:25 |
=== doko_ is now known as doko | ||
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:04 |
darkfader | lol | 23:09 |
darkfader | this is so funny, because you can't close-wontfix without becoming a joke | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!