[00:00] <fta> universe?
[00:00] <asac> why not
[00:00] <fta> i don't know why it's not in there yet
[00:00] <asac> its the perfect place for that ;)
[00:00] <asac> now that it becomes more popular
[00:00] <fta> there's probably a reason
[00:00] <asac> fta: there is no sponsor/maintainer
[00:00] <asac> fta: ask jcastro
[00:01] <asac> ;)
[00:01] <fta> jcastro, ^^
[00:03] <jcastro> fta: I usually don't push one unless upstream asks me to
[00:03] <jcastro> he doesn't really want it in universe until he gets it hooked up to the gnome keyring
[00:03] <jcastro> which he's working on currently
[00:04] <jcastro> fta: however, if you want to throw an update into your PPA I have no qualms copying them to the official PPA. :D
[00:04] <fta> jcastro, ok, i can do a rogue snapshot then
[00:04] <jcastro> fta: follow the versioning scheme that's in the gwibber ppa, let me know and I'll copy them over when yours are built
[00:04] <fta> i follows the version scheme so it integrates well
[00:04] <fta> yeah
[00:04] <fta> -s
[00:04] <jcastro> actually
[00:04] <jcastro> let me just give you access to the gwibber ppa
[00:05] <jcastro> so if I get hit by a truck you can update
[00:05] <fta> lol, I think i risk more than you do, i commute by bike everyday
[00:06] <fta> and in paris, drivers are crazy
[00:06] <jcastro> your lp username is "fta" right?
[00:06] <asac> obviously ;)
[00:06] <jcastro> well, I never assume lp names because there are so many ones
[00:06] <jcastro> and I've on many occasions assigned bugs to the wrong people, heh
[00:07] <fta> asac, http://paste.ubuntu.com/104608/
[00:07] <jcastro> fta: ok you should be able to push to the gwibber ppa now
[00:07] <fta> asac, that's for your "is not a symbolic link"
[00:07] <jcastro> fta: I usually push to my personal ppa, announce on identi.ca for people to test it
[00:07] <jcastro> and then if I get good results I push it to the official ppa
[00:08] <asac> fta: do_remove = 1 is default ... scary
[00:08] <asac> but "is not a symbolic link" sets it to 0
[00:08] <asac> so should be ok i hope
[00:09] <fta> jcastro, great, i'll experiment on my side 1st, i hate to push broken stuff, and now that ppa have stats, it's even worse
[00:09] <asac> ppa have stats?
[00:09] <asac> what kind of stats?
[00:09] <fta>  PPA build status
[00:09] <fta> Total builds: 	2781
[00:09] <fta> Failed 	305
[00:09] <fta> Pending 	2
[00:09] <fta> Superseded 	66
[00:09] <fta> Succeeded 	2408
[00:09] <asac> ok
[00:10] <asac> thought download stats ;)
[00:10] <asac> for a moment
[00:10] <fta> no, i wish
[00:10] <fta> if only
[00:10] <fta> 11% of failed :(
[00:11] <fta> I push by 36 so it raises fast
[00:11] <asac> 36?
[00:12] <fta> asac, you cost me ~108 bad with your upstreamed patches
[00:12] <asac> you mean because i forgot to rename?
[00:12] <asac> in series?
[00:13] <fta> {xul/ff 3.1/3.2} {hardy,intrepid,jaunty} {i386,amd64,lpia}
[00:13] <fta> yes
[00:13] <asac> good ;)
[00:13] <asac> finally i found a purpose ;)
[00:14] <asac> i will try to do better in future ;)
[00:14] <fta> yes, please
[00:14] <fta> at least, push the full series
[00:14] <asac> did i push half series at some point ;)?
[00:16] <asac> fta: i think 10% isnt that bad ;) ... givent that moz central is burning more than half of the time ;)
[00:16] <fta> when you renamed a patch without updating the series, obviously
[00:16] <asac> http://tinderbox.mozilla.org/Firefox/
[00:17] <asac> fta: yes, but in that case  just forgot th eseries ... didnt push "half" of it :) (just kidding because of "full")
[00:20] <fta> lol https://code.edge.launchpad.net/gwibber
[00:20] <fta> more contributors than us
[00:21] <asac> whats funny?
[00:21] <asac> ah
[00:21] <asac> we dont have an upstream tree
[00:21] <asac> its natural that you dont get that many ;)
[00:21] <asac> those are mostly topic branches
[00:22] <asac> but did they ever contribute anything? e.g. how many got merged at some point?
[00:24] <fta> how would I know
[00:24] <asac> launchpad auto detects that nowadays
[00:25] <asac> at least when you requested a merge
[00:25] <asac> if the merge is pushed the merge request gets auto flagged as "merged"
[00:25] <fta> https://code.edge.launchpad.net/~gwibber-committers/gwibber/trunk
[00:25] <asac> imo branches should be marked as such too
[00:25] <fta> the last two, maybe
[00:25] <asac> otherwise you end up with zillions of new ones
[00:30] <fta> jcastro, hm, how do you merge the two branches? manually?
[00:30] <fta> i see two .bzr in your last tarball
[00:31] <fta> too bad you don't have a debian dir in the packaging branch
[00:39] <asac> what kind of packaging branch doesnt hav a debian/dir at all?
[00:39] <fta> asac, https://code.edge.launchpad.net/~gwibber-team/gwibber/packaging
[00:40] <asac> fta: yes. thats a "debian" only branch
[00:40] <asac> fta: you can use it like ours
[00:40] <asac> just take the upstream branch
[00:40] <fta> i have it
[00:40] <asac> and use --merge --export-upstream=/path/to/upstream --export-upstream-revision=...
[00:41] <asac> on first build to get the orig
[00:41] <asac> then you can copy that for subsequent runs to tarballs
[00:41] <asac> and just use --merge
[00:41] <asac> ( bzr bd)
[00:42] <jcastro> fta: yeah when I first made it I failed at naming it properly
[00:42] <fta> ok, i jast packed the tarball myself, and used --merge
[00:42] <fta> jsut
[00:42] <fta> grrr
[00:42] <asac> branch should also get .bzr-builddeb/default.conf
[00:42] <asac> with revid:... and so on
[00:42] <asac> so you can fix the upstream revision for individual releases
[00:44] <asac>   ok off to sleep
[00:44] <asac> cu
[00:44] <jcastro> what I do is when he says to do a release I go into my gwibber dir, bzr pull, then I bzr branch my packaging branch into debian/, then debuild
[00:45] <jcastro> This was my first ppa so I am totally open to whatever everyone else is doing
[00:46] <fta> we have a packaging branch like yours but with a debian/ dir
[00:46] <fta> so bzr bd --merge from the packaging branch works directly
[00:46] <jcastro> yeah
[00:46] <jcastro> I didn't know about this bd --merge
[00:47] <fta> 0.7~bzr120~intrepid~ppa0 looks like a native version to me
[00:49] <fta> what about 0.7~bzrXX-1~intrepid~ppaY instead? so upstream is 0.7~bzrXX and packaging is 1~intreprepid~ppaY
[00:49] <fta> 1 or 0ubuntu1, i don't mind
[00:49] <jcastro> what is the 1 for?
[00:49] <fta> 1st iteration of packaging
[00:49] <fta> debian syntax
[00:50] <jcastro> I thought that's what ppaX was for?
[00:50] <jcastro> sure, whatever you think is best
[00:50] <fta> ok
[00:50] <jcastro> I kind of just winged the version to what seemed to work
[00:50] <jcastro> I am not really wedded to anything as long as I know how to do it from then on
[00:50] <fta> feel free to reject my changes afterwards ;)
[00:51] <jcastro> Having someone who cares about updating it is worth changes to me. :D
[00:58] <fta> current snapshot seems broken
[00:58] <fta> it starts file, i open the about dialog, i can't close it
[00:58] <fta> http://paste.ubuntu.com/104618/
[00:58] <fta> -file+fine
[01:00] <fta> jcastro, ^^
[01:32] <fta> jcastro, to update the package automatically: http://paste.ubuntu.com/104627/ (that's without the --export-upstream* from asac).
[01:35] <fta> "+" is fixed, not \
[01:37] <fta> a get-orig-source rule would be nice
[11:35] <asac> fta: you dont like --export-upstream?
[11:51] <asac> bug 316452 becomes more interesting
[11:52] <asac> ldconfig is too smart for us ;)
[13:44] <fta> asac, it's not that i don't like --export-upstream, more that i never used it. should experiment 1st.
[13:53] <asac> ah
[13:54] <asac> thought you use bzr bd
[13:54] <asac> fta: --export-upstream isnt perfect .. if you are on a different system the same export can have different check-sum
[13:54] <asac> so its usually a one time operation
[13:54] <asac> so bzr bd -e --export-upstream... could do the trick
[13:54] <asac> for "just" export
[13:56] <asac> with default.conf you dont have to care at all
[13:57] <fta> i use bzr bd all the time, but without --export-upstream
[14:11] <asac> fta: so jaunty is + and hardy is ~ ;)
[14:11] <asac> not that bad ;)
[14:12] <asac> except that you have to bump veresion for jaunty upload to next ubuntu revision
[14:12] <asac> (if uploaded officially)
[14:12] <fta> my mistake, jcastro used intrepid as default.
[14:12] <fta> no, i can bump ftaX
[14:13] <asac> fta: yeah ... but usually we dont include personall suffixes in uploads to official archive
[14:13] <asac> not really an issue though ;)
[14:13] <fta> the naming in my ppa doesn't hurt the one in the gwibber ppa, i'm lower, i can use their naming when i push there
[14:14] <fta> i don't plan to copy, but to re-push
[14:15] <asac> fta: 0.7.3~bzr183-0ubuntu1~fta2 not fixed
[14:15] <asac> +
[14:15] <fta> the idea to use the ~fta sig in my ppa is to be able to identify my debs so it's clear in bugs and i can ask people to revert all my stuff if they complain too much
[14:15] <asac> fta: all fine ;)
[14:16] <asac> (fta suffix)
[14:16] <asac> i dont care ;) ... just wanted to point out and being picky ;)
[14:16] <asac> but the + isnt fixed for me :/
[14:16] <fta> but jorge pushed in it's own ppa too, with the naming i provided in my pastebin yesterday
[14:16] <fta> its
[14:17] <fta> https://edge.launchpad.net/~jorge/+archive
[14:19] <asac> fta: is the current snapshot latest bzr?
[14:19] <fta> i think so
[14:19] <asac> 187 ;)
[14:19] <asac> https://code.edge.launchpad.net/~gwibber-committers/gwibber/trunk
[14:20] <fta> 4 hours ago...
[14:20] <fta> so it's not, but close
[14:20] <asac> yeah.
[14:20] <asac> wasnt really a complain ;)
[14:36] <asac> fta: bump ;)
[14:36] <asac> jk
[14:49] <fta> asac, http://paste.ubuntu.com/104851/  ??
[14:50] <asac> fta: not sure why there is a difference
[14:51] <asac> the applications thing is for the start menu
[14:51] <fta> and why two ?
[14:51] <asac> the autostart thing is for autostart
[14:51] <fta> bzr-gtk: /etc/xdg/autostart/bzr-notify.desktop
[14:51] <fta> app-install-data: /usr/share/app-install/desktop/bzr-notify.desktop
[14:51] <asac> so nm-applet doesnt have a menu entry so its only in autostart
[14:51] <fta> i mean
[14:51] <fta> bzr-gtk: /usr/share/applications/bzr-notify.desktop
[14:51] <fta> app-install-data: /usr/share/app-install/desktop/bzr-notify.desktop
[14:51] <asac> fta: app-install-data is used for the add/remove ... dialog
[14:51] <fta> oh
[14:51] <asac> e.g. the apps listed there are available with image and so on before installing
[14:51] <fta> X-AppInstall-Popcon=318 sounds weird
[14:52] <asac> fta: yes, but makes sense. its the popularity info used to display in gnome-app-install
[14:52] <asac> based on popcon data
[14:52] <asac> http://popcon.ubuntu.com
[14:52] <fta> oh, lol, i thought they hardcoded their ranking
[14:54] <asac> yea its knd of hardcoded. just automatically updated
[14:54] <asac> and maintained outside the app ;)
[14:54] <asac> to prevent fraud
[15:06] <asac> jcastro: any clue why some messages from me dont show up on my personal page?
[15:06] <asac> (identi.ca)
[15:19] <fta> asac, jcastro, a bunch of fixes: https://code.edge.launchpad.net/~gwibber-team/gwibber/packaging
[15:19] <jcastro> fta: ok
[15:20] <jcastro> fta: I have some questions about that little script
[15:20] <fta> sure
[15:20] <jcastro> but they will have to wait until later
[15:20] <fta> ok
[15:20] <jcastro> actually I can do one now
[15:20] <jcastro> why the tarballs?
[15:20] <jcastro> I usually just bzr bd --split
[15:21] <fta> that's how it used to work with bd prior to --split, --export-upstream, etc.. old style i would say
[15:21] <jcastro> ah ok
[15:22] <fta> i can add a get-orig-source so none of this will matter
[15:29] <asac> fta: how about adding .bzr-builddeb/default.conf instaead=
[15:30] <fta> yeah, maybe it's time for me to look at this. pointer to a doc ?
[15:34] <jcastro> fta: in hindsight, could we perhaps rename packaging to debian so when we branch it in the gwibber dir it puts the debian directory in the right place?
[15:34] <jcastro> right now it spits out a packaging/debian/
[15:34] <jcastro> which is kind of dumb
[15:35] <fta> can bd use a flat packaging dir now?
[15:37] <Jazzva> fta: https://wiki.ubuntu.com/MozillaTeam/Extensions/Bzr there is something there about .bzr-builddeb/default.conf
[15:39] <fta> thx, i'll have a look later today, i have to run now
[16:58] <asac> jcastro: really, look at bzr-builddeb/default.conf stuff ... in that way you just get the debian dir and run bzr bd  -> done
[16:58] <asac> no hazzles ;)
[16:58] <asac> but fta now looks into it i gues
[17:04] <jcastro> asac: I am investigating it
[17:04] <jcastro> asac: I am slowly getting into the best practice
[17:04] <asac> jcastro: cool. https://wiki.ubuntu.com/MozillaTeam/Extensions/Bzr
[17:04] <asac> thats what we currently have for extensions
[17:04] <asac> look a bit down the page
[17:05] <asac> Configure .bzr-builddeb/default.conf to specify upstream branch revision ID  and ff
[17:06] <jcastro> yep I noticed that earlier
[17:07] <asac> yeah ... wasnt sure if you saw Jazzva's post
[17:30] <fta> back
[17:31] <[reed]> asac: that your first time to use Hg?
[17:31] <[reed]> :)
[17:31] <fta> asac, it's not very user friendly, i mean, you have to track the rev id yourself, bd should provide a hook for a script
[17:32] <asac_> reconnect
[17:33] <fta> asac_, <fta> asac, it's not very user friendly, i mean, you have to track the rev id yourself, bd should provide a hook for a script
[17:34] <asac_> fta: what kind of script?
[17:34] <asac_> for what purpose?
[17:34] <asac_> finding the revid?
[17:35] <fta> something to get the upstream version and rev id
[17:36] <asac_> what would be the improvement?
[17:36] <asac_> wouldnt it just help to update the default.conf properly when doing a merge --upstream-merge ?
[17:37] <asac_> fta: ?
[17:37] <asac_> for me this sounds like the feature we want ;)
[17:37] <asac_> maybe bzr bd-merge ;)
[18:07] <fta> asac, really, i don't see the benefit. you still have to find all the info yourself, and it's no longer a packaging branch, it's a huge branch with upstream in it, so it's slow.
[18:08] <fta> and big
[18:08] <fta> and worse, it's manual
[18:24] <jcastro> fta: asac: how are you guys liking this denting for team-related work?
[18:28] <fta> jcastro, about what? .bzr-builddeb/default.conf? gwibber?
[18:31] <jcastro> fta: I mean just denting in general about mozilla-team stuff
[18:31] <jcastro> I am wondering if we should encourage other teams to do the same thing
[18:31] <jcastro> get more info out there to users, etc.
[19:00] <BUGabundo1> fta asac ping
[19:01] <BUGabundo1> fta do you remember that last week I mention I saw a segfault on the console when closing FF?
[19:01] <BUGabundo1> well now, I see a popup several times a day
[19:02] <BUGabundo1> also is there a way for 3.1 not block pages auto-refresh, and not show that anowing button that says Allow, but clicking it won't allow anything??
[19:50] <asac> fta: manual? how is that?
[19:51] <asac> fta: i said: "wouldnt it just help to update the default.conf properly when doing a merge  --upstream-merge ?
[19:51] <asac> =
[19:57] <asac> jcastro: i use #ubuntumozilla ... as and experiment
[19:57] <asac> jcastro: havent done the automated summary thing yet though
[19:59] <fta> jcastro, i'm still unsure about that microblogging thing, it's fun for sure but on the long run, 140 chars are too short to convey anything more than instant feeling or quick Q&A. and it's volatile.
[20:00] <BUGabundo1> fta that's why I like jaiku
[20:00] <BUGabundo1> 140 for the OP
[20:00] <BUGabundo1> and unlimite for comments1
[20:00] <fta> asac, from the ex in the wiki, i don't see any benefit; but maybe i missed something
[20:07] <asac> fta: you missed that the ex in wiki is just a first simple solution. there are ways to make things better; but its definitly a good way. and full-source target - even though huge - are usually better either, as they have everything you need at the same place
[20:08] <fta_> it's a totally different work-flow
[20:08] <fta_> it has its own advantages and drawbacks
[20:09] <asac> the workflow is:  bzr  branch ... work on package; bzr bd ... no hazzles; no thinking about upstream etc.
[20:10] <asac> but i see that there can be different opinions ;)
[20:10] <fta_> the tarball thing is not ideal i agree, especially for tracking huge fast moving targets like moz trunk but here, that's two huge branches
[20:10] <fta_> i would rather use just one
[20:10] <asac> but i used both extensively and full-source is nicer for me
[20:12] <fta_> that's why i requested the doc, the wiki is a particular case
[20:12] <asac> 6 boxes burning in tinderbox ;)
[20:12] <asac> its not relevant for us anyway ;) ... at lesat until we can sync from hg to bzr
[20:12] <asac> otoh, once we move stuff to upstream thats ok i guess
[20:13] <asac> but i am not yet sure if we really should move everything there
[20:13] <asac> or improve upstream build to pull packaging from bzr  ;)
[20:15] <fta_> asac, read my answer to the chromium guys?
[20:15] <fta_> http://archive.ubuntu.com/ubuntu/pool/universe/f/fennec/
[20:15] <asac> mail?
[20:16] <jcastro> fta: btw I made a debian branch instead of packaging, now you can branch right in the gwibber root and it will do what you expect
[20:16] <fta_> asac, yes, mail
[20:16] <fta_> https://edge.launchpad.net/ubuntu/jaunty/+source/fennec/1.0~a2-0ubuntu1
[20:16] <fta_> how come the ftp only has 2 arches??
[20:17] <fta_> jcastro, ??
[20:18] <asac> fta_: thats ok ... publishing thing i guess
[20:18] <jcastro> fta_: instead of a stupid "packaging" directory when you check out it just puts the debian directory there
[20:18] <asac> fta_: ah ... now i understand your question ;)
[20:18] <asac> fta_: the other archs are on ports.ubuntu.com
[20:18] <asac> fta_: ?
[20:18] <asac> got that?
[20:18] <asac> 21:18 < asac> fta_: ah ... now i understand your question ;)
[20:18] <asac> 21:18 -!- fta [n=fta@ubuntu/member/fta] has quit [Read error: 110 (Connection timed out)]
[20:18] <fta> yes
[20:19] <asac> 21:18 < asac> fta_: the other archs are on ports.ubuntu.com
[20:19] <asac> k
[20:19] <asac> fta: i think usually only supported archs are on main ftp
[20:19] <asac> lpia is an exception
[20:19] <fta> when i reco, my old session takes ages to timeout :(
[20:19] <asac> not sure why it wasnt moved there
[20:19] <asac> armel will probably follow
[20:19] <asac> but maybe also an issue with mirrors and space
[20:20] <fta> armel in in ports
[20:20] <fta> is
[20:20] <asac> yes
[20:20] <asac> as i said
[20:20] <asac> armel is official i think ... same for lpia
[20:20] <asac> but both are stuck in ports
[20:22] <fta> i thought the debs were supposed to re-enter NEW but apparently not
[20:24] <asac> fta: reenter NEW? i think they were approved
[20:25] <asac> fta: you dont get mail if binaries end up in NEW
[20:25] <fta> the src was
[20:25] <asac> fta: binaries definitly too
[20:25] <asac> you just had luck that archive admins had an eager day ;)
[20:25] <fta> well, at least for xul 1.9.1, ff 3.1, it was in 2 steps
[20:25] <fta> i polled seb128, but i'm not sure who did it in the end
[20:26] <asac> fta: who cares  as long as it happened ;)
[20:26] <fta> sure
[20:30] <fta> epiphany crashed
[20:32] <asac> fta: will you go for ext4?
[20:32] <asac> ;)
[20:32] <fta> tempting but not now.
[20:32] <asac> i wonder if i try with build partitions first
[20:32] <asac> scared about loosing my home
[20:33] <fta> I need to change my main HD. mine is too noisy, and too slow
[20:33] <fta> and too small
[20:33] <asac> that would be a good moment to reconsider fs ;)
[20:33] <asac> fta: you need to get two fast raptor disks
[20:33] <asac> use them in RAID for build-dir
[20:34] <asac> that rocks ;) and boosts builds by 50% at least
[20:34] <asac> striped
[20:34] <asac> and for home two 1TB ;)
[20:35] <asac> doesnt need to be that fast
[20:35] <asac> just massive storage
[20:35] <asac> so four new disks ;)
[20:35] <asac> (at least i would need that)
[20:35] <asac> and a new CPU :)
[20:36] <asac> and 16GB of mem ;)
[20:36] <asac> read: a new computer ;)
[20:36] <jcastro> asac: I got a 32gb ssd. :D
[20:36] <jcastro> so I put that as / and my normal disk as /home
[20:36] <jcastro> though I should put my build area on the ssd someplace
[20:36] <asac> jcastro: is ssd fast?
[20:36] <fta> fta@ix:~ $ dmesg | grep segfault | tr '[' ' ' | awk '{ print $2 }' | sort | uniq -c
[20:36] <fta>       1 evolution
[20:36] <fta>      60 firefox-3.2
[20:36] <asac> jcastro: i wouldnt put / on it ... just /var/builddir
[20:36] <jcastro> asac: it's sick fast
[20:37] <asac> hmm
[20:37] <jcastro> my boot is like 15 seconds
[20:37] <asac> jcastro: can one stripe them even?
[20:37] <jcastro> and that was before people started optimizing boot for jaunty
[20:37] <jcastro> yep, they're normal sata drives as far as the pc is concerned
[20:37] <jcastro> that would be insanely expensive (but fast)
[20:37] <asac> hmm ... i dont ned fast boot ... just massive build performance
[20:37] <asac> at best for 4 builds at the same time ;)
[20:38] <asac> let me check what my dealer charges for those
[20:38] <fta> BUGabundo1, me too. i think apport changed or something
[20:38] <fta> gasp, too late
[20:38] <jcastro> asac: you want a samsung SLC SSD (which is the one I got) or any of the intel ones, the other ones suck
[20:39] <jcastro> asac: lots of new ones coming out this quarter though, so waiting is also an option. :D
[20:41] <asac> yeah ... head abou tthat
[20:41] <white> asac: xulrunner DSA released, waiting for Eric to upload iceweasel now
[20:42] <white> asac: thanks for all your work :)
[20:43] <asac> white: welcome too for helping out
[20:47] <fta> another ff3.2 crash on exit :(
[20:48] <asac> fta: isnt that the same segfault still?
[20:48] <fta> it is
[20:49] <asac> white: would you be interested to help out directly contributing to old branch security upstream?
[20:49] <fta> my 60+ crashes are when i click on urls, so remote sessions
[20:49] <asac> white: for instance, we lack folks that verify fixes for which we backport and commit patches
[20:49] <asac> fta: yeah. i will look into it at some point
[20:50] <asac> fta: could you report that upstream?
[20:56] <white> asac: well, i suppose I'll do future DSAs, but hope that other members of the sec team will take them as well. At the moment, I don't have the time to constantly check ice* code, but if issues arise, I'm happy to help :)
[21:00] <rzr> hi guys , do you know about palm's WebOS ? http://www.newlc.com/en/forum/palm-plateforms-also-gnulinux-based
[21:03] <fta> asac, mozilla bug 473629
[21:05] <asac> fta: do you have libc-dbgsym installed?
[21:05] <fta> http://paste.ubuntu.com/104971/
[21:08] <fta> asac, ^^
[21:12] <jcastro> asac: Is ap association speed after resume being real slow a NM problem or a driver problem?
[21:16] <asac> jcastro: its a scan thing i think
[21:16] <asac> jcastro: a reace
[21:16] <asac> race
[21:17] <asac> NM wakes up; wpasupp wakes up
[21:17] <asac> nm sends dbus scan but wpasupp isnt there yet
[21:27] <asac> fta: can you bump nspr and nss in ppa?
[21:27] <asac> (to include fix)
[21:29] <fta> I thought you pushed that to main !?
[21:33] <asac> fta: i mean for intrepid/hardy ;)
[21:34] <fta> ok
[21:34] <jcastro> asac: does that happen for everybody regardless of what driver they use then?
[21:34] <asac> fta: i have a intrepid sysstem where i likely can verify the upgrade issue because there are a bunch of stuff hanging
[21:34] <jcastro> asac: because for me it really sucks, it's easily over a minute
[21:35] <asac> jcastro: not known whether driver matters; if it matters, its just of a less/more fortunate timing; so its not a driver bug most likely
[21:35] <asac> jcastro: can you reproduce?
[21:35] <asac> for me its rather quick usually ... so ;)
[21:36] <jcastro> I will just give you my laptop during the sprint. :D
[21:36] <fta> [reed], i can't add checkin-needed for mozilla bug 460913
[21:36] <asac> let me check something
[21:37] <[reed]> why not?
[21:37] <[reed]> what happens?
[21:37] <fta> no such flag
[21:37] <fta> with my profile at least
[21:37] <[reed]> it's a keyword
[21:37] <[reed]> see at the top
[21:37] <[reed]> Keywords: ______________________
[21:37] <[reed]> put checkin-needed there
[21:38] <fta> oh, it's not per-patch
[21:39] <fta> should I add wanted1.9.1 too ? I need it there
[21:40] <[reed]> if you want to, sure
[21:41] <[reed]> you should request approval1.9.1 on the attachment
[21:41] <asac> fta: once the patch has landed and applies to 1.9.1 you can ask for approval stating a good reason ;)
[21:41] <[reed]> once it lands on trunk
[21:41] <asac> heh
[21:42]  * asac slow typer ;)
[21:42]  * asac should rest while eating ;)
[22:04] <fta> asac, damn, Rejected: File nspr_4.7.3.orig.tar.gz already exists in PPA for Fabien Tassin, but uploaded version has different contents
[22:04] <fta> asac, where did you take the tarball you pushed?
[22:29] <fta> asac, some dbgsym debs are missing: http://ddebs.ubuntu.com/pool/main/libs/libselinux/  no 2.0.65-5
[22:42] <fta> pff, it's not using debhelper at all
[23:16] <asac> fta: not sure. i think i used the one you had in ppa
[23:17] <asac> fta: hmm ... you think you can build libselinux with dbg?
[23:18] <fta> i tried, nada. i ended up forcing a nostrip build
[23:18] <asac> fta: you can do DEB_BUILD_OPTIONS="debug nostrip"
[23:18] <asac> no?
[23:18] <asac> err
[23:18] <asac> noopt
[23:18] <asac> ok
[23:18] <asac> right
[23:25] <fta> i think it's either a jemalloc/malloc confusion, or a flash unloading issue
[23:33] <asac> thought it happens on remote client too
[23:36] <fta> it does
[23:50] <asac> means its flash unrelated
[23:50] <fta> "Approved merge ~asac/gwibber/bug317073-pasted-url-escaping"
[23:50] <fta> \o/
[23:51] <asac> cool
[23:52] <asac> :)
[23:53] <asac> /usr/bin/ld: jsapi.o: relocation R_X86_64_PC32 against undefined hidden symbol `stdin' can not be used when making a shared object
[23:53] <asac> mozilla-central incremental build
[23:53] <asac> too bad
[23:53] <asac> cleaned just js/ ... lets hop