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