[00:05] <asac> what is n2n?
[00:05] <BUGabundo> ntop.com
[00:05] <asac> you can add tun to /etc/modules to ensure its loaded
[00:06] <BUGabundo> asac: #ubuntu+1 is tunnign on it
[00:07] <BUGabundo> modprobing tun fixes
[00:07] <BUGabundo> it
[00:07] <BUGabundo> seems lucid stop modprobing tun 2 weeks ago
[00:07] <BUGabundo> now we are trying to target a few more tests :\
[00:09] <asac> check older kernel
[00:09] <asac> maybe tun was not a module before
[00:10] <fta> hm, java is not working out of the box in chromium, seems like a symlink is needed
[00:11] <fta> weird
[00:11] <BUGabundo> fta: was fine one week ago
[00:11] <BUGabundo> when I tested
[00:12] <fta> can't get my dynamic stock charts
[00:14] <asac> fta: where does chromium look for plugins?
[00:14] <asac> mozilla/plugins?
[00:15] <asac> or also xulrunner-addons/plugins?
[00:15] <fta> it's a bit late to buy stock though, last quotation day of the year
[00:15] <fta> i should probably wait
[00:16] <asac> tomrrow trading for half a day in the US afaik
[00:17] <fta> yep
[00:18]  * asac still hopes for a new bank collapse :)
[00:18] <asac> but i think that is over for now
[00:19] <BUGabundo> (12:18:38 AM) seg|ars: the new backend is uncrashable
[00:19] <BUGabundo> (12:19:03 AM) seg|ars: no seriously, in the next major version the backend is significantly more stable
[00:19] <BUGabundo> fta: ^^^^^^^^^ (gwibber)
[00:19] <asac> problem is that housing prices only got boosted here in hamburg  during this whole crisis ... i hoped i could buy a cheap flat ;)
[00:20] <BUGabundo> (12:04:51 AM) seg|ars: yeah, trunk has been quiet because of this rewrite
[00:20] <BUGabundo> (12:04:59 AM) seg|ars: I haven't even pushed it to a branch yet. It's not quite usable at the moment
[00:20] <BUGabundo> (12:05:35 AM) seg|ars: I'm working on it full-time this week
[00:20] <BUGabundo> asac: boosted? here they drop like rocks
[00:20] <asac> yeah
[00:20] <asac> here they doubled ;)
[00:20] <BUGabundo> WOUTCH
[00:20] <fta> here too
[00:20] <asac> seems everyone wanted a safe investment
[00:20] <asac> and moved their money from spain etc. to hamburg downtown :)
[00:21] <asac> really a pity
[00:21] <asac> i hoped sooo much ;)
[00:21] <fta> current prices are not worth it, far from it
[00:21] <asac> qwll. in paris that might be true
[00:22] <asac> but german city prices were really undervalued before compared to other european countries ... so i dont see them falling agian
[00:22] <asac> :(
[00:22] <asac> maybe if interest doubles
[00:22] <asac> but that would kill spain etc. even more i guess :)
[00:22] <asac> so i dont see that happening either
[00:23] <BUGabundo> (12:20:01 AM) seg|ars: it uses a model similar to chrome. All of the message retrieval and processing operations are performed in separate processes
[00:23] <BUGabundo> (12:20:15 AM) seg|ars: if any of those processes fail, even if they suffer a segmentation fault, the daemon just keeps on running
[00:23] <BUGabundo> (12:21:36 AM) seg|ars: the process pool is created at the beginning of a refresh cycle and destroyed at the end
[00:23] <BUGabundo> (12:21:43 AM) seg|ars: so it also completely insulates the backend against memory leaks
[00:23] <asac> thats n2n?
[00:23] <asac> whats the benefit of a peer-to-peer vpn ;)
[00:23] <asac> for isolated countries>
[00:23] <asac> ?
[00:24] <asac> building bridges?
[00:26] <asac> or just easy to setup?
[00:26] <fta> seems that's gwibber
[00:27] <BUGabundo> asac: that's gwibber
[00:27] <asac> heh
[00:27] <BUGabundo> from segphault
[00:27] <fta> which has been dead for weeks/months
[00:27] <asac> yeah
[00:27] <BUGabundo> in #statusnet
[00:27] <BUGabundo> why do you think I'm cc you ?
[00:27] <BUGabundo> lol
[00:27] <asac> i had no time to talk about that at UDS unfortuantely
[00:27] <asac> i tried to prevent such things to happen
[00:27] <fta> i would love more controls in gwibber, to depend less on the web interface
[00:28] <asac> i didnt recognize his nick :)
[00:28] <asac> but more controls doesnt happen by making a multi-process backend framework
[00:28] <fta> asac, prevent which things to happen?
[00:29] <BUGabundo> fta: for it to stale
[00:29] <asac> that they put so much work into making a super scalable multi-process bakcend
[00:29] <fta> sure, multi-process for gwibber seems weird to me
[00:29] <asac> its a big misunderstanding. they didnt know how to do it right
[00:29] <BUGabundo> do you want me to tell that to segphault ?
[00:29] <BUGabundo> lol
[00:29] <asac> thats why they think it helps to make it even more complex ;)
[00:29] <asac> BUGabundo: i already raised that ... at least to ken
[00:29] <BUGabundo> ok
[00:30] <asac> unfortunately i had no time to thoroughly talk to him at UDS
[00:30] <asac> fta: web interface gets better though ;)
[00:31] <fta> yep, but that also means gwibber is lagging behind :P
[00:31] <asac> i think the reason for all this is that there were some omnious gwibber backend hangs because of facebook
[00:31] <asac> which i never saw after my final fixes ;)
[00:33] <BUGabundo> I don't even have FB account
[00:33] <asac> the outstanding thing is to define a good dbus api and properly deal with dbus timeouts (which still crash gwibber)
[00:34] <asac> those are less likely though
[00:35] <asac> ok so with some luck tomorrow we have working chromium for armel on karmic and lucid ;) in a public accessible ppa.
[00:35] <asac> would be a great EOY
[00:35] <asac> :-P
[00:36] <asac> then we have two weeks to get that in the archive for alpha-2 :-P
[00:37] <asac> but with even the gyp license bug i dont see that happening ;)
[00:37] <asac> fta: do all tests succeed in the ppa?
[00:38] <asac> on x86
[00:38] <fta> nope
[00:38] <fta> far from it
[00:39] <fta> various issues, ms fonts, network accesses forbidden, shared memory forbidden, and various other stuff
[00:40] <asac> what do they attempt to do with network access
[00:40] <fta> i wanted to enable perf tests, but i'm afraid it's not possible within the builders
[00:40] <asac> maybe you can fire up a http server during build on some unprivileged port on localhost
[00:41] <fta> test the http stack, dns stack, ftp stack, etc
[00:41] <asac> i think perf tests are the last we should care about :)
[00:41] <asac> yes, but what are they doing?
[00:41] <asac> special webpages
[00:41] <asac> ?
[00:41] <asac> from some public server
[00:41] <asac> ?
[00:41] <fta> i really need to compare our build with the official ones, some people claim we're slower
[00:42] <asac> is there data available to backup that claim?
[00:42] <fta> for network, sometimes it's against google.com, sometimes against localhost (they start a small sever locally)
[00:43] <fta> nope, just claims, no proof
[00:43] <asac> ok so google.com is the problem?
[00:43] <asac> that really feels like ok to skip
[00:43] <fta> no; even localhost doesn't work
[00:43] <asac> really?
[00:43] <fta> yep
[00:43] <asac> how?
[00:43] <asac> what port?
[00:43] <fta> i don't remember
[00:44] <asac> that would bust PGO for firefox
[00:44] <asac> we need a proxy for that too
[00:44] <BUGabundo> asac: how is PGO?
[00:45] <asac> dont know ;)
[00:46] <fta> dead ? ;)
[00:46] <asac> upstream doesnt use it afaik because it didnt work for them
[00:46] <asac> i will try again though ;)
[00:46] <fta> stuff like: Creating shared memory in /dev/shm/com.google.chrome.shmem.unit_tests-28518 failed: Permission denied
[00:46] <asac> yeah
[00:46] <asac> those i saw
[00:46] <asac> thats because its in a chroot i think
[00:46] <asac> bindmounting /dev somehow doesnt do that recursively for /dev
[00:46] <asac> i saw that in my chroot
[00:46] <fta> most likely fakeroot's fault
[00:47] <asac> so udev would need to create stuff for chroot i guess (no clue what i am talking about here)
[00:47] <asac> could be fakeroot ... but in chroot its definitly a problem in bindmount
[00:47] <asac> not sure if builders use a chroot in a xen image or a native xen image
[00:48] <asac> hmm. too bad i deleted he old builds
[00:48] <asac> maybe the tests worked on the real builders
[00:48] <asac> and now i only build on armel
[00:49] <asac> http://launchpadlibrarian.net/37208452/buildlog_ubuntu-karmic-i386.chromium-browser_4.0.283.0~svn20091226r35283-0ubuntu1~ucd1~karmic_FULLYBUILT.txt.gz
[00:49] <asac> fta: ^^thats last build log on real builders
[00:50] <asac> ok same issuue
[00:50] <asac> [6631:6631:1226/172727:443931680155:ERROR:base/shared_memory_posix.cc(192)] Creating shared memory in /dev/shm/com.google.chrome.shmem.SharedMemoryOpenCloseTest failed: Permission denied
[00:50] <asac> base/shared_memory_unittest.cc:131: Failure
[00:50] <asac> Value of: rv
[00:51] <asac> fta: where are the branches for the beta/dev channel?
[00:51] <asac> do you auto fork them with appropriate checkpoint commit?
[00:51] <asac> or dont you even do that in branches?
[00:52] <fta> hm, no, i forked .head once for each channel, then they will need merging from head :(
[00:53] <asac> well. that shouldnt be a problem, would it?
[00:53] <fta> the branches are on lp, like for trunk
[00:53] <fta> no, but it's manual
[00:53] <asac> feels natural. fork if upstream forks. then just track security landings on their branches
[00:53] <asac> then merge if they merge too
[00:53] <asac> of course you dont know when they merged and when they updated
[00:53] <asac> but maybe you can guess that by how the version scheme moves forward
[00:53] <asac> for that we first need to see non-merged landings on beta/dev channel upstream branches i guess
[00:55] <fta> the bot will just trigger new builds if either the packaging branch changed, or upstream published a new build
[00:56] <fta> it's just get-orig-source CHANNEL={beta,dev}
[00:56] <asac> sure
[00:56] <asac> but upstream has two ways to publish a new build
[00:56] <asac> a) update biuld with a cherry pick (security/stability)
[00:56] <asac> b) bump to new release (e.g. merge trunk/beta)
[00:57] <asac> for a) you just move the .beta/d.ev branch forward ... when b) happens you need to merge .head etc.
[00:57] <asac> but i think thats clear ;)
[00:57] <asac> err planned
[00:57] <fta> they don't merge, they fork off from trunk, and cherry pick as long as they stick to that branch
[00:57] <asac> right
[00:58] <asac> so when they switch dev to a new branch we need to merge from .head ... if a branch moves forward we can just bump changelog in beta/dev branches
[00:59] <asac> at least i would hope they dont make new trunk forks that lie in the past
[00:59] <asac> fta: licensecheck.pl doesnt recurse in directories?
[00:59] <asac> --hel pisnt that helpful ;)
[00:59] <fta> -r
[00:59] <fta> hm
[01:00] <fta> oh, mine?
[01:00] <asac> perl debian/licensecheck.pl  -r build-tree/src/
[01:00] <asac> error
[01:00] <asac> Unknown option: r
[01:00] <asac> Usage: debian/licensecheck.pl [options] directory -a           display all licenses found (default will hide whitelisted licenses) -h           this help screen
[01:01] <fta> i call licensecheck -r --copyright $dir
[01:01] <fta> so yes, it's recursive
[01:02] <asac> ok beause you have "filelist" in --help
[01:02] <asac> oh its just confusion. ok
[01:03] <asac> doesnt print anything :(
[01:03] <fta> the bug is moving forward
[01:03] <fta> wait
[01:03] <asac> really?
[01:03] <asac> gyp?
[01:03] <asac> cool
[01:04] <asac> if we cojuld upload that on jan 4 that would be a good step ;)
[01:04] <fta> no
[01:04] <fta> http://code.google.com/p/chromium/issues/detail?id=28291
[01:05] <fta> you should link yours there
[01:05] <asac> i cannot link even with my underpowers ;)
[01:05] <asac> cant do nothing bug comment and star ;)
[01:06] <fta> lol
[01:06] <fta> which one is yours?
[01:06] <asac> dunno ;)
[01:06] <asac> its filed against gyp
[01:07] <asac> http://code.google.com/p/gyp/issues/detail?id=133
[01:07] <fta> done
[01:09] <asac> fta: so that script buffers all results?
[01:09] <asac> it consumes cycles
[01:09] <asac> but doesnt dump anything
[01:09] <asac> i run that on the armel board fwiw ... so it will take some time to finish ;)
[01:09] <fta> it's needed to sort the results
[01:10] <fta> on arm! lol, run that locally, you're crazy
[01:11] <asac> i am too lazy to extract the source ;)
[01:11] <asac> also i am on a mini 9
[01:11] <asac> fta: how about dumping DEP-5 format ;)
[01:11] <asac> you already seem to sort that stuff somewhat.
[01:12] <asac> build-tree/src/third_party/yasm/source/patched-yasm/tools/python-yasm/pyxelator/
[01:12] <asac> is UNKNOWN
[01:12] <fta> DEP-5 format?
[01:12] <asac> yes. new parsable copyright format
[01:13] <asac> http://dep.debian.net/deps/dep5/
[01:13] <asac> i think using DIR/* for dirs with all files of same license would work
[01:13] <asac> otherwise listing them explicitly
[01:13] <asac> by dir
[01:13] <asac> so the Files: line doesnt get too long ;)
[01:14] <fta> it's possible, eveything is possible
[01:14] <asac> in theory you could probably dump all files for each license in one use Files: ;)
[01:14] <asac> well
[01:14] <asac> i hoped it would be easy for you ;)
[01:14] <fta> in fact, that's why i added -a
[01:15] <asac> i think i might be able to do something ;)
[01:15] <asac> checked the  code
[01:15] <asac> all i want to know is how to check length of the eys %{$$data{$dir}}
[01:15] <asac> keys
[01:15] <asac> in perl
[01:16] <asac> fta: any hint ;)?
[01:16] <fta> length("foo") => 3
[01:17] <fta> keys %hash returns a list
[01:17] <fta> length takes a string
[01:17] <asac> copyright info is probably quite incomplete atm?
[01:18] <asac> maybe we should just gen the full list ;)
[01:18] <asac> and not try to merge
[01:18] <asac> we would need to merge by copyright holder too
[01:18] <asac> hmm
[01:18] <fta> i sort by license
[01:18] <asac> yes. if we now could also sort by copyright holders within each dir that would be perfect
[01:19] <asac> probably requires some computing, but the files per dir list should be short enough :)
[01:20] <fta> iirc, i already did that
[01:20] <asac> i dont think so
[01:20] <asac> there hsould be another loop
[01:20] <asac> first extract all copyrights into a unique set
[01:21] <asac> then filter all files returned for each copyright for each license ;)
[01:21] <asac> hehe
[01:21] <fta> i sort by dir, then by license
[01:21] <fta> then by file
[01:21] <fta> the 3 for() loops at the end
[01:22] <asac> yes. but not by copyright holder
[01:22] <asac> thats just dumped
[01:22] <asac> having those also sorted below the license level would help a lot and hopefully would allso  abunch of dirs to be just *
[01:23] <asac> then we just need to resort the whole list by dir depth and dep-5 is valid and great ;)
[01:24] <asac> current copyright is 3.5 M ;)
[01:24] <asac> i mean the raw dump
[01:25] <asac> so
[01:25] <asac> for my $license (sort values %{$$data{$dir}})
[01:25] <asac> err
[01:25] <asac> for my $copyright (sort values %{$$data{$dir}})
[01:25] <asac> would give a sorted list of copyright hoders in a dir?
[01:31] <asac> fta: http://paste.ubuntu.com/349346/ ;)(
[01:31] <asac> to give the idea ;)
[01:31] <asac> ignore my unperlism
[01:31] <asac> maybe help me fix that ;)
[01:33] <fta> er, what did you change?
[01:33] <asac> hmm. doesnt like continue ;)
[01:34] <asac> fta: the copyright sortage in the license loop
[01:34] <asac> what is the continue equiv in perl?
[01:34] <asac> next?
[01:34] <fta> yes, but you have two nested loops over the same thing..
[01:34] <fta> hm
[01:36] <asac> oh
[01:36] <asac> i wanted values
[01:36] <asac> not keys
[01:36] <asac> for my $copyright (sort values %{$$data{$dir}}) {
[01:36] <asac> that way
[01:37] <asac> help ... why is there no equiv to continue; ;)
[01:37] <fta> hm, no, it's a 3 levels hash table
[01:37] <asac> not sure why next wants a parameter :)
[01:37] <fta> continue => next, break => last
[01:38] <asac> yes, but next without an argument hates me :(
[01:38] <asac> find docs about next FILE;
[01:38] <asac> not sure what i shoudl put there for a afor ;)
[01:38] <fta> nope, next alone is fine
[01:38] <fta> with a ";"
[01:38] <asac> hmm
[01:38] <asac> i tried
[01:38] <asac> while(1)
[01:38] <fta> it's not python
[01:38] <asac> next;
[01:38] <asac> that failed :)
[01:38] <asac> sure
[01:39] <asac> i am used to C ;)
[01:39] <fta> sure, you need braces
[01:39] <fta> print "foo" if $bar;  or if ($bar) { print "foo"; }
[01:39] <asac> sure
[01:40] <asac> oh
[01:40] <asac> you cannot have a one line thing like in C?
[01:40] <asac> odd
[01:40] <asac> ok
[01:40] <asac> yeah ... now it does something ;)
[01:41] <asac> yeah ... so what is in values?
[01:41] <fta> my eyes are closing fast
[01:41] <asac> another map?
[01:41] <asac> sure
[01:41] <fta> the ref of a hash
[01:41] <fta> imho, you're doing it the wrong way
[01:42] <asac> its definitly supoptimal ;)
[01:43] <asac> will try something else ;)
[01:43] <fta> i don't understand what you're trying to do with your loop
[01:45] <asac> dont bother
[01:45] <asac> i will play around a bit ;)
[01:45] <asac> good night :)
[01:47] <fta> thanks, we'll rediscuss that next time
[02:37] <micahg> dogatemycomputer: why did you mark that bug invalid?
[02:38] <dogatemycomputer> micahg:  I was told if it was reported upstream then it should be marked invalid for the ubuntu project.  is that incorrect?
[02:38] <micahg> dogatemycomputer: only for kubuntu packages
[02:38] <dogatemycomputer> micahg: ohhhh..  I wish this was documented somewhere.  :-(
[02:38] <micahg> dogatemycomputer: that's the only place it should say to invalidate :)
[02:39]  * micahg fixed it
[02:39] <dogatemycomputer> micahg:  I don't think it actually says one way or the other.   What should I mark it as?
[02:39] <micahg> dogatemycomputer: once it's upstreamed it should be marked triaged and if there's no importance, it should be set
[02:40] <dogatemycomputer> micahg: ahhh..  i'll try that then.   I don't think I can set importance but I think i can mark it triaged.
[02:40] <micahg> dogatemycomputer: you probably can't do either
[02:40] <dogatemycomputer> micahg:  i'm not in BugSquad.. mainly because i'm still learning.
[02:41] <micahg> but you go into #ubuntu-bugs and ask a -control member to do it for you
[02:41] <dogatemycomputer> micahg: I think I can mark it 'complete' though..  and past experience says someone will come along and change it to triaged.
[02:41] <micahg> dogatemycomputer: you should join bugsquad while learning
[02:42] <dogatemycomputer> micahg:  honestly.. I like the idea that I can't do something terribly wrong yet.  :-)
[02:42] <micahg> dogatemycomputer: bugsquad has no special privs
[02:42] <dogatemycomputer> micahg:  I do plan to join though.  Probably in March or April.  It says in the docs that I should have some experience before asking to join.
[02:42] <micahg> bugcontrol has special privs
[02:43] <micahg> dogatemycomputer: let's go to #ubuntu-bugs
[02:43] <dogatemycomputer> micahg: okay..
[02:44] <micahg> [reed]: can you push something I got approval for?
[02:47] <[reed]> micahg: sure
[02:47] <[reed]> bug #?
[02:47] <micahg> mozilla 510040
[02:48] <micahg> [reed]: I didn't test the patch against the branch
[02:50] <[reed]> micahg: done
[02:50] <micahg> [reed]: thanks
[10:13] <BUGabundo_work> morning
[11:20] <asac> hi
[11:27] <BUGabundo_work> hi asac
[11:27] <BUGabundo_work> ready for the PARTTTYYYY ?
[11:30] <asac> yeah
[11:30] <asac> well. ... not really ready. but preparing atm ;)
[11:32] <asac> ok packing things and then moving to different city for this event ;)
[11:33] <asac> see you next year, everybody!! 2010!!
[11:36] <BUGabundo_work> bye asac
[11:36] <BUGabundo_work> enjoy
[11:37] <BUGabundo_work> and guud luck entering 2010
[15:52] <BUGabundo_work> asac: fta: http://paste.ubuntu.com/349581/
[16:34] <BUGabundo_work> bye guys. see you tomorrow. enjoy your party. i know i will
[17:15] <mbana> something is broken in the way TB 3 replies to the messages.  the quote doesn't appear to be properly formatted when i look at it in Gmail
[17:18] <micahg> mbana: and teh same setting worked in TB2?
[17:20] <mbana> yes.  i just checked.  it only applies when replying in html mode
[17:20] <mbana> the quote is indented as opposed to proper quoting
[17:20] <micahg> mbana: can you file a bug in LP with screenshots?
[17:20] <mbana> if u use gmail, u can see it yourself.
[17:21] <mbana> just reply to a message in TB 3 in HTML form.  look at the message in Gmail and unhide the quote
[17:21] <mbana> it's indented and not quoted.
[18:06] <micahg1> mbana: I don't have time to test right now