[00:00] <asac> even --fail-missing
[00:00] <fta> yep, iirc, it's different
[00:00] <fta> it's already failing when files are listed in *.install but not there
[00:00] <asac> i think it checks whether all files that are in lets say debian/tmp/ are sorted to some package
[00:01] <asac> fta: what do you mean. doesnt it fail anyway if files in .install are not avail?
[00:01] <fta> yes
[00:01] <fta> that's what i keep fixing in the moz packaging
[00:01] <asac> fta: well. --list-missing and --fail-missing really seems to be like compare
[00:01] <fta> not last time i give them a try
[00:01] <asac> fta: i think we compare dist/bin vs. debian/tmp/
[00:02] <asac> and we also use compare for debian/tmp/ vs. debian/ALLPACKAGES?
[00:02] <fta> yes
[00:02] <asac> i think the latter can be done with dh_install --fail-missing (or list)
[00:02] <fta> i don't think so
[00:03] <asac> so we need compare for dist/bin vs. debian/tmp though
[00:04] <fta> yes
[00:04] <asac> k
[00:04] <asac> fta: do we have a mean to blacklist files from warning/erroring for the dist/bin/ vs. debian/tmp case?
[00:05] <asac> fta: the firefox-3.1 build log looked like there are a bunch of files listed that are ok not to have
[00:05] <asac> so i wonder if we could get them out of the log/warning
[00:05] <fta> yes, EXCLUDE_*
[00:05] <asac> fta: EXCLUDE_<what?>
[00:05] <asac> package name?
[00:05] <asac> and what kind of format?
[00:05] <fta> # The following variable are available:
[00:05] <fta> # COMPARE_FILTER_PRE_IN and COMPARE_FILTER_PRE_OUT (for a/)
[00:05] <fta> # COMPARE_FILTER_IN and COMPARE_FILTER_OUT (for b/)
[00:05] <fta> # By default, all are 'sed' commands that could be augmented (+=) or
[00:05] <fta> # overwritten by the caller.
[00:06] <asac> ok
[00:06] <asac> that looks promissing
[00:06] <fta> look in  /usr/share/mozilla-devscripts/firefox-3.1.mk
[00:06] <asac> so we should maintain that list and fail hard everywhere
[00:06] <asac> e.g. so we dont need to review logs all the time
[00:07] <fta> that was my initial idea, i just started it transparently, then it slept out of my list
[00:08] <asac> yeah. thats ok
[00:09] <asac> fta: is there a switch to make it fatal yet?
[00:09] <fta> no
[00:09] <fta> the code is ugly, i should revisit it
[00:09] <asac> heh
[00:10] <asac> oh . its basically one long sh line ;)
[00:10] <fta> ok, pushed a new chromium, it should have a shiny icon now
[00:11] <fta> gasp, forgot my -dbg fix
[00:11] <fta> well, that could wait
[00:11] <asac> :)
[00:12] <fta> hmm
[00:14] <fta> oh, they're back
[00:14] <fta> they disappeared from the build page, i thought they all failed
[00:15] <fta> .. fetching the songbird sources, i'm quite sure it will fail, if it's like last time
[00:16] <fta> ix:~/bzr/songbird.head$ wc -l debian/rules
[00:16] <fta> 302 debian/rules
[00:16] <fta> pffff
[00:18] <fta> Songbird1.1.1   ?? 1.1.1 or 1.1 ?
[00:19] <fta> http://timeline.songbirdnest.com/client/browser/tags/Songbird1.1.1/build/sbBuildInfo.ini.in so 1.1.1, strange
[00:25] <fta> asac, i should also update my ia32-*chromium* to get your new nss. is it already in hardy-sec?
[00:27] <fta> boooh, songbird is still using FIREFOX_3_0_3_RELEASE
[00:27] <fta> apparently, they don't care about security
[00:28] <fta> asac, asac_ http://paste.ubuntu.com/129584/
[00:32] <asac_> fta: yeah seems so. its a shame (sec)
[00:33] <asac_> fta: maybe we should file bugs ;)
[00:34] <asac_> and teach mitre to also have songbird added to the list for most firefox issues
[00:34] <asac_> i will try to talk to someone
[00:36] <asac_> anyway ... bailing out. have to get up tomorr at 7 or so
[00:36] <asac_> @time
[00:36] <asac_> ubottu: ping
[00:36] <asac_> good
[00:36] <asac_> cu
[00:37] <fta> cu
[01:45] <[reed]> asac: why do you have multiple bugzilla accounts?
[02:32] <LLStarks> asac. evening.
[08:51] <asac> [reed]: you mean asacmoz gmail?
[08:51] <asac> LLStarks: hi
[08:52] <asac> [reed]: the canonical one is _just_ for exception processing
[08:52] <[reed]> oh, I used your normal one for that canonical thing
[08:52] <[reed]> should I swap it to use the canonical one?
[08:52] <asac> [reed]: which canonical thing? the component? yes please.
[08:52] <[reed]> yes
[08:52] <[reed]> ok
[08:53] <asac> [reed]: my normal account is something i will use even after quitting.
[08:53] <asac> [reed]: the gmail one is a "give me all mail because i love searching one"
[08:53] <[reed]> planning on quitting soon?
[08:53] <[reed]> :p
[08:53] <asac> [reed]: no ;)
[08:53] <asac> [reed]: but you never know
[08:53] <asac> [reed]: you think the gmail one is bad?
[08:54] <asac> asacmoz at gmail i think
[08:54] <[reed]> no
[08:54] <[reed]> I was talking about the canonical one
[08:54] <asac> ah yeah. its really just for the "Official" canonical stuff. i dont want to mix them
[08:54] <[reed]> k
[08:55] <asac> [reed]: thanks for switching the default for the "exception" component to asac@canonical.com ;)
[08:55] <[reed]> ok, I swapped it to your @canonical :)
[08:55] <asac> [reed]: great.
[08:55] <asac> [reed]: which component is it?
[08:55] <[reed]> Legal :: Canonical
[08:55] <asac> ah good.
[08:56] <asac> [reed]: hmm. when will you support OpenID?
[08:56] <[reed]> lol
[08:56] <asac> or is that considered insecure (no clue)?
[08:56] <[reed]> mozilla bug 294608
[08:57] <asac> cool
[08:57] <asac> too bad. i guess i have remembered my pass on my laptop
[08:57] <asac> and not on this ffox 3.2 profile ;)
[08:57] <[reed]> ;)
[08:59] <[reed]> asac: I talked to ted about PGO, and he had some ideas
[09:00] <asac> [reed]: different idea from making a minimal test browser in xulrunner and use that to optimize xul?
[09:00] <[reed]> basically, compile xulrunner normally, compile firefox, use firefox to recompile xulrunner with PGO, and then recompile firefox with PGO
[09:00] <asac> hmm
[09:01] <asac> step 3 sounds difficult. i will think about it
[10:53] <gnomefreak> i cant get into admin for mailing list
[10:53] <gnomefreak> nevermind i think i got it
[10:59] <asac> gnomefreak: ;)
[10:59] <gnomefreak> its the pre coffee problem :)
[11:07] <asac> lol
[11:08] <asac> i am on coffee already ;)
[11:09] <gnomefreak> mine should be done i just havent got up to get it
[11:48] <gnomefreak> asac: do you happen to have the master firefox bug that keeps asking you to restart? i have duplicates but cant find any other bug like that but i know we have one
[11:48]  * gnomefreak goes for coffee and smoke
[11:53] <gnomefreak> would be nice if LP supported wildcard searches
[11:55] <asac> gnomefreak: hmm
[11:55] <asac> gnomefreak: there should be plenty
[11:55] <asac> gnomefreak: its ubufox
[11:55] <gnomefreak> thats what i thought too
[11:55] <asac> gnomefreak: 270303
[11:55] <gnomefreak> ah gppd call
[11:56] <gnomefreak> bug 27030
[11:56] <asac> renamed
[11:56] <asac> to MASTER ;)
[11:56] <gnomefreak> bug 270303
[11:56] <gnomefreak> thanks
[12:10] <gnomefreak> ok these reports are way too scattered.
[12:15] <gnomefreak> we have other reports for "firefox already running" i looked under firefox and ubufox using search (i reaally didnt feel much like looking through every bug report
[12:16] <asac> ubottu: ping
[12:17] <asac> scary. net outage for 40 seconds or so ;)
[12:17] <asac> seems to have recovered without reconnect though
[12:31] <gnomefreak> bug 194894 is now a master bug i know there are more out there but im looking for a different bug
[12:35] <gnomefreak> asac: master bug for firefox already running i was working on this the other day with upstream but i cant find it now and i know ubuntu has a bug on this :(
[12:36] <asac> gnomefreak: ok
[12:36] <asac> gnomefreak: already running?
[12:36] <asac> i dont know what bug that is in particular
[12:36] <asac> gnomefreak: if the user NFS then there is a master bug for that
[12:37] <gnomefreak> i looked in ubufox and firefox (still going through ff-2 bugs looking for it
[12:37] <asac> e.g. home mounted over NFS
[12:37] <gnomefreak> he doesnt state
[12:37] <asac> ask
[12:37] <asac> that would be bug 237970
[12:37] <gnomefreak> this is bug 77625
[12:37] <asac> ah
[12:37] <asac> yeah well.
[12:38] <asac> if we have a bug for arbitrary strange things then that would be it ;)
[12:38] <gnomefreak> :)
[12:38] <asac> if its not NFS, its probably "weird happenings when firefox is not restarted after upgrade"
[12:38] <asac> i think we had a master for that though
[12:38] <gnomefreak> im thinking ubufox but firefox process should die when closed (sort of like my 3.1 buttons problem
[12:38] <asac> e.g. "MASTER - everything can happen if firefox is not restarted after upgrade"
[12:39] <gnomefreak> i have to write my script for that
[12:39] <asac> gnomefreak: usually it closes. could be upgrade issue from above, or some plugin/extension that keeps something running
[12:39] <gnomefreak> that would be nice but a shit load of work
[12:40] <gnomefreak> i figured out my was ubufox but process still sticks and removed my buttons. killall firefox-3.1 works same issue different UI issues as the above bug but i can swear ther eis another 1 or 100 of this
[12:41]  * gnomefreak not really setting out for bug work today :)
[12:44] <gnomefreak> asac: im leaning towards translation for bug 63499 and yes it is still present
[12:45] <asac> gnomefreak: reassign that to hunspell dictionaries packages
[12:45] <gnomefreak> k
[12:45] <asac> firefox has nothing to do with that
[12:45] <asac> i mean it doesnt even use aspell
[12:45] <gnomefreak> i figured that
[12:45] <asac> so its a ispell dictionaries bug and a hunspell dictionaries bug
[12:47] <gnomefreak> i changed it to hunspell should i add ispell or hunspell covers that?
[12:48] <gnomefreak> ill be right back soon to be pain in the ass wife calling me
[13:16] <gnomefreak> ok im back for ~30 minutes to finish what i started than she wants to go shopping and dragging me along with her :(
[13:46] <fta2> gasp... songbird :(
[13:47] <fta2> Remove the patches directory on all active branches. Our patches are now applied directly to our dependencies in the vendor repository; you can do an |svn diff -r /vendor/trunk/$package /vendor/upstream/$package| to get a list of diffs/patches. The patches int he patches/ directories were old, and were not the patches we were even using anymore; this was causing too much confusion.
[13:47] <fta2> so my package is definitely broken now
[13:51] <gnomefreak> fta2: did upstream get to a point where we can package it in archives for KK
[13:52] <fta2> no
[13:52] <gnomefreak> ok thats what i thought see bug 94494
[13:52] <fta2> imho, they will never do that, they don't care enough about us. either we'll have to bend, or it's out forever
[13:55] <gnomefreak> i agree that they dont seem to care enough but as for the packaging i wouldnt know
[14:01]  * gnomefreak off for a while.
[14:10] <asac> fta2: i really think a first step is to raise pressure on general security support
[14:10] <asac> fta2: once they notice that they get bad reputation with their current way, they might look into new innnovative things
[14:10] <asac> one solution that comes up is to remove all patches and just ride the xulrunner security updates aka libxul
[14:11] <asac> fta2: thats why i will ask mitre folks to remember to add songbird for all rendering sec issues
[14:11] <asac> that are announced for firefox/xulrunner
[14:11] <asac> in that way they will be officially insecure all the time and while this might work for some time
[14:11] <asac> it will come up at some point
[14:13] <fta2> apparently, my old method of packaging (ie, get their xul tag and patch it) is no longer what they do
[14:17] <asac> fta2: they probably failed to properly rebase stuff in svn ;)
[14:18] <asac> and now patches are out of sync with the full tree they have
[14:18] <asac> or they forgot to udpate patches and now nobody knows what to do ;)
[14:18] <asac> which could also be the reason why they are stuck at 3.0.3. we should ask stevel
[14:29] <fta2> http://timeline.songbirdnest.com/vendor/browser/tags/Songbird1.1.1/xulrunner/mozilla/config/milestone.txt => 1.9.0.5
[14:30] <fta2> !info xulrunner-1.9 jaunty
[14:30] <fta2> asac, any chance to talk with the modem guy yet?
[14:34] <asac> i asked again now. lets see
[14:38] <asac> fta2: so does that key work more than once with NM?
[14:38] <asac> or can you connect exactly once and then never again until you use windows?
[14:39] <asac> fta2: also. thats a huawei with "option" driver? can you give the pci id?
[14:39] <fta2> more than once
[14:39] <asac> err usb id;)
[14:39] <asac> fta2: more than once? like you can plug in the key multiple times?
[14:39] <asac> or more than once without repluggin?
[14:40] <fta2> let's sum up. 2 SIMS: S1 and S2, one key: the huawei E220 (12d1:1003)
[14:40] <fta2> initially, both S1 and S2 worked for a short while
[14:41] <fta2> then S1 stopped working, even after several attempts, replugs, reboots
[14:41] <fta2> S2 was still fine
[14:41] <fta2> i pluggued my key with S1 in an XP box, it connected just fine
[14:41] <fta2> back in ubuntu, S1 was fine
[14:42] <fta2> the next week-end, S1 was still fine, but S2 broke
[14:42] <fta2> i'm still there: S1 ok, S2 nok
[14:43] <asac> fta2: so if S2 is broken you can flip sims and it will work?
[14:43] <fta2> yes
[14:44] <fta2> when it's broken, it connects and hangup immediately after
[14:52] <asac> fta2: you still have a link to a serial log paste in your backlog?
[14:52] <asac> i know you posted it, but i cant find it :(
[14:55] <asac> fta2: serial + ppp debug on log i guess (if you dont mind to capture one)
[14:56] <fta2> http://paste.ubuntu.com/125513/
[14:56] <asac> they say that some modems reset magic stuff on AT+CFUN=0 ... and only windows knows the secret commands to fix that on next plugging
[14:57] <asac> fta2: ok and if you retry it looks the same?
[14:57] <asac> e.g. thats the reproducible error?
[14:57] <fta2> yes, 100%
[14:58] <fta2> that was a few days ago (Mar  2 23:52)
[15:00] <asac> fta2: so you always get to ppp stage and then get a hang up after sent [IPCP ConfReq id=0x2 <compress VJ 0f 01>
[15:00] <asac> fta2: can you try to disable all the compression stuff in /etc/ppp/options ?
[15:01] <asac> fta2: add novj novjccomp
[15:03] <asac> fta2: 16:00 < tambeti> asac: I have a modem with same usb ids
[15:03] <asac> 16:00 < tambeti> asac: and I've never seen such a problem
[15:04] <fta2> hm
[15:04] <fta2> so what? I got it twice
[15:06] <asac> fta2: try the compression stuff. also please modify the --delay to 4000 in the udev .rules
[15:06] <asac> i mean the fact that your thing doesnt work with udev also doesnt sound right
[15:06] <asac> fta2: twice? so you say its reproducible to fix this in windows, even though only cured it once?
[15:07] <fta2> will try that tonight
[15:07] <asac> k
[15:08] <fta2> it locked twice, i cured it only once to have a chance to troubleshoot it
[15:08] <asac> fta2: yeah. did you connect using windows or just boot?
[15:08] <fta2> the 1st time, i connected it
[15:09] <asac> fta2: if you need to connect we should try to capture the USB traffic so we see the maybe-secret AT command send
[15:09] <asac> if its during boot its probably harder
[15:09] <fta2> how? i'm clueless with windows
[15:10] <asac> fta2: imo just go for the compression thing first.
[15:10] <asac> providers might have a bogus ppp server which just chokes when you start negotating about things it doesnt know about
[15:10] <asac> and hang up
[15:11] <asac> fta2: if it comes to usb monitoring under windows, i will try to find the right tools for you
[15:11] <fta2> but the other sim is doing exactly the same thing
[15:11] <asac> so you can just keep that running and capture everything
[15:12] <asac> fta2: well. as i said before, you might be on a different hub or gateway
[15:15] <asac> i mean: i also had similar issues at some point
[15:15] <asac> and couldnt connect .... but i never used windows and it just started to work at some point again
[15:15] <asac> and the ppp log really looked similar.
[15:15] <asac> tweaking the compression things helped a bit - at least the log was different
[15:16] <asac> e.g. hangup during VJ compression negotation
[15:20] <fta2> ok, will try that, compression is rejected anyway
[15:20] <fta2> i would love to have something working out of the box
[15:25] <asac> fta2: well. if its really compression negotiation we can maybe turn that off everywhere. i am not sure that 3g uses that ppp part
[15:39] <fta2> asac, why so many people have to patch their kernel and manually install madwifi on their netbooks?
[15:40] <asac> fta2: i dont know. probably because ath drivers really sucked in hardy?
[15:40] <asac> its only been 6 month or so when the bad atheros situation improved
[15:40] <asac> before it was as closed as broadcom
[15:41] <fta2> they are on intrepid and jaunty
[15:41] <asac> atheros was messy in intrepid because of the close timeline. jaunty should be better afaik
[15:41] <asac> meaning: in hardy all was lost, but we got this working by having a hacked wpasupplicant
[15:42] <asac> in intrepid the new drivers appears and sucked, madwifi didnt work anymore, because wpasupplicant dropped support (saying its dead)
[15:42] <asac> in jaunty. i hope its fixed
[15:42] <asac> also intrepid driver should be fixed in -updates
[15:42] <asac> i think that normal netbook remix doesnt ship everything from -updates
[15:42] <asac> so that might be the reason
[15:43] <asac> at least most cases should be fixed
[15:43] <asac> or in -backport-modules
[15:45] <asac> fta2: safest thing would really be dell mini. the netbook image for hardy has quite perfect modem integration now (its hacky, yes, but i connects fast and knows about everything - even unlocking)
[15:45] <asac> only prob is that the kernel patch hasnt landed in mainline.
[15:45] <asac> so its not in mainstream jaunty, but the kernel provided by Netbook folks will have that too soon
[15:48] <asac> fta2: http://www.notebookjournal.de/tests/toshiba-netbook-nb100-11r-701
[15:48] <asac> is that the netbook you are looking at?
[15:49] <asac> Toshiba NB100
[16:00] <fta2> no, i initially wanted the dell mini 10, but it's lacking some features i need, and they will come too late. so i'm looking at the samsung NC10 now
[16:00] <fta2> https://help.ubuntu.com/community/NC10
[16:09] <asac> fta2: that page says "installing latest madwifi drivers helps"
[16:09] <asac> thats wrong
[16:09] <asac> a few lines later they just use the ath5k
[16:09] <asac> so its like i said
[16:09] <asac> you need backport-modules
[16:09] <asac> in intrepid and jaunty should work
[16:09] <fta2> it's a community page, so it's kind of half obsolete
[16:09] <asac> yes. i think they just mixed the names up
[16:10] <asac> madwifi was the old hostap driver
[16:10] <asac> ath5k and ath9k are the new drivers that are shipped in mainline kernel
[16:10] <asac> and hence are supposed to become quite solid and reliable in the future
[16:34] <LLStarks> hi asac
[16:35] <asac> LLStarks: hey
[16:35] <LLStarks> do you have thoughts on this? http://ubuntuforums.org/showthread.php?p=6874367#post6874367
[16:35] <LLStarks> it doesn't seem to be limited to sans-serif fonts and only occurs in certain textboxes
[16:37] <asac> LLStarks: what sans serif font is that in the back?
[16:37] <asac> i guess you dont use any windows fonts?
[16:37] <LLStarks> i do.
[16:38] <LLStarks> but i don't know what font that is.
[16:39] <asac> LLStarks: i think windows fonts have problems with metrics
[16:41] <LLStarks> should i file a bug?
[16:41] <asac> LLStarks: first check whether it goes away if you remove the windows fonts
[16:42] <LLStarks> if it doesn't, file with fontconfig and ttf-msttcorefonts?
[16:42] <asac> LLStarks: provide a way to reproduce without msttcorfonts and put it against fontconfig
[16:42] <asac> otherwise i am not sure
[16:44] <LLStarks> gotcha
[17:33] <kosmonaut> I've got a quite strange behavior in TB 2.0.0.19(jaunty). Since AFAIK yesterday TB refuses to filter my mail. In the filtermenu everything is looking ok. When I select apply filter (in the filtermenu it self) my mail gets filtered. BUT when new mail comes in nothing happens, filters are not working. Now I have looked in "msgFilterRules.dat" there are entries called "enabled="no"". I changed them to "enabled="yes"" an *tata* filter
[17:33] <BUGabundo> asac: ping
[17:33] <BUGabundo> hi
[17:33] <BUGabundo> asac: does this mean anything to you http://paste.ubuntu.com/129828/ ?
[17:46] <asac> BUGabundo: not sure. network problems seem to prevent me to get that page
[17:48] <asac> BUGabundo: far too long
[17:48] <asac> plesae paste relevant bits
[18:47] <fta> stevel, where are the updated instructions to build sb now that you changed everything for the n-th time?
[18:48] <stevel> fta: building the dependencies is here: http://wiki.songbirdnest.com/Build_Release/Building_the_vendor_repository
[18:48] <stevel> building the main app should be the same
[18:52] <fta> ok, thanks, i was almost there. just need to re-do my patches to your new files :(
[18:58] <asac> stevel: now that 1.1 is out ... how about making a new upstreaming round and reviewing if things can be done different or not at all that are not suitable for xulrunner tree?
[18:58] <asac> i know. broken record. sorry about that ;)
[19:00] <stevel> heh, no worries. yeah... i'd like to, i've been pretty swamped with critical work for the past 2 months or so and haven't had time to look into it.  will try again when i get some free cycles
[19:00] <asac> stevel: thats why i ask now. if not now after release (well after fixing first critical feedback things), then probably never :)
[19:01] <fta> i don't see how it's possible now that everything is flat
[19:01] <asac> one goal would be to get to a state where we can build it against system xul and songbird isnt completely broken afterwards
[19:01] <fta> "Remove the patches directory on all active branches. Our patches are now applied directly to our dependencies in the vendor repository; you can do an |svn diff -r /vendor/trunk/$package /vendor/upstream/$package| to get a list of diffs/patches. The patches int he patches/ directories were old, and were not the patches we were even using anymore; this was causing too much confusion."
[19:01] <asac> that would definitly be a victory
[19:01] <fta> (that's from svn log)
[19:07] <kosmonaut> some1?
[19:08] <asac> kosmonaut: ?
[19:09] <kosmonaut> please see 18:33
[19:10] <asac> kosmonaut: no :-P
[19:10] <asac> please repost
[19:10] <asac> we dont even know which timezone you are in
[19:10] <kosmonaut> I've got a quite strange behavior in TB 2.0.0.19(jaunty). Since AFAIK yesterday TB refuses to filter my mail. In the filtermenu everything is looking ok. When I select apply filter (in the filtermenu it self) my mail gets filtered. BUT when new mail comes in nothing happens, filters are not working. Now I have looked in "msgFilterRules.dat" there are entries called "enabled="no"". I changed them to "enabled="yes"" an *tata* filter
[19:10] <asac> hmm
[19:11] <asac> thanks
[19:11] <kosmonaut> strange..ha?
[19:11] <asac> yeah
[19:11] <asac> kosmonaut: can you disbale rules in the rule wizard?
[19:11] <asac> does that change the state to enabled=false?
[19:11] <asac> or no
[19:11] <asac> ?`
[19:11] <kosmonaut> hold on
[19:13] <asac> fta2: i can only reemphasize how important it is that you open an ITP in debian ;) for chromium parts currently not taken
[19:13] <asac> just got reminded because i got a chromium update from daily
[19:14] <kosmonaut> now: I enabled the rules in the filtermenu...in "msgFilterRules.dat" all enabled are set to "enabled=no"
[19:14] <asac> kosmonaut: what do you mean by "enabled the rules"  ... were they disabled?
[19:15] <kosmonaut> asac: Extra->Filters...>Aktivieren (german)
[19:16] <asac> kosmonaut: i know. for me the Rules .dat is in sync with the U
[19:16] <kosmonaut> it seems like it the "aktivieren"-botton gives a false feedback to "msgFilterRules.dat"
[19:17] <asac> kosmonaut: i stopped tbird, modified the .dat ... started again and the state in UI matches the .dat
[19:17] <asac> e.g. it seems to parse it on startup
[19:17] <asac> which sounds correct.
[19:17] <kosmonaut> hmm
[19:17] <asac> if that doesnt do that for you it could be either a) an extension
[19:18] <asac> or b) some bad syntax
[19:18] <asac> kosmonaut: you could try to reduce the .dat file until you find the bad entry
[19:18] <kosmonaut> ok...good I'll try to do so
[19:18] <asac> e.g stop tbird; remove all rules, but one. see if that works (backup the bad .dat first of course)
[19:18] <kosmonaut> sure ;-)
[19:18] <asac> kosmonaut: yeah. please backup otherwise i see the issue just go away ;)
[19:19] <asac> kosmonaut: oh you could also look in tools -> error console if there is an error
[19:19] <asac> but i doubt that there is one
[19:19] <kosmonaut> thx! :-D
[19:19] <kosmonaut> I'll try all of your hints
[19:20] <fta> stevel, it seems i have to specify SB_VENDOR_BUILD_ROOT, what is that supposed to be?
[19:20] <asac> kosmonaut: thanks. we see complains about not working filters more or less regularly, so you finding might be the nail - which would be great
[19:22] <kosmonaut> ok...but what made me kind of worry was: that when flters are activated the entry in that *.dat was "off" and when they were de-activated the entry is "on"...Let's see if I find the troublemaker
[19:22] <kosmonaut> (sorrry for my english)
[19:22] <kosmonaut> ;-)
[19:22] <asac> kosmonaut: yes. there is something bad. are you sure you have no extension installed?
[19:22] <asac> (except enigmail maybe)
[19:22] <kosmonaut> no extensions for sure
[19:22] <asac> ok good. then lets find what causes this in the file
[19:23] <fta> stevel, i mean, is there a default value for SB_VENDOR_BUILD_ROOT? (that i'm not getting for some reason)
[19:23] <kosmonaut> oh...enigmail...i forgot about it...it is no an extension 4 me it is a basic module :-)
[19:23] <asac> kosmonaut: i hope its a syntax thing ... otherwise its probably harder to track down
[19:23] <asac> kosmonaut: i dont think enigmail causes this. i have it installed too. but better safe than sorry and disable it for debugging this
[19:23] <kosmonaut> asac: well....was long as it filters and I know what to do am quite happy
[19:24] <asac> kosmonaut: thats an egocentric point of view. we need to nail this down and fix it for everyone
[19:24] <kosmonaut> asac: all right. but 4 now I have to say good night to my kids
[19:24] <asac> kosmonaut: sure.
[19:24] <asac> kosmonaut: no hurry. if there is nothing private in the .dat file you could also share it
[19:24] <asac> or maybe a reduced file that also has this issue
[19:32] <fta> stevel, nm.. but why do i need to co the binaries too?? i don't want that
[20:08] <stevel> fta: sorry, was at a meeting and then lunch.
[20:12] <fta> stevel, i'm patching the new build system, step by step, to fit my needs.
[20:12] <fta> it's not working out of the box :(
[20:13] <stevel> what's not working?
[20:13] <stevel> lemme see if i can get our build guy in here
[20:14] <fta> now it's failing in the breakpad symbol code.
[20:14] <JayPee> Yo yo.
[20:15] <fta> hi
[20:15] <fta> http://paste.ubuntu.com/129913/
[20:15] <JayPee> someone wanted to chat w/ me?
[20:16] <fta> JayPee, about songbird? me :)
[20:16] <JayPee> yup
[20:16] <fta> cd $(SRC_DIR)/dependencies/vendor/taglib ; make -f Makefile.songbird SB_VENDOR_BUILD_ROOT=$(SRC_DIR)/dependencies/vendor SB_BUILD_TYPE=release
[20:16] <JayPee> what's up?
[20:16] <fta> ends up like this http://paste.ubuntu.com/129913/
[20:16] <Mook_sb> hmm, it's http://src.songbirdnest.com/source/xref/dependencies/xulrunner/mozilla/toolkit/crashreporter/tools/symbolstore.py copied by http://src.songbirdnest.com/source/xref/dependencies/xulrunner/mozilla/toolkit/crashreporter/tools/symbolstore.py ...
[20:16] <JayPee> ok; without looking, I'm going to say building dependencies in the vendor dir isn't supported; it may be ok, but that's not how we build it.
[20:17] <fta> I don't have/want the vendor binaries so i had to slightly patch http://paste.ubuntu.com/129917/
[20:17] <JayPee> do you care about symbols?
[20:17] <JayPee> my guess is "no"
[20:17] <fta> no, i don't build xul with breakpad
[20:18] <fta> (we have our own symbol system in our bug tracker)
[20:18] <JayPee> fta: build with SB_VENDOR_GENERATE_SYMBOLS=0
[20:18] <fta> ok, trying..
[20:19] <fta> why does it clean at each run?
[20:20] <JayPee> because we use this to generate vendor-binaries, so we assert that the build area is clear.
[20:20] <fta> well.. ok.
[20:20] <JayPee> because I don't want to mess around with packages not getting dependency tracking correct
[20:20] <JayPee> it's not rule #1 of building release builds
[20:20] <JayPee> but it's up there.
[20:22] <fta> ok, good for taglib
[20:22] <fta> hm, it's doing svn up during build (mozbrowser)
[20:23] <fta> bad, it will break in our builders
[20:23] <fta> no network access allowed
[20:23] <Mook_sb> fta: read the makefile, you can disable that update
[20:23] <Mook_sb> (another random variable to set :D )
[20:23] <JayPee> yes
[20:23] <fta> ok.. reading..
[20:23] <JayPee> we put that in there just for situations like this, where you have weird rules!
[20:24] <fta> it's not weird, it's about security
[20:24] <Mook_sb> ("you" = "the guy on a boat"? :D )
[20:25] <JayPee> fta: it's as weird to me as requiring a rebuild is to you.
[20:25] <JayPee> (which is to say it's a requirements issue)
[20:26] <fta> anyone could send something to the builders, so network access is not allowed, makes perfect sense to me. but it's sometimes difficult to live with. i don't think it's the case here. anyway, building sb now
[20:28] <fta> failed
[20:29] <fta> components/mediacore/metadata/handler/taglib/src/MetadataHandlerTaglib.cpp missed the taglib headers
[20:30] <fta> http://paste.ubuntu.com/129921/
[20:31] <fta>  /src/bzr/build-area/songbird-1.1.1/build-tree/songbird/dependencies/linux-i686/taglib/release/include/taglib is wrong, i have no taglib in linux-i686/
[20:32] <fta> JayPee, ^^ ?
[20:34] <Mook_sb> what does /src/bzr/build-area/songbird-1.1.1/build-tree/songbird/dependencies/linux-i686/taglib/release/include/taglib look like?
[20:35] <fta> nada: http://paste.ubuntu.com/129923/
[20:37] <fta> taglib was built with:         cd $(SRC_DIR)/dependencies/vendor/taglib ; make -f Makefile.songbird SB_VENDOR_BUILD_ROOT=$(SRC_DIR)/dependencies/vendor SB_BUILD_TYPE=release SB_VENDOR_GENERATE_SYMBOLS=0
[20:37] <fta> Mook_sb, ^^
[20:38] <Mook_sb> fta: got the full taglib build log?
[20:38] <Mook_sb> because staring at random snippets is really, really hard.
[20:39] <fta> i can sure recapture it
[20:39] <fta> hold on
[20:47] <fta> Mook_sb, http://www.sofaraway.org/ubuntu/tmp/sb.log.txt
[20:47]  * asac waves to songbird crew
[20:47]  * Mook_sb waves to asac
[20:47] <asac> thanks for ending up here ;)
[20:49] <Mook_sb> -- Installing: /src/bzr/build-area/songbird-1.1.1/build-tree/songbird/dependencies/vendor/linux-i686/taglib/release/include/taglib/fileref.h
[20:50] <fta> asac, the chromium-daily ppa was full, again. it has 7GB now
[20:50] <Mook_sb> so, JayPee: we actually end up checking in .../dependencies/vendor/linux-i686, then check it out as .../dependencies/linux-i686, don't we?
[20:51] <JayPee> uh
[20:51] <JayPee> well, in the normal build system, we check out $(root)/checkouts/linux-i686
[20:51] <JayPee> then $(root)/linux-i686 is supposed to be created by the user
[20:51] <JayPee> and symlinks are created
[20:51] <JayPee> and then removed as packages are rebuilt
[20:52] <Mook_sb> oh, the checkin bit was from building vendor-binaries, and the checkout bit is the actual songbird build process, yeah
[20:52] <JayPee> $(root)/linux-i686 is eventually cehcked back in
[20:52] <fta> is that documented somewher?
[20:52] <JayPee> fta: yup!
[20:52] <Mook_sb> so I guess in fta's case, he needs to be making symlinks and stuff
[20:52] <JayPee> well
[20:52] <fta> i don't co the vendor-binaries, don't want to, and don't need to
[20:52] <JayPee> ah
[20:52] <JayPee> well, then it's unlikely to work!
[20:52] <fta> why?
[20:53] <JayPee> uh
[20:53] <JayPee> because that's how it's designed to work
[20:53] <fta> if it depends on binaries, i'd better stop right now.
[20:53] <Mook_sb> your process is different from our process, so things need to be adapted :)
[20:53] <JayPee> it probably doesn't.
[20:53] <JayPee> if you're just building taglib
[20:53] <Mook_sb> fta: you can make a local bzr repo and clone it, if it makes you feel better ;)
[20:54] <JayPee> but the build system expects that stuff to exist
[20:54] <JayPee> but, we accept patches; so you could always write one to disable that functionality
[20:54] <JayPee> it's mostly used for building gstreamer, since gstreamer depends on so many sub-packages
[20:54] <JayPee> taglib, I believe, does not.
[20:55] <fta> no, i've spent a lot of energy on this package for quite a long time, and at each milestone, every changes, so i'm back to square one, it's frustrating, at best.
[20:55] <fta> everything
[20:55] <JayPee> I can check, but I'm pretty sure the vendor build system didn't change much, if at all, between 1.0 and 1.1
[20:55] <JayPee> I think I may have required that you set the BUILD_ROOT
[20:55] <JayPee> but you were doing that already
[20:56] <JayPee> anyway, I can understand being frustrated; you would probably find it more rewarding to read through the makefiles, and contribute back fixes that make building the dependencies for you easier
[20:56] <JayPee> rather than working around it every release.
[20:56] <fta> for taglib, i used to have: cd $(SRC_DIR)/dependencies/vendor/taglib ; AUTOCONF=autoconf2.50 AUTOM4TE=autom4te sh ./songbird_taglib_make.sh
[20:57] <fta> now i have: cd $(SRC_DIR)/dependencies/vendor/taglib ; make -f Makefile.songbird SB_VENDOR_BUILD_ROOT=$(SRC_DIR)/dependencies/vendor SB_BUILD_TYPE=release SB_VENDOR_GENERATE_SYMBOLS=0
[20:57] <fta> and it's broken
[20:58] <JayPee> out of curiosity, what happens if you make -f Makefile.songbird release
[20:59] <JayPee> you're not really supposed to set SB_BUILD_TYPE
[20:59] <fta> it fails
[20:59] <fta> missing SB_VENDOR_BUILD_ROOT
[20:59] <fta> then missing SB_VENDOR_BINARIES_DIR
[20:59] <fta> then it's doing a debug build, that i don't want
[21:00] <fta> then it fails on breakpad symbols
[21:00] <fta> then it's placing the results where sb is not expecting them
[21:01] <JayPee> well
[21:01] <JayPee> have you created SB_VENDOR_BUILD_ROOT?
[21:01] <JayPee> and I suppose you could fake SB_VENDOR_BINARIES_DIR by creating it
[21:01] <JayPee> also, it's not.
[21:02] <JayPee> 13:58 < JayPee> out of curiosity, what happens if you make -f Makefile.songbird  release
[21:02] <JayPee> did you see the "release" I added to the target there?
[21:02] <fta> oh
[21:03] <fta> ix:~/bzr/build-area/songbird-1.1.1/build-tree/songbird/dependencies/vendor/taglib$ make -f Makefile.songbird release
[21:03] <fta>  /src/bzr/build-area/songbird-1.1.1/build-tree/songbird/dependencies/vendor/taglib/../songbird-vendor-defs.mk:271: *** Must define SB_VENDOR_BUILD_ROOT.  Stop.
[21:03] <JayPee> sigh.
[21:04] <JayPee> What ahppens if you run make -f Makefile.songbird release SB_VENDOR_BUILD_ROOT=$(SRC_DIR)/dependencies/vendor SB_VENDOR_GENERATE_SYMBOLS=0 ?
[21:04] <JayPee> is what I was really interested in.
[21:05] <fta>  /src/bzr/build-area/songbird-1.1.1/build-tree/songbird/dependencies/vendor/taglib/../songbird-vendor-defs.mk:278: *** SB_VENDOR_BUILD_ROOT (/src/bzr/build-area/songbird-1.1.1/build-tree/songbird-1.1.1/build-tree/songbird/dependencies/vendor) does not exist....  Stop.
[21:05] <fta> i can create that, should I?
[21:06] <JayPee> sure
[21:06] <JayPee> does build-tree/songbird have the songbird code in it?
[21:08] <fta> hm, nm, the path is wrong, i messed it up, retrying.
[21:15] <fta> it fails while building sb, still missing the includes
[21:15] <fta> JayPee, ^^
[21:16] <fta> JayPee, http://www.sofaraway.org/ubuntu/tmp/sb2.log.txt
[21:16] <JayPee> ok, you need to build these COMPLETELY SEPARATELY
[21:16] <JayPee> preferably in separate build areas
[21:16] <JayPee> are you doing that?
[21:17] <fta> hm, no, i'm not. it's supposed to be built in its own dir, right?
[21:18] <JayPee> well, we build the vendor binaries completely separately from the songbird build
[21:18] <JayPee> and when I saw that you're building things in dependencies vendor, I became sorta scared anyway
[21:18] <JayPee> 'cause we don't do that
[21:19] <fta> is it just a matter of SB_VENDOR_BUILD_ROOT ? i can use something else.
[21:19] <JayPee> yes
[21:19] <JayPee> or rather, that should work
[21:20] <JayPee> (FWIW, I'm not saying this build system is perfect; the weird directories you have to create were due to iterating over what I needed; it's better for us than the old shell system in tons of ways, but it's not perfect, and it's not bug free.)
[21:24] <fta> i don't understand. if i use SB_VENDOR_BUILD_ROOT=/whatever to build taglib, how will songbird know where to look?
[21:26] <Mook_sb> songbird needs it in $root/dependencies/$platform/taglib/release/include
[21:26] <Mook_sb> the normal songbird build system involves a svn ci / co, so it gets moved anyway
[21:31] <fta> i think i should take a step back from this. it doesn't make any sense to me (binaries, ci/co while i already have all the sources i need, etc.).
[21:32] <Mook_sb> _you_ don't need to ci/co, but you need to account for the normal procedure and adjust accordingly.
[21:36] <fta> 18776242   12 -rw-r--r--   1 fta      fta          9385 Mar 11 22:09 ./build-tree/songbird/dependencies/vendor/linux-i686/taglib/release/include/taglib/fileref.h
[21:36] <fta> 15876536   12 -rw-r--r--   1 fta      fta          9385 Mar 11 22:09 ./build-tree/songbird/dependencies/vendor/build/taglib/release/taglib/fileref.h
[21:37] <fta> so i have a bogus /vendor/ in the middle, right?
[21:41] <Mook_sb> right, or rather, the vendor-binaries build system ends up not putting it where the main songbird build system expects
[21:42] <Mook_sb> (because normally those things are disconnected)
[21:45] <fta>         mkdir -p $(foreach dir,checkout build linux-$(MACHINE),$(SRC_DIR)/my-deps/$(dir))
[21:45] <fta>         cd $(SRC_DIR)/dependencies/vendor/taglib ; make -f Makefile.songbird release SB_VENDOR_BUILD_ROOT=$(SRC_DIR)/my-deps SB_VENDOR_GENERATE_SYMBOLS=0
[21:46] <fta> taglib builds fine but sb is still unable to find it.
[21:46] <JayPee> fta: ok, can you post complete log for *that*?
[21:47] <JayPee> Mook_sb: well, again, they're separate build system
[21:47] <JayPee> the method should be
[21:47] <fta> JayPee, http://www.sofaraway.org/ubuntu/tmp/sb3.log.txt
[21:48] <JayPee> create Sandbox A; build taglib. create Sandbox B; checkout soungbird; cp the correct directory from Sandbox A into Sandbox B
[21:48] <JayPee> build Songbird
[21:48] <JayPee> the two sandboxes shouldn't know anything about each other.
[21:48] <JayPee> and certainly shouldn't share a build tree
[21:48] <JayPee> fta: so yeah; can you do that please?
[21:49] <JayPee> I notice that you're still building in dependencies/vendor/taglib
[21:49] <fta> hm
[21:50] <fta> if i trash my tree, i will have to rebuild xul, ~45 min on this box
[21:50] <JayPee> well, I don't know that you need to trash your tree
[21:50] <JayPee> just make a build-tree/songbird-vendor
[21:51] <JayPee> and build taglib there.
[21:51] <JayPee> (make that the BUILD_ROOT
[21:51] <fta> rm -rf build-tree :)
[21:51] <JayPee> well, if you want it to be clean, yes you'll have to do that
[21:51] <JayPee> if you want to test my theory out, then you won't.
[23:05] <Nafallo> asac
[23:05] <Nafallo> 23:02 < andresmujica> Hi MOTUs!
[23:05] <Nafallo> 23:02 < andresmujica> i wonder if someone can help me with this bug #317860
[23:05] <Nafallo> 23:02 < ubottu> Launchpad bug 317860 in mobile-broadband-provider-info "Request to upgrade to latest SVN 3G profiles" [High,In
[23:05] <Nafallo>                 progress] https://launchpad.net/bugs/317860
[23:05] <Nafallo> 23:02 -!- quadrispro [n=quadrisp@ubuntu/member/quadrispro] has joined #ubuntu-motu
[23:05] <Nafallo> 23:03 < andresmujica> the lastest 3g profiles reported at launchpad and all around are at upstream SVN, a quick update to the
[23:05] <Nafallo>                       package would be great for Jaunty a6
[23:05] <Nafallo> stop it ubottu ! :-P
[23:10] <dtchen> fta: heads-up: in ~6 hrs, my ppa will have a newer linux containing a fix for the glitch-free aberrations
[23:10] <asac> Nafallo: yes.
[23:10] <fta> dtchen, newer linux?
[23:10] <asac> antti is moving 500 km north close to the north pole
[23:10] <asac> so update will happen next week finally
[23:10] <dtchen> fta: yes, we've patched the original hw-ptr issue causing so much instability in pa
[23:11] <fta> dtchen, you mean a newer kernel?
[23:11] <dtchen> it's pretty necessary for glitch-free
[23:11] <dtchen> yes
[23:11] <fta> d'oh
[23:11] <asac> RESTART YOUR SYSTEM
[23:11] <asac> just got that
[23:11] <dtchen> fta: it won't require a reboot
[23:12] <dtchen> fta: you'll need to unload all the sound modules and load the new ones, but beyond that, you can keep on working
[23:15] <fta> ok
[23:23] <fta> dtchen, could you please tag your packages with something else than ~ppa? the idea is to be able to see where the updates are coming / came from
[23:26] <dtchen> fta: sure. the `linux' upload is a simple bump (9.31ubuntu1)
[23:26] <dtchen> i'll just need to adjust dch