[01:32] <BUGabundo> asac: seems we need some udev love : http://code.google.com/p/proxoid/wiki/installationLinux
[01:39] <BUGabundo> asac: manage to proxy my internet via my !android over USB with http://code.google.com/p/proxoid
[02:39]  * BUGabundo mv /home/bugabundo /media/bed
[06:35] <B9> i wish ur crew would sort it so I can see Tibetan script with my browser of choice, i'm being seduced away by Opera
[12:17] <fta> asac, the last nmt commit broke the g-o-s target
[12:17] <fta> sed: -e expression #1, char 9: unterminated `s' command
[12:17] <fta> 0
[12:18] <fta> asac,  sed -e 's/\.\.\./'  <= need another /
[12:21] <asac> hmm
[12:21] <asac> i tested it ... no.
[12:21] <asac> i am not entirely happy how we get the short revision
[12:22] <asac>  sed -e 's/\.\.\.$//'`;
[12:22] <asac> hmm ... gues its a double $$
[12:23]  * asac tests
[12:23] <fta> oh, i just watched the logs, not the branch, right $$
[12:24] <fta> for some reason, i broke the summary too
[12:25] <asac> modified debian/rules
[12:25] <asac> Committed revision 111.
[12:25] <asac> let me check all the other branches
[12:26] <asac> ok the other branches dont have that feature yet
[12:26]  * asac thinks this git logic should go somewhere in cdbs or something
[12:26] <asac> we currently copy the code everywhere
[12:27] <asac> wonder if folks wouzld feel offended if i commit this as git.mk ;)
[12:27] <asac> guess rather nmt-git.mk so folks can invent their own thing
[12:28] <asac> ok that explains why nm wasnt uploaded for a few days :/
[12:28]  * asac should read more carefullly the logs
[12:28] <asac> fta: hwo about putting in email title. "FAILED"
[12:28] <asac> so i know where i should look closer?
[12:28] <fta> it's not easy to catch this
[12:28] <asac> hmm
[12:28] <fta> it doesn't really fail
[12:29] <asac> fta: but the upload failed?
[12:29] <fta> did it?
[12:29] <asac> yesterday someone wondered why there were no uploads for a few days
[12:29] <asac> let me check
[12:29] <asac> hmm
[12:29] <asac> 6hours ago it worked
[12:29] <asac> so what is broken? ;)
[12:30] <fta> the version ends with a .
[12:30] <asac> hmm ... applet is broken on lpia?
[12:30] <asac>  libgnome-bluetooth-dev: Depends: libgnome-bluetooth2 (= 2.27.5-1ubuntu1) but it is not installable
[12:30] <asac> hmm
[12:31] <asac> fta: yeah
[12:31] <asac> fta: ok that is not worst case
[12:31] <asac> ;)
[12:31] <asac> at least something
[12:31] <asac> right one ... even from same upstream commit would be higher fortunately
[12:36] <fta> hm how are we supposed to upgrade gwibber now? do we need to kill the daemon manually?
[12:40] <asac> i think so
[12:40] <asac> i think postinst should get  "killall" ;)
[12:40] <asac> kenvandine: ^^
[12:41] <asac> we also did a "killall nm-system-settings" in nm now for the trunk migration ;)
[12:41] <asac> unless tony didnt commit that
[12:41] <asac> but i told him to
[12:43] <asac> maybe gwibber client should do a handshake and if it detects a version mismatch try to kill it once
[12:43] <asac> not sure if gwibber client is ready for NameOwnerChanged though
[12:43] <asac> most likely not ;)
[12:44] <asac> almost all dbus clients dont do it right :/
[12:44] <asac> they always assume the server will never crash/restart
[12:45] <fta> Traceback (most recent call last):
[12:45] <fta>   File "/usr/lib/python2.6/dist-packages/gwibber/client.py", line 829, in <lambda>
[12:45] <fta>     dialog.connect("response", lambda *a: dialog.hide())
[12:45] <fta> NameError: free variable 'dialog' referenced before assignment in enclosing scope
[12:45] <fta> i can't close the About box
[12:45] <asac> yeah
[12:45] <asac> you killed the daemon while it was running?
[12:46] <asac> or just the about box?
[12:46] <fta> no, existed the client, killed the 5 days old daemon, restarted the client
[12:46] <fta> -s
[12:50] <asac> i probably used too much glib ;)
[12:50] <asac> any hints how to best do lists etc. in plain C without pulling in any lib?
[12:51] <asac> i started to write my own minilib just because i couldnt find anything ;)
[12:51] <asac> which feels like i am doing something wrong ;)
[12:54] <fta> nope, i wrote my own too
[12:54] <asac> isnt there some public domain cut-and-paste lib somewhere? ;)
[12:55] <fta> donno, i have the probably bad habit to recode everything i need
[12:55] <asac> what i want is basic datastructures like lists etc.
[12:55] <asac> and mainloop
[12:55] <asac> with IO and timeout/idle
[12:56] <asac> better rewrite than pull-in half of the world ;)
[12:58] <asac> its really a problem if you want to provide something tiny that can be wrapped for qt and glib
[13:00] <asac> bug 423694
[13:20] <bdrung_> asac: http://packages.ubuntu.com/karmic/firefox-dev needs an update, doesn't it?
[13:23] <asac> good question
[13:23] <asac> probably yes.
[13:23] <asac> though it was always empty
[13:23] <asac> should at least depend on xulrunner-dev
[13:24] <asac> bdrung_: want to add it? :)
[13:24] <asac> btw, i will look at those xpi cleanup merges once i can think clearly again ;)
[13:24] <asac> my head is exploding with this bad cold
[13:27] <bdrung_> asac: i thought, it should point to firefox-3.5 instead of firefox-3.0 or is it totally superseeded by xulrunner-dev?
[13:28] <bdrung_> get well soon.
[13:35] <fta> asac, i'm not sure upstream with fix chromium for the new zlib bug. they said we are at fault
[13:36] <fta> asac, http://paste.ubuntu.com/265545/
[13:45] <asac> fta: we are at fault? is that code from a patch we carry?
[13:46] <fta> https://edge.launchpad.net/ubuntu/karmic/+source/zlib/1:1.2.3.3.dfsg-13ubuntu2
[13:47] <asac> did you talk to mvo?
[13:49] <asac> ok updated the bug
[13:49] <asac> bug 402178
[13:50] <fta> asac, mvo is not here, i pinged colin in #-devel
[13:50] <fta> he was part of the discussion
[13:50] <fta> but he's not there either
[13:52] <asac> fta: he will answer i guess ...
[13:52] <asac> he seemed to have been in doubt about the patch. so giving him proof might help convince him to take another road ;)
[13:53] <fta> in the meantime, i will disable system zlib :P
[13:55] <asac> fta: btw, i own the chromium ITP now on debian side
[13:55] <fta> i need to restart this damn xchat, sick of it opening epiphany
[13:55] <fta> brb
[13:55] <asac> so once i get a stab on the licensing i will try to get a ftpmaster assigned who does the handhelding for getting this punched in
[13:56] <fta> fixed, good
[13:56] <asac> doesnt it use gnome-www-browser?
[14:00] <fta> xdg-open
[14:01] <fta> itself calling gnome-open
[14:04] <fta> asac, will the itp mean moving away from bzr?
[14:04] <asac> fta: why?
[14:04] <asac> in no way
[14:05] <fta> i remember the v8 itp sunk after a bzr import debacle
[14:05] <asac> i will just be downstream from your builds and it also will help getting it into ubuntu
[14:05] <asac> we just dont have the archive admins up to this task ;)
[14:05] <asac> fta: you say the guy that owned it?
[14:05] <asac> thats why i took over it
[14:05] <asac> so that mess stopps and we can just use the ubuntu packages everywhere
[14:06] <fta> good
[14:06] <fta> so what's needed to push the 1st batch?
[14:06] <asac> i need to go through the un-documented licenses
[14:06] <asac> and document somehow
[14:06] <asac> e.g. prepare all the paperwork so i can convince an ftp master to believe us that all is good ;)
[14:07] <fta> upstream is ready to help, if we file a bug pointing to the files we're not happy with
[14:07] <asac> yeah
[14:07] <asac> thats what i mean
[14:07] <fta> i've been told a lawyer could be assigned to that
[14:07] <asac> i plan to use your script and then check if there are things that need to be documented
[14:08] <fta> good
[14:08] <asac> maybe we can even make your script generate the new copyright file format
[14:11] <fta> probably yes
[14:12] <fta> what about the codecs package?
[14:12] <asac> not sure
[14:13] <asac> i think in debian all ffmpeg decoders are in
[14:13] <asac> but not many encoders
[14:13] <asac> not sure why chromium would need the encoders
[14:13] <fta> they don't
[14:13] <fta> i mean, it doesn't
[14:13] <asac> yeah. so we should check if we can just package those parts up that are decoders and verify that the debian ffmpeg packages have all those codecs
[14:14] <fta> the thing is more it's not the same ffmpeg, the chromium one is multi-threaded, from another upstream branch
[14:14] <asac> yes
[14:14] <asac> but it shouldnt be that much different wrt to packaging
[14:15] <asac> and how its split/stripped
[14:15] <asac> at least thats what i would expect
[14:16] <fta> http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-codecs-ffmpeg.head/annotate/head%3A/debian/rules
[14:19] <fta> asac, ff 3.5 is still red
[14:19] <asac> fta: did you compare with the debian ffmpeg source package?
[14:19] <asac> fta: yes.
[14:19] <asac> sorry about that :) /me not motivated enough on 1.9.1 branch ;)
[14:20] <asac> let me get a upstream clone at least
[14:20] <fta> http://git.debian.org/?p=pkg-multimedia/ffmpeg-debian.git;a=blob;f=debian/rules;h=47e7cd6350740eb1b6b70fd0bcccb2b3da6f96ba;hb=HEAD
[14:20] <fta> http://git.debian.org/?p=pkg-multimedia/ffmpeg-debian.git;a=blob;f=debian/confflags;h=b416a01adfa2f9ffd55fdf066a90f97285f8652b;hb=HEAD
[14:20] <asac> get-orig-source.sh
[14:21] <asac> http://git.debian.org/?p=pkg-multimedia/ffmpeg-debian.git;a=blob;f=debian/get-orig-source.sh;h=6001b719c091a7cf4ea0633d86e5f63a4615267e;hb=HEAD
[14:21] <asac> looks pretty straight forward
[14:22] <asac> lets talk to siretart ;)
[14:23] <fta> the m-t branch is supposed to be merged at some point
[14:23] <asac> asked him to join this channel. so if he shows up we have to talk ;)
[14:28] <fta> grep: write error: Broken pipe
[14:28] <fta> hm
[14:28] <fta> in nmt logs
[14:29] <asac> cant see it in the last i have
[14:29] <asac> no hit for pipe
[14:30] <asac> guess i should also add the > /dev/null for a few more greps
[14:30] <asac> 0
[14:30] <asac> 1
[14:30] <fta>     my $maint = `grep '^ -- ' debian/changelog | head -1 | sed -e 's/^ -- \(.*\)  .*/\1/'`;
[14:31] <asac> http://paste.ubuntu.com/265567/
[14:31] <fta> i don't see how that could produce a broken pipe
[14:31] <asac> ah thats yours
[14:31] <fta> and grrr, why did i use shell inside perl :P
[14:31] <asac> fta: head -1?
[14:31] <asac> head -n1
[14:31] <asac> ;)
[14:31] <asac> or am i old/young?
[14:31] <fta> head -1 is fine
[14:31] <fta> you're too young ;)
[14:32] <asac> feels like a feature that could go away ;)
[14:32] <asac> thats what i thought. felt like a old thing ;)
[14:32] <fta> i don't think so, it's been there since like forever
[14:32] <asac> yeah
[14:32] <asac> back those days folks found it smart to do things like that ;)
[14:33] <asac> /magic/
[14:33] <asac> fta: is http://paste.ubuntu.com/265567/ ok in your opinion?
[14:33] <asac> ;)
[14:33] <fta> grep -c "orig" >/dev/null  ???
[14:34] <asac> look at nmt log
[14:34] <asac> 0
[14:34] <asac> 1
[14:34] <fta> try grep -q
[14:34] <asac> ;)
[14:35] <asac> fixed
[14:36] <fta> if echo $(1) | grep -c "orig" >/dev/null || echo $(DEB_VERSION) | grep -c "git" > /dev/null;  looks wrong to me
[14:36] <asac> but it works afaik ;)
[14:36] <asac> now its grep -q -c
[14:36] <asac> it means: if its orig or git ... do this.
[14:37] <fta> either "if [ xx ] || [ xx ] ; then", or if test xx || test xx ; then"
[14:37] <asac> no that works
[14:37] <fta> grep -q is enough, no need for -c
[14:37] <asac> if true || false; then echo yes; fi
[14:38] <asac> even works in posh ;)
[14:38] <asac> yeah
[14:38] <asac> now it happened ;)
[14:38] <fta> -c forces a count, while -q returns zero if there's a match (beware, it's reversed)
[14:38] <asac> te -c is still in there ;)
[14:38] <asac> thats not reversed
[14:38] <asac> grep -c is true if there is a match and false otherwise
[14:39] <asac> its not a "test"
[14:39] <asac> just a return value thing if you dont use test []
[14:39]  * fta is tired
[14:39] <asac> if echo test | grep -q -c test; then echo yes; fi
[14:39] <asac> yes
[14:39] <asac> hehe
[14:40] <asac> but i agree -c isnt needed
[14:40] <asac> without it it even fast succeeds and so its better resource wise
[14:40] <asac> if its a long input
[14:42] <asac> i will tell cyphermox to clean stuff up and then put it everywhere
[14:42] <asac> ;)
[14:42] <asac> j.k.
[14:42] <fta> strange, the broken pipe is only in nmt, not umd, ucd, ...
[14:44] <asac> busted changelog format somewhere?
[14:44] <asac> odd
[14:45] <asac> grep '^ --' debian/changelog looks normal
[14:47] <cyphermox> put what everywhere?
[14:47] <asac> cyphermox: synching all the copise for our get-orig etc. snippets
[14:48] <cyphermox> ah!
[14:48] <asac> we need to put it somewhere centralized at somepoint
[14:48] <cyphermox> indeed
[14:49] <cyphermox> a quickly script for daily build debian/rules?
[14:50] <asac> maybe. but i dont think the snippet belongs there
[14:50] <asac> quickly could add it if you want to use git
[14:50] <asac> at the include ... line ;)
[14:51] <asac> but integrating xpi.mk into quickly would be cool
[14:51] <cyphermox> ttyl
[15:11] <fta> hm, what is this:  http://www.startpanic.com/
[17:34] <fta> asac, checking for sqlite3 >= 3.6.16... Requested 'sqlite3 >= 3.6.16' but version of SQLite is 3.6.10 (jaunty)
[17:34] <fta> http://launchpadlibrarian.net/31369641/buildlog_ubuntu-jaunty-amd64.xulrunner-1.9.1_1.9.1.4~hg20090904r26338%2Bnobinonly-0ubuntu2~umd1~jaunty_FAILEDTOBUILD.txt.gz
[18:24] <fta> mozilla 508104
[18:33] <asac> thx
[18:38] <asac> fta: https://bugzilla.mozilla.org/show_bug.cgi?id=508104#c10
[18:38] <fta> the same
[18:38] <asac> no ;)
[18:38] <asac> it has changed ;)
[18:38] <asac> i posted a comment
[18:40] <fta> hm, i've updated our branches
[18:40] <asac> we need to unpatch it
[18:40] <asac> for 1.9.1
[18:40] <asac> cannot push that out as a security update
[18:41] <asac> would require serious baking to just revert to in-source ... and as i read the bug its mostly because of stupid win crashes
[18:41] <asac> i hope i can get it landed upstream quickly
[18:41] <asac> unfortunately its sat ;)
[18:44] <fta> sohuld i uncommit?
[18:44] <asac> fta: depends if you want the dailies to not be broken
[18:45] <asac> actually i think its ok on .head
[18:45] <fta> here, i don't mind
[18:45] <asac> we want to track what they say
[18:45] <asac> i am just concerned about the stable branches
[18:45] <asac> i think we have that version in karmic?
[18:45] <asac> want to keep system sqlite in karmic all the time
[18:46] <asac> in case there are issues with our version
[18:48] <fta> yep, it's jaunty-
[18:55] <fta> asac, is there something new in nmt? i need to test the bot.. gwibber is not moving at all, the other pockets are too big
[18:55] <asac> fta: what?
[18:55] <asac> there is something new in nmt
[18:56] <asac> its a new target "get-snapshot-info"
[18:56] <asac> but thats not used anyway iirc
[18:56] <fta> doesn't matter, it's just to test the new summary ;)
[18:57] <asac> yeah
[18:57] <asac> i did commits today
[18:57] <asac> not upstream, just in bzr
[18:58] <fta> ok
[18:58] <asac> so far the mail title looks promising
[18:58] <asac> not sure how to spot the actual error though
[18:58] <asac> maybe you can put whatever lines lead to the FAILED trigger in the summary?
[18:58] <asac> or mark them somehow in the log?
[19:02] <fta> asac, did you get the last one? nmt
[19:07] <asac> checking
[19:07] <asac> - network-manager113: Alexander Sack
[19:07] <asac> -> whitespace missing
[19:08] <asac> quite nice
[19:11] <asac> fta: did you also loose the app icons in the window decoration?
[19:11] <asac> for me there is now a button like thing
[19:11] <asac> which i dont like ;)
[19:12] <fta> hm, no, but i didn't restart X since Aug31
[19:12] <fta> i will remove the "New packaging revisions", it's already in the "sync results"
[19:13] <asac> i prefer the New packaging revision
[19:13] <asac> because there is no daily merge in
[19:13] <asac> and the revisions match those of the .head tree in consequence
[19:13] <fta> hm
[19:13] <asac> fta: idea:
[19:14] <asac> shorten the sync result to only include the first two lines like:
[19:14] <asac>   - network-manager: merged rev #113 from network-manager.head
[19:14] <asac>     * 103: Fabien Tassin 2009-09-05 [merge] * Merge with network-manager.head #113
[19:14] <asac>     *   81.1.32: Alexander Sack 2009-09-05 * fix noisy output: use grep -q -c rath...
[19:14] <asac>    * ...
[19:15] <asac> and having alternatively upstream commits in the summary for low/mid noise trees would definitly make this even more useful ;)
[19:16] <asac> but that wouldnt work for CVS LOCAL_BRANCH things obviously
[19:16] <asac> not sure if your bot uses LOCAL_BRANCH for that
[19:16] <asac> guess not
[19:18] <fta> my summary is based on the logs from the others scripts
[19:19] <fta> so the upstream commit should come from one the scripts, probably the update one, calling get-orig-source
[19:19] <asac> yeah. but LOCAL_BRANCH is kind of internal to the package so you probably doest use it
[19:19] <asac> hmm
[19:19] <asac> feels complicated
[19:20] <asac> so maybe not ;)
[19:21] <fta> one idea could be to add an optional parameter to g-o-s, like PREVIOUS_COMMIT, and let it display whatever it wants, so it could be re-used in the summary
[19:21] <fta> providing a prefix
[19:22] <fta> but it means custom g-o-s rules
[19:24] <asac> http://www.overclock.net/windows/569458-microsoft-attack-linux-retail-level-probably.html
[19:25] <asac> "Nothing is as complete as Windows 7" ;)
[19:25] <asac> nasty
[20:10] <fta> asac, given a bzr merge, is it possible to find the rev id of the original revision? (without using the comment)
[20:12] <asac> fta: so if its just a one way merge you are probably able to use the second parent line.
[20:13] <asac> check this out:
[20:13] <asac> http://paste.ubuntu.com/265714/
[20:13] <asac> parent: asac@ubuntu.com-20090803120745-gmprxt1gdcaj3t8p
[20:13] <asac> parent: asac@ubuntu.com-20090701011726-qbf9iy0izaacrqdw
[20:13] <BUGabundo> heet
[20:13] <asac> == revision-id: asac@ubuntu.com-20090701011726-qbf9iy0izaacrqdw
[20:13] <BUGabundo> hey
[20:13] <asac> fta: thats with --show-ids
[20:13] <asac> you can use that revision with revid:LONGREVISIONID
[20:13] <asac> but i guess you know
[20:14] <fta> fta@cube:/data/bot/firefox-3.1.head.daily $ bzr log -r 613 --show-ids -n 0 | grep 462
[20:14] <fta>   * Merge with firefox-3.1.head #462
[20:14] <fta>       (merge r462 from lp:~jdstrand/firefox/firefox-3.5-apparmor)
[20:14] <asac> why would you grep for 462?
[20:15] <fta> that's the revid i want to find
[20:15] <asac> yeah
[20:15] <asac> i already told you how ;)
[20:15] <asac> well ... once you have the long revision id like above you do:
[20:15] <asac> bzr log -r revid:LONGREVISIONID -l1 | grep revno: | sed EXTRACTREVNO
[20:16] <fta> ok, thanks
[20:16] <asac> makes sense?
[20:17] <asac> i think thats the most reliable way
[20:19] <fta> grr, grep: write error: Broken pipe
[20:20] <fta> fta@cube:/data/bot/firefox-3.1.head.daily $ bzr log --line | grep '\[merge\]' | head -1
[20:20] <fta> 613: Fabien Tassin 2009-09-03 [merge] * Merge with firefox-3.1.head #462
[20:20] <fta> grep: write error: Broken pipe
[20:21] <fta> grep | something seems to complains now, it's a regression
[20:22] <fta> er..
[20:22] <fta> fta@cube:/data/bot/firefox-3.1.head.daily $ bzr log --line | grep '\[merge\]' | head -1 | cut -d: -f1
[20:22] <fta> 613
[20:22] <fta> grep: write error: Broken pipe
[20:22] <fta> fta@cube:/data/bot/firefox-3.1.head.daily $ bzr log --line | grep '\[merge\]' | cut -d: -f1 | head -1
[20:22] <fta> 613
[20:22] <fta> fta@cube:/data/bot/firefox-3.1.head.daily $
[20:46] <asac> broken mem ;)?
[21:03] <fta> i don't think so
[21:24] <fta> damn, it didn't work
[21:44] <bahuvrihi>  Hi! I'm using Firefox 3.5.2 from Ubuntu repo and my userContent.css is not working. What might be the reason?
[23:00] <alicemirror> hi to all...
[23:01] <alicemirror> I need for test to know how I can change the response of http headers duringe client request. can anyone help me ?