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