[04:03] <pitti> Good morning
[05:44] <didrocks> good morning
[06:25] <tjaalton> didrocks: how's the new intel? :)
[06:29] <didrocks> tjaalton: not crashy (yet)
[06:30] <didrocks> tjaalton: will keep you posted if I see anything today :p
[06:57] <tjaalton> cool
[07:05]  * RAOF should really check if his hang-on-resume is really DRI3 related.
[07:35] <tjaalton> RAOF: you mean if we could enable it again?
[07:36] <RAOF> Yeah.
[07:36] <RAOF> Or, rather, I enabled it and noticed that things were screwy.
[07:36] <tjaalton> what gen do you have?
[07:36] <RAOF> 7
[07:36] <RAOF> Iris pro 5200
[07:36] <tjaalton> so IVB
[07:36] <RAOF> Oh, might be off by a gen. Haswell :)
[07:37] <tjaalton> oh right
[07:37] <RAOF> Oh, that's right.
[07:37] <RAOF> That's gen 7.5 :)(
[07:37] <tjaalton> yeah
[07:37] <tjaalton> good, I have haswell too
[07:37] <tjaalton> too bad it doesn't do S3
[07:37]  * RAOF was *pretty* sure broadwell was 8, so...
[07:37] <tjaalton> yep
[07:37] <RAOF> Well, this laptop S3s fine.
[07:37] <RAOF> And it even *mostly* comes back.
[07:37] <tjaalton> mine is an intel beta
[07:38] <RAOF> Yeah, had one of those.
[07:38] <tjaalton> right mine does suspend, but is totally worthless after resume
[07:38] <RAOF> If this comes back, it comes back fine.
[07:38] <RAOF> It just sometimes doesn't come back.
[07:39] <RAOF> But now that I consult my Xorg.0.log I don't think I can blame DRI3 for that anymore.
[07:39] <tjaalton> good ole harris beach.. can't understand why they only sent one qual upgrade unit to us.. two weeks after the betas arrived
[07:40] <RAOF> So, in related news, Haswell is buggy on 15.10 :)
[07:40] <seb128> good morning desktopers
[07:40] <tjaalton> does wily have 4.2 already?
[07:40] <RAOF> NO
[07:40] <RAOF> Ahem. No.
[07:40] <tjaalton> heh
[07:40] <darkxst> hey seb128
[07:41] <pitti> bonjour seb128
[07:41] <RAOF> I know that enables some PPPPPPGT thingy that's been in development since forever.
[07:41] <seb128> hey RAOF tjaalton darkxst pitti
[07:41] <tjaalton> hey seb128
[07:41] <RAOF> Yo seb128!
[07:41] <darkxst> indeed seems unpaired devices won't show up in g-c-c with bluez5 ;(
[07:41] <seb128> darkxst, thanks for testing!
[07:43] <darkxst> paired devices do show up though, I'll try with 3.16
[07:46]  * didrocks confirms
[07:46] <seb128> did you try under unity?
[07:46] <didrocks> yep
[07:47] <seb128> k, weird
[07:47] <seb128> here it writes "No bluetooth adapter found"
[07:47] <didrocks> I paired the other way (from devices to laptop), so didn't notice
[07:47] <didrocks> seb128: I meant, I tried our u-c-c
[07:47] <didrocks> which is basically the same behavior for unpaired device (which makes sense)
[07:48] <seb128> ah, right
[07:48] <seb128> didrocks, can you try g-c-c.real?
[07:49] <seb128> we are talking about g-c-c specifically
[07:49] <seb128> u-c-c works for me
[07:49] <darkxst> oh, after I told my phone to forget laptop, it showed up in g-c-c
[07:49] <seb128> g-c-c doesn't
[07:50] <didrocks> seb128: well, g-c-c.real does the same "no bluetooth adapter found" in unity
[07:50] <didrocks> darkxst: ah, let me try
[07:50] <seb128> didrocks, k, so not only me
[07:50] <seb128> that seems buggy, or it depends on some gnome component to be on the bus or something
[07:50] <darkxst> I dot not a "no bluetooth adapter found" in g-c-c
[07:50] <darkxst> do not get
[07:51] <didrocks> yeah, not sure what interface it's expecting
[07:51] <didrocks> darkxst: hum, disociating both sides doesn't show the device up in u-c-c for me though
[07:52] <darkxst> didrocks, I was talking about g-c-c btw
[07:52] <didrocks> darkxst: yeah, I doubt there is huge diff on that though
[07:52] <seb128> didrocks, u-c-c is supposed to list only known devices, otherwise you need to do "+" to add devices
[07:52] <didrocks> bluetoothctl devices
[07:52] <didrocks> only list the paired one
[07:53] <didrocks> seb128: ah ok, so yeah, it works
[07:53] <seb128> didrocks, the new g-c-c has a different UI, they removed the wizard/dialer to add devices, those are supposed to be listed in the main list instead
[07:53] <didrocks> ok
[07:53] <seb128> dialer->dialog
[07:53] <darkxst> didrocks, g-c-c bluetooth panel changed bigtime after bluez5
[07:53] <didrocks> darkxst: I thought we reused the upstream panel and modified it
[07:53] <didrocks> but ok, the version in the ppa is just the reimport of the older one
[07:54] <seb128> didrocks, https://rishi.fedorapeople.org/gnome-control-center-bluetooth.png
[07:54] <didrocks> seb128: oh right, I remember that UI now
[07:54] <didrocks> ok
[07:54] <didrocks> so all good on u-c-c side, apart from the issue I mentionned on the ML
[07:55] <seb128> right, and I can confirm the issue here
[07:56] <seb128> it should be fixed but isn't a blocker for landing imho, you can unpair using the indicator
[07:56] <didrocks> seb128: +1
[07:56] <seb128> didrocks, thanks for testing!
[07:56] <didrocks> seb128: I wonder if it's the issue about doubling signal
[07:57] <didrocks> yw!
[07:57] <didrocks> like it's sending a disable one
[07:57] <didrocks> the indicator is sending enable
[07:57] <seb128> darkxst, did you try under unity btw? or are you remark from testing under GNOME only?
[07:57] <didrocks> and so it switches back, or if it's really disabled
[07:57] <seb128> didrocks, could be but I don't even see the widget flicker
[07:57] <didrocks> anyway, we'll see, but not a biggy
[07:58] <darkxst> seb128, not tried u-c-c yet. think it failed to install actually on my laptop
[07:58] <seb128> darkxst, no, I meant g-c-c under !GNOME
[07:58] <seb128> though I guess it's not a setup we care much about
[07:58] <seb128> g-c-c is mostly used under GNOME
[07:59] <seb128> I'm just wondering if there is a bug here (but didrocks gets the same) or if something makes it not work out of GNOME envs
[07:59] <didrocks> would be interesting to see how it works with Mate for instance
[07:59] <willcooke> o/
[07:59] <darkxst> seb128, no, that seems pointless really
[07:59] <seb128> k
[07:59] <didrocks> hey willcooke
[07:59] <seb128> hey willcooke
[08:00] <darkxst> didrocks, an mate uses a forked g-c-c 2
[08:01] <didrocks> darkxst: how would that work with bluez5, do you know if they adapated it for it?
[08:02] <darkxst> no idea, flexiondotorg ^?
[08:02] <seb128> he replied on the list asking if we can update blueman2 in the ppa as well
[08:03] <seb128> which I'm looking at now
[08:03] <seb128> so maybe they use blueman?
[08:03] <didrocks> seb128: org.gnome.SettingsDaemon.Rfkill
[08:03] <didrocks> seems like the dbus iface that g-c-c bluetooth panel is using
[08:03] <didrocks> (and I don't see it under u-s-d and unity)
[08:04] <Laney> hullo
[08:04] <willcooke> hi Laney
[08:04] <didrocks> hey Laney
[08:04] <seb128> hey Laney
[08:04] <Laney> what goes?
[08:04] <seb128> didrocks, ok, makes sense, they moved that to g-c-c I think
[08:05] <pitti> hey Laney, good morning
[08:05] <didrocks> seb128: confirmed, that's what they call the "adapter"
[08:05] <darkxst> hey Laney
[08:07] <darkxst> rfkill is still in g-s-d so far as I remember, it has always been there
[08:07] <darkxst> the interface may have changed since u-s-d was forked though
[08:09] <seb128> didrocks, thanks for checking!
[08:10] <seb128> Laney, can you feel the earth moving?
[08:10] <seb128> some gcc5 bits migrated to wily
[08:11]  * seb128 got emails about things hitting wily proper during the night
[08:11] <pitti> yes, gcc-5 was unleashed
[08:11] <pitti> which unblocked quite a bunch of stuff
[08:12] <Laney> indeed, I had loads of migrations
[08:19] <seb128> Laney, pitti, seems like https://code.launchpad.net/~justinmcp/aptdaemon/1352654/+merge/243354 fixes packagekit (according to robert_ancell)
[08:23] <darkxst> seb128, packagekit 1.0?
[08:24] <seb128> no, we are on 0.8 still
[08:24] <seb128> or I'm unsure what you are asking
[08:24] <pitti> yeah, I thought 1.0 was blocked on click
[08:24] <pitti> MoM has a comment like that
[08:25] <seb128> it is
[08:25] <seb128> 1.0 drops support for plugins
[08:25] <seb128> which click is  using atm
[08:25] <darkxst> I know its blocked on click, but wasnt aware of anything else that would break api wise
[08:25] <pitti> ah, I thought that was apt -> aptcc
[08:26] <pitti> that broke langpacks and other plugins too indeed
[08:26] <darkxst> pitti, thats a different story, but ximion is happy for patches in aptcc to handle langpacks
[08:26] <seb128> what did? the drop of plugins in 1.0?
[08:26] <pitti> darkxst: not from me -- waaaaaaaaaay to complicated
[08:26] <pitti> seb128: moving to aptcc
[08:26] <pitti> (I thought this alraedy happened in 0.8, not sure)
[08:27] <seb128> darkxst, in case you missed the start of the discussion, "pkcon install <something>" doesn't work on wily, with 0.8
[08:27] <seb128> pitti, it might be
[08:27] <seb128> unsure what changed between vivid and wily
[08:27] <pitti> I just gave up on PK, TBH -- we've used the aptdaemon implementation which has always worked much better and faster
[08:27] <seb128> but not aptdaemon
[08:27] <seb128> so yeah, maybe that's a side effect of apt->aptcc
[08:27] <pitti> PK as a D-Bus interface is a fine idea
[08:28] <pitti> PK as "the implementation" quite bad for Debian IMHO
[08:28] <seb128> yeah
[08:30] <darkxst> I didnt say you have to switch to aptcc on the lists, that would seem to be a longterm goal, but getting packagekit 1.0 is a short term goal
[08:31] <pitti> that's fine I think -- our current PK already dropped the apt backend, so there's nothing further to lose from that point
[08:31] <willcooke> Trevinho, hikiko - hope that new meeting time on Friday is suitable for you both.  Let me know if not
[08:31] <seb128> can we get pk1.0 and get our stuff (aptdaemon, sessioninsaller, ...) keep working the same way?
[08:32] <pitti> wrt. to general plugins, that's certainy a bigger blocker (wrt. click)
[08:32] <Trevinho> willcooke: fri is fine for me
[08:32] <seb128> oh, Trevinho is back again? ;-)
[08:32] <hikiko> willcooke, for me it's fine :)
[08:32] <seb128> so he was just off to avoid the meeting!
[08:33] <hikiko> lol
[08:33] <Trevinho> seb128: not yet... I've a ship to take this afternoon
[08:33] <Trevinho> seb128: so half-available .)
[08:33] <seb128> ;-)
[08:33] <seb128> going to China by boat? ;-)
[08:34] <Trevinho> lol
[08:34] <willcooke> :D
[08:34] <Trevinho> no, I've to go back to my place in italy
[08:36] <seb128> safe travel then ;-)
[08:36]  * willcooke wonders why he lives in a country which has "yellow rain warnings"
[08:37] <willcooke> I should move to Italy too
[08:37] <Trevinho> yeah... Here it rained yesterday after about two months of sun
[08:37] <Trevinho> even too much sun :)
[08:38] <willcooke> Ohhhh, too much sun??  Poor Trevinho, with his sunshine.  ;D
[08:38] <willcooke> It's bloomin' *dark* here
[08:39] <hikiko> you should come to Greece if you like sun guys... this is the 1st week we don't have 38 degrees... :p (we have 35)
[08:40] <willcooke> I think I'll try and book a holiday to a Greek island next year.  Maybe Kefalonia
[08:40] <hikiko> kefalonia is nice and the Ionian sea is not too hot like the Aegean :)
[08:40] <davmor2> willcooke: I have Sun
[08:41] <willcooke> davmor2, pictures or it didnt happen
[08:41] <Trevinho> yeah, we need to help greece... let's move all there
[08:41] <willcooke> XD
[08:41] <hikiko> the ionian sea islands are pretty much like Italy :) and basically they were part of italy :)
[08:42] <tjaalton> hmm mesa update is blocked by something
[08:46] <davmor2> willcooke: http://people.canonical.com/~davmor2/image20150812_094241420.jpg and http://people.canonical.com/~davmor2/image20150812_094245293.jpg
[08:46] <willcooke> davmor2, bah - no fair
[08:47] <hikiko> where's that place? uk?
[08:48] <davmor2> willcooke: you just live in the wrong bit on England, we tell you southerns that it's grim up here but that's only because you're big girls blouses and we don't want to have to water down the beer or Cider ;)
[08:49] <willcooke> XD
[08:50] <Laney> tjaalton: weird, it says that yade is in progress but I don't see that
[08:50] <Laney> pitti: any clue about that?
[08:51] <pitti> Laney: ah, because yade is uninstallable
[08:51] <pitti> so it's waiting for yade to become installable before it can run the test
[08:52] <Laney> that shows as 'test in progress'?
[08:52] <pitti> Laney: see https://lists.ubuntu.com/archives/ubuntu-release/2015-August/003339.html thread
[08:52] <pitti> Laney: ATM yes; it's not ideal, we are currently discussing how to handle this
[08:52] <pitti> before we just let new packages break things in -release, now it's holding back things too aggressively
[08:53] <Laney> Oh, I saw the thread but not this detail
[08:53] <pitti> -> if mesa doesn't break yade, it's fine to override
[08:54] <pitti> I need to read the britney code to more thoroughly understand why it adds these (FTBFS/uninstallable) to "exclusions"
[09:13]  * pitti wonders if there's a knob in the new pinentry stuff to forget my gpg passphrase less often than every 10 mins
[09:17] <Laney> gpg-agent options -> default-cache-ttl?
[09:25] <pitti> $ gpg-agent options
[09:25] <pitti> gpg-agent: gpg-agent running and available
[09:25] <pitti> Laney: is that a config file somewhere?
[09:26] <pitti> ah, ~/.gnupg/gpg-agent.conf ?
[09:26] <Laney> pitti: oh right, yes, sorry - "echo default-cache-ttl 9999 > ~/.gnupg/gpg-agent.conf" or so
[09:26] <pitti> cheers
[09:27] <Laney> haven't tested this myself, mind - just read gpg-agent(1)
[09:27] <pitti> yeah, I did this now, will restart my session to see whether it works
[09:27] <pitti> I'm sure I'll upload some more packages today :)
[09:27] <Laney> you can reload the agent
[09:27] <Laney> echo RELOADAGENT | gpg-connect-agent
[09:28] <pitti> yay, thanks
[13:04] <jcastro> ricotz: mamarley: tseliot: heya so what do you guys think the next step should be?
[13:04] <mamarley> Probably go ahead and set up a team for it on Launchpad and create the PPA so we can get started.
[13:04] <mamarley> I was thinking it might be a good idea to have some sort of hidden PPA to which the packages could initially be uploaded, and then copied to the real PPA once they pass at least some basic smoke-testing.
[13:05] <mamarley> Another thing I was wondering is how to handle the users who are already using my current PPA?
[13:06] <mamarley> I can definitely put up a message in the description asking people to use the new one instead, but I don't think most people go looking at the PPA description much after the first time they add it.
[13:08] <didrocks> willcooke: FYI, I just took an hour to put my x220 appart, (change keyboard) and cleanup fans. It's like a all new one, no more overheating and such (and so, fan turning way slower, so less noise). You should try on yours which was overheating as well IIRC
[13:09] <didrocks> (it's way easier than on my Dell to do that operation)
[13:10] <jcastro> didrocks: I have to take my thinkpad apart to change the wireless card, it's fun and scary at the same time.
[13:10] <didrocks> jcastro: still your x220?
[13:10] <jcastro> x230
[13:10] <didrocks> ah, you changed since :)
[13:10] <jcastro> just remember when you upgrade to skip the x240 and go for the x250
[13:10] <didrocks> at least, on the x220, it was issue, not sure for the x230
[13:10] <jcastro> yeah my 220 died, such a shame, great laptop
[13:10] <didrocks> yep :)
[13:10] <mamarley> I had to take my T530 apart to dry out once because an HVAC accident caused some water to get dumped on it.  It wasn't difficult at all.
[13:10] <didrocks> ah :/
[13:11] <didrocks> yeah, quite impressed by the quality and documentation you find
[13:11] <jcastro> yeah I got the service manual
[13:11] <jcastro> it's top notch
[13:11] <didrocks> yeah, that + the little picture at the back to tell you what screws is for what…
[13:12] <seb128> didrocks, did you manage to fix your keyboard?
[13:12] <mamarley> Sadly, they got rid of the hardware multiplexer for the T540, so you can't use the NVIDIA card to its full potential with Linux anymore.
[13:13] <didrocks> seb128: I had another one shipped to me, so yeah, replaced and happy :)
[13:13] <didrocks> but that was the excuse to clean it, which was long overdue
[13:13] <didrocks> and the results are way better than what I was expecting
[13:14] <didrocks> (even if it didn't seem that dusty)
[13:14] <tseliot> jcastro: what mamarley suggested sounds good to me
[13:14] <didrocks> mamarley: the only thing that I hate about my x220 is the intel card, it's not as good as I have hoped (and I had low expectations)
[13:15] <jcastro> didrocks: the new iris pro intels perform quite well, they get expensive quickly though
[13:15] <mamarley> didrocks: Yeah, I have tried out mine in Intel-only mode, but I can't fix the tearing so I keep switching back to NVIDIA mode.
[13:16] <didrocks> mamarley: what about your battery consumption then?
[13:16] <tseliot> tearing in videoclips or in general?
[13:16] <mamarley> didrocks: Last time I tried, it would last for about 6 hours.  I haven't used it on the battery in a while though.
[13:16] <didrocks> not bad
[13:16] <mamarley> tseliot: The tearing was in kwin with compositing turned on, so it affects everything.  I get no tearing with NVIDIA though.
[13:18] <tseliot> mamarley: is that intel only or intel+nvidia. As, for the latter, it's kind of expected. If it's the former, it's probably kwin (I can't reproduce the problem with compiz)
[13:18] <mamarley> tseliot: It was Intel-only.  I had kwin in full scene repaint mode too.
[13:19] <willcooke> didrocks, cool (geddit!)  I just squirted a lot of compressed air in to the fan, that seems to have solved the random power offs
[13:19] <jcastro> mamarley: yeah so I guess create the PPA, invite the right people, respond on the list?
[13:19] <didrocks> that's good enough :)
[13:20] <mamarley> jcastro: Am I even allowed to create a team on Launchpad?
[13:20] <ricotz> jcastro, hi, create a proper group, and a ppa which should support armhf
[13:20] <tseliot> mamarley: that's weird but I haven't used kwin in ages
[13:20] <jcastro> mamarley: anybody can create a team on lp
[13:20] <ricotz> e.g. "ubuntu-gpu-team"
[13:21] <mamarley> ricotz: But then I couldn't upload to it because only Canonical employees can upload to non-virtualized PPAs.
[13:21] <ricotz> so it could fit fglrx needs too
[13:21] <jcastro> ricotz: just name it so when users add it it's easy to remember, etc.
[13:21] <tseliot> right
[13:21] <ricotz> mamarley, no, armhf support is not connected to non-virtualized
[13:21] <mamarley> Oh, OK.
[13:22] <tseliot> I think i386 and amd64 are our main focus anyway
[13:22] <ricotz> right, but keep the nvidia armhf building and tested it useful
[13:22] <mamarley> Just as a disclaimer, I have never packaged NVIDIA stuff on ARM before.
[13:22] <tseliot> that would be nice to have
[13:23] <ricotz> tseliot, you git repo should be the base for the packaging, should be added to launchpad too then
[13:23] <tseliot> mamarley: it's ok, usually you don't have to touch any code for armhf
[13:23] <tseliot> ricotz: right, we have git support on launchpad now
[13:24] <ricotz> tseliot, did you read my message on the list?
[13:24] <tseliot> but yes, let me take care of the big packaging changes
[13:24] <tseliot> ricotz: err... what list?
[13:24] <mamarley> So does everybody agree on "ubuntu-gpu-team" for the team name?
[13:24] <ricotz> tseliot, i really don't like those transitional packages which should not be part of the driver package
[13:25] <ricotz> this should be handled with metapackages to transition users to a new series if needed
[13:25] <tseliot> ricotz: it's ok to keep a small diff against my repository
[13:26] <tseliot> we tried to come up with decent metapackages but you can never really predict how many legacy drivers NVIDIA will come up with
[13:26] <ricotz> tseliot, this is not what I am saying, the used packaging structure for the ppa stuff should match the archive one aka be official
[13:26] <tseliot> do you have a plan to show me what you mean about metapackaging?
[13:26] <tseliot> *metapackages
[13:27] <ricotz> https://lists.ubuntu.com/archives/ubuntu-desktop/2015-August/004701.html
[13:27] <ricotz> like the linux kernel is doing it
[13:28] <ricotz> those tansitional package would "silently" purge older driver series which should not happen imo
[13:28] <tseliot> I don't think I'm on that list
[13:30] <ricotz> tseliot, I explicitly sent it to you too
[13:30] <didrocks> tseliot: unrelated but… no intel driver crash for now :)
[13:30] <didrocks> tseliot: I'll call it victory if it passes tomorrow
[13:30] <didrocks> tjaalton: as well ^
[13:30] <tseliot> ricotz: I'm pretty sure I've never received that email
[13:31] <didrocks> (not sure if you followed that crash tseliot)
[13:31] <tseliot> didrocks: no, I really don't know what issue you're talking about :)
[13:31] <tjaalton> tab-complete fail I guess :)
[13:31] <tjaalton> ah no
[13:31] <ricotz> didrocks, you mean tjaalton
[13:31] <didrocks> yeah, it was tab-complete fail at first ;) ETOOMANYT
[13:32] <tjaalton> didrocks: good, I'll update it to a later snapshot before FF
[13:32] <tjaalton> and move the bugs a bit, maybe someone can bother do a bisect..
[13:32] <ricotz> tseliot, are you ok with "ubuntu-gpu-team"?
[13:33] <tseliot> tjaalton: it works for me. jcastro ?
[13:33] <jcastro> the ubuntu seems redundant no?
[13:33] <jcastro> I was hoping for something short and sweet
[13:33] <jcastro> add-apt-repository ppa:nvidia
[13:34] <jcastro> something like that
[13:34] <tseliot> gfx-drivers ?
[13:34] <tseliot> ugly, I know :D
[13:34] <ricotz> jcastro, then get the one who owns "nvidia" to give it up ;)
[13:34] <jcastro> someone has that?
[13:34] <ricotz> https://launchpad.net/nvidia
[13:35] <jcastro> well, the guy who registered it works for Canonical
[13:35] <ricotz> but as said it would be nice to use it for fglrx too, which tseliot would not mind, I guess
[13:35] <jcastro> surely I can convince him
[13:35] <tseliot> ricotz: that's for Canonical projects that involve NVIDIA
[13:35] <jcastro> oh, so we probably can't use that
[13:35] <tjaalton> jcastro: hah, leddy is long gone
[13:35] <jcastro> hey so how about just "gamers"
[13:35] <tseliot> so, no, nvidia is not an option
[13:36] <jcastro> that way it's non-vendor specific, and it kind of tells you what it's for
[13:36] <ricotz> jcastro, too specific for my taste
[13:36] <jcastro> ok so let's not bikeshed too much longer
[13:36] <jcastro> I am fine with whatever as long as it's short
[13:36] <ricotz> i mean it is not just for gamers
[13:37] <ricotz> think opencl
[13:37] <tseliot> ricotz: the only doubt I have about metapackages in Ubuntu (not in a PPA) is me having to maintain and (kernel) patch (which means SRUs) a bazillion nvidia flavours :)
[13:38] <ricotz> mean even "blobs" is taken
[13:38] <tseliot> rolling back is probably something that snappy will make easy
[13:39] <ricotz> tseliot, mamarley, jcastro, "blob"?
[13:39] <tseliot> how about something a little nicer? :D
[13:39] <jcastro> indeed
[13:39] <jcastro> graphics-drivers?
[13:40] <tseliot> if it's available, then yes
[13:40] <mamarley> OK, let me check.
[13:41] <ricotz> it is available
[13:41] <mamarley> What membership policy do you guys want?
[13:42] <ricotz> mamarley, restricted
[13:43] <ricotz> mamarley, admin right for the code
[13:43] <ricotz> core
[13:44] <mamarley> OK, the team is created and jcastro, ricotz, and tseliot are added.  Anyone else?
[13:46] <jcastro> sounds like a good start, I'm sure more people will start to show up
[13:46] <tseliot> it should be enough for now
[13:46] <mamarley> I made you guys administrators too.
[13:46] <tseliot> so, I'm going to publish my code for 355, so that you can use it for the PPA
[13:47] <mamarley> Cool, thanks!
[13:47] <ricotz> mamarley, tseliot, any objections to binary copy the xedgers packages?
[13:47] <tseliot> ricotz: what's the difference between your packages and mamarley's ?
[13:48] <ricotz> xedgers is based on the ubuntu packages
[13:48] <mamarley> And mine are based on xedgers.
[13:48] <tseliot> ok
[13:48] <ricotz> oh really?
[13:48] <ricotz> why are you tweaking the version then?
[13:49] <mamarley> ricotz: No good reason.
[13:49] <ricotz> i see
[13:49] <ricotz> i guess #ubuntu-x might be a better place ;)
[13:50] <tseliot> right
[14:08]  * willcooke reads most of the backlog
[14:08] <willcooke> So if there is a new PPA available soon, it would be good to get it added to the list of "Additional Drivers" asap, in time for W and so we can work the kinks out before X
[14:10] <willcooke> Does anyone know how we add moar things to the list of additional drivers in the Software & Updates settings UI?
[14:10] <willcooke> and also, are those other proprietary drivers listed already in PPAs, or are they in main or something?
[14:11] <didrocks> willcooke: I think we should 'just' have a checkbox in this panel (I did touch it last I guess), then after refreshing from the repo, the new drivers will appear
[14:12] <didrocks> willcooke: however, having something installed by default adding extra ppa, not really ubuntu archive compliant
[14:12] <didrocks> that should be discussed with the technical board
[14:12] <willcooke> yeah, I thought that might be the case
[14:12] <willcooke> so if it was to be in the settings UI it would need to be in main?
[14:13] <didrocks> well, the UI shouldn't add/install anything that is not in the archive
[14:13] <didrocks> I guess the discussion would start from it
[14:14] <willcooke> oki, jcastro what do you reckon ^^ ?  Could you speak to the technical board?  See if they have any better ideas?
[14:15] <jcastro> ack
[14:15] <jcastro> I'll put something on the next agenda
[14:16] <jcastro> willcooke: they meet next Tuesday, I'll add something to their agenda after work today
[14:16] <willcooke> If we have good QA on the PPA, I think it could get "promoted" to the archive without too much worry
[14:17] <willcooke> but I expect it's always going to be bleeding edge, which means people should expect breakage, which therefore means it probably *shouldnt* go in the archive
[14:17] <willcooke> eek
[15:35] <pitti> tjaalton, Laney: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mesa says more clearly now what's the problem
[15:39] <tjaalton> pitti: thx
[16:23] <hikiko> willcooke, I have an idea about the vsync bug... normally, the vsync should need less cpu because it only draws every time the screen is vertically refreshed unless if we have threads and while the rendering thread runs, there's some sort of busy loop somewhere... in this case: when we render too often (no vsync) the busy loop is less busy => faster/less cpu and when we have vsync it's slower => consumes cpu
[16:24] <hikiko> but since I don't know where that could be I  have to check with a sampling profiler
[16:24] <hikiko> (if you guys know a good one to suggest... I've never used one :))
[16:25] <hikiko> if I find something like that the solution is to replace the busy loop with some sort of blocking
[16:26] <hikiko> (anyway, it's just an idea)
[16:26] <willcooke> sounds plausible :)
[22:11] <robert_ancell_> tkamppeter, can you check https://code.launchpad.net/~noskcaj/ubuntu/wily/libjpeg6b/merge/+merge/265455 and see if we still need any Ubuntu change on libjpeg to fix HP drivers?
[22:56] <tkamppeter> robert_ancell, I have seen it, will do.
[22:56] <robert_ancell> tkamppeter, thanks