=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [13:16] ogra_, What is the status of linux-raspi2? [13:16] linux-raspi2 | 4.2.0-1008.10 | wily-proposed/universe | source [13:16] linux-raspi2 | 4.2.0.1008.9 | wily-proposed/universe | armhf [13:17] Will it be promoted to the release pocket before beta 2? [13:19] flexiondotorg, see backlog in #ubuntu-release :) [13:29] ogra_, What does that ^^^^ mean to a layman like me? :-) [13:29] 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 " [13:29] we probably want to drop the tools :) [13:29] hmm [13:29] i doubt anyone in snappy will use them [13:29] (and i'm not sure how well suited the kernel will be for non-snappy setups) [13:29] ogra_, yup, will do. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [17:00] ogra_: Eh. How does one make a snappy-specific kernel, and why would we do such a thing? [17:01] infinity, it might have config options that arent desired in "normal" systems [17:01] ogra_: Like? [17:01] no idea, i didnt make the config :P [17:01] ogra_: We're using the x86 generic kernel for x86 snappy, so that sounds like a BS argument. [17:02] just saying i'm not sure it is suposed to be re-used outside of the snappy scope it was developed for [17:02] else we'd have used -generic with a RPi specific DT [17:02] 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. [17:03] ogra_: No, we couldn't use -generic because it's missing a ton of drivers/patches to actually work on rpi2. :P [17:03] ah [17:03] ogra_: This kernel is about enablement, not some snappy-only love-in. [17:03] thats not how i understood it, but then it is fine indee [17:03] d [17:04] (i highly doubt you will make any graphical stuff work on it as is ... but indeed i might be wrong) [17:05] 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. [17:06] (well, perhaps via the fbdev xserver if that still exists ) [17:06] 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 [17:07] 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 [17:07] thats all i'm sying [17:07] *enablement [17:09] ogra_: Sure, did I say anything about graphics? :P [17:09] 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). [17:09] the config in use was created based on requested snappy requirements ... so nobody can guarantee anything outside of that scope [17:10] i dont say that [17:10] 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. [17:10] i just say it was driven by snappy and nobody looked into making it work in any other context yet [17:10] If something is "necessary for snappy", it's necessary on all platforms, not just rpi. [17:11] ogra_: I'm slightly amused about "other contexts". Other than how it boots, snappy and regular old ubuntu server are effectively identical. :P [17:11] (Well, how it installs, boots, and manages packages, but the userspace is the same) [17:11] not sure ... [17:12] i.e. the RPi uses a very specific bootloader setup ... [17:12] you cant just use DTs from uboot [17:12] That's not snappy-specific. [17:12] That's rpi2 specific. [17:12] no. thats RPi specific [17:12] Yeah. [17:12] So, again. There's nothing snappy about this kernel. [17:12] Anyhow. I'm done ranting. [17:13] ok :) [17:13] And I yelled at Tim for listening to you about dropping half his package. :P [17:13] well, we used to drop the tools in the past from the arm kernels [17:13] (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) [17:13] ogra_: No we didn't. [17:14] ogra_: Unless you mean some distant past 6 years ago. [17:14] we definitely did [17:14] for at least 10 kernels i had to work with in the last 5 years [17:14] ogra_: ti-omap4 and armadaxp and keystone (all the ones we still support) have tools. [17:14] ogra_: The linaro kernels didn't, but they were crap. [17:14] since when does omap have tools ? [17:14] Since always. [17:14] i know we had to explicitly rip them out for years [17:15] that must have happened after 12.04 [17:15] 12.04 was a long time ago now. :P [17:15] Time to get with the times, grandpa. ;) [17:15] 12.04 was when we dropped tthe panda :) [17:16] * ogra_ shakes his cane [17:16] well, post 12.04 was