[07:07] asac: please ping me re bug 460860 as soon as you're up [07:07] Launchpad bug 460860 in prism "old prism apps just stop working after upgrade" [High,Triaged] https://launchpad.net/bugs/460860 [10:50] kenvandif: ken ... IF ;) you are there, let me know. [10:50] bindwoodish issue here [10:50] nothing works [10:50] at least none of the tests i suggested [11:50] jdstrand: so i am not sure what to do for sqlite [11:50] jdstrand: there have been SRUs [11:50] if we want to roll something to security we would need two updates for each release? [11:51] in jaunty there is one SRU https://edge.launchpad.net/ubuntu/+source/sqlite3/3.6.10-1ubuntu0.2 [11:51] intrepid too https://edge.launchpad.net/ubuntu/+source/sqlite3/3.5.9-3ubuntu1 [11:53] * asac sits and waits [12:08] asac, morning. I have to run my son to daycare. Should be back in half hour to forty-five minutes [12:14] ok [12:31] seems i can't play videos on my dual core. sound & video are jerky. like here http://vimeo.com/4904965 [12:33] or here http://vimeo.com/6601409 [12:34] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [12:34] 20429 fta 20 0 1075m 386m 34m R 115 19.2 130:08.03 firefox-3.7 [12:34] 1055 root 20 0 307m 165m 15m S 20 8.2 68:10.32 Xorg [12:34] 1501 fta 9 -11 157m 7828 6556 S 2 0.4 35:21.16 pulseaudio [12:36] it was fine a couple of weeks ago === kenvandif is now known as kenvandine === mtrudel_ is now known as cyphermox [13:01] Hi, asac. I'm back [13:01] lunch now ... 30 minutes [13:02] np [13:45] urbanape: ok [13:45] urbanape: so .... [13:45] where is the couchdb located? [13:47] asac, it's desktopcouch [13:47] where? [13:48] it starts up on a random, unclaimed port. You can either query dbus for it, or you can go to a generated static page: [13:48] file:///home//.local/share/desktop-couch/couchd.html [13:48] er, couchdb.html [13:48] file:///home/asac/.local/share/desktop-couch/couchdb.html [13:48] that doesnt exist [13:48] do you have desktopcouch installed? [13:48] i have couchdb processes running [13:49] is it the system couchdb? 5984? [13:49] ii desktopcouch 0.5-0ubuntu1 A Desktop CouchDB instance [13:49] http://paste.ubuntu.com/302052 [13:49] thats the ps -eaf | grep couchdb [13:51] firefox 6706 asac 25u IPv4 6542946 0t0 TCP 127.0.0.1:37486->127.0.0.1:5984 (ESTABLISHED) [13:51] so seems ffox has a connection open to that port [13:51] http://paste.ubuntu.com/302055/ [13:51] weird. It shouldn't be falling back on the system couchdb. [13:51] hmm [13:51] We took out that behavior a long while ago [13:52] who would startup desktopcouch? [13:52] dbus activation? [13:52] yes, ffox with bindwood installed should start it up (the act of querying it for its port will start it if it's not already) [13:54] * asac kills [13:55] killing killed it [13:55] nothing starts [13:57] what happens if you start it manually: $ python /usr/lib/desktopcouch/desktopcouch-service [13:57] now things are running with my user [13:57] after i restarted couchdb [13:57] also, incidentally, are you using the apparmor profiles for ffox? [13:57] we've had at least one report that bindwood doesn't behave very well in that environment. [13:58] apparmor is enabled by default afaik [13:58] yeah [13:58] Oct 26 14:55:05 tinya kernel: [416505.927541] type=1503 audit(1256565305.801:72): operation="exec" pid=12797 parent=12796 profile="/usr/lib/firefox-3.5.*/firefox" requested_mask="::x" denied_mask="::x" fsuid=1000 ouid=0 name="/usr/share/bindwood/couchdb_env.sh" [13:58] Oct 26 14:56:22 tinya wpa_supplicant[1320]: CTRL-EVENT-SCAN-RESULTS [13:58] Oct 26 14:56:36 tinya kernel: [416596.256205] type=1503 audit(1256565396.133:73): operation="exec" pid=13148 parent=13147 profile="/usr/lib/firefox-3.5.*/firefox" requested_mask="::x" denied_mask="::x" fsuid=1000 ouid=0 name="/usr/share/bindwood/couchdb_env.sh" [13:58] Oct 26 14:56:54 tinya kernel: [416614.703574] type=1503 audit(1256565414.578:74): operation="exec" pid=13169 parent=13168 profile="/usr/lib/firefox-3.5.*/firefox" requested_mask="::x" denied_mask="::x" fsuid=1000 ouid=0 name="/usr/share/bindwood/couchdb_env.sh" [13:58] Oct 26 14:57:45 tinya kernel: [416665.533608] type=1503 audit(1256565465.409:75): operation="exec" pid=13206 parent=13205 profile="/usr/lib/firefox-3.5.*/firefox" requested_mask="::x" denied_mask="::x" fsuid=1000 ouid=0 name="/usr/share/bindwood/couchdb_env.sh" [13:58] jdstrand: ^^ ... one more for you ;) [13:59] ok trying with disabled [14:00] does that only stop system-installed extensions? I've been using Bindwood since, well, its inception and haven't had any problems. [14:00] I might not be running apparmor, though. I've got no logs in /var/log/apparmor/ [14:01] yes [14:01] system installed are differenct [14:01] I mostly have been running Bindwood developmentally with a file in my profile's extensions directory pointing to the dev directory [14:01] different [14:01] apparmor wise [14:01] s/mostly// [14:01] please file a bug against apparmor [14:01] will do [14:01] or move the bug you had there [14:01] we just want to add an exception for Bindwood's shell script? [14:02] It's the only process we call. [14:03] urbanape: i get a complain "login to localhost:49698" [14:03] administrator [14:03] password [14:03] urbanape: if just ignoring that process error is a solution we can do that [14:03] are you getting it repeatedly? [14:03] yes. with my real profile [14:03] what kind of port is that? [14:03] is that bindwood? [14:04] that's the desktopcouch port. [14:04] yeah. seems its busted somewhat [14:04] It picks a random, unused port to start the couch process listening. [14:04] hmm [14:04] do you check if thats taken already? [14:04] dbus does [14:04] dbus just picks an unused port for the process. [14:04] beam.smp 12910 asac 13u IPv4 6549527 0t0 TCP 127.0.0.1:49698 (LISTEN) [14:04] we find out which port by querying dbus. [14:04] so its taken [14:05] dbus? [14:05] thats a http thing, right? [14:05] no, it's a system process thing [14:05] beam.smp [14:05] beam.smp is the erlang process that's running CouchDB [14:05] beam.smp has something to do with couchcb [14:05] yeah [14:05] should be renamed imo ;) [14:05] thought you were asking if dbus is an http thing [14:05] but why does firefox think it needs to connect using http? [14:05] no [14:06] i know that dbus isnt http [14:06] alright, here's how Bindwood works [14:06] but firefox gets a http auth [14:06] on that port [14:06] go ahead [14:06] we start up, and we run that couchdb_env.sh, which gets us: [14:06] the port that CouchDB is listening on, and the oauth tokens from our personal desktop couch ini file. [14:07] querying the port has a side effect of starting up desktop couch if it's not already running. [14:07] (that happens with anything that queries for our desktop couch, not just Bindwood) [14:07] yeah [14:07] thats understood [14:07] then, we ensure that there's a bookmarks database in our CouchDB, creating if necessary. [14:08] (using the AJAX couch.js libs) [14:08] so why would firefox not succeed with that oauth ... [14:08] that should be using the oauth tokens [14:08] and it's not, so it's trying to fall back on HTTP Basic Auth. [14:08] you'll get a prompt for each ajax request, and it will be misery if you've got a lot of bookmarks. [14:08] so it means that ooauth failed? [14:08] the way we solved this before was ... [14:09] it means that for some reason, the oauth tokens it got were different from what couch was expecting. [14:09] ok. so where does ffox get that ooauth token from? [14:09] also ... does it safe that in profile? [14:09] that would explains it i guess [14:10] as i created the couchdb with a different profile [14:10] no, doesn't get saved in profile, we read it each time firefox starts up. [14:10] ok [14:10] so why would that not work? [14:11] and all of your (asac's) ffox profiles share a CouchDB. We tag each Couch record with the profile associated with it, and filter for the currently running profile when dealing with the records. [14:11] hmm [14:11] so the test i outlined wouldnt work anyway [14:11] anyway. so lets focus on why oauth token can be invalid [14:11] how do you get that token? [14:12] err, apparmor is installed and enabled by default in Ubuntu, but one must opt-in to the firefox profile, which is disabled by default [14:12] jdstrand, aha, okay. [14:12] jdstrand: oh. so i have it enabled because i enabled it? [14:13] I'm not sure the profile will ever be enabled by default, but we'll keep plugging away at it and making it better as we go [14:13] asac: yes [14:13] asac, this should give you four tokens joined with colons: python -c "from desktopcouch import local_files; tokens = local_files.get_oauth_tokens(); print ':'.join([tokens['consumer_key'], tokens['consumer_secret'], tokens['token'], tokens['token_secret']])" [14:13] you don't need to paste them here. [14:13] checking [14:14] asac: see https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#New%20profiles [14:14] asac: it will tell you how to disable it again if desired [14:14] urbanape: yes. that works ... four things [14:14] jdstrand: no. i know [14:14] i did it [14:14] k, so the couchdb_env.sh is getting *something*. [14:14] just thought we had it enabled [14:14] asac: ah, ok [14:14] Lemme check with thisfred and see why your Couch might be using something different. [14:15] jdstrand: so for sqlite3 update ... what do you think wrt SRUs [14:15] 12:50 < asac> jdstrand: so i am not sure what to do for sqlite [14:15] 12:50 < asac> jdstrand: there have been SRUs [14:15] 12:50 < asac> if we want to roll something to security we would need two updates for each release? [14:15] 12:51 < asac> in jaunty there is one SRU https://edge.launchpad.net/ubuntu/+source/sqlite3/3.6.10-1ubuntu0.2 [14:15] 12:51 < asac> intrepid too https://edge.launchpad.net/ubuntu/+source/sqlite3/3.5.9-3ubuntu1 [14:15] * jdstrand nods [14:15] asac: so that is in -updates? [14:15] yes. we have something in -updates [14:15] but we wwant the new update go to -security [14:16] asac: we pull from -updates for -security updates [14:16] rolling two updates sounds hard [14:16] jdstrand: ok. so its ok to base on top of -updates version. thanks [14:16] that fixes my issues ;) [14:16] asac: not only ok, it is how we always do it ;) [14:16] great. [14:16] otherwise it the maintenance issues would just explode [14:17] right [14:17] thats what i felt [14:17] s/it// [14:17] cool [14:17] * asac continues to proceed on sqlite3 [14:22] asac, I'll let you know when I've got something for you to try or a question about your environment. [14:22] thx [14:25] asac: if you start ffox from the command line like so: `BINDWOOD_DEBUG=1 firefox &`, we log more diagnostic output in the error console. It might be useful to see the errors you're getting from that point of view (if you can get past all the annoying basic auth prompts) [14:25] let me try [14:25] no change [14:25] no log [14:26] odd [14:26] nothing new [14:26] echo $BINDWOOD_DEBUG [14:26] 1 [14:30] nothing in the Error Console? [14:37] brb [14:43] had to uninstall bindwood [14:53] kenvandine: can you verify bindwood for me ;)? [14:53] kenvandine: it doesnt work at all here, but i dont want to block this upload just because it doesnt work for me [14:53] of course if its still broken we shouldnt upload it, so would be nice if you could run the testcases i posted in the mail threads and confirm that they work [14:55] asac, it's very strange. I'm definitely using it in a different manner than by installing the package (though I will do that as well), but I haven't had any of these particular problems since we've corrected the oauth code after the last major release (0.4.0) [14:55] asac, it is working here [14:55] kenvandine, are you on desktopcouch 0.5.0? I'm upgrading locally from 0.4.2, but it's taking a bit longer than I had anticipated. [14:55] asac, let me check my mail [14:55] kenvandine, also check my followup [14:55] urbanape, i have 0.5.0 from your ppa [14:56] not from karmic [14:56] k [14:59] asac, you emailed tests? [14:59] ah... friday :) [15:01] kenvandine: yes. though we found out today that those arent going to work as they are filtered per-profile ... so instead of using a new profile it probably is dropping the .mozilla profile and ensure that its properly synched... [15:01] yeah [15:01] i filed bug 461150 fwiw [15:01] Launchpad bug 461150 in bindwood "when oauth fails, user gets spammed with HTTP authentication dialogs" [Undecided,New] https://launchpad.net/bugs/461150 [15:02] asac, good... that sucks :) [15:02] kenvandine: i am not sure why oauth fails here ... but its definitly bad ;) [15:02] here [15:02] yeah [15:18] urbanape, [object XULElement] [15:18] damn [15:18] how do you copy errors from the error console? [15:29] kenvandine: right click /copy/ [15:30] or install Console2 [15:48] urbanape, there is definately a problem [15:48] asac, right click copy got me the object XULElement thing [15:49] * kenvandine finds console2 [15:49] kenvandine, hrm. I'm still going through my upgrade. [15:50] oh nm... i still have 0.4.1 installed [15:51] humm... it got installed friday [15:51] weird [15:51] ok [15:51] i guess i did that :) [15:51] * kenvandine removes and retests [15:52] *whew* [15:52] i guess that explains why i didn't have to install it in my new mozilla dir :) [16:11] urbanape, asac: ok i have tested with a clean profile and it is populating my bookmarks correctly [16:11] and not spamming me with livemarks [16:11] but let me run it for a little longer to make sure they don't come back :) [16:11] not getting the basic auth prompts? [16:11] nope [16:11] working fine [16:11] good deal [16:12] whacked the profile, installed bindwood.xpi and verified Bookmarks->Desktop Couch with an unfiled bookmark appeared [16:12] kenvandine: and adding new bookmarks, moving and starting with fresh profile works? [16:12] yes [16:12] kenvandine: please test system install [16:12] that was the unfiled bookmark [16:12] not .xpi [16:12] ok [16:14] asac, where can i build the deb from [16:15] nm [16:15] found it [16:17] COPYING.BSD isnt in upstream btw [16:17] it should have been included during the last release. [16:17] (or after) [16:18] huh. Guess it got overlooked. [16:18] its in the packaging branch [16:18] not in the upstream tree [16:18] oddly enough [16:18] anyway [16:19] yeah, just hasn't been backported. I'll file a bug for it and get it landed. [16:19] ok pushing the potential packaging release to ~ubuntu-dev/firefox-extensions/bindwood.ubuntu [16:19] asac, yeah it works from a deb and clean profile [16:19] kenvandine: can you branch that ... use bzr bd to build [16:19] ok [16:19] asac, i just merged locally and bzr bd [16:20] better check the branch from above [16:20] i can do that too [16:20] i dont want to have it fail because we did separate things [16:20] thx [16:20] :) [16:20] sorry for not posting it earlier [16:20] no worries [16:21] - fix LP: #459068 - Create a proper folder for storing Couchdb/UbuntuOne book [16:21] marks [16:21] so why does that fix livebookmarks? [16:21] that was a separate bug [16:21] mildly related [16:21] slightly related rather [16:21] err [16:21] so why do we get a merge reqeust for that bug and it fixes something else? [16:22] urbanape, ^^ [16:22] it was initially the other bug fix [16:22] i dont want to fix stuff that isnt release critical at this point [16:22] then he branched that to fix the folder thing [16:22] thats not nice [16:22] yeah, well without that fix it gets really ugly [16:23] basically bookmarks you get synced all show up in your toolbar [16:23] so it gets huge [16:23] this drops it into a folder of it's own [16:23] asac, it was a modification to the third fix I listed in my initial email [16:24] previous behavior was to pull new bookmarks into the toolbar folder, which was bad. kenvandine's bug lists that as the bad behavior and the fix I added just redirects them to a known folder location inside the bookmarks menu. [16:25] ok doesnt matter i will upload that now [16:25] once bindwood is in main this needs to be done by adding patches i guess [16:28] yeah [16:28] asac, for sure [16:28] uploaded [16:28] asac, ok tested from your branch and it works [16:28] asac, thx! [16:28] yeah. had to uncommit and add new bug to changelog [16:28] but it should be same [16:28] thx [16:28] yeah [16:28] :) [16:28] * kenvandine will be glad to have firefox behaving again :) [16:29] this oauth spamming needs to be fixed ;) [16:29] but well ... glad its not in main ;) [16:30] btw, the other bug was added after the grave bug in the branch [16:30] so it was not really a reuse of the other fix ;) [16:30] ok off ... watching a potential flat [16:31] kenvandine: you might need to prod pitti or scottk [16:31] to get this in [16:31] i can do that when back [16:31] ok [16:31] i think archive is almost locked down ... so lets hope that still goes in [16:31] i'll talk to pitti right now [16:31] thx [16:31] thx, both of you [16:31] welcome [16:36] ok pitti accepted it :) [16:38] gotta reboot after dist-upgrade [16:38] brb [16:44] hi asac [16:59] hey guys [17:30] micahg: hi [17:35] I'll be back in about an hour [18:29] asac: what did you think of my prism fix? [18:34] jdstrand: for the apparmor bugs, is there a process you'd like me to follow? [18:34] micahg: in general, see https://wiki.ubuntu.com/DebuggingApparmor [18:35] what are we committed to having work in the profile? [18:36] micahg: also, while I developed the profile, I won't necessarily be the one to fix it. aa profiling bugs are often easy to fix. however, feel free to subscribe ubuntu-security rather than directly assigning me [18:36] ok, sorry [18:36] np [18:36] so, what do you think the profile should support (so I know what's a bug and what isn't) [18:36] I've been watching the bugs [18:37] micahg: 1st, remember the profile is opt-in, so none of the profiling bugs should be higher than 'Low' I would say [18:37] idea being that people who enable it should be able to file a bug/fix it themselves [18:37] in terms of what it supports, I would like it to support anything that is shipped in Ubuntu [18:38] does that mean allow entries for everything? [18:38] the profile should generally be able to handle most people's extenstions [18:38] extensions that they download [18:38] we can look at those on a case by case basis [18:39] micahg: what I mean by 'anything that is shipped in Ubuntu' is that if there is an action within firefox or a shipped extension that doesn't work because of the profile, then we should look hard at fixing it [18:39] the recent nautilus one is an example of that [18:39] am I better off subscribing ubuntu-security if the logs show an issue with the apparmor profile? [18:39] being able to run fsck is an example of one that we would not allow [18:40] rather than trying to fix it myself and possibly cause something unsecure to happen? [18:40] micahg: feel free to subscribe us and attach a debdiff fixing it. we can review it and give feedback [18:40] or a diff if that is easier [18:40] is triaged still appropriate if the kernel log is attached? [18:41] yes [18:41] ok, great, thank you for your time [18:41] assuming it is just a profiling bug (eg, like the nautilus one, where we should just allow Ux access) [18:41] micahg: np! thanks for your help with these :) === dpm is now known as dpm-afk [18:50] hi asac [18:50] or asac_ === asac_ is now known as asac [19:00] micahg: ok [19:00] ok? [19:01] micahg: so ... what was the prism branch? [19:01] https://code.edge.launchpad.net/~micahg/prism/prism-karmic-2 [19:01] still waiting for the reporter to test [19:02] micahg: on bug folks say it didnt work [19:02] say one person [19:03] how is your fix supposed to work? [19:03] it's supposed to provide a fake xulrunner-1.9 binary that calls the prism binary and loads the webapp [19:03] hmm [19:03] the command works for me [19:03] but I don't have an old app created by prism [19:04] that's what I needed tested [19:04] so would Exec=xulrunner-1.9 /usr/share/prism/application.ini -webapp slimtimer@prism.app [19:04] i don't get what the guy posted [19:04] so would Exec=xulrunner-1.9.1 /usr/share/prism/application.ini -webapp slimtimer@prism.app [19:04] work? [19:04] no [19:04] idk [19:04] why not? [19:05] didn't test that [19:05] I have it turning into prism-bin /usr/share/prism/application.ini -webapp slimtimer@prism.app [19:05] because currently it's prism $@ [19:05] when the new prism writes out a shorcut [19:06] ok. [19:06] shipping xulrunner-1.9 is too messy [19:06] imo we can sell this as an acceptable breakage [19:07] that's why I added a conflicts [19:07] and a comment in the changelog [19:07] yes. but that gets messy. prism should push xulrunner-1.9 out [19:07] or get pushed out because of xulrunner-1.9 [19:07] well, it can't work with 1.9 anyways [19:08] i think we can won't fix that bug. [19:08] I was thinking to write a migration script, but I don't know enough about prism to do it properly [19:09] I figured this could get us through release and then in -updates we could fix it properly [19:09] i dont think we should fix it [19:09] the migration script would require either to replace xulrunner-1.9 [19:09] well, that leaves people to recreate their apps [19:09] sure [19:10] we can ship a xulrunner-1.9 link in xulrunner-1.9.1 [19:10] thats all we can do [19:10] but not before updates [19:10] let me see if that does it [19:10] but that's messy as well [19:10] as it builds on an initial bad practice [19:11] yes. but messing with /usr/bin/xulrunner* is better to be done in a xulrunner package [19:11] cant the user just edit the .desktop file? [19:15] yes [19:15] I'm testing your fix [19:15] anyways, I think I messed up a symlink in the package anyways [19:16] https://bugs.edge.launchpad.net/ubuntu/+source/prism/+bug/460860/comments/10 [19:16] Launchpad bug 460860 in prism "old prism apps just stop working after upgrade" [High,Won't fix] [19:17] micahg: i think we hsould keep it won't fix as i said in the bug [19:17] ok [19:17] its inconvenient, but prism is a preview thing [19:18]