[00:00] <fta> asac, we were supposed to discuss the ppa reorg today :P
[00:05] <fta> asac, bug 243344, grrrr. tons of dupes, filed 1.5y ago, no one cared :(
[01:13] <micahg1> fta: asac: I realized yesterday after I went offline it was probably comm-central branching that caused the issues with tb3
[01:15] <fta> micahg, it was, i said so yesterday, i fixed 3.0 and created a new 3.1 branch
[01:16] <micahg> so, what is 3.0 dailiy pointing at now?
[01:17] <fta> comm-1.9.1
[01:18] <micahg> ok, are you going to make a 3.1 daily?
[01:19] <fta> probably
[01:19] <micahg> ok, are you going to be on much longer?
[01:19] <fta> nope, it's late
[01:20] <micahg> ok, fine, just wondering whether I should work on Prism now or a little later :)
[02:07] <ripps> hrm... bottom extension toolbar is missing chromium-daily...
[04:20] <micahg> asac: help...xpi.mk is driving me nuts
[08:00] <eagles0513875> morning
[11:12] <micahg> asac asac_ up yet?
[11:34] <micahg> hi asac__
[11:37] <av`> micahg, it's sunday, asac won't be here till evening / night
[11:37] <av`> he's just lagging
[11:37] <micahg> he said he would be here
[11:37] <micahg> I was trying to finish up prism
[11:38] <micahg> but had some issues with m-dev
[11:38] <av`> strange, he's usually away sunday morning
[11:38] <av`> which issues?
[11:38] <micahg> prism won't build :)
[11:38] <av`> paste me the error
[11:38] <micahg> ok, I just restored the orirginal m-dev
[11:38] <micahg> I"m building now
[11:39] <av`> k
[11:39] <asac__> hey
[11:39] <micahg> hi
[11:39] <av`> micahg, you were right :)
[11:39] <micahg> xpi.mk was driving me crazy
[11:39] <asac__> hmm
[11:39] <asac__> micahg: didnt the thing work?
[11:40] <asac__> i mean common-post-build-arch .... or wahtever i said?
[11:40] <micahg> oh, btw, ScottK wanted to know if anything needs to be done for bug 217908
[11:40] <micahg> yeah, that wasn;t the issue
[11:40] <asac__> what wasnt the issue?
[11:40] <av`> asac__, I mailed linux-bluetooth ML at kernel.org and they said me using udev to fix the rfkill thing it's really bad and shouldnt be done
[11:40] <micahg> changing to what you said
[11:40] <asac__> the refractor.xpi:: rule was clearly wrong
[11:40] <av`> asac__, that's why rfkill is disabled for normal users
[11:41] <micahg> the problem seem to be wildcard (MOZ_XPI_FILE) doesn't resolve
[11:41] <micahg> at least the first problem
[11:41] <asac__> av`: well... you can do whatever you want in debian
[11:41] <micahg> http://pastebin.ubuntu.com/301253/
[11:41] <asac__> av`: its a temporary workaround as i said
[11:41] <av`> asac__, there should be a plan to build a rfkilld but who knows when it will be done, in the meantime I need to find out a working thing to do
[11:41] <asac__> bluez will get rfkill support
[11:42] <asac__> and then it can go away
[11:42] <av`> asac__: the patch should be applied to bluez itself not gnome-bluetooth
[11:42] <asac__> thats what i explained yesterday
[11:42] <asac__> no
[11:42] <asac__> there is not patch for bluez
[11:42] <asac__> wlel you can put it in bluez
[11:42] <asac__> but i have no strong opinion ;)
[11:42] <av`> don't misunderstand me, I meant bluez needs to be fixed
[11:42] <av`> not gnome-bluetooth
[11:42] <asac__> go ahead and do it
[11:43] <asac__> or wait till bluez upstream does it
[11:43] <asac__> and gnome-bluetooth gets fixed to use that then new dbus api
[11:43] <asac__> ;)
[11:43] <micahg> asac, this is the line that doesn't seem to work http://pastebin.ubuntu.com/301253/
[11:43] <micahg> oops XPI_FILE = $(wildcard $(MOZ_XPI_FILE))
[11:43] <av`> asac__, actually I wanted to use your workaround but the other maintainer stopped me from doing it
[11:43] <micahg> the pastebin is the end of the build
[11:43] <asac__> micahg: what diff did you do?
[11:43] <asac__> micahg: point is that you rannot use refractor.xpi:: rule anymore
[11:43] <asac__> that doesnt get called at all
[11:44] <asac__> it was called in older mozilla-devscripts
[11:44] <av`> asac__, cause some developers at linux-bluetooth wrote that it's the wrong thing to do, but my question is: why they say it's wrong to do and they don't provide a patch to have it fixed asap?
[11:44] <asac__> av`: its understood that its the wrong thing to do
[11:44] <micahg> asac: http://bazaar.launchpad.net/~micahg/prism/prism-1.0b2-karmic/revision/117
[11:44] <asac__> av`: i told you yesterday
[11:44] <asac__> so you didnt get any new info
[11:44] <av`> asac__, yeah, but the problem here is how long will it take upstream to implement that^
[11:45] <asac__> but its the only feasible thing to do atm
[11:45] <asac__> until its fixed
[11:45] <av`> we can't leave that thing for ages, so it would be nice to know upstream's roadmap for it
[11:45] <asac__> it will ge tdone
[11:46] <asac__> we discussed it all when we added it
[11:46] <asac__> its on roadmpa ... or even already in bluez
[11:46] <asac__> you can check
[11:46] <asac__> micahg: maybe you still need the zip -d?
[11:47] <asac__> thta produced the .xpi in the past
[11:47] <asac__> thought it woudl do that automatically
[11:47] <micahg> no, the XPI is there
[11:47] <micahg> this line isn't working XPI_FILE = $(wildcard $(MOZ_XPI_FILE))
[11:47] <micahg> if I take out the wildcard, it gets to the next step
[11:48] <asac__> micahg:
[11:48] <asac__> ifneq (,$(MOZ_XPI_FILE))
[11:48] <asac__> XPI_FILE = $(wildcard $(MOZ_XPI_FILE))
[11:48] <asac__> else
[11:48] <asac__> XPI_FILE = $(wildcard *.xpi)
[11:48] <asac__> endif
[11:48] <asac__> thats only used if you specify MOZ_XPI_FILE
[11:49] <asac__> which yo dont, right?
[11:49] <micahg> that is specified
[11:49] <asac__> that shouldnt
[11:49] <av`> asac__, yeah, I hope so, kernel 2.6.31 is in NEW now so gnome-bluetooth will rock now on debian as well
[11:49] <asac__> thats why we moved it to common now
[11:49] <av`> asac__, the last thing that needs fixing is the rfkill thing
[11:49] <micahg> asac, so this line I get rid of: MOZ_XPI_FILE            := refractor.xpi
[11:49] <av`> asac__, are the patches you applied the ones taken from the new upstream release?
[11:49] <asac__> av`: do what we did
[11:50] <asac__> av`: no i didn them before ... then he did it on his own
[11:50] <asac__> they are more or less equivalent
[11:50] <asac__> but i have to rebase them to say if anything is left
[11:50] <asac__> the leak is probably still left
[11:50] <av`> asac__, I wanna keep in sync debian's package with ubuntu
[11:50] <asac__> but also he took some other approach ... so not sure
[11:50] <av`> so we don't diverge it
[11:50] <asac__> currently we are ahead
[11:50] <av`> we have 2.28.3
[11:50] <asac__> so you can just upload the ubuntu package
[11:51] <asac__> then its your decision
[11:51] <av`> and ubuntu has 2.28.1
[11:51] <asac__> i wont check for debian stuff on my own :)
[11:51] <asac__> av`: yes. but because you bumped th eversion
[11:51] <asac__> so add the .rules file
[11:51] <av`> asac__, the 2.28.3 release integrates the crash fixes you applied I guess
[11:52] <av`> so apart the .rules thing it's the same
[11:52] <asac__> i said something different above
[11:52] <asac__> 12:50 < asac__> but i have to rebase them to say if anything is left
[11:52] <asac__> 12:50 < asac__> the leak is probably still left
[11:52] <asac__> 12:50 < asac__> they are more or less equivalent
[11:52] <asac__> 12:50 < asac__> but i have to rebase them to say if anything is left
[11:52] <asac__> 12:50 < asac__> the leak is probably still left
[11:52] <micahg> asac: commenting out MOZ_XPI_FILE didn't help
[11:52] <av`> yeah, but you'll have to adapt them to the latest release anyway
[11:52] <av`> they are taken from the gnome svn
[11:52] <asac__> micahg: remove it
[11:52] <micahg> that wildcard command seems to be the issue
[11:53] <av`> so they should be into the latest snapshot already
[11:53] <asac__> micahg: without MOZ_XPI_FILE it should use the other wildcard
[11:53] <asac__> $(wildcard *.xpi)
[11:53] <asac__> that should definitly work
[11:53] <av`> but it's worth to give it a check
[11:53] <asac__> you just repeat what i said three times already
[11:53] <micahg> nope
[11:53] <asac__> i need to rebase them to check what is left
[11:53] <asac__> thats it
[11:53] <av`> yep :)
[11:54] <asac__> i said that exactly that 4 times ;)
[11:54] <micahg> asac__ no go
[11:54] <asac__> micahg: well. how does it fail now
[11:54] <micahg> same
[11:54] <micahg> wildcard doesn't seem to expand
[11:54] <av`> asac__, I gonna start doing stuff for the desktop-team with lucid
[11:54] <asac__> hmm
[11:54] <micahg> when I changed wildcard MOZ_XPI_FILE to just MOZ_XPI_FILE it got further
[11:55] <asac__> av`: not sure what you mean ...
[11:55] <av`> asac__, e.g updating gnome stuff, merges, syncs like I do for the debian team
[11:55] <asac__> micahg: where does that stop then?
[11:56] <asac__> no
[11:56] <asac__> i dont like gnome stuff
[11:56] <asac__> well
[11:56] <asac__> there are neough folks doing that
[11:56] <asac__> some packages i do
[11:56] <asac__> like epiphany, etc.
[11:56] <av`> asac__, seb told me the team requires some help
[11:56] <asac__> but synching and merges are easy enough ... so usually the gnome team can cover that
[11:57] <asac__> could be. but not my help ;)
[11:57] <asac__> i mean ... everyone needs help
[11:57] <asac__> i need help too
[11:57] <micahg> indeed
[11:57] <asac__> micahg: how does it fail when yo drop the wildcard?
[11:57]  * micahg is learning to help :)
[11:57] <asac__> micahg: you are helping a lot
[11:57] <micahg> asac__ rebuilding now :)
[11:58] <micahg>  No rule to make target `install-refractor.xpi-stamp', needed by `xpi-install'
[11:58] <av`> asac__, actually I saw tons of uploads made by robert
[11:58] <micahg> it doesn't seem to expand the %
[11:58] <asac__> av`: yes. he is sebs helper
[11:58] <av`> asac__, so I guess that he can't do everything alone with seb
[11:59] <asac__> why do you discuss that with me ;)
[11:59] <asac__> there surely is need for more folks helping out
[11:59] <av`> asac__, you said before '<asac__> there are neough folks doing that'
[11:59] <asac__> seb and me and a few others work more like 14h a day in average ;)
[11:59] <asac__> yes. there are enough folks so i dont need to drop my other work and help our there
[11:59] <av`> so I thought that means no help is required
[11:59] <asac__> out there
[11:59] <micahg> asac freeze in 10 seconds...
[12:00] <asac__> freeze?
[12:00] <micahg> universe freeze
[12:00] <asac__> ah
[12:00] <asac__> ok
[12:00] <micahg> ScottK said we could fudge a little
[12:00] <asac__> i think it shouldnt be a problem
[12:00] <micahg> but what do you think of that next error I posted
[12:01] <av`> asac__, I'm seeing you a bit nervous today, slept bad?
[12:01] <asac__> micahg: i think unzip-%-stamp: $(XPI_FILE)
[12:01] <asac__> didnt work
[12:01] <asac__> micahg: are you sure there is a .xpi on top level dir?
[12:01] <micahg> yes
[12:02] <asac__> av`: i dont see me nervous :)
[12:02] <micahg> I see refractor.xpi in the top dir
[12:03] <asac__> yeah
[12:03] <asac__> let me check it. have absolutely no idea from here what it could be
[12:04]  * asac__ branches micah branch
[12:05] <asac__> odd the version in changelog does not match the version produced by get-orig-source
[12:05] <micahg> yess
[12:06] <asac__> feels like moz-devscripts is wrong there
[12:06] <micahg> that's a problem with svn devscript maybe?
[12:06] <asac__> i mean the version
[12:06] <micahg> I changed it to 1.0~b2
[12:06] <asac__> it should produce 1.2~b... and not 2b
[12:06] <av`> asac__, how can I avoid this: https://buildd.debian.org/fetch.cgi?&pkg=gnome-bluetooth&ver=2.28.3-1&arch=ia64&stamp=1256303819&file=log
[12:06] <asac__> yeah
[12:06] <av`> asac__, it fails to build on ia64 cause of that
[12:06] <av`> asac__, e.g missing network
[12:06] <micahg> asac, also get-orig-source failed until I made the dir
[12:07] <asac__> how anoying ;) ... why does debian use https for that? ;)
[12:08] <asac__> av`: usually thats done using some catalog file
[12:08] <asac__> av`: the current build seems to need network access
[12:08] <asac__> which is bad
[12:08] <av`> asac__, is there a way to fix that?
[12:09] <asac__> i havent used xsltproc lately, but other xml/xslt things can use a catalog file so they dont try to lookup stuff remotely
[12:09] <asac__> question is why it works on other buildds
[12:09] <av`> yeah :)
[12:09] <asac__> i dont know that
[12:09] <asac__> maybe xsltproc is OK with a "no net" error,
[12:09] <asac__> but not if its a HTTP error like that
[12:10] <asac__> check with the ia64 porters
[12:10] <asac__> this could be a buildd bustage
[12:10] <asac__> at least if you are sure
[12:10] <av`> it built fine on ubuntu
[12:10] <av`> ia64
[12:10] <asac__> that it works on other buildds its likely a buildd configuration that is different
[12:10] <asac__> av`: not sure. do we produce those docs?
[12:10] <asac__> in ubuntu?
[12:11] <asac__> if we do  then yes.
[12:11] <asac__> try to find the owner of those machines and bug him ;)
[12:11] <micahg> cool, debian is fixing secure delete in sqlite
[12:11] <asac__> good
[12:11] <av`> asac__, problem is pkern is now filing an RC bug against my package
[12:11] <av`> cause it shouldnt require network access
[12:11] <av`> but why it works everywhere and fails there
[12:14] <asac__> yes. network-access is probably bad
[12:14] <asac__> i agree with that
[12:14] <asac__> but as i said
[12:14] <asac__> maybe it has no problem if ther eis no net
[12:15] <asac__> but has a problem if there is some kind of net
[12:15] <asac__> that gives bogus stuff
[12:15] <asac__> like here
[12:15] <asac__> so it could be that the problem is that the ia64 builder has a bad network setup
[12:15] <asac__> av`: you can easily test ... tear down all your network
[12:15] <asac__> and see if it works
[12:15] <asac__> if so, its a ia64 buildd setup problem imho
[12:16] <av`> you're right
[12:16] <av`> I should test if it builds
[12:16] <av`> without network
[12:16] <asac__> micahg: so with refractor.xpi being in place at the start it works
[12:16]  * av` grabs the sources
[12:16] <micahg> what, how?
[12:16] <asac__> micahg: try a debuild -b ... then after the fail, run debuild -nc -> success
[12:17] <asac__> so problem really is that the XPI_FILE thing gets somewhat evaluated too early
[12:17] <av`> asac__, brb, shutting down my network
[12:17] <asac__> the odd thing is that it works for things that specify a build command
[12:18] <asac__> like all the other extension packages
[12:18] <micahg> asac__:  is there a pre-build arch?
[12:18] <asac__> so $(wildcard file.xpi) -> empty if that file doesnt exist yet
[12:18] <asac__> but it doesnt exist for other extenion packages
[12:18] <asac__> micahg: touching a file would be a hack. and we dont do that for other packages
[12:19] <asac__> i think the only difference is that we have no build command
[12:19] <micahg> I'm saying, can we move the copy up?
[12:20] <micahg> ok, I'm testing installing now
[12:21] <asac__> micahg: no ... refractor.xpi gets produced during build
[12:21] <asac__> so its not there in pre-build::
[12:21] <asac__> or something
[12:21] <asac__> you can run a touch refractor.xpi there most likely
[12:21] <asac__> ;)
[12:21] <asac__> but thats  a hack
[12:22] <asac__> ok trying something
[12:22] <av`> asac__, builds fine *without* network access ;)
[12:23] <micahg> well, the.debs seem to work
[12:23] <asac__> av`: ok then setup a proxy on that host that gives you HTTP/1.1 504 Gateway Time-out
[12:23] <micahg> although the window might not be wide enough
[12:23] <av`> asac__, a proxy that doesnt work then
[12:24] <asac__> av`: e.g. setup a host with http proxy, but no other network
[12:24] <asac__> yeah. i think setting up a proxy on localhost
[12:24] <av`> k
[12:24] <asac__> and then tearing donw the network will give that timeout
[12:24] <asac__> and i expect that xsltproc will then baild out
[12:24] <asac__> because it gets a real http error
[12:24] <asac__> rather than a network error
[12:24] <av`> done
[12:25] <av`> closing down network
[12:25] <av`> brb
[12:25] <asac__> av`: if you run wget http://www.google
[12:25] <asac__> you get the same error
[12:25] <asac__> then you are ready for test
[12:25] <asac__> bdrung: there?
[12:25] <bdrung> asac: yes
[12:26] <asac__> any clue why XPI_FILE gets evaluated early for prism, but late for all the other stuff?
[12:26] <asac__> e.g. for prism its always empty
[12:26] <asac__> prism has a NULL build command
[12:26] <asac__> thats the only difference i can see
[12:26] <bdrung> do you have a link to the sources?
[12:27] <asac__> http://bazaar.launchpad.net/~micahg/prism/prism-1.0b2-karmic/revision/117
[12:27] <asac__> bdrung: you want a full tree that you can debuild?
[12:27] <asac__> let me get that for you
[12:27] <bdrung> that would be nice
[12:28] <micahg> tarball here: https://edge.launchpad.net/~micahg/+archive/mozilla-test/+files/prism_1.0~b2+svn20090813r49078.orig.tar.gz
[12:28] <asac__> http://people.canonical.com/~asac/tmp/pp.tar.gz
[12:28] <asac__> hmm
[12:28] <asac__> ok
[12:28] <asac__> the pp.tar.gz is a build tree you can use for debuid -.b
[12:29] <asac__> bdrung: so only difference i see is BUILD_COMMAND=0 ...with using common-post-build-arch to do that
[12:29] <av`_> asac__, it built fine anyway
[12:30] <av`_> it worked with a proxy as well
[12:30] <av`> going to eat, brb
[12:30] <micahg> asac, while he's looking into that, can you see if anything needs to be done with bug 217908 before release?
[12:30] <asac__> k
[12:31] <asac__> that should clearly happen upstream
[12:31] <micahg> yeah, and upstream still seems to be working on it
[12:31] <asac__> exactly. so the story here is that the fix only works with most recent X server
[12:32] <micahg> which is fine for karmic, right?
[12:33]  * bdrung builds it now.
[12:34] <micahg> I'll let ScottK know
[12:35] <asac__> once upstream issue landed on trunk
[12:36] <asac__> i can at least think about trying to cherry pick that here
[12:36] <asac__> but before that its tough ;)
[12:37] <micahg> so, it's not blocking release is it?
[12:43] <asac__> no
[12:43] <micahg> ok
[12:43] <asac__> is a visual glithc
[12:43] <micahg> asac, I have one more big bug you should look at: bug 453616
[12:43] <micahg> Is the problem with synaptic?
[12:44] <micahg> aptitude properly suggests the install
[12:44] <asac__> workd for ms
[12:44] <asac__> me
[12:44] <micahg> in synaptic?
[12:45] <asac__> i would think its a old bug
[12:45] <asac__> hmm
[12:45] <asac__> when did i do th elast firefox update?
[12:45] <micahg> when I marked abrowser for installation, it didn't work
[12:45] <micahg> last week?
[12:45] <micahg> I just tested it an hour ago
[12:45] <asac__> yeah
[12:45] <micahg> with the latest updates
[12:45] <asac__> so thats where i fixed a few abrowser issues
[12:45] <asac__> hmm
[12:45] <asac__> sudo apt-get install abrowser-3.5 works
[12:45] <asac__> sudo apt-get install abrowser works
[12:46] <micahg> yes, but the bug was reported with using synaptic
[12:46] <micahg> SHould I move to synaptic and subscibe mvo?
[12:46] <asac__> micahg: does apt-get work for you too?
[12:46] <asac__> e.g. just try to run it and see if it complains or would allow it
[12:46] <bdrung> asac: the common-post-build-arch produces this issue. workaround: "MOZ_XPI_FILE		:= dist/xpi-stage/refractor.xpi"
[12:46] <micahg> no
[12:47] <micahg> sudo apt-get install abrowser fails
[12:47] <bdrung> asac: fyi the clean rules does not clean enough
[12:47] <asac__> right
[12:47] <asac__> so thats working for me
[12:47] <asac__> and synaptic too
[12:47] <micahg> weird
[12:47] <asac__> micahg: what packages do you have instlaled?
[12:47] <asac__> dpkg -l firefox\*
[12:48] <micahg> http://pastebin.com/f4d222bc3
[12:57] <asac__> micahg: what is the exact error?
[12:57] <asac__> if you run apt-get install ...
[12:58] <asac__> bdrung: why does it the early evaluation happen if we have common-post?
[12:58] <asac__> and why would the $(wildcard dist/xpi-stage/refractor.xpi) be not empty?
[12:58] <asac__> oh ... did we hook up the stuff in common-post ?
[12:59] <asac__> hmm
[12:59] <asac__> then we can probably also do it in build/prism::
[12:59] <micahg> testing build in ppa
[12:59] <micahg> asac http://pastebin.com/f312e6403
[13:00] <micahg> pastebin is for abrowser
[13:00] <asac__> micahg: try apt-get install abrowser-3.5-branding and see what that gives you
[13:00] <micahg> ah
[13:01] <micahg>  abrowser-3.5-branding: Depends: firefox-3.5 (= 3.5.3+build1+nobinonly-0ubuntu2) but 3.5.3+build1+nobinonly-0ubuntu6 is to be installed
[13:01] <micahg> because I have the security PPA enabled I think
[13:01] <micahg> at 501
[13:01] <asac__> micahg: maybe some pinning?
[13:01] <micahg> yeah
[13:02] <asac__> ok ... probably means that the pinned archive doesnt have that trantiion
[13:02] <asac__> transition
[13:02] <asac__> so it it security? or somehting else that is pinned to ubuntu2?
[13:02] <micahg> no, it has abrowser
[13:02] <asac__> micahg: so yeah
[13:03] <micahg> testing
[13:04] <asac__> http://pastebin.com/f22dbabc7
[13:04] <asac__> thats what i would suggest for prism
[13:04] <asac__> currently trying
[13:05] <micahg> oh
[13:05] <micahg> I changed MOZ_XPI_FILE as bdrung suggested and then got rid of the cp command
[13:05] <asac__> seems that the evaluation of XPI_FILE is somewhat hooked into the common-post
[13:05] <asac__> i would think the build/... is better
[13:06] <asac__> as its better suitable as an example
[13:06] <micahg> ok
[13:06] <asac__> for other packages that dont have a build command
[13:07] <micahg> trying again...
[13:09] <asac__> micahg: so is the abrowesr issue gone with all up-to-date?
[13:09] <micahg> didn't test that yet
[13:09] <asac__> kk
[13:09] <micahg> had to upload new version of prism :)
[13:09] <asac__> micahg: imo the bug was fixed
[13:09] <asac__> it was
[13:09] <asac__> https://edge.launchpad.net/ubuntu/+source/firefox-3.5/3.5.3+build1+nobinonly-0ubuntu6
[13:09] <micahg> no
[13:09] <micahg> abrowser branding was fixed
[13:10] <asac__> hmm
[13:10] <micahg> abrowser wasn't
[13:10] <micahg> The following packages have unmet dependencies:
[13:10] <micahg>   abrowser: Depends: abrowser-3.5-branding but it is not going to be installed
[13:10] <micahg> E: Broken packages
[13:10] <asac__> but apt-get install abrowser-3.5-branding works?
[13:10] <micahg> yes
[13:10] <asac__> thats strange
[13:10] <micahg> ugh
[13:10] <micahg> and it wanted to pull in sobgbird
[13:10] <micahg> songbird
[13:11] <asac__> i mean ...why would that happen? if abrowser-3.5-branding installs fine, then abrowser depends on abrowser-3.5-branding should be fulfillable
[13:11] <micahg> right
[13:11] <micahg> and they are the same version now
[13:11] <micahg> with the same priority
[13:12] <asac__> micahg: sudo apt-get -oDebug::pkgProblemResolver=1 install abrowser
[13:12] <asac__> thry that
[13:12] <asac__> and paste
[13:12] <asac__> maybe that has hints why its rejected as a good solution
[13:12] <asac__> might be that something only depends on firefox or something
[13:13] <asac__> but not sure why it would complain abour -branding ... so lets look at the solver output
[13:13] <micahg> http://pastebin.com/d484b2913
[13:15] <asac__> micahg: maybe some extension directly depends on firefox or something, but not on abrowser?
[13:15] <asac__> which makes it too costy?
[13:17] <micahg> ugh
[13:17] <micahg> firefox-launchpad-plugin  depends on firefox
[13:18] <asac__> yeah
[13:18] <asac__> i think thats the cause then
[13:18] <asac__> probably should go through all that depend on firefox directly
[13:18] <micahg> but doesn't abrowser provide firefox?
[13:18] <asac__> yeah
[13:18] <asac__> we would need to ask mvo
[13:18] <asac__> how the decision is done in this case
[13:19] <asac__> maybe abrowser-3.5-branding should provide firefox-3.5-branding  ... hmmm
[13:19] <micahg> ok, prism seems to build fine
[13:20] <asac__> so firefox stuff is not going to be fixed for release .... we should fix that in first sru/sec update
[13:21] <asac__> not sure if a provides is what we want
[13:21] <asac__> we want users to be able to go back and forth by installing -branding
[13:21] <asac__> and the main packages
[13:21] <asac__> e.g. abrowser-3.5 .... abrowser
[13:21] <asac__> micahg: does apt-get install abrowser-3.5 work?
[13:21] <micahg> medium -> Triaged -> you?
[13:22] <asac__> yeah. i think so
[13:22] <micahg> testing prism install now
[13:22] <asac__> post the paste stuff you have me there too
[13:22] <asac__> thcx
[13:22] <asac__> th
[13:22] <asac__> x
[13:22] <micahg> all that debug?
[13:22] <asac__> yes
[13:23] <asac__> i want mvo to take a look
[13:23] <BUGabundo> asac both kernel .15 and .32.x don't fix my 3G bug
[13:23] <BUGabundo> at least not out of the box
[13:23] <BUGabundo> dtchen: latest PA has regressed to me. now it starts muted again :(
[13:23] <micahg> no, asac abrowser-3.5 didnt' work either
[13:24] <asac__> ok ... paste both debugs
[13:24] <asac__> also the debug for installing the -branding
[13:24] <asac__> (which works)
[13:24] <asac__> and post that firefox-lp-improvements only depends on firefox
[13:24] <micahg> no, it was the launchpad-plugin
[13:25] <asac__> yeah then that ;)
[13:27] <av`> asac__, http://bugs.debian.org/552307
[13:31] <av`> asac__, I commented out that this is not a package's issue
[13:32] <av`> and I decreased severity since it makes the package unable to reach testing
[13:32] <av`> for what? for a buildd issue
[13:34] <asac__> av`: ansewered
[13:34] <asac__> i commented giving rational why i think its a buildd bustage +  wishlist bug against the xml parts used
[13:35] <asac__> micahg: so is prism ok?
[13:35] <av`> asac__, thanks :)
[13:35] <micahg> seems to be
[13:35] <asac__> micahg: have you tried to use it?
[13:35] <asac__> like making a webapp out of a website in ffox?
[13:35] <micahg> I'm browsing in it
[13:35] <asac__> ok
[13:35] <micahg> using the google mail app
[13:35] <asac__> and the ffox plugin is good?
[13:35] <asac__> micahg: try to create a new webapp
[13:35] <asac__> in ffox
[13:35] <micahg> haven;t tried that
[13:35] <asac__> thats what the plugin is supposed to allow you
[13:35] <asac__> err extension ;)
[13:35] <micahg> didn't know we had it
[13:37] <micahg> got an icon conversion error on lp
[13:38] <asac__> micahg: so failed completely? or just icon is defualt?
[13:38] <micahg> icon is default
[13:38] <micahg> it works
[13:38] <asac__> ok try somem other site
[13:38] <asac__> maybe some works
[13:38] <asac__> i think thats an upstream bug then
[13:38] <asac__> and shouldnt block it
[13:39] <asac__> so maybe check what bdrung ment by saying that clean isnt clean ... and close changelog
[13:39] <asac__> so i can sponsor and poke scottk
[13:39] <micahg> cnn's favicon worked
[13:39] <asac__> good
[13:39] <asac__> so feels ready
[13:39] <asac__> if you see what is not clean maybe fix that
[13:39] <micahg> hold on I have to push up latest bze
[13:39] <asac__> but isnt that important
[13:39] <asac__> micahg: ok.
[13:40] <micahg> flash even seems to work :)
[13:42] <asac__> great ;)
[13:43] <micahg> ok, should I propose a merge?
[13:43] <asac__> micahg: you can do that. yes. or i can just push the branch
[13:44] <asac__> micahg: do you have the FFe bug closed in changelog?
[13:44] <BUGabundo> now that you mention it
[13:44] <asac__> if so, just push and i will take care for the rest
[13:44] <BUGabundo> I should upgrad my flash
[13:44] <asac__> probably is late
[13:44] <micahg> yes
[13:44] <micahg> I pushed up to my branch
[13:44] <micahg> was about to propose a merge
[13:44] <asac__> micahg: thanks a lot for your work. i will upload after shower, dont think you need to stay awake longer :)
[13:45] <micahg> ok
[13:45] <asac__> micahg: you had identica account?
[13:45] <micahg> do I need to propose a merge?
[13:45] <asac__> micahg: if you like ...
[13:45] <asac__> not necessarily as i know that i have to do that right now
[13:45] <micahg> no, no identica
[13:45] <micahg> do I need one?
[13:45] <asac__> no
[13:46] <asac__> wanted to refer to you when saying that prism was fixed
[13:46] <asac__> will just use your name then ... and not a linked account ;)
[13:46] <asac__> thx
[13:46] <asac__> or twitter?
[13:46] <asac__> ;)
[13:46] <BUGabundo> micahg: you are not on identica?
[13:46] <micahg> ok, np, thanks for helping me with this
[13:46] <micahg> no
[13:46] <BUGabundo> or the StatusNet network?
[13:46] <asac__> welcome
[13:46] <micahg> micahg on lp is fine :)
[13:46] <BUGabundo> shame :)
[13:46] <asac__> micahg: just close changelog with relesae commit
[13:46] <asac__> and push up
[13:46] <asac__> and i will take care of the rest
[13:47] <asac__> tty tomorrow
[13:47]  * asac__ heads for shower
[13:47] <micahg> oh, I didn't set it for karmic release
[13:47] <micahg> but I did mark the bugs closed
[13:49]  * micahg needs to go collapse in bed :)
[13:50] <BUGabundo> fta: can you so some renaming on gwibber?
[13:50] <BUGabundo> s/laconi.ca/StatusNet/ ?
[13:52] <fta> ?
[13:53] <fta> what does that mean? can I "so some renaming on xx"?
[14:03] <fta> asac, grrrr bug 460069
[14:04] <BUGabundo> fta: https://bugs.launchpad.net/gwibber/+bug/419817
[14:04] <fta> asac, not branch review, not branch at commit at all
[14:04] <fta> -at
[14:05] <fta> BUGabundo, asac is the gwibber master now
[14:05] <BUGabundo> :\
[14:05] <asac__> BUGabundo: whats the problem?
[14:05] <asac__> i am doing the upstream work, so if its upstream issue let me know with a bug :)
[14:06] <BUGabundo> asac: https://bugs.launchpad.net/gwibber/+bug/419817
[14:06] <BUGabundo> commited but not fixed
[14:06] <BUGabundo> for weeks now :(
[14:06] <asac__> BUGabundo: everything tahts committed should be fixed because we release from trun
[14:06] <asac__> k
[14:06] <asac__> unless its in a branch
[14:07]  * asac__ checks
[14:07] <BUGabundo>   Installed: 2.0.0~bzr476-0ubuntu1
[14:07] <BUGabundo>  *** 2.0.0~bzr476-0ubuntu1 0
[14:07] <BUGabundo>         500 http://archive.ubuntu.com karmic/universe Packages
[14:07] <BUGabundo>      2.0.0~bzr473-0ubuntu2~daily1 0
[14:07] <BUGabundo>         500 http://ppa.launchpad.net karmic/main Packages
[14:07] <asac__> yea
[14:07] <asac__> let me check code
[14:15] <asac__> ok prism uploaded
[14:16] <asac__> BUGabundo: i am not 100% if renaming the name would wipe your settings etc.
[14:16] <asac__> you can try that by bzr branch lp:gwibber ...
[14:16] <asac__> then change the name in microblog/laconica.py
[14:16] <BUGabundo> ok
[14:16] <asac__> and killall gwibber-daemon gwibber
[14:16] <asac__> and start them like ./bin/gwibber-daemon
[14:16] <asac__> and ./bin/gwibber
[14:16] <asac__> let me know if that worked
[14:16] <BUGabundo> right I know
[14:16] <asac__> and didnt loose your setting
[14:16] <asac__> for laconica
[14:17] <asac__> as a second thing you could try to rename laconica.py to statusnet.py
[14:17] <asac__> and see if thta works similar good
[14:17] <BUGabundo> ehe
[14:17]  * BUGabundo checking out
[14:18] <asac__> you need to change laconica -< statusnet in __init__.py in microblog too to check that
[14:18] <asac__> (e.g. the rename of .py)
[14:19] <asac__> like
[14:19] <asac__>   "identica": identica,
[14:19] <asac__> -<
[14:19] <asac__> ->
[14:19] <asac__>   "identica": identica,
[14:19] <asac__> urgh
[14:19] <asac__> i mean
[14:19] <BUGabundo> LOL
[14:19] <BUGabundo> calm down
[14:19] <asac__> "laconica": laconica,
[14:19] <asac__> ->
[14:19] <asac__> "laconica": statusnet
[14:19] <asac__> if that work
[14:19] <asac__> you can also try
[14:19] <asac__> "statusnet": statusnet
[14:19] <asac__> but do all three steps to be sure that your settings dont get lost
[14:20] <BUGabundo> let me 1st try the 1st one :)
[14:23] <asac__> yeah
[14:23] <asac__> step by step ...
[14:25] <BUGabundo> asac could the old 1.2 jaiku .py be ported too?
[14:25] <BUGabundo> no idea why it abandoned
[14:25] <BUGabundo> nor do I see a bug for it
[14:26] <asac__> i wont do that porting
[14:26] <asac__> someone who uses it needs to step up
[14:26] <BUGabundo> :(
[14:26] <asac__> at best whoever contributed it initially
[14:27] <BUGabundo> I think it was Ryan
[14:27] <BUGabundo> :|
[14:27] <asac__> what doenst work?
[14:27] <asac__> is it completely broken? or just a bit?
[14:27] <asac__> do you get errors and all that stuff?
[14:27] <BUGabundo> its not ported
[14:28] <BUGabundo> so its not available anymore
[14:28] <BUGabundo> renaming done
[14:28] <asac__> ok then file a bug
[14:28] <BUGabundo> starting local gwibber modded
[14:28] <asac__> BUGabundo: k lets first check out the rename
[14:28] <asac__> so that was just the "name": in laconica.py (1st step)
[14:30] <BUGabundo> asac renaming done, and working so far
[14:31] <BUGabundo> still pleanty of "laconica" string around
[14:31] <asac__> in UI?
[14:31] <asac__> where?
[14:32] <asac__> BUGabundo: http://pastebin.com/f29a2cb6e ... you did that, right?
[14:33] <BUGabundo> yes that's what I did
[14:33] <BUGabundo> its not UI, just cli messages
[14:33] <BUGabundo> and inside the ,py
[14:33] <asac__> sure
[14:33] <BUGabundo> DEBUG:gwibber:Scheduled Op: <receive:laconica>
[14:33] <BUGabundo> DEBUG:gwibber:Scheduled Op: <responses:laconica>
[14:33] <BUGabundo> DEBUG:gwibber:Scheduled Op: <private:laconica>
[14:33] <asac__> thats ok
[14:33] <BUGabundo> I know
[14:33] <asac__> thats a separate step
[14:33] <asac__> for now its UI
[14:33] <asac__> ok i am committing that
[14:34] <BUGabundo> wait
[14:34] <BUGabundo> let me try it :)
[14:34] <BUGabundo> at least ill learn a bit mre
[14:34] <BUGabundo> and purpose a merge
[14:35] <asac__> BUGabundo: oh already committed it ... but gave you credits
[14:35] <fta> asac__, should we really keep this in tb*? MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png
[14:35] <asac__> BUGabundo: bzr commit -m "rename Laconi.ca to StatusNet (UI part) in laconica.py (thx @BUGabundo for testing) - lp:419817"Committing to: bzr+ssh://bazaar.launchpad.net/~gwibber-committers/gwibber/trunk/
[14:35] <asac__> modified gwibber/microblog/laconica.py
[14:35] <asac__> Committed revision 477.
[14:35] <asac__> BUGabundo: next one :/
[14:36] <asac__> BUGabundo: you can try the rename of laconica.py as i said above (step 2 and 3)
[14:36] <BUGabundo> trying
[14:36] <asac__> fta: good point. i think we should update that
[14:36] <asac__> maybe add the mimetype for mail files it can process
[14:36] <fta> asac__, while you're in there, please check that bug 460069 is properly committed
[14:36] <asac__> application/rss+xml
[14:36] <asac__> is reasonable
[14:36] <asac__> application/rdf+xml
[14:36] <asac__> that too
[14:37] <asac__> yes
[14:37] <asac__> let me check
[14:37] <asac__> there is a bug in gwibber fonts
[14:37] <asac__> hmm
[14:37] <fta> asac__, i mean, someone provided a debdiff, and scottk sponsored it
[14:37] <asac__> did jordan hall upload that?
[14:37] <asac__> did he commit it to packaging?
[14:38] <fta> i don't think so
[14:39] <asac__> hmm
[14:39] <BUGabundo> asac account lost on change of __init__
[14:39] <asac__> fta: is that ok for you? e.g. size wise?
[14:40] <asac__> BUGabundo: bzr diff
[14:40] <asac__> paste that
[14:40] <asac__> i think you need to keep the old name
[14:40] <asac__> i mean
[14:40] <bdrung> asac: i modified the clean rule to http://paste2.org/p/483856
[14:40] <BUGabundo> and I can't change the properties of a new one
[14:40] <asac__> "laconica": statusnet
[14:40] <asac__> that what i would have hoped should work
[14:40] <BUGabundo>  File "/home/bugabundo/temp/gwibber2_trunk/gwibber/table.py", line 38, in custom_handler
[14:40] <BUGabundo>     for k, f in list(fns.items()): cell.set_property(k, f(o))
[14:40] <BUGabundo>   File "/home/bugabundo/temp/gwibber2_trunk/gwibber/configui.py", line 185, in get_proto_icon
[14:40] <BUGabundo>     return gtk.gdk.pixbuf_new_from_file(resources.get_ui_asset("icons/%s.png" % acct["protocol"]))
[14:41] <asac__> bdrung: did you commit on top of what i uploaded?
[14:41] <asac__> otherwise let me do that
[14:41] <asac__> BUGabundo:  paste your diff for now
[14:41] <BUGabundo> asac $ bzr diff __init__.py | pastebinit  http://paste.ubuntu.com/301329/
[14:42] <bdrung> asac: no, only modified the files you gave me
[14:42] <bdrung> asac: you may have to clean more than that
[14:42] <asac__> ok. i twas uploaded. i can commit your changes for now
[14:42] <asac__> and we can cleanup more later
[14:42] <asac__> ;)
[14:43] <asac__> or ask micahg to do that
[14:43] <asac__> let me file a bug
[14:43] <fta> asac__, donno, i just saw a dent yesterday about that, that led me to that bug
[14:44] <asac__> i complained now
[14:49] <asac__> bdrung: that paste service is inferior
[14:49] <asac__> no way to get pure data from it
[14:49] <asac__> ok found it
[14:53] <bdrung> asac: do you know a fast paste service with autodetection of the format?
[14:57] <asac__> no ;)
[14:57] <asac__> i just paste plain text
[14:58] <asac__> its all good
[14:58] <asac__> just that the "clean" format was hidden
[15:03] <fta> i often use pastebinit -f format
[15:03] <fta> asac__, ppa re-org? ready when you are
[15:06] <asac__> fta: so i mozillateam/TOPIC ok with you?
[15:06] <asac__> if so ... lets do as suggested. put ffox + xul per-version ppa
[15:06] <asac__> and tbird per-version ppa
[15:07] <fta> so we forget about webtech?
[15:07] <asac__> hmm
[15:07] <asac__> fta: thats ok too
[15:07] <asac__> but i cannot create any ppa ther ebecause i am not even in that team ;)
[15:07] <fta> you sure?
[15:08] <asac__> yes
[15:08] <fta> oh
[15:08] <asac__> https://edge.launchpad.net/~ubuntu-webtech/+members#active
[15:09] <asac__> is the build-deps ppa supposed to be for  all?
[15:09] <fta> fixed
[15:09] <asac__> thx
[15:09] <asac__> ok so let me create in webtech:
[15:09] <asac__> mozilla-central
[15:09] <asac__> hmm
[15:09] <asac__> lets check that if that would work
[15:10] <fta> no, it's a moving target
[15:10] <asac__> so we would have mozilla-central, mozilla-1.9.x etc.
[15:10] <asac__> for xulrunner and firefox daily combo
[15:10] <asac__> fta: we can also use firefox-3.7, etc. but the versions sometimes changes afterwards
[15:11] <asac__> and we cannot rename ppas afaik
[15:11] <asac__> so my vision would be something like:
[15:11] <asac__> mozilla-central
[15:11] <asac__> mozilla-1.9.x-daily
[15:11] <fta> and we will loose all the current users
[15:11] <asac__> mozilla-1.9.x-milestones
[15:11] <asac__> yes. but this has to happen at some point
[15:11] <asac__> for a bit we can upload to both
[15:11] <asac__> but i think thats unavoidable
[15:12] <asac__> we can check with launchpad folks about a redirect later
[15:12] <asac__> though not sure where to redirect as tbird will not be in the xul/ffox ppa etc.
[15:12] <fta> upload to both means a lot of ppa time
[15:12] <asac__> yes.
[15:12] <asac__> the alterantive is to upload to new
[15:12] <asac__> and just "copy"
[15:12] <asac__> using launchpad copy
[15:12] <asac__> but for that we have to wait till finished etc.
[15:12] <asac__> so a bit cumbersome
[15:13] <asac__> imo we should rather ask launchpad t remove the ppa so users will see a failure
[15:13] <fta> copy means writing scripts with  the lp api, last time i checked, it was not up to the task for big PPAs like ours
[15:13] <asac__> and check whats wrong
[15:13] <asac__> and then they might move to new locations
[15:13] <asac__> or will stop using dailies
[15:13] <asac__> if we complement this with blog posts and mailing list announcements it should be ok
[15:14] <asac__> yeah. imo we should just accept that we have to migrate ... even if we loose some users
[15:14] <asac__> they will stack up later
[15:14] <asac__> and if we can make them getting errors on apt-get update
[15:14] <asac__> its a good way to provide a hint
[15:14] <asac__> thoughts?
[15:14] <fta> yep
[15:15] <asac__> fta: so i think for mozilla-central and friends its easy
[15:15] <fta> if we do moz-central, we should probably add a meta package to allow the transition from one version of trunk to the next
[15:15] <asac__> would using comm-central + comm-1.9.0 comm-1.9.1
[15:15] <asac__> work?
[15:15] <asac__> hmm
[15:15] <asac__> right
[15:16] <asac__> so that makes me come back to the idea to not split by version
[15:16] <asac__> and rather write some kind of "mozilla testers" tool that does the right pinning etc.
[15:16] <fta> i'd like to avoid that pinning hell
[15:16] <asac__> depending on what you seleect
[15:16] <asac__> fta: yes, but we also need to do transitions etc. in dailies
[15:16] <asac__> that isnt really possible with split archives
[15:16] <asac__> i just forgot that above when suggesting
[15:17] <asac__> like firefox-3.5 becomes default ... firefox-3.0 also needs to be in same archive ... for the time at least where ffox 3.0 is still shipped
[15:17] <fta> so?
[15:17] <asac__> firefox-daily
[15:17] <asac__> firefox-milestones
[15:18] <asac__> or
[15:18] <asac__> yeah
[15:18] <asac__> that and
[15:18] <asac__> same for thunderbird-daily
[15:18] <asac__> and thunderbird-milestone
[15:18] <asac__> etc.
[15:18] <fta> hm, that still means pinning
[15:18] <asac__> for those that want to selectively use it
[15:18] <asac__> but i really think that there is no way around
[15:18] <fta> i prefer per version ppas
[15:18] <asac__> and we need some UI that allows users to express what they really want
[15:18] <asac__> but that doesnt work
[15:19] <fta> why?
[15:19] <asac__> you will send users into breakage
[15:19] <asac__> 16:17 < asac__> like firefox-3.5 becomes default ... firefox-3.0 also needs to be in same archive ... for the time at least where ffox 3.0 is still shipped
[15:19] <asac__> we need them so users get good transitions
[15:20] <asac__> so basically what we support is: on archive side you can opt-in/out per-application
[15:20] <asac__> for dailies/milestone
[15:20] <asac__> if you want more things you need pinning ... which we should make easy by providing a "daily testers tool"
[15:20] <asac__> or something
[15:21] <asac__> if you split stuff users would be in the same position as they were before we replaced all firefox 3.0 packages
[15:21] <fta> pinning is bad because if you've already ahead of what you want, it simply doesn't work until you manually downgrade
[15:21] <fta> -ve+re
[15:22] <asac__> but is that an important case?
[15:22] <asac__> usually daily would catch up and then you would ride it
[15:22] <asac__> also i thought you can pin so hard that it also downgrades
[15:22] <asac__> but imoi that "daily testers" tool could do the pinning
[15:22] <asac__> and then do the initial downgrade
[15:22] <asac__> explicditly
[15:22] <asac__> if its really a needed use case
[15:23] <asac__> "Note that a priority above 1000 will allow even downgrades no matter the version of the prioritary package. This means that you can use priority 1001 for a stable source if you want to downgrade to the stable versions of the packages you have installed (let's say from testing) on the system. this is not recommended unless the number of changes are minimal "
[15:23] <asac__> http://wiki.debian.org/AptPinning
[15:23] <asac__> sounds reasonable
[15:25] <fta> i tried that already, it never worked for me
[15:26] <BUGabundo> guys just got 20 wave invites, if anyone needs one
[15:27] <fta> BUGabundo, i already have an account there
[15:27] <BUGabundo> fta: going on my second :)
[15:27] <fta> but no invites.. where are they supposed to be?
[15:27] <BUGabundo> just got mine
[15:27] <BUGabundo> fta: only ppl who got invited by google have invites!
[15:28] <BUGabundo> ppl Nominated don't get them
[15:28] <BUGabundo> so if you need one for a friend
[15:28] <BUGabundo> ask while I still have some
[15:28] <fta> it's ok, my friends still have some, so we have a pool ;)
[15:29] <BUGabundo> ok
[15:29] <fta> asac__, do you have one? we could draft the ppa thing there ;)
[15:30] <BUGabundo> LOLOLOL
[15:36] <fta> -Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[15:36] <fta> +Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[15:36] <fta> lol
[15:38] <asac__> fta: gwibber hack backed out ;)
[15:38] <asac__> fta: that maintainer part is correct
[15:38] <asac__> MOTU isnt used anymore
[15:38] <asac__> fta: what invite do you want?
[15:39] <asac__> google?
[15:39] <asac__> gmail?
[15:39] <asac__> i have plenty ;)
[15:39] <fta> it was for wave, but i don't need any
[15:39] <asac__> but i dont think its needed
[15:39] <asac__> i think we should setup a wiki page
[15:39] <asac__> and spec
[15:39] <asac__> spec like
[15:39] <asac__> to play through all cases
[15:40] <asac__> https://wiki.ubuntu.com/MozillaTeam/PPAs
[15:40] <asac__> hmm
[15:40] <asac__> i think its ok to put there
[15:40] <asac__> and then make a WebTech PPa page that links to the sub teams
[15:40] <fta> wave a bit like gobby
[15:40] <fta> +is
[15:41] <asac__> ah ;)
[15:41] <asac__> fta: you can also use google doc
[15:41] <asac__> s
[15:41] <asac__> ;)
[15:42] <asac__> i added introduction to that page now
[15:42] <asac__> "This document describes what ppas the mozillateam runs and what mechanisms users can use to opt-in/out from individual apps etc."
[15:42] <asac__> unfortuantely we got now visitors ... i am basically in the bedroom now hiding ;) ... saiyng that i am getting dressed. i will be back at 7 i think
[15:44] <fta> :)
[15:45] <asac__> so ... now i really have to get dressed
[15:45] <asac__> i will finish my thoughts while sitting there and listening to low-quality talks ;)
[15:46] <asac__> bbiw
[16:16] <fta> BUGabundo, i think i trashed my W7 vbox install, i tried too hard to have dx10, now, it's painfully slow
[16:19] <BUGabundo> lolol
[16:19] <BUGabundo> no idea
[16:19] <BUGabundo> never pushed it that hard
[16:19] <BUGabundo> great thing about VM
[16:19] <BUGabundo> take a snapshot and restore
[17:02] <fta> asac, if you feel brave enough to fix a really annoying gwibber bug: it scrolls at the top for each reload/update while you're reading
[17:02] <BUGabundo> YES YES YES
[17:02] <BUGabundo> very anoying
[17:52] <dtchen> BUGabundo: please see https://wiki.ubuntu.com/PulseAudio/Log
[17:52] <BUGabundo> dtchen: and now I hear glitches again :(
[17:53] <BUGabundo> dtchen: logging now
[17:53] <dtchen> BUGabundo: the glitches aren't necessarily PA's fault.
[17:54] <dtchen> BUGabundo: e.g., the driver may not be doing DMA properly given the constraints of the hw
[17:56] <fta> dtchen, will you push sdl to the p-a ppa?
[17:56] <fta> or to a new place?
[17:58] <dtchen> fta: it will be in the ubuntu-audio-dev PPA as usual
[17:59] <fta> dtchen, ok, great. i still have themuso and crimsun, could i just drop that now?
[17:59] <dtchen> fta: yes
[17:59] <fta> excellent
[18:02] <fta> d'oh!
[18:02] <fta> 53 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[18:02] <fta> Need to get 1,081MB of archives.
[18:02] <fta> After this operation, 461MB of additional disk space will be used.
[18:02] <BUGabundo> dtchen: was 100% ok until yesterday
[18:02] <BUGabundo> now I hear it all the time
[18:02] <BUGabundo> let me check PAMAN to see if I have anything above 100%
[18:03] <fta> Get:14 http://archive.ubuntu.com karmic/universe nexuiz-data 2.5.2-1build1 [793MB]
[18:03] <fta> pfff
[18:03] <BUGabundo> fta: aha
[18:04] <BUGabundo> fta: better change mirrors :)
[18:04] <fta> why, it's fast
[18:05] <BUGabundo> is it?
[18:05] <BUGabundo> not for me
[18:06] <asac__> ok
[18:10] <fta> ok, now that the ppa dls are done, it's slow
[18:11] <BUGabundo> ahahah
[18:14] <asac__> fta: https://wiki.ubuntu.com/MozillaTeam/PPAs#preview
[18:17] <BUGabundo> dtchen: need my current log?
[18:18] <asac__> ok renamed the -mliestones to -dailies
[18:18] <asac__> err backports ;)
[18:20] <BUGabundo> lolol
[18:20] <BUGabundo> typo like that
[18:21] <BUGabundo> and we are all doomed
[18:26] <asac__> so what was the right way to add a pin for a repo?
[18:26] <asac__> examples?
[18:26] <asac__> fta: ?
[18:26] <asac__> would like to put examples on the wiki page so we can check if that is what we want to do
[18:28] <fta> well, i'm not sure it's the right way, but i have:
[18:28] <fta> Package: *
[18:28] <fta> Pin: release o=LP-PPA-ubuntu-mozilla-daily
[18:28] <fta> Pin-Priority: 101
[18:32] <sebner> fta: you should thank me and not complain about the size :P
[18:32] <fta> nexuiz?
[18:34] <asac__> so how about this https://wiki.ubuntu.com/MozillaTeam/PPAs#preview
[18:34] <fta> sebner, nexuiz?
[18:35] <sebner> fta: yeah, say god to me as I brought it in ;)
[18:35] <fta> sebner, why did it jump from 322MB to 757MB?
[18:35] <asac__> better graphics ;)
[18:35] <asac__> hehe
[18:35] <asac__> more sound
[18:35] <sebner> fta: because it's getting cooler and cooler and more professional
[18:35] <sebner> hhuhu mighty asac__ _D
[18:35] <sebner> :D
[18:35] <asac__> hi sebner
[18:35] <sebner> long time no see
[18:36] <fta> well, i play openarena, not nexuiz :P
[18:36] <sebner> fta: you updates say something different :P
[18:36] <sebner> *your
[18:37] <fta> it's installed, but i haven't used it in months
[18:37] <fta> maybe i should
[18:39] <sebner> ack
[18:39] <sebner> ^^
[18:39] <asac__> https://wiki.ubuntu.com/MozillaTeam/PPAs
[18:39] <sebner> asac__: mighty, what's going on at the reeperbahn? =)
[18:39] <asac__> i am in kiel atm ;)
[18:39] <fta> http://launchpadlibrarian.net/34364433/buildlog_ubuntu-jaunty-amd64.firefox-3.7_3.7~a1~hg20091025r34171%2Bnobinonly-0ubuntu1~umd1~jaunty_FAILEDTOBUILD.txt.gz
[18:41] <asac__> fta: that reminds me ... how long do you want micah to continue before adding him to team? ;) i think we could ask him to ask for review for things that are not trivial, but i think he would ask and not just push stuff that is too difficult for him
[18:41] <asac__> a least simple rebasing seems to be ok for him ;)
[18:41] <fta> i agree
[18:41] <asac__> he has been around doing bunch of bug work too for quite some time
[18:41] <asac__> cool
[18:42] <av`> asac__, who?
[18:42] <asac__> micah
[18:42] <av`> ah :)
[18:42] <asac__> fta: do you think that way of pinning would work?
[18:42] <asac__> i would make a simple script then to help users opt-in/out from things
[18:42] <fta> you should try ;)
[18:43] <asac__> hmm
[18:43] <asac__> right
[18:43] <asac__> guess i can already do that
[18:43] <asac__> thought for a moment i would need it
[18:43] <asac__> fta: only thing that bothers me is the meta package
[18:43] <asac__> we should include the metapackage >= target version somehow
[18:43] <asac__> not sure how that is best done
[18:44] <asac__> i think i know how
[18:44] <fta> why would it be different from now?
[18:45] <asac__> no its not different
[18:45] <asac__> thats why i said "for a moment"
[18:45] <asac__> i can try
[18:45] <asac__> and will do that now
[18:46] <asac__> just wondering if that works for the version
[18:46] <asac__> too
[18:46] <asac__> ok added how i think that meta package could be done
[18:47] <asac__> now checking what happens ;)
[18:54] <asac__> hmm ffox didnt finish for today yet
[19:07] <asac__> a bit odd ... it doesnt read what i have in preferences.d
[19:07] <asac__> hmm
[19:37] <dtchen> BUGabundo: sure.
[19:44] <BUGabundo> dtchen: pastebining now
[19:54] <fta> sebner, nexuiz is unplayable on my dual core.
[19:55] <fta> problably same sdl/p-a issue as openarena
[20:03] <BUGabundo> dtchen: $ pastebinit pulseverbose.log  http://paste.ubuntu.com/301533/
[20:03] <BUGabundo> sorry it took a while. 2MB file over 2G :)
[20:04] <dtchen> hmm
[20:04] <dtchen> BUGabundo: are you actually using rtp actively?
[20:04] <sebner> fta: I don't have any problems. Have audio deactivated in nexuiz though
[20:04] <BUGabundo> dtchen: no
[20:04] <dtchen> BUGabundo: if not, just use pactl to unload those modules
[20:05] <BUGabundo> I just have it enabled
[20:05] <BUGabundo> :(
[20:05] <dtchen> BUGabundo: oh, in that case, disable it _and_ unload those modules
[20:05] <BUGabundo> can't I keep it?
[20:05] <BUGabundo> does it affect me some how?
[20:05] <BUGabundo> LOLOL
[20:05] <BUGabundo> ahahahahahahaahahahahaahahah
[20:05] <dtchen> it's known to cause aberrations ATM
[20:06] <BUGabundo> turning it off then
[20:06] <BUGabundo> but it was fine up to last update :|
[20:06] <BUGabundo> dtchen: done
[20:06] <BUGabundo> restart ?
[20:07] <dtchen> BUGabundo: no need
[20:07] <BUGabundo> ok
[20:07] <dtchen> unloading them should be sufficient
[20:07] <BUGabundo> need to put my system to a stress test :|
[20:07] <BUGabundo> ideas?
[20:07] <dtchen> I probably need to hack in frame debugging into alsa-lib for 10.04
[20:08] <fta> asac, http://launchpadlibrarian.net/34368035/buildlog_ubuntu-jaunty-amd64.prism_1.0b2%2Bsvn20090813r49078-0ubuntu2~umd3~jaunty_FAILEDTOBUILD.txt.gz
[20:10] <BUGabundo> dtchen: if you need further testing or I still see glitchs I'll let you know!
[20:10] <BUGabundo> dtchen: do you think this will also fix my mute at start up?
[20:16] <dtchen> BUGabundo: it's likely unrelated, but I haven't stared at the volume code in some time.
[20:17] <BUGabundo> dtchen: it was all fine up until recently. I installed kernel .15 and -32 to test 3G modem support bug, and am back to karmic kernel
[20:17] <BUGabundo> but now audio is muted on boot
[20:18] <dtchen> kernel .15?
[20:18] <BUGabundo> dtchen: Linux BluBUG 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux
[20:19] <dtchen> sorry, but what's .15?
[20:19] <BUGabundo> 2.6.31-25
[20:19] <BUGabundo> grrrr
[20:19] <BUGabundo> 2.6.31-15
[20:19] <BUGabundo> brb, dinner
[20:20] <dtchen> git reset --hard origin/master
[20:20] <dtchen> bah, sorry
[20:21] <dtchen> BUGabundo: I don't see a -15?
[20:21] <BUGabundo> dtchen: kernel ppa
[20:22] <dtchen> ah
[20:22] <dtchen> right, I don't even see it tagged in ubuntu-karmic.git
[20:39] <BUGabundo> back
[20:39] <BUGabundo> dtchen: yeah I know
[20:39] <BUGabundo> I was testing it
[20:39] <BUGabundo> cause the bug report said it fixed 2G
[20:39] <BUGabundo> *3G
[20:39] <BUGabundo> not related to audio
[20:39] <BUGabundo> but I though I should mention