**** BEGIN LOGGING AT Wed Sep 23 02:59:59 2015 Sep 23 13:16:33 ogra_, What is the status of linux-raspi2? Sep 23 13:16:54 linux-raspi2 | 4.2.0-1008.10 | wily-proposed/universe | source Sep 23 13:16:54 linux-raspi2 | 4.2.0.1008.9 | wily-proposed/universe | armhf Sep 23 13:17:18 Will it be promoted to the release pocket before beta 2? Sep 23 13:19:56 flexiondotorg, see backlog in #ubuntu-release :) Sep 23 13:29:11 ogra_, What does that ^^^^ mean to a layman like me? :-) Sep 23 13:29:32 http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ... "linux-raspi2-tools-4.2.0-1008/armhf unsatisfiable Depends: linux-raspi2-tools-common " Sep 23 13:29:32 we probably want to drop the tools :) Sep 23 13:29:32 hmm Sep 23 13:29:32 i doubt anyone in snappy will use them Sep 23 13:29:34 (and i'm not sure how well suited the kernel will be for non-snappy setups) Sep 23 13:29:34 ogra_, yup, will do. Sep 23 17:00:51 ogra_: Eh. How does one make a snappy-specific kernel, and why would we do such a thing? Sep 23 17:01:29 infinity, it might have config options that arent desired in "normal" systems Sep 23 17:01:37 ogra_: Like? Sep 23 17:01:46 no idea, i didnt make the config :P Sep 23 17:01:56 ogra_: We're using the x86 generic kernel for x86 snappy, so that sounds like a BS argument. Sep 23 17:02:07 just saying i'm not sure it is suposed to be re-used outside of the snappy scope it was developed for Sep 23 17:02:46 else we'd have used -generic with a RPi specific DT Sep 23 17:02:52 ogra_: And most of the components on snappy weren't "meant to be used outside the classic server scope they were designed for", good thing no one made that arbitrary restriction. Sep 23 17:03:15 ogra_: No, we couldn't use -generic because it's missing a ton of drivers/patches to actually work on rpi2. :P Sep 23 17:03:26 ah Sep 23 17:03:29 ogra_: This kernel is about enablement, not some snappy-only love-in. Sep 23 17:03:48 thats not how i understood it, but then it is fine indee Sep 23 17:03:50 d Sep 23 17:04:51 (i highly doubt you will make any graphical stuff work on it as is ... but indeed i might be wrong) Sep 23 17:05:59 ogra_: I mean having a separate source package is about enablement. Yes, the driving force behind supporting the rpi2 at all is snappy, but it's ridiculous to limit it to just one use-case. Sep 23 17:06:06 (well, perhaps via the fbdev xserver if that still exists ) Sep 23 17:06:23 ogra_: Like if I told you that I'm building packageX with options that make it unsuitable for snappy because screw you, it's a server package. :P Sep 23 17:07:41 well, it was created for cloud and embedded use for now ... nobody looked at making kms graphical stuff work or anything so re-using it for desktop enabled might or might not work Sep 23 17:07:46 thats all i'm sying Sep 23 17:07:58 *enablement Sep 23 17:09:11 ogra_: Sure, did I say anything about graphics? :P Sep 23 17:09:58 ogra_: Dropping tools and debug symbols made it unsuitable for anyone doing any debugging on a deb-based system (or, alternately, for anyone who wants to sort out how to deb2snap those bits to debug on a snappy system, if you want to pretend snappy is the whole world). Sep 23 17:09:59 the config in use was created based on requested snappy requirements ... so nobody can guarantee anything outside of that scope Sep 23 17:10:23 i dont say that Sep 23 17:10:29 ogra_: Either way. The argument is silly. If we're using generic kernels elsewhere, this one should have a config review and be a generic kernel, not a unique snowflake. Sep 23 17:10:48 i just say it was driven by snappy and nobody looked into making it work in any other context yet Sep 23 17:10:57 If something is "necessary for snappy", it's necessary on all platforms, not just rpi. Sep 23 17:11:37 ogra_: I'm slightly amused about "other contexts". Other than how it boots, snappy and regular old ubuntu server are effectively identical. :P Sep 23 17:11:55 (Well, how it installs, boots, and manages packages, but the userspace is the same) Sep 23 17:11:58 not sure ... Sep 23 17:12:15 i.e. the RPi uses a very specific bootloader setup ... Sep 23 17:12:22 you cant just use DTs from uboot Sep 23 17:12:30 That's not snappy-specific. Sep 23 17:12:38 That's rpi2 specific. Sep 23 17:12:39 no. thats RPi specific Sep 23 17:12:42 Yeah. Sep 23 17:12:53 So, again. There's nothing snappy about this kernel. Sep 23 17:12:57 Anyhow. I'm done ranting. Sep 23 17:13:02 ok :) Sep 23 17:13:11 And I yelled at Tim for listening to you about dropping half his package. :P Sep 23 17:13:29 well, we used to drop the tools in the past from the arm kernels Sep 23 17:13:48 (And, for the record, there are people, including our own kernel engineers, running non-snappy Ubuntu on rpi2, cause snappy itself is a crap development/debugging environment) Sep 23 17:13:55 ogra_: No we didn't. Sep 23 17:14:07 ogra_: Unless you mean some distant past 6 years ago. Sep 23 17:14:08 we definitely did Sep 23 17:14:21 for at least 10 kernels i had to work with in the last 5 years Sep 23 17:14:24 ogra_: ti-omap4 and armadaxp and keystone (all the ones we still support) have tools. Sep 23 17:14:36 ogra_: The linaro kernels didn't, but they were crap. Sep 23 17:14:42 since when does omap have tools ? Sep 23 17:14:48 Since always. Sep 23 17:14:54 i know we had to explicitly rip them out for years Sep 23 17:15:15 that must have happened after 12.04 Sep 23 17:15:38 12.04 was a long time ago now. :P Sep 23 17:15:48 Time to get with the times, grandpa. ;) Sep 23 17:15:51 12.04 was when we dropped tthe panda :) Sep 23 17:16:10 * ogra_ shakes his cane Sep 23 17:16:33 well, post 12.04 was **** ENDING LOGGING AT Thu Sep 24 02:59:57 2015