[07:07] <micahg> asac: please ping me re bug 460860 as soon as you're up
[10:50] <asac> kenvandif: ken ... IF ;) you are there, let me know.
[10:50] <asac> bindwoodish issue here
[10:50] <asac> nothing works
[10:50] <asac> at least none of the tests i suggested
[11:50] <asac> jdstrand: so i am not sure what to do for sqlite
[11:50] <asac> jdstrand: there have been SRUs
[11:50] <asac> if we want to roll something to security we would need two updates for each release?
[11:51] <asac> in jaunty there is one SRU https://edge.launchpad.net/ubuntu/+source/sqlite3/3.6.10-1ubuntu0.2
[11:51] <asac> intrepid too https://edge.launchpad.net/ubuntu/+source/sqlite3/3.5.9-3ubuntu1
[11:53]  * asac sits and waits
[12:08] <urbanape> asac, morning. I have to run my son to daycare. Should be back in half hour to forty-five minutes
[12:14] <asac> ok
[12:31] <fta> seems i can't play videos on my dual core. sound & video are jerky. like here http://vimeo.com/4904965
[12:33] <fta> or here http://vimeo.com/6601409
[12:34] <fta>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
[12:34] <fta> 20429 fta       20   0 1075m 386m  34m R  115 19.2 130:08.03 firefox-3.7
[12:34] <fta>  1055 root      20   0  307m 165m  15m S   20  8.2  68:10.32 Xorg
[12:34] <fta>  1501 fta        9 -11  157m 7828 6556 S    2  0.4  35:21.16 pulseaudio
[12:36] <fta> it was fine a couple of weeks ago
[13:01] <urbanape> Hi, asac. I'm back
[13:01] <asac> lunch now ... 30 minutes
[13:02] <urbanape> np
[13:45] <asac> urbanape: ok
[13:45] <asac> urbanape: so ....
[13:45] <asac> where is the couchdb located?
[13:47] <urbanape> asac, it's desktopcouch
[13:47] <asac> where?
[13:48] <urbanape> 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] <urbanape> file:///home/<username>/.local/share/desktop-couch/couchd.html
[13:48] <urbanape> er, couchdb.html
[13:48] <asac> file:///home/asac/.local/share/desktop-couch/couchdb.html
[13:48] <asac> that doesnt exist
[13:48] <urbanape> do you have desktopcouch installed?
[13:48] <asac> i have couchdb processes running
[13:49] <urbanape> is it the system couchdb? 5984?
[13:49] <asac> ii  desktopcouch                         0.5-0ubuntu1                         A Desktop CouchDB instance
[13:49] <asac> http://paste.ubuntu.com/302052
[13:49] <asac> thats the ps -eaf | grep couchdb
[13:51] <asac> firefox    6706        asac   25u     IPv4    6542946      0t0        TCP 127.0.0.1:37486->127.0.0.1:5984 (ESTABLISHED)
[13:51] <asac> so seems ffox has a connection open to that port
[13:51] <urbanape> http://paste.ubuntu.com/302055/
[13:51] <urbanape> weird. It shouldn't be falling back on the system couchdb.
[13:51] <asac> hmm
[13:51] <urbanape> We took out that behavior a long while ago
[13:52] <asac> who would startup desktopcouch?
[13:52] <asac> dbus activation?
[13:52] <urbanape> 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] <asac> killing killed it
[13:55] <asac> nothing starts
[13:57] <urbanape> what happens if you start it manually: $ python /usr/lib/desktopcouch/desktopcouch-service
[13:57] <asac> now things are running with my user
[13:57] <asac> after i restarted couchdb
[13:57] <urbanape> also, incidentally, are you using the apparmor profiles for ffox?
[13:57] <urbanape> we've had at least one report that bindwood doesn't behave very well in that environment.
[13:58] <asac> apparmor is enabled by default afaik
[13:58] <asac> yeah
[13:58] <asac> 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] <asac> Oct 26 14:56:22 tinya wpa_supplicant[1320]: CTRL-EVENT-SCAN-RESULTS
[13:58] <asac> 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] <asac> 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] <asac> 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] <asac> jdstrand: ^^ ... one more for you ;)
[13:59] <asac> ok trying with disabled
[14:00] <urbanape> does that only stop system-installed extensions? I've been using Bindwood since, well, its inception and haven't had any problems.
[14:00] <urbanape> I might not be running apparmor, though. I've got no logs in /var/log/apparmor/
[14:01] <asac> yes
[14:01] <asac> system installed are differenct
[14:01] <urbanape> I mostly have been running Bindwood developmentally with a file in my profile's extensions directory pointing to the dev directory
[14:01] <asac> different
[14:01] <asac> apparmor wise
[14:01] <urbanape> s/mostly//
[14:01] <asac> please file a bug against apparmor
[14:01] <urbanape> will do
[14:01] <asac> or move the bug you had there
[14:01] <urbanape> we just want to add an exception for Bindwood's shell script?
[14:02] <urbanape> It's the only process we call.
[14:03] <asac> urbanape: i get a complain "login to localhost:49698"
[14:03] <asac> administrator
[14:03] <asac> password
[14:03] <asac> urbanape: if just ignoring that process error is a solution we can do that
[14:03] <urbanape> are you getting it repeatedly?
[14:03] <asac> yes. with my real profile
[14:03] <asac> what kind of port is that?
[14:03] <asac> is that bindwood?
[14:04] <urbanape> that's the desktopcouch port.
[14:04] <asac> yeah. seems its busted somewhat
[14:04] <urbanape> It picks a random, unused port to start the couch process listening.
[14:04] <asac> hmm
[14:04] <asac> do you check if thats taken already?
[14:04] <urbanape> dbus does
[14:04] <urbanape> dbus just picks an unused port for the process.
[14:04] <asac> beam.smp  12910        asac   13u     IPv4    6549527      0t0        TCP 127.0.0.1:49698 (LISTEN)
[14:04] <urbanape> we find out which port by querying dbus.
[14:04] <asac> so its taken
[14:05] <asac> dbus?
[14:05] <asac> thats a http thing, right?
[14:05] <urbanape> no, it's a system process thing
[14:05] <asac> beam.smp
[14:05] <urbanape> beam.smp is the erlang process that's running CouchDB
[14:05] <asac> beam.smp has something to do with couchcb
[14:05] <asac> yeah
[14:05] <asac> should be renamed imo ;)
[14:05] <urbanape> thought you were asking if dbus is an http thing
[14:05] <asac> but why does firefox think it needs to connect using http?
[14:05] <asac> no
[14:06] <asac> i know that dbus isnt http
[14:06] <urbanape> alright, here's how Bindwood works
[14:06] <asac> but firefox gets a http auth
[14:06] <asac> on that port
[14:06] <asac> go ahead
[14:06] <urbanape> we start up, and we run that couchdb_env.sh, which gets us:
[14:06] <urbanape> the port that CouchDB is listening on, and the oauth tokens from our personal desktop couch ini file.
[14:07] <urbanape> querying the port has a side effect of starting up desktop couch if it's not already running.
[14:07] <urbanape> (that happens with anything that queries for our desktop couch, not just Bindwood)
[14:07] <asac> yeah
[14:07] <asac> thats understood
[14:07] <urbanape> then, we ensure that there's a bookmarks database in our CouchDB, creating if necessary.
[14:08] <urbanape> (using the AJAX couch.js libs)
[14:08] <asac> so why would firefox not succeed with that oauth ...
[14:08] <urbanape> that should be using the oauth tokens
[14:08] <urbanape> and it's not, so it's trying to fall back on HTTP Basic Auth.
[14:08] <urbanape> you'll get a prompt for each ajax request, and it will be misery if you've got a lot of bookmarks.
[14:08] <asac> so it means that ooauth failed?
[14:08] <urbanape> the way we solved this before was ...
[14:09] <urbanape> it means that for some reason, the oauth tokens it got were different from what couch was expecting.
[14:09] <asac> ok. so where does ffox get that ooauth token from?
[14:09] <asac> also ... does it safe that in profile?
[14:09] <asac> that would explains it i guess
[14:10] <asac> as i created the couchdb with a different profile
[14:10] <urbanape> no, doesn't get saved in profile, we read it each time firefox starts up.
[14:10] <asac> ok
[14:10] <asac> so why would that not work?
[14:11] <urbanape> 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] <asac> hmm
[14:11] <asac> so the test i outlined wouldnt work anyway
[14:11] <asac> anyway. so lets focus on why oauth token can be invalid
[14:11] <asac> how do you get that token?
[14:12] <jdstrand> 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] <urbanape> jdstrand, aha, okay.
[14:12] <asac> jdstrand: oh. so i have it enabled because i enabled it?
[14:13] <jdstrand> 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] <jdstrand> asac: yes
[14:13] <urbanape> 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] <urbanape> you don't need to paste them here.
[14:13] <asac> checking
[14:14] <jdstrand> asac: see https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#New%20profiles
[14:14] <jdstrand> asac: it will tell you how to disable it again if desired
[14:14] <asac> urbanape: yes. that works ... four things
[14:14] <asac> jdstrand: no. i know
[14:14] <asac> i did it
[14:14] <urbanape> k, so the couchdb_env.sh is getting *something*.
[14:14] <asac> just thought we had it enabled
[14:14] <jdstrand> asac: ah, ok
[14:14] <urbanape> Lemme check with thisfred and see why your Couch might be using something different.
[14:15] <asac> jdstrand: so for sqlite3 update ... what do you think wrt SRUs
[14:15] <asac> 12:50 < asac> jdstrand: so i am not sure what to do for sqlite
[14:15] <asac> 12:50 < asac> jdstrand: there have been SRUs
[14:15] <asac> 12:50 < asac> if we want to roll something to security we would need two updates for each release?
[14:15] <asac> 12:51 < asac> in jaunty there is one SRU https://edge.launchpad.net/ubuntu/+source/sqlite3/3.6.10-1ubuntu0.2
[14:15] <asac> 12:51 < asac> intrepid too https://edge.launchpad.net/ubuntu/+source/sqlite3/3.5.9-3ubuntu1
[14:15]  * jdstrand nods
[14:15] <jdstrand> asac: so that is in -updates?
[14:15] <asac> yes. we have something in -updates
[14:15] <asac> but we wwant the new update go to -security
[14:16] <jdstrand> asac: we pull from -updates for -security updates
[14:16] <asac> rolling two updates sounds hard
[14:16] <asac> jdstrand: ok. so its ok to base on top of -updates version. thanks
[14:16] <asac> that fixes my issues ;)
[14:16] <jdstrand> asac: not only ok, it is how we always do it ;)
[14:16] <asac> great.
[14:16] <jdstrand> otherwise it the maintenance issues would just explode
[14:17] <asac> right
[14:17] <asac> thats what i felt
[14:17] <jdstrand> s/it//
[14:17] <jdstrand> cool
[14:17]  * asac continues to proceed on sqlite3
[14:22] <urbanape> asac, I'll let you know when I've got something for you to try or a question about your environment.
[14:22] <urbanape> thx
[14:25] <urbanape> 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] <asac> let me try
[14:25] <asac> no change
[14:25] <asac> no log
[14:26] <asac> odd
[14:26] <asac> nothing new
[14:26] <asac> echo $BINDWOOD_DEBUG
[14:26] <asac> 1
[14:30] <urbanape> nothing in the Error Console?
[14:37] <urbanape> brb
[14:43] <asac> had to uninstall bindwood
[14:53] <asac> kenvandine: can you verify bindwood for me ;)?
[14:53] <asac> kenvandine: it doesnt work at all here, but i dont want to block this upload just because it doesnt work for me
[14:53] <asac> 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] <urbanape> 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] <kenvandine> asac, it is working here
[14:55] <urbanape> 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] <kenvandine> asac, let me check my mail
[14:55] <urbanape> kenvandine, also check my followup
[14:55] <kenvandine> urbanape, i have 0.5.0 from your ppa
[14:56] <kenvandine> not from karmic
[14:56] <urbanape> k
[14:59] <kenvandine> asac, you emailed tests?
[14:59] <kenvandine> ah... friday :)
[15:01] <asac> 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] <kenvandine> yeah
[15:01] <asac> i filed bug 461150 fwiw
[15:02] <kenvandine> asac, good... that sucks :)
[15:02] <asac> kenvandine: i am not sure why oauth fails here ... but its definitly bad ;)
[15:02] <asac> here
[15:02] <kenvandine> yeah
[15:18] <kenvandine> urbanape, [object XULElement]
[15:18] <kenvandine> damn
[15:18] <kenvandine> how do you copy errors from the error console?
[15:29] <asac> kenvandine: right click /copy/
[15:30] <urbanape> or install Console2
[15:48] <kenvandine> urbanape, there is definately a problem
[15:48] <kenvandine> asac, right click copy got me the object XULElement thing
[15:49]  * kenvandine finds console2
[15:49] <urbanape> kenvandine, hrm. I'm still going through my upgrade.
[15:50] <kenvandine> oh nm... i still have 0.4.1 installed
[15:51] <kenvandine> humm... it got installed friday
[15:51] <kenvandine> weird
[15:51] <kenvandine> ok
[15:51] <kenvandine> i guess i did that :)
[15:51]  * kenvandine removes and retests
[15:52] <urbanape> *whew*
[15:52] <kenvandine> i guess that explains why i didn't have to install it in my new mozilla dir :)
[16:11] <kenvandine> urbanape, asac: ok i have tested with a clean profile and it is populating my bookmarks correctly
[16:11] <kenvandine> and not spamming me with livemarks
[16:11] <kenvandine> but let me run it for a little longer to make sure they don't come back :)
[16:11] <urbanape> not getting the basic auth prompts?
[16:11] <kenvandine> nope
[16:11] <kenvandine> working fine
[16:11] <urbanape> good deal
[16:12] <kenvandine> whacked the profile, installed bindwood.xpi and verified Bookmarks->Desktop Couch with an unfiled bookmark appeared
[16:12] <asac> kenvandine: and adding new bookmarks, moving and starting with fresh profile works?
[16:12] <kenvandine> yes
[16:12] <asac> kenvandine: please test system install
[16:12] <kenvandine> that was the unfiled bookmark
[16:12] <asac> not .xpi
[16:12] <kenvandine> ok
[16:14] <kenvandine> asac, where can i  build the deb from
[16:15] <kenvandine> nm
[16:15] <kenvandine> found it
[16:17] <asac> COPYING.BSD isnt in upstream btw
[16:17] <urbanape> it should have been included during the last release.
[16:17] <urbanape> (or after)
[16:18] <urbanape> huh. Guess it got overlooked.
[16:18] <asac> its in the packaging branch
[16:18] <asac> not in the upstream tree
[16:18] <asac> oddly enough
[16:18] <asac> anyway
[16:19] <urbanape> yeah, just hasn't been backported. I'll file a bug for it and get it landed.
[16:19] <asac> ok pushing the potential packaging release to ~ubuntu-dev/firefox-extensions/bindwood.ubuntu
[16:19] <kenvandine> asac, yeah it  works from a deb and clean profile
[16:19] <asac> kenvandine: can you branch that ... use bzr bd to build
[16:19] <asac> ok
[16:19] <kenvandine> asac, i just merged locally and bzr bd
[16:20] <asac> better check the branch from above
[16:20] <kenvandine> i can do that too
[16:20] <asac> i dont want to have it fail because we did separate things
[16:20] <asac> thx
[16:20] <kenvandine> :)
[16:20] <asac> sorry for not posting it earlier
[16:20] <kenvandine> no worries
[16:21] <asac>     - fix LP: #459068 - Create a proper folder for storing Couchdb/UbuntuOne book
[16:21] <asac>       marks
[16:21] <asac> so why does that fix livebookmarks?
[16:21] <kenvandine> that was a separate bug
[16:21] <kenvandine> mildly related
[16:21] <kenvandine> slightly related rather
[16:21] <asac> err
[16:21] <asac> so why do we get a merge reqeust for that bug and it fixes something else?
[16:22] <kenvandine> urbanape, ^^
[16:22] <kenvandine> it was initially the other bug fix
[16:22] <asac> i dont want to fix stuff that isnt release critical at this point
[16:22] <kenvandine> then he branched that to fix the folder thing
[16:22] <asac> thats not nice
[16:22] <kenvandine> yeah, well without that fix it gets really ugly
[16:23] <kenvandine> basically bookmarks you get synced all show up in your toolbar
[16:23] <kenvandine> so it gets huge
[16:23] <kenvandine> this drops it into a folder of it's own
[16:23] <urbanape> asac, it was a modification to the third fix I listed in my initial email
[16:24] <urbanape> 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] <asac> ok doesnt matter i will upload that now
[16:25] <asac> once bindwood is in main this needs to be done by adding patches i guess
[16:28] <kenvandine> yeah
[16:28] <kenvandine> asac, for sure
[16:28] <asac> uploaded
[16:28] <kenvandine> asac, ok tested from your branch and it works
[16:28] <kenvandine> asac, thx!
[16:28] <asac> yeah. had to uncommit and add new bug to changelog
[16:28] <asac> but it should be same
[16:28] <asac> thx
[16:28] <kenvandine> yeah
[16:28] <kenvandine> :)
[16:28]  * kenvandine will be glad to have firefox behaving again :)
[16:29] <asac> this oauth spamming needs to be fixed ;)
[16:29] <asac> but well ... glad its not in main ;)
[16:30] <asac> btw, the other bug was added after the grave bug in the branch
[16:30] <asac> so it was not really a reuse of the other fix ;)
[16:30] <asac> ok off ... watching a potential flat
[16:31] <asac> kenvandine: you might need to prod pitti or scottk
[16:31] <asac> to get this in
[16:31] <asac> i can do that when back
[16:31] <kenvandine> ok
[16:31] <asac> i think archive is almost locked down ... so lets hope that still goes in
[16:31] <kenvandine> i'll talk to pitti right now
[16:31] <asac> thx
[16:31] <urbanape> thx, both of you
[16:31] <asac> welcome
[16:36] <kenvandine> ok pitti accepted it :)
[16:38] <urbanape> gotta reboot after dist-upgrade
[16:38] <urbanape> brb
[16:44] <micahg> hi asac
[16:59] <eagles0513875> hey guys
[17:30] <asac> micahg: hi
[17:35] <micahg> I'll be back in about an hour
[18:29] <micahg> asac: what did you think of my prism fix?
[18:34] <micahg> jdstrand: for the apparmor bugs, is there a process you'd like me to follow?
[18:34] <jdstrand> micahg: in general, see https://wiki.ubuntu.com/DebuggingApparmor
[18:35] <micahg> what are we committed to having work in the profile?
[18:36] <jdstrand> 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] <micahg> ok, sorry
[18:36] <jdstrand> np
[18:36] <micahg> so, what do you think the profile should support (so I know what's a bug and what isn't)
[18:36] <micahg> I've been watching the bugs
[18:37] <jdstrand> micahg: 1st, remember the profile is opt-in, so none of the profiling bugs should be higher than 'Low' I would say
[18:37] <jdstrand> idea being that people who enable it should be able to file a bug/fix it themselves
[18:37] <jdstrand> in terms of what it supports, I would like it to support anything that is shipped in Ubuntu
[18:38] <micahg> does that mean allow entries for everything?
[18:38] <jdstrand> the profile should generally be able to handle most people's extenstions
[18:38] <jdstrand> extensions that they download
[18:38] <jdstrand> we can look at those on a case by case basis
[18:39] <jdstrand> 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] <jdstrand> the recent nautilus one is an example of that
[18:39] <micahg> am I better off subscribing ubuntu-security if the logs show an issue with the apparmor profile?
[18:39] <jdstrand> being able to run fsck is an example of one that we would not allow
[18:40] <micahg> rather than trying to fix it myself and possibly cause something unsecure to happen?
[18:40] <jdstrand> micahg: feel free to subscribe us and attach a debdiff fixing it. we can review it and give feedback
[18:40] <jdstrand> or a diff if that is easier
[18:40] <micahg> is triaged still appropriate if the kernel log is attached?
[18:41] <jdstrand> yes
[18:41] <micahg> ok, great, thank you for your time
[18:41] <jdstrand> assuming it is just a profiling bug (eg, like the nautilus one, where we should just allow Ux access)
[18:41] <jdstrand> micahg: np! thanks for your help with these :)
[18:50] <micahg> hi asac
[18:50] <micahg> or asac_
[19:00] <asac> micahg: ok
[19:00] <micahg> ok?
[19:01] <asac> micahg: so ... what was the prism branch?
[19:01] <micahg> https://code.edge.launchpad.net/~micahg/prism/prism-karmic-2
[19:01] <micahg> still waiting for the reporter to test
[19:02] <asac> micahg: on bug folks say it didnt work
[19:02] <micahg> say one person
[19:03] <asac> how is your fix supposed to work?
[19:03] <micahg> it's supposed to provide a fake xulrunner-1.9 binary that calls the prism binary and loads the webapp
[19:03] <asac> hmm
[19:03] <micahg> the command works for me
[19:03] <micahg> but I don't have an old app created by prism
[19:04] <micahg> that's what I needed tested
[19:04] <asac> so would Exec=xulrunner-1.9 /usr/share/prism/application.ini -webapp slimtimer@prism.app
[19:04] <micahg> i don't get what the guy posted
[19:04] <asac> so would Exec=xulrunner-1.9.1 /usr/share/prism/application.ini -webapp slimtimer@prism.app
[19:04] <asac> work?
[19:04] <micahg> no
[19:04] <micahg> idk
[19:04] <asac> why not?
[19:05] <micahg> didn't test that
[19:05] <micahg> I have it turning into prism-bin /usr/share/prism/application.ini -webapp slimtimer@prism.app
[19:05] <micahg> because currently it's prism $@
[19:05] <micahg> when the new prism writes out a shorcut
[19:06] <asac> ok.
[19:06] <asac> shipping xulrunner-1.9 is too messy
[19:06] <asac> imo we can sell this as an acceptable breakage
[19:07] <micahg> that's why I added a conflicts
[19:07] <micahg> and a comment in the changelog
[19:07] <asac> yes. but that gets messy. prism should push xulrunner-1.9 out
[19:07] <asac> or get pushed out because of xulrunner-1.9
[19:07] <micahg> well, it can't work with 1.9 anyways
[19:08] <asac> i think we can won't fix that bug.
[19:08] <micahg> I was thinking to write a migration script, but I don't know enough about prism to do it properly
[19:09] <micahg> I figured this could get us through release and then in -updates we could fix it properly
[19:09] <asac> i dont think we should fix it
[19:09] <asac> the migration script would require either to replace xulrunner-1.9
[19:09] <micahg> well, that leaves people to recreate their apps
[19:09] <asac> sure
[19:10] <asac> we can ship a xulrunner-1.9 link in xulrunner-1.9.1
[19:10] <asac> thats all we can do
[19:10] <asac> but not before updates
[19:10] <micahg> let me see if that does it
[19:10] <micahg> but that's messy as well
[19:10] <micahg> as it builds on an initial bad practice
[19:11] <asac> yes. but messing with /usr/bin/xulrunner* is better to be done in a xulrunner package
[19:11] <asac> cant the user just edit the .desktop file?
[19:15] <micahg> yes
[19:15] <micahg> I'm testing your fix
[19:15] <micahg> anyways, I think I messed up a symlink in the package anyways
[19:16] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/prism/+bug/460860/comments/10
[19:17] <asac> micahg: i think we hsould keep it won't fix as i said in the bug
[19:17] <micahg> ok
[19:17] <asac> its inconvenient, but prism is a preview thing
[19:18] <micahg> I"ll test an edit workaround and post that in the bug
[19:18] <asac> thats great
[19:18] <asac> not sure if we put these workarounds for universe apps in release notes or somewhere
[19:18] <asac> i will check that
[19:19] <micahg> yeah, changing from xulrunner-1.9 to prism works
[19:20] <micahg> posted workaround
[19:24] <micahg> ok, about the clean up bug, there were some makefiles left after I added the stuff in bug
[19:26] <micahg> http://pastebin.com/d4c03c40d
[19:26] <asac> good
[19:26] <micahg> do I just add lines to remove those files in debian/rules?
[19:27] <asac> micahg: make distclean should remove most
[19:27] <asac> doesnt that do it?
[19:28] <micahg> idk
[19:28] <micahg> how do I run that?
[19:28] <asac> make distclean
[19:28] <micahg> where?
[19:28] <micahg> at the top level?
[19:29] <asac> i would think so
[19:29] <micahg> no make target
[19:29] <asac> not sure where it gets build
[19:29] <asac> but whatever is used to build it
[19:29] <asac> should be used to clean it
[19:29] <asac> maybe you removed the top level Makefile already?
[19:30] <asac> let me quickly build it
[19:30] <micahg> yeah
[19:30] <micahg> it's gone alreadt
[19:32] <asac> not sure why its gone for you
[19:32] <asac> try again
[19:32] <asac> ls Makefile
[19:32] <asac> Makefile
[19:32] <asac> thats after make clean
[19:47] <micahg> in / or in prism/
[19:50] <micahg> ugh, I'll see if I can fix 3.7 daily tonight
[19:55] <fta> lol, i'm playing with windows 7, just installed an inti-virus, it's talking to me :)
[19:55] <fta> and in french
[20:15] <micahg> asac: anything left to fix before release?
[20:16] <asac> yes. font problems ;)
[20:17] <micahg> I don't think I can fix that
[20:17] <asac> for release there is not much we can do on mozilla front
[20:18] <micahg> ok
[20:18] <micahg> does prism use b.m.o?
[20:18] <micahg> oh, I wanted to ask you about sqlite
[20:19] <asac> odd
[20:19] <micahg> does that have the possibility of breaking other apps
[20:19] <asac> didnt i file removal bugs for firefox-3.0
[20:19] <micahg> no, you transitioned it
[20:20] <asac> hmm
[20:21] <asac> are there still rdepends on xulrunner-1.9?
[20:21] <micahg> thught we fixed them
[20:21] <micahg> I haven't checked since I added the tasks to the supercede bug
[20:22] <micahg> according to the bug we got them all
[20:25] <micahg> I can do a final check alittle later
[20:25] <asac> hmm bfilter still depends on xulrunner-1.9
[20:26] <asac> mozilla-helix-player
[20:26] <asac> python-hulahop
[20:27] <micahg> asac: your bfilter upload was never pushed through
[20:27] <asac> hmm
[20:27] <urbanape> hey, asac. So, there's this dumb developer we have on staff named me.
[20:27] <asac> urbanape: sounds good :-P
[20:27] <asac> what is broken?
[20:27] <asac> ;)
[20:28] <asac> micahg: ok so ... what was that transition bug id?
[20:28] <micahg> bug 455517
[20:28] <micahg> also, helix-player depnds on www-browser
[20:28] <micahg> that's why I didn't report it
[20:28] <urbanape> fixed a silly typo and pushed it up. Since you mentioned before about cherry picking and so on, I wanted to check to see what would be better to do WRT versioning or tagging the branch.
[20:29] <asac> micahg: yes. but we should upload it i guess ... can you try if it builds at all with 1.9.1?
[20:29] <urbanape> https://code.edge.launchpad.net/~urbanape/bindwood/fix-lp461371/+merge/13986 is the merge proposal. It's fixed and pushed.
[20:29] <asac> helix that is
[20:30] <urbanape> should I propose that bug for targeting karmic as well?
[20:35] <asac> ok
[20:35] <asac> urbanape: what is the impact?
[20:35] <asac> its not clear from the bug
[20:36] <urbanape> with that typo in place, changes made locally to bookmarks (titles, URIs, &c) are not propagated to CouchDB.
[20:36] <asac> new additions not?
[20:36] <asac> i mean that works?
[20:36] <urbanape> new additions work properly.
[20:37] <asac> or everything but the first sync is b roken?
[20:37] <asac> ok
[20:38] <asac> micahg: apt-get source bfilter gives me the control with 1.9.1
[20:38] <asac> did that fail to biuld?
[20:38] <micahg> checking
[20:38] <micahg> yes :(
[20:38] <micahg> https://edge.launchpad.net/ubuntu/+source/bfilter/1.1.4-1ubuntu2/+build/1300661/+files/buildlog_ubuntu-karmic-i386.bfilter_1.1.4-1ubuntu2_FAILEDTOBUILD.txt.gz
[20:38] <urbanape> the event handler for when bookmarks change, though, will fail early on with an exception and the change isn't pushed.
[20:39] <asac> hmm
[20:39] <micahg> looks like an SPI change
[20:39] <micahg> *API
[20:40] <asac> yes
[20:40] <asac> javascript bustage
[20:40] <micahg1> I spun a test build of helix with xul-1.9.1
[20:40] <asac> good
[20:40] <asac> that worked?
[20:40] <micahg> waiting
[20:41] <asac> so bfilter .... hmm
[20:41] <asac> did debian port that yet?
[20:41] <micahg> I'll let you know about helix when the build is done
[20:41] <micahg> cehcking
[20:43] <micahg> debian had a depends on libmozjs1d
[20:44] <asac> yes
[20:44] <asac> ok
[20:44] <asac> so thats from xul 1.9.1?
[20:44] <asac> if so we should check what patch they added to bfilter
[20:44] <asac> ... if any
[20:45] <micahg> I don't know how it even built on debian
[20:45] <micahg> the latest I mean
[20:45] <micahg> packages are missing
[20:45] <micahg> they have libmozjs2d now
[20:54] <asac> yeah
[20:55] <asac> it probably wasnt built
[20:55] <asac> is 1.9.1 in unstable at all?
[20:55] <micahg> yes
[20:56] <micahg> as is xulrunner-dev
[20:56] <micahg> 1.9.1.3
[20:56] <asac> micahg: k
[20:56] <asac> micahg: so heix?
[20:56] <asac> helix ;)
[20:56] <micahg> still working
[20:56] <asac> want to paste a debdiff?
[20:56] <asac> ah
[20:56] <asac> ok
[20:57] <micahg> if it builds, I'll giv eyou the debdiff
[20:57] <asac> thanks
[20:57]  * micahg had to throw to ppa as I have no clean environment
[20:57] <asac> micahg: maybe paste it already so i can prepare and wai for your confirm
[20:57] <micahg> ok
[20:58] <asac> micahg: oh ... close that bug like i did in the other uploads
[20:58] <asac> i mean: rememberto close it ;)
[20:59] <micahg> I'll attach debdiff to bug
[20:59] <micahg> mark as patch?
[21:02] <micahg> debdiff attached to bug
[21:03]  * micahg used the debdiff tool for the first time :)
[21:11] <asac> micahg: what bug?
[21:11] <asac> i mean id ;)
[21:12] <asac> bug 455517
[21:13] <asac> ok
[21:13] <asac> so next is python-hulahop
[21:18] <asac> ok python-hulahop needs pyxpom
[21:18] <asac> thats not there anymore
[21:18] <asac> so hmm
[21:33] <asac> urbanape: no i uploaded it
[21:33] <asac> err ... "ok i uploaded it"
[21:33] <asac> its a cherry-pick merge
[21:33] <asac> so please take care that that branch gets merged into the trunk branh
[21:34] <asac> _without_modifications_
[21:34] <asac> otherwise i will get conflicts on next upstream merge in branch ;)
[22:22] <micahg> asac: helix had a nonrelated build error
[22:32] <micahg> asac: apparently helix and python 2.6.4 don't get along
[22:33] <urbanape> asac: again with the wonderful and the good and gentleman and all that. I'm keeping a running tally of beers owed at UDS
[22:38] <micahg> asac: helix is out of dayer
[22:38] <micahg> date
[22:38] <micahg> 2 years out of date
[22:38] <micahg> and is no longer in debian
[22:49] <asac> urbanape: haha ok. i will remember that
[22:50] <asac> urbanape: maybe i can upgrade from a beer to a whiskie ;)
[22:51] <urbanape> asac, we could do some serious damage to whiskey stocks in TX.
[22:51] <asac> odd
[22:51] <asac> hehe
[22:51] <asac> yeah
[22:51] <asac> micahg: helix failed again=
[22:51] <asac> that sucks
[22:51] <micahg> yeah, it also failed a month and a half ago during teh test rebuild
[22:51] <asac> it built here
[22:52] <micahg> do you have python-2.6.4rc2?
[22:52] <asac> no clue
[22:52] <asac> i have current python
[22:52] <asac> rc1
[22:52] <asac> 2.6.4~rc1-0ubuntu1
[22:52] <asac> ok lets file a removal request
[22:52] <asac> can you file the bug and i ack it and try to poke scottk
[22:52] <asac> etc.?
[22:53] <asac> xurl.cpp:864:6: error: #elif with no expression
[22:53] <asac> wait
[22:53] <micahg> well, ubuntu's kept it for 3 releases past debian, doesn't that mean we should fix it?
[22:53] <asac> thats the build failure
[22:53] <asac> thats a code bug
[22:53] <asac> and gcc 4.4 related
[22:54] <micahg> oh, I had a python - ribesome build error in my ppa
[22:54] <micahg> but I see that in the test rebuild
[22:54] <micahg> can you fix it
[22:54] <asac> 864
[22:55] <asac> i dont know
[22:55] <asac> what build failure are you seeing?
[22:55] <asac> i only se the elif without expression on builders
[22:55] <micahg> http://launchpadlibrarian.net/34429124/buildlog_ubuntu-karmic-amd64.helix-player_1.0.9-0ubuntu7~karmic~ppa1_FAILEDTOBUILD.txt.gz
[22:55] <micahg> TypeError: exceptions must be classes or instances, not str
[22:56] <micahg> so there are 2 problems now :(
[22:56] <asac> not sure why python is a different verison for you
[22:56] <asac> we have rc1
[22:56] <asac> i think
[22:56] <asac> your issue is amd64
[22:56] <asac> most likely a different problem yes.
[22:57] <micahg> same on i386
[22:57] <micahg> python-2.6minimal is rc2
[23:02] <asac> hmm
[23:02] <asac> ok
[23:02] <asac> i think we should remove it if its removed from debian
[23:02] <micahg> asac: ScottK was more inclined to fix it
[23:02] <micahg> I can't find the reason for removal upstream
[23:03] <micahg> and realplayer is popular
[23:03] <asac> hmm
[23:04] <asac> do you know how to fix it ;)?
[23:04] <asac> ok let me see what built here
[23:05] <micahg> no, but if I had a couple of days, I could build the new version :)
[23:05] <asac> new version?
[23:05] <asac> hmm
[23:05] <micahg> yeah realplayer 11 compatible
[23:06] <micahg> we've got the equivalent of 9 right now
[23:06] <asac> the problem is that we use py 2.6 on builders
[23:06] <asac> while it needs 2.4 i think
[23:06] <asac> that complain about strings not being valid in exceptions feels like a thing likely to happen in 2.6 which became stricter afaik
[23:07] <micahg> I can make a build dep on python2.4
[23:07] <micahg> hmm
[23:07] <asac> ok fixed hxurl.cpp
[23:07] <micahg> it's already got that
[23:07] <asac> lets see how far it gets now
[23:08] <asac> python: can't open file '/bin/pyar.py': [Errno 2] No such file or directory
[23:08] <asac> ok maybe it needs a full debian/rules build
[23:08] <asac> trying
[23:09] <asac> micahg: anyway. put latest helix on your todo for lucid ;)
[23:10] <micahg> ok
[23:10] <micahg> I can file a bug :)
[23:10] <asac> filed
[23:11] <asac> 461543
[23:11] <asac> bug 461543
[23:11] <micahg> should I assign to myself?
[23:11] <asac> platform/unix/unix_net.cpp:1772:10: error: #elif with no expression
[23:11] <asac> platform/unix/unix_net.cpp: In static member function ‘static HX_RESULT unix_net::get_host_by_name(char*, hostent*&)’:
[23:12] <asac> next bug
[23:12] <asac> micahg: already assign it ;)
[23:12] <asac> assigned
[23:12] <asac> ok one more build run
[23:12] <asac> lets see how far we get now
[23:13] <asac> so far ttwo #elif bugs fixed
[23:13] <asac> not yet seen your python thing
[23:13] <micahg> asac: you probably won't see it...it shouldn't happen in the PPA either as the build-deps is for python2.4
[23:13] <asac> it says its using python 2.6 here
[23:14] <micahg> weird
[23:14] <micahg> that's probably another bug we should look into at some point
[23:14] <asac> micahg: well. i think it needs to explicitl yset the python version
[23:14] <asac> somewhere
[23:15] <asac> the build depends is probably not enough
[23:15] <micahg> ok
[23:15] <asac> micahg: so why does the archive build fail different from your ppa build?
[23:15] <micahg> idk
[23:15] <asac> the archive thing failed similar to what i saw and fixed now
[23:16] <micahg> yeah, weird
[23:16] <micahg> idk
[23:16] <asac> i think it will finish here
[23:17] <asac> do you have a pbuilder where you could quick check if the debdiff i will do helps?
[23:17] <asac> but lets first wait
[23:17] <asac> guess takes 5 more minutes or so
[23:17] <asac> so bbib
[23:20] <fta> (i can share my script to easily create/manager pbuilders for different dists/arches)
[23:25] <micahg> fta: that would be great :)
[23:25] <micahg> I should set that up on my server
[23:25] <asac> ok try this debdiff
[23:26] <asac> debdiff helix-player_1.0.9-0ubuntu7.dsc helix-player_1.0.9-0ubuntu8.dsc  | pastebinit
[23:26] <asac> http://pastebin.com/f63989e9b
[23:27] <micahg> where should I try it?
[23:27] <asac> not sure ... locally ;)?
[23:28] <micahg> I just use patch to apply to the folder?
[23:28] <asac> micahg: yes apt-get source helix-player ... then cd hel*/
[23:28] <asac> patch -p1 < /tmp/debdiff.diff ;)
[23:29] <asac> download from pastebin
[23:29] <asac> dont copy paste
[23:29] <asac> that will bust
[23:29] <micahg> did that
[23:29] <micahg> changelog busted
[23:29] <asac> huh?
[23:29] <micahg> but that's ok
[23:29] <asac> thats your own?
[23:29] <asac> ok
[23:29] <asac> i used whatever i uploaded before i think
[23:29] <micahg> yeah
[23:29] <micahg> my fault
[23:30] <asac> ok
[23:30] <micahg> worked no
[23:30] <micahg> now
[23:30] <micahg> my funny ppa versions broke it ;)
[23:30] <asac> ok also pushhed to my ppa
[23:30] <asac> buildesr are empty
[23:30] <asac> so we should get results from there too soon
[23:31] <micahg> asac: also have bug 461006
[23:31] <fta> micahg, http://paste.ubuntu.com/302412/
[23:31] <micahg> I can;t confirm but bd murray did
[23:31] <asac> hmm i can start reader and mail
[23:32] <BUGabundo> http://code.google.com/p/chromium/issues/detail?id=21624
[23:32] <BUGabundo> this guys are totally lost!
[23:33] <micahg> asac: so can I
[23:33] <asac> https://edge.launchpad.net/~asac/+archive/ppa/+build/1310159
[23:34] <micahg> applying patch 90-fix-gcc4 to ./ ... failed.
[23:34] <micahg> make: *** [patch-stamp] Error 1
[23:34] <micahg> that's what I get locally
[23:35] <asac> hmm
[23:35] <micahg> pythonfailure
[23:35] <asac> dpatch is really my enemy no 1
[23:35] <asac> i did nothing wrong :/
[23:36] <asac> err it even builds here :/
[23:36] <micahg> I patched it twice, that's why I failed locally
[23:36] <asac> ah
[23:38] <micahg> ugh, still failed on that patch
[23:40] <asac> ok let me try fix umake to use python2.4
[23:41] <micahg> ok, now it seems to be working
[23:42] <micahg> locally at least
[23:42] <asac> well ... it always works for me locally ;)
[23:42] <asac> i will try to run umake with python2.4 explicitly now
[23:43] <asac> lets check if there are other explicitly python invokations tha we should fix
[23:44] <asac> ok that looks better ... lets try
[23:44] <asac> pushed to ppa again
[23:44] <asac> [#-00000001][2009-10-27 00:44:18][1075727472][INFO ] : Ribosome v2.4.8
[23:44] <asac> [#-00000002][2009-10-27 00:44:18][1075727472][INFO ] : Using Python v2.6.4-rc2
[23:44] <asac> so that might work ;)
[23:44] <micahg> that was the same as before
[23:45] <asac> hm
[23:45] <asac> strange ;)
[23:45] <asac> i run it with PYTHON = python2.4
[23:46] <asac> lets hope that just umake.py is broken
[23:46] <asac> thats run with python2.4 at least
[23:47] <micahg> we should know in 2.5 minutes :)
[23:47] <asac> yeah ... rounda bout
[23:47] <asac> builders are free
[23:47] <asac> which is kind of ingteresting
[23:47] <asac> last time during release freeze they were really busy
[23:47] <asac> as nothing goes in folks usually go to ppas ;)
[23:48] <micahg> maybe because of the late freeze, people got all their fixes in :)
[23:49] <asac> feels odd for me that this time freeze was later
[23:49] <asac> i mean ... it was always zero for stuff for main after RC
[23:49] <asac> but universe i thought i could upload till day before rleease iirc
[23:50] <asac> https://edge.launchpad.net/~asac/+archive/ppa/+build/1310173
[23:50] <asac> now its getting interesting
[23:50] <asac> umake is in action
[23:50] <asac> failed ;)
[23:51] <asac>   SDK named 'oggvorbissdk'. Please read documentation for instructions
[23:51] <asac>   on how to obtain and install this SDK.
[23:53] <asac> hmm libogg-dev
[23:53] <asac> lets check that ;)
[23:53] <asac> not hats not it