[00:04] <chrisccoulson> hmmmm, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53516 is pretty lousy. this is what breaks firefox. i wonder what else in the archive is subtely broken :/
[00:04] <ubot2> gcc.gnu.org bug 53516 in tree-optimization "[4.6 Regression] Vectorization and memset recognition miscompile bitfield stores" [Normal,Assigned: ]
[00:10] <david> yo jason u here
[00:16] <jasoncwarner_> chrisccoulson: just saw the tweet, you fixed it?
[00:17] <chrisccoulson> jasoncwarner_, i figured out what it was and then someone else found the gcc bug :)
[00:17] <chrisccoulson> i guess i need to bug doko about that tomorrow
[00:17] <jasoncwarner_> david: I'm here, though I'm jasoncwarner_ , not jason (that is someone else)
[00:17] <jasoncwarner_> chrisccoulson fair enough
[00:28] <micahg> chrisccoulson: regarding the GCC bug, I've seen some maintainers switching away from -03 with gcc 4.7
[00:28] <chrisccoulson> micahg, it's not just broken with -O3. firefox uses -Os ;)
[00:29] <micahg> chrisccoulson: you said that gcc-4.6 works normally?  according to that bug, it should be broke as well
[00:29]  * micahg will find out later tonight with precise testing
[00:30] <chrisccoulson> it definitely is only broken with 4.7 ;)
[00:30] <chrisccoulson> not sure why the bug lists 4.6.3 too
[00:33] <chrisccoulson> i'll grab the gcc patch in a bit and make sure it fixes our problem, but i'm pretty sure it will
[00:33] <chrisccoulson> must sleep first though
[00:33] <micahg> chrisccoulson: good night
[01:02] <robert_ancell> RAOF, bryceh, do you know if there's a reason we have 'xorg' in the desktop-common seed?  It drags in a lot of legacy crap
[01:03] <robert_ancell> I just had a look a the actual content in xbitmaps and it's pretty random
[01:04] <RAOF> Wow. x11-xfs-utils?
[01:05] <RAOF> We probably do want a desktop-seed metapackage pulling in all the necessary X stack, but it looks like we could trim down the dependencies of the ?xorg? metapackage.
[01:07] <robert_ancell> yeah
[01:07] <RAOF> robert_ancell: We could probably drop xorg and pick up xserver-xorg and x11-common.
[01:07] <robert_ancell> well, xorg is a metapackage that should drag in all of xorg
[01:08] <robert_ancell> so yeah, list the actual dependencies instead
[01:08] <RAOF> That will require a little bit of testing; I'm not sure what the minimal dependency set is.
[01:10] <robert_ancell> RAOF, this is xbitmaps btw http://imgur.com/6UpgM.  I still can't work out what "wingdogs" is supposed to be (second from right on row one up from bottom)
[01:11] <RAOF> It's quite clearly a winged dog!
[01:11] <robert_ancell> oh, I see it's a background tile.  For when you need winged dogs on your background
[01:12] <mdeslaur> kill it with fire!
[01:12] <robert_ancell> btw I'm noticing this because I updated http://people.canonical.com/~platform/desktop/versions.html to list eveything that's on the CD, and then I'm blacklisting the stuff we don't care about (basically foundations packages).  So what's left has some interesting finds
[01:25] <bryceh> robert_ancell, yeah we've done purges of legacy crap in the past; could well benefit from another run.  iirc most of the remaining bits don't actually use that much space, but useless is useless.
[02:49] <RAOF> Any DDs feel like a little colord sponsoring?
[02:50] <techman246> yo jason u here
[02:52] <RAOF> techman246: Do you mean Jason Warner, of the desktop team, or another Jason? ? He's been here, and he's probably in IRC. If you've got a question for him you should just ping him with that question; he'll get back to you if he's not currently watching IRC like a hawk.
[02:53] <techman246> well jason warner is who i mean
[02:54] <Optichip> techman246: please hit tab and complete his name.
[02:54] <Optichip> techman246: just using jason is not going to get the attention of his IRC client
[02:55] <jasoncwarner_> techman246: yes, I am here (as I was before when you asked). as Optichip said, tab key is your friend here ;)
[02:55] <jasoncwarner_> ok...nm!
[02:55] <Optichip> lol
[02:55] <Optichip> jasoncwarner_: he's got vision problems
[02:55] <jasoncwarner_> Optichip: ack, thanks...when I see him again I'll msg him
[02:56] <Optichip> jasoncwarner_: and he's interested in finding a solution so that he can use Ubuntu, the software that comes pre-installed, he says, is worthless.
[02:56] <Optichip> jasoncwarner_: he seems to like the compiz magnifier as it functions well for him
[02:56] <jasoncwarner_> TheMuso, do you know techman/david is talking about here?  ^^ (sorry to use the ^^, I know you hate that ;) )
[02:57] <Optichip> jasoncwarner_: he's usually on the linuxdistrocommunity mumble server so I speak with him from time to time.
[02:57] <jasoncwarner_> Optichip: thanks...when he comes back I'll find a way to get in touch with him and get to the bottom of it
[02:58] <Optichip> great jasoncwarner_ if I see him on mumble I will let him know that you've been made aware of his issue and will look into it.  He's a college student so the attention span can be short at times :)
[02:58] <jasoncwarner_> Optichip: oh no! that means I have to compete with video games, beer and the colbert report ;) I'm never going to win!
[03:00] <Optichip> jasoncwarner_: lol :)  if you'd like mumble info  linuxdistrocommunity.mumble.com port 3259 popey rarely drops by but you're more then welcome to come hang with everyone :)
[03:00] <jasoncwarner_> thanks, Optichip , I'll add the server
[03:01] <Optichip> great sir, have a good day, hope you got your coffee in ya and those e-mails all sorted ;)
[03:01]  * Optichip will go back to building his ubuntu spin ;x
[03:26] <TheMuso> jasoncwarner_: Not really...
[03:47] <pitti> Good morning
[04:45] <TheMuso> D/c
[05:21] <RAOF> pitti: Could I get a colord upload to Debian when it's convenient for you?
[05:21] <RAOF> pitti: It's tagged in git, and I've checked that I've actually pushed the pristine-tar branch this time :)
[05:24] <pitti> RAOF: sure; /me dist-upgrades sid chroot
[05:32] <pitti> RAOF: thrown Debianwards
[05:46] <didrocks> good morning
[05:50] <pitti> bonjour didrocks
[05:50] <didrocks> guten morgen pitti, how are you?
[05:51] <pitti> I'm great, thanks! how about yourself?
[05:52] <didrocks> I'm fine, thanks :) Time to catchup on what have been delayed due to the new compiz ;)
[05:53] <RAOF> Heh
[07:49] <seb128> hey
[07:54] <micahg> hi seb128
[07:54] <pitti> bonjour seb128
[07:55] <seb128> hey micahg, pitti, how are you?
[07:55] <didrocks> salut seb128
[07:55] <pitti> Je suis bien, merci!
[07:55] <micahg> seb128: well thank you, and you (a little tired, need to go to bed soon)
[07:56]  * micahg can't even get parentheses right at this hour apparently :-/
[07:57] <seb128> micahg, I'm good thanks
[07:57] <seb128> pitti, great ;-) (suis -> vais if you want to be correct, I'm not sure is as broken as my "ich bin gut" but it's not something we would say ;-)
[07:57] <seb128> didrocks, lut, en forme ?
[07:58] <didrocks> seb128: ça va bien, et toi?
[07:58] <pitti> seb128: ah, so "je vais bien", but "je suis désolé"?
[08:01] <chrisccoulson> good morning everyone
[08:02] <seb128> didrocks, ca va merci !
[08:02] <seb128> pitti, correct
[08:02] <seb128> chrisccoulson, hey, how are you?
[08:02] <chrisccoulson> seb128, tired. how are you?
[08:04] <seb128> chrisccoulson, did you fight toolchains to no hours again?
[08:04] <seb128> chrisccoulson, I'm good, a bit tired as well
[08:04] <seb128> chrisccoulson, or did you defeat the toolchain, and finally being able to play angry bird again you spent your night on it? ;-)
[08:04] <chrisccoulson> seb128, yeah, we got somewhere (see the comments on https://bugzilla.mozilla.org/show_bug.cgi?id=754554)
[08:04] <seb128> micahg, oh btw how did the firefox testing go? are we go for next week?
[08:04] <ubot2> Mozilla bug 754554 in JavaScript Engine "Various JIT test failures related to FloatArrays when compiled with gcc 4.7" [Normal,New: ]
[08:05] <micahg> chrisccoulson: seb128: gcc 4.7 uploaded by doko already
[08:05] <micahg> seb128: nothing show stopping so far, just stuff I've already found before (i.e. not regressions) or minor and probably upstream design choice (Bug #1006748)
[08:05] <ubot2> Launchpad bug 1006748 in firefox "favicons don't show up in live bookmarks anymore" [Low,Triaged] https://launchpad.net/bugs/1006748
[08:06] <chrisccoulson> that works fine here in all of my profiles btw
[08:06] <micahg> chrisccoulson: in Firefox 13?
[08:06] <chrisccoulson> yeah
[08:06] <micahg> hrm, I just get an RSS icon
[08:06] <chrisccoulson> oh
[08:06] <chrisccoulson> that's intentional
[08:07] <chrisccoulson> AFAIR, that's been the case for a while
[08:07] <chrisccoulson> i don't remember it ever being any different
[08:07] <micahg> nope, this is the first release like that
[08:07] <chrisccoulson> well, if the icon has been replaced with another icon, that's almost certainly intentional
[08:07] <chrisccoulson> and please use apport to file bugs, as i'm going to start automatically closing non-apport bugs ;)
[08:07] <micahg> well, it used to be favicons, now it's not, I figured it might be intentional
[08:07] <seb128> micahg, did you do a full test coverage? i.e are we confident the update is good to ship out when they roll the final tarball?
[08:08] <micahg> seb128: I'm more confident than before :), still need to finish the testing and will have to do final testing on Monday again, but looks good thus far
[08:09] <seb128> micahg, great, thanks
[08:10] <micahg> chrisccoulson: I'd rather not sign in all my VMs, I'll give you apport info when it's pertinent (and I should've included the version in the favicon report)
[08:30] <micahg> didrocks: I meant to ask you, can we switch nux to glew 1.7 in quantal?
[08:35] <didrocks> micahg: this is *exactly* what I'm doing now :)
[08:35] <didrocks> micahg: see all my compiz upload I just did :p
[08:36] <micahg> didrocks: I see boost :)
[08:37] <didrocks> micahg: yeah, today is transition day :)
[08:38] <micahg> didrocks: but thanks, good to know, once it builds, can I remove the 1.6 dev packages?
[08:38] <didrocks> micahg: yep, if I see no regression with the newer glew
[08:38] <didrocks> micahg: if I see, I'll warn you anyway, and just do boost
[08:38] <micahg> didrocks: do you want to ping me once you test and are confident?
[08:38] <didrocks> micahg: will do
[08:38] <micahg> thanks
[08:40]  * micahg will wait until after alpha 1 anyways, just to be sure :)
[08:47] <pitti> tkamppeter: hey Till, how are you?
[08:57] <pitti> tkamppeter: since jockey is going away (https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-third-party-driver-installation), we need to move the openprinting.org driver stuff to s-c-p and aptdaemon
[08:58] <didrocks> interesting, so newer boost in compiz is ok, but newer boost in nux with old unity == ko
[08:59] <pitti> tkamppeter: I think the lookup of driver packages should happen in s-c-p directly; there is little reason why s-c-p should initiate the query, then move to jockey over d-bus, which again uses s-c-p API (python-cups) to do the actual query..
[08:59] <pitti> tkamppeter: as for actually installing them, that should use the PackageKit API, so that it uses only upstream friendly APIs
[09:13] <pitti> glatzor: hey, how are you?
[09:14] <glatzor> hey pitti, fine. and yourself?
[09:14] <pitti> glatzor: gut, danke!
[09:14] <pitti> argh, phone, brb
[09:14] <glatzor> pitti, but I have to leave in a minute again :)
[09:15] <glatzor> mvo, pitti I started to move AptAuth to python-apt: See lp:~glatzor/python-apt/auth. But it isn't yet complete and the tests are missing.
[09:17] <glatzor> see you pitti and mvo
[09:21] <pitti> glatzor: that's actually related to my question
[09:21] <pitti> glatzor: in current aptdaemon trunk, tests fail/hang with "dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.debian.apt was not provided by any .service files"
[09:24] <pitti> .. due to ImportError: No module named softwareproperties.AptAuth
[09:24] <pitti> glatzor: wb
[09:24] <pitti> glatzor: aptdaemon trunk cannot currently run the tests because of that; known? is there a workaround?
[09:25] <pitti> but "from softwareproperties.AptAuth import AptAuth" does work in a python shell, so I'm a bit confused why it doesn't work in aptdaemon
[09:31] <pitti> glatzor: oh, it's running through python3, I see
[09:53] <Sweetshark> seb128, pitti: libreoffice_3.5.4-0ubuntu1 is on chinstrap and ready for upload to precise-proposed.
[09:56] <seb128> Sweetshark: what about q? SRU rules says it should be uploaded to unstable first
[09:57] <pitti> *nod*
[09:58] <Sweetshark> seb128: I dont run q. Do you really want me to forwardport LibreOffice 3.5 to a very unstable prealpha where it will never be part of in production (as we will use 3.6 there)?
[10:00] <seb128> Sweetshark: you mean we can't upload that version to q? why wouldn't it work there?
[10:01] <Sweetshark> seb128: if you want it to be endusertested: it is. its in the libreoffice ppa for a week already. That ppa has 12000 downloads of 3.5.3 on precise, which should be better testing that doing something on q.
[10:02] <ricotz> hey desktopers
[10:02] <seb128> Sweetshark: well, I personally don't care much, I'm just trying to make SRU uploaded SRUs go in
[10:02] <seb128> hey ricotz, it has been a while we didn't see you talk here, how are you?
[10:02] <ricotz> Sweetshark, it should be fine to just take this package and upload it to quantal
[10:02] <ricotz> seb128, hi, i am fine, a bit busy
[10:03] <ricotz> seb128, how are you?
[10:03] <seb128> ricotz, I'm good thanks
[10:03] <ricotz> Sweetshark, could you request some more space for the lo ppa?
[10:04] <ricotz> Sweetshark, got your mail, btw, with the impatient user ;)
[10:07] <Sweetshark> seb128: It _might_ work on q. I didnt ever try. It is not unlikely with the deps of LO, someone broke something there (Java, gcc update, or kde/gtk being funky again). The prospect of having to do workarounds for q, reverting them back for p and never releasing to q for production in the first place seems totally wrong to me.
[10:08] <seb128> sweetshark: well, ideally we will want > 3.5.3 in q at some point no?
[10:08] <seb128> so that work will need to be done
[10:08] <pitti> Sweetshark: we don't do package copies from precise-proposed to quantal for exactly this reason any more --- we'd introduce versions which are actually unbuildable (and might behave differently when built in Q
[10:08] <seb128> sweetshark: I don't disagree with "let's do 3.5.4 for p" first
[10:09] <pitti> so it comes down to whether the SRU team accepts fixing it in precise _only_, with quantal lagging behind
[10:09] <pitti> I guess quantal should eventually get 3.6?
[10:10] <Sweetshark> seb128: no, I dont intend to package 3.5.X for q at all. I will start with 3.6.0~alpha1 for quantal and work the way to 3.6.2/3 for final.
[10:11] <seb128> sweetshark: ok, that works as well, do you have a timeframe for 3.6.0~alpha builds?
[10:11] <Sweetshark> seb128: http://wiki.documentfoundation.org/ReleasePlan/3.6
[10:12] <seb128> sweetshark: ok, this week then ;-)
[10:12] <seb128> Alpha(1..)n[1] 	Week 22, May 28 - Jun 3, 2012
[10:12] <pitti> FYI, I added the LibO milestones to https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock a while ago
[10:13] <seb128> pitti, thanks
[10:14] <Sweetshark> seb128: yes, I have LO master (3.6) build on precise here now, will try to hop over to a quantal pbuilder now, so I can get the alphas out early.
[10:14] <seb128> sweetshark: ok, great
[10:15] <seb128> it seems good enough to me as a plan but I'm not in the SRU team so let's see how it goes
[10:15] <seb128> Sweetshark: I'm not sure this afternoon but I will review the SRU tomorrow
[10:17] <Sweetshark> ricotz: actually it is a good sign that the impatient user are not only bugging us directly about the ppa, but also everyone else related to libreoffice ;)
[10:20] <ricotz> Sweetshark, oh, i dont really know where this mail came from
[10:22] <Sweetshark> ricotz: eliane is the south american libreoffice marketing wonder. good to have her on our side.
[10:23] <ricotz> Sweetshark, ah, i see :)
[10:23] <ricotz> Sweetshark, is the lo version on chinstrap using the debian rc2 tarballs?
[10:24] <Sweetshark> ricotz: yes
[10:24] <Sweetshark> ricotz: thats the only change.
[10:24] <Sweetshark> (to the ~rc2 version in the ppa)
[10:24] <ricotz> ok, so i am going to use them
[10:25] <ricotz> Sweetshark, i will try to do it soon
[10:36] <seb128> chrisccoulson, did you test bug #997640 out of unity? is that a firefox issue?
[10:36] <ubot2> Launchpad bug 997640 in firefox "Keyboard shortcuts for moving tabs don't work" [Low,New] https://launchpad.net/bugs/997640
[10:37] <chrisccoulson> seb128, it's a firefox issue, but i'm not really sure if it's actually a real issue or not, or if the documentation is just out of date
[10:39] <seb128> TheMuso, did you look at bug #996245 (it's assigned to you) (looking through the team bugs which got dispatched to team members but were not followed up on since)
[10:39] <ubot2> Launchpad bug 996245 in alsa-driver "Audio level is too low on Intel Z77 Chipset (Gigabyte MB: GA-Z77X-UD5H-WB)" [Undecided,New] https://launchpad.net/bugs/996245
[10:39] <seb128> chrisccoulson, ok, good, feel free to unassign yourself, I just wanted to make sure we don't break firefox with some key grabbing or something
[10:39] <seb128> chrisccoulson, if that's a firefox issue it doesn't seem important enough to be specifically tracked
[10:45] <ricotz> didrocks, hi :), i hope you find time for https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1003286 -- http://bazaar.launchpad.net/~mefrio-g/pantheon-files/fix-1003286/revision/817
[10:45] <ubot2> Launchpad bug 1003286 in pantheon-files "dbus unity launcherentry.updates aren't getting dismissed" [Medium,Fix committed]
[10:45] <didrocks> ricotz: yeah, this week, it's already prepared, just not tested over dbus yet :)
[10:45] <didrocks> making complex transition on unity first
[10:45] <ricotz> didrocks, alright, thanks
[10:45] <Sweetshark> ricotz: pushed to git too btw ...
[10:46] <ricotz> Sweetshark, good
[10:47] <Sweetshark> seb128: just seen on #libreoffice-dev: "12:41 <@pmladek> Fridrich, shm_get: I have just pushed the tag libreoffice-3.5.98.1; please, launch the 3.6.0-alpha1 builds"
[10:47] <seb128> sweetshark: nice ;-)
[11:13]  * Sweetshark packs LibreOffice 3.6.0~alpha1 tarballs.
[11:14] <Sweetshark> ricotz: ppa build filesystem increase request filed.
[11:16] <Sweetshark> ricotz: when you have the 3.5.4 backports, will you copy them over to https://launchpad.net/~libreoffice/+archive/libreoffice-3-5 too?
[11:17] <Sweetshark> ricotz: for the guys who want 3.5.x but not want to be surprised by a 3.6.x update?
[11:19] <ricotz> Sweetshark, ok, libreoffice-3-5 is already big enough?
[11:19] <ricotz> irc, it should be at least 7-8gb
[11:20] <Sweetshark> ricotz: hmm, true.
[11:23] <Sweetshark> ricotz: *grumble* where is that get-more-ppa-space-button hiding?
[11:25] <ricotz> hehe, you need to request it as well in the answer-tracker of soyuz ;)
[11:25] <Sweetshark> ricotz: yep, Im on it.
[11:27] <Sweetshark> ricotz: https://answers.launchpad.net/launchpad/+question/198979
[11:29] <ricotz> Sweetshark, alright
[11:55] <ricotz> Sweetshark, could you push you git tags too?
[11:56] <cyphermox> good morning!
[12:11] <Sweetshark> ricotz: i will tag 3.5.4-0ubuntu1 when seb128 has it in precise-proposed
[12:15] <ricotz> Sweetshark, ok
[12:52] <bcurtiswx> good morning
[13:17] <pitti> tkamppeter: I updated the work items on https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-third-party-driver-installation accordingly, FYI
[13:19] <pitti> mvo: do you usually review aptdaemon merge proposals, or do you leave that to glatzor? (https://code.launchpad.net/~pitti/aptdaemon/pkcompat-enhancements/+merge/108156)
[13:19] <mterry> mpt, mvo: Morning (for me)!  mpt, I've got a few questions about the software updater spec.  When looking at the details of updates, was your intention that the expander and changelog pane divider always start in the same position or that we save their state?
[13:20] <pitti> mvo: I committed a few small cleanups directly to trunk, but this is a larger change and should get peer review
[13:20] <mvo> pitti: mostly glatzor, but I can do it too
[13:20] <pitti> mterry: I pinged him first! :-)
[13:20] <mvo> hey mterry, good morning
[13:20] <pitti> mterry: j/k, good morning!
[13:20] <mterry> pitti, hi!
[13:21] <mvo> pitti: "- Doesn't support recursive dependency resolution."> is that a obsolete/old docstring? noticed that you remove it in the diff
[13:22] <pitti> mvo: yes, that fixed the comment in what_provides() -- copy&paste error back then, sorry
[13:22] <mvo> ok
[13:23] <pitti> mvo: I actually meant to commit the removal of add_test_repository() straight to trunk, but forgot to push
[13:23] <pitti> it's not really related to that MP
[13:23] <mpt> mterry, "that is always collapsed by default"
[13:23] <pitti> mvo: I can fix that, if you consider it confusing noise
[13:23] <mvo> pitti: its a bit confusing, but its not a big deal
[13:24] <mterry> mpt, yeah I saw that text, but just wanted to double-confirm that default meant every-open instead of first-open
[13:24] <pitti> mvo: I just see that InstallSignature() is not implemented either; I'll work on that next, but that can be a separate MP
[13:25] <mterry> mpt, also FYI, the default theme does not make the separator pane divider for changelogs very visible.  Which may be a feature not a bug, but just saying  :)
[13:25] <mvo> mpt: fwiw, for people who are interessted in the detail its going to be a click on that everytime and also a click and drag on the changelog pane handle.
[13:26] <mpt> mterry, I think I mentioned last week that I made a mistake in using two different disclosure controls in the same window
[13:26] <mpt> mterry, so that I wanted to change the handle to a disclosure triangle too
[13:26] <mvo> pitti: very nice, thanks
[13:26] <pitti> thanks mvo!
[13:27] <mterry> mpt, ah... OK.  A sub-control of the main triangle or a sibling-control?  Do you know the label you want for it yet?
[13:27] <mpt> mvo, so do you think we should remember expanded state?
[13:27] <pitti> mterry: did you happen to think about the fate of openal-soft and its new (rather heavy) roaraudio dependency chain?
[13:27] <pitti> mterry: (feel free to answer later, not urgent)
[13:28] <mvo> mpt: my initial impulse is yes, but it would be not ideal for people who accidently expand and are actually not interessted. but that is the only downside for remembering that I can see
[13:29] <mpt> mterry, what do you think?
[13:29] <mvo> mpt:  I also wonder if we should actually show the changelog in the details by default assuming that people who are interessted in details are interessted in that level too (would be interessting to get some data on this)
[13:29]  * mvo wonders if that actually is a understandable sentence
[13:30] <mvo> i mean, clicking on details would show them all by default (including changelogs) so that there is just one "level" of details by default
[13:30] <mterry> mpt, eh.  I am usually interested in the changelogs, but I'm not the target audience by a long shot
[13:30] <pitti> mvo: you should add even more "sssss" for better Parsel tongue :)
[13:30] <mpt> mvo, well, there's a bit of a difference between thinking "No, I don't want to install Firefox right now" vs. understanding "* Switch back to GCC 4.7 now that the issues with bitfield stores are fixed, and also reenable PGO (LP: #1003733)"
[13:30] <tkamppeter> pitti, sorry for answering late. We should do it as you describe.
[13:31] <mvo> pitti: ahaha
[13:31] <mpt> (where by "install" I mean "update", obviously)
[13:31] <pitti> tkamppeter: ok, thanks; I'm working on getting "add repository" and "install new GPG key" working in aptdaemon
[13:31] <dobey> hi pitti :)
[13:32] <pitti> tkamppeter: do you think you can do the lookup in s-c-p (that should be easy, it's basically all there already) and the installation of packages through the PackageKit API?
[13:32] <pitti> tkamppeter: as today is my last day on desktop, I won't have time to work on this, I'm afraid
[13:32] <mterry> pitti, thanks for the catch on mx's dependency before it hit main.  Silly me
[13:32] <tkamppeter> pitti, with all in s-c-p and using the PackageKit API we have much better chances that other distros adopt automatic driver download.
[13:32] <pitti> tkamppeter: I can help you with that, of course; i. e. give you some example code how to use the PackageKit API
[13:33] <pitti> tkamppeter: right, as these are all upstream APIs, so it should just work on other distros as well
[13:33] <mpt> mterry, mvo: Okay, how about this: https://wiki.ubuntu.com/SoftwareUpdates?action=diff&rev2=65&rev1=63
[13:33] <pitti> tkamppeter: assuming that PackageKit supports their packaging system, but that should be the case on at least RPM/Fedora-ish systems
[13:33] <pitti> mterry: mx> you're welcome
[13:34] <tkamppeter> pitti, OK, I will do it and would be great if you could send me sample code already. On which IRC channel(s) will you be reachable for the case that I need help?
[13:34] <mvo> mpt: that looks good to me, I assume the "naother expander, “Description”, " also remembers its expanded/collapsed state?
[13:35] <pitti> tkamppeter: I'll be at least in #ubuntu-devel; but I'll stay in #-desktop as well, unless I get thrown out :)
[13:35] <desrt> pitti: we'll miss you!!!
[13:35] <pitti> tkamppeter: I just got "add repository" working in aptdaemon's trunk, but that's not yet in quantal yet, so a bit tricky to play with
[13:35] <desrt> *tear*
[13:35]  * pitti hugs desrt
[13:36] <desrt> i hope microsoft treats you well
[13:36] <pitti> tkamppeter: but I'm sure our great mvo will get it uploaded soon
[13:36]  * pitti unhugs desrt
[13:36] <chrisccoulson> lol
[13:36] <mpt> mvo, no, it would always be collapsed initially. So this way if you wanted to see the changelog it would be two clicks the first time you ran Update Manager, one click thereafter.
[13:36] <desrt> pitti: about time.  that hug lasted like 20 seconds.  well past the comfortable zone.
[13:37] <pitti> hey dobey, how are you?
[13:37] <pitti> desrt: not nearly enough to turn your face into a becoming blue :)
[13:37] <mvo> mpt: meh, ok. at least I got one click
[13:37] <dobey> pitti: good, you?
[13:37] <mterry> mvo, :)
[13:38] <pitti> dobey: quite fine; trying to get most of my remaining WIs done on my last desktop day..
[13:39] <dobey> pitti: ah. so delegate them all? :)
[13:39] <pitti> well, I'm sure Pete will allow me to clean up the remaining bits ;)
[13:39] <dobey> hehe
[13:40] <dobey> pitti: did you see my e-mail to technical-board? wondering what your thoughts are on that
[13:41] <pitti> dobey: I saw it, yes; haven't had time to respond yet
[13:41] <pitti> dobey: in short, this sounds ok to me, if you could elaborate a bit on the tests you do for each release
[13:44] <dobey> hmm, ok. though not sure how to elaborate further without getting into specific minutae
[13:49] <Sweetshark> ricotz: https://answers.launchpad.net/launchpad/+question/198979
[13:52] <pitti> dobey: I'm mostly interested in how much coverage the tarmac tests on the destination release have, if they are using the actual -proposed packages, whether they also cover upgrades, existing files in the cloud, etc.
[13:52] <pitti> dobey: but I already know that your automated upstream test are really comprehensible, so I'm not really worried
[13:53] <dobey> tarmac is only for landing changes in the upstream code. it doesn't build/install packages or test upgrades or anything, no. but we're also very strict about only putting bug fixes into stable released branches
[13:53] <pitti> dobey: right, but we need something or someone who will test the actual .debs
[13:54] <pitti> dobey: the upstream tests won't catch packaging failures (which might not even be your fault, e. g. perl or debhelper or whatever migth change)
[13:54] <dobey> pitti: right, and we do that manually, to verify the bug fixes, once the packages are in -proposed
[13:55] <dobey> and i test build the packages before uploading of course.
[13:55] <pitti> dobey: the point of a MRE is usually that there are too many bug fixes to verify individually, and we rather rely on comprehensive regression tests and one "meta" bug like "update lucid to version x.y"
[13:55] <dobey> if perl or debhelper changes that much in a stable ubuntu release, i think we have bigger problems :)
[13:56] <pitti> dobey: right, and they usually don't, but we have seem the most curious and unexpected bugs :)
[13:56] <pitti> dobey: so as long as the actual .debs in the archive get tested somehow, I'm happy
[13:56] <dobey> clearly perl needs more comprehensive regression testing :)
[13:57] <didrocks> mterry: hey, small question on line 119 of https://code.launchpad.net/~mterry/quickly/extras/+merge/107104
[13:58] <didrocks> mterry: I don't really get why the subtitution can't be done in setup.py?
[13:59] <dobey> pitti: we will usually have more than a couple fixes in the microreleases, and will do single patches for exceptional (critical) issues. but the micro releases are easier for us to manage, particularly given we also have to support multiple platforms, and we're trying to maintain a unified release process across all our supported platforms. and we're aligning our releases with the ubuntu freezes, lts schedule, etc…
[13:59] <mterry> didrocks, a lot of that code (almost all of it) should eventually be moved into the project_root code.  But this is step 1 of world domination, where my concern is just SRU-ability.  So I kept all the logic only in the --extras codepath.  Once this hits trunk and 12.04, we can work on better long term solutions
[14:01] <dobey> pitti: but some of our projects will have new microreleases even with no changes in the code, just to keep things consistent across the board; like for example how some GNOME modules only have translations updates or such, in a microrelease, but everything is 3.4.1 or whatever. :)
[14:01] <pitti> dobey: we don't really care much about the naming/version/whether the fixes come as patches or from a new release
[14:01] <didrocks> mterry: good, just was wondering if I didn't miss anything obvious, can you just a TODO not on top of this stenza? (to move it to setup.py)
[14:01] <didrocks> mterry: second question: line 135 of the merge proposal
[14:02] <dobey> pitti: right, i'm just explaining why we want it this way :)
[14:02] <didrocks> mterry: the glib-compile-schemas isn't done in a trigger but when you make install?
[14:02] <pitti> dobey: you need a MRE if you either have too many fixes per release which are impractical or redundant to verify individually, or when new versions have changes which do not match the usual SRU criteria
[14:02] <didrocks> mterry: or did I miss an obvious "> debian/footrigger" ? :)
[14:02] <mterry> didrocks, ask that again?  not sure I understood
[14:03]  * pitti brb, supermarket
[14:03] <dobey> right, and most all our fixes are redundant to verify individually
[14:03] <didrocks> mterry: so, line 135 and beyond, you are detecting if there is a gesttings schema
[14:03] <didrocks> if so, you call glib-compile-schemas
[14:04] <didrocks> but you add that to install_rules
[14:04] <didrocks> which is executed on "make install"
[14:04] <didrocks> so when you create the package
[14:04] <didrocks> I think what you want is on make install create the triggers file you want
[14:05] <didrocks> so that the triggers is installed (or in the postinst) when you actually install the package on the machine, right?
[14:05] <mterry> didrocks, you mean install a dpkg trigger just for this package?  I figured that would be overkill, and we could just compile it ourselves.  No one else is sharing the schema directory with us
[14:05] <mterry> didrocks, plus, I suspect the ARB would not be thrilled with us installing triggers
[14:06] <didrocks> mterry: but in that case, you want the compilation to happen when you install the package, right?
[14:06] <didrocks> so, in the postinst
[14:06] <mterry> didrocks, it doesn't matter when it happens because we are the only schema in the directory.  the compiled schemas will never be out of date
[14:06] <didrocks> mterry: as it's mmaped, there is no i386/amd64 diff?
[14:07] <didrocks> (or armel)
[14:08] <mterry> didrocks, oh, hmm...  shoot I didn't realize it compiled into an arch-specific format
[14:08] <mterry> I thought it was just a bundling and compressing
[14:08] <didrocks> desrt: is it? ^
[14:08] <didrocks> mterry: as it's something that gsettings then mmaped, I think it's arch-specific
[14:08] <didrocks> let's see what the master says :)
[14:09] <desrt> no
[14:09] <desrt> it's architecture independent
[14:09] <desrt> that's why it's in share and not lib
[14:09] <mterry> great
[14:10] <didrocks> awesome :)
[14:11] <didrocks> mterry: approved then: https://code.launchpad.net/~mterry/quickly/extras/+merge/107104 awesome work man! :)
[14:11] <mterry> didrocks, thanks!
[14:11] <didrocks> mterry: thanks to you!
[14:12] <mterry> didrocks, just FYI, wendar and I talked about this branch, and she'd like to see almost all of that code we stuff into debian/rules go into the project_root for 12.10.  So that's step 2 of world domination as mentioned above
[14:13] <mterry> didrocks, (since ARB apps aren't really supposed to have such bat-shit-insane debian/rules)
[14:14] <didrocks> mterry: agreed on that
[14:14] <didrocks> mterry: also, deeper integration on the whole stack
[14:14]  * Sweetshark handcuffs pitti to the heater.
[14:15] <didrocks> mterry: that's why I patch cdbs/p-d-e/debhelper at the time
[14:15] <Sweetshark> Try leaving the desktop team now *MUHAHA*
[14:15] <didrocks> mterry: but seems the patches were lost in merges
[14:37] <pitti> Sweetshark: MMMmmmmMmmmmmm mmm *mmmgMMmmm*!!!
[14:45] <dobey> pitti: did you see my last message? :)
[14:46] <pitti> dobey: dobey | pitti: right, i'm just explaining why we want it this way :)
[14:46] <pitti> dobey: this one? yes
[14:46] <dobey> 10:03 < dobey> right, and most all our fixes are redundant to verify  individually
[14:46] <dobey> that one :)
[14:46] <pitti> ah; yes, that's an MRE then
[14:47] <pitti> we mostly need regression testing, the actual fixes should already be covered by new test cases
[14:49] <dobey> mostly they are, but not everyting is easily testable, or tested. though of course with continuous integration, comes continuous improvement. but we're also pragmatic. :)
[14:54] <didrocks> pitti: for your guadec flight, you are laying of at alvedro's airport, right?
[14:54] <pitti> didrocks: alvedro? I have a layover in Madrid
[15:16] <mterry> pitti, can you point me at that openal-soft bug you mentioned?
[15:16] <pitti> mterry: it's not a bug report yet, it's in http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[15:17] <pitti> mterry: I did some MIR filings and package reviews, but for this one I wasn't sure whether we really want it
[15:17] <pitti> mterry: my gut feeling is that we have more than enough sound APIs in main already..
[15:18] <mterry> pitti, :)  true.  let me look at it for a sec
[15:20] <mterry> pitti, this is all for the kgoldrunner game?  Won't KDE be bumped to universe this cycle?
[15:21] <pitti> mterry: that was the idea, yes
[15:22] <pitti> mterry: oh, then we can drop openal-soft, too? even better
[15:22] <mterry> pitti, yeah, the only rdepends I can see is kdegames
[15:40] <Sweetshark> LibreOffice 3.6.0~alpha1 finished "./debian/rules build" on precise -- how it only need to survive packaging.
[15:42]  * Sweetshark is excitedly watching the tar xz-compressing the 2GB libreoffice-dbg. It only takes half an hour.
[15:43] <Sweetshark> xz need parallelization. 3 cores idling.
[16:45] <pitti> mvo: it won't be long before aptdaemon implements more of the PK API than PK itself now :-P  https://code.launchpad.net/~pitti/aptdaemon/pkcompat-enhancements/+merge/108201
[16:45] <pitti> tkamppeter: ^ FYI, with that we'll have the necessary pieces all together
[16:48] <pitti> mvo: as usual, writing the test took 80% of the time :)
[16:48] <mterry> didrocks, pretty please can you review https://code.launchpad.net/~mterry/quickly/empty-version/+merge/108202 too?  Then I'll do an SRU for this, the flash template fix, and the extras bits
[16:49] <didrocks> looking
[16:49] <pitti> good night everyone!
[16:50] <didrocks> good night pitti
[16:50] <didrocks> mterry: fresh project doesn't have project_version?
[16:50] <kenvandine> good night pitti!
[16:51] <kenvandine> pitti, you'll be missed :-D
[16:51] <didrocks> ah, they don't have on for ubuntu-application -derived template. and so '' (and so < '11.12') ok ;)
[16:52] <didrocks> mterry: approved
[16:54] <mterry2> didrocks, sorry power went off
[16:54] <mterry2> didrocks, can you repeat anything from last few minutes?
[16:54]  * mterry2 is on phone now
[16:55] <jbicha> oh I guess we need to disable the annoying totem vegas plugin
[16:59] <didrocks> 18:50:23      didrocks | mterry: fresh project doesn't have project_version?
[16:59] <didrocks> 18:51:11      didrocks | ah, they don't have on for ubuntu-application -derived template. and so '' (and so < '11.12') ok ;)
[16:59] <didrocks> 18:52:00      didrocks | mterry: approved
[16:59] <didrocks> jbicha: vegas? waow, attractive! :)
[17:01] <mterry2> didrocks, awesome.  quickly is weird sometimes.  ok will cut a release for Q and backport for 12.04
[17:02] <didrocks> mterry2: I'm not *that* weird :p
[17:02] <didrocks> mterry2: yeah, upgrade seemed to be a good idea at start
[17:02] <didrocks> but when the need for derived template came
[17:02] <didrocks> it added a lot of complexity
[17:02] <didrocks> well, it's still running and looking at the right version and running the right upgrade
[17:03] <didrocks> (and the idea/goal for the upgrade scripts were that they are indempotent)
[17:03] <didrocks> but with this warning sentence, it's not the case :)
[17:04] <mterry2> didrocks, yar, it's fine.  this warning was at fault, just the per-template versoning is a bit hard to grok
[17:08] <jbicha> didrocks: not really, Vegas breaks Flash
[17:12] <didrocks> jbicha: ah, it's not that flashy then :)
[17:12] <didrocks> mterry2: yep, agreed :)
[17:12]  * didrocks waves good evening
[17:13] <mterry2> bye didrocks
[17:40] <mterry> w00t for humble bundle 5
[17:50] <mterry> dpm, heyo.  I bought the humble bundle to test this thing out, and going into the software center, redeeming it seems weird...  Like, I click on the banner, then get shown a list of just LIMBO
[17:52] <dpm> hey mterry, thanks for the feedback, can you jump into #ca-internal on the Canonical server to report this?
[17:52] <mterry> dpm, sure
[17:52] <dpm> thanks!
[18:18] <mvo> pitti: sweet, and ++ on completeness :)
[19:10] <hggdh> anyone: please see to bug 993187
[19:10] <ubot2`> Launchpad bug 993187 in xorg "ubuntu 12.04 completely freezes frequently" [High,Confirmed] https://launchpad.net/bugs/993187