[00:48] <LLStarks> asac
[00:48] <LLStarks> you there?
[11:47] <AnAnt> asac: Hello
[11:47] <asac> hi
[11:47] <asac> quite busy so dont run away ;)
[11:47] <asac> wait ... :-P
[11:47] <AnAnt> ok
[11:48] <AnAnt> asac: ping me when you're free please
[11:51] <AnAnt> asac: chmsee 1.0.6 can't be merged from Debian because it must be build against xulrunner 1.9.0 (not .1), and the change you done to chmsee is build-dep on xulrunner-1.9.1
[11:58] <asac> AnAnt: why does that mean it cant be merged? most likely the change i did just needs to be applied similarly
[11:58] <AnAnt> asac: because chmsee cannot compile against xulrunner-1.9.1
[11:59] <asac> AnAnt: but it worked for the package i uploaded. the merge should rebase and adjust whatever changes i did so it builds against 1.9.1. makes sense?
[11:59] <AnAnt> asac: I tried that here, and it didn't work, I got compile error, some sort of configure script failed saying that it cannot find libxul-whatever <= 1.9.0.99
[12:00] <AnAnt> and I just asked upstream developer (lidaobing), and he confirmed that chmsee 1.0.6 cannot be compiled against xulrunner 1.9.1
[12:01] <asac> AnAnt: then the patch (or wahtever i did needs to be properly adjusted/merged)
[12:01] <AnAnt> ok
[12:02] <asac> well. previous version couldnt be compiled too i guess
[12:02] <AnAnt> hang on, it seems I can patch chmsee 1.0.6 can be patched
[12:02] <asac> merging involves ensuring that previous patches are not lost
[12:02] <AnAnt> ok, I will work on it with upstream
[12:02] <asac> so dont just drop my patch
[12:02] <AnAnt> asac: it seems that I won't have to !
[12:03] <AnAnt> doh, how do I use quilt in a cdbs package ?
[12:04] <asac> man quilt
[12:05] <Jazzva> asac: could you review nspluginwrapper 1.3.0 :)? I've been using it for about a week or so, and  it's OK (meaning it's not crashing anymore than 1.2.2).
[12:05] <asac> yes
[12:06] <asac> we can upload that i think do we know what changes were done there?
[12:06] <asac> do we have latest svn or release?
[12:06] <asac> maybe latest svn is better ?
[12:06] <Jazzva> asac: we have latest 1.3.0 (released as tar.gz). I don't know the state of latest svn
[12:06] <asac> AnAnt: what i mean is: there is nothing special about quilt wrt packaging or not packaging. the cdbs-edit-patch thing is not use. you just use quilt directly
[12:10] <AnAnt> asac: I mean what should I include in rules file
[12:12] <asac> AnAnt: dpkg -L quilt | grep cdbs.*mk
[12:12] <AnAnt> yeah found it, thanks
[12:13] <Jazzva> asac: do you want me to update to the latest svn_
[12:13] <Jazzva> ?
[12:14] <asac> Jazzva: no. just review what has happened in between for now would be great
[12:15] <eagles0513875> morning asac :)
[12:15] <asac> hi
[12:23] <Jazzva> asac: some improvements, afaics. last commit was on 17. january.
[12:38] <asac> ok
[12:39] <asac> lets get 1.3.0 up then and review if the patches are worth taking
[12:39] <Jazzva> 3 patches are already submitted upstream, but no comment from upstream yet
[12:40] <Jazzva> asac: this should be the link to the branch http://code.launchpad.net/~jazzva/nspluginwrapper/1.3.0
[12:43] <AnAnt> asac: ok, would you sponsor this: LP 416346
[12:56] <asac> i will check this later
[12:56]  * asac on a MIR rush
[13:03] <mac_v> AnAnt: did you get the xsplash bug mail?
[13:11] <AnAnt> mac_v: oh, you're here, yes, thanks
[13:12] <AnAnt> mac_v: didn't check the link yet
[13:12] <mac_v> :)
[15:06] <asac> seems someone sponsored chmsee already
[15:08] <asac> Jazzva: you didnt base on current lp:nspluginwrapper?
[15:23] <Jazzva> asac: Hmm, I did, but I uncommitted changes related to 0ubuntu6.
[15:23] <Jazzva> those are revisions 54-56
[15:24] <Jazzva> and then applied diff from the archive.
[15:24] <Jazzva> brb, need to go outside and buy cigarettes.
[15:35] <plun> Hello asac around ?
[15:36] <plun> Hve you tested this...?  http://blogs.gnome.org/dcbw/2009/07/10/unwire-with-networkmanager/
[15:37] <plun> have
[15:38] <plun> Also tested with gnome-bluetooth from SVN but with no succes
[15:40] <asac> not yet tested. how does it fail? NM not seeing it?
[15:42] <plun> Hello asac,  it just dont give me this option...http://ubuntu-pics.de/bild/22501/3_bt_pan_1kQDA9.png
[15:45] <Jazzva> asac: I'm back, if you need any more info.
[16:03] <asac> Jazzva: on a call. ~30min
[16:21] <plun> and me...    :)...  lost in the jungle  ;)
[17:18] <plun> asac  ???
[17:43] <asac> sorry ... was on a call ... will be back in 2 hours ... far tooo hot to stay inside any minute longer
[17:43] <asac> plun: Jazzva: ^^
[17:45] <Jazzva> asac: no prob. I'm studying (taking a pause atm), so I might be a bit unresponsive later. Ping me when you come back, and I will see the message. Have fun...
[19:50] <fta> Mook_sb, http://launchpadlibrarian.net/30582954/buildlog_ubuntu-jaunty-amd64.songbird_1.4.0~a~svn20090820r14593-0ubuntu1~usd1~jaunty_FAILEDTOBUILD.txt.gz gasp, did something change?
[19:51] <Mook_sb> fta: hmm, we moved to bz2 instead of gz for xulrunner bits
[19:54] <fta> looking at my rules..
[19:59] <fta> Mook_sb, i used your make-xulrunner-tarball.sh
[19:59] <fta> -d
[19:59] <Mook_sb> hmm
[20:00] <fta>         sh ./make-xulrunner-tarball.sh $(XUL_SRC_DIR)/compiled/xulrunner-$(XUL_RELEASE)/dist/bin $(SRC_DIR)/dependencies/linux-$(MACHINE)/xulrunner/$(XUL_RELEASE) xulrunner.tar.gz
[20:01] <fta> should I just change the last arg?
[20:01] <Mook_sb> it'a using $TAR xzvhf, so... that doesn't sound quite right; poking our build guy at the moment
[20:03] <Mook_sb> fta: :( he's using http://publicsvn.songbirdnest.com/vendor/trunk/xulrunner/make-xulrunner-tarball.sh instead, which uses -cjvh
[20:03] <Mook_sb> (but yes, change the last arg too)
[20:03] <fta> ok
[20:04] <Mook_sb> sorry about that :(
[20:26] <bdrung_> asac: when do you plan to release -devscripts 0.15?
[20:32] <asac> bdrung_: let me think ;) ... hmm
[20:32] <asac> there was something we still needed?
[20:32] <asac> anything you would like to land first?
[20:33] <bdrung_> asac: i want to implement the xpi-build target (as alternative to MOZ_XPI_BUILD_COMMAND)
[20:33] <bdrung_> asac: if you want to release soon, i can implement it today
[20:34] <bdrung_> asac: is there any progress i having a policy for debian version names?
[20:34] <asac> bdrung_: can we review if something prevents us from using it outside of cdbs?
[20:34] <asac> from what i see we have xpi-install and xpi-clean
[20:34] <asac> which you can just call
[20:34] <asac> if you use debhelper etc.
[20:35] <asac> give that those xpi- targets appear to become top level rules ... i wonder if we should name it a bit different
[20:35] <asac> e.g. no xpi-build (which would imply you should call that on your own?)
[20:35] <asac> or maybe implement xpi-build and provide a hook rule
[20:35] <asac> like xpi-build-impl/PACKAGE ?
[20:38] <bdrung_> asac: short away
[20:48] <asac> applet discussion: http://pastebin.ubuntu.com/256499/
[20:48] <asac> (just for me)
[20:59] <fta> Mook_sb, hm, nope, not good enough. http://launchpadlibrarian.net/30585187/buildlog_ubuntu-karmic-amd64.songbird_1.4.0~a~svn20090820r14593-0ubuntu1~usd2_FAILEDTOBUILD.txt.gz
[20:59] <fta> tar -j -x -p -f /build/buildd/songbird-1.4.0~a~svn20090820r14593/build-tree/songbird/dependencies/linux-x86_64/xulrunner/release/xulrunner.tar.bz2 -C /build/buildd/songbird-1.4.0~a~svn20090820r14593/build-tree/songbird/compiled/dist/xulrunner
[20:59] <fta> bzip2: (stdin) is not a bzip2 file.
[20:59] <fta> tar: Child returned status 2
[20:59] <fta> so something more is needed
[21:16] <bdrung_> asac: back to -devscripts.
[21:16] <bdrung_> asac: what do you mean with "can we review if something prevents us from using it outside of cdbs?"
[21:21] <Mook_sb> fta: sorry, was lunching/meeting; I don't understand that bzip2 error, but line 40 of the new make-xulrunner-tarball.sh should be echoing the command line, so maybe it's ending up using the old one?
[21:32] <BUGabundo> night ! o/
[21:38] <fta> Mook_sb, hmm
[21:38] <fta> ./tools/scripts/make-xulrunner-tarball.sh
[21:38] <fta> ./dependencies/vendor/xulrunner/make-xulrunner-tarball.sh
[21:38] <Mook_sb> yes, should be using the vendor/ version
[21:39] <fta> http://paste.ubuntu.com/256521/
[21:39] <fta> the other should be dropped then
[21:39] <fta> +one
[21:40] <Mook_sb> yes, it should
[21:47] <Mook_sb> okay, the stale scripts removed upstream.
[21:48] <fta> thanks
[22:02] <fta> asac, do you know which tool/site uses our customized user agent?
[22:17] <asac> fta: what do you mean?
[22:17] <asac> bdrung_: i mean that folks tend to think that mozilla-devscripts is only for cdbs. so i want to be sure it works well with debhelper and other approaches ;)
[22:18] <fta> asac, i remember that at some point, we stopped mentioning ubuntu in the UA and it broke some stats, like ubuntu loosing popularity or something
[22:18] <bdrung_> asac: ah, ok. i can test it if it would work with simple debhelper
[22:18] <asac> fta: i think all http logs have that user agent
[22:19] <asac> and some do analysis
[22:19] <asac> netcraft is probably one of them
[22:19] <asac> fta: if you ask if it would make sense to do something similar for chromium, then i would say yes
[22:19] <fta> hmm.. there was a bug and a lot of attention
[22:19] <asac> just do it in the same syntax that firefox uses
[22:20] <asac> so websites that really need to parse it can at least learn
[22:20] <asac> for me the problems incurred are worth the win
[22:20] <asac> but thats a subjecting pov
[22:20] <bdrung_> asac: https://bugs.launchpad.net/ubuntu/+source/pwdhash/+bug/416651
[22:20] <asac> for the distro having the distro stuff in there is definitly beneficial
[22:21] <asac> fta: there is the shiretoko bug
[22:21] <asac> but at least some of those sites actually hate the word Linux ;)
[22:21] <asac> you cannot help those
[22:21] <fta> asac, well, chromium won't do it apparently
[22:21] <fta> bug 246775?
[22:22] <bdrung_> asac: you could say "good os" instead of "Linux" :)
[22:22] <asac> fta: that was the bug when we dropped it (accidentially actually)
[22:22] <asac> i moved stuff to or from ubufox and forgot to commit one half iirc
[22:22] <BUGabundo> asac: 3G still broken :(
[22:22] <asac> BUGabundo: definitly not in the same way. so you need to be more specific
[22:23] <asac> like --debug logs etc
[22:23] <BUGabundo> oh ok
[22:23] <BUGabundo> on next boot and upgrade
[22:23] <BUGabundo> I have to downgrade to old version for it to work
[22:23] <asac> wait till all three are there: nm + applet + mm
[22:23] <asac> hmm
[22:23] <asac> i need the log then
[22:23] <asac> the bug you filed is fixed ... pretty sure
[22:24] <BUGabundo> wait for the next batch of logs :)
[22:24] <BUGabundo> at least the behabior is *exaclty* the same
[22:29] <asac> i hav the feeling you are stuck with something old you built
[22:29] <asac> on your own ;)
[22:29] <asac> but well. file a bug and we can check that in depth
[22:29] <asac> have to go now .. and play a game
[22:30] <BUGabundo> eheh
[22:30] <BUGabundo> ok
[22:30] <BUGabundo> go play
[22:30] <BUGabundo> and let us suffer :)
[22:30] <fta> asac, http://code.google.com/p/chromium/issues/detail?id=17095
[22:32] <asac> fta: what is the full user agent atm?
[22:33] <asac> seems they explicitly want patches in downstreams
[22:33] <fta> Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/4.0.203.0 Safari/532.0
[22:35] <asac> thx ... looks like the epiphany webkit string
[22:36] <asac> they land a fix now ... not sure it goes into webkit directly though
[22:36] <asac> k bbl
[22:38] <BUGabundo> heyyy that looks like my android agent!!!!!!
[23:01] <bdrung_> asac: my idea of having a xpi-build target is not needed. the build/$(MOZ_EXTENSION_PKG) target could be used for long build commands. e.g. use http://paste.ubuntu.com/256553/ instead of http://paste.ubuntu.com/256554/
[23:01] <bdrung_> that should be documented
[23:17] <bdrung_> asac: i tried to combine xpi.mk with dh 7, but it failes. here's an example rule for adblock-plus: http://paste.ubuntu.com/256563/
[23:18] <bdrung_> asac: if someone can hack in perl, following simple rule would be cool:
[23:18] <bdrung_> %:
[23:18] <bdrung_> \tdh --with xpi $@
[23:34] <asac> bdrung_: just override_dh_auto_install:
[23:35] <asac> bdrung_: just override_dh_auto_install: xpi-install
[23:35] <asac> doesn t work either?
[23:35] <asac> why do you think that override_dh_auto_install: is the right hook?
[23:35] <bdrung_> asac: doesn't work either
[23:36] <bdrung_> asac: why not override_dh_auto_install?
[23:37] <bdrung_> asac: xpi-install is equivalent to "make install", isn't it?
[23:45] <asac> bdrung_: i had no idea about dh 7 ... but looked at code. either  i miss something or its not extensiable at all
[23:45] <asac> it fails because it doesnt know about xpi-install target and because its run with catch-all rule %:
[23:45] <asac> it thinks it must be a sequence
[23:45] <asac> so we need to add a sequence somehow ;)
[23:46] <asac> didnt see how thats doable from looking at /usr/bin/dh ;) ... fail
[23:46] <bdrung_> man dh
[23:46] <bdrung_> %: is only used if there is no other rule
[23:46] <bdrung_> asac: whats a "sequence"?
[23:47] <asac> well. look at the code
[23:47] <asac> i get "xpi-install is not a sequence"
[23:47] <asac> a sequence is a sequence of commands
[23:47] <asac> in dh code its basically the full list of dh_ commands
[23:47] <asac> in some order
[23:47] <bdrung_> sequence = command for the rule
[23:47] <asac> and then done in a way that you can override them
[23:48] <micahg> asac: have you seen bug 416627
[23:48] <asac> well. the error comes from dh
[23:48] <asac> so the catch all rule is called ... dont ask me why
[23:48] <asac> micahg: yes i am aware of that bug
[23:48] <asac> its tricky thing
[23:49] <micahg> ok, does have to do with making it the default?
[23:49] <asac> the patch for that should probably be adapted for non-default builds
[23:49] <bdrung_> asac: make[2]: *** Keine Regel, um »xpi-install« zu erstellen.  Schluss.
[23:49] <asac> we have a patch that restarts using that path so you can restart firefox even though the firefox version/directory change
[23:49] <asac> d
[23:49] <asac> dh xpi-install
[23:49] <asac> dh: Unknown sequence xpi-install (choose from: binary binary-arch binary-indep build clean install)
[23:50] <micahg> yes, but shouldn't it use the original command like /usr/bin/firefox-3.5?  Shouldn't the symlink just change?
[23:50] <bdrung_> asac: because xpi-install is missing, dh xpi-install is run. so why is xpi-install missing?
[23:52] <micahg> asac: Medium -> Triaged -> Assign to you?
[23:52] <micahg> or is this something I might be able to fix in the patch? :)
[23:56] <asac___> 00:49 < bdrung_> asac: make[2]: *** Keine Regel, um »xpi-install« zu erstellen.  Schluss.
[23:57] <asac___> 00:49 < asac> we have a patch that restarts using that path so you can restart firefox even though the firefox version/directory change
[23:57] <asac___> 00:49 < asac> d
[23:57] <asac___> 00:49 < asac> dh xpi-install
[23:57] <asac___> 00:49 < asac> dh: Unknown sequence xpi-install (choose from: binary binary-arch binary-indep build clean install)
[23:57] <asac___> 00:50 < asac> thats with MAKE ....
[23:57] <asac___> 00:50 < asac> your make is probably wrong
[23:57] <asac___> 00:50 < asac> you ened to do make -f $(CURDIR)/debian/rules xpi-install
[23:57] <asac___> 00:52 < asac> or use ...: xpi-install
[23:57] <asac___> 00:52 < asac> that has the same error afaict
[23:57] <asac___> 00:53 < asac> so solution is to make -f /usr/share/.../xpi.mk xpi-install ;)
[23:58] <micahg> (05:52:05 PM) micahg: asac: Medium -> Triaged -> Assign to you?
[23:58] <micahg> (05:52:48 PM) micahg: or is this something I might be able to fix in the patch? :)
[23:58] <asac___> micahg: the problem is that we have a script
[23:59] <asac___> so we cannot create a link to the right binary and then $0 would be correct
[23:59] <micahg> you can't see where the original call was from?
[23:59] <asac___> no
[23:59] <asac___> but i have an idea
[23:59] <micahg> ok, then can we just set it to launch based on version?
[23:59] <asac___> creating a /usr/bin/firefox-real -> /usr/lib/firefox-VERSION/firefox
[23:59] <asac___> and runing that
[23:59] <asac___> from the firefox script