[00:00] <fta> i wish gwibber had a way to show URLs fully resolved, like the Attachments in the identi.ca web pages
[00:02] <BUGabundo> me too
[00:02] <BUGabundo> I hate short links
[00:03] <BUGabundo> I think I have a bug for that
[00:08] <fta> hm, sometimes, when i want to submit a dent, gwibber just adds a carriage return in the textfield but doesn't send anything
[00:12] <BUGabundo> eheh
[00:12] <BUGabundo> I'm back on 1.2
[00:12] <BUGabundo> I couldn't take it anymore
[00:38] <fta> http://arstechnica.com/tech-policy/news/2009/09/does-less-evening-internet-mean-europeans-lead-better-lives.ars
[01:31] <andv> asac, all-in didnt appear on NEW
[01:31] <andv> asac, plus I received no NEW mail
[01:32] <andv> asac, something went wrong then
[01:32] <andv> going to sleep
[01:32] <andv> cya tomorrow
[08:46]  * asac goes and gets some coffee
[09:45] <asac> ejat: there?
[09:45] <asac> bdrung: hi!
[09:45] <asac> bdrung: saw you got added to the team ... congrats ;)!
[09:53] <asac> bdrung: did your MOTU application work out well?
[10:08] <fta_> asac, aren't MOTU nearly dead? i mean, with the archive reorg in progress
[10:14] <fta_> d'oh! http://www.youtube.com/watch?v=0qqxjO5nr8k&feature=featured
[11:00] <eagles0513875> morning gnomefreak
[11:08] <andv> asac, hi
[11:09] <andv> asac, had a problem with the upload yesterday? :)
[11:26] <asac> andv: no orig
[11:26] <asac> its now done
[11:27] <andv> asac, yeah :)
[11:27] <andv> saw it on new
[11:32] <eagles0513875> hey asac :)
[11:45] <asac> hi eagles0513875
[11:46] <eagles0513875> how goes it asac
[11:48] <asac> pretty good ... still catching up a bit on vacation stuff ;)
[12:23] <gnomefreak> ok how the hell do i get normal gwibber back?
[12:27] <bdrung> asac: thanks. the MOTU application was deferred because they had no quorum
[12:28] <asac> bdrung: during meeting?
[12:28] <asac> hmm
[12:28] <asac> gnomefreak: no way ... just keep using it ;)
[12:29] <gnomefreak> asac: i cant figure out how to send message
 brings you down to next line to type
[12:29] <bdrung> asac: no, before :)
[12:29] <asac> gnomefreak: i dented about that and got an answer
[12:30] <asac> gnomefreak: http://identi.ca/notice/9277389
[12:30] <gnomefreak> thanks lookinhg
[12:30] <asac> http://identi.ca/conversation/9276118#notice-9277389
[12:30] <gnomefreak> I DONT LIKE IT
[12:31] <gnomefreak> asac: i cant move it up
[12:31] <fta2> there's a pref in the menu
[12:32] <gnomefreak> not here there isnt
[12:32] <gnomefreak> at least not in pref
[12:32] <gnomefreak> i have same ui for new as was for old versions
[12:33] <gnomefreak> for pref
[12:33] <fta2> not in pref, just View / Editor
[12:33] <gnomefreak> fta2: i can typw but i cant send it
[12:33] <gnomefreak> s/typw/type
[12:33] <fta2> it's enter, as before
[12:33] <gnomefreak> fta2: brings me down a line in editor
[12:33] <fta2> but sometimes, it just adds a carriage return
[12:33] <fta2> it's a bug
[12:34] <fta2> scroll up, and enter
[12:34] <gnomefreak> same thing
[12:35] <asac> gnomefreak: you can drag it up ... just try a bit more ... its  tiny grab thing like where the separator line is right at bottom
[12:36] <gnomefreak> asac: not here it just brings the text back to editor as if it is not permitted
[12:36] <asac> well then you already have the editor
[12:36] <asac> which was what i didnt have
[12:36] <asac> sending worked for me
[12:36] <gnomefreak> i have editor since i typed in it but no way to send it
[12:37] <fta2> iirc, View / Editor is disabled by default, which is bad
[12:37] <asac> gnomefreak: i hit enter and it works
[12:37] <gnomefreak> i have the editor that part i knew from other releases its sending it that isnt working
[12:38] <asac> fta2: for the searchplugins we actually should add replaces to all lower firefox versions on all firefox branches i think
[12:39] <asac> or we should get rid of the common firefox-addons/searchplugins dir
[12:40] <fta2> asac, or make a dedicated src package
[12:40] <asac> yeah
[12:40] <gnomefreak> cant clear window either let me see if there is an update for it
[12:42] <gnomefreak> bug in apturl too :(
[12:45] <fta2> asac, i like the dedicated source package, so we can add/remove/update searchplugins independently of ff
[12:46] <asac> fta2: technically i agree. problem is that it bears the risk that we miss if upstream changes their default searchplugins
[12:47] <asac> and we are obliged to have them unless we explicitly applied/communicated for a change
[12:47] <asac> wonder if there is a way to add a safety net
[12:47] <asac> like "if we are package that ship default package, verify that the searchplugins in the other package are all the same"
[12:48] <fta2> we can just pull that from trunk, like today
[12:51] <asac> thats not what we do today
[12:51] <asac> we pull them from the branch of the package installed
[12:51] <asac> the package with highest version is supposed to win
[12:51] <asac> but in default install we have the plugins of firefox-3.5 as shipped by upstream unless someone installs firefox-3.7 et al
[12:52] <asac> so i guess we should need to pull them from current default branch
[12:52] <fta2> 3.7 doesnt provide those searchplugins, just a link
[12:52] <asac> as thats where mozilla wants trademark being inforced
[12:53] <asac> fta2: yes. so i think what we should do is provide a firefox-searchplugins package which is produced from the same package where we have the meta package
[12:53] <asac> does that sound about right?
[12:53] <asac> and everything depends on firefox-searchplugins in turn
[12:53] <fta2> yes
[12:54] <asac> ok so no standalone source package
[12:54] <asac> just an unversioned package for the current METAPACKAGE thing
[12:54] <asac> at some point we probably want to assemble debian/control on-the-fly ;)
[12:54] <asac> hehe
[12:58] <asac> jdstrand: so at best the apparmore profile feature would become independent from the firefox version by some template magic
[12:58] <asac> i would like to able to just land it in firefox-(3.0?)/3.5/3.6/3.7
[12:59] <asac> jdstrand: ok ... so i think the general 3.* and 1.9* things can be kept that way
[12:59] <asac> but the firefox-3.5.* would probably be better replaced during build with @DEB_SOURCE_PACKAGE@.* or something
[13:00] <asac> if it makes things cleaner (as we use templating anyway) we could also replace the 1.9* and 3.* with proper template things
[13:01] <jdstrand> asac: I'm cool with that conceptually, but will it make it too easy to not verify it? I intentionally did it this way so someone would need to look at it. ie, 3.0's profile didn't work with 3.5
[13:01] <jdstrand> it mostly worked, but needed tweaking
[13:04] <asac> jdstrand: yes. but we usually have those branches right from day zero where 3.5 == 3.6 for instance
[13:04] <asac> jdstrand: so its more a continous process anyway
[13:04] <asac> so assume we have it for firefxo-3.6 and then 3.7 got created the files would be the same anyway without verification needed
[13:04] <asac> only while upstream changes we need to adjust
[13:04] <asac> so i dont think it provides a safety net for us
[13:05] <jdstrand> asac: if that works better with your process then I'll update it
[13:05] <asac> would be precious. let me check if i can see something else
[13:12] <asac> jdstrand: not sure if i am just confused, but isnt
[13:12] <asac> +        if [ ! -e "$APP_CONFFILE" ]; then
[13:12] <asac> +            ln -sf $APP_CONFFILE $APP_DISABLE
[13:12] <asac> wrong?
[13:13] <asac> e.g. APP_CONFFILE does not exist => then we link it?
[13:13] <jdstrand> it looks wrong but isn't
[13:13] <asac> shouldnt it be the other way around?
[13:13] <jdstrand> it is based on https://wiki.ubuntu.com/ApparmorProfileMigration
[13:13] <jdstrand> the idea is this happens in preinst, and we know our package supplies the file after unpacking
[13:14] <jdstrand> so yes it dangles for a second, but then is resolved at unpack
[13:15] <jdstrand> keep in mind ApparmorProfileMigration is mostly geard for files moving from apparmor-profiles to a package which provides its own profile, but many of the ideas are the same
[13:16] <asac> you think we can use $0 in the pre/post stuff to prevent templating there?
[13:16] <asac> e.g. for firefox-3.5 etc.
[13:16] <asac> ?
[13:18] <asac> hmm postinst.in is alrady a template. so i guess we are fine with making .in out of everything
[13:19] <jdstrand> asac: I should be able to do something with preinst
[13:19] <jdstrand> asac: I'll work on making it all generalized
[13:20] <asac> jdstrand: thanks. i dont like all the maintainer script stuff, but if its really needed then i am fine with the changes once they are generic
[13:22] <jdstrand> asac: the idea is to protect the user. if they upgrade from jaunty to karmic, the profile is disabled. if they already have a profile they wrote or they upgrade from karmic to karmic-security we don't want to automatically disable it again
[13:23] <jdstrand> that said, I'm confident I can generalize it
[13:25] <asac> jdstrand: yes. i figured that and accepted it ;)
[13:25] <asac> all fine
[13:26] <asac> jdstrand: you might want to investigate at some point if you can do some debhelper magic to automatically add the right snippets
[13:26] <asac> so you dont need to duplicate all the things in all maintainer scripts ;)
[13:26] <asac> but not karmic topic of course
[13:26] <asac> dh_installapparmor ;)
[13:26] <asac> or something
[13:27] <jdstrand> yeah, the problem is they tend to be different enough for each package... but it has been something I've thought about
[13:27] <jdstrand> thanks :)
[13:28] <asac> no problem ;) /me likes giving easy advices for not-so-easy things :)
[13:30] <gnomefreak> !grub2
[13:46] <asac> jdstrand: you think i should wait for the karmic ppa security upload for your new merge request?
[13:47] <asac> i think release is still 1-2 weeks away so we can wait a bit if you would like to get that into the first .14 upload
[13:48] <jdstrand> asac: well, I'd personally like it sooner than later, but I'll leave ff release management up to you :)
[13:48] <asac> jdstrand: we only ship profile in firefox package right? not xulrunner?
[13:48] <jdstrand> asac: correct
[13:48] <asac> jdstrand: when do you think can you do the generalization?
[13:48] <jdstrand> asac: I'm building a package with my changes right now
[13:48] <jdstrand> so... soon?
[13:48] <jdstrand> :)
[13:50] <asac> great
[13:50] <asac> i will wait a bit then
[13:50] <jdstrand> asac: do you have any objections to me adding something to the apport hook?
[13:51] <jdstrand> asac: I did it with evince and it has worked out fantastically
[13:51] <jdstrand> (is that a word?)
[13:53] <asac> jdstrand: i am happy to retrieve apport hook love
[13:53] <asac> ;)
[13:53] <asac> of course depends on what you want to append ;)
[13:53] <jdstrand> cool, I get that going then too
[13:53] <asac> no root passwords for instance :)
[13:53] <jdstrand> heh
[13:54] <asac> in general who last touched the hook owns it until someone else touches it ;)
[13:54] <jdstrand> eek
[13:54] <jdstrand> that is a big committment!
[13:55] <asac> not so big
[13:55] <asac> just a joke ;)
[13:55] <jdstrand> :)
[14:18] <asac> fta2: i think there are localized search plugins in the locale hg tree ... which are not in the .xpi translation packages we ship
[16:09] <jdstrand> asac: ok, I committed r459 for apparmor/firefox
[16:10] <jdstrand> asac: it should be generalized completely
[16:10] <jdstrand> asac: it also will add apparmor stuff to the apport report if the profile is not disabled
[16:11] <jdstrand> asac: https://code.launchpad.net/~jdstrand/firefox/firefox-3.5-apparmor/+merge/11061
[16:12] <asac> let me check
[16:12] <jdstrand> asac: I think I did all the LP right this time too, so the 'Review Diff' should now be accurate
[16:12] <asac> yeah saw that the other is properly marked as superseded ... well done ;)
[16:12] <jdstrand> heh
[16:12] <asac> jdstrand: have you tested the apport hook?
[16:13] <asac> this also smeels like something that could be factored into apport general package i think
[16:13] <jdstrand> asac: yes, works great (both when disabled and enabled)
[16:13] <asac> we have similar generic functions for wifi etc in there now
[16:13] <asac> jdstrand: thx for confirming
[16:13] <jdstrand> asac: yeah, I thought of that too, but too late for FF
[16:13] <jdstrand> (on my todo)
[16:13] <asac> imo thats not FF relevant ;)
[16:14] <asac> but thats just me ;)
[16:14] <jdstrand> I'll talk to pitti when I have more time, and if I can get to it, I will and will update this packaging
[16:14] <asac> the feature is there ... just not in the central apport hook library ;)
[16:14]  * jdstrand nods
[16:15] <asac> jdstrand: no problem
[16:16] <asac> [ Jamie Strandboge <jamie@ubuntu.com ]  -> wrong (i will fix it during merge)
[16:16] <asac> ;)
[16:17] <jdstrand> asac: fyi, I compared all the old maintainer scripts with the newly generated ones and they're the same
[16:17] <jdstrand> asac: re changelog> oops! :)
[16:17] <jdstrand> thanks
[16:19] <jdstrand> asac: fyi, I fixed the typo in debian/changelog in r460
[16:20] <asac> jdstrand: there is also DEBIAN_NAME_OTHER ... for abrowser ... not sure if we can make that work easily ... without copying the full block
[16:20] <jdstrand> asac: oh, I forgot-- you probably should wait to upload until the next kernel is uploaded
[16:20] <asac> jdstrand: what will happen with old kernels?
[16:21] <jdstrand> asac: as it is disabled by default, nothing, but if someone enables it, it won't load cause I use PUx for evince
[16:22] <asac> jdstrand: there is no new dependency added
[16:22] <asac> is that because its installed by default?
[16:22] <asac> since when are the binaries used available?
[16:22] <jdstrand> asac: not a huge issue-- the patches are committed to the kernel and just awaiting upload
[16:22] <asac> like aa-... ?
[16:23] <jdstrand> asac: this will work fine without apparmor installed, so no Depends or Recommends. sometimes I add a Suggests, but didn't here
[16:23] <jdstrand> (tried to keep the packaging changes to a minimum)
[16:24] <asac> jdstrand: but it calls apparmor_parser and aa-status without checking that the binaries actually exist
[16:24] <asac> hmm ... but only if APP_PROFILE exists for postinst
[16:24] <asac> jdstrand: point is that we build the .head branch everywhere: hardy - karmic
[16:25] <asac> so if possible it would not break there ;)
[16:25] <asac> ok seems ok
[16:25] <jdstrand> asac: well, 'aa-status' will fail if it isn't around
[16:25] <asac> do you see anything that might break?
[16:25] <asac> yeah true
[16:25] <jdstrand> and I 2>/dev/null it
[16:26] <micahg> asac: I'm reminding you about the fixed-3.5.3 and fixed-3.0.14 tags
[16:26] <jdstrand> asac: this is the same recipe I use all over the place
[16:26] <micahg> I saw the branches committed for the next ff release
[16:26] <asac> micahg: huh ;)
[16:26] <jdstrand> asac: I have tested it here and am comfortable with it
[16:26] <asac> thanks
[16:26] <asac> micahg: that was last minute ;9
[16:26] <jdstrand> asac: I'll of course fix anything that breaks
[16:26] <asac> micahg: though i already uploaded xulrunner ;)
[16:26] <asac> but thats ok i guess
[16:26] <asac> next time i should remember it better
[16:27] <asac> jdstrand: ok. i think its ok. lets merge it and see if the daily mob shouts ;)
[16:27] <jdstrand> heh
[16:28] <asac> jdstrand: but we need to fix abrowser later
[16:28] <asac> does the name need to match the binary? or just this: /usr/lib/@APPNAME@.*/firefox { ?
[16:28] <asac> oh its referring to firefox
[16:28] <jdstrand> /usr/lib/@APPNAME@.*/firefox
[16:28] <asac> so i guess only question is if usr.bin.firefox.apparmor
[16:28] <asac> has any meaing
[16:28] <asac> but i guess not
[16:29] <asac> ok great
[16:29] <asac> lets go for it
[16:29] <jdstrand> whatever uses that binary is confined
[16:30] <asac> jdstrand: ok merged ... i will check if its easy to just pull that over to 3.7 and 3.6 branch and if not i will poke you ;M)
[16:30] <jdstrand> asac: if it makes sense to rename the profile to simply apparmor.profile, we can do that.
[16:30] <jdstrand> asac: cool, I will be more than happy to fix anything wrt this
[16:30] <jdstrand> asac: thanks for the review and merge! :)
[16:31] <asac> micahg: bug 236853 ... is that really fixed by ffox? not by nss?
[16:31]  * asac checks upstream bug
[16:32] <asac> ok its fixed in ffox/xul
[16:32] <asac> thx
[16:33] <micahg> I just followed whatever they said upstream
[16:36] <asac> micahg: documented. thanks a bunch for that ;)
[16:36] <asac> micahg: you were right.
[16:43] <micahg> are they actually releasing 3.0.14 or did it go t oRC?
[16:48] <micahg> asac: I made my patch better, but now it fails to build for bug 66015
[16:48] <micahg> http://launchpadlibrarian.net/31218684/buildlog_ubuntu-jaunty-amd64.xulrunner-1.9.1_1.9.1.2%2Bnobinonly-0ubuntu0.9.04.1~ppa10_FAILEDTOBUILD.txt.gz
[16:48] <asac> micahg: beta
[16:48] <micahg> ok
[16:48] <asac> usually it goes 1-2 weeks before release to beta channels
[16:48] <asac> thats when i try to upload stuff to PPA
[16:48] <asac> if all goes well they dont respin and the same binary will be the release
[16:49] <asac> jdstrand: remember to mark your branch as merged (if launchpad didnt do that yet)
[16:51] <jdstrand> asac: done
[16:52] <micahg> asac, here's the new patch http://pastebin.com/f3982e877
[16:53] <micahg> Apparently, I don't have PRUniChar loaded
[16:55] <asac> micahg: but thats still the same approach
[16:55] <asac> how about the idea replacing _ with - (or vice versa)
[16:55] <asac> and then checking whether a dictionary with that name is alread in the mDictionaries map?
[16:55] <asac> btw its PRUnichar
[16:55] <micahg> ah
[16:56] <micahg> why not stop it at the source though
[16:56] <micahg> prevent the file from loading
[16:56] <asac> the file isnt loaded if you dont put it in the dictionarie
[16:56] <micahg> my original patch actually worked
[16:57] <micahg> ok
[16:57] <micahg> why not use a simpler patch though?
[16:57] <asac> because its fragile
[16:57] <asac> nobody knows what is wanted
[16:57] <micahg> why?
[16:57] <asac> _ or -
[16:57] <micahg> ah
[16:57] <asac> so better safe than sorry
[16:57] <asac> and allow both
[16:57] <micahg> I can add a commet
[16:57] <micahg> oh
[16:58] <micahg> that's what you mean
[16:58] <micahg> I looked at the upstream binaries
[16:58] <micahg> and they ship - in the files
[16:58] <micahg> it seems to be a mozilla thing
[16:58] <asac> just allow both variants, but just normalize the key
[16:58] <asac> (e.g. dict)
[16:58] <asac> the other alternative is to resolve an eventual link first
[16:58] <micahg> well
[16:59] <asac> like if file == link -> resolve ... then use leafName, normalize like discussed (e.g. replace _ by -)
[16:59] <micahg> what I'm wondering is why it doesn't display the whole name for the _ dicts but does for -
[16:59] <asac> micahg: that logic was at the other place
[16:59] <micahg> ah
[16:59] <asac> what bug id was it again?
[16:59] <micahg> bug 66015
[16:59] <asac> the other patch touched the source that assembles the name
[17:00] <micahg> would that type of patch be worthy of upstreaming then?
[17:00] <asac> content/global/inlineSpellCheckUI.js
[17:00] <asac> micahg: http://launchpadlibrarian.net/31020349/inlineSpellCheckUI.patch shows that it only shows the full name for "-" most likely
[17:00] <asac> at least thats what is processed properly
[17:00] <asac> (without that patch)
[17:01] <micahg> ok
[17:01] <asac> micahg: what are the links for us?
[17:01] <micahg> so I'll work on it tongiht
[17:01] <asac> the _ or the -?
[17:01] <micahg> -
[17:01] <micahg> _ is the normal file
[17:01] <asac> - are links to the _ files?
[17:01] <asac> hmm
[17:01] <micahg> apparently the ISO standard is _
[17:01] <micahg> but mozilla likes -
[17:01] <asac> ok so what we want is to use the dict key normalization to use "-" (because thats what mozilla uses)
[17:01] <micahg> ok
[17:02] <micahg> I have to leave for work soon
[17:02] <asac> and then we want to first split with "-"
[17:02] <micahg> so I'll work on this tonight
[17:02] <asac> so i think in best case we dont need to touch the .js
[17:02] <asac> yeah
[17:02] <asac> i think you dont need to resolve the link
[17:02] <asac> though upstream might want us to do that
[17:03] <asac> but lets first try to just normalize to use "-" as the key
[17:03] <asac> and check that for (var i = 0; i < list.length; i ++) {
[17:03] <micahg> ok
[17:03] <asac> list here is that key
[17:03] <asac> but i think its right then
[17:03] <asac> as long as we normalize to use -
[17:03] <micahg> ok
[17:03] <micahg> BTW, is ABrowser the official branded name of the unbranded browser?
[17:04] <micahg> we have bug 413076
[17:04] <asac> its our unbranded browser name
[17:04] <asac> there is no official unbranded branding ;)
[17:04] <micahg> so, can we change the menu to ABrowser vs A Web Browser so it doesn't seem so weird on other languages?
[17:06] <asac> abrowser was ment to be short for "A Web Browser"
[17:06] <asac> it was considered rougue to just use "Web Browser"
[17:06] <asac> because other browsers would then want that name too
[17:06] <micahg> yes, but if it's like that, it would seem that it should be localized in other langauges
[17:06] <asac> i will think about it
[17:07] <asac> not if "A Web Browser" is considered a brand name
[17:07] <asac> but well
[17:07] <micahg> oh
[17:07] <micahg> oops
[17:07] <asac> ;)
[17:07] <micahg> got it mixed up
[17:07] <micahg> it is translating it
[17:07] <asac> yeah
[17:07] <micahg> but only patially
[17:07] <asac> so technically its right
[17:07] <micahg> *partially
[17:07] <asac> question is if the bug has a point about confusion. i dont think so for now
[17:07] <asac> but have to think more
[17:08] <micahg> ok
[17:08] <micahg> ok to mark as triaged then?
[17:08] <asac> yes assign it to me and triaged stating this is pending decision
[17:09] <asac> you can also project that we probably won't go for just "WebBrowser"
[17:09] <asac> Rather "A Browser" ;)
[17:09] <asac> given the rational against taking Web Browser from above
[17:09] <micahg> I was thinking without the space and have it be an actually name - ABrowser
[17:09] <asac> Yeah
[17:10] <asac> but firefox == "Firefox Web Browser" .... abrowser = "A Web Browser" or "ABrowser Web Browser"
[17:10] <asac> which would be odd too ;)
[17:10]  * micahg likes the last one actually
[17:10] <micahg> ABrowser web browser
[17:10] <micahg> then the description can be localized
[17:10] <micahg> but the name remains
[17:10] <asac> we intentionally picked the most generic name so we wont need to enforce any trademarks on it as its probably not trademarkable on its own
[17:11] <asac> yeah
[17:11] <asac> but ABrowser Web Browser is double ;)
[17:12] <micahg> do you think it's worth throwing up on brainstorm?
[17:12] <asac> definitly not
[17:12] <asac> thtough branding discussion in the wild and you get a fully raged rant
[17:12] <asac> everybody in the end being unhappy
[17:12] <micahg> ah, right
[17:12]  * micahg remembers the Shiretoko rants
[17:34] <asac> micahg: fyi: https://developer.mozilla.org/en/XPCOM/Strings
[17:34] <asac> Mozilla internal string guide
[17:35] <asac> https://developer.mozilla.org/en/String_Quick_Reference
[17:47]  * mac_v seems nothing rogue about using "Web Browser"
[17:47] <mac_v> *sees
[18:12] <asac> mac_v: we would claim a generic name that other browsers would want to use if it was open for discussion
[18:12] <asac> so everyone agrees to not use such a generic name
[18:39] <mac_v> hmm... too bad , now we have to confuse the user ;p
[18:49] <micahg> mac_v: ??
[18:50] <mac_v> micahg: the "AWeb Browser" , i was replying to asac ;)
[18:50] <micahg> sorry, I must've caught the last line of that
[19:49] <fta> asac, http://launchpadlibrarian.net/31252914/buildlog_ubuntu-intrepid-i386.firefox-3.7_3.7~a1~hg20090902r32157%2Bnobinonly-0ubuntu1~umd1~intrepid_FAILEDTOBUILD.txt.gz
[19:54] <andv> asac, all-in-one accepted
[19:55] <andv> asac, I pinged a friend, who is ftp-assistant
[19:55] <andv> ;)
[21:55] <sveinung> andv and asac: thanks a lot for your help and sponsorship getting all-in-one-sidebar into Debian
[21:55] <andv> ;)
[21:56] <andv> sveinung, np
[21:56] <sveinung> :)
[21:56] <andv> sveinung, let me know when there will be a new upstream release
[21:57] <sveinung> andv: sure
[21:57] <andv> sveinung, I gonna sponsor the package from now on
[22:07] <andv> sveinung, do you know how Debian BTS work?
[22:08] <sveinung> andv: yes, at least part of it
[22:08] <andv> ok, both me and you will receive bug mails
[22:08] <sveinung> ok
[22:08] <andv> so if you don't know what to do, ping me
[22:08] <sveinung> sure