[00:32] yay for -1 day SRUs. :p [04:24] desrt: apport time delta> yes, we have that information at hand; I just wonder in what way this should be presented in the report; perhaps adding a new field if the delta between "crash happened" and "crash reported" is > 15 mins? or make better efforts to tell if it happened in the same session? [04:24] desrt: I don't think merely showing the exact time delta is very useful, as it's hard to search/filter for === Amaranthus is now known as Amaranth [04:55] Wooo! Look at the 12.10 errors.ubuntu.com graph for colord. BOOYAH! [05:06] RAOF vs. D-Bus 1:1 ? [05:07] RAOF: wow, nice dip! [05:07] guten morgen pitti [05:07] pitti: I think I may have fixed ALL OF THE BUGS! [05:07] still twice as many as 12.04, but that might be due to people still needing to upgrade? [05:08] Are the scales for 12.04 & 12.10 the same? [05:08] RAOF: indeed, I stopped getting annoying apport bubbles for this a while ago \o/ [05:08] before that it seemed to be the way of quantal to say "good morning" [05:08] hey didrocks, wie gehts? [05:08] Because I *know* that 12.04 is still terribly crashy and will remain so until colord moves into -proposed [05:08] pitti: I'm ok, yourself? [05:09] quite fine [05:10] RAOF: hm, I'd expect that, otherwise the graph would be really confusing [05:10] RAOF: after all, the point of it is to allow comparisons? [05:13] I have no idea what the values on the axes mean :) [05:14] For example, on the 10th of October there were 0.11 $THINGS in 12.10. [05:14] I think it's "crashes per user in the selected time frame" (1 day, 1 month, etc.) [05:14] although, it's probably not that [05:14] Heh [05:14] we don't know the #users [05:15] This is making a fairly persuasive point for “does anyone know what the vertical axis means exactly” :) [05:15] Presumably ev does. [05:15] so obviously it's "Kilojiffies by Milliblurbs" [05:16] The many ways of autostarting things in DMs are confusing :-/ .... indicator-cpufreq does it via /etc/xdg/autostart/, indicator-weather does it via X-GNOME-autostart-enabled=true in /usr/share/applications/ .... is one more correct ? Is there anywhere I can read about this stuff? [05:16] maxb: Does X-GNOME-autostart-enabled=true actually do anything? [05:17] erm, good question [05:17] I assumed it did since I found it in an official quantal package, but... [05:18] * maxb logs out/in [05:18] maxb: /etc/xdg/autostart or ~/.config/autostart should be the set of (non-default) things that get started. (Technically, that's $XDG_CONFIG_DIRS/autostart and $XDG_CONFIG_HOME/autostart) [05:19] Er, right, that'll teach me to trust stuff in the archive ;-) [05:24] Greetings all. === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [07:32] pitti: i was also thinking it could be useful if there was some global state flag set when logging out [07:32] or if we could find out if the machine rebooted since [07:32] or if something like the xdg session cookie or dbus bus address was different in the crashing session and the one that 'notices' the crash [07:35] these sort of things are more reliable than time passed (since that could happen for other reasons) [07:35] but still not as great as a flag set at logout time [07:35] because there could also be other reasons that a crash isn't noticed until logout/login even if the crash is not caused by the logout [07:36] desrt, good morning :) [07:37] * larsu is not used to seeing desrt around at this time [07:46] hey desktopers [07:47] salut seb128 [07:47] lut didrocks, ca va bien ? [07:48] seb128: on fait rouler :) [07:48] et toi? [07:49] tout va bien icic ;-) [07:49] desrt: re (sorry, was in a meeting) [07:49] bonjour seb128 [07:49] pitti, salut, ca va ? [07:49] desrt: apport actually already makes some effort to determine whether the crash happens during session shutdown [07:50] desrt: and it's supposed to add a particular tag when you report a crash in a different session than the one it happened in, but that might be broken in some cases [07:50] larsu: hi :) [07:50] hey larsu, wie gehts? [07:50] seb128: bien, merci! [07:50] pitti: ah. that's good news to know. how do i look for that? [07:50] pitti, guten morgen! Gut, und selbst? [07:51] this channels speaks odd languages at this hour [07:51] desrt, you're starting to sound like tedg ;) [07:52] desrt: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2058 is supposed to catch the crashes during shutdown, but apparenlty it's not sufficient [07:53] pitti: why would you think that this works? [07:53] DBUS_SESSION_BUS_ADDRESS doesn't magically disappear from the environment of a process when the bus goes away... [07:54] desrt: right, but gnome-session sohuld either be gone, or its state should be "shutting down" [07:54] oh [07:54] you just use the environment variable to contact gnome-session [07:55] right [07:55] desrt: hm, I recently added in_session_of_problem() which would tell you whether or not you report a crash that happened in the currently running session [07:55] desrt: but I just see that we don't seem to transform that into a tag [07:55] odd, I certainly discussed that with ev, but apparently it slipped through the cracks [07:56] pitti: glad to hear we're well on our way to a solution :) [07:56] desrt: you can kind of infer it from the presence or absence of an ~/.xsession-errors attachment [07:56] desrt: as we only attach it when the crash happened in the current session (otherwise xsession-errors is pointless) [07:56] ah. neat trick. [07:56] but I guess a tag would be better [07:56] i'll check that for now [07:57] i. e. XsessionErrors [07:57] desrt: but it'd probably be best if you file a bug with the thing you are actually looking for (that wouldn't be a time delta for sure, but some more fundamental property), and then I'll see how to incorporate this? [07:57] pitti, the issue is that XsessionErrors is only there when there are errors matching your regexp to catch [07:58] so it could be a new session or it could be that this issue didn't let any info in the log === bryceh is now known as bryce [07:59] that's right; but in practice we always seem to have some warnings [07:59] don't get me wrong, I don't think this is an ideal state, just saying where we currently use it [07:59] I'd love to make it more explicit [08:00] pitti, that's a nice trick, thanks for the hint ;-) [08:00] pitti: okay [08:00] https://bugs.launchpad.net/apport/+bug/1067646 [08:00] Launchpad bug 1067646 in apport "should report if crash happened at logout/shutdown" [Undecided,New] [08:01] desrt: thanks; following up there [08:07] seb128: ah, thanks for the other use cases of hw dependend service activation [08:08] seb128: I still don't think that this is the main solution for our performance problems, but it's interesting nevertheless [08:08] pitti, yw ;-) That's the thing I want upstart jobs the most for [08:08] hallo [08:09] pitti, well, it's not only performances, it's flexibility ... autostarts are pretty limited (only one condition) and happen only on session start [08:09] we have no way atm to bring up a service when a key is set [08:09] or bring it down when a key is unset [08:09] key = gsettings key [08:09] same for hardware events [08:09] Laney, hey, how are you? [08:09] *nod*; but would upstart be able to listen for gsettings changes? [08:10] seb128: that rather seems to be a job for g-s-d to me? [08:10] yes [08:10] that's one of the things we asked for at last uds [08:10] a gsettings bridge (or whatever they call the events generators) [08:10] just like g-s-d starts/stops the trackpad polling process depending on the gsettings key [08:10] bonjour seb128, didrocks quel est la mots de la rue apropos le release? [08:10] (sorry for changing the topic ;) ) [08:10] just humor me [08:10] seb128: this would be a lot more upstream friendly [08:11] bonjour rickspencer3 [08:11] rickspencer3: quantal? c'est déjà dépassé, on bosse sur les SRU :) [08:11] rickspencer3, salut, on dirait qu'il y a toujours quelque problème de secure boot sur certaines images [08:11] rickspencer3, sinon c'est ok [08:11] * rickspencer3 just sees "ok" and tunes out [08:11] ah, must be le french invasionne hourre ;-) [08:11] j/k [08:11] pitti, well, I don't want g-s-d to become more of a kitchen sink, it's not g-s-d's job to take down the gwibber lens when there is not internet connection [08:12] bryce: "hourre"? "season" rather :p [08:12] til "on bosse sur" [08:12] didrocks, hehe [08:12] or seaaaazone :p [08:12] hi [08:12] seb128: right, but for wacom it might be [08:12] getting this error: [08:12] dpkg-source: error: cannot represent change to mesa-9.0/bin/install-sh: [08:12] dpkg-source: error: new version is symlink to minstall [08:12] dpkg-source: error: old version is nonexistent [08:12] no idea what it means :( [08:12] pitti, yes, my examples suck, I didn't stop to think about proper ones [08:12] bryce: you shouldn't have showed up I guess ^ :p [08:12] hey seb128, pitti, didrocks! [08:12] hey rodrigo_ ;) [08:13] hey rodrigo_ [08:13] rodrigo_, hey [08:13] rodrigo_, what version of dpkg do you use? maybe try asking on #ubuntu-devel, the dpkg people are not on #desktop [08:14] 1.16.8 (amd64) [08:14] seb128, ok, I'll ask there [08:14] urg [08:14] I'm getting loads of weird crashes [08:14] hope it's not faulty ram [08:14] didrocks, nah, I shoved mesa9 into x-updates, I deserve all the complaints [08:14] bryce, oh, you already packaged it? [08:14] bryce: heh ;) [08:14] bryce, was trying to [08:14] * Laney is going to run a quick memtest [08:15] rodrigo_, no; tjaalton packaged mesa9 for quantal, I just copied it into x-updates ppa. Is that where you're installing from? [08:15] bryce, no, I was trying to package it for the PPA you created for us [08:16] so, looking for the tjaalton's package, will just copy that one [08:16] rodrigo_, yeah that'd be best [08:16] yes [08:17] rodrigo_, btw I didn't merge your PPA into x-updates yet, but would like to do so when you feel it to be ready [08:18] bryce, yes, still waiting for more feedback, so not ready yet, will let you know as soon as it is [08:18] it works for me perfectly, but that's not enough testing :) [08:18] :-) [08:18] with the mesa 9 update we should get more testing [08:18] yeah agreed === doko_ is now known as doko [08:46] I guess that is a known issue, but compiz/xorg are using all my cpu after some time and make the system sluggish - thisis a intel video card [08:48] good morning everyone [08:50] mvo, hey, not know afaik ... [08:51] mvo, did you see the GTK guys fixed your leak in git ;-) [08:51] chrisccoulson, hey, how are you? [08:51] seb128, yeah, good thanks. how are you? [08:51] chrisccoulson, I'm good thanks [08:52] chrisccoulson, shame that you didn't upload that tb messaging menu fix on monday, with the late respins it would have made it to the iso :-( [08:52] chrisccoulson, they moved things from proposed to the iso still yesterday [08:52] seb128, oh, i didn't realize that there were late respins :/ [08:52] never mind :( [08:52] mvo, usually high xorg cpu is due to clients driving the X server beyond the norm. So try to identify which client app might be driving it. [08:52] chrisccoulson, can we get the SRU rolling anyway? [08:53] seb128, yeah, i'll upload it now [08:53] chrisccoulson, thanks [08:56] seb128: very nice [08:56] seb128: looks like its not one leak but multiple from looking at the git diff - but great to know that its fixed now [08:57] mvo, well, the specific one you pointed seems to be one commit to destroy a cairo surface [08:57] but cosimoc fixed other issues while he was at it [08:58] bryce: thanks, this is my usual workload, i.e. xchat, firefox, mutt, emacs - but it now stopped (or is smaller, more like 10% cpu when typing here) [08:58] bryce: is there anything I could do to debug when this happen next time? look at something like top to see what else is using high cpu? [08:58] (crude, I know :/ [08:59] and here it is again [09:03] hmm, there is xrestop but it mostly reports memory usage [09:04] mvo, fwiw those four programs are also my four main programs. (well, emacs -nox) [09:04] firefox plugins can sometimes drive X. [09:04] compiz plugins are another likely source, esp. if you have something non-default enabled [09:05] bryce: its a pretty stock install, let me try xrestop [09:05] mvo, if you kill a client app and the X.org CPU usage decreases, that's a good sign [09:06] bryce: well… [09:06] bryce: that caused a nice x crash [09:06] awesome [09:06] [200466.552] Caught signal 11 (Segmentation fault). Server aborting [09:06] bryce: was this a trick ;) ? [09:06] mvo, anything captured in /var/crash/ ? [09:07] oh there's a bug about xrestop crashing [09:07] tjaalton, oh? just crashing itself or crashing xserver? [09:07] xserver [09:07] doh [09:07] tjaalton, bug #? sounds bad [09:08] bug 1060059 [09:08] Launchpad bug 1060059 in xorg-server "Xorg crashed with SIGABRT in ResFindAllRes()" [Medium,New] https://launchpad.net/bugs/1060059 [09:09] I reported it now using apport but it would not open a bugreport [09:09] (after asking me a bunch of question like if I am willing to help debug) [09:09] tjaalton, shrug, shouldn't "obvious xorg crasher" bugs be better triaged that non confirmed, medium, non assigned, non milestoned? [09:09] tjaalton, sheesh. wtf xserver... [09:10] seb128: just remembered that it was reported [09:10] tjaalton, who do I assign it to? ;-) [09:10] it's milestoned for quantal-updates now fwiw :p [09:10] I've been assigned to other tasks for the next few weeks.. [09:11] seb128, chill. we have a lot of X crashes, but me and all the other X guys are tied up on various projects [09:11] seb128, assign to canonical-x or escalate with jason for critical issues [09:12] * mvo runs xrestop again just to see if its reproducable [09:13] bryce, sorry, it's always annoying when we gets bugs that lead users to have their session to go down and close,loose any open work [09:13] bryce, but understood, I know everyone is busy and stretched out :-( [09:13] mvo, there is also https://wiki.ubuntu.com/X/Troubleshooting/HighCPU however it doesn't say much more than I've already mentioned. [09:14] bryce, I've set it to triaged/high for now [09:14] seb128, actually I set it triaged/high, but thanks :-) [09:14] bryce, https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1065113/+activity :p [09:14] Launchpad bug 1065113 in xorg-server "Xorg crashed with SIGABRT in free()" [High,New] [09:14] bryce, yw ;-) [09:15] shrugh, wrong bug [09:15] anyway moving on ;-) [09:15] * seb128 is trying to clean up the "quantal milestoned bugs" list [09:15] pretty reliable [09:16] seb128, but yes for the future either assign to me or to canonical-x, and I'll ensure they get assigned out to the right folks [09:16] bryce, thanks [09:16] seb128, sadly I guess *most* X.org bugs are of the "session goes down; lose your work" variety [09:16] maybe we should stop recommending using it for now [09:17] mvo, yeah now that I know, for sure. Actually getting the crash fixed should be a top priority now. [09:17] bryce, yeah, I figured so... [09:17] lol - xvfb-run xrestop is fine [09:18] bryce: well would help if we could start testing the quantal stack too but I kind of want the multiarch bug fixed first before I announce it for wider testing [09:18] seb128, bryce: I should have a few spare cycles today, so I'll at least make sure it's sent upstream [09:19] this particular bug looks like it should be catchable with valgrind [09:19] might even get a 0-day update for it, we'll see [09:19] mlankhorst: don't mind you looking at it ;) [09:19] maybe it was during the weekend when I saw duflu's bug about it go by [09:20] so didn't react or test [09:20] tjaalton, thanks [09:20] "Xorg crashed with SIGABRT in free()" [09:20] mvo, typically the next step I suggest after identify possible client causes is to set up xtrace between server and (suspected) client, and see if what X calls it's making. Most (but not all) high X.org CPU issues are due to an out of control client making excess X calls. [09:20] that's not really something we'd instantly notice though :x [09:21] desrt: hey, I think we'll need your help :p [09:21] tjaalton, thanks [09:21] mvo: it's also possible that the gpu is (partially) hung [09:22] check dmesg [09:22] * mlankhorst updating quantal [09:22] i've seen that on precise a couple of times [09:23] mlankhorst: that is blocking on me right ? that multiarch bug? sorry for that [09:24] np :) [09:24] tjaalton: nothing suspicious in dmesg afaict [09:25] mvo: and the system is not swapping? [09:26] tjaalton: I doubt it, haven't checked, but it has 8gb of ram (can't check now as the session crashed so all memory hungry stuff is gone) [09:26] ah, ok :) [09:26] tjaalton: but I will remember to check next time :) [09:26] could be firefox eating all my ram of course [09:27] in theory there could be a huge pixmap leak or such causing it to swap [09:27] * mvo nods [09:27] good to know [09:27] and here I was hoping we didn't have such problems :p [09:27] but those tend to stay, not vanish by itself [09:27] oh well, lunch -> [09:33] seb128, gvfsd-http still leaking pretty bad, i think we can rule out that it was just outdated pkg on my system [09:34] seb128, can you rep? just open the dash and do random searches in shopping/music [09:34] mhr3, you know how to valgrind and track leaks right, patches are welcome ;-) [09:35] seb128, i just can't take the joy from you :) [09:37] mhr3, but yeah, confirmed [09:39] seb128: what screen reader does ubuntu use? [09:42] mlankhorst, orca [09:42] mlankhorst, https://launchpad.net/ubuntu/+source/gnome-orca [09:42] ah k === MacSlow is now known as MacSlow| === MacSlow| is now known as MacSlow|lunch [11:35] pitti: would you mind bumping https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3910394 please? :) [11:36] pitti: it contains a worrying upgrade issue fix for SRU0 and I want it to have wider testing [11:36] (for compiz) [11:38] didrocks, you're stealing my PPA builders? ;) [11:39] chrisccoulson: do you have an urgent upgrade issue? :p [11:39] heh, not today ;) [11:39] chrisccoulson, just upload that tb fix to proposed :p [11:40] seb128, i uploaded it this morning ;) [11:40] chrisccoulson: see, I can steal them gladely then! :) [11:40] it's not been approved yet though [11:40] chrisccoulson, \o/ [11:57] didrocks: done [11:57] * didrocks hugs pitti [11:58] didrocks: je suis désole, j'étais au déjeuner [11:58] pitti: tu as de la chance, j'ai pas pu encore en avoir! à cause de ce *ù$*$ù**mmfs de bug :-) [11:59] * pitti hugs didrocks [12:06] hello everyone...im new to ubuntu...just having ditched windows in the last week and put ubuntu on every computer in the house, and while everything is going fine...is there a FULL list of keyboard commands? [12:06] hold the key between control and alt? [12:07] yes i know of that...but thats all the commands? [12:08] all and all im really impressed with ubuntu...and the rest of the family are finding it easy to use also [12:15] :-) === MacSlow|lunch is now known as MacSlow [13:03] morning :) [13:13] cyphermox, hey, how are you? === m_conley_away is now known as m_conley [13:30] seb128: not bad, you? [13:34] cyphermox, I'm good thanks [13:50] maaaaan, trying to get the background of a tooltip to render on to the surface of another window is a PITA === Ursinha is now known as Ursinha-afk [14:00] desrt: ok, so currently the decision is - no per-relocatable-schema overrides in gsettings? [14:01] yes [14:01] the unity package should override all of the plugins that it wants to [14:01] not just the plugin list [14:02] hum the discussion started on another channel? [14:02] desrt: currently it's a bit hard with the current way things are [14:02] desrt: the issue is that we have 2 profiles [14:02] desrt: and the profiles are different depending on the session you start [14:03] (and it's using different locations) [14:03] Since in this case we won't be able to use overrides for this purpose really [14:04] hey desrt btw :p [14:04] (sorry, jumping into the discussion as it seems you are speaking about the issue we had) [14:04] Since the case is we need like 2 different overrides, each for every profile, as didrocks says - so not sure if we can use overrides in this way [14:05] didrocks: good that you joined in, I was expecting that even! :) [14:05] sil2100: not sure what the beginning of the discussion was, but well, I think that desrt needs and deserves to have the full story :p [14:06] otherwise, this means a dconf *writes* at first login :) [14:06] and I know desrt doesn't like that! [14:06] i don't want to add a complicated feature to gsettings that will really only support a single (very weird) usecase [14:06] desrt: what do you suggest that we do in that case? [14:06] and hopefully this one user will be gone soon enough... [14:07] didrocks: install overrides [14:07] desrt: but we already do that [14:07] and don't expect a gnome session to work on the same machine as a unity session [14:07] didrocks: I know you'll be mad at me, but I gave desrt the whole story on priv... then I got enlighted that I'm talking in private, so I moved the discussion here [14:07] ;( [14:07] desrt: ok, so waiting for the fallback session to die [14:07] sil2100: yeah, please stop this habit :( [14:08] didrocks: it's getting better though, since I understood this myself and corrected my behavior this time ;)! [14:09] so here's one possibility [14:09] heh, https://twitter.com/opensourcerer/status/258569723481055233 ;) [14:09] the compizconfig abstraction is pretty... impressive [14:09] why not just have a second set of schemas in there? [14:09] like, instead of installing overrides, the unity session could install new copies of the schemas [14:09] with some prefix or something.... [14:10] chrisccoulson: do not listen to him, get to work. [14:10] lol [14:10] chrisccoulson: you be scrollin', they be hatin' [14:10] I think that's what was being done with GConf [14:10] desrt: I think that relocatable schemas were exactly for those purposes, isn't it? [14:10] didrocks: no [14:11] desrt: so I think that's why we're using relocatable schemas [14:11] didrocks: they were made for the case where you have multiple accounts, for example [14:11] and each account has user/password/host/port/etc type settings [14:11] Ok, in this use-case, you only need one pair of overrides usually [14:11] desrt: don't you think we can have "types of accounts" with exactly the same parameter, by different default values? [14:11] didrocks: i guess it's unusual to have some account parameters set by default [14:12] for only one account.... [14:12] desrt: ok, I'm fine with the hack for quantal, as I think the profile thingy will die soon [14:12] i'll look the other way when you write to dconf :) [14:14] desrt: heh, and worse, I have to use dconf itself because of the revert :p [14:14] desrt: but we'll discuss this at UDS I guess [14:14] (revert bug) [14:14] ;) [14:15] didrocks: it's always your option to install a dconf override :) [14:15] it's really the same issue as we've had 1000 times before [14:15] desrt: heh, indeed :) [14:15] we want one set of settings in one session and another in another [14:17] desrt: rings me a bell :p [14:20] * sil2100 remembers setting once both gsettings and dconf override for the same thing just to be sure it's overridden [14:21] Not really proud of that one === qengho_ is now known as qengho [14:35] oh crap [14:35] firefox is loading 2 different copies of sqlite in to memory [14:35] it's own copy, and the system copy :( [14:36] i wonder how this has not completely broken already [15:06] pitti, hi [15:35] Laney, do you run your glib update? [15:35] yeah [15:35] well, without the cherry-pick [15:35] Laney, does "gresource details /usr/bin/nautilus" works? [15:36] seb128: nope, "gresource is built without elf support" [15:36] Laney, ok, your "drop libelf-dev build-depends" is buggy :p [15:36] huh, weird [15:36] $ gresource details /usr/bin/nautilus [15:36] nautilus 206 u /org/gnome/nautilus/icons/knob.png [15:36] nautilus 482 u /org/gnome/nautilus/icons/thumbnail_frame.png [15:36] nautilus 18004 c /org/gnome/nautilus/nautilus-bookmarks-window.ui [15:36] ... [15:37] on quantal [15:37] well [15:37] https://launchpadlibrarian.net/117502434/buildlog_ubuntu-quantal-i386.glib2.0_2.34.0-1ubuntu1_BUILDING.txt.gz [15:37] checking for LIBELF... no [15:37] checking for elf_begin in -lelf... yes [15:37] checking for elf_getshdrstrndx in -lelf... yes [15:37] ... [15:37] yeah i was going to compare that [15:37] still testsuiting atm [15:37] so it did do something before [15:38] Laney, well anyway gresource doing "gresource is built without elf support" is the reason why I added that build-depends in quantal :p [15:38] not sure why Josselin though it was the wrong lib... [15:38] no, it's fine, I just believed the changelog from joss [15:38] there are 2 elf libs though, one used to be in universe [15:39] so we might prefer the other one compared to debian (I know that was the case for bud-buddy by then) [15:39] it's true that libelf-dev doesn't ship a pcfile [15:41] seb128, does turning on accessibility slow down the desktop a little? and is accessibility required to be on to use onboard? [15:42] Laney, right, but the configure doesn't check for one, it checks for .h also [15:42] correct [15:42] putting it back [15:42] kenvandine, using chromium-browser how does webapps let me (for example) work with gmail? i installed unity-webapps-gmail but i dont' know how it's supposed to work [15:43] Laney, thanks [15:43] rickspencer3, my gut feeling is that it does slow down thing yes, and it's not required for onboard afaik [15:43] hello tkamppeter [15:45] bcurtiswx, you should get prompted to integrate [15:45] and you shouldn't need to install the package yourself [15:45] that should happen automatically [15:45] hmm [15:45] kenvandine, even if I already had a gmail account setup and logged in before webapps was integrated ? [15:45] yes [15:45] well [15:46] installing the package isn't integrating [15:46] you need to click yes in the infobar [15:46] when it prompts you [15:46] does it work in firefox? [15:47] kenvandine, yes it does (noticed i haven't used firefox in a while) [15:48] so you got prompted, and after accepting it you see the launcher for it? [15:48] thanks seb128 [15:48] i get prompted yes, haven't gone through to see the launcher. I wanted to use chromium-browser [15:48] bcurtiswx, you should get prompted in chromium as well [15:48]