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