[00:00] cftok fixed [00:00] fta: fixed [00:01] andv: yes. but thats not a problem. [00:01] andv: he cannot upload to archive anyway [00:01] otherwise you can use the extension-dev team [00:01] asac_, we won't upload to ubuntu archive anyway [00:01] we gonna keep the package synced [00:01] andv: well. there are freezes in debian ... then you might upload to ubnutu [00:01] true [00:02] in that case yes [00:02] sveinung gonna merge the .debian branch changes into his main one [00:02] then merge it again on the ubuntu-dev [00:02] so we gonna keep just one merge [00:02] * branch [00:02] and not 2-3 of them [00:03] fta: ok so in the last few days new symbols were added [00:03] andv: do you prefer a merge or a rebase? [00:03] let me fix the automake version thing first [00:03] asac_ don't likes rebases [00:03] there are no .debian branch changes [00:03] if you need that you do something wrong [00:03] you only need one release branch [00:03] yes [00:03] and everything else is topic branches [00:03] if you think you need both be able to write to release branch [00:04] that's why he gonna merge .debian branch changes into ubuntu-dev one [00:04] then use ~ubuntu-extensions-dev team [00:04] to keep just one release branch [00:04] as you suggested [00:04] https://edge.launchpad.net/~mozilla-extensions-dev [00:04] andv: use that team to do collaborative extension maintenenace [00:04] if you dont want to use ~ubunu-dev [00:05] sveinung do you prefer https://edge.launchpad.net/~mozilla-extensions-dev [00:05] or the general ubuntu-dev branch? [00:05] you won't be able to upload to the ubuntu-dev branch [00:05] as you may know [00:05] so it's your choice === asac_ is now known as asac [00:07] andv: I'm not a member of ~mozilla-extensions-dev so ubuntu-dev is OK for me :) [00:07] sveinung, im not a member of ~mozilla-extensions-dev too [00:07] :) [00:07] brb [00:07] but asac can fix that if you want [00:08] in that case ~mozilla-extensions-dev [00:09] brb [00:09] I suggest you to make a brand new branch [00:09] in there [00:09] so we have a clean tree [00:09] for debian [00:09] andv: no need to [00:09] merge then? [00:10] no ... just push the ~ubuntu-dev branch there. [00:10] like we just did for ubuntu-dev [00:10] ok [00:10] then open changelog and change the bzr address [00:10] ok [00:10] i will mark the ubuntu-dev one abandoned then [00:10] yes [00:10] add a rationale for it [00:10] e.g abandoned for moving to a collaborative maintenance [00:10] somewhere else [00:11] andv: sveinung_: ok both of you added added to team [00:11] andv: no need to add a rational ... we can add the new location to the old branch info [00:11] asac: thank you [00:11] thanks [00:11] ok [00:11] its ok if things move [00:12] sveinung_, mere the ubuntu-dev branch [00:12] into the mozilla-extension team branches [00:12] * merge [00:12] nah [00:12] just push [00:12] hi asac [00:12] oh ok [00:12] sveinung_, just push the .debian branch [00:12] ok let me push [00:12] iok [00:12] one second [00:13] ok [00:13] ok new location is: lp:~mozilla-extensions-dev/firefox-extensions/all-in-one-sidebar.ubuntu ... will be there in a minute or too [00:13] have fun [00:13] i will document that in ~ubuntu-dev and mark it abandoned [00:13] great [00:14] sveinung_, push .debian changes into the brand new branch [00:14] pushed by asac [00:14] and we're done for now [00:14] asac, more fixes needed [00:14] https://code.edge.launchpad.net/~ubuntu-dev/firefox-extensions/all-in-one-sidebar.ubuntu [00:14] fta: for modemmanager? [00:14] that worked for me now [00:14] the nm stuff i will fix now [00:15] symbols + automake ... whatelse? [00:15] ok [00:19] andv: pushed into the new branch [00:19] perfect [00:21] sveinung, tomorrow I gonna fix some stuff [00:22] sveinung_, are you available tomorrow for testing= [00:22] andv: yes [00:22] perfect [00:22] fta: seems it was only symbols for NM ... made new snapshot and added tose [00:22] when the branch is ready I gonna ping you to test the package [00:22] * asac does a test build [00:23] andv: ok [00:25] andv: how early should I get on IRC? [00:25] which timezone are you in? [00:25] im gtm+2 [00:25] * gmt [00:25] +1 [00:26] fta: ok seems good [00:26] very nice \o/ [00:26] so it's 12.26 am [00:26] there [00:26] here it's 1.26 am === sveinung_ is now known as sveinung [00:27] as soon as I wake up tomorrow [00:27] and I fix those [00:27] andv: it's 1:25 here as well [00:27] I guess in the first afternoon [00:27] everything should be ready [00:27] like 1-2 pm [00:27] if you can make it [00:27] andv: OK, great [00:27] :) [00:28] oooook, im going to sleep now [00:28] im a bit tired [00:28] bye [00:28] asac, I've mailed you already [00:28] with some more details after reading your mail [00:29] maybe :) ... i dont know. i dont read mails in the evening [00:29] ok, you'll see it tomorrow then [00:29] asac, sveinung, fta: night [00:29] andv: night [00:39] fta: ok i think one more push and then good night ;)? [00:43] asac: when can I chat with you about firefox 3.6? [00:45] micahg: what info do you want? [00:45] well, they're working on the final roadmap this week [00:45] about "whethe ror not"? [00:45] if they decide to try to launch 3.6 in Nov [00:45] can we try to get in Karmic? [00:46] also, can we drop 3.0 from Karmic? [00:46] micahg: first, thats a roadmap. and while moz gets better at getting quick releases out, i dont expect that to happen [00:46] anyway [00:46] as you say top requirement for anything like that is to get 3.0 out ;) [00:46] well, someone said something about needing a release for Windows 7 compatability [00:46] we definitly cannot justify three xulrunner/firefox versions in the archive [00:47] correct [00:47] (or even 4 as we stil lavent removed 1.8 from the archive) [00:47] * micahg would help gut 3.0 and move to 3.6 [00:47] but wouldn't we look bad if they release a new version a month after us and we can't get it to the users easily? [00:47] so when do they plan first beta? [00:47] 3.5 was released 2 months after jaunty [00:47] sep [00:48] early sep [00:48] it's in the meeting plans to finalize the release part of the roadmap this week [00:48] thats the point. i mean, a few cycles back noone would have expected a second firefox in the archive [00:48] people always complained on ubuntu being outdated [00:48] but there was not a big deal [00:48] well, you already did it once [00:49] now we provide them and if we provide them we cannot rebrand them and people will bitch about that and so on ;) [00:49] * micahg is worried about the feature freeze [00:49] for me its basically a tool to get feedback from stable users ;) [00:49] of course i try to make users happy. but this second firefox is never our primary browser etc. [00:49] asac: does the branding require more validation or is it an ubuntu policy not to change branding? [00:49] ok long story short. i think we can get it in. [00:50] but not with a name like ~a1 [00:50] * micahg never got the full story [00:50] in the past we uploaded things not before a6 (for 3.0) and b1 (3.5) [00:50] I'm just worried about the feature freeze [00:50] it'll at least be late beta before release [00:50] granted those cycles were longer, but they also wanted a 9 month cycle for 3.5 and ended up making a full year [00:50] or at least early beta [00:51] micahg: in the past we had no problems to add that after feature freeze [00:51] can we get it in after feature freeze? [00:51] ok [00:51] that's my only concern [00:51] * micahg is wiling to help clean stuff up to make it happen [00:51] no guarantees, but if they reach beta before us then we will get it in [00:51] ok [00:51] but first we have to see that [00:51] I'd also like to get an alternative in there [00:51] in anycase. getting firefox 3.0 and xul 1.9.1 (and 1.8) out of the archive is a requirement [00:52] /etc/alternatives [00:52] or something [00:52] but also a worthwhile goal on its own [00:52] i want to get rid of them in any case [00:52] so users can switch between 3.5 and 3.6 [00:52] i am not so sure about alternatives [00:52] i dont like them [00:52] you wanna write up a spec? [00:52] * micahg can take tasks [00:52] users get too easily confused and trapped by them (without knowing about alternatives) [00:53] micahg: spec? about what? [00:53] ok, but I was thinking something like after 3.5 is EOL, users can switch the default (not us) to 3.56 [00:53] spec about removing 3.0 [00:53] or is there one? [00:54] micahg: so if we give up, we should migrate the default for everyone as otherwise the users left behind dont have security support [00:54] but alternative is no solution for that [00:54] imho [00:54] ok [00:54] I'd be interested in hearing other options [00:54] that would solve some of the EOL issues [00:55] it dosent solve them [00:55] it just hides them and makes them less populater [00:55] * micahg doesn't considering it giving up if you have a viable alternative (i.e. later browser in the disstro) [00:55] because all the xulrunner consumers would still be affected [00:55] ah, right [00:55] well [00:55] what do they do after mozilla EOLs a release? [00:55] micahg: who is they? [00:56] other products...miro..and the like [00:56] micahg: in the past we backported [00:56] patches [00:56] micahg: the upstream on all the mozilla based software are quite unsesitive about security [00:56] songbird also doesnt really track security releases in a real timeley fashion [00:57] even though you can use it just like a normal browser too [00:57] mozilla itself of course an exception [00:57] they take security quite serious [00:57] ;) [00:57] but they limit their exposure by EOLing in a timely manner [00:58] for me EOLing is not a valid tool to limit exposure ;) [00:58] well, it's a problem for distros [00:58] yes thats true [00:58] but imagine if they had to backport security fixes to all the earlier branches [00:58] and we had to live with that [00:58] i would love to not needing to backport anything [00:58] they would only be able to roll out a new version every 2 years [00:58] but i dont see that we are ready for that yet [00:59] i hope to get next LTS in a state where we can do major version upgrades [00:59] * micahg thinks we can get close for the non LTS releases [00:59] there are still too many rdepends [00:59] yeah, I ran that the other day [01:00] I was shocked [01:00] micahg: oyu have to look in the Sources files in the archive [01:00] only that way you can spot all biuld-rdepends etc. [01:00] oh, I wanted to ask you about the kde-firefox spec [01:00] rdepends is only a first pitch [01:00] there are 2 [01:00] ah [01:00] one is mine i guess [01:00] yes [01:00] those are reasonable things. someone need to find time to work on those i guess ;) [01:01] * micahg would like to try maybe [01:01] and first check if everything is still relevant [01:01] is that a bad idea? [01:01] i think its a touch task. but you never know in advance ;) [01:01] You created this: https://blueprints.edge.launchpad.net/ubuntu/+spec/firefox-kde-integration-intrepid [01:01] but definitly not a first code starter unless you are good at kde coding [01:01] another user created this: https://blueprints.edge.launchpad.net/ubuntu/+spec/firefox-kde-support [01:01] maybe parts of it [01:01] would hav eto heck [01:02] I was going to start at least linking bugs to the specs [01:02] yeah [01:02] if there are kde complains they definitly would fit [01:02] so, which one would you like me to link to [01:03] but i think the spec needs to be polished/updated [01:03] would minimal integration be ok as a first step? [01:03] or is it an all or nothing [01:03] the one that is a complete approved spec ;) [01:03] the gnome-support package just seems to provide gvfs, is that correct? [01:04] fta: thx. nm built ;) [01:04] and -applet maybe too ... but not so sure bout jaunty [01:05] file associations seem to be a big thing for the kde people [01:05] I was thinking, if I can make a settings file for KDE, could we package that and call it the beginning of firefox-kde-support? [01:07] your spec is more focused on using QT type stuff [01:07] the other one is just about defaults for KDE vs gnome [01:09] as you note in the spec, upstream has some interest in KDE support [01:09] so maybe we can keep things simple until they do it? [01:12] micahg: we have to do it in upstream suitable fashion [01:13] problem is that you cannot solve this on a packaging level [01:13] firefox needs runtime detection of kde/qt/gnome features as you can have kde and gnome installed on the same system [01:13] well, you can't solve the QT thing, but can't we have a KDE settings file that has KDE default apps set vs gnome apps? [01:14] i might not understand the concrete solution suggested [01:14] asac, \o/ [01:14] asac, did you get the emails? [01:15] fta: the build failures? i would think so [01:15] one sec [01:15] yes bunch of nm/modemmanager mails [01:15] good [01:15] oh, set firefox to open things in KDE apps without having to set it in the browser, but rather by installing a package [01:16] like bug 413337 [01:16] what file do they suggest to ship? mimeTypes.rdf? [01:16] Launchpad bug 413337 in firefox-3.5 "If Firefox is installed on Kubuntu is should set Akregator as default Feedreader" [Wishlist,Triaged] https://launchpad.net/bugs/413337 [01:16] this is my idea [01:16] ship something like that [01:16] as a simple kde-support pacakge [01:17] micahg: what's "default feedreader" in this context? iirc, the code gives the choice of live bookmarks/web options/local default [01:18] but I don't know how well the last bit works on Linux, since I don't have a current linux box [01:19] yes. that example looks different from what i thought this topic was about [01:19] i thought it was about changing mime-type handlers someone on kde [01:19] but this feed thing doesnt seem to suggest apps for me [01:19] asac: that was part of it [01:19] just webapps: bloglines, google, etc. [01:20] do you have an OS handler for feed: ? [01:20] for some reason, I thought choice of feed reader was a setting in firefox [01:20] let me check i think i saw liferea there too at some point [01:20] so its not a mimetype, but a url scheme handler [01:20] ok [01:20] hmm [01:21] ok, so, can't that be overriden with a config file [01:21] er [01:21] oh [01:21] I see [01:21] you want to do what? [01:21] http://www.grabup.com/uploads/cc0155deb95fc78c3c8584c4fb0f301b.png?direct [01:21] feeds are special [01:22] you could hardcode it to always use the system default, but that's kinda crappy [01:22] what if I don't want to use a local feed reader? [01:23] mconnor: this might have been a bad example [01:23] feed: handler is rhythmbox [01:23] ;) [01:23] making it work so that we properly detect the local default on KDE sounds great [01:23] I was originally thinking about mime type settings [01:23] but I knew where this bug was and didn't have a mime type bug to show [01:23] let's forget about this one for the moment [01:23] how about the mime type idea [01:23] I don't necessarily think we should ever hardcode any app [01:23] does that work? [01:24] mconnor: I"m not saying that we should [01:24] so, let's assume PDF [01:24] if I get application/pdf, right now I'll get open/save [01:24] and the default with open is whatever we get from whatever API call we use [01:24] right and in kde the default should be the kde app that opens pdfs [01:25] what you really want is to make sure that whatever API we call returns the default KDE has [01:25] I don't know what we call, it's been like four years since I've looked at this stuff [01:25] mconnor: mozilla bug 397700 [01:25] Mozilla bug 397700 in File Handling "Implement application selector (nsIMIMEInfo.possibleLocalHandlers) for Linux" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=397700 [01:26] it's a problem [01:26] problem is that that api call is not really one api, but a combination of reading the legacy mailcap stuff and then overloading that somehow with what we get from a gnome-vfs database [01:26] right [01:26] so [01:26] right solution is to have a kde-vfs thing and decide on _runtime_ which to use [01:26] based on the what desktop you are currently running [01:26] thats what my spec i wrote back then suggested [01:26] asac: indeed, but I don't know how to do that :) [01:27] yeah. but everything not-runtime will just cause confusion [01:27] is it better to wait for that than to offer a temporary solution and be upfront about what it does [01:27] because like now if you have gnome installed and log into kde you get applications that are gnome and your kde configuration tools dont work to change them on system [01:28] have I mentioned that KDE vs. GNOME is one of my biggest issues with Linux? [01:28] ah, I see [01:28] mconnor: you have a problem with choices? [01:28] if you now install like a kde-support package without having any runtime logic in place, you get the same problem on gnome [01:28] * micahg uses Xfce [01:28] true [01:28] micahg: I have a problem with unnecessary division of labour [01:28] micahg: choices are good, but for ISVs its a problem because it fragments a small market even further [01:28] mconnor: why is it unnecessary? [01:29] bot gnome and kde have moved to standardized libraries for most things [01:29] *both [01:29] why is it necessary? [01:29] people like QT vs GTK [01:29] sure [01:29] why is it necessary? [01:29] why not? [01:29] why should you care? [01:29] if people are willing to work on it [01:30] KDE is now cross-platform [01:30] if. [01:30] you can install it on Windows :) [01:30] that's entirely orthogonal [01:31] I can't write an app for Linux, I can write it for GTK or KDE or both [01:31] mconnor: either one is an app for linux [01:31] but it adds complexity and overhead to every ISV [01:31] i think this example about mime-types shows a bit why its a problem. its not simple to write an app on linux that works everywhere similar good [01:31] if someone likes your app, they'll probably install the required libs [01:31] micahg: but it doesn't work consistently [01:31] asac: there are standards that desktop environments are moving to [01:31] I can write a great GTK app, but it'll work differently from your KDE app, and usability suffers [01:32] micahg: like this. if you install the gnome-vfs stuff on kde you cannot configure the mime-types through kde. [01:32] freedesktop.org has been working on this [01:32] micahg: maybe that works at some point, but it didnt work for ages [01:32] very slowly [01:32] I think both gnome and kde are moving more towards standards [01:32] but now you're building two instead of one [01:33] it keeps them innovating [01:33] you can't stagnate [01:33] I think that's a hollow argument [01:33] competition is good [01:33] no it's not [01:34] I don't actually think I've seen anything out of Linux environments that's been really great/innovative in a very long time [01:34] and anyway, choices is what linux is about [01:34] name one great feature that users care about in either [01:34] You can run kmail on gnome if you install the libs [01:34] you can run xfce and mix and match your apps [01:34] or straight KDE [01:34] but you get to choose [01:34] or you can decide life's too short, and buy a Mac [01:35] yes, the Mac, where everything is coookie cutter [01:35] it works [01:35] and there's apps that are great [01:35] so does, Ubuntu, Kubuntu, Xubuntu [01:35] have you used a Mac for an extended period of time? [01:35] in the last two years? [01:35] no [01:35] * asac ... feels this is going down a dead end road. [01:36] yeah [01:36] I did back in the early 90s [01:36] ok [01:36] asac's right [01:36] let's get back on topic [01:36] the point where we started was about what is needed to do proper mime-type handling in kde [01:36] asac: seems more like an upstream project [01:36] i dont see the standadization coming. the freedesktop has agreed on a database standard, but there are no cross libs for that yet afaik [01:36] right [01:36] so we can either wait till that happens and then move firefox to that lib [01:37] really, at some point someone needs to do a real Qt port [01:37] so is it worth me trying to figure the KDE stuff out or helping gut 3.0 from Karmic? [01:37] but no one ever seems willing to maintain that [01:37] or we can have two system backends that you can install either or (or none) that is selected based on which desktop your current window is on [01:37] actually i think we dont need a qt port for now [01:37] if you use gtk with qt engine the looks is decent enouhg [01:38] yeah, but calling the right filepicker etc would be nice [01:38] what makes them bleed is the missing integration and that is - even though not a one day job - at least something oable [01:38] the qt port is being done i think for the mobile ... not sure if that is still driven by someone [01:38] I think vlad wrote a Qt port in a day, it just needed some love [01:38] but its not getting a full browser product soon afaik [01:39] right, because no one really wants to maintain it ;) [01:41] ok, asac, is there anything I can do to help with the karmic preparations [01:41] or is triaging bugs enough right now? [01:41] micahg: depends on what you want to do ;) [01:42] * micahg is willing to learn [01:42] micahg: there are still a bunch of open tasks on the firefox-3.5 by default karmic spec ... e.g. porting apps, also helping on getting old apps dropped from the archive, so we can remove the old xulrunner/firefox etc. [01:42] old apps? [01:42] its desktop-karmic-firefox-3.5 [01:42] yeah [01:42] I'm looking at it [01:43] yeah well. some apps are abandoned upstream and i dont want to port the app unless lots of people complain [01:43] so get that removed soon and see if they complain ;) [01:43] are they listed? [01:43] what do I have to do? [01:43] just ressearch the rdepends? [01:45] micahg: look on the spec whiteboard. there are a bunch of tasks [01:45] yes [01:45] desktop-karmic-firefox-3.5 [01:45] but I don't know what I have to do for them :) [01:45] micahg: so one thing i still need to do is to do a verify run of all those that are marked DONE [01:45] e.g. check if they really built on all arches, if someone filed a bad bug due to the transition or something [01:45] ok [01:45] how should we keep track? [01:45] if thats too lame for you you could check those that are flagged" maybe move to webkit" [01:46] nah, nothings too lame if it helps [01:46] micahg: track of what? [01:46] what I've checked [01:46] can I edit and mark verified? [01:46] good question [01:46] we produce burndown charts based on those tasks [01:47] so its probably not nice to just use a new word [01:47] i will tell you tomorrow. have to check with the one doing those charts. [01:47] maybe we can use VERIFIED1 VERIFIED2 etc. [01:47] ok, I was thinking DONE -- VERIFIED -- micahg [01:47] i also want to verify a bit later in cycle for a second time, because then we have beta users, that might catch more issues [01:47] something like that [01:47] ah [01:47] ok [01:47] micahg: shouldnt be a problem. i will let you know [01:47] ok, thanks [01:47] * micahg jsut wants to make this good [01:48] and help :) [01:48] asac: I also might have a new person to help me triage FF bugs [01:48] really? [01:48] then maybe I can focus on the backlog if someone can take care of the incoming [01:49] I started training him last night [01:49] maybe. [01:49] seems to have a good head [01:49] micahg: what do you mean with backlog? [01:49] all those bugs now open? [01:49] of bugs :) [01:49] 2000 over 3 packages [01:50] getting 3.0 out of karmic will help [01:50] indeed ;) [01:50] magic filter [01:50] so we have to finish getting 3.5 in before we can get 3.0 out? [01:51] micahg: in some way yes. [01:51] can we just remove the ff package now and leave xulrunner? [01:51] or is it too early? [05:53] asac, subpixel is acting up again. [09:13] olas [09:14] Jazzva, you there? [09:14] andv: yes [09:15] Jazzva, erroneously I removed myself from extension team (wanted to leave another team but i missed) [09:15] could you please re-add me? [09:16] andv: sure, just a second [09:16] thanks [09:17] andv: done :) [09:18] Jazzva, thanks a lot, and keep up the good work with bugmail-extension [09:18] ;) [09:18] andv: no problem. thanks, I'll try :) [09:19] do you any other extension you're working on? [09:19] * have [09:20] andv: I worked on couple of them in the past. They need to be upgraded, but I don't have time to do that at the moment. [09:20] package names? [09:21] andv: I suppose this way is easier :) https://edge.launchpad.net/~jazzva/+related-software [09:22] cool [09:22] a lot of packages [09:22] which aren't in debian I seee [09:23] I see a lot of -0ubuntu1 [09:27] andv: yes... I submitted one before (gnome-voice-control, but version 0.2 is not really useful, so I stopped working on that submission to Debian). Now that there's mozilla-devscripts in Debian, it would be good to move extensions there. [09:27] yep [09:28] if you have any package you may want to move there [09:28] just ping me [09:28] but I haven't done anything related to that before (which is not good, I know :)) [09:28] and give me a working branch [09:28] andv: well, I'll be able to work on that after my exams (which are on 23rd and 24th August) [09:28] great [09:28] let me know if you need help [09:29] andv: I will need it :). At least with differences in policies between Debian and Ubuntu [09:29] yeah [09:29] don't worry I'll help you [09:30] andv: Thanks :)... That would be great [09:30] ;) [10:04] hmm ... my other irssi cannot connect to freenode atm [10:16] heya asac [10:17] some network issues for freenode [10:18] really? [10:18] yep [10:18] thats interesting [10:18] why can i cannot from this system then ;) [10:19] dunno [10:19] I started lagging before [10:19] i can connect [10:19] then I got kicked out from the server [10:19] hmm- [10:19] and you got kicked as well [10:19] my other system resolves irc.ubuntu.com and irc.freenode.com to an IP that doesnt work [10:19] yeah [10:19] irc.freenode.net [10:19] ok lets assume thats normal then ;) [10:20] I connected using irc.ubuntu.com before [10:20] after the kick and it worked fine [10:20] yeah i used that too [10:20] doesnt matter [10:20] on my irc gateway both dont work [10:20] but when using this system directly it works ;) [10:20] important is that it works [10:21] somewhere [10:21] yeah ... but that was just a matter of luck i guess [10:21] yep [10:21] im finishing working on all in one for debian [10:22] fta: is 3.6 still called minefield in the menu? thought we are at Namoroka [10:23] just have to remove an extra license file [10:23] and I start test-building [10:26] andv: use the ne xpi.mk feature to remove the extra license [10:26] how does that work? [10:27] http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/revision/230 [10:27] we will upload 0.15 soon. so just depend on 0.15~ [10:28] the idea is that you add license files that are in the produced xpi after checking that you properly documented them in debian/copyright [10:28] asac, If I add >=0.15 it won't work [10:28] e.g i won't be able to do test builds [10:30] asac, in fact the extra license file is the MPL license one [10:30] which get installed already [10:30] thanks to the docs maintainer script === ripps_ is now known as ripps [10:31] ./usr/share/doc/all-in-one-sidebar/MPL.gz [10:31] the extra license file gets installed here: /usr/share/all-in-one-sidebar/license.txt [10:31] doesnt matter [10:32] if its documented properly in copyright you are supposed that feature [10:32] so it doesnt get duplicated in the produced xpi-tree [10:32] * asac gets mail etc. bbl [10:33] asac, check my mail too [10:33] ;) [10:33] anyway ok gonna use that feature [10:33] which is MOZ_XPI_DOCUMENTED_LICENSE_FILES (OPTIONAL): [10:33] I guess [10:42] yes [10:50] asac, I've added this line: MOZ_XPI_DOCUMENTED_LICENSE_FILES: license.txt [10:50] but seems to not work [10:50] I've tried using the TEMPDIR variable as well [10:50] but nothing [10:51] bzr bd doesnt even produce an output about it [10:51] andv: thats because you dont have the latest mozilla-devscripts most likely [10:51] andv: bzr branch lp:mozilla-devscripts [10:51] debuild that and install [10:51] remember to use minimum build depends of >= 0.15~ [10:51] ok, let me see [10:56] asac, nothing again [10:56] I've installed latest mozilla-devscripts [10:56] bumped them on control file [10:56] and built again [10:56] but that extra license file didnt go away [10:57] andv: you should use MOZ_XPI_DOCUMENTED_LICENSE_FILES := license.txt [10:57] thanks [10:57] let me try [11:01] bdrung, thanks [11:01] it worked out [11:01] andv: yw [11:02] bdrung, you should specify that in MOZ_XPI_DOCUMENTED_LICENSE_FILES documentation [11:02] e.g adding some usage cases [11:03] example on how you can use this feature: MOZ_XPI_DOCUMENTED_LICENSE_FILES := foo.txt [11:03] or whatever [11:03] andv: an example should be sufficient. using := or = is the normal way to declare variables in makefiles [11:03] yes, I know [11:03] asac: is there an example for using xpi.mk? [11:03] the only thing I see is MOZ_XPI_DOCUMENTED_LICENSE_FILES (OPTIONAL): [11:04] which can get you doing it wrong [11:06] # Usage: include this file in your cdbs debian/rules file and define the [11:06] # following variables: [11:07] didnt see it [11:13] andv: look at the README, there is a link to https://code.launchpad.net/~mozillateam/firefox-extensions/XPI.TEMPLATE [11:20] bdrung, thanks [11:20] didnt see those [11:20] the template is not up-to-date [13:02] andv: I see that you used MOZ_XPI_DOCUMENTED_LICENSE_FILES that I asked about yesterday. :) Should I test with the bzr version of mozilla-devscripts or wait until it's released? [13:47] andv: yeah, example should go to XPI.TEMPLATE/debian/rules, as all other examples (regular packager shouldn't bother to look into xpi.mk for explanations, though it might be needed sometimes :)). asac, do you agree? [13:48] sveinung: andv tested already (if I read correctly). With mozilla-devscripts ver. <0.15 MOZ_XPI_DOC_LIC_FILES will do nothing, but the build won't fail. With ver. >=0.15 it will exclude those files when packing a XPI. [13:52] sveinung, hi [13:53] sveinung, do bzr branch lp:mozilla-devscripts [13:53] andv: hi [13:53] then bzr bd it [13:53] and install it [13:53] andv: I have already buildt it [13:53] great [13:54] as Jazzva already said you [13:54] the build won't fail with 0.14 [13:54] but that variable won't work [13:54] asac told me he will upload 0.15 soon [13:54] yes [13:54] perfect [13:54] sveinung, test the package on squeeze please [13:55] ok [13:55] Jazzva, yeah, wasnt able to find a good example [13:56] to follow before [13:56] that's why I asked [13:56] ;) [13:56] do we have ${xpi:Depends} now for Depends field? I think I saw someone worked on that in xpi.mk [13:56] andv: I'll update XPI.TEMPLATE now, so it will be better :) [13:56] perfect thanks [13:56] no prob :) [13:57] sveinung, if the package works fine on squeeze [13:58] we just gonna have to wait mozilla-devscript 0.15 [13:58] and the package is ready for upload [13:59] Jazzva: yes, we have it in 0.14 [14:00] bdrung: great, I'll put that in XPI.TEMPLATE :) === kenvandif is now known as kenvandine [14:00] Jazzva: and MOZ_EXTENSION_PKG is now optional [14:01] bdrung: ok, I'll be sure to document that in debian/rules in template :) [14:01] thanks [14:02] bdrung: thank you for implementing that :) [14:02] Jazzva: that was a simple one liner [14:02] andv: works fine [14:03] sveinung, perfect [14:03] sveinung, can you please do a lintian run [14:03] to the package generated [14:03] sure [14:10] andv: strange. I still get the extra license warining... (I compiled and installed mozilla-devscripts again just to be sure) [14:11] really? [14:11] let me see [14:11] trying again just to be certain... [14:11] yeah, me too now [14:12] what went wrong [14:12] let me see [14:12] andv: check if the variable is assigned correctly. [14:12] Jazzva, worked locally before [14:12] jazzva: MOZ_XPI_DOCUMENTED_LICENSE_FILES := license.txt [14:12] then I pushed and stopped working [14:13] that's weird... [14:13] Jazzva, it's the same as before [14:14] but worked for me [14:14] Now running lintian... [14:14] W: all-in-one-sidebar source: newer-standards-version 3.8.3 (current is 3.8.2) [14:14] Finished running lintian. [14:14] hmm, so it's working? [14:14] not anymore [14:14] since I pushed it and modified rules again [14:14] andv: where is the branch for the extension? [14:14] http://bazaar.launchpad.net/~mozilla-extensions-dev/firefox-extensions/all-in-one-sidebar.ubuntu/annotate/head%3A/debian/rules [14:17] seems like the unzip command don't exclude the file... [14:17] Jazzva, found the problem [14:17] Jazzva, I've moved includes to the top [14:17] andv: what was it? :) [14:17] ah... [14:17] and it stopped working [14:18] I moved them again [14:18] and now it works [14:18] this is really really strane [14:18] * strange [14:18] anyway [14:18] andv: that sounds logical :) [14:18] Jazzva, usually includes are on top [14:18] of the file [14:18] sveinung, give me a second [14:18] sveinung, I push fixed change [14:19] and then you can test again [14:21] andv: I don't really know how they work for build files, but I suppose it includes them where the include line is. So, I suppose it included them on the top, leaving the assignments below, so those assignments were never reached (since they were below the actual build script). [14:21] Jazzva, yeah [14:21] that might be the right view [14:24] sveinung, branch now [14:24] and build again [14:24] the includes usually come after the top level defines [14:24] asac, yep [14:24] asac, I noticed it [14:25] fix pushed already [14:25] sveinung, build and lintian it again [14:25] debian/control: bumped debhelper to level 7 plus Standards- [14:25] thats not needed [14:26] its wrong to bump build depends if not required [14:26] asac: can I push updated XPI.TEMPLATE to mozillateam directly, or would you like to review it first? [14:26] Jazzva: go ahead. [14:27] asac, in debian it's needed [14:27] asac, the package must follow all the corrent standards [14:27] it's not needed to bump them in ubuntu [14:27] but it is in debian [14:28] and anyway in this case it has been a no change with no consequent changes [14:28] e.g the bump didnt require any other change [14:28] as may happen [14:29] andv: work, the lintian warning is gone [14:29] perfect [14:29] package ready then [14:29] if you tested it correctly it's ready [14:30] I've tested it in IceWeasel [14:30] asac, why do i now receive bug mails for libcanberra? [14:30] asac, "You received this bug notification because you are a member of Network-manager, which is subscribed to NetworkManager." [14:31] sveinung, could you try it on firefox too? [14:32] andv: Debian calls Firefox Iceweasel. Do you mean in Ubuntu? [14:32] yep [14:32] I already know you tested it on debian [14:32] this package gonna be synced in ubuntu [14:33] so it's nice to give him a try on firefox as well [14:33] fta: good question [14:34] let me look [14:34] andv: sure. Unplugging me net connection here and transferring it to my Ubunut machine [14:34] fta: maybe its NM bugmail? [14:34] sveinung, perfect [14:34] hmm the team isnt subscribed [14:35] fta: maybe nm team was explicitly added to that bug? [14:35] which id is that? [14:35] asac, any news from the bindwood team' [14:36] asac, the package looked fine but the control file was the same as another mozilla package [14:36] with random depends [14:36] we make a switch to ICU 4.2.1 [14:37] if you need a review for that [14:37] yes that needs to be cleaned up. imo we should could just do the packaging from scratch [14:37] based on lp:bindwood [14:37] using mozilla-devscripts that should be easy enough [14:37] statik: there? [14:37] Jazzva: you should change mozilla-devscripts (>= 0.14) to mozilla-devscripts (>= 0.14~) [14:37] asac, bug 146918 [14:37] statik: re bindwood. andv spotted a few depends that appear to have been copied from ubufox [14:37] Launchpad bug 146918 in hundredpapercuts "Poor descriptions for some applications in Startup Programs window" [Medium,In progress] https://launchpad.net/bugs/146918 [14:38] hi asac [14:38] i thought i vetted the depends pretty good, but maybe i missed some. whic ones looked wrong? [14:39] bdrung: why? the current version is 0.14. [14:39] statik: apturl (>= 0.1.2ubuntu1), [14:39] (in the archives) [14:39] remove that one i guess [14:39] yep apturl (>= 0.1.2ubuntu1), [14:39] let me review the rest of the package [14:39] Jazzva: it should work with backported versions, too [14:40] bdrung: ah, ok :) [14:40] statik: ok add license boilerplate to dbus.sh [14:40] Jazzva: like 0.14~jaunty1 or 0.14~ppa1 [14:40] asac, great, i'm changing it now [14:40] Jazzva: 0.14~ > 0.13 [14:40] statik: do that in upstream tree ;) (or is that dbus.sh part of ubuntu branch only) [14:41] statik: also open a "needs-packaging" bug for bindwood, so we have a tracker bug for the first upload [14:41] asac, i'm dropping apturl in the ubuntu packaging branch, and adding the licensing goo in the upstream tree and then updating .bzr-builddeb to have the right base revision [14:42] bdrung: thanks. pushing now [14:42] asac, we have 408758 for needs packaging, but I should make it also-affects ubuntu I guess [14:42] statik: yes. add "ubuntu" to it. and close it in the changelog of ubuntu [14:43] yessir, the changelog already points to it :) [14:44] statik: one suggestion: http://pastebin.com/f74eecdf8 [14:45] fta: i guess someone subscribed nm team for the papercut thing [14:45] let me check and unsubscribe [14:45] fta: dont see why we get that bugmail [14:46] asac, thanks! will apply that patch to the upstream branch as well [14:46] statik: good. remember to merge that in then, update .bzr-builddeb/default.conf and make a single release commit to close the changelog. i will upload it then [14:47] statik: release commit is: dch -r -Dkarmic; debcommit -r [14:47] asac, right now i only have one changelog entry since it's never been released, is that ok? [14:47] statik: oh you can also use ${xpi:Depends} instead of firefox-3.5/3.0 [14:47] asac, oh nice, i'll change that [14:47] if you want to use mozilla-devscripts >= 0.14 (in karmic) [14:47] andv: tested on Jaunty with Firefox 3.5 (that will be default in Karmic) from Universe. Works [14:48] statik: that only works in karmic. if you want to provide backports in a ppa you can just upload the latest mozilla-devscripts there too [14:48] statik: let me know. i think we are ready for upload then ;) [14:48] sorry that it took me a while to look at this. [14:49] sveinung_, great :) [14:49] we're ok then [14:49] asac, no worries. thanks for your excellent help and coaching. i'll get this all done in the next 15 minutes or so and ping you when i've pushed the branches [14:49] statik: are we sure that it doesnt work with ffox 3.0, 3.6? [14:49] otherwise tweak the install.rdf accordingly [14:50] statik: great. just let me know. we can check the max/min version after the upload [14:50] asac, i'm sure it doesn't work with 3.0, 3.6 i'd hope it would still work with [14:50] is the current standards-version 3.8.2 or 3.8.3? [14:51] statik: 3.8.3 [14:51] bdrung, thanks! [14:51] just release some days ago === sveinung__ is now known as sveinung [14:51] so thats ok to use in karmic packages then? [14:52] yes. should be fine [15:24] asac, just to be sure: when you say to do a single release commit, you want the merges and other packaging changes to be committed first, then the debcommit -r? [15:28] statik: yes [15:29] statik: just do a dch -r + debcommit -r after the final merge (after verifying your packages are good et al) [15:29] so basically thats a "sign off commit" ;) [15:32] hmm.. i have a native x64 build of chromium, but it fails with the sandbox, works quite fine without it [15:32] so it's getting close, but it's not for today [15:33] fta: nice [15:49] it's failing in syscall(__NR_clone, CLONE_NEWPID | SIGCHLD, 0, 0, 0) [15:49] operation not permitted [15:49] hmm [17:13] asac, \( -name \*.la -o -name \*.a \) [17:14] asac, and the LOCAL_BRANCH seems to be broken [18:11] fta: i except just a dir to be passed to LOCAL_BRANCH ... i ran it a few times, also uncommitted stuff there to see how it updates etc [18:12] expect [18:13] the LOCAL_BRANCH dir is the dir on top of the actual checkout branch. thats easier didnt expect it to be a problem [18:13] let me check if i can see someting in the mail you send [18:14] and yes. i can make it one find [18:15] hmm. the log i got by mail looks ok for network-manager LOCAL_BRANCH [18:15] -applet looks good too [18:15] same for mm [18:15] whats the problem? [18:16] * asac checks build failures [18:16] looks good too [18:17] hmm. nm wasnt uploaded [18:17] * asac checks mail again [18:18] guess nm didnt get any new commits [18:21] asac, why does it say "Initialized empty Git repository in /tmp/tmp.mK7TBYzkn8/NetworkManager/.git/" [18:22] (and you should not use /tmp, a repo could be big, and /tmp may be short) [18:22] asac, and could you make the cloning less verbose, the updated files are already listed during the 1st step [18:23] fta: i clone it for real because thats the safest way to export a certain git id [18:23] i use mktemp -t [18:24] and afaik i remove it in the end [18:24] i can remove verbosity. yeah [18:24] just for the clone, the 1st update is fine [18:24] the git archive feature produced orig.tar.gz that were not bzr-builddeb friendly for me at some point [18:25] fta: the second clone is used to checkout the revision id i want [18:25] i dont think its good idea to do that in the LOCAL_BRANCH [18:25] hm, it seems it shows all the files [18:25] let me check the log again so i see what we are talking about [18:26] for hg, i just clone in the upstream dir, cp -al to a temp dir, then checkout the copy with my rev id or tag [18:27] fta: upstream dir == LOCAL_BRANCH/dir ? [18:27] yes [18:27] http://paste.ubuntu.com/255256/ -> thats the update of the local branch [18:27] fta: yeah. so the only difference is that i use clone instead of cp -al [18:27] which should be the same (or even less if there are local branches in the LOCAL_BRANCH) [18:28] cp -l is usually very fast, it uses hard links [18:28] http://paste.ubuntu.com/255257/ -> thats the clone/cp + checkout [18:28] not sure if it's reasonable with git [18:28] fta: i think hard links could be a problem. one could just copy the .git directory though [18:29] but imo it should be fine like it is. i will remove the verbose output [18:29] ok [18:29] thats not needed (maybe just print how many files got pulled) [18:29] great [18:29] fta: so the network-manager.git got new files, but there was no upload [18:30] http://paste.ubuntu.com/255256/ [18:30] thats the updates we got in LOCAL_BRANCH [18:32] hm, according to the email, it has been pushed. didn't you get a reject? [18:32] or an accept? [18:34] network-manager_0.8~a~git.20090817t192429.80d4883-0ubuntu1~nmt1.dsc: Version older than that in the archive. 0.8~a~git.20090817t192429.80d4883-0ubuntu1~nmt1 <= [18:34] +0.8~a~git.20090817t203502.3e22183-0ubuntu1~nmt2 [18:34] did you trash your .daily branch? [18:35] or is it a bug in the build bot? [18:35] hmm [18:35] date screwed? [18:35] odd [18:35] let me check [18:35] there are two dates ... thought i took the right one [18:36] HEAD^^^ - http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a8ca7f537d0cdbba972a86ae8ddcecdae30ac8d1 [18:36] HEAD^^ - http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=80d48837ce15da8826f5d21ec909feca0f16273d [18:36] HEAD^ - http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b62702d33754e5444447535b3d4b475cb56fd944 [18:36] ? [18:37] asac: thunderbied 2.0.23 is using 1.8GB resident memory [18:37] look at HEAD^^^ (yesterday) vs. HEAD^ [18:37] (today) [18:37] both times are lower than the second time of the first [18:37] feels like the git server doesnt bump date if it gets above 0.00 [18:37] dan commits with UTC-5 or something [18:38] and i know that he did the last commit _after_ he first commit [18:38] and both times match, except that the first commit was on 17th [18:38] hmm. actually its ok [18:39] so scratch what i said [18:39] i looked in wrong order [18:39] i think the second commit is the problem [18:39] you have dates in GMT there [18:39] that's good enough [18:39] yes [18:39] take the date from the branch, not from the committer [18:39] but [18:39] 0.8~a~git.20090817t192429.80d4883-0ubuntu1~nmt1 <= [18:39] 19:34 < asac> +0.8~a~git.20090817t203502.3e22183-0ubuntu1~nmt2 [18:39] sure ... but those dates dont even match [18:40] with what i see on gitweb [18:40] well the first matches [18:40] nevermind [18:40] i have to find how i can parse the right time [18:40] i am sure thats it [18:40] from the rss feed maybe [18:41] just get the hash from the tip of the rss, and chekout that hash [18:41] +out [18:41] ugh, asac, is there anything I can do to diagnose why TB 2.0.0.23 is eating up all my RAM? [18:42] fta: found it [18:42] have to use --pretty=fuller ;) [18:43] then there is CommitDate: [18:43] micahg: regression? [18:43] that's my guess [18:43] wanted to ask if there was anything to do before I restart it [18:43] dont think so [18:43] asac, in another project, i used REV=`git log --pretty=format:%cd~%h --date=short -1 | tr -d -` [18:44] yeah. fuller is ok ;) [18:44] the rest works well [18:44] its just that git log alone only shows the original date [18:48] asac: I'm gonna restart TB if there's no troubleshooting I can do [18:50] micahg: unfortunately nothing afaik. check the error console [18:50] maybe you see some odd errors there [18:51] can I tap into the error console if I started it from the menu? [18:52] micahg: tap? [18:52] you can open it there ... it should show errors that came up before too [18:52] tools -> error console [18:52] also you can check $HOME/.xsession-errors ... which is the file where stderr from programs from the menu to got [18:52] * micahg thought you meant shell errors :) [18:53] to [18:53] yeah thats xsession-errors [18:54] asac, so i think I've got all the changes you asked for except the final release commit here: bzr+ssh://bazaar.launchpad.net/~ubuntuone-control-tower/bindwood/ubuntu/ but, the orig.tar.gz that is being built is not correct. i'm scratching my head looking at bzr builddeb and not seeing why its not working - i've updated .bzr-builddeb/default.conf to point to the revid of the correct upstream branch commit [18:54] nothing in xsession-errors from 8/13 on... [18:54] let me check [18:55] statik: so your merge should show up if you do bzr log --include-merges --show-ids [18:56] asac, yep I see it listed as a parent [18:56] elliot@elliotmurphy.com-20090818141730-pwjbun1liosscsyg [18:56] thats the id i would pick [18:57] let me compare that with default.conf [18:57] yes, thats what i've got in default.conf [18:57] maybe i made a typo in default.conf or something - i cut n pasted the revid though [18:58] statik: works for me === rickspencer3 is now known as rickspencer3-afk [18:58] what doesnt work for you? [18:58] asac, leaving for two days, sea waiting me [18:58] have fun in the meantime!! :) [18:59] asac, when i do bzr bd --builder="debuild -S -sa", and then look at the orig.tar.gz it's missing the COPYING files and some other stuff, and the diff.gz has too much in it [18:59] statik: http://paste.ubuntu.com/255276/ [18:59] hmm [18:59] let me check the diff.gz [18:59] that one looks correct [18:59] or more correct than what i'm getting anyway [18:59] i was beginning to think i'd lost my mind [19:00] statik: so the problem is that you didnt bump the upstream version [19:00] statik: meaning: your previous version was 0.1 ... the current one is 0.1 too [19:00] you shouldnt use 0.1 unless its a tagged 0.1 release [19:00] if you build packages from bzr i would suggest to use [19:00] 0.1~bzr.REVISIONNO [19:00] if you are moving towards 0.1 [19:00] if you are past 0.1 use [19:00] 0.1+bzr.REVISIONNO [19:01] you have to change the upstream version in the bzr merge [19:01] that sounds promising! which version is this? [19:01] in the install.rdf? [19:01] statik: it should somehow match what is in installr.df [19:02] so if oyu have 0.1b1 you would use 0.1~b1 [19:02] i'm not sure which version number I should have incremented, considering that this hasn't ever been released yet [19:02] statik: right. so ... assuming you dont want to do a full release now. set the version in install.rdf. to 0.1pre [19:02] and then we use 0.1~pre.bzrREVISION for the debian changelog [19:03] at some point you release 0.1 [19:03] and then you change to 0.1 in install.rdf [19:03] tag that in your upstream branch [19:03] and then we do a "merge release 0.1" [19:03] to ubuntu branch [19:03] statik: alternatively we could say that you release 0.1 _now_ [19:04] but you also have to consider that you already had tarballs with 0.1.orig.tar.gz out in ppas [19:04] so we need to move ahead i [19:04] so lets do this: [19:04] asac, aha, now I see. what if we do 0.2pre or something? [19:04] you use 0.2pre in [19:04] install.rdf [19:05] and merge it as a 0.2~pre.bzrREV [19:05] yeah [19:05] so I'd set the version in the changelog to 0.2~pre.bzrREV ? [19:06] statik: actually i think we should just use 0.2~bzrREV [19:06] asac, i like that fine [19:06] statik: the project looks small enough that you probably dont want to do real alpha/betas [19:06] so we dont need to keep the namespace for that [19:06] asac, so should install.rdf be set to 0.2 or 0.2pre in that case? [19:06] to be safe you can use 0.2~~bzrREV [19:06] that will allow you to do a alpha1 like 0.2~a1 [19:07] or even pre alpha1 snapshots lke [19:07] 0.2~a1~bzrREV [19:07] oh wow, i didn't know you could use two ~ like that [19:07] or post alpha1 snapshots ;) [19:07] 0.2~a1+bzrREV [19:07] cool [19:07] i need to talk to you more, i learn a lot this way [19:07] statik: yeah. i usually use that if i am not sure if there will be an alpha beta at some point [19:07] but if i know that we are moving towards some version ;) [19:08] statik: one second [19:08] right. so just to be sure, i should set install.rdf to 0.2 in upstream? [19:08] we might need to delimit bzr.REV [19:08] because if we go four digits we need the alpha comparision that is only done if things can be split [19:08] * asac does trial and error with dpkg --compare-versions [19:09] statik: set it to 0.2pre [19:09] we use 0.2 in install.rdf only for the real 0.2 release [19:10] statik: ok seems we dont need to delimit it with . [19:10] so just bzrXXX or bzr.XXX ... wqhatever you prefer [19:10] statik: if you want to keep it open to do a alpha at some point you probably need to use 0.2a1pre [19:11] but i think bindwood does not need that ;) [19:11] we do snapshots as betas ;) [19:11] i agree [19:15] asac, so in the changelog i do bindwood (0.2~bzrREV-0ubuntu1) ? [19:23] asac, so I agree that we needed to change the revision number but the orig.tar.gz that is being generated here is still wrong for me, I see all kinds of stuff in the diff.gz that should not be there [19:29] statik: yes. use that version number [19:29] statik: it should work [19:30] just try it ... be sure oyu have no orig.tar.gz with that version anywhere in builds/ or tarballs/ directory [19:30] the diff.gz i produced for the 0.1 we had has only debian/ in it [19:34] asac, yeah this is really odd. I've made sure everything is removed from ../build-area and .. [19:35] but still the orig.tar.gz is wrong. huh, I get an orig.tar.gz in .. and another one in ../build-area [19:35] i'm using the bzr-builddeb plugin in karmic [19:35] rather than from source [19:39] well, i've pushed up the latest branch to bzr+ssh://bazaar.launchpad.net/~ubuntuone-control-tower/bindwood/ubuntu/ i have to go for now to pick up my kid from school === jdstrand_ is now known as jdstrand [20:24] damn pdebuild, it's not using fakeroot by default [20:31] * asac grumbles about bzr-bd [20:31] i have .bzr-builddeb/default.conf with explicit export-upstream and export-upstrema-revision [20:32] and it still thinks its smarter and now just exports "revision 9" [20:32] because there is bzr9 in the upstream version [20:32] what a mess [20:33] bzr blame debian/rules [20:33] oops [20:33] grrr [20:35] unnecessary USE_SYSTEM_* changes [20:36] me? [20:36] no [20:36] well [20:36] good [20:36] at last [20:36] you sponsored it, but nm [20:44] asac: ah, so bzr bd is ignoring the export-upstream-revision command? [20:44] er, setting === rickspencer3-afk is now known as rickspencer3 [20:55] statik: worked around it ... pushed the branch to the ~ubuntu-dev location (see bug) [20:55] asac, http://paste.ubuntu.com/255336/ [20:55] statik: for future uploads just start from that branch state [20:55] thanks [20:55] i will upload that now [20:56] i wonder why it worked for years in xul&ff [20:56] statik: also fixed the changelog a bit for you and the revid: ... but that wasnt the problem. it was really bzr [20:57] fta: configure.in has a safety net that mozilla sometimes forget [20:57] so if it didnt work it might have been that [20:58] asac: thanks! [20:58] asac, nm, $$ [21:00] fta@ix:~$ pkg-config --atleast-version=9.6.1 sqlite3 && echo 1 || echo 0 [21:00] 0 [21:00] fta@ix:~$ pkg-config --atleast-version=1.6.1 sqlite3 && echo 1 || echo 0 [21:00] 1 [21:00] that's what i need [21:00] fta: thats what bdrung suggested [21:00] no, i need 1 or 0, not 1 or undef [21:01] fta: pkg-config "nspr < 4.3" && echo yes [21:01] fta: pkg-config "nspr > 4.3" && echo yes [21:01] works for me [21:02] same for <= and >= [21:02] and i know it really fixed things for gnomefreak ;) [21:02] yep, it's still yes or undef [21:02] exists is wrong [21:02] fta: what do you mean? [21:02] yes its undef [21:02] but you are only interested in yes [21:02] no, it's not for xul [21:03] http://paste.ubuntu.com/255345/ [21:03] fta: --exists works too [21:03] pkg-config --exists "nspr <= 4.3" && echo hallo [21:03] pkg-config --exists "nspr >= 4.3" && echo hallo [21:03] [21:58] asac, nm, $$ [21:03] you have duped pkg-config [21:04] ah [21:04] ;) [21:04] ok [21:04] you dont need the --at-least-version imo [21:04] but doesnt matter [21:04] (shell pkg-config pkg-config --atlea [21:04] ^^^ [21:04] duped [21:09] yep, fixed it already [21:10] it was a bzr diff | pastebin, not committed yet [21:11] sure [21:17] asac, http://paste.ubuntu.com/255360/ \o/ [21:18] fta: very nice. [21:18] well done [21:18] still crashy? [21:19] no. i will do a final build with the remaining system libs before updating the ppa [21:19] good. not somewhere with 64-bit anyway atm [21:19] oh asac, do you have an answer for what I should add to the blueprint for verification? [21:19] fta: tar.bz2 size would be? [21:21] ~93 MB [21:22] working closely with upstream really pays off [21:24] tar.bz2? [21:24] or lzma in orig? [21:25] lzma [21:29] hm, strange [21:31] fta@voyager:/usr/lib/chromium-browser/plugins $ sudo ln -s /usr/lib/xulrunner-addons/plugins/flashplugin-alternative.so [21:31] fta@voyager:/usr/lib/chromium-browser/plugins $ cd [21:31] fta@voyager:~ $ chromium-browser [21:31] Gtk-Message: Failed to load module "canberra-gtk-module": /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: wrong ELF class: ELFCLASS64 [21:31] ALSA lib ../../src/conf.c:2700:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so [21:31] ALSA lib ../../../src/pcm/pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default [21:31] asac, ^^ [21:32] that's on amd64, with nsp [21:40] -rw-r--r-- 1 fta fta 117253067 2009-08-18 17:07 chromium-browser-4.0.202.0~svn20090818r23607-source.tar.bz2 [21:40] -rw-r--r-- 1 fta fta 96632694 2009-08-18 17:07 chromium-browser-4.0.202.0~svn20090818r23607-source.tar.lzma [21:40] asac, ^^ [21:42] good [21:42] do you know if new icu will reduce patchset? [21:42] e.g. found out that they look into updating it to 4.3.. or something like that [21:51] asac, http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/README.google [21:55] micahg: so yes. use VERIFIED1 for this round [21:55] ok [21:55] thanks [21:55] now, for the packages I can just check the karmic section of the package in LP? [22:18] micahg: unlikely [22:18] micahg: only those that are approved show up there [22:18] so you wont see bugs done by normal users [22:18] of course if a package has a karmic section bug that means we should look closer before verifying [22:18] as that is considered relesae critical [22:43] sorry, I meant the overview section, not the bugs section [22:43] but I will check the bugs section as well [22:56] i still have to build a small libzlib.a, because of the unzip thing [22:56] asac, ^^ [23:03] fta: you have to or you want to? [23:03] better make a so out of it [23:04] have to [23:04] ar t build-tree/src/sconsbuild/Release/lib/libzlib.a [23:04] ioapi.o [23:04] unzip.o [23:04] zip.o [23:08] why not make a .so out of that? [23:10] it's a static build [23:11] http://paste.ubuntu.com/255411/ [23:12] asac, ^^, of course, i don't ship any of those === asac_ is now known as asac [23:14] yes [23:14] micahg: do you need anything? [23:15] I think I'm good, but do youhave time to look at an strace? [23:18] micahg: bug id? [23:19] bug 368966 [23:19] Launchpad bug 368966 in firefox-3.0 "address bar completion gone after screensaver" [Undecided,Incomplete] https://launchpad.net/bugs/368966 [23:21] micahg: it needs to be strace -f ;) [23:21] anyway. i dont think that its anything we can see in strace [23:22] ah [23:22] can you tell me when strace -f vs strace -eopen is appropriate? [23:22] or should it always be -f -eopen? [23:22] micahg: no. its always strace -f -eopen ;) [23:22] yeah [23:22] ah [23:23] that could be why i've missed things :) [23:23] in some cases getting more is required ... then dropping -e is good or extending it by the syscalls we want to see [23:23] (like stat or something) [23:23] micahg: problem is that firefox forks away [23:23] without -f you will only see files that get opened before it forks itself [23:24] which is why my TB strace was showing nothing :) [23:28] yes. its important to know ;) [23:28] guess you will remember now [23:28] :-P [23:28] micahg: can you reproduce the focus issue? [23:28] no [23:28] does it help if you explicitly click in the location bar first? [23:28] hmm [23:28] * micahg will remember now [23:29] le tme check [23:29] the step instruction is not clear [23:29] is the location bar empty when locking? [23:29] he doesnt say that he clears the field [23:29] ah ok its all selected [23:30] aftter hitting esc twice [23:30] seems to work fine [23:31] the report says you have to keep it locked for a few minutes [23:31] seems to work fine for me [23:31] ok [23:31] i think i cannot lock my screen ;) ... it will ghost my X :) [23:32] should I apologize and ask for a strace -f -eopen? [23:32] i dont think it will be useful here [23:32] ok [23:32] we should first verify if its reproducible at least [23:32] ok [23:32] I'll try it now [23:32] because they gave quite detailed instructions. if its a problem we need to forward and triage it upstream [23:34] hitting escape for me brings back the current URL [23:35] so, I've been asking for an strace if I don't think it's a profile issue, but might be a system issue, is that correct? [23:42] asac: just tested [23:42] seems fine [23:48] hello