[00:00] chrisccoulson, yep that'd do it :-) [00:01] RAOF, interestingly, I think I'm coming to the conclusion that those false gpu lockups no longer exist [00:01] RAOF, we've only had a small handful reported, and after going through them I think they're all mis-reported real gpu lockups [00:01] so, wee [00:02] :) === zyga_ is now known as zyga [06:01] Good Morning. [06:39] Nice day BigWha.le =) [06:41] chilicuil, this is yet to be seen. ;) [07:16] good morning [07:49] RAOF: colord> ah, thanks [07:50] If it's a performance problem we could probably delay colord startup. [07:50] RAOF: not a particular one, I'm just on a mission to kill everything from startup which we don't need, and I just wondered [07:51] It'd need cupsd to not query colord on startup and instead lazy-load stuff, and a patch for gnome-settings-daemon to not query colord if stuff hasn't been set. [07:57] RAOF: so, that's an option we should keep in mind once the more CPU intense stuff (nautilus, notify-osd) have been fixed [08:04] TheMuso: what's the current status of switching openjdk to the apt-spi2 bridge? [08:04] TheMuso: IIRC that mostly needed testing whether it works, right? [08:07] pitti: are you feeling better, btw? [08:07] didrocks: oh, yes; first night without having to take a decongestant [08:07] didrocks: bonjour [08:08] pitti: guten morgen! [08:08] pitti: ah, nice. Hope you will have some restfull night again before the rally :) [08:13] pitti: Haven't tested yet, I actually need to find a java app to test with. [08:15] TheMuso: any particular requirements? should be easy to grab a .jar from somewhere and run it [08:17] TheMuso: apt-get install cronometer -> relatively small, but full swing GUI [08:17] and runs without any setup [08:33] hey guys, is any one else getting gsd crashes on Precise? [08:48] rickspencer3: do you have any issue with your connection? [08:49] rickspencer3: re your gsd crash: I read some people got some. chrisccoulson was looking at it yesterday [09:13] good morning everyone [09:13] the gsd crash could be bug 903973 [09:13] Launchpad bug 903973 in xorg-server "gnome-settings-daemon crashed with signal 5 in _XReply()" [High,In progress] https://launchpad.net/bugs/903973 [09:14] didrocks, rickspencer3 ^^ [09:14] good morning chrisccoulson, how are you? [09:15] pitti: Ok cool, will test next week. [09:16] hi chrisccoulson [09:16] thanks for the link [09:18] sudo rm -rf usr/lib/python2.7/dist-packages/kazam/ [09:18] whoops [09:23] hey [09:23] salut seb128, ça va ? [09:24] lut didrocks, ca va et toi ? [09:24] seb128: ça va bien :) [09:25] hey seb128 [09:26] hey pitti, wie gehts? [09:27] seb128: je suis bien, merci! [09:28] What is this? I can't even ... :> [09:28] BigWhale: C'est un langage drôle! [09:29] pitti, how is your cold? getting better? [09:29] seb128: oh yes, a lot, thanks; should be fine by Sunday :) [09:32] BigWhale: see, pitti's cold makes him speaking a weird language :) [09:33] didrocks, :)) I speak weird language even when I am not cold! ;) [09:33] bazillus frankophonus [09:33] :)) [09:50] pitti, Bon jour [09:51] tkamppeter: Germans talking French to other Germans? /me quickly checks whether Napoleon is back :) [09:51] pitti, kennst Du Dich mit Python aus? [09:52] tkamppeter: I do a lot in Python, yes [09:52] pitti, can you install hplip-gui on Precise and then run "hp-toolbox"? [09:53] mvo, hey [09:53] pitti, this happens only on Precise, on Oneiric there is no problem. So something is wrong with Python on Precise. [09:54] tkamppeter: what exactly? [09:54] I get [09:54] I get a dialog "No Installed HP Devices Found." which is not quite surprising [09:54] tkamppeter: i. e. what should I look out for? [09:54] Traceback (most recent call last): [09:54] File "/usr/bin/hp-toolbox", line 37, in [09:54] from base.g import * [09:54] ImportError: No module named base.g [09:55] The file /usr/share/hplip/base/g.py is there and in HPLIP nothing changed compared to Oneiric. [09:55] hm, where does it set sys.path, though? [09:55] hey seb128, I think I found the solution for my problem, the window is not displayed anymore when the crash happens [09:58] tkamppeter: I added a "print sys.path" right before the import, and /usr/share/hplip is the first entry; so looks ok from here [09:58] tkamppeter: ooh, it's because /usr/bin/hp-toolbox is a symlink to ../share/hplip/toolbox.py [09:58] tkamppeter: it always adds the directory of the program to the library path [09:59] pitti, can it be that Precise's has a bug? The symlink was always there, also in Oneiric and older. [09:59] tkamppeter: perhaps you have a local version where /usr/bin/hp-toolbox is not a symlink/ [09:59] ? [09:59] tkamppeter: what does ls -l /usr/bin/hp-toolbox say for you? [10:00] pitti, yes, it is a real copy in Precise. [10:00] tkamppeter: I just installed the package in precise, and it's a link [10:00] mvo, ok, great, ken find the issue in gwibber as well, it doesn't seem a bug in gtk after all, just that the new code is less tolerant to those errors [10:00] pitti, does "perl -p -i -e 's/.../.../' " turn the symlink into a copy? [10:01] $ dpkg -c /var/cache/apt/archives/hplip-gui_3.11.10-1ubuntu3_all.deb | grep hp-toolbox [10:01] lrwxrwxrwx root/root 0 2012-01-06 01:27 ./usr/bin/hp-toolbox -> ../share/hplip/toolbox.py [10:01] tkamppeter: the .deb is okay [10:01] mvo, in gwibber he didn't cancel a callback which was making it update an image sometime while it was been disposed [10:01] tkamppeter: are you sure that you don't have a local version, or a "make install" or so? [10:01] tkamppeter: sounds possible [10:01] pitti, I am testing the not yet uploaded 1ubuntu4. [10:03] pitti, There I have added [10:03] perl -p -i -e 's:^\s*\#\!/usr/bin/env\s+python.*:#!/usr/bin/python:' ./\ [10:03] debian/tmp/usr/bin/* ./debian/tmp/usr/sbin/* ./debian/tmp/usr/lib/cups/*/* [10:03] to debian/rules, to fix bug 912625. [10:04] Launchpad bug 912625 in hplip "#!/usr/bin/env python breaks Python-based Ubuntu packages in the presence of virtualenvs, local installations" [Medium,In progress] https://launchpad.net/bugs/912625 [10:04] tkamppeter: yep [10:04] $ echo hello > real [10:04] $ ln -s real link [10:04] $ perl -pi -e 's/hello/goodbye/' link [10:04] -rw-rw-r-- 1 martin martin 8 Jan 6 11:04 link [10:05] pitti, this is a bug in perl [10:05] seb128: yeah [10:05] tkamppeter: try perl -pi -e .... `readlink -f file` [10:05] mvo, I knew it, it's all your fault and not gtk's one!!! ;-) [10:06] mvo, you are always trying to drag the good gtk name in the mud! ;-) [10:07] pitti, yes, that's it. Thank you. === rickspencer3_ is now known as rickspencer3 [10:10] seb128: … ;) [10:19] didrocks: I'm trying to test the upstream nm-applet; I already added it to the panel whitelist, but I get a message [10:19] ** Message: applet now removed from the notification area [10:19] didrocks: this string is not from nm-applet itself; does it ring a bell? [10:20] didrocks: if not, don't worry, I'll investigate (or just start the fallback session) [10:21] ah, I can just run gnome-panel in my unity session to see it [10:21] hum, yeah, it rings a bell [10:21] didrocks: so, nevermind [10:21] isn't it the indicator? [10:21] with fallback [10:21] didrocks: upstream doesn't have indicator support, I guess [10:21] I'm running from upstream trunk [10:21] pitti: oh, it's without the indicator [10:21] ok [10:21] so, let me have a quick look at gnome-panel [10:22] I usually develop fixes in upstream trunk first, and then port them to ubuntu [10:22] better revision control, easier to forward upstream, and faster build cycles [10:22] didrocks: don't worry, I'll just run it from gnome-panel [10:22] I just need to see the applet [10:22] pitti, what name did you whitelist? [10:22] (working on boot speed, not visual) [10:22] seb128: "nm-applet" [10:23] pitti, check the .xsession-errors log [10:23] seb128: it's not that message anyway with the reject [10:23] seb128: nothing there [10:23] didrocks, didn't it use to tell the name of what got blocked? [10:24] seb128: yeah, it's something like "rejecting (Xwindoname)" [10:24] but not "applet now removed…" [10:24] didrocks, right, I was looking for where "nm-applet" is the correct name [10:25] where->whether [10:25] yeah, it's not easy to get the right Xwindow name [10:25] but if there is nothing in .xsession-errors about a reject [10:25] well seems like it stopped printing rejects [10:25] http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg2566236.html [10:25] I just tried with vino [10:25] -> seems to be an icon theme issue [10:26] http://ubuntuforums.org/showthread.php?t=1602997 as well [10:26] pitti: don't you have the icon missing as in the thread? [10:27] oh nevermind, I misread [10:27] didrocks: well, it does work fine in gnome-panel, so I think not [10:29] pitti: ok, it's maybe just rejected and unity stopped printint the name, as seb told [10:29] Nm-Applet or nm-applet to whitelist [10:29] (need the X window info) [10:30] didrocks: is there a magic "whitelist all" entry, for testing whether it's that or something else, OOI? [10:30] didrocks: tried these and Nm-applet, no change [10:30] pitti: indeed, just set ['all'] [10:30] pitti: you need to restart unity [10:31] the new setting is not picked up [10:31] ah [10:31] hm, not just unity-panel-service [10:31] didrocks: ok, rebooting then (want to test the new polkit anyway) [10:32] pitti: no, libunity-misc is in the compiz process [10:32] not in the panel service, unfortunately [10:33] pitti: seb128: FYI, it's not under the debug magic variable [10:33] s/not/now/ [10:33] so yeah, not printed by default [10:34] anyway, no need to waste more time on this -- this can just be tested in gnome-panel [10:34] which is painless and quick [10:36] pitti, hey [10:38] pitti, I'm seriously confused ... [10:38] I just updated my laptop to 12.04 ... [10:38] and I can't find *anything* wrong with it [10:39] pitti, any issues I should check for? [10:39] rickspencer3: did you actually upgrade? :-) [10:39] if (username == "rickspencer3") { dontbreak(); } [10:39] pitti, all working with HPLIP on Precise now, thanks for the help. [10:39] lol [10:39] well done [10:39] :) [10:40] * rickspencer3 tries user switching [10:40] rickspencer3: oh, there's this release critical bug! [10:40] rickspencer3: the unity-greeter wallpaper says "11.10"!!!111!! [10:40] tkamppeter: gern geschehen :) [10:41] pitti, STOP THE LINE! [10:42] rickspencer3: seriously, we do have a couple of upgrade bugs still, and some RC bugs as well (https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus#rcbugs) [10:43] pitti, I don't recall having an upgrade to a *stable* release going this smoothly [10:43] rickspencer3: but I don't think we actually _introduced_ a lot of major bugs into precise so far, most of above are already from previous releases [10:43] does this mean that we haven't actually changed anything? ;) [10:43] rickspencer3: we actually did [10:43] should we just stop here and release precise next week ? [10:43] but the new automatic upgrade tests, also with main-all, helped immensely [10:43] we fixed a ton of upgrade bugs [10:43] ogra_, yeah, I am wondering that ;) [10:44] :) [10:45] didrocks: FTR, 'all' helped, I see it now; thanks! [10:45] pitti: great! yw ;) [10:47] didrocks: oh, I know [10:47] WM_CLASS(STRING) = "lt-nm-applet", "Lt-nm-applet" [10:47] didrocks: running from trunk, it's the libtool wrapper :) [10:47] pitti: ahah, funny :-) [10:48] you can chase for a long time for the right name to put! [10:48] 'all' is much easier indeed [10:51] yeah ;) [10:54] ok, notify-osd killed harder [10:54] pitti, nice! [10:55] it already fell out of the boot sequence on my thinkpad, but was still on my dell mini for some reason [11:08] pitti, wifi against eth? [11:08] nope, both system-wide wifi connection [11:09] seb128: I'm actually not sure how I evaded notify-osd on my laptop [11:09] it queries server caps right at startup [11:09] * pitti adds another noWerror.patch to fix FTBFS, *sigh* [11:27] cyphermox: argh, I can't push to n-m-applet bzr; can you please pull lp:~pitti/network-manager-applet/precise into lp:~network-manager/network-manager-applet/ubuntu.head ? [11:29] * ogra_ wonders why all the -common packages from the desktop seed suddenly take over 20min to unpack on arm [11:29] lots of help files, I guess? [11:29] evo-common took even 45min [11:29] pitti, that wasnt the case on oneiric, ubuntu-docs and gnome-user-docs were the only two that did that [11:30] but suddenly i see it in evince-common and evo-common too [11:30] hmm; they didn't really change a lot since oneiric [11:30] different kernel sync behaviour? [11:30] did they switch to some evil compression mechanism ? [11:30] like xz [11:30] ogra_: is it any better with eatmydata? [11:30] ogra_: no [11:30] kernel is the same as in oneiric [11:30] try unpacking the oneiric .deb and compare? [11:31] evolution-common | 3.2.2-0ubuntu0.1 | oneiric-proposed | all [11:31] evolution-common | 3.2.2-0ubuntu3 | precise | all [11:31] not much diff there [11:31] well, i cant play with eatmydata atm, system needs all resources (i'm happy i can still type on IRC) [11:31] i'll try that for the next update === MacSlow is now known as MacSlow|lunch [12:06] mvo: do we also set $RELEASE_UPGRADE_IN_PROGRESS for lucid->precise upgrades? [12:06] mvo: I'm pondering bug 911813 [12:06] Launchpad bug 911813 in lightdm "Lucid to Precise: debconf prompt about which DM to use during upgrade" [Medium,New] https://launchpad.net/bugs/911813 [12:06] if [ -z "$2" -a -n "$RELEASE_UPGRADE_IN_PROGRESS" ]; then [12:06] mvo: ^ if that's true, we don't ask [12:06] mvo: and lightdm is new, so -z "$2" ought to be true [12:07] log has "Selecting previously unselected package lightdm." which confirms this [12:08] mvo: and history.log has it in "install", not in "upgrade" [12:10] pitti: hm, odd. we do set this when the release upgrader is used: os.environ["RELEASE_UPGRADE_IN_PROGRESS"] = "1" [12:10] mvo: oh, wait -- this might actually be a debconf question from gdm, not from lightdm [12:11] * pitti checks gdm [12:12] mvo: yeah, I think that's it [12:12] mvo: sorry for disturbing, thinko :) [12:13] mvo: seems the upgrade logs don't show which debconf questions are asked and shown, do they? [12:23] pitti: unfortuantely not, but that would be a neat addition [12:26] mvo: btw, do you plan an apt upload before a2? [12:29] pitti: yes, I was talking to slangasek about it, but there are some issues in the current bzr that needs to get resolved first [12:39] mvo: I'm also looking forward to a newer apt (for multi-arch reasons), I currently have a custom build in my PPA to be able to install an i386 upstart in an armel container, though there are still bugs in apt preventing it to work as well as it should [12:40] IIRC mostly has to do with considering provides of another architecture (for upstart-jobs for example) [12:41] oh and we have that other bug currently affecting ia32-libs where apt doesn't consider winbind:amd64 as a potential candidate to meet the dependencies and so fails to install ia32-libs unless you explicitly ask for "ia32-libs winbind:amd64" [12:48] stgraber: is that fixed with trunk? [12:49] mvo: last time I cherry-picked a commit from the experimental bzr branch [12:49] mvo: well, for the one commit I needed, I don't know if the ia32-libs problem has been fixed in trunk [12:50] mvo: might be worth building the current trunk so everyone who's been having multi-arch related weirdness can check if that's fixed [12:52] mvo: I believe the commit I had to cherry pick to be able to install upstart:i386 on armel was this one http://bazaar.launchpad.net/~donkult/apt/experimental/revision/2187.1.6 [12:53] so yeah, that specific one seems to be in the trunk (according to the comment in that commit, rev2189 of mainline) === MacSlow|lunch is now known as MacSlow [13:42] hi all [13:45] Can anyone help me with bug 912563? I'm disregarding the NM crash for now and looking at the partman part of the crash (see near the end of the syslog) because I know that better and it looks similar; I'm as certain as I can be that ubiquity never stores None into that column of the tree model, because it would crash immediately afterwards if it did, but pygobject seems to be returning None [13:45] Launchpad bug 912563 in ubiquity "ubiquity crashed with AttributeError in _decode_value(): 'NoneType' object has no attribute 'decode'" [High,Confirmed] https://launchpad.net/bugs/912563 [13:46] In particular I believe that the only code that ever adds rows to that model is ubiquity/plugins/ubi-partman.py lines 1208 and 1215, which are immediately followed by code that would crash if None: [13:46] partition_tree_model.append([item, disk_cache[item]]) [13:46] dev = disk_cache[item]['device'] [13:46] partition_tree_model.append([item, partition_cache[item]]) [13:46] size = int(partition_cache[item]['parted']['size']) [13:46] is it possible that pygobject is losing references somewhere or something? [13:48] pitti, ^ seems something pygobjectish, you are probably the best placed there to have a clue about it ;-) [13:51] cjwatson, are you sure you don't have null values in a column of the model which is supposed to have strings? [13:52] cjwatson, it seems that pygobject was tolerant to that but that http://git.gnome.org/browse/pygobject/commit/gi/overrides/Gtk.py?id=654711d0f940d7480d0f1cdb25a3dc9996f7a706 made it not like it [13:52] you could argue that there is a pygobject bug that null values should be supported [13:52] re (sorry, was at lunch) [13:52] looking [13:52] cjwatson, the s-c pointed which had a similar bt was fixed by https://code.launchpad.net/~kiwinote/software-center/bug905605/+merge/87257 which sets '' rather that nothing [13:52] s-c bug [13:53] but None values in models ought to work [13:53] pitti, than pygobject bug [13:53] pitti, http://git.gnome.org/browse/pygobject/commit/gi/overrides/Gtk.py?id=654711d0f940d7480d0f1cdb25a3dc9996f7a706 makes it not work [13:53] where? [13:53] it should check for None [13:53] type_ == GObject.TYPE_STRING should be false then [13:53] + value = value.decode('UTF-8') [13:53] seb128: (a) I'm as certain as I can be, and yes I did read that commit (b) the partman part of this bug isn't a case of a string column anyway [13:53] for None [13:54] pitti, it's the column type [13:54] not the field type [13:54] it's an object column that apparently contains None and ubiquity itself crashes on that because that's supposed to be impossible heree [13:54] *here [13:54] pitti, if you have a string column and a None value in the model you get value = Nanoe.decode('UTF-8') [13:55] oh, right [13:55] that's a bug indeed [13:55] the NM part of the bug is a case of None in a string column; again, as far as I can tell ubiquity never stores that, but I'm deferring looking at that for now since I don't know the client code there as well [13:55] so yes, I think we should fix that in pygobject [13:55] I agree, but that isn't all of this bug [13:55] need to condense it to a small test case [13:57] cjwatson, sorry I looked to backtrace on the bug first, that's one valid bug even if that's not the one you asked about ;-) [13:57] looking to the other one... [13:57] pitti: did you experience this week's sudoku crash on oneiric also or just precise? [13:57] jbicha: haven't tried on oneiric [13:58] seb128: a pygobject change would make the NM-related backtrace go away, but I'm still not sure None is supposed to be there in the first place ... [14:00] pitti, do you have any clue about the "TypeError: argument of type 'NoneType' is not iterable" errors in https://launchpadlibrarian.net/89179568/syslog? [14:01] cjwatson, do you have a testcase out of running easier than trying to do an install from a liveCD? [14:01] (just in case) [14:01] I wish I did :-( [14:01] seb128: partition == None [14:01] -"out of running" [14:01] you can't iterate over None [14:01] pitti: see what I wrote above [14:02] pitti: as far as I can tell, ubiquity can never store None into that model in that column. If it ever did, it would crash immediately after doing so, and it is not doing that. [14:02] right, that's the other part [14:02] pygobject is giving back None when that's not what ubiquity put into the model [14:02] that's *the* part :-) === nessita1 is now known as nessita [14:10] ok, have a test case for the pygobject None mishandling, will continue on that later [14:11] * pitti boots daily image to reproduce [14:18] cjwatson: I tried the back button a few times, but I don't seem to get _this_ crash (trying to delete an unknown partition got me another, but let's stay on this one for the moment) [14:18] cjwatson: do you know how to reproduce this? [14:19] afraid not :-( [14:19] and clicking "New partition table" doesn't do anything, hmm [14:20] unless Kate's thing about having a chkdsk-requiring Windows partition is implicated someho [14:20] w [14:38] cjwatson: in fact, I think the software-properties crash is exactly the same (also not supposed to be None), and trivial to reproduce [14:38] it should be _("Other...") and is None [14:39] cjwatson: so it looks like a dupe of bug 905602 [14:39] Launchpad bug 905602 in pygobject "software-properties-gtk crashed with AttributeError in _decode_value(): 'NoneType' object has no attribute 'decode'" [High,In progress] https://launchpad.net/bugs/905602 [14:39] phew [14:39] (I reassigned the s-props one to pygobject, working on that now) === m_conley_away is now known as m_conley [14:49] pitti: thanks, I merged it [14:49] cyphermox: ah, "pull" for better history and correct tags, but *shrug*; thanks! [14:50] pitti: yeah, I had some stuff on my local branch too :/ [14:50] dah, I should have pulled and then merged my changes on top, d'oh [14:50] rebase FTW [14:51] I'll say, "moo"? [14:51] didn't know there was rebase for bzr [15:20] cjwatson: hm, back to square one, I think; I analyzed the s-properties problem, and it's because that pygobject patch always changes the returned data type, so a previously working comparison against a str value doesn't work any more [15:20] cjwatson: I think this patch should be reverted completely, as the original justification was wrong (will talk to upstream about it) [15:20] cjwatson: but that still doesn't explain why there are None values [15:21] cjwatson: they might be None values because somewhere the ubiquity code runs into the same trap (expecting str where it now gets unicode) [15:21] but for that it would really be helpful to be able to reproduce this, so maybe skaet still remembers how to do that [15:22] skaet: ^ if you have a way to reproduce which I can't easily replicate here, I'd like to walk you through a few tests [15:22] * skaet looking [15:22] skaet: bug 912563 I mean [15:22] Launchpad bug 912563 in ubiquity "ubiquity crashed with AttributeError in _decode_value(): 'NoneType' object has no attribute 'decode'" [High,Confirmed] https://launchpad.net/bugs/912563 [15:23] pitti, cjwatson, I think I can. I'll be bringing the system to budapest with me. [15:24] monday ok? [15:24] skaet: sure [15:24] the objects in question shouldn't be either str or unicode [15:24] at least for the partman bit of the bug [15:25] cjwatson: ah, interesting; then it's completely unrelated to that pygobject commit [15:25] ah well; note I won't be in Budapest, but maybe Evan can help out with ubiquity-specific bits [15:25] ok, I'll revert that one then, and investigate the ubiquity one in Budapest then [15:25] thanks [15:31] cjwatson: still curious, though; if the affected column type is not a string, then I really don't see how it should get past the type_ == GObject.TYPE_STRING check (as it crashes in the then clause) [15:34] mvo: so, I'll upload a pygobject which should also fix the software-center crash, in case you want to revert the workaround [15:36] pitti: I think you're looking at a different traceback [15:37] cjwatson: I thought we were talking about bug 912563 ; you mean something else then? [15:37] Launchpad bug 912563 in ubiquity "ubiquity crashed with AttributeError in _decode_value(): 'NoneType' object has no attribute 'decode'" [High,Confirmed] https://launchpad.net/bugs/912563 [15:37] mvo, https://jenkins.qa.ubuntu.com/job/precise-softwarecenter-amd64/lastCompletedBuild/testReport/ [15:38] mvo, I skipped test_downloader and will add gtk3 tests. [15:43] didrocks: when is the next unity SRU round planned? [15:44] pitti: aha, nice, I'm curious about the diff that fixed it [15:44] jibel: thanks [15:44] pitti: look at the partman tracebacks in the UbiquitySyslog attachment [15:44] mvo: reverted http://git.gnome.org/browse/pygobject/commit/gi/overrides/Gtk.py?id=654711d0f940d7480d0f1cdb25a3dc9996f7a706 [15:45] mvo: it's breaking existing behaviour, inconsistent with the rest of Gtk, and the original test case in the bug was invalid [15:46] pitti: it's pushed in the ubuntu-desktop ppa right now (like 30 minutes ago) [15:46] pitti: will be pushed in -proposed next week, once we will have the precise unity release [15:48] cjwatson: ah, so let's retitle the bug accordingly? [15:48] * pitti does [16:14] A question! [16:14] *gasp* [16:14] :) [16:14] http://gstreamer.freedesktop.org/wiki/GStreamerHackfest2012 Will gstreamer1.0 land in Pangolin? [16:14] ah that i do not know [16:15] pitti, seb128: ^^ have we decided on gstreamer versions? [16:15] skaet: ^^ [16:16] there was no explicit discussion/decision for this [16:16] if it lands well before FF and doesn't cause major issues, it's fine to update [16:16] no plan concerning gstreamer [16:17] we didn't "maintain" it for years, slomo is doing good work maintaining it in Debian and we sync what they use [16:17] pitti: i think it's parallel installable, so i'd guess there'd be gstreamer1.0 source vs gstreamer0.10, in debian? [16:17] he's part of the upstream teams [16:17] right [16:18] well it's seems not likely that we will use by default for the lts [16:18] dobey: right, but we wouldn't want to have two sources [16:18] and i suspect even if it landed, there'd be a period where some things haven't ported yet, so you'd have to keep both versions around, just like gtk2 vs gtk3 [16:18] it seems incompatible and it's late to land a new serie and port the code [16:18] pitti: not on the CD, surely [16:18] if we switch, then everything should be switched over IMHO, otherwise it's a mess [16:18] not for the lts then... [16:18] at least for main/default install [16:18] yeah [16:18] that's my gut feeling anyway [16:18] we can probably get it in universe for people who want to use it [16:18] ^ sure [16:19] well I'm sure slomo will get it in Debian when it's time [16:19] then we can sync [16:19] seb128: question is if some of gnome 3.4 stuff we ship, will require it, i guess [16:19] no [16:19] I think we'd rather stay at the gnome 3.2 version in that case [16:19] we stay on totem 3.0 to avoid clutter [16:19] oh [16:20] totem uses clutter now? [16:20] yes [16:20] clutter-gst instead of xv for rendering [16:20] ugh [16:20] since 3.2 [16:21] crap ... why do I have to give names to milestones? :/ [16:21] well you have to call a milestone something [16:22] they don't have to be names like "Ed" or anything [16:22] they can be versions [16:22] yeah I know [16:22] still :> [16:22]