[10:06] <xnox> slangasek: cjwatson: what I am thinking is this - what is the minimal amount of features/packages we can backport to fake a non-lts like experience, without actually making a non-lts release.
[10:07] <xnox> For a lot of users - backporting quantal theme changes to precise will make them believe they are running quantal.
[10:07] <xnox> we already backported kernel and graphics stack to precise, thus hwe story/features are there.
[10:09] <xnox> firefox and thunderbird are updated already. If we can identify a small subset of ubuntu-desktop packages that significantly improve user experience (e.g. speed & maybe eye candy). It would be a win for the e.g. system76 like laptop target market.
[10:09] <xnox> E.g. I don't think anybody cares about gnome-terminal changes / updates. Yet unity improvements would be awesome.
[13:55] <slangasek> xnox: what gives me pause is that a straight backport might include disruptive behavior changes in unity, that we wouldn't normally tolerate in an SRU, and those would be difficult if not impossible to separate out
[13:55]  * stgraber waves
[13:58] <slangasek> hi - sorry, hangouts giving me fits, will have things up shortly (I hope)
[14:01] <slangasek> sorry, it's still not working
[14:02] <slangasek> is there a Canonical person here who's registered to do on-air hangouts who could run the video for us today?
[14:02] <slangasek> (at least for first session while I try to get this figured out)
[14:02] <seb128> slangasek, I can
[14:03] <seb128> my slot is empty
[14:03] <slangasek> seb128: please do :)
[14:03] <seb128> slangasek, only for the first slot though, I need to do client 1 then
[14:03] <lool> ok, hangout open
[14:03] <slangasek> seb128: yep, I'll work on trying to sort it here
[14:03] <lool> seb128: I'm ready
[14:03] <ogra_> link ?
[14:04] <seb128> http://youtu.be/ixNPyJw9Lmw
[14:04] <ogra_> seb128, i'm running this session ... not the on air one :)
[14:05] <lool> I'm on
[14:05] <ogra_> well, i would like too :)
[14:06] <stgraber> can someone send me the link please (or update summit so that it gives it to me)?
[14:07] <apw> ogra_, ^^
[14:07] <ogra_> apw, yep already PMed
[14:07] <ogra_> waiting for rsalveti
[14:07] <smagoun> The embedded youtube link in http://summit.ubuntu.com/uds-1303/meeting/21633/foundations-1303-cdimage-android-builds/ isn't working, can someone update it to the video at http://www.youtube.com/watch?v=ixNPyJw9Lmw ?
[14:08] <xnox> Is there a hangout yet?
[14:08] <seb128> xnox, cf distro channel
[14:08] <barry> xnox: i don't think so
[14:08] <xnox> seb128: barry: http://www.youtube.com/watch?v=ixNPyJw9Lmw
[14:09] <xnox> ogra_: can you update the summit with the hangout url
[14:09] <xnox> ogra_: http://www.youtube.com/watch?v=ixNPyJw9Lmw
[14:09] <xnox> ???
[14:09] <cjohnston> I just put the link in summit
[14:09] <xnox> cjohnston: thanks.
[14:11] <xnox> ogra_: stgraber: how is the android rootfs build currently?
[14:12] <ogra_> xnox, https://wiki.ubuntu.com/Touch/Porting#Building_the_image
[14:12] <stgraber> xnox: I believe at least initially the rootfs was built on Offspring and the android image was built on Jenkins
[14:13] <rsalveti> xnox: the usual android way of doing, if you ever built it
[14:13] <cjwatson> Can you describe it briefly?  I assume it has no particularly intrinsic ties to Jenkins
[14:14] <xnox> cjwatson: looks like stock android build system - get a forest of git repositories, modify configs a little bit - fire the build script "brunch" and wait till you get a rootfs blob
[14:14] <ogra_> cjwatson, https://wiki.ubuntu.com/Touch/Porting#Building_the_image
[14:15] <cjwatson> slangasek: FWIW, disabling IPv6 in Firefox fixed it for me
[14:15] <xnox> "upstream android way"
[14:15] <xnox> =)
[14:15] <apw> cjwatson, interesting i use ipv6 with it (in chromium) no problem
[14:15] <cjwatson> So did I, yesterday
[14:15] <apw> quality
[14:15] <lool> slangasek: ^
[14:16] <lool> slangasek: disabling ipv6 perhaps?
[14:16] <ogra_> cjwatson, it boils down to: phablet-dev-bootstrap [target_directory]; repo sync; . build/envsetup.sh brunch <targetdevice>
[14:16] <stgraber> it's at least not a generic ipv6 problem as I'm connected to the hangout over IPv6 here
[14:16] <cjwatson> No, I didn't debug it fully
[14:17] <cjwatson> ogra_: Right, so nothing we couldn't do on a livefs builder, say
[14:17] <ogra_> cjwatson, exactly, my proposal is to include that into BuildLiveCD or similar
[14:25] <ogra_> cjwatson, does the live builder actually have internet access ? i thought it didnt
[14:26] <xnox> ogra_: toolbox on the left -> enable "lower third" to have your name & irc nickname and a flag =)
[14:26] <ogra_> xnox, trying that since yesterday, doesnt work :(
[14:26] <xnox> ogra_: did you enable "permissions" for toolbox to access your video stream?! =)
[14:27] <ogra_> heh, this time it works
[14:27] <ogra_> HA !
[14:27] <xnox> ogra_: \o/
[14:30] <cjwatson> ogra_: Limited, I think
[14:31] <cjwatson> ogra_: We could poke a firewall hole if needed, I'm sure
[14:31] <ogra_> right, it needs to see phablet.ubuntu.com at least
[14:31] <lool> are there questions from the audience here?
[14:34] <slangasek> cjwatson: where do you disable IPv6 in firefox?  (I suspected it might be a v6 issue, but in the process of debugging my laptop overheated and I had to wait for it to cool down before I could log back in \o/)
[14:34] <cjwatson> slangasek: about:config, search for ipv6
[14:34] <cjwatson> I forget the exact key name but it's obvious
[14:34] <slangasek> cjwatson: ack, thanks
[14:39] <ogra_> lool, http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/
[14:42] <ogra_> lool, http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/quantal-ubuntu_stamp
[14:45] <xnox> slangasek: what's that flag?
[14:46] <joe-uds> why not have jenkins update the '/latest' link rather than polling?
[14:47] <ogra_> jenkins has no write access to access cdimage
[14:47] <ogra_> (and is unlikely to get it)
[14:48]  * xnox has no clue about hostnames & network =)
[14:48] <pgraner> cjohnston, its in the qa lab
[14:48] <pgraner> cjwatson, ^^^^
[14:48] <slangasek> xnox: "American Samora", according to Google
[14:49] <ogra_> heh, pgraner isnt using xnox' tab completion fix to xchat :)
[14:49] <slangasek> joe-uds: because we're used to thinking of the cdimage server being inaccessible :-)
[14:49] <ogra_> :)
[14:49] <pgraner> cjwatson, the qa lab is an internal canonical network, just let retoaded know and he'll take care of it
[14:50] <pgraner> cjwatson, the firewall bits etc we do it all the time
[14:50] <pgraner> slangasek, ^^^^^^^^^^^
[14:50] <xnox> https://launchpad.net/ubuntu/+source/xchat/2.8.8-7ubuntu2 even references cj watson & c johnston
[14:50] <slangasek> pgraner: the issue is going to be on nusakan's side :)
[14:51] <pgraner> slangasek, thats fine we have two way all the time
[14:53] <cjwatson> pgraner: cool, thought so
[14:54] <cjwatson> jenkins certainly *can* have write access to cdimage via a suitably-careful trigger
[14:55] <lool> cjwatson: So jenkins has tons of extra plugins and what not, and SSH / SFTP publishing are builtin features anyway, but the easiest would likely be to just run whatever unix commands we need to run at the end of the build scripts for the smoke tests
[14:55] <lool> e.g. if it's a HTTP trigger or a SSH trigger, just run it from the shell script configured in the jenkins job to do the build
[14:55] <cjwatson> OK, so it's just ssh cdimage@nusakan trigger
[14:55] <lool> exactly
[14:55] <lool> hmm maybe we want to push the smoke tests logs or something
[14:56] <cjwatson> And a parser for $SSH_ORIGINAL_COMMAND or whatever it's called
[14:56] <cjwatson> All I need is success/failure for a given build
[14:56] <cjwatson> Logs can stay where they are
[14:56] <cjwatson> Perhaps a link to them as a nicety, but it's not that important :)
[14:56] <lool> cjwatson: so build id and result; sounds like a ssh command wrapper with 2 args then
[14:56] <cjwatson> yep
[14:57] <cjwatson> I'll work out the cdimage side and then say what I need
[14:57] <lool> ok
[14:57] <lool> I don't have write access to the jenkins side, but I would be happy to pass on
[14:57] <lool> likely to Sergio
[14:57] <ogra_> yeah
[14:57] <lool> ogra_: thanks for the session!
[14:57]  * lool moves to client-1
[14:58] <cjwatson> In the first instance the jenkins instance in question would be the one that runs our x86 smoke-tests :-)
[14:58] <ogra_> lool, thanks for participating !
[14:58] <slangasek> ogasawara: fwiw G+ has been not very usable for me today; I managed to get connected to a session last hour and managed to launch a test on-air hangout, but it's back to giving me fits
[14:59] <slangasek> ogasawara: do you think you could launch the on-air hangout (under your canonical acct) and pass me the urls for summit?
[14:59] <xnox> slangasek: what's the next session for you? Kylin or Webkit or Communit/Quality ?
[14:59]  * ogra_ ponders where to go ... 
[15:00] <slangasek> ogasawara: oh; ignore me, that's not for another hour :)
[15:00] <slangasek> so I have time to argue with software
[15:00] <slangasek> xnox: I was going to poke my nose into the kylin one
[15:00] <ogasawara> slangasek: if it's not sorted by then, just let me know
[15:01] <xnox> slangasek: I'm thinking webkit =)
[15:01] <xnox> slangasek: didn't want kylin to be left alone though.
[15:46] <slangasek> ogasawara: ok, G+ has stopped throwing tantrums for the moment; hangout is up and going
[15:47] <slangasek> ah, though that apparently leaves us with 15 minutes of excess footage at the beginning of the video if I do it that way ;)
[15:47] <slangasek> so, cancelled and will relaunch in a little bit
[15:50] <seb128> slangasek, I think you can edit the videos to cut the non-interesting bits once they are published
[15:51] <seb128> slangasek, yeah, there is an edit function with "cut" on it, seems trivial to use
[15:53] <slangasek> seb128: oddly, I have used it before and when I went into my video list yesterday couldn't find it
[15:53] <slangasek> regardless... hangout reset
[15:53] <seb128> slangasek, weird, here my video list has a "modifier" (modify/change) combo next to the video
[15:53] <seb128> slangasek, e.g the list in https://www.youtube.com/my_videos
[15:54] <seb128> or if you have a grid view it's the second icon you get on mouseover
[15:54] <slangasek> yeah, I'm not finding the 'cut' option anywhere
[15:55] <seb128> slangasek, you have a top banner with icons
[15:56] <seb128> info / changes /audio
[15:56] <seb128> it's the second icon
[15:56] <seb128> by default you land on the first "tab", info
[15:56] <slangasek> ah righ
[15:57] <slangasek> so in English it says 'Enhancements'
[15:57] <seb128> the translation is better :p
[15:57] <slangasek> which is less than clear, yeah :)
[16:01] <sconklin_> sconklin
[16:03] <arges> Also with the 3.9 kernel will there be an upstream stable branch maintained? or will need to maintain our own like 3.5?
[16:04] <sforshee> arges, I don't think we know at this point
[16:04] <gQuigs> yes, and please make it a real installable PPA so we can easily upgrade
[16:06] <arges> I primarily use the mainline ppa builds for bug fixing, for example does this bug affect upstream
[16:07] <gQuigs> arges: right but can that really be called a PPA, you can't add it to your sources
[16:07] <arges> bjf: and would be apply all of our sauce patches on top of the daily PPA?
[16:07] <bjf> arges, yes
[16:09] <einonm> arges: all recent kernel version have a stable branch. Do you mean a longterm branch?
[16:09] <arges> apw: so from a user of a develpoment release, if they hit a bug with a 'normal' kernel do we ask them to use the PPA daily kernel before proceeding?
[16:10] <arges> yes
[16:11] <arges> so if it affects a development release + daily PPA, we need to target upstream pretty much
[16:11] <arges> then wait for it to trickle down
[16:11] <chiluk__> but it should be closer to upstream right? so theoretically there will be less giberish to bring in..
[16:12] <arges> einonm: yea -longterm
[16:17] <diwic> bjf, since greg did not pick 3.8, maybe...
[16:18] <geofft> Am I mishearing, or is the claim that if you install 12.04.1 instead of 12.04, you don't get 5 years security support?
[16:18] <jjohansen> ogasawara: we did commit to the 14.04 kernel back on 12.04 for the life of 12.04
[16:19] <apw> geofft, you are miss hearing i think
[16:19] <jjohansen> geofft: not exactly, just that if you install 12.04.1 you have to roll forward to the 14.04 HWE stack on 12.04
[16:20] <geofft> oh, that's going to exist? OK.
[16:20] <geofft> I'm just curious what the expected path is if I install a server say now and want it supported until '17
[16:21] <geofft> is it security updates, new kernel with 14.04, security updates, new kernel with 16.04?
[16:22] <gQuigs> this is going to require more users to test on the kernel testing "PPA" right?   Could we make that easier for people to install and stay up to date on the different kernel PPAs?
[16:22] <jjohansen> geofft: you can stay on 12.04 with security support for 5 years. The HWE stack for 12.04 will stop with 14.04
[16:22] <geofft> Right, but suppose my server doesn't boot with 12.04.0 and requires the first HWE stack.
[16:23] <jjohansen> geofft: so if you use the HWE stack, and are staying with 12.04, you WON'T get as 16.04 HWE stack on 12.04
[16:23] <geofft> and will I have options for staying within security support for five years?
[16:23] <jjohansen> geofft: you will stabilize at the 14.04 HWE stack
[16:23] <geofft> OK.
[16:23] <bjf> geofft, you can start with a 12.04.x and then you will want to upgrade to 14.04 when it comes out
[16:23] <jjohansen> geofft: yes the 14.04 HWE stack will be supported for the life of 12.04
[16:24] <geofft> bjf: if I'm running a server on the LTS, I'd rather not upgrade the userspace for five years.
[16:24] <gQuigs> that makes it harder to test....
[16:24] <jjohansen> bjf: no, we commited to a 14.04 HWE stack on 14.04
[16:24] <jjohansen> s/14.04/12.04/
[16:24] <bjf> geofft, i understand
[16:24] <diwic> dkms = binary graphics?
[16:24] <jjohansen> you don't have to roll forward to full 14.04
[16:24] <bjf> jjohansen, yes, but we don't support the point releases for 5 years
[16:24] <diwic> or all sorts of dkms packages?
[16:24] <brendand_> what are the plans for kernel updates in raring (assuming a rolling release happens)?
[16:25] <arges> apw: from a bug fix perspective, lets say I fix something upstream and we want all Ubuntu kernel versions to have this fix. Where all would these patches land? Development / SRU etc?
[16:26] <geofft> apw: Okay, that makes sense, thanks.
[16:26] <bjf> geofft, sorry for confusing you
[16:26] <geofft> apw: "some kernel" under security support is plenty
[16:27] <diwic> QUESTION: could you clarify *what* dkms packages that will / will not be tested?
[16:28] <jjohansen> apw: right
[16:28] <jjohansen> thanks for bringing that up
[16:29] <diwic> apw, thanks
[16:30] <cking> apw,  should we call out to community to find out what kind of DKMS packages are being used?
[16:30] <arges> hey did you guys see my question ^^
[16:30] <arges> ogasawara: bjf ^^^
[16:32] <arges> apw: ok and those versions are going to have names? since we have rolling releases
[16:33] <SpamapS> heavy testing and a more continuous model would be preferred over anything that involves the fairly limited bandwidth of the SRU team
[16:33] <arges> haha
[16:33] <arges> ok. cool thanks
[16:33] <SpamapS> we don't really look at it anyway ;)
[16:34] <arges> yea i usually try to verify a test build before submitting anyway
[16:34] <arges> s/usually/always
[16:34] <SpamapS> automate.. automate.. automate..
[16:35] <arges> yup as much as possible. some bugs are very difficult to automate (specific hardware requirements, intermittent failures etc)
[16:35] <cking> +1 to apw's comments, that's what I was driving at - good to flag it up those looking after DKMS packages
[16:35] <diwic> but if the new actually breaks dkms packages; won't it get stuck in -proposed due to rdepends testing?
[16:35] <geofft> Whose responsibility is testing the DKMS packages?
[16:36] <SpamapS> diwic: only if it explicitly declares breakage
[16:36] <geofft> We care about OpenAFS -- should I set up on an organizational machine a cronjob to test build it against the PPA?
[16:36] <geofft> Or can we get automatic testing in Launchpad somehow?
[16:36] <SpamapS> diwic: brittney doesn't actually try to install every package with every other package. It just runs the graph.
[16:36] <geofft> Just whether it builds, is sufficient for OpenAFS
[16:36] <geofft> since it's a filesystem, not a hardware driver
[16:36] <cjwatson> Though I'd kind of like to test file conflicts too
[16:36] <geofft> Sure, that makes sense.
[16:36] <cjwatson> Doesn't yet, though
[16:37] <diwic> SpamapS, hmm
[16:37] <geofft> But if there's LP test build infrastructure, that would be better than setting up our own server for test builds
[16:37] <plars> geofft: if you are just worried about it building, getting an autopkgtest in for it would be a good start
[16:37] <cjwatson> LP has no test infrastructure except for what happens during package builds
[16:37] <cjwatson> Tests are done by Jenkins
[16:38] <geofft> OK. I'm not super familiar with Ubuntu's test infrastructure, but I should go figure that out
[16:38] <geofft> But if there were a way I could get a test in the OpenAFS package that runs before kernels were pushed, that would be wonderful
[16:38] <arges> thanks
[16:38] <ogasawara> slangasek: you can kill the hangout whenever you're ready
[16:38] <kamal> thanks folks
[16:38] <Limurx> Most competent, reasonable and comprehensible session so far! Thanks!
[16:39] <diwic> thanks
[16:39] <cking> Limurx, +1 that
[16:39] <geofft> thanks all for your work, btw. I know I'm just sitting here asking questions :)
[16:42] <bjf> geofft, np, you can also ask in ubuntu-kernel channel any time
[16:53] <cjwatson> geofft: So the plan is to let you do that with autopkgtest; they are not yet integrated into proposed-migration but it's on the list
[16:53] <cjwatson> Although exactly how triggering that on kernel upgrades specifically would work is an open question (due to the way dependencies on the kernel work, or rather don't)
[16:59] <slangasek> ogasawara: ok, killed ;)
[18:03] <joe-uds_> is there a video link?
[18:07] <ogra_> joe-uds_, once the session starts
[18:07] <ogra_> (7min)
[18:07] <joe-uds_> ogra_: didn't realize I was early :)
[18:10]  * ogra_ quickly cares for fresh cofee
[18:12] <slangasek> sorry folks, this next session is being cancelled
[18:12] <pgraner> slangasek, the providing monthly snapshotting?
[18:13] <slangasek> we think we need to sort through the discussion that's been taking place on the list, and do further requirements gathering, before we try to have an implementation discussion
[18:13] <slangasek> pgraner: yes
[18:13] <pgraner> slangasek, ack sounds good
[18:13] <slangasek> sorry for the short notice
[18:13] <joe-uds_> slangasek: ack, thanks
[18:13] <tumbleweed> thanks slangasek
[18:16] <xnox> slangasek: I mean I can rsync dists/ and add reverse proxy to archive.ubuntu.com / launchpadlibrarian to fetch the debs. And updates the dists/ every month or even provide monthly folders.
[18:17] <xnox> Completely outside of launchpad. Chuck it over to the mirror network and be done with it. And the launchpad side delay deb removal from the mirrors by e.g. 3 months from rolling. So it's not like that part is hard.
[18:18] <xnox> the other questions of SRUs/security will need to be solved for rolling anyway independently of the snapshots.
[18:18] <slangasek> xnox: wow, that's some serious breaking of threads :)
[18:19] <xnox> slangasek: my view is that _all_ packages in a rolling release should be phased. And people given a notch to speed up phasing to get me all (current development release mode), participate (phase at 50% because I am an enthusiast), I want working updated machine (phase at 100% after everyone else)
[18:20] <xnox> that way when regressions happen we can surplant the phasing.
[18:20] <xnox> Or phase quicker for security / critical bugs.
[18:21] <xnox> cjwatson was mentioning that phasing everything will enquire in "additional <something>" on launchpad / publishing side and will not scale. But I want to know further details about it.
[18:21] <cjwatson> Eh?
[18:21] <dobey> is the stream not up yet?
[18:21] <cjwatson> dobey: 18:12 <@slangasek> sorry folks, this next session is being cancelled
[18:21] <xnox> From my understanding, phasing everything has no added impact on launchpad/mirror/publishing side, as the decision is done enterily client side.
[18:21] <cjwatson> 18:13 <@slangasek> we think we need to sort through the discussion that's been taking place on the list, and do further requirements gathering, before we try to have an implementation discussion
[18:22] <dobey> oh
[18:22] <dobey> thanks cjwatson
[18:22] <cjwatson> xnox: So, every time you change the phased-update-percentage, that's a new publication (BPPH)
[18:22] <xnox> cjwatson: I may be wrong, but I remember something like "phasing everything will require more publishing cycles" but I didn't understand it.
[18:22] <cjwatson> And indeed it requires republishing the pocket in question (which is obviously a necessity - you have to rewrite Packages)
[18:22] <cjwatson> This is something to bear in mind; I don't think it's a blocker
[18:23] <cjwatson> My concern about phasing everything is more that we have zero experience with actually using phased-update-percentage right now, e.g. how it will interact with dependency chains, and I'd rather try it out in rather simpler cases first and gain that experience
[18:24] <ev> cjwatson: doesn't it not touch dep chains?
[18:24] <cjwatson> ev: be my guest if you want to work that out :-0
[18:24] <cjwatson> :-)
[18:24] <xnox> cjwatson: ok.
[18:24] <cjwatson> I'm not convinced it won't cause spurious removals; the code is fairly crude
[18:25] <ev> cjwatson: well I mean that it ignores the phasing for any dependencies surely
[18:25] <cjwatson> But I didn't really want to go mucking around without some idea of roughly what kinds of things might go wrong
[18:25] <ev> so it's hard to phase something like libgtk since it's a dep for everything
[18:25] <cjwatson> ev: There's no explicit code to do that.  If it happens it's an emergent effect
[18:25] <cjwatson> Which is entirely possible given u-m
[18:25] <ev> but makes this problem easier
[18:25] <ev> ah
[18:26] <cjwatson> All that the phase handling does is rip the package in question out of the updates list
[18:26] <cjwatson> Now, in theory I think anything that depends on it will end up held back as a result
[18:26] <cjwatson> But what about sets of packages from the same source that all need to be installed together - I suspect that, as the code stands, the probability of them being selected will be raised to the power of the number of packages in question
[18:27] <cjwatson> i.e. they will be disproportionately unlikely to be selected
[18:27] <cjwatson> The client code definitely needs work
[18:27] <xnox> cjwatson: right.
[18:28] <ev> I don't see why it would be held back in that case. My understanding is that it's just hiding it from the updates list. So while libgtk may not show in the UI because it's below the threshold, if fooapp depends on it and fooapp is to be installed, it will be
[18:28] <ev> since this is happening a level up from apt
[18:28] <xnox> cjwatson: my idea was that if A and B are phased at 50% and libgtk is phased at 5%, those that "hit" a or b will get the libgtk as a dep as well. That means that the more reverse-depends a package has (e.g. libgtk) the slower it should be phased, as it is pulled in by _other_ packages in phasing as well.
[18:29] <cjwatson> ev: I can believe that that may be true, but I have no evidence for it
[18:29] <ev> :)
[18:29] <cjwatson> xnox: Of course remember that actually requiring the *new* version of gtk will be quite rare
[18:29] <cjwatson> (And likewise for most dependencies)
[18:30] <cjwatson> ev: I thought that the updates list was computed after asking the depcache to upgrade, though; if you uncheck things in it by hand that have reverse-deps, all of the reverse-deps are automatically unchecked too, IIRC
[18:30] <xnox> cjwatson: sure. but e.g. new major glibc every next package build after that upload will pretty much depend on a >> 1.17
[18:31] <cjwatson> xnox: Hardly, given symbols files
[18:31] <xnox> cjwatson: ok, true. =)
[18:31] <cjwatson> glibc was practically the poster child for symbols files in the first place
[18:31] <xnox> cjwatson: even better than.
[18:31] <ev> cjwatson: eep. Still, it's fixable.
[18:33] <cjwatson> Yep - like I say, would just like some real-world experience (or possibly a u-m test suite that's less painful to experiment in ...)
[18:33] <cjwatson> Spoiled by at least some parts of the LP test suite
[18:33] <cjwatson> (OK, some parts of it are dire, but if you find bits that use the right helpers it can be quite pleasant)
[18:40] <tumbleweed> a derived distro lets you do new releases of your desktop, on the LTS Ubuntu base
[18:40] <tumbleweed> err
[18:40] <tumbleweed> wrong window
[18:41] <xnox> cjwatson: so I guess we should start a test suite for all the /whatifs/. Cause even with SRUs we have cases of adding symbols to a library and a app potentially starting to use it and both "published" simultaniously, yet with phasing, a client might hit none, one or the other or both. And we do want to know what will happen then.
[18:42] <cjwatson> Perhaps start by refactoring u-m's test suite
[18:42] <cjwatson> If you spend about ten minutes on it you'll see the problems :)
[18:42] <cjwatson> The only way to add cases is to manually add trees of sample Packages and dpkg/status files, which is pretty cumbersome
[18:43] <cjwatson> Even just fixing that would make reasoning about the rest of this a whole lot easier
[18:43] <xnox> cjwatson: ok.
[18:43] <xnox> cjwatson: that sounds a lot like a copy&paste apt-get test suite?!
[18:44] <cjwatson> Could well be
[18:44] <xnox> with joethesixpack archive signing key and the rest of the bells and whistles.
[18:44] <cjwatson> It would be massively improved by having the cases generated dynamically
[18:45] <cjwatson> When I was doing the Conflicts/Replaces work recently, I spent a day or two hammering the test suite up to the point where I could actually add even one thing to it effectively, but there was still clearly lots to do
[18:46] <cjwatson> I'd like to be able to say self.add_package("foo", conflicts="bar (<< 1.1)") or something like that
[18:47] <cjwatson> I think the new apt integration tests have something very much along those lines in shell; it looked very nice to use
[18:48] <xnox> cjwatson: no pseudo language to describe sample packages/status?
[18:48] <xnox> fair enough.
[19:02]  * slangasek waves
[19:03] <xnox> hola =)
[19:03]  * xnox goes to the other room where logind and consolekit are discussed.
[19:04] <cjwatson> ich auch
[19:04] <smb> cjwatson, sehr schön
[19:05] <cjwatson> danke ;-)
[19:05] <smb> cjwatson, yeah, sorry not very nice I guess. lacking a quick response at that time of day
[19:08] <ogra_> ogasawara, mings sharing the hangout url ?
[19:10] <smb> hangout broke
[19:10] <cyphermox> uhoh.
[19:10] <ppisati> ja
[19:10] <sforshee> yep, for me too
[19:12] <ricmm> feed is down again
[19:12] <smb> yup
[19:12] <slangasek> blast
[19:12] <slangasek> sorry
[19:13] <krabador> heh...
[19:13] <mrman_> Stream is down
[19:13] <jdstrand> *sigh*
[19:13] <slangasek> ogasawara: maybe you could host?  browser probs again
[19:13] <slangasek> (my own doing, but)
[19:13] <krabador> google don't wants that people talks about other mobile kernels....
[19:13] <ogasawara> slangasek: sure, just a sec
[19:14] <slangasek> oh; or did it come back now?
[19:14] <mrman_> back up
[19:14] <smb> yes back
[19:14] <krabador> back
[19:14] <slangasek> ok, I will keep my hands off the browser :-)
[19:18] <cyphermox> regdomain: yeah, that's kind of broken everywhere right now
[19:18] <cyphermox> we ought to fix crda to at least get the right info from the installer
[19:19] <cyphermox> (on desktop_
[19:19] <sforshee> wpa_supplicant normally does the heavy lifting
[19:19] <sforshee> as far as configuring wireless
[19:20] <ogra_> on my SGS2 i can only get wlan0 up actually using the android wpa_supplicant (which seems to load the FW as well etc)
[19:20] <cyphermox> sforshee: well, it doesn't currently appear to be doing much for this, at least on a portion of desktop installs: cf. iw reg get.
[19:20] <ogra_> and even though i can bring up the device i cant access it
[19:21] <cyphermox> then as awe mentions, it gets more complicated on touch, due to the lack of udev and stuff
[19:21] <cyphermox> sforshee: we can all talk about it later
[19:21] <sforshee> cyphermox, regulatory is a bit of a side issue
[19:21] <sforshee> cyphermox, sure
[19:21] <cyphermox> aye
[19:21] <ogra_> rtg_, you are supposed to make calls ! not surf all day !
[19:21] <cyphermox> why isn't he on IRC anwyay
[19:22] <sforshee> for these fullmac devices the regulatory probably is done in the hw anyway
[19:22] <sforshee> I don't know how the interaction is handled
[19:22] <sforshee> broadcom does have an open-source fullmac driver in the kernel, I wonder if it supports the hw in question
[19:23] <ogra_> sforshee, it doesnt on the n7 (we tested it)
[19:23] <sforshee> ogra_, ack
[19:23] <ogra_> (and i doubt it does on my SGS2 ... which admittedly isnt a supported device)
[19:23] <cyphermox> sforshee: in hardware, I don't know too well how it works, but at least on the intel drivers it seems like the userspace gets a netlink message, udev reacts on it to set the regdomain
[19:23] <cyphermox> but we never configure the default reg domain, so it always remains at 00
[19:24] <sforshee> ogra_, I do have a pretty good working relationship with one of the broadcom engineers if we want to inquire with them
[19:24] <sforshee> cyphermox, yeah but that's softmac where mac80211 handles the regulatory
[19:24] <ogra_> that might make sense
[19:24] <cyphermox> yeah
[19:24] <sforshee> I'll have to look at what happens for fullmac
[19:28] <bjf>  http://kernel.ubuntu.com/~kernel-ppa/configs/raring/reviews/uds-13.03/n7initial-issues.html
[19:34] <sforshee> does autoloading of modules work in this bastardized android/ubuntu image?
[19:35] <ogra_> sure
[19:35] <sforshee> okay, I thought udev wasn't running
[19:35] <ogra_> its a plain ubuntu, just a kernel built from android source
[19:35] <rsalveti> not yet :-)
[19:35] <rsalveti> it'll be
[19:35] <ogra_> oh, heh
[19:35] <ogra_> we'Re talking different things
[19:35] <sforshee> the phablet image is what I'm talking about
[19:35] <ogra_> yeah, no udev there
[19:35] <sforshee> so that might be a concern wrt making some things into modules
[19:36] <cking> apw, options like CC_OPTIMIZE_FOR_SIZE is really dependant  on how good gcc is, has that been checked to see how good it is?
[19:36] <ogra_> cking, linaro did a lot on that iirc
[19:36] <cking> ogra_, ok, I will defer to their wisdom ;-)
[19:37] <ogra_> (not sure who anymore though)
[19:37] <ogra_> that was a while ago
[19:37] <cking> ..or which version of gcc .. ;-)
[19:39] <sforshee> awe_, did they switch stacks for all devices or just those using broadcom wireless chipsets?
[19:40] <sforshee> e.g., what does the n4 use?
[19:40] <awe_> AFAIK, all devices
[19:40] <ogra_> cyphermox, ^^^^
[19:40] <awe_> but I could be wrong....
[19:40] <awe_> rsalveti, ^^
[19:41] <rsalveti> nexus 4 is atheros
[19:41] <sforshee> rsalveti, right, I just wandered if they were still using the broadcom userland software for bluetooth that awe_ was talking about
[19:41] <cyphermox> what's this about?
[19:41] <cyphermox> oh bluetooth
[19:41] <rsalveti> oh, sorry, about bluetooth
[19:41] <ogra_> cyphermox, we were discussing BT
[19:41] <rsalveti> not sure
[19:42] <cyphermox> I don't know
[19:42] <cyphermox> I suspect all?
[19:42] <awe_> sforshee, I really haven't looked at bluedroid at all...
[19:42] <cyphermox> if not, then that's good news, but heh
[19:42] <awe_> we need someone to draw some basic diagrams of the two stacks, and involved components...
[19:42] <cyphermox> last I touched a nexus 4 I didn't think of looking
[19:42] <sforshee> I've got an n4, I'll take a look
[19:42] <awe_> from kernel to UI
[19:42] <awe_> sforshee, thanks
[19:43] <sforshee> might help if I turned on bluetooth ...
[19:44] <ogasawara> slangasek: we've ended early, you can kill the hangout