[10:55] does anyone know where to find roman numerals? i dont see them in the char. map [10:56] ᦙ [10:56] gnomefreak, how about "MMXII"? [10:57] are those I's [10:57] that should work [10:59] yep that works for me. thanks directhex [11:23] !music [11:23] Sorry, I don't know anything about music [11:23] !extract [11:23] Sorry, I don't know anything about extract [11:23] !cd [11:23] Sorry, I don't know anything about cd [11:23] damn you bot [11:23] !bot [11:23] Hi! I'm #ubuntu-mozillateam's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots [11:23] !cd extracting [11:23] Sorry, I don't know anything about cd extracting [11:24] Nafallo: yeah i know the bot all too well :( [11:24] gnomefreak: think you want help.ubuntu.com or something ;-) [11:24] Nafallo: yeah im there and search shows nothing [11:24] i might still have the link [11:25] gnomefreak: rhythmbox can do it. sound-juicer likewise. [11:25] probably banshee as well :-) [11:26] Nafallo: but they dont change format (atleast rhythmbox and i thought sound-juicer was default app but i dont see it [11:26] gnomefreak: how do you mean? [11:26] Sound Juicer is Ubuntu's default CD-ripping application, [11:26] change format? [11:26] no no. sound-juicer WAS Ubuntu's default until rhythmbox grew that feature. [11:27] from .wav to mp3 (i think default cd tracks are .wav [11:27] )* [11:28] CD tracks aren't files, so they don't have anything as convenient as a container format [11:28] directhex: when extracting the extract as .wav IIRC [11:28] gnomefreak: you need to install gstreamer lame or whatever :-) [11:28] true. it's a convenient container [11:29] .wav, .flac, .ogg, .mp3 are the default profiles IIRC [11:29] i have everything i need but cant find a player that extracks [11:29] .wav being close to raw. [11:29] gnomefreak: I gave you three examples mate... [11:30] banshee, too! [11:30] but sound-juicer & rhythmbox are default options [11:30] Nafallo: i know but they dont give a choice to change format but im looking into them atm [11:30] gnomefreak: they sure do for me. [11:31] gnomefreak: rhythmbox, edit, preferences, music, preferred format [11:32] Nafallo: thanks i found it [11:32] :-) [11:32] directhex: sound-juicer is no longer default (atleast not in Jaunty [11:33] jauntwho? [11:33] not since hardy IIRC [11:33] * directhex is running hardy on here ;) [11:33] * gnomefreak has Intrepid and Jaunty with chroots for dapper and up [11:34] brb upgrades are taking forever [11:37] asac, mozilla bug 381900 :( [11:37] Mozilla bug 381900 in Build Config "Make a checkout target for the build system" [Normal,Resolved: wontfix] http://bugzilla.mozilla.org/show_bug.cgi?id=381900 [11:37] hi [11:38] just emerged from a 17h sleep [11:38] morning fta :-) [11:40] thx, it's almost 1pm here :P [11:41] Mon Dec 15 11:41:31 GMT 2008 [11:41] :-) [11:41] delivery in 19 minutes hopefully :-D [11:42] want to have it done before I go on holiday on Wednesday :-) [11:42] delivery? [11:46] yea. to the datacenter :-) [11:46] bits and bobs I need basically. [12:08] asac, mozilla bug 467874 [12:08] Mozilla bug 467874 in GFX: Thebes "cairo calls FT_Done_Face on FT_Faces for unscaled_fonts created from_face" [Critical,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=467874 [12:40] whats the new name for gstreamer-lame-*? [12:41] there's no such thing. it's either gstreamer-* or lame [12:41] it used to be gstreamer0.8-lame [12:42] it has since changed its name [12:44] gstreamer0.10-plugins-ugly-multiverse then [12:44] the package lame doesnt help [12:44] fta: i have it and still not helping [12:44] it contains /usr/lib/gstreamer-0.10/libgstlame.so [12:44] gstreamer0.10-plugins-ugly-multiverse: Installed: 0.10.7-2 [12:45] what are you trying to do? [12:45] nothing seems to want to change format to mp3 to rip [12:46] https://help.ubuntu.com/community/CDRipping [12:49] works for me [12:51] i made the profile and edited it so i have mp3 option but selecting it doesnt add it to the dropdown when choosing the format to rip [12:52] fta: did you use audio/x-raw-int,rate=44100,channels=2 ! lame name=enc bitrate=160 ! id3v2mux for gstreamerpipeline? [12:52] i found problem i think [12:53] yep fixed that now to get sound-juicer to load cd [12:54] ok now breakfast while riping than get ready for meeting [13:33] uuuuah [13:34] pain everywhere ;) [13:35] fta: how was your trip back? [13:36] better than the other way [13:36] yeah ... it was amazing 3h faster to go that way [13:36] tail wind made us fly 1100 km/h ;) [13:36] well almopst [13:36] also not over arctis, but straight over US [13:39] sfo-cincinnati was quite nice, bigger seats, nice personal tv, yet, VOD was not free. same for the food. [13:40] cincinnati-paris was nice too, but the seats were old, no personal tv, food was ok. [13:40] for the 1st time ever, i was able to sleep [13:40] heh [13:40] yeah [13:40] i could sleep as well a bit ... but not much [13:41] but for London to HAM it was stupid ... we boarded at flight time (so far too late) ... and then didnt get any slot and couldnt leave the gate for 1h ... then another 30 minutes traffic jam [13:41] i fell asleep there ;) [13:44] for cvg-paris, we had some electrical problems, half of the plane had no light/no sound. they tried to reboot, to change the fuses, nada [13:44] fortunately, i was on the right side which was fine [13:46] rebooting my router. brb [14:15] fta: ouch [14:15] ? [14:15] electrical problems [14:15] fta: did you hear about the german folks that left the hotel early in the morning? [14:15] nope [14:15] when i arrived at airport late afternoon they where still there [14:15] lol [14:16] apparently their plane couldnt properly lift the wheel [14:16] so they took a 2+ hour flight over the desert of nevada dumping fuel [14:16] and then came back [14:16] wooowww [14:16] ogra was completely pale ... he is scared of flying anyway [14:16] lufthansa told them that they had another plane they could use [14:17] but then shortly before we left they all came up from gate and said that apparently there was no plane and now it was delayed without any new time [14:18] at that moment i was happy that i was on a crappy cheap united flight ;) [14:18] most likely they didnt made it yet ;) [14:19] fta: also pitti (on another lifthansa flight) was also still there ... they couldnt close the door [14:19] scary scary [14:19] somehow i have the feeling that the technical crew at SFO is a bit overworked ;) [14:20] scary indeed. [14:20] i'm glad i'm home now :) [14:20] me too ;) [14:22] asac, fta: welcome back :) [14:22] asac: there is another patch for nspluginwrapper, which we might apply before pushing. [14:23] asac: it sounds like it should help npw to be more stable, as it should fix one rare, but possible crash situation [14:25] anyway, I'm off to study a bit, then I'll test the patch tonight... [14:33] Jazzva: yep ... fwiw, i subscribed to your twitter i think ;) [14:33] asac, identi.ca :) [14:34] Jazzva: you are on that too? [14:34] asac, twitter is similar, but more popular, and also it's source is not available. [14:34] s/it's/its/ [14:34] yeah right [14:35] i subscribed to your identi.ca thing ;) [14:35] noticed :) [15:21] asac, http://www.sofaraway.org/ubuntu/tmp/IMG_1190.JPG [15:30] fta: lol [15:31] fta: could you upload all images you have from me somewhere? [15:31] ;) [15:31] Jazzva: how about a microblog bot here ;) [15:32] so when i am saying: "off for shopping" ... i dont need to post it here as well ;) [15:32] lets see if irssi has a identi.ca or twitter plugin [15:32] asac, good idea :) [15:34] http://projects.friocorte.com/twitter-irssi/ [15:34] hmm [15:34] what does that do? [15:37] asac, it should just display you an updates timeline of you and your friends, and should work on twitter (www.twitter.com). I suppose it could be adapted for identi.ca [15:37] The Identi.ca API supports an API compatible with Twitter's. [15:38] hmm ... maybe it can be used as a base for what i want to do [15:39] probably... just add him a listener functionality to recognize your "[post] blabla" input :) (sounds reasonable to me, although I don't know how the plugin works) [15:45] Jazzva: do you use irssi too? [15:46] Jazzva: btw, did you figure how to tag stuff in identi.ca? [15:57] asac, brb... a friend dropped by. I got a late birthday present - a coughing ashtray... it actually coughs when you touch it :) [16:03] Jazzva: oh ... congrats (in case i didnt do that for your birthday) [16:09] and here's the ashtray - http://www.youtube.com/watch?v=TzcT0Mn0QiI [16:12] jcastro: how do I tag stuff on identi.ca? [16:19] Jazzva: urgh ... why didnt you do a bzr merge to get new upstream sources? [16:19] (nspluginwrapper) [16:22] Jazzva: withtout a merge you cannot get the upstream from the .ubuntu branch :/ [16:25] Jazzva: so to get the "initial" upstream branch you do: [16:25] bzr branch -r 1.1.3 nspluginwrapper/ upstream.real [16:26] (i guess your prob was that you couldnt find the right upstream branch) [17:08] hmm [17:08] asac: like this, #mozilla [17:08] or whatever [17:11] jcastro: oh ... so just add that to the message? [17:13] jcastro: you know whether i can tag it a-posteriori? [17:21] jcastro: http://identi.ca/asac ;) [17:29] Jazzva: do you still have firefox-sage.ubuntu branch locally? i get: [17:29] bzr: ERROR: bzrlib.errors.NotLefthandHistory: Supplied history does not follow left-hand parents [17:35] asac: no you can't add afterwards [17:36] asac: launchpad.net/gwibber is what I use as a desktop app [17:36] jcastro: yeah ... ok i am using #ubuntu-mozilla as tag to post work for ubuntu-mozillateam ... i hope i can use that later to assemble better team reports [17:36] yep [17:37] I have a script someone made to make a bunch of dents spit out in moin format [17:37] I'll get it out asap [17:37] cool [17:37] we have a pending action for mozillateam how to post work done ... i will suggest to use identi.ca for that [17:37] <3 [17:38] jcastro: i think we should ask launchpad to allow users to link to it ... that would be cool ;) [17:38] e.g. on top of jabber, mail etc. [17:38] already on it [17:39] a bunch of launchpadders use it already [17:39] maybe even show the last few things like a rss summary or something [17:39] yep [17:41] jcastro: is gwibber usable yet? [17:41] yeah, it's been good for a while imo [17:41] if you have packages and need a sponsor for debian/ubuntu let me know ;) [17:41] I do [17:41] I need him to convince a 1.0 [17:42] jcastro: i can also take a look at pre-1.0 packages if the guy doing this wants them in [17:42] oh its you ;) [17:43] heh [17:43] it doesn't need anything special for jaunty [17:43] the older stuff needed new webkit, pywebkit, etc. [17:43] but we should be all set for jaunty imo [17:43] other than my packaging nitnoids I'm sure [17:46] cool ... i will try the packages later then ;) [17:53] jcastro: i found "tags" in settings. what happens if i add a bunch there? [17:54] jcastro: does that auto tagging or just shows folks what i am interested in? [17:56] settings in where? [17:56] in gwibber or the page? [17:56] jcastro: no i mean in identi.ca :) [17:56] those will show folks what you are interested in [17:57] ah ... too bad that it removes "-" ;) ... guess i have to use #ubuntumozilla then [17:57] yeah he's still working on - and _ [17:57] hmm ... so it seems that peopletags are different to post tags [17:57] http://identi.ca/tag/ubuntumozilla [17:57] is what you want to tell people to follow [17:58] yep ... thought that it tags in profile would allow folks to click on them and then get messages [17:58] saw that #ubuntu-mozilla messages pop up when using ubuntumozilla ... so fine [17:58] ok [18:01] asac: I just mailed you the script we used for UDS [18:01] grewat [18:02] could easily be adapted for your team report generator [18:02] jcastro: is it a bad idea to say "automatically subscribe to users that subscribe to me?" ... it says: "best for non-humans"? [18:03] I turn it on [18:03] when you get hundreds of followers you might want to shut it off [18:03] ok ... lets try ;) [18:43] asac: hey [18:44] rgreening: hi [18:44] asac: when you have some time, I was hoping ot start work on Firefox KDE integrations issues that we discussed at UDS :P [18:44] yep ... let me look something up [18:45] cool. ty [18:45] rgreening: https://wiki.ubuntu.com/Firefox3KDEIntegrationIntrepid [18:46] awesome [19:00] asac: I had a quick read. Looks great. Is anyone started on any part of this spec? [19:00] asac: sorry, I was off. So, bzr was showing me some errors, it wasn't possible to merge .ubuntu with .upstream, sort of "no common predecessor" error. I didn't know what cause it, and I just copied the sources from .upstream to .ubuntu (yeah, I know it's not a good thing to do) [19:00] asac: sorry about that... [19:01] I'll fix them for the next upload... [19:01] and for firefox-sage branch, I don't think I have it locally. let me check [19:01] ok, maybe on the desktop... just to turn it on [19:02] rgreening: no ... there are basically a few things that need to happen: [19:02] rgreening: 1st: identify the functions/operations we need to make desktop dependent and design a idl for that [19:02] e.g. [19:02] nsILinuxDesktopIntegration.idl [19:03] rgreening: then we need to create two implementations: 1st: nsGnomeDesktopIntegration and 2nd: nsKDEDesktopIntegration [19:03] and move the current gnome code there (or reuse existing components) [19:04] Jazzva: ok let me know when the nspluginwrapper branch is repaired so i can upload ;) [19:04] Jazzva: i think its easiest to reapply the diff from after your initial copy there ... though you might have problems because you did multiple rounds of copies [19:04] Jazzva: so maybe reapply the diff but exclude everything not in debian/ [19:04] asac: ok. [19:05] e.g. bzr diff -rX..Y | filterdiff -i*/debian/* [19:05] asac: ok [19:06] hmm... problem with bugmail and bugreports that have many affected projects. for example bug 272959. I can't see the mail because of all affected projects :) [19:06] Launchpad bug 272959 in useragentswitcher "Packages that depend on firefox-2 or firefox should just depend on firefox" [Low,Confirmed] https://launchpad.net/bugs/272959 [19:07] Jazzva: hmm ... yeah. i have no solution for that [19:08] maybe one can tell mutt to only certain affected headers [19:09] or to include a scrollbar, if possible :) [19:15] @time [19:15] Current time in Etc/UTC: December 15 2008, 19:15:51 - Current meeting: LoCo Council [19:17] asac, I have firefox-sage.ubuntu. [19:17] *firefox-sage.ubuntu locally [19:17] Jazzva: http://identi.ca/notice/1470949 [19:17] ;) [19:17] all fine agaiun [19:17] Jazzva: please run the same on your branch [19:17] or dump it (i guess its all merged in anyway) [19:18] yeah, it is [19:19] ok, I'll dump it on LP === rgreening_ is now known as ghost === ghost is now known as Guest98214 === Guest98214 is now known as ghost_ === ghost_ is now known as rgreening_ [20:02] james_w`: feature request: bzr bd --show-user-config-dirs -> in that way our get-orig-source could automagically place the tarball in the right directory [20:05] james_w`: filed: 308276 === rgreening_ is now known as rgreening [20:29] asac: branch format for lp:~ubuntu-dev/nspluginwrapper/upstream should be upgraded - bzr suggested that === asac_ is now known as asac [20:38] Jazzva: ok let me do that [20:38] ok, I'll do that for my branches [20:38] Jazzva: err. jazzva... the right way to get upstream branch is to look in the log [20:38] Jazzva: of .ubuntu [20:38] and use the revision last merged in [20:38] Jazzva: e.g. the upstream branches are not needed anymore [20:38] uh? [20:38] (and not sure if its really up to date) [20:38] let me check [20:39] that's something new for me :) [20:39] Jazzva: yeah ... didnt i post the right revision in my comment? [20:39] e.g. something like 1.1.4? [20:39] Jazzva: search for 1.1.3 in bzr log of ubuntu branch [20:40] so, something like 'bzr branch -r branch.ubuntu'? [20:40] so to get the right upstream branch you do: bzr branch -r 1.1.3 lp:nspluginwrapper [20:40] ah... ok [20:40] yeah ... so: bzr branch -r 1.1.3 lp:nspluginwrapper upstream [20:40] cd upstream [20:40] rm -r * [20:40] cp -r /tmp/newupstream/* . [20:40] bzr add . [20:40] bzr commit -m "* new upstream release ...." [20:40] then in nspluginwrapper simply [20:41] bzr merge ../upstream [20:41] and so on [20:41] right... [20:41] ok, less branches, more complicated (at least for now :)) [20:42] Jazzva: yeah. we even have a much better way we are supposed to use [20:42] e.g. .builddeb.conf -> there we put upstream=. and upstream-revision=revid:REVISIONID (you get the right revision id through bzr log --show-ids [20:42] but i have to document that somehow [20:43] mhm [20:43] Jazzva: for now looking in bzr log and using the revision you find there is good enough ;) [20:44] right [20:44] its just a bit more work as youz need to look that up [20:44] ok, doing it that way now [20:44] james_w`: the builddeb.conf file and its syntax is not documented in bzr help bd [20:45] * asac looks at lastlog [20:45] 11:59 < james_w> with a .bzr-builddeb/default.conf [20:45] 12:02 < james_w> do a "vi .bzr-builddeb/default.conf" before commit [20:45] 12:09 < james_w> http://jameswestby.net/bzr/builddeb/user_manual/export_upstream.html [20:45] there it is ;) [20:45] Jazzva: we should adapt all our branches accordingly ... but lets do that in a separate batch [20:46] umm... yeah. I need to adapt a bit [20:46] :) [20:46] Jazzva: heh ... first i have to document that ;) [20:46] let me check if we have any comprehensive doc on how to merge new upstreams at all [20:47] ok i guess the right doc to fix is: https://wiki.ubuntu.com/MozillaTeam/Extensions/Bzr [20:48] ok... just to check. i branched -r1.1.3 from lp:nspluginwrapper. copied new upstream source and commit that. do i need to branch .ubuntu branch from that? or just to apply the diff with /debian/ contents to that branch branched from lp:nspluginwrapper [20:48] ? [20:49] s/commit/committed/ [20:58] Jazzva: ubuntu branch -> bzr branch lp:nspluginwrapper [20:58] Jazzva: upstream branch bzr branch lp:nspluginwrapper nsp.upstream [20:58] err [20:58] Jazzva: upstream branch bzr branch -r1.1.3 lp:nspluginwrapper nsp.upstream [20:59] commit new upstream releas to nsp.upstream [20:59] then merge that into nspluginwrapper, add changelog entry [20:59] commit [20:59] apply your filtered diff [20:59] commit [20:59] release [20:59] ;) [20:59] ah, ok... thanks for the clarification :) [21:02] Jazzva: ok ... so if you want you can also add the .bzr-builddeb/default.conf [21:02] in the merge commit [21:02] and add as export-upstream-revision= [21:03] the revision-id you can see with bzr log --show-ids [21:03] using the syntax: [21:03] revid:ID [21:03] e.g. [21:03] if i do [21:03] bzr branch -r revid:fta@ubuntu.com-20081015152908-oacyq9kxr1jp6zk4 lp:nspluginwrapper [21:03] i get the 1.1.3 commit [21:03] export-upstream=. [21:04] when that is done you dont need to create upstream tarballs anymore ... just bzr bd --merge ... will do the right thing from there on :) [21:04] * fta is waking up.. hm? [21:04] asac, ok. I'll try to follow that :) [21:04] fta: talking about the meta file for doing automatic orig creation [21:04] fta: [21:05] 21:45 < asac> 11:59 < james_w> with a .bzr-builddeb/default.conf [21:05] 21:45 < asac> 12:02 < james_w> do a "vi .bzr-builddeb/default.conf" before commit [21:05] 21:45 < asac> 12:09 < james_w> http://jameswestby.net/bzr/builddeb/user_manual/export_upstream.html [21:05] fta: the idea is to use revision-ids rather than tags ... so we dont needs to bother to tag each and every commit on upstream branch [21:05] not very handy if you have to edit the file before a commit [21:06] fta: no that works fine [21:06] fta: you create upstream branch anyway [21:06] using revision id ensures that you alrewady kmnow it before [21:06] so [21:06] 1. commit new upstream sources to .upstream branch (locally) [21:06] 2. look at bzr log --show-ids | head [21:07] edit file to use the revision id in .ubuntu branch after merge, but before you commit [21:07] revisionid != revision [21:07] i think that should work quite well [21:11] sounds too complex, would be better to use tags [21:11] s/complex/error prone/ [21:12] fta: well .. tags would need a new syntax guideline ... is complex too [21:13] but in the end i dont mind ;) ... maybe we can leave it open to the one preparing the updates [21:13] if its done automatically there is no need for tags imo [21:24] I noticed that libxul0d is removed in Debian sid but still lingers in Ubuntu. Why is that? [21:25] I understand the reasons for the removal from Debian; it's the fact that it lingers in Ubuntu that's what I find weird. [21:31] Good evening everybody.. I'm an author of the library libproxy and a ubuntu user reported an issue with compiling the lib, linking against mozilla-js on Ubuntu 8.10. Libproxy uses pkg-config in order to identify the location of include files, but apparently on Ubuntu 8.10, this seems not to reflect the reality. Is something like this known to you? [21:53] DimStar: mozilla-js is a bit of an issue to link against [21:53] asac: why is that? [21:54] DimStar: there is no upstream policy for stable API/ABI [21:54] in fact they dont maintain any ABI/API hints in soname [21:55] DimStar: we had this discussion a few weeks ago with another author [21:55] asac: yes, that's indeed an issue, that's true... [21:55] DimStar: the final solution was to lazily load the .so [21:55] by finding the right place where the .so is through the GRE/glue mechanisms [21:55] asac: did you follow a bit of what 'my' issue was? it's actually that pkg-config --cflags point to an include dir where the headers do not reside [21:56] DimStar: yeah. you can just add /unstable there ... its a bug ... but as i said mozilla-js is not really supported ATM [21:57] asac: ok... well, as it's a 'confirmed' bug from the ubuntu side, then I'll just advise the user about it... and have it closed on our system... we can't possibly include hacks for every distro's bugs I 'm afraid [21:58] asac: is this bug tracked somewhere in a bugzills? (as reference for our tracker) [22:11] DimStar: well ... problem is still that you try to do something wrong [22:11] DimStar: you cannot link against it anyway the way you are tryingt to do it [22:11] DimStar: at least rename the bug on your side [22:12] fta: i guess you have enough backlog ... can you search for a spidermonkey discussion we had over the last month or two? [22:13] and give me a date so i can look athat up in irc archive? [22:14] DimStar: at best stay around a bit longer until i found the issue [22:14] err discussion ;) [22:17] asac, https://code.edge.launchpad.net/~jazzva/nspluginwrapper/ubuntu.jaunty/+merge/2356 [22:18] it's still scanning branch [22:19] Jazzva: yeah. next time consider to give the branch a topic name ... like .VERSION-0ubuntu1 ;) [22:19] so you can just mark as merged and dont need to delete [22:20] last suggestion was to use .release_name :) [22:20] asac, http://paste.ubuntu.com/85795/ ? [22:22] fta: can you also grep for everything that suzhe said? i think he also said more on the following days ;) [22:22] fta: but i can continue manually here ;) [22:24] http://paste.ubuntu.com/85797/ [22:24] ok [22:25] http://paste.ubuntu.com/85798/ [22:25] DimStar: ^^ read those above (only what me and suzhe says) [22:25] thanks asac... [22:25] DimStar: he finally came up with a proper solution [22:25] DimStar: he created a glue for js and loaded it through standalone glue [22:26] sounds more like a hack than a solution... [22:26] DimStar: btw, there is no issue with the headers from what i can see [22:26] DimStar: its a hack because there is no API/ABI [22:26] guarantee [22:27] so he hacks around the upstream constraint in a sensible fashion ... which everybody should do that wants to use mozilla-js before upstream takes a more decent approach [22:28] DimStar: also for the header: its not a bug [22:28] its just that the headers you want to access are "unstable" and so are not encouraged to link against [22:28] if it's not a bug it must be a feature :-) [22:28] meaning if you want to use them use: echo `pkg-config --variable=includedir mozilla-js`/unstable [22:28] DimStar: right ... its a feature [22:29] the idea is to not export stuff that might break deliberately ... when users want to do that they have to do explicit stuff like the pkg-config from above combined with the glue [22:30] well, I'll have a look at it... interestingly /unstable is not true neither... if the reporter is right, it's actually in /stable [22:30] DimStar: i know that its a bad answer, but thats how it is and the guy above did it in a good fashion i think. should be easy for you to adopt ... he even posted the glue code in the log and pointed to the code he uses to auto generate the glue [22:30] DimStar: stable is already in pkg-config: [22:31] DimStar: [22:31] pkg-config --cflags mozilla-js [22:31] -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9.0.4/stable -I/usr/include/nspr [22:31] yes, and is also where the jsapi.h lies actually... [22:31] _but_ [22:31] ls /usr/include/xulrunner-1.9.0.4/stable/js* [22:31] ls: cannot access /usr/include/xulrunner-1.9.0.4/stable/js*: No such file or directory [22:31] or.. .no... sorry.. the include is actually in the lib folder [22:31] ls /usr/include/xulrunner-1.9.0.4/unstable/js* [22:31] /usr/include/xulrunner-1.9.0.4/unstable/jsapi.h /usr/include/xulrunner-1.9.0.4/unstable/jslock.h [22:31] /usr/include/xulrunner-1.9.0.4/unstable/jsarena.h /usr/include/xulrunner-1.9.0.4/unstable/jslong.h [22:31] ... [22:31] DimStar: ^^ [22:31] so its in unstable ;) [22:31] ok [22:32] DimStar: but note that you dont know how to set the -rpath [22:32] which is also a feature [22:32] :-) [22:32] as that would only make sense if those symbols are actually abi/api tracked ... [22:32] (actually then that should go into /usr/lib/ [22:32] ) [22:32] the fact that its in pkglibdir instead just means: dont link directly against it ;) [22:33] DimStar: there are a few bugs mentioned in the log i and fta pasted [22:33] DimStar: there wa also a spidermonkey guy in here who agreed to it [22:33] so hopefully they will work on this in future [22:33] (tracking abi/api should be rather easy to do for them) [22:34] well... this gives me something to do :-) especially hoping the same won't break on all other distros where the exact thing actually works the way it is. [22:34] DimStar: will work on fedora and should also work on debian [22:34] if its not working on debian its a bug in their glue [22:34] DimStar: fedora works for sure ... suse probably too(if they have a xulrunner package at all) [22:34] asac my goal is not to move the bug from one system to another... then I prefer keeping the bug on a well defined place :-) [22:35] asac: suse has working xul packages.. and the whole story with pkg-config works as expected for normal packages there [22:35] DimStar: yeah because they probably introduced a hack for that ... what do they give you for pkg-config --cflags? [22:36] DimStar: (if they have a proper xul pakage then the method i described will work) [22:36] pkg-config --cflags xulrunner-js [22:36] -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.8.1.17/js -I/usr/include/nspr4 [22:36] DimStar: thats an old xulrunner package ... do they have xulrunner-1.9? [22:37] yes.. let me verify what 1.9 says [22:37] and actually 11.1 ships xul 1.8.7 and 1.9... for good reasons [22:38] 1.8.7? [22:38] 17 you mean ;)? [22:38] right [22:39] Jazzva: it should be revid:REVISION-ID ;) [22:39] i can fix that in merge [22:39] not REVISION-ID [22:39] right... sorry about that [22:39] Jazzva: also export-upstream = . [22:39] not URL [22:39] because we want to produce the orig from the same branch you are in [22:40] testing can be done by removeing orig.tar.gz [22:40] and just doing bzr bd --merge [22:40] Jazzva: cool ;) ... it really works with those modifications ;) [22:41] ok, i'm testing it :) [22:41] asac.. that's from the xulrunner 190 package: [22:41] pkg-config --cflags mozilla-js [22:41] -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9.0.4/unstable -I/usr/include/nspr4 [22:41] DimStar: we have rotten old xulrunner in universe as well ... i think even in intrepid [22:41] DimStar: problem is that it will definitly go away in this cycle for every distro [22:41] which is why i would suggest to fix it for real [22:41] 11.1 is being released in two days and it's still in :-) [22:42] DimStar: yeah ... this cycle isnt this cycle for all distros ;) [22:42] consider 11.1 to be last cycle ;) [22:42] asac: next one will be around 09-09.... so plenty of time for moz to fix it [22:45] DimStar: unlikely that there will be a fix for that before mozilla 2 [22:46] asac: how long will the paste links you posted be available? [22:47] DimStar: not sure if they get backed-up ... but unless there is hardware failure incident they probably wont be removed at all [22:47] DimStar: also take the paste fta paste before [22:47] thats the first day of discussiuon [22:47] ok.. so it's fine to link them from the issue [22:47] the others are day 2 and 3 [22:47] got it [22:49] Thanks very much for your time+ [22:50] DimStar: wait [22:50] DimStar: what does suse give you for pkg-config --libs mozilla-js ? [22:51] fta: what was the blocklist time calculate thing again? [22:52] perl -e 'print scalar localtime($num)' [22:52] mine is ~mid aug here too, like on my laptop [22:55] fta: strange ... thats i386 though right? [22:55] desktop, yes [22:55] my laptop is 64 [22:56] Jazzva: can you look up app.update.lastUpdateTime.blocklist-background-update-timer in about:config [22:56] what does it give you? [22:56] DimStar: maybe you can look too ;)? [22:57] 1219108309 [22:57] asac, 1229378620 [22:57] fta: thats 3.1 right? [22:57] right [22:57] 1229378620 is correct [22:59] last week, i bump the interval to 60sec and sniffed my network; nada [22:59] bumped [22:59] fta: what is extensions.blocklist.url [22:59] ? [22:59] https://addons.mozilla.org/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/ [23:11] strange that both my 2 ff stopped the same day. I can't remember if i touched something that day [23:11] fta: that url is probably invalid [23:11] because its ffox 3.1 [23:12] ffox 3.0 -> [23:12] https://addons.mozilla.org/blocklist/2/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/ [23:12] note the "2" [23:12] i can't see any packet leaving the box [23:24] maybe an upstream commit between 20080809r16542 and 20080819r17035 [23:32] fta: hmm ... maybe. can you try to launch firefox 3.0? [23:32] and look in that profile? [23:40] Dec 5 [23:40] <[reed]> yeah, if blocklist stuff isn't working, that's a real problem [23:40] <[reed]> that definitely needs to be working [23:40] looks fine, i last use 3.0 to check-in on Delta [23:41] so for some reason 3.1 is not working at all for me [23:46] fta: ok ... can you check that the blocklist was updated now that you started 3.0 again? [23:51] asac, yep, it worked for 3.0