[00:29] <jbicha> desrt: the gmenus in Unity are very nice \o/
[00:47] <TheMuso> jbicha: What apps currently use it? I'd like to try for myself for a11y reasons.
[00:50] <jbicha> TheMuso: epiphany-browser gnomine gnotravex iagno mahjongg quadrapassel
[00:50] <TheMuso> Ok epiphany it is then. :)
[00:51] <TheMuso> Hrm epiphany uses clutter? For what?
[00:53] <jbicha> TheMuso: I don't think it needs clutter, but I heard that epiphany < 3.92 might have been broken with the latest webkit
[00:53] <TheMuso> Ah haven't got a new enough indicator-appmenu yet.
[00:53]  * TheMuso updates.
[05:28] <TheMuso> jasoncwarner_: Where can I file a bug against the piece of code responsible for generating that bug webpage?
[05:28] <jasoncwarner_> ha!
[05:28] <jasoncwarner_> directly with kate, I think
[05:28] <BigW> Good Morning.
[05:28] <jasoncwarner_> I talked to her this morning b/c there were some without tags showing up in that list
[05:29] <TheMuso> jasoncwarner_: Ok thanks, nothing quite so serious for me, just something to help me navigate that page a little better with Orca.
[05:29] <jasoncwarner_> oh, fair enough!
[05:29] <jasoncwarner_> are you having trouble with it?
[05:30] <TheMuso> No problems at all, but if the sections like desktop et al were marked with header tags, I could use Orca's next heading/previous heading navigation commands to move between the different bug groups.
[05:30] <TheMuso> Without having to go through an entire list of bugs for a particular team before getting to the next one.
[05:52] <pitti> Good morning
[06:18] <didrocks> good morning
[06:30] <pitti> bonjour didrocks
[06:30] <didrocks> hey pitti, how are you?
[06:31] <pitti> quite fine, thank you!
[06:32] <didrocks> fever and tired definitively behind you?
[06:32] <pitti> absolutely, yesterday was quite fine already
[06:33] <RAOF> Hey didrocks, pitti!
[06:33] <RAOF> Good moring!
[06:34] <didrocks> good evening RAOF ;)
[06:34] <didrocks> pitti: good :)
[06:34] <dupondje> Gnome3 seems a bit broken today :(
[06:36] <dupondje> Waarschuwing van vensterbeheer:Log level 8: gtk_style_context_save: assertion `GTK_IS_STYLE_CONTEXT (context)' failed
[06:36] <dupondje> Waarschuwing van vensterbeheer:Log level 8: meta_color_spec_render: assertion `GTK_IS_STYLE_CONTEXT (context)' failed
[06:36] <dupondje> it gets flooded :)
[06:48] <rickspencer3> pitti, didrocks, RAOF good morning guys
[06:49] <rickspencer3> beta2! beta2!
[06:49] <rickspencer3> (freeze ;))
[06:50] <pitti> hey rickspencer3
[06:50] <pitti> oh, right!
[06:50] <didrocks> bonjour rickspencer3!
[06:51] <rickspencer3> hey didrocks
[06:51] <rickspencer3> French Mafia testing going ok?
[06:51] <didrocks> rickspencer3: it's under way. We already spotted some annoying more issues
[06:51] <rickspencer3> didrocks, :(
[06:51] <rickspencer3> well ...
[06:51] <rickspencer3> :)
[06:51] <didrocks> with the compiz ABI break, we need a window of at least 5 hours of build
[06:51] <didrocks> so will be short!
[06:51] <rickspencer3> it's good that the testing works
[06:52] <didrocks> right, it's testing the testing :)
[07:02] <jasoncwarner_> hey rickspencer3 didrocks and pitti...morning, Europeans.
[07:02] <pitti> hey jasoncwarner_
[07:02] <rickspencer3> hey jasoncwarner_
[07:03] <didrocks> hey jasoncwarner_
[07:03] <jasoncwarner_> hey didrocks :) going to be a good day, right? right?  :)
[07:04]  * didrocks crosses fingers :)
[07:04] <didrocks> jasoncwarner_: we already spotted regressions
[07:04] <jasoncwarner_> I'm using the time tested and very scientific method called "THE SECRET" to will the universe to do what I want
[07:04] <didrocks> so trying to keep people busy ;)
[07:04] <didrocks> heh :-)
[07:04] <didrocks> let's see if it works :p
[07:04] <jasoncwarner_> didrocks: did all the branches land that you wanted to land? I saw the recap email and it looked like only some landed
[07:05] <jasoncwarner_> didrocks: in the regressions, anything major?
[07:06] <didrocks> jasoncwarner_: hum, some still worrying and which deserve a fix before pushing
[07:06] <jasoncwarner_> didrocks: k...(pinging thumper)
[07:07] <didrocks> jasoncwarner_: I bother it before you! :p
[07:07] <didrocks> but I guess he's not around yet
[07:07] <didrocks> him*
[07:07] <jasoncwarner_> :)
[07:08] <jasoncwarner_> yeah, I figure thumper tends to have like 10 pings right around this time....
[07:08] <jasoncwarner_> and first thing in my morning ;)
[07:08] <jasoncwarner_> I'm sure he hates having me in this TZ ;)
[07:08] <jasoncwarner_> hey didrocks how is compiz looking? we good to go on that?
[07:08] <jasoncwarner_> I know you need a new build, but are you waiting on anything there?
[07:09] <didrocks> jasoncwarner_: very good, I cherry-picked some other fixes from trunk yesterday
[07:09] <didrocks> jasoncwarner_: and it's a wonderful life on that side :)
[07:09] <didrocks> jasoncwarner_: it's still on the staging ppa for now
[07:09] <didrocks> but there is an ABI break
[07:10] <didrocks> that's why we need a solid window of 5 hours of upload/build
[07:10] <didrocks> times for dependencies to build
[07:10] <didrocks> then publish
[07:10] <didrocks> then depends build…
[07:10] <didrocks> publish…
[07:10] <didrocks> and so on ;)
[07:10] <didrocks> to not having a "zomg you broke the CD"
[07:11] <RAOF> didrocks: You can't stage that in a PPA?
[07:11] <RAOF> That worked pretty well for the X transition.
[07:11] <didrocks> RAOF: we have that in a ppa, but there is no dbgsym package built, pkgbinarymangler isn't as well, right?
[07:12] <RAOF> I'm not sure, actually.
[07:12] <didrocks> RAOF: will be nice next cycle with -proposed opened
[07:12] <RAOF> Not building the dbgsym packages would be annoying, and you'd obviously need a non-virtualised PPA.
[07:13] <didrocks> hyperair: hey, btw, UNE doesn't exists anymore, no more need to move banshee .desktop file to /usr/share/une/applications
[07:13] <didrocks> RAOF: yeah, kind of late for this cycle to change the process I would say
[07:13] <hyperair> didrocks: oh okay, thanks for the notice.
[07:13] <RAOF> didrocks: Yeah, perhaps.
[07:13] <didrocks> hyperair: no worry ;)
[07:13] <didrocks> RAOF: but definitively something on my list for next cycle (/me looks at -proposed)
[07:14] <RAOF> Yeah, if -proposed is open then that's even better.
[07:29] <pitti> didrocks: BTW, as we'll be frozen tomorrow, I'd appreciate if you could upload the new compiz galore to precise-proposed
[07:29] <pitti> didrocks: we can accept it there, let evrything build, and move it to precise in one step, to avoid archive inconsistency for half a day again
[07:29] <didrocks> pitti: to -proposed?
[07:29] <pitti> didrocks: does that sound ok?
[07:29] <didrocks> it's opened?
[07:29] <pitti> didrocks: well, technically it's open all the time
[07:29] <pitti> didrocks: but you can't accept pacakges while precise is not frozen
[07:29] <didrocks> ah ok ;)
[07:30] <pitti> but for beta-2 it will be, so bug 930217 doesn't hit
[07:30] <ubot2`> Launchpad bug 930217 in launchpad "Make proposed pocket useful for staging uploads" [Low,Triaged] https://launchpad.net/bugs/930217
[07:30] <pitti> rickspencer3: ^ FYI
[07:30] <didrocks> but that would mean that they will be accepted tonight?
[07:30] <pitti> that'll also be a real-world test drive for that approach
[07:30] <pitti> cjwatson: ^ FYI as well
[07:30] <didrocks> at first (just after we are frozen)
[07:30] <pitti> didrocks: ah, I thought you were planning an upload tomorrow
[07:30] <pitti> didrocks: if you want to upload today, please go ahead
[07:30] <pitti> earlier >> test-driving
[07:30] <didrocks> pitti: well, we don't know yet :)
[07:31] <didrocks> and I don't want to break if the release team isn't happy with a safer upload tomorrow
[07:31] <pitti> ok
[07:31] <didrocks> right now, we have regressions I would prefer we won't let them enters
[07:31] <pitti> what I mean is: correct >> earlier >> test driving :)
[07:31] <didrocks> we'll know more in a couple of hours
[07:32] <didrocks> will keep you in touch
[07:32] <pitti> cheers
[07:49] <rickspencer3> thanks for the fyi pitti
[07:49] <rickspencer3> also, can I say, "pretty cool"
[07:50] <rickspencer3> that's a meaningful advance in our release process
[07:51]  * rickspencer3 steps away
[07:56] <tkamppeter_> pitti, can you upload CUPS to Debian and Ubuntu? Thanks.
[07:57] <jibel> pitti, Sweetshark good morning.
[07:57] <jibel> pitti, Sweetshark I added a testcase to bug 916291 . I think we can find a smaller set of packages to reproduce the problem
[07:58] <ubot2`> Launchpad bug 916291 in libreoffice "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [Critical,Triaged] https://launchpad.net/bugs/916291
[07:58] <jibel> but at least with this packages, the upgrade crashes systematically
[07:58] <jibel> *these
[08:01] <pitti> jibel: bonjour! thanks for this
[08:02] <didrocks> RAOF: there has been no recent change in mesa/intel driver?
[08:09] <bryceh> didrocks, last change to mesa was the 17th, which was just a dependency tweak.  -intel hasn't received a change since the 15th of Feb.
[08:10] <didrocks> ok, thanks ;)
[08:10] <bryceh> didrocks, mesa 8.0.2 was released yesterday and is on the docket but hasn't landed yet
[08:10] <didrocks> bryceh: we are seeing a crash in the driver right now
[08:10] <bryceh> which driver?
[08:10] <didrocks> getting the dbgsym stacktrace
[08:10] <bryceh> ah the mesa/intel driver
[08:11] <didrocks> right
[08:11] <didrocks> https://pastebin.canonical.com/62804/
[08:11] <bryceh> didrocks, the main crash we've been seeing there is the intel_miptree_release() bug (#926379)
[08:11] <didrocks> ok, it's the same :)
[08:12] <bryceh> pretty much all the other mesa bugs we're tracking are random (non-crash) gunk - https://bugs.launchpad.net/ubuntu/+source/mesa?field.tag=precise&field.tags_combinator=ALL
[08:12] <didrocks> bryceh: thanks for the link :)
[08:13] <bryceh> didrocks, I repro'd the bug on my own hardware using an instrumented mesa, and collected debug data.  Waiting for advice from upstream, but might dig in further if I have time.
[08:14] <bryceh> anyway, nite.
[08:14] <didrocks> bryceh: have a good night! and thanks again ;)
[08:21] <tkamppeter> pitti, hi
[08:21] <pitti> hello tkamppeter
[08:22] <tkamppeter> pitti, can you upload cups-filters and cups to Debian and Ubuntu? Thanks.
[08:22] <pitti> yes, at it; I'm currently updating my chroots
[08:44] <pitti> didrocks: I feel really bad at pinging you, but I have to: does the new unity fix the resizing area again, or is that a gtk bug?
[08:44] <pitti> (bug 160311)
[08:44] <ubot2`> Launchpad bug 160311 in metacity "Resizing windows by grabbing window borders is difficult" [Low,In progress] https://launchpad.net/bugs/160311
[08:44] <didrocks> pitti: it fixes it
[08:44] <pitti> for 3D I mean (I know it has always been broken in 2d)
[08:44] <pitti> didrocks: \o/
[08:44] <didrocks> pitti: you had this only if you didn't install mutter
[08:44] <didrocks> which is the case rarely isn't it? :p like just in the default install ;)
[08:45] <didrocks> yeah, will still be broken in 2d though
[08:45] <pitti> didrocks: cheers!
[08:45] <didrocks> ;)
[08:45]  * didrocks goes back to this crash on startup…
[08:45]  * pitti hugs didrocks, merci
[08:46]  * didrocks hugs pitti back
[08:46] <htorque> bryceh: hi! can bug 926379 be related to those invalid writes (valgrinding compiz): http://paste.ubuntu.com/886919/ ?
[08:46] <ubot2`> Launchpad bug 926379 in xserver-xorg-video-intel "compiz crashed with SIGSEGV in intel_miptree_release()" [Critical,Confirmed] https://launchpad.net/bugs/926379
[08:47] <htorque> before opening a wishlist bug report: is the new GTK color picker just a stop gap? → http://img.xrmb2.net/images/709325.png
[08:47] <htorque> (the old one looked like this: http://img.xrmb2.net/images/620480.png)
[08:47] <xclaesse> ricotz, FYI the g-k update in gnome3 ppa did not fix my problem, still asking for the ssh password when I do "git pull"
[08:48] <xclaesse> oh and since last update, now in gnome-shell, windows decoration is just black bar
[08:51] <seb128> hey
[08:51] <ricotz> xclaesse, have you tried to confirm your g-k problem with the ubuntu packages? (make sure to revert all g-k related packages)
[08:51]  * pitti hugs seb128
[08:52]  * seb128 hugs pitti
[08:52] <didrocks> salut seb128
[08:52] <ricotz> hello everyone
[08:52] <seb128> pitti, happy beta2 freeze day? ;-)
[08:52] <seb128> hey didrocks, ricotz
[08:52] <pitti> hey ricotz, guten Morgen
[08:52] <pitti> seb128: and to you!
[08:52] <seb128> pitti, how are you today?
[08:53] <pitti> seb128: splendid, thanks! just a bit scared about how much stuff there is still to do..
[08:53] <ricotz> xclaesse, could to toggle the window-manager theme? when you are not using adwaita -- might be a graphics card driver problem if you are using a propritary one?
[08:53] <seb128> pitti, don't tell me!
[08:54] <ricotz> pitti, libreoffice natty amd64 build turned out well, /me added another builder to the "good" list ;)
[08:54] <pitti> ricotz: yay! king it is
[08:54] <xclaesse> ricotz, it's intel chipset here
[08:54] <xclaesse> ricotz, changing theme does nothing
[08:55] <ricotz> xclaesse, hmm, any other x related ppas active?
[08:55] <xclaesse> ricotz, but I see there is a mutter update now, but that would remove gnome-shell... I guess I should wait for the update batch to be done
[08:55] <ricotz> xclaesse, ah, you are still on .90?
[08:55] <ricotz> better wait for .92 then
[08:55] <xclaesse> gnome-shell is .90 yes
[08:57] <xclaesse> ricotz, oh, I see vuntz has that same problem actually
[08:57] <xclaesse> so that would be upstream
[08:57] <vuntz> xclaesse: look at your ~/.xsession-errors :-)
[08:57] <ricotz> on intel too?
[08:58] <xclaesse> vuntz, ah, right, lots of warnings
[08:58] <vuntz> ricotz: yes
[08:59] <xclaesse> switching windows/workspace is also not smooth anymore
[08:59] <xclaesse> maybe related
[08:59] <ricotz> vuntz, didnt see it here
[08:59] <ricotz> but i am on a newer mesa, i guess
[08:59] <xclaesse> ricotz, gnome-shell .92 is already uploaded?
[08:59] <ricotz> xclaesse, yes
[08:59] <xclaesse> good
[09:00] <kelemengabor> hi, could someone take a look at bug #943279? We have a brand new default VNC client without any translation templates, and that's rather ugly.
[09:01] <ubot2`> Launchpad bug 943279 in remmina "Remmina i18n support problems" [Undecided,New] https://launchpad.net/bugs/943279
[09:01] <chrisccoulson> good morning everyone
[09:01] <seb128> hey chrisccoulson
[09:01] <seb128> how are you?
[09:01] <pitti> hey chrisccoulson
[09:01] <seb128> kelemengabor, looking
[09:02] <kelemengabor> thanks!
[09:02] <chrisccoulson> hi seb128, pitti, how are you?
[09:02] <pitti> chrisccoulson: I'm great, thanks
[09:04] <xclaesse> pff, ppa-purge to remove gnome3 ppa wants to remove all gnome packages... :(
[09:05] <seb128> chrisccoulson, I'm good thanks
[09:08] <seb128> chrisccoulson, btw did you plan to look at totem for the bug you pointed the other day? if not I will put on my list for today
[09:08] <chrisccoulson> seb128, i might not be able to look at it today, as i've got a new firefox release to deal with
[09:08] <seb128> kelemengabor, btw thanks for all the work you put into those translation bugs
[09:09] <seb128> chrisccoulson, ok, I'm taking it, beta2 freeze is in 12 hours or so
[09:09] <chrisccoulson> thanks
[09:09] <kelemengabor> seb128: you are welcome :)
[09:25] <Sweetshark> hmmm, is porter-armel down?
[09:26]  * Sweetshark wonders if he killed the littlun with a libreoffice build.
[09:28] <Sweetshark> .oO(thanks aptitude for removing bzr, who needs that anyway in ubuntu development)
[09:42] <xclaesse> ricotz, FYI, I reverted all packages from gnome3 ppa to the version from precise, so I have g-k 3.2.2, and git pull still asking for the password
[09:42] <xclaesse> even after restarting the session
[09:44] <ricotz> xclaesse, so something might be wrong with you setup
[09:45] <ricotz> xclaesse, could be useful to create a separate clean user profile to test/confirm with
[09:48] <ricotz> xclaesse, for me it is working fine here with ssh and gpg keys
[10:05] <xclaesse> ricotz, checking gnome-session-properties, and I don't see ssh agent started there
[10:05] <xclaesse> ricotz, shouldn't it include gnome-keyring something?
[10:09] <seb128> xclaesse, we hide system services from the session properties dialog
[10:15] <Sweetshark> pitti: can we get 3.5.1-1ubuntu1 into the distro now? all but armel succeeded building.
[10:15] <Sweetshark> I am trying to look into the armel thing, but the porter box seems to be down now.
[10:15] <pitti> Sweetshark: what do you mean? it is already in precise
[10:16] <Sweetshark> pitti: duh
[10:16]  * Sweetshark takes his meds.
[10:16] <Sweetshark> ;)
[10:17] <xclaesse> seb128, ah ok
[10:17] <xclaesse> ricotz, ah, mutter/gnome-shell updated now, and black bar is fixed :)
[10:17] <xclaesse> vuntz, ^
[10:17] <pitti> tkamppeter: FTR, sid is currently broken, need to wait a bit (pcre3)
[10:19] <vuntz> xclaesse: weird, I'm up-to-date and I see this; I might need to log out and log in again
[10:37] <tkamppeter> pitti, what does "pcre3" mean?
[10:37] <tkamppeter> pitti, should the packages be uploaded Ubuntu-only then?
[10:37] <pitti> tkamppeter: Debian uploaded a bad pcre3 library yesterday, which pretty much breaks everything
[10:38] <pitti> tkamppeter: a fix is already in place, but it still needs a couple of hours to land
[10:38] <pitti> tkamppeter: if it's urgent, then you can do that
[10:38] <tkamppeter> pitti, it simply should go before beta2 freeze.
[10:53] <pitti> tkamppeter: so better upload it now
[10:58] <mandel> can anyone give me a hand with lighdm, I'm not able log in with my account (mandel) and I had to install gdm to be able to use my machine, my lightdm logs are the following: http://paste.ubuntu.com/894951/
[10:58] <mandel> you will see that I can log as a guest which I used to su to my account which has sudo right and install gdm
[11:05] <tkamppeter> pitti, are you using a German or an English UI?
[11:05] <pitti> tkamppeter: German
[11:05] <tkamppeter> pitti, can you enter the command "lpstat -r" and tell me the output?
[11:06] <pitti> $ lpstat -r
[11:06] <pitti> scheduler is running
[11:07] <tkamppeter> pitti, do you have any German translated output from CUPS command line tools?
[11:07] <tkamppeter> seb128, hi
[11:07] <seb128> tkamppeter, hey
[11:07] <pitti> tkamppeter: I don't; ./locale/cups_de.po does not actually have any translations
[11:08] <pitti> tkamppeter: well, some, but only very few
[11:08] <tkamppeter> seb128, I assume that you have a French user interface. Can you run "lpstat -r" and post the output here?
[11:08] <seb128> tkamppeter, "scheduler is running"
[11:09] <tkamppeter> seb128, thanks.
[11:09] <seb128> yw
[11:09] <pitti> tkamppeter: see /usr/share/cups/locale/fr/cups_fr.po
[11:10] <pitti> it seems nobody really bothered to actually translate those
[11:10] <tkamppeter> pitti, seb128, it is because of bug 960496, for me (using English UI) updating of the PPDs of existing print queues works, for some other users not.
[11:10] <ubot2`> Launchpad bug 960496 in gutenprint "[Precise] [Regression] Cannot print on Epson CX3650" [Undecided,New] https://launchpad.net/bugs/960496
[11:11] <pitti> tkamppeter: if I add a tranlation to /usr/share/cups/locale/de/cups_de.po, I get
[11:11] <pitti> $ lpstat  -r
[11:11] <pitti> Steuerprogramm läuft
[11:11] <pitti> tkamppeter: i. e. the machinery is working, just all the translations are missing upstream
[11:12] <pitti> tkamppeter: eek, how do PPDs depend on translated client messages? that sounds wrong
[11:13] <didrocks> pitti: bug #916892, seems it can be the cause that unity doesn't show up usb keys on the launcher anymore?
[11:13] <ubot2`> Launchpad bug 916892 in unity-distro-priority "gnome-disk-utility crashed with SIGSEGV in gdu_device_get_object_path()" [Undecided,Fix committed] https://launchpad.net/bugs/916892
[11:14] <tkamppeter> pitti, if you look into the postinst script of cups, /var/lib/dpkg/info/cups.postinst, you see that before the PPD update is started, at first it is checked whether the scheduler is running, analysing output of "lpstat -r", during the update routine there is heavy use of CUPS command line toools.
[11:14] <pitti> tkamppeter: it's running under LC_ALL=C, so that should work
[11:15] <pitti> if only programs would have something like an exit code, so that callers woudln't need to grep i18n'ed output
[11:15] <tkamppeter> pitti, I see now.
[11:18] <tkamppeter> pitti, the PPD updating part of the cups.postinst also checks with "ehich lpstat", "which llpinfo", and "which lpadmin" whether the command line tools are present. Can it happen that they are not present when cups gets configured?
[11:19] <pitti> tkamppeter: no, as cups depends on cups-client
[11:23] <pitti> dpm: hey David, how are you?
[11:24] <dpm> heya pitti, very well, thanks, yourself?
[11:24] <pitti> dpm: quite fine, thanks!
[11:24] <dpm> :)
[11:24] <pitti> dpm: do you have an opinion about bug 961065 ?
[11:24] <ubot2`> Launchpad bug 961065 in apport "[UIFE] Alert inappropriately refers to "program version" for internal errors" [Undecided,Fix committed] https://launchpad.net/bugs/961065
[11:24] <dpm> looking...
[11:24] <pitti> dpm: I want to do an apport upload today before the freeze, either with or without that change
[11:29] <dpm> pitti, ok, it might be a bit of a pain to retranslate it, but I think it makes sense to do the change if it is to comply with the spec. I've commented on the bug.
[11:29] <pitti> dpm: thanks
[11:30] <dpm> pitti, will you send a heads up to the translators list, or do you want me to send it?
[11:30] <pitti> well, if you ask me like this... :)
[11:30] <pitti> but I guess I ought to do it as the uploader
[11:30] <dpm> ha, wrong way of asking :)
[11:31] <didrocks> pitti: bug #916892, seems it can be the cause that unity doesn't show up usb keys on the launcher anymore?
[11:31] <ubot2`> Launchpad bug 916892 in unity-distro-priority "gnome-disk-utility crashed with SIGSEGV in gdu_device_get_object_path()" [Undecided,Fix committed] https://launchpad.net/bugs/916892
[11:32] <pitti> hm, there is no such program like "gnome-disk-utility"
[11:32] <pitti> I suppose someone tampered with the bug title
[11:32] <pitti> didrocks: but yes, could be
[11:32] <pitti> Title: compiz crashed with SIGSEGV in gdu_device_get_object_path()
[11:32] <pitti> ah yes, that's more like it
[11:33] <pitti> it's on my radar, if I ever manage to get out of the mail/backlog/archive/bug swamp of this morning
[11:33] <didrocks> pitti:
[11:33] <pitti> dpm: translators list is which exactly?
[11:33] <didrocks> pitti: thanks :)
[11:34] <dpm> pitti, ubuntu-translators at lists dot u dot c
[11:37] <pitti> dpm: sent, thanks
[11:38] <dpm> cool, thanks pitti
[11:38] <dpm> does anyone here know the remmina upstream developer? He/she's set the translations to open in Launchpad, which is not a very good idea wrt quality
[11:46] <dpm> pitti, while reading the e-mail on the translators list, I've noticed that on https://translations.launchpad.net/apport/trunk/+translations-settings you can set the import settings to "Import template files" instead of "Import template files and translations" - the latter setting is generally for new projects that need a one-off import of PO files, or for vcs imports
[11:47] <pitti> dpm: sometimes I update po/de.po in the branch
[11:47] <pitti> and sometimes merges change them
[11:47] <pitti> so why wouldn't I let them auto-import back to LP?
[11:51] <dpm> pitti, in that case, then it's fine, I was just mentioning it in case, as many projects do not make use of it and maintainers just set it thinking it's the right setting. But as you say, you do make use of it. The only thing to bear in mind is that imports take precedence over translations done in the LP web UI
[11:58] <pitti> dpm: ok, thanks for having a look
[12:00] <chrisccoulson> that sucks. the UDS registration form doesn't work in nightly builds of Firefox
[12:26] <seb128> chrisccoulson, iz firefox bog!
[12:26] <chrisccoulson> firefox doesn't have any bugs! :-P
[12:30]  * mpt just encountered a very odd Firefox bug
[12:31] <mpt> (bug 799400)
[12:31] <ubot2`> Launchpad bug 799400 in firefox "message missing when trying to upload ureadable file" [Undecided,Confirmed] https://launchpad.net/bugs/799400
[12:39] <ndec_> seb128: hi. assuming gst 1.0 get released soon, i was wondering if moving to gst 1.0 in 12.10 is something doable, or not even an option... did you think about that already?
[12:39] <seb128> ndec_, hey, "lol" ;-)
[12:40] <ndec_> lol ?
[12:40] <ndec_> i didn't realize it was a joke!
[12:40] <seb128> ndec_, we are focussed on 12.04
[12:40] <ndec_> i know ...
[12:40] <ndec_> so am i
[12:40] <ndec_> for the OMAP part of it!
[12:40] <seb128> so "if", "assuming", "maybe", "could"
[12:40] <seb128> said differently no clue, it's too early to say
[12:40] <seb128> gst 1.0 is not out
[12:40] <seb128> UDS is not there yet
[12:41] <seb128> we are focussed on 12.04 I didn't give any thinking to 12.10
[12:41] <seb128> it mostly depends what upstream people do, i.e totem, rhythmbox, banshee, pitivi, etc
[12:41] <seb128> it's the sort of "let's wait for gst1.0 to be out, let's wait to see how much work is porting an app, and let's see what happen"
[12:42] <ndec_> thx
[12:42] <seb128> yw
[12:42] <seb128> ndec_, sorry but there is just too much "unknown" is that equation to have a reply and it's not the right timing in any case, we will probably discuss it at UDS
[12:43] <seb128> ndec_, do you need 1.0 for anything? I guess we will have it in the archive for sure for 12.10, I can't see how much we will port though...
[12:43] <ndec_> seb128: no worry. i wasn't expecting a commitment, just a thought about feasibility!
[12:43] <ndec_> basically i just wanted to hear that you were not strongly opposed to the idea
[12:43] <seb128> ndec_, I'm waiting for gst1.0 to be out first and to see how goes the first app porting
[12:43] <seb128> ndec_, ideally I would like to move to it if it's feasable
[12:44] <ndec_> yeah, we kind of need gst1.0 for ARM SoC (at least the one i care about: OMAP)
[12:44] <seb128> ok, that's a good reason to push for it
[12:44] <ndec_> we can get around with gst0.10.. but with 1.0 we can use upstream, and get rid of the pile of patches we have on 0.10
[12:44] <seb128> ndec_, do you know what's the roadmap from the gst guys to have the stable out?
[12:44] <ndec_> soon
[12:44] <seb128> ok
[12:45] <seb128> so yeah, starting to use it next cycle makes sense
[12:45] <seb128> I'm not sure how much we can "port" in one cycle though
[12:45] <BigWhale> if gst1.0 becomes stable and performance is better and xvimagesrc is ported to 1.0 then I'll switch too...
[12:45] <BigWhale> with Kazam.
[12:46] <BigWhale> so I'd be happy to see it in 12.10 too :)
[12:53] <kelemengabor> seb128: sorry, I had to reopen bug #943279 - it's not perfect yet :(
[12:53] <ubot2`> Launchpad bug 943279 in remmina "Remmina i18n support problems" [High,Triaged] https://launchpad.net/bugs/943279
[12:54] <seb128> kelemengabor, are you sure?
[12:55] <seb128> kelemengabor, I looked at the code, the plugins code use the "remmina" domain
[12:55] <seb128> kelemengabor, there is only one GETTEXT_PACKAGE defined in the soruce
[12:55] <kelemengabor> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/remmina/precise/view/head:/remmina-plugins/po/CMakeLists.txt
[12:55] <seb128> kelemengabor, I think upstream is buggy
[12:55] <kelemengabor> is this not redefining it?
[12:56] <kelemengabor> I don't speak CMakeLists though, just assuming this based on the upstream...
[12:56] <seb128> kelemengabor, I don't speak CMakeLists either
[12:57] <seb128> let me check
[12:57] <desrt> seb128: nor should you learn :)
[12:57] <seb128> hey desrt, how are you ?
[12:57] <desrt> although.... i have to say... CMakeLists have a lot in common with french
[12:57] <desrt> good :)
[12:58] <seb128> desrt, looking to make friends today? ;-)
[12:58] <desrt> seb128: by your estimation, which group should be more insulted by that statement? :)
[12:59] <seb128> desrt, I think it's insulting the french!
[12:59] <seb128> ;-)
[13:03] <kenvandine> seb128, thx for the review!
[13:03] <kenvandine> seb128, please don't forget the other one though :)
[13:03] <seb128> kenvandine, hey, yw!
[13:04] <seb128> kenvandine, doh, thanks for pointing it, I didn't notice there were 2 of them, I went through by email a bit quickly
[13:04] <kenvandine> :)
[13:04] <kenvandine> you did the second one :)
[13:04] <kenvandine> https://code.launchpad.net/~ken-vandine/telepathy-indicator/lp_926072/+merge/98719
[13:04] <kenvandine> after submitting that, i found that it also fixes 2 other fixes too :)
[13:05] <seb128> kenvandine, I'm reading it, do you care about old C compliance or are you C99?
[13:05] <kenvandine> i don't really care :)
[13:06] <seb128> kenvandine, i.e you did a variable declaration after the g_return_val_if_fail()
[13:06] <kenvandine> but don't mind cleaning it up
[13:06] <kenvandine> ah
[13:06] <seb128> I know some GNOME guys used to report bugs about those
[13:06] <seb128> saying it's a c99ish
[13:06] <seb128> ism
[13:06] <kenvandine> yeah, i did that on purpose... i like doing that before doing anything else
[13:06] <kenvandine> but i know not everyone agrees with that :)
[13:07] <seb128> kenvandine, ok, approved
[13:07] <kenvandine> thx!
[13:07] <seb128> yw ;-)
[13:07] <kenvandine> i think that makes all open bugs for tp-indicator fixed
[13:07] <kenvandine> :)
[13:07] <kenvandine> woot
[13:07] <pitti> hey kenvandine
[13:07] <seb128> \o/
[13:07] <kenvandine> hey pitti
[13:07] <pitti> kenvandine: FYI, new pygobject with fix for mardy is in precise
[13:08] <kenvandine> great
[13:08] <kenvandine> thx
[13:09] <pitti> kenvandine: I'm getting the hang of doing upstream releases :)
[13:10] <kenvandine> pitti, hehe... yeah it is a little different :)
[13:10] <kenvandine> then you get downstreams yelling about bugs :)
[13:13] <BigWhale> Can someone comfirm this: Make sure you have multiple windows opened (couple of terminals, xchat, browser) Press CTRL-ALT-UPARROW to change desktop, tap ALT to open HUD, tap ALT to close HUD, press CTRL-DOWNARROW, again tap ALT twice. Repeat couple of times, see windows jump around ...
[13:15] <kelemengabor> seb128: false alarm, you are right. I just installed an upstream remmina-plugins.po as remmina.mo and its strings showed up translated
[13:16] <kelemengabor> sorry
[13:16] <seb128> kelemengabor, yw
[13:16] <seb128> kelemengabor, I just concatenated all strings from both source in the remmina template
[13:16] <seb128> kelemengabor, which should work
[13:16] <kelemengabor> great :)
[13:20] <kenvandine> anyone know if the gnome classic session should have a messaging menu?
[13:22] <seb128> kenvandine, I think it does, jbicha let the default config be "classic Ubuntu" like
[13:22] <seb128> i.e with indicators
[13:23] <kenvandine> i thought so
[13:23] <kenvandine> but i am not getting the messaging menu
[13:23] <kenvandine> seb128, it occurred to me that we probably don't want OnlyShowIn=Unity; for tp-indicator
[13:24] <kenvandine> because of gnome classic
[13:24] <seb128> kenvandine, it's there for me
[13:24] <seb128> in a guest session ubuntu classic
[13:24] <kenvandine> ah, let me try a guest session :)
[13:25] <kenvandine> ah, great
[13:25] <kenvandine> it is for a guest session
[13:26] <seb128> kenvandine, you want that I think
[13:26] <seb128> OnlyShowIn=GNOME;Unity;
[13:26] <seb128> AutostartCondition=GNOME3 unless-session gnome
[13:26] <seb128> kenvandine, that's i.e what we use for the gsd mounter
[13:26] <kenvandine> seb128, cool
[13:26] <seb128> kenvandine, "gnome" is gnome-shell
[13:26] <kenvandine> i'll check
[13:26] <seb128> kenvandine, that should make it run under unity and gnome-classic
[13:27] <jbicha> I really wish there were separate OnlyShowIn values for GNOME Shell & Classic since they're so different
[13:27] <seb128> right
[13:27] <kenvandine> there really should be
[13:27] <jbicha> for instance we want Onboard to show in Classic GNOME, but GNOME Shell has a built-in onscreen keyboard
[13:28] <kenvandine> anyone know what settings i should clear to get the default setup again in gnome classic?
[13:28] <jbicha> & the AutostartCondition line doesn't work there because we use an autostartcondition to check if the keyboard should be on or not
[13:28] <jbicha> only allowing one AutostartCondition might be a bug though...
[13:29] <jbicha> kenvandine: I believe gsettings reset-recursively org.gnome.gnome-panel would work
[13:29] <jbicha> but it depends on what settings you're talking about
[13:30] <kenvandine> jbicha, that did it
[13:30] <kenvandine> i didn't have the indicators
[13:41] <Darxus> Any chance of cherry picking this patch for Precise?  https://bugzilla.gnome.org/show_bug.cgi?id=672358#c8  I know it's late, but I have to ask.
[13:41] <ubot2`> Gnome bug 672358 in wayland "Wayland and X11 backends simultaneously enabled is broken" [Normal,Unconfirmed]
[13:42] <seb128> Darxus, we don't build the wayland backend so it's not a bug in Ubuntu
[13:42] <seb128> Darxus, also we will ship GTK 3.4 when it's rolled out next week, so get it commited upstream this week?
[13:43] <tjaalton> trying to build sound-juicer 3.3.90, but after autoreconf it complains about missing GNOME_COMMON_INIT
[13:43] <seb128> tjaalton, install gnome-common
[13:43] <tjaalton> seb128: thanks
[13:43] <seb128> yw
[13:43] <Darxus> Okay.  (I was thinking it would make rebuilding with both backends slightly easier.)
[13:45] <tjaalton> seb128: can you recall if there's a gnome package with cdbs that runs autoreconf during build?
[13:49] <seb128> tjaalton, 90% of GNOME
[13:49] <tjaalton> oh :)
[13:50] <tjaalton> I'll look for an example then
[13:50] <jbicha> tjaalton: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-shell/debian/rules?view=markup
[13:50] <seb128> tjaalton, what's the issue?
[13:50] <tjaalton> jbicha: thanks
[13:50] <tjaalton> seb128: building s-j from git
[13:50] <seb128> tjaalton, basically depends on dh-autoreconf
[13:51] <seb128> then include the autoreconf.mk
[13:51] <seb128> that's it
[13:51] <tjaalton> yeah
[13:51] <seb128> tjaalton, why not just packaging 3.3.90?
[13:51] <tjaalton> seb128: no tarball
[13:51] <tjaalton> i'm using the tag
[13:51] <seb128> tjaalton, ?
[13:51] <seb128> http://ftp.acc.umu.se/pub/GNOME/sources/sound-juicer/3.3/sound-juicer-3.3.90.tar.xz
[13:51] <seb128> tjaalton, ^
[13:52] <seb128> tjaalton, or what do you mean no tarball?
[13:52] <tjaalton> http://ftp.gnome.org/pub/GNOME/sources/sound-juicer/ doesn't have it
[13:52] <seb128> tjaalton, ?
[13:52] <tjaalton> uh
[13:52] <tjaalton> uscan didn't find it
[13:52] <seb128> tjaalton, you got me very confused
[13:52] <jbicha> xz
[13:52] <tjaalton> sorry
[13:53] <tjaalton> right, the watch file is outdated
[13:53] <jbicha> silly GNOME has to keep changing things!
[13:59] <chrisccoulson> woohoo - https://twitter.com/#!/mike_conley/status/182826884256628736 \o/
[13:59] <chrisccoulson> native pdf rendering in firefox :)
[13:59] <chrisccoulson> take that, chrome
[14:01] <pitti> sweet! but .js, is that any fast, compared to poppler?
[14:02] <jbicha> chrisccoulson: oh it finally landed? awesome, that's future FF14 then?
[14:02] <chrisccoulson> jbicha, yeah, it is
[14:03] <chrisccoulson> pitti - js is pretty fast, and it's better than adding more binary code to the tree (especially for pdf rendering, which doesn't have the greatest history for stability or security)
[14:03] <chrisccoulson> and pdf.js works on all platforms ;)
[14:03] <pitti> yes, absolutely
[14:03] <pitti> I was just curious
[14:04] <chrisccoulson> the good thing about something like pdf.js is that it doesn't widen the attack surface any further :)
[14:05] <seb128> chrisccoulson, well it's still extra code dealing with pdf parsing in your browser
[14:06] <seb128> so it does increase chances you get a security issue
[14:06] <seb128> chrisccoulson, I like better having pdf opening in evince under apparmor ;-)
[14:06] <jdstrand> \o/
[14:06] <pitti> hm, I just got four clicking noises out of my speakers for the fourth time in 15 minutes
[14:06] <pitti> but there's nothing that tells me what these are about
[14:06] <pitti> WTH?
[14:07] <chrisccoulson> seb128, it runs in content context, so it's bound by existing browser security technologies
[14:07] <chrisccoulson> which is why i said that it doesn't widen the attack surface ;)
[14:07] <chrisccoulson> if it ran in privileged context, then that wouldn't be true :)
[14:07] <seb128> chrisccoulson, did we have any "in browser pdf viewer" before?
[14:07] <seb128> I though we just called evince
[14:07] <tjaalton> yeah, multidisc musicbrainz queries work in the new s-j just as planned.. ship it :)
[14:08] <chrisccoulson> seb128, the adobe plugin. and chrome has its own proprietary binary plugin too
[14:08] <jdstrand> chrisccoulson: well, except you are trusting the browser to get it right. apparmor helps make sure that even if the app got it wrong, things are contained
[14:08] <seb128> chrisccoulson, I never understood people reading their pdf in the browser to be honest
[14:08] <jbicha> seb128: you don't use apparmor for your firefox?
[14:08] <chrisccoulson> jdstrand, right. but if the browser doesn't get it right, then the holes are already there :)
[14:08] <jdstrand> (of course, if you browser is confined with apparmor, you are ok-- but that is not something we can turn on by default in Ubuntu)
[14:08] <seb128> jbicha, ^
[14:09] <jdstrand> jbicha: I absolutely do! :)
[14:10] <seb128> chrisccoulson, be careful, you seem on the path to want to get ride of the desktop to only run a webbrowser ;-)
[14:10] <chrisccoulson> heh
[14:10] <jdstrand> chrisccoulson: 'if the browser doesn't get it right, then the holes are already there'. I don't follow-- yes there is a hole if the browser didn't get it right. I'm saying that if evince/poppler doesn't get it right, apparmor confines what an attacker can do in the default install. if the browser doesn't get it right, apparmor isn't there for the browser in the default install
[14:10] <mdeslaur> I think getting rid of everything and only keeping the most insecure one is a great idea

[14:11] <seb128> hehe
[14:11] <seb128> I like better having a real pdf viewer in any case, there is enough specific ui bits in there that it fits better in an application with presentation mode, continuous or by page scrolling, etc
[14:12] <seb128> the "move everything in the browser" trend is just wrong ;-)
[14:12] <seb128> let the browser do what it's built to do, browse the web, don't try to turn it into my desktop!
[14:12] <jdstrand> I tend to agree. I used to obsess over having acroread work in the browser. now I really like the separate process
[14:13] <jbicha> seb128: you could always use epiphany ;)
[14:13] <jdstrand> (and by 'now' I mean for the last several years)
[14:13] <seb128> jbicha, I could...but nah, I like having a good browser and firefox is pretty amazing ;-)
[14:13] <jbicha> actually with it being open source, I guess other browsers will look at scooping it up
[14:15] <tjaalton> seb128: does s-j fall under the gnome "FFe"? :)
[14:15] <seb128> tjaalton, bug fix versions are not under ffe and we live on a git snapshot, I would say better to update to an official tarball
[14:15] <pitti> we do not formally have a standing gnome FFE any more
[14:16] <tjaalton> seb128: true, at least it fixes this one musicbrainz-related bug, likely more
[14:16] <tjaalton> I'll check the list
[14:17] <mterry> RAOF, sorry for not pushing my last unity-greeter packaging changes to bzr!  :(
[14:17] <mterry> just noticed
[14:31] <mpt> mvo, here's what I've come up with based on our chat about OS upgrades a couple of weeks ago: https://wiki.ubuntu.com/ReleaseUpgrades#ready
[14:33] <mvo> mpt: thanks, in a meeting right now, but I have a look
[14:34] <jbicha> mpt: the configuration file conflict proposal might not be nice
[14:44] <mpt> jbicha, alternatives welcome. :-)
[14:45] <mpt> (Alternatives that don't involve showing a diff or asking people questions they don't know the answer to)
[14:50] <cyphermox> mpt: jbicha: perhaps override the "reboot" in that case and make sure the user is aware that this happened to files.
[14:50] <cyphermox> as in, don't just merrily go ahead and reboot into a system that possibly got broken because of using the package provided config file.
[14:51] <jbicha> well how often do /etc conflicts happen and why? if it's because people have made changes to their configurations...
[14:51] <mpt> In what kind of cases would a system get broken from using the config file provided with the package?
[14:51] <cyphermox> jbicha: not very often.
[14:51] <mpt> Yeah, we need examples
[14:52] <jbicha> well it violates Debian policy, so it'd probably require a bit more discussion than just here
[14:52] <cyphermox> jbicha: there is that
[14:53] <cyphermox> mpt: i've seen conffile update requests for files like /etc/securetty and /etc/vsftpd.conf; not something you just want to override because it can really break a package, or access to the system
[14:53] <jbicha> using /etc/*.d/ folders helps with reducing conflicts
[14:56] <mterry> Daviey, heyo.  Got some time for MIRs.  So there's the python-tz one, and what else are you looking at?
[14:56] <cyphermox> jbicha: back on that gnome-shell merge request you wanted me to review?
[14:56] <cyphermox> looks good to you? I'm not really all that knowledgeable about that gnome-shell should be doing, I never use it ;)
[14:57] <jbicha> cyphermox: is that something that should be fixed in NM?
[14:57] <cyphermox> AFAICS the change seems reasonable
[14:57] <cyphermox> jbicha: well, the disconnect notification was set as CRITICAL from a design bug
[14:58] <cyphermox> (a bug from the design team); to make sure disconnect notifications get seen. I could change it back, but the increase in priority isn't exactly wrong
[14:59] <jbicha> cyphermox: all I have to do is click the notification in gnome-shell and it goes away
[15:00] <cyphermox> right, but it probably should get away by itself, especially if you get back to connected :)
[15:01] <cyphermox> let me give a little fix a try, I have an idea
[15:02] <jbicha> my instinct is that this isn't really a gnome-shell bug
[15:05] <mterry> Daviey, oh, I see a bunch of new MIRs.  on it
[15:08] <cyphermox> jbicha: I don't know. seems to me like any transient notification should indeed be transient, no matter the priority.
[15:09] <jbicha> cyphermox: but is it notify-osd that's doing it wrong?
[15:09] <jbicha> I forget how it works in Fedora
[15:09] <cyphermox> jbicha: what would notify-osd be doing wrong?
[15:09] <cyphermox> jbicha: this fails because we have a distro patch to set the prio of the disconnect notification to CRITICAL
[15:10] <cyphermox> all the notifications are set to be transient though, the hint is set on each of the notifications nm-applet generates
[15:10] <jbicha> I don't know, anyway if you decide the merge is good, I'll accept the patch
[15:30] <cyphermox> jbicha: my feeling is that it's good; but I'd like to get the opinion of gnome-shell developers.
[15:30] <cyphermox> if transient notifications aren't transient, it *should* be a bug, unless it's clearly defined that a critical urgency overrides that
[15:37] <tjaalton> nice, can't get sound-juicer or gvfsd-cdda to crash anymore like on oneiric.. looks like the gvfs updates really made a difference
[16:38] <mterry> Daviey, is maas going to be seeded anywhere?  in Server?
[16:39] <pitti> wasn't it cluttering component-mismatches all over yesterday
[16:39] <pitti> ?
[16:39] <pitti> but not any more, I suppose it was unseeded, or it's dependencies fixed?
[16:56] <mterry> pitti, it has a large MIR chain I'm working on
[16:57] <pitti> yeah, I saw; that looked quite crazy
[16:57] <pitti> and I'm fairly sure we don't want to pull in half of Haskell there
[16:57] <pitti> sabdfl explicitly nacked this as approved technology
[16:57] <mterry> pitti, hadn't gotten to haskell bits yet
[16:57] <pitti> so I guess it needs some serious work to drop some deps
[17:02] <pitti> dpm: argh, I forgot to request a full langpack export for beta-2
[17:02] <pitti> dpm: I requested it now on https://translations.launchpad.net/ubuntu/precise/+language-packs, but can we start a manual export now, so that I can build them tomorrow?
[17:03] <pitti> dpm: otherwise I can forge it from the last base and current delta, but then the next delta packs will be wrong
[17:04] <dpm> pitti, let me ask the lp losas. I think it shouldn't be a problem, the only issue with exports starting in the afternoon is that they are right in the middle of the database disconnect around ~9:00 UTC and they then fall, but perhaps they can postpone tomorrow's disconnect
[17:05] <pitti> dpm: ah, argh; so perhaps building the tarball myself is better then
[17:05] <pitti> and requesting/uploading another one after b2?
[17:08] <dpm> I think we can still ask, but the other issue I can think of is that full exports take about 22 h. So it'd be ready by tomorrow 16:00 our time, which might be a little late.
[17:08] <pitti> sounds OK
[17:09] <dpm> ok, let me check with the LP people
[17:19] <Daviey> mterry: maas is already seeded
[17:24] <pitti> Daviey: ah, so it's dependencies got lighter?
[17:25] <Daviey> pitti: yeah, we trimmed quite a bit.
[17:26] <pitti> Daviey: *phew*, no Haskell in mainn :)
[17:27] <Daviey> pitti: Well, can reintroduce it if you would like? :)
[17:32] <dpm> pitti, ok, full precise langpack export running now, expecting it to be finished tomorrow at about 15:30UTC
[17:32] <pitti> dpm: cheers!
[17:32] <dpm> np :)
[18:12] <dobey> mdeslaur: ping?
[18:12] <mdeslaur> dobey: yes?
[18:13] <dobey> mdeslaur: hi. i'm looking at bug #925713 from you, and trying to figure out the best way to fix it on all the platforms we have to support. It's not exactly clear to me either, how reading from ca-certificates.crt instead of a .pem with the same content is any better
[18:13] <ubot2`> Launchpad bug 925713 in ubuntuone-storage-protocol "CA Certificate is hardcoded" [Undecided,Confirmed] https://launchpad.net/bugs/925713
[18:15] <mdeslaur> dobey: when that CA gets compromised, we will push out a new system ca-certificates package, and we'll change certificate providers on the server
[18:15] <mdeslaur> dobey: having a bunch of hard coded certificates in various packages is incredibly hard to manage
[18:16] <dobey> mdeslaur: right, i understand that, but i don't think these certs are in the ca-certificates package?
[18:16] <mdeslaur> dobey: on linux, use the system certs, on other platforms, use the bundled cert
[18:16] <mdeslaur> dobey: they'd better be...where did the cert come from?
[18:17] <dobey> godaddy, but it's got a slightly different chain than the godaddy certs in ca-certificates, i think
[18:18] <mdeslaur> dobey: the certs in ca-certificates come from firefox....so I doubt godaddy is selling certs that don't work in firefox
[18:18] <mdeslaur> dobey: could you give it a try?
[18:19] <mdeslaur> dobey: you can still shove the cert into /etc/ssl/certs if it,s not already there
[18:20] <mdeslaur> dobey: just make it use _any_ valid cert in /etc/ssl/certs, and not that specific filename
[18:20] <seb128> pitti, nice apport upload!
[18:21] <dobey> it might work now (in precise), but i think it might not work in older versions of ubuntu (lucid). there was an issue with the chaining, with openssl iirc
[18:21] <mdeslaur> dobey: well, we don't really need to fix it in the older releases, but it would be nice to have it going forward
[18:21] <mdeslaur> dobey: you can tell it to use /etc/ssl/certs/ca-certificates.crt
[18:22] <mdeslaur> dobey: that is a dynamically-generated file containing all the system certs, including the one you stuck in /etc/ssl/certs yourself
[18:23] <dobey> right
[18:32] <dobey> mdeslaur: hrmm. ca-certificates.crt really needs a comment for each cert, telling which file it came from exactly
[18:34] <dobey> mdeslaur: and it seems the .pem files we're installing aren't getting added to it. :-/
[18:34] <mdeslaur> dobey: are you calling update-ca-certificates in your postinst?
[18:35] <mdeslaur> when you dump stuff in there, you need to tell the system about it
[18:35] <seb128> mdeslaur, isn't what triggers are for?
[18:35] <dobey> mdeslaur: running it manually just now doesn't add it either
[18:35] <dobey> Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.
[18:36] <mdeslaur> oh, it may be handled by triggers too, I'm not sure what the best practice is there
[18:36] <pitti> seb128: heh, thanks; I hope this one causes less dupes to be filed
[18:36] <pitti> seb128: and it helps a bit with catching up with you, too :)
[18:37] <seb128> pitti, hehe
[18:37]  * seb128 hugs pitti
[18:37] <dobey> seb128: well, we should still do whatever the trigger does, when we do ./setup.py install, for people that decide to install by hand, i guess; but bleh, i hate setuptools/distutils because it makes stuff like this really hard.
[18:37] <mdeslaur> dobey: wait a sec, let me refresh my memory with update-ca-certificates
[18:37] <dobey> not to mention every linux distro does this slightly differently :-/
[18:38] <mdeslaur> yes, it's insane
[18:39] <dobey> and i don't really see how packages shoving their own certs into ca-certificates.crt, and reading it instead of the .pem files directly, changes anything really. the same cert revocation concerns are still there
[18:40] <micahg> mdeslaur: dobey: please read the update-ca-certificates manpage :)
[18:41] <mdeslaur> micahg: no relevant info in the manpage...what specific part are you talking about?
[18:42] <dobey> the part where the files are in /usr/share and there's a .conf file that lists all of them i guess
[18:42] <mdeslaur> dobey: well, presumably the package won't ship it's own cert file anymore
[18:42] <dobey> but there's no conf.d directory to shove others into
[18:42] <dobey> mdeslaur: we have to
[18:42] <mdeslaur> dobey: ok, then forget it and close the bug
[18:43] <dobey> mdeslaur: ok
[18:44] <micahg> mdeslaur: files get installed in /usr/share/ca-certificates/ update-ca-certificates installs to /etc/ssl/certs
[18:45] <mdeslaur> micahg: yes, I know that part...but where do other packages besides ca-certificates put their certs?
[18:45] <micahg> in the same dir there
[18:46] <micahg> I'm not sure it's necessarily intended for other packages to ship certs, I think that's the point of having this in the first place
[18:48] <dobey> well apparently java ships some certs and has some complex special thing which gets run by update-ca-certificates as wlel
[18:48] <dobey> well
[19:12] <dobey> hrmm. is apport retracer blocked/disalbed for amd64 bugs?
[19:19] <pitti> dobey: no, it shouldn't?
[19:19]  * pitti checks
[19:19] <pitti> last run was 7 minutes ago
[19:20] <pitti> looks quite happy
[19:21] <dobey> pitti: oh, hrmm. i guess this bug is missing necessary info :-/
[19:21] <pitti> which bug?
[19:21] <dobey> https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client-gnome/+bug/953313
[19:21] <ubot2`> Launchpad bug 953313 in ubuntuone-client-gnome "Ubuntu One crashes while sharing a folder from nautilius" [High,New]
[19:21] <dobey> there's no StackTrace.txt attachment
[19:21] <dobey> zyga: ^^ why you break apport?
[19:23] <pitti> dobey: this is a ProblemType: Bug, not a crash
[19:23] <pitti> there's nothing to retrace or check
[19:23] <cyphermox> seb128: re bluez; I'm finding some pretty bad issues with file transfers, and skipping in audio; so I'd be in favor of not updating to 4.99 afterall
[19:24] <pitti> dobey: probably best to invalidate it and ask to send a proper crash report
[19:24] <zyga> dobey, huh
[19:24] <zyga> dobey, sorry
[19:24] <zyga> dobey, if you want I can re-try that
[19:24] <dobey> zyga: do you have a file in /var/crash for that?
[19:24] <zyga> dobey, let me check
[19:25] <cyphermox> after discussion with upstream that management API change isn't something that would get used with the kernel we're shipping in Precise, so it kind of defeats the purpose of updating bluez anyway. since things are pretty stable and working right now, seems to me like we're okay.
[19:25] <zyga> dobey, note: apport has been crashing for me all week
[19:25] <dobey> apport-bug apport :)
[19:25] <cyphermox> pitti: has jmleddy spoken to you about gvfs ? :/
[19:25] <zyga> dobey, maybe: _usr_bin_nautilus.1000.crash
[19:25] <pitti> cyphermox: yes; it's on my list of things to look into
[19:25] <cyphermox> pitti: ok
[19:25] <dobey> zyga: can you do "apport-collect 953313" please?
[19:25] <pitti> cyphermox: i. e. we need to debug what's actually causing the problem
[19:26] <zyga> sure
[19:26] <dobey> i /think/ that should add everything to the existing bug
[19:26] <pitti> zyga: how did apport crash?
[19:26] <zyga> pitti, reporting crashes of itself, I did not investigate
[19:26] <pitti> dobey: not core dumps, though; apport-collect doesn't attach anything that isn't already there, as the bug was reported through apport already
[19:26] <pitti> zyga: do you have a /var/crash/*apport*?
[19:26] <dobey> ah ok
[19:27] <cyphermox> pitti: yes, I've been looking into it but it looks like issues with the async calls between obex and gvfs, really not trivial to debug. not quite sure how the patch he changes actually changes that behavior, but I'm way out of my understanding of this stuff
[19:27] <pitti> zyga: I uploaded a new apport with a ton of fixes today, perhaps that helps
[19:27] <zyga> pitti, yes, three
[19:27] <zyga> pitti, but uploaded
[19:27] <zyga> pitti, thanks I'll ensure to send any reports if it crashes again
[19:27] <pitti> zyga: ah, do you remember the bug numbers?
[19:27] <dobey> zyga: then just "ubuntu-bug /var/crash/_usr_bin_nautilus.1000.crash" please
[19:27] <zyga> /usr/share/apport/apport-gtk:264: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
[19:27] <zyga>   if widget.get_label() == _('Relaunch'):
[19:27] <zyga> pitti, that's all it keeps saying now
[19:27] <pitti> zyga: that's fixed
[19:27] <dobey> zyga: i filed a bug about that error the other day
[19:28] <zyga> dobey, in progress (the first is done now)
[19:28] <pitti> zyga: as a workarund, report them through apport-cli or apport-kde
[19:28] <pitti> zyga: . o O { *phew* } :)
[19:28] <pitti>     apport | 1.95-0ubuntu1 |       precise | source, all
[19:28] <pitti> or just dist-upgrade
[19:39]  * pitti fixes valac package upgrade failure
[19:43] <pitti> didrocks: OOI, did you see bug 916892 yourself?
[19:43] <ubot2`> Launchpad bug 916892 in unity-distro-priority "gnome-disk-utility crashed with SIGSEGV in gdu_device_get_object_path()" [Undecided,Fix committed] https://launchpad.net/bugs/916892
[19:43] <dobey> zyga: did you get the new bug filed yet?
[19:44] <pitti> and why is that unity-distro-prio task "fix committed"?
[19:45] <zyga> dobey, yup, sorry, got stuck
[19:45] <pitti> didrocks: I can't actually reproduce it, so I guess I can just try and fix it blindly
[19:45] <dobey> zyga: what's the bug #?
[19:45] <seb128> cyphermox, your call
[19:46] <seb128> cyphermox, are those .98->99 regressions?
[19:46] <cyphermox> seb128: yeah
[19:46] <cyphermox> seb128: rather not embark in that, honestly.
[19:46] <zyga> dobey, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/962470
[19:46] <ubot2`> zyga: Error: <Bugtracker.plugin.Launchpad instance at 0xa5ae8cc> bug 962470 not found
[19:46] <zyga> haha
[19:46] <zyga> nice
[19:46] <zyga> this bug is private now
[19:47] <dobey> oh
[19:47] <dobey> yeah because it's a crash
[19:47] <dobey> but why can't i see it
[19:47] <seb128> dobey, because it's not retraced yet
[19:47] <cyphermox> seb128: I don't think it's related to mgmt api, but I could see after the fact that there were changes in bluez to deal with permission errors in file transfers, but we also have a fix in the kernel for that, I think at this point they may be conflicting
[19:47] <seb128> dobey, only retracer have initial access
[19:47] <dobey> ah right
[19:48] <seb128> cyphermox, ok, fair enough, as said I was mostly trying to set us in a position where it would be easier to get stable updates later on
[19:48] <cyphermox> seb128: ok
[19:48] <seb128> cyphermox, but if those are tight to kernel updates there is no point
[19:48] <seb128> cyphermox, it's not like we can't backport bug fixes in any case ;-)
[19:49] <cyphermox> seb128: I do think we're ok; we can pretty easily cherry-pick patches in general they are well made as atomic and all
[19:49] <cyphermox> right
[19:49] <seb128> cyphermox, thanks for looking to it in any case!
[19:49] <cyphermox> I'll update the pad; already let ScottK to nak the bug
[19:49] <seb128> cyphermox, thanks
[19:49] <seb128> cyphermox, don't get too happy too soon, I assigned you an eds bug this week as well ;-)
[19:49] <cyphermox> np :)
[19:50] <seb128> cyphermox, one with a patch upstream so should be easy
[19:50] <seb128> (don't take my word on it though ;-)
[19:50] <cyphermox> eds and evo I've been wanting to review since last week but kept being dragged back to NM or bluez :)
[19:50]  * cyphermox drops a tear for shattered hopes or a newer, bug-free bluez :)
[19:51] <seb128> cyphermox, next one will be better! ;-)
[19:52] <cyphermox> seb128: they all say that
[19:55] <didrocks> pitti: I didn't see the crash, I know there is a bug where the device connected to launcher are not shown
[19:55] <didrocks> pitti: was thinking it can be the same bug
[19:59] <unit3> Hey all, I'm trying to get my desktop working using nouveau drivers, my video card is supported and it works from the 11.10 live cd... but in my install environment, running "compiz --replace" in a terminal results in the error: GLX_EXT_texture_from_pixmap is missing
[19:59] <unit3> However, glxinfo shows that the texture_from_pixmap extension is present.
[19:59] <unit3> so I'm not sure what Unity's problem is?
[19:59] <unit3> ugg. no focus follows mouse in this failsafe mode, obviously.
[20:00] <unit3> so yeah, any ideas how to get it to shape up and run, since the glx extension is there?
[20:00] <unit3> I tried "unity --reset", no luck.
[20:01] <dobey> pitti: ugh. apport failed for the new bug :-/
[20:01] <dobey> pitti: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/962470
[20:01] <ubot2`> dobey: Error: <Bugtracker.plugin.Launchpad instance at 0xa5ae8cc> bug 962470 not found
[20:01] <dobey> ubot2`: be quiet
[20:01] <ubot2`> Factoid 'be quiet' not found
[20:03] <seb128> dobey, nautilus version 1:3.3.91-0ubuntu4 required, but 1:3.3.92-0ubuntu2 is available
[20:03] <pitti> dobey: yeah, lots of updates today :/
[20:04] <pitti> I'm afraid that needs a fresh crash
[20:04] <seb128> dobey, the retracers don't work on outdated version, they only have the current version dbgsym
[20:04] <seb128> it's not today, that was updated on tuesday
[20:04] <seb128> pitti, is there any way we could block submiting based on lp versions rather than mirror versions?
[20:05] <seb128> some mirrors seems to be outdated by days
[20:05] <pitti> seb128: in theory yes of course, but not trivially
[20:05] <pitti> seb128: we could at least use rmadison, should be a bit cheaper
[20:05] <pitti> but still much harder than just querying python-apt
[20:05] <dobey> or try to retrace with the newer versions of the packages
[20:06] <seb128> dobey, that's what happened there :p
[20:06] <seb128> dobey, the dump is for .91 and it retraced with .92 and of course signatures didn't match so gdb bailed out
[20:07] <dobey> well it broke before retracing. it failed to install the packages no?
[20:07] <seb128> dobey, no
[20:07] <seb128> dobey, the retracer doesn't "install" the packages
[20:07] <seb128> dobey, it unpack the binaries
[20:08] <seb128> dobey, installation is too error prone
[20:09] <seb128> dobey, the log just warns that the unpacked version is .92 but the dump is from .91, so it's likely not going to get any working gdb output
[20:11] <dobey> hmm
[20:11] <dobey> oh well
[20:11] <dobey> and i guess apport won't write a new file in /var/crash as there's already one that's been uploaded?
[20:14] <pitti> it does
[20:14] <pitti> it only doesn't overwrite files which haven't been shown yet
[20:22] <pitti> didrocks: hm, my USB sticks always get shwon
[20:22] <pitti> didrocks: and mounted ISOs and SSH mounts don't; but they also don't cause unity to crash
[20:23] <pitti> didrocks: anyway, thanks; I'll do some stack trace vs. source code analysis
[20:23] <didrocks> pitti: well, it's in a separate process (the panel service one), so unity won't crash
[20:23] <didrocks> pitti: but it just doesn't shsow up
[20:23] <didrocks> pitti: not a big bug for the release, was thinking it was related, but no then
[20:23] <pitti> didrocks: oh, panel? I thought you meant the usb icons in the launcher
[20:23] <didrocks> pitti: long story, it's mounted in the panel service in fact :)
[20:24] <pitti> unity::launcher::DeviceLauncherSection::OnVolumeAdded(_GVolumeMonitor*, _GVolume*,
[20:24] <didrocks> but shown on the launcher
[20:24] <pitti> that's part of the stack trace
[20:24] <jbicha> pitti: what are you doing still here?
[20:24] <pitti> so I thought it was unity that crashed
[20:24] <pitti> jbicha: fixing bugs until the bitter end :)
[20:24] <didrocks> pitti: hum, maybe on that one, I need to look at the code, it maybe changed since last time I touched
[20:24] <didrocks> pitti: but the current state is just "nothing is shown"
[20:24] <didrocks> no crash
[20:24]  * pitti looks at gtimelog.. "Total work done: 12 h 37 min"; that's not too bad for a freeze day :)
[20:25] <pitti> didrocks: hm, WFM
[20:25] <didrocks> pitti: that's because you don't have 5.8 ;)
[20:26] <pitti> didrocks: heh, right
[20:26] <didrocks> ok, so not platform related 5.8 regression
[20:26] <pitti> didrocks: but neitehr does that guy who reported that crash
[20:27] <didrocks> right, it's a separate issue then
[20:27] <didrocks> having the 3 machines on latest staging ppa to test the crash on startup makes me hard to confirm if we have a regression or not :/
[20:29] <seb128> I hate makefiles
[20:29] <seb128> 	TYPE="text"
[20:29] <seb128> 	echo $(TYPE)
[20:29] <seb128> should the echo print "text" for that?
[20:30] <seb128> or am I doing something stupid?
[20:30] <pitti> nope
[20:30] <pitti> seb128: it's two different shells
[20:30] <pitti> each line is a new shell command
[20:30] <pitti> seb128: try:
[20:31] <pitti> TYPE="text"; echo $$TYPE
[20:31] <seb128> I hate makefiles :p
[20:31] <pitti> seb128: or define TYPE not in a rule, but at the top of the file
[20:31] <pitti> $(TYPE) -> make variable
[20:31] <pitti> $$TYPE -> shell variable
[20:31] <pitti> you can't define make variables in rules
[20:31] <seb128> pitti, that's not a rules, it's an upstream Makefile
[20:32] <pitti> I mean in makefile rules, not "debian/rules"
[20:32] <pitti> i. e. in the actions that build a target
[20:32] <seb128> TYPE="text"
[20:32] <seb128> echo $TYPE
[20:32] <seb128>  
[20:32] <seb128> that's what is printed with $$TYPE
[20:32] <seb128> oh, on the same line
[20:32] <pitti> seb128: is that in a rule or are these declarations?
[20:32] <pitti> echo $TYPE is not a valid make declaration
[20:33] <pitti> MAKEVAR=value
[20:33] <pitti>  
[20:33] <pitti> mybin: mysource.c
[20:33] <seb128> ok
[20:33] <pitti>       # this is a rule
[20:33] <pitti>      echo $(MAKEVAR)
[20:33] <seb128> so let's take a concrete example
[20:33] <pitti>      SHELLVAR=foo; echo $$SHELLVAR
[20:33] <pitti>  
[20:33] <seb128> I was trying to do that (which doesn't work)
[20:33] <seb128> totem.desktop.in: totem.desktop.in.in mime-type-list.txt desktop.sh
[20:33] <seb128> 	$(AM_V_GEN) cat totem.desktop.in.in | sed 's,@FULL_LIBEXECDIR@,$(FULL_LIBEXECDIR),' > $@ &&\
[20:33] <seb128> 	$(AM_V_GEN) cat totem.desktop.in.in | sed 's,@MIMETYPE@,$($(SHELL) $(srcdir)/desktop.sh $(srcdir)/mime-type-list.txt $(srcdir)/uri-schemes-list.txt),' > $@
[20:33] <pitti> perhaps that makes it clelarer
[20:34] <seb128> the second like doesn't work
[20:34] <didrocks> it's easy once you got that the declaration are only on top :)
[20:34] <seb128> now I'm trying to debug why it doesn't work :p
[20:34] <seb128> the MIMETYPE line doesn't work
[20:34] <seb128> chrisccoulson, it's all your fault btw, that's the stupid totem mimetype bug :p
[20:35] <chrisccoulson> heh, thanks :)
[20:35] <seb128> the makefile was
[20:35] <seb128> totem.desktop.in: totem.desktop.in.in mime-type-list.txt uri-schemes-list.txt desktop.sh
[20:35] <seb128> 	$(AM_V_GEN) cat totem.desktop.in.in | sed 's,@FULL_LIBEXECDIR@,$(FULL_LIBEXECDIR),' > $@ &&\
[20:35] <seb128> 	$(SHELL) $(srcdir)/desktop.sh $(srcdir)/mime-type-list.txt $(srcdir)/uri-schemes-list.txt >> $@
[20:35] <seb128>  
[20:35] <seb128> but with the unity list the 3rd line doesn't work
[20:35] <pitti> wht is AM_V_GEN?
[20:35] <seb128> we don't want to append the text
[20:36] <seb128> pitti, it's a makefile stuff that make it hide output if you don't set V=1
[20:36] <seb128> i.e ignore it
[20:36] <pitti> seb128: try $(SHELL command), not $(SHELL) command
[20:36] <pitti> $(SHELL command) expands to the output of "command"
[20:36] <pitti> it's a make function
[20:37] <pitti> which I think is what you might want there
[20:37] <pitti> $($(SHELL) stuff) -> that might magically work, but I'm afraid I can't parse that
[20:38] <seb128> pitti, I just want to put the output of "$(srcdir)/desktop.sh $(srcdir)/mime-type-list.txt $(srcdir)/uri-schemes-list.txt" there
[20:38] <seb128> the original makefile.am is doing
[20:38] <seb128> $(SHELL) $(srcdir)/desktop.sh $(srcdir)/mime-type-list.txt $(srcdir)/uri-schemes-list.txt >> $@
[20:38] <seb128> I basically want to take what is before the >>
[20:38] <seb128> and put it in a sed
[20:38] <seb128> so I put it under $()
[20:39] <seb128> that's basically "evaluate "sh desktop.sh ..."
[20:39] <pitti> I thought $(stuff) would expand the make variable "stuff"
[20:40] <pitti> $(SHELL) might expand to "/bin/sh"
[20:40] <seb128> yeah, I don't practice makefile regularly
[20:40] <pitti> seb128: so yes, try
[20:40] <seb128> I didn't do stuff like that since my Debian NM when jorge made me rewrite a rules in pure makefile :p
[20:40] <seb128> which is like ... 10 years (doh, not getting any younger)
[20:41] <pitti> ... sed 's,...,$(SHELL $(srcdir)/desktop.sh $(srcdir)/mime-type-list.txt $(srcdir)/uri-schemes-list.txt)'
[20:41] <pitti> or just avoid the $(SHELL) stuff altogether, you are already writing shell stuff after all
[20:41] <pitti> seb128: oh, wait
[20:41] <pitti> seb128: you are trying to to the shell $(), not the make $()
[20:42] <pitti> seb128: now I know why I couldn't parse that :)
[20:42] <pitti> seb128: simple fix should be to replace $( with $$(
[20:42] <pitti> that'll use teh shell's $() , i. e. same as ``
[20:42] <pitti> make is fun
[20:43] <seb128> oh
[20:43] <seb128> I see what you mean
[20:43] <seb128> let me try
[20:46] <seb128> hum
[20:46] <seb128> so
[20:46] <seb128> 	echo `$(SHELL) desktop.sh mime-type-list.txt uri-schemes-list.txt`
[20:46] <seb128> works
[20:48] <pitti> yes, using `` shoudl be a little clearer than the $$($(SHELL) dance
[20:48] <pitti> it looks dangerously close to a sendmail config at that point :)
[20:48] <seb128> that still doesn't work in the sed line though
[20:49] <pitti> anyway, I think time to sleep for me; I can't really think coherently any more
[20:49] <pitti> and in teh remaining 11 minutes I won't be able to do an upload any more
[20:49] <seb128> pitti, I think I got it
[20:49] <seb128> pitti, thanks for thelp!
[20:49] <pitti> seb128: \o/
[20:49] <seb128> the help
[20:50] <seb128> I will sneak that in and call it a day as well :p
[20:50] <pitti> seb128: if all else fails, write a shell script which does everything and just call that in the rule
[20:50] <pitti> that's what I did wit pkgbinarymangler in the end, when the cdbs make rules becaome totally incomprehensible
[20:50] <pitti> good night everyone, sleep well!
[20:51] <pitti> nice fix-it day today, looking forward to tomorrow's images
[20:51] <seb128> 'night pitti
[20:51]  * pitti hugs seb128
[20:51]  * seb128 hugs pitti back
[20:51] <didrocks> good night pitti!
[20:51]  * pitti hugs didrocks as well, hope you don't have to burn the midnight oil so long
[20:51] <didrocks> pitti: well, we'll see :-) almost here, but anyway, won't upload before tomorrow
[20:52] <pitti> didrocks: that's fine; skaet knows as well, and I'll do the pocket copying
[20:52] <didrocks> so, we'll need to discuss tomorrow :)
[20:52] <pitti> didrocks: so, upload to -proposed it is
[20:52] <didrocks> good news \o/
[20:52]  * didrocks hugs pitti
[20:52] <pitti> and you can say you paved the ground for a proper staging area :)
[20:52] <didrocks> heh, yeah \o/
[21:54] <seb24> salut didrocks :D ça bosse ?
[21:54] <didrocks> seb24: un peu trop :-)
[21:54] <seb24> je me doute :)
[23:12] <chrisccoulson> hmmm, so the only downside of pdf.js is that it has a popout sidebar on the left hand edge of the firefox window
[23:12] <chrisccoulson> right where the unity launcher is
[23:13] <didrocks> chrisccoulson: still awake?
[23:14] <chrisccoulson> didrocks, no, i'm fast asleep now :)
[23:14] <didrocks> ;)
[23:15] <chrisccoulson> this is probably better than reading pdf's in evince :)
[23:16] <RAOF> chrisccoulson: What's performance like?
[23:16] <chrisccoulson> RAOF, it seems to be pretty good here
[23:17] <RAOF> Have you tried it on something hard, like the Pathfinder book? :)
[23:17] <chrisccoulson> not yet ;)
[23:22] <chrisccoulson> hmmm, they need to fix scrollwheel zooming :)
[23:23] <chrisccoulson> because the pdf viewer is just all normal webcontent, ctrl+scrollwheel zooms the whole thing, including the pdf viewer chrome
[23:23] <chrisccoulson> which is clearly not meant to happen
[23:34]  * didrocks waves good night
[23:35] <TheMuso> chrisccoulson: What program is this?
[23:36]  * TheMuso exited from his IRC session earlier and just missed catching the start of the convo in backscroll.
[23:37] <didrocks> or not yet ;)
[23:41] <desrt> didrocks: cheerio
[23:42] <didrocks> hey desrt ;)
[23:46] <desrt> didrocks: i thought you were on your way out :)
[23:46] <didrocks> I thought it to :)
[23:47] <didrocks> I was pretty sure it was the case when I typed /quit and was going to press enter
[23:47] <desrt> only to discover....
[23:47] <didrocks> until I saw this little notification bubble :)
[23:47] <desrt> so it's mirco's fault, you're saying
[23:47] <didrocks> desrt: totally agree ;)