[00:02] <lifeless> ok, no poolie yet
[00:02] <lifeless> spiv: stand hup ?
[00:02] <spiv> lifeless: sure
[00:02] <spiv> skype or pots is fine.
[00:03] <lifeless> you and I can skype, and I'll skype out to get poolie
[00:13] <Odd_Bloke> Why do Canonical use Skype rather than a free VoiP solution?
[00:13] <Odd_Bloke> Or is it just the case that everyone in Canonical uses Skype, without there being any sort of policy?
[00:14] <lifeless> skype works
[00:14] <lifeless> we have an asterix server
[00:28] <jml> hi
[00:28] <jml> (again)
[00:29] <jml> I'd like to get the stacked-on url for a branch without opening a branch.
[00:30] <jml> I'm guess I should open the bzrdir for the url and do something from there?
[00:32] <Verterok> jelmer: I can't upload to bzr-svn, maybe need to be in the bzr-svn team?
[00:33] <Verterok> jelmer: anyway, I uploaded both dmg's to: http://verterok.com.ar/bzr-svn
[00:34]  * jml experiments
[00:34] <jelmer> Verterok, you should now be in the team
[00:35] <spiv> vila: great work on finding and fixing the pycurl select/poll bug.
[00:35] <Verterok> jelmer: ok, uploading to launchpad :)
[00:40] <jelmer> Verterok, thanks!
[00:43] <Verterok> jelmer: np, now I need figure out hot to include both versions in the bzr dmg
[02:17] <rocky> what is the typical way to control read/write access with bzr smart server?  perhaps proxy it with apache and use htpasswd based auth ?
[02:21] <jearl> rocky: it depends on what you want to do.
[02:24] <jearl> rocky: I think typically people use bzr+ssh if they have complicated requirements for who can read and write.
[02:24] <rocky> i'm thinking more about replacing a svn+apache+dav setup
[02:31] <rocky> is there more involved docs for serving up bzr (particularly with the smart server) than just the little section at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server ?
[02:32] <jearl> I know I've seen something, but I can't remember where.
[02:33] <jearl> one second
[02:36] <jearl> OK, I can't find the docs I was looking for, but you can, of course, use htpasswd based authentication to control access to your smart server.
[02:37] <rocky> right... atm tho i'm having trouble setting up the smart server, period ;)
[02:37] <jearl> That's part of the reason that bzr+ssh is so popular.
[02:38] <rocky> well, for this particular project, setting up shell users for each committer isn't an option ;)
[02:39] <jml> rocky: at the moment, that's your only option if you want to provide write access to branches with the server.
[02:39] <jml> well, not true.
[02:39] <jearl> No, there are other options.
[02:39] <rocky> --allow-writes
[02:40] <jml> you could use Launchpad, or you could set up PQM.
[02:40] <rocky> the smart server supports --allow-writes
[02:40] <jearl> You could also do writes via FTP (assuming you can create FTP users)
[02:41] <jml> rocky: but that 'allow writes' means that anyone who can access the port would have write access.
[02:41] <rocky> jml: yes... that's what the apache htpasswd access is for
[02:42] <jml> it's not a web service though.
[02:43] <rocky> i thought it was a simple wsgi app
[02:43] <rocky> the smart server, that is
[02:43] <jml> no. the smart server is a custom server with a custom protocol.
[02:43] <jml> well
[02:44] <jml> you can get bzr+http access
[02:44] <jml> but that's readonly, afaik
[02:44] <rocky> ok google's broke, can't seem to find better bzr smart server / http serving docs
[02:45] <jml> the ones on bazaar-vcs.org are the best there is, I think.
[02:46] <jml> rocky: there's the possibility that I've said something wrong also :)
[02:47] <rocky> ;)
[02:48] <jml> rocky: you don't have to give people remote shell access in order to let them run 'bzr' via ssh, you know.
[02:49] <jml> they still need an account on the machine, but you can deny them a shell
[03:11] <lifeless> jml: spiv: mail for you
[03:27] <markh> would it make sense to add a param to tree.auto_resolve() that tells it not to perform the actual resolution, meaning it would return what files it *could* auto-resolve?
[03:29] <markh> (picture a GUI 'resolve' tool - ideally it would list all files in conflict, but put checkboxes (or otherwise distinguish) only the ones that can be auto-resolved)
[03:32] <Peng_> lifeless: Someone else already wrote a different log --limit patch: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080831160826.GA28292%40mutt.xyzz.org%3E
[03:32] <Peng_> He added a different test too.
[03:37] <spiv> markh: a dry_run=False param?
[03:37] <markh> spiv: yeah
[03:37] <lifeless> Peng_: I prefer mine :P
[03:37] <markh> spiv: how was the snow?
[03:37] <spiv> markh: If there's no better way to discover the auto-resolvable files (and I'm guessing there isn't), then it makes sense to me.
[03:38] <spiv> markh: slightly bruising :)
[03:38] <markh> I can't see one - that function has a local regex and string literals it checks the 'conflict type' against.  Duplicating that would be fragile...
[03:38] <markh> spiv: bruises are to be expected I expect :)
[03:38] <lifeless> well
[03:38] <spiv> markh: more bruising for my wife.  It turns out that knee pads mean that instead of vicious bruises covering most of the knee, you get mild bruise covering the *entire* shin.
[03:38] <lifeless> its a bit of  LBYL thing
[03:39] <lifeless> Why mark those you can autoresolve
[03:39] <lifeless> why not autoresolve and show the remaining conflicts
[03:39] <Peng_> lifeless: The other patch's unit test simply tests how many revisions were returned. What about adding that to your test and going with that?
[03:39] <Peng_> Oh, i see.
[03:39] <Peng_> Oh, i just noticed that you added a blackbox test, while the other patch didn't.
[03:40] <markh> lifeless: I'm slightly concerned that is "too magic" - a user sees a file as 'conflicting' - they right-click and hit 'resolve' - but then the list of files presented doesn't include the one they selected!
[03:40] <lifeless> Peng_: I didn't add any tests; I changed a insufficient test into a sufficient test :P
[03:40] <lifeless> markh: 'resolve file' means 'mark it resolved no matter what' in the CLI
[03:40] <markh> and presenting the remaining conflicting ones in the dialog isn't useful - they can't meaningfully resolve those that are left from that dialog anyway
[03:41] <markh> lifeless: yeah, I understand that
[03:41] <markh> lifeless: but the CLI has a terminal it can print meaningful messages to
[03:41] <lifeless> markh: I don't understand the problem I guess
[03:42] <markh> lifeless: I guess the question is about the user's expectation if they hit 'resolve conflict' on a file marked as being in conflict
[03:43] <lifeless> markh: it should resolve it, always
[03:43] <lifeless> markh: because they should only see the file being in conflict if it is
[03:43] <markh> lifeless: ok - so they select that on the root of the working tree
[03:43] <markh> you are saying "auto-resolve and list the remaining ones"
[03:44] <markh> in effect saying "there is no resolve dialog - just a dialog with a result of what files were auto-conflicted"
[03:44] <lifeless> no
[03:44] <lifeless> there are broadly three sorts of conflicts
[03:45] <lifeless> conflicts bzr can tell when they are resolved
[03:45] <lifeless> conflicts bzr can't tell when they are resolved
[03:45] <lifeless> conflicts that have been resolved but bzr hasn't checked yet
[03:45] <lifeless> if you have a resolve dialog, which of these three sets are useful to show ?
[03:46] <markh> phrased slightly differently: what does the user expect to happen when 'resolve conflicts' is selected from the menu?
[03:46] <lifeless> right
[03:47] <markh> my thought was "show all conflicts, which checkboxes against ones able to be auto resolved"
[03:47] <lifeless> fugly :)
[03:47] <markh> we have a similar concept now - eg "qbzr ci filename" shows *all* modifications, but only 'filename' checked
[03:47] <markh> similarly for resolve
[03:48] <lifeless> I think its ugly because it means the user has to think more about what the ui is telling it
[03:49] <markh> yes, I agree it might not be obvious
[03:49] <lifeless> is there ever going to be a different choice for the user than 'yes, the X boxes are right' ?
[03:50] <markh> I'm not sure it will be obvious though to auto-resolve all conflicts before evein showing them the dialog, and then only showing them the rest.  It means 'cancel' won't actually cancel anything
[03:50] <markh> for a file bzr can't auto-resolve but the user has resolved it, the user would check that specific item
[03:51] <markh> I'm slightly uncomfortable with "well do some magic in the background before asking you to go further"
[03:51] <lifeless> well
[03:51] <lifeless> use cases
[03:52] <lifeless> 'I want to resolve a conflict bzr can't auto-resolve'
[03:52] <lifeless> 'I want to run 'bzr resolve' - resolve everything it can and show me the remainder'
[03:53] <markh> and the most common 'I want to resolve a conflict bzr can auto resolve'
[03:53] <lifeless> why is that a use case?
[03:54] <lifeless> I think its a use case because you have a different one you haven't articulated, which is 'I want to keep something that is conflicted, that auto-resolve would unconflict, marked as a conflict'
[03:54] <markh> because the user edited a file to remove the conflict, but the item is still showing as being in conflict
[03:55] <lifeless> that is covered by 12:52 < lifeless> 'I want to run 'bzr resolve' - resolve everything it can and show me the remainder'
[03:55] <markh> the user wants to tell tbzr to show it correctly now please
[03:55] <markh> IMO the user is specifically focused on a single source file
[03:55] <lifeless> why wouldn't tbzr show it correctly automatically ?
[03:56] <markh> I'm not sure the users will expect a conflict cycle of "fix one conflict, attempt to resolve entire tree, fix next conflict, repeat..."
[03:56] <lifeless> I think this is like the status discussion
[03:56] <markh> I personally work more like "fix one, resolve one, fix next, resolve next"
[03:56] <lifeless> its a YAGNI driven by performance concerns
[03:56] <markh> no - its user expectations and workflows
[03:57] <markh> notihing about perf at all :)
[03:57] <lifeless> ok
[03:57] <lifeless> so you save the file
[03:57] <lifeless> and tbzr marks it as unconflicted
[03:57] <markh> we have one menu with scarce real-estate.
[03:57] <lifeless> no need for a menu item so far
[03:58] <markh> I think we are simply disagreeing on user expectations
[03:58] <markh> I should probably take it to the tbzr and qbzr mailing lists and try to form a consensus :)
[03:58] <lifeless> please keep bazaar@ in the loop
[03:58] <markh> ok
[03:58] <lifeless> I'm on neither of the GUI lists, and I'm not sure Martin or Aaron or others are either
[04:00] <lifeless> I would say that if you want a single file resolve, do that; don't conflate that with tree wide auto resolve; you can refactor bzr's auto resolve to a per-file basis to use it there if you want as well
[04:00] <lifeless> I certainly don't think that bringing up a tree wide menu if you are doing single-file workflow makes any sense, but that is what you seemed to be proposing
[04:01] <markh> I'm proposing that like TSVN, any directory with conflicting items would have a 'resolve' item on its menu
[04:01] <markh> and any file in conflict would similarly
[04:01] <markh> beyond that, I'm still working things out :)
[04:01] <lifeless> I would like:
[04:03] <lifeless> well
[04:03] <lifeless> I don't think doing a tree wide scan for auto-resolvable files without actually resolving them makes sense
[04:03] <lifeless> if you need that, I think there is confusion about whats going on
[04:05] <markh> think of it as warming the caches for the actual resolution that will happen any second now :)
[04:05] <markh> but I see your concerns
[04:05] <markh> I think broadening the discussion makes sense
[04:24]  * spiv wonders which project http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C200809010242.m812g2p9078345%40harfy.jeamland.net%3E belongs to
[04:24] <spiv> Ah, squid, judging from gmane.
[04:25] <markh> lifeless: do you think it makes more sense for some of you guys to join the tbzr developers mailing list rather than forcing cross-posts to 3 lists when most of the bzr readers probably don't care?  John already is...
[04:26] <lifeless> spiv: yes
[04:26] <lifeless> markh: well, this is the price of having multiple lists
[04:27] <spiv> Hmm, I thought abentley fixed the bug of broken merge directives on other lists being attributed to bzr?
[04:27] <lifeless> if the submit field is set correctly
[04:27] <markh> it doesn't seem helpful to introduce more noise on the bzr mailing list if the reality is that its only for the benefit of a couple of people
[04:28] <markh> its no skin off my nose though :)
[04:32] <jml> lifeless: mail regarding what?
[04:32] <lifeless> jml: launchpad's sftp server
[04:33] <jml> lifeless: I'll check my spam folder.
[04:33] <mwhudson> jml: it was bug mail
[04:34] <jml> mwhudson: I saw the thread, but didn't see lifeless's email.
[04:38] <jml> there it is.
[04:38]  * jml changes the bug's summary
[05:05] <jml> where can I find the version of pyflakes that loves lazy_import?
[05:10] <mwhudson> lp:~mwhudson/pyflakes/support-lazy-imports i think
[05:16] <jml> yay branches
[05:20] <mwhudson> i even used the ~vcs-import branch!
[05:24] <jml> lifeless: so, I've got all my interface tests done and have an implementation that makes them all pass. thing is it still opens the branch.
[05:24] <jml> lifeless: got ideas on how I can (or whether I should) write a test that shows that it doesn't open the branch?
[05:26] <lifeless> well
[05:26] <mwhudson> i guess you could delete .bzr/repository...
[05:26] <lifeless> opening the branch would fail if
[05:26] <lifeless> the stacked on branch was inaccessiblee or something
[05:27] <jml> so set a made-up, definitely doesn't exist url?
[05:30] <lifeless> or use a real url then delete the contents there
[05:40] <LaserJock> jelmer: around?
[06:03] <jml> lifeless: next question. I've got a test in bzrdir_implementation.test_bzrdir that looks like this: http://paste.ubuntu.com/42310/
[06:03] <jml> lifeless: problem is, none of the implementations run with a stackable branch & repo format.
[06:04] <jml> so the test never exercises the bit I'm primarily interested in.
[06:04] <jml> what should I do about this?
[06:04] <lifeless> change the meta one up to use 1.6
[06:04] <jml> the actual scenario?
[06:04] <jml> or just for this test?
[06:05] <lifeless> the scenario
[06:06] <jml> ok
[06:11] <mwhudson> bzrlib has a lot of lint
[06:12]  * AfC hands mwhudson a lint brush.
[06:14] <jml> yes it does :)
[06:18] <mwhudson> at least it's test suite is fairly fast
[06:21] <mwhudson> though, otoh, said test suite contains this:
[06:21] <mwhudson> reduce(getattr, (module).split('.')[1:], __import__(module))
[06:21] <mwhudson> which is not a thing to make a man happy
[06:23]  * jml stares
[06:24]  * jml attains satori
[06:33]  * mwhudson is not so lucky
[06:33]  * mwhudson goes to mow the lawn before it gets too dark
[06:54] <jml> lifeless: should I do something special for remote formats?
[07:14]  * mwhudson writes a whiny email to the list
[07:50] <jonnydee> lifeless: you said I should remember you if your fix for https://bugs.launchpad.net/bzr/+bug/255656 has not been merged into bzr.dev. Well hereby I remember you :)
[07:53] <jonnydee> (sorry, it means "remind you"...)
[08:15] <lifeless> jml: what do you mean?
[08:19] <markh> Is it 'expected' that 'bzr rm dir' silently takes no action and prints no message if dir is the root of a working tree?
[08:21] <Peng_> Whether or not it's expected, IMHO it should display an error.
[08:22] <markh> yeah, that's why I used quotes around 'expected' :)  I guess the question is: should I report a bug?
[08:22] <markh> no point wasting my time if lifeless or someone else can quickly say "nah, that's normal, don't bother reporting anything" :)
[08:25] <lifeless> Peng_: why should it error?
[08:25] <lifeless> Peng_: bzr add likewise doesn't error
[08:25] <lifeless> markh: it has taken an action
[08:26] <Peng_> Oh?
[08:26] <markh> you know I'm going to ask what action it took ;)
[08:26] <lifeless> its scanned for and removed any missing files
[08:27] <markh> the only action I can see it took was to compare the abspath to an empty string and therefore skipped that entry in the file_list
[08:27] <markh> doesn't 'bzr rm dir' normally removes versioned files in dir, and dir itself?
[08:27] <lifeless> markh: delete a file, run 'bzr rm'
[08:28] <markh> if 'dir' is the root of a wt, it doesn't take the same action it takes when dir is a subdirectory of a wt.
[08:29] <Peng_> That's...convenient, but nonintuitive. It is explained in the help though. Huh.
[08:29] <lifeless> markh: oh, I missed the exact quesiton; but I'm not sure its wrong anyhow
[08:30] <lifeless> Peng_: same as 'bzr add' being nonintuitive that it will scan-and-add, if you're coming from somewhere where you had to be explicit
[08:30] <markh> what about 'bzr rm .'?
[08:31] <Peng_> lifeless: Ehh, perhaps.
[08:31] <markh> (that gets a little upset trying to remove 'dir' on windows - or takes no action if the cwd is the root of a wt)
[08:31] <lifeless> markh: if we say: the same as  'bzr add .', then the current behaviour is probably good; if we say that 'explicit parameters always cause explicit actions' probably bad
[08:32] <markh> I'm more worried about the silence than the behaviour.  'bzr add .' at least tells you it does nothing :)
[08:33] <lifeless> markh: sure, file a bug if you like
[08:34] <markh> (although even then bzr seems confused:  added hello.txt\nadded new.txt\nignored 2 file(s).\nIf you wish to add some of these files, please add them by name.
[08:34] <markh> why did it say 'added' on the first 2 lines?
[08:34] <lifeless> markh: becase it added files
[08:35] <markh> oh right!  so 'bzr add .' *does* work in the root of a wt exactly the same as it does in a subdir
[08:35] <lifeless> note that 'bzr add .' won't print any output if there is nothing ignored and nothing added
[08:38] <lifeless> I'd like bzr rm to behave the same at any depth too
[08:39] <lifeless> I'm waiting to see if people become addicted to 'bzr rm' the way I have
[08:44] <lifeless> anyhow, I'm calling it a day
[08:45] <Peng_> Good night. :)
[08:46] <markh> have a good one!  nearly beer-oclock for me too :)
[09:09] <visik7> I can't get the difference between pull and update
[09:11] <luks> pull downloads revisions from a remote branch and updates the working tree to the head revision
[09:11] <luks> updates updates the working tree to the head revision of the bound branch
[09:11] <luks> -s in the first "updates" :)
[09:12] <luks> pull in a standalone branch, and update in a checkout are similar though
[09:13] <luks> it all makes more sense if you understand the concept of branches and working trees in bzr
[09:25] <markh> in some ways, having 'pull' default to also doing an update of the working tree isn't helpful to someone learning bzr concepts (although it certainly is useful in its own right)
[09:30] <AfC> markh: you're not the first to remark that
[10:23] <poco> hi
[10:24] <poco> i have a repository but i want to move all its content in a subdirectory. should i simply use bzr mv? and if i want to merge 2 repositories in one parent repo, how should i do that?
[10:25] <poco> maybe juste a bzr merge inside a subdir ?
[10:27] <poco> if i simply do a merge inside current dir, i loose all the revisions of original repo
[10:28] <poco> with a mkdir bla; cd bla; bzr merge foo; mkdir foo; bzr mv * foo
[10:30] <poco> and if i do "bzr co" inside "bla" i'm gona have multiple repos
[10:31] <poco> maybe "bla" should be init with init-repo? could i then use recursive "repositories" (init-repo)
[10:33] <Odd_Bloke> poco: Using bzr mv for your first case is probably the best way to go about it.
[10:34] <poco> Odd_Bloke, thanks
[10:35] <Odd_Bloke> As for merging two branches (which is, I assume, what you mean), are you sure that the merge loses the revisions, or is it just not showing them in the left-hand ancestry?
[10:36] <poco> i am not sure, what do you mean by left-hand ancestry?
[10:40] <Odd_Bloke> poco: The mainline revisions, which don't have a dotted revision number.
[10:41] <poco> ah!
[12:10] <poco> i understand how to solve conflict with the .THIS, .BASE and .OTHER, but how am i suppose to resolve them with the 'moved existing file to ... .moved' ?
[12:11] <james_w> if you want a particular copy then move that in to place
[12:11] <james_w> if you want some hybrid then copy the bits you want from .moved in to the file
[12:11] <poco> ah ok, i need to given explicitely the filename when resolving?
[12:12] <james_w> I think so, yes
[12:13] <poco> thanks
[15:49] <jelmer> lifeless, ping
[15:49] <Guest47733> jam, ping
[15:56] <ignas> hi
[15:57] <ignas> is there a way to "lift" my changes, merge from another branch and apply them back again without commiting?
[15:57] <ignas> i have tried to use "shelve"
[15:57] <ignas> but it did not help me, because it does not "shelve" added directories :/
[16:00] <Odd_Bloke> ignas: Could you not add the directories/files back _after_ you've merged?
[16:01] <ignas> i just thought that maybe there is a way that will not require me to play around with specific files/changes
[16:13] <jam> jelmer: I saw you released 0.4.12, but I don't see the tag available from bzr.d.o
[16:14] <jelmer> jam, I've pushed to http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental
[16:14] <jam> jelmer: so should this go in "bzr-beta-ppa" then?
[16:15] <jelmer> we're not uploading to unstable at the moment because of the freeze of lenny
[16:15] <jam> k
[16:15] <jelmer> jam: it's actually a stable release of bzr-svn, so probably ~bzr
[16:23] <jelmer> jam, what's the easiest way to test for a deprecation warning?
[16:23] <jelmer> I was looking for tests for ensure_null() but there don't appear to be any >-)
[16:48] <james_w> jelmer: apply_deprecated I think
[16:49] <jelmer> james_w: Thanks
[16:49] <jam> james_w: it would be self.applyDeprecated, but that is only if the function you are calling is directly deprecated
[16:49] <jam> you need callDeprecated
[16:49] <jam> to pass in a custom deprecation string
[16:50] <james_w> hi jam
[16:50] <jam> I'm not really here
[16:50] <jam> I'm on vacation today :)
[16:50] <james_w> it's alright, I didn't see you.
[16:57]  * awilkins curses Borland for writing batch scripts that call classes for which not even the fricking package exists
[16:58] <awilkins> I hope the crotch of their testing manager gets savaged by a german giant rabbit
[16:58] <jelmer> good morning to you too, awilkins :-)
[16:59] <awilkins> Bah, time to go home
[16:59] <awilkins> Back later :-)
[17:11]  * jelmer files some more bzr-builddeb wishlist bugs
[17:19] <jam> jelmer: packages should be uploaded
[17:19] <jam> at least for gutsy/hardy/intrepid
[17:20] <jelmer> jam: Thanks
[17:34] <exarkun> Why does this happen?  http://rafb.net/p/UJo6VW65.html
[17:38] <rocky> jelmer: you released bzr-svn 0.4.12 but the download link on pypi leads to a page that lists all releases up to 0.4.11 it looks like
[17:40] <jelmer> rocky: Sorry, I forgot to update the wiki page. will do so now
[17:40]  * rocky is in jelmer's shadow ;)
[18:07] <Snaury> jelmer: while trying to checkout pugs with bzr-svn I noticed with -Dtransport that there are often multiple 'svn get-dir' lines for the same revision, why could it be so?
[18:07] <Snaury> (this is during "determining revisions to fetch" phase)
[18:37] <rocky> anyone have a favourite bzr mode for emacs? something preferably along the lines of psvn ?
[18:59] <jelmer> Snaury, would need some looking into
[18:59] <jelmer> Snaury, the direct return value of get_dir isn't cached but some of the values based on it are
[19:01] <Snaury> http://kitsu.ru/bzr-log-partial.log - it's just the pattern looked strange to me.
[19:04] <Snaury> And they look rather expensive too (unless there's something else eating time between the calls, haven't checked that yet). When there are 20000 revisions the overhead would turn out pretty bad. :)
[19:05] <jelmer> it's only called if the branch directory changed in that revision
[19:12] <Snaury> Well, judging from the fact that it was determining revisions to fetch for more than several hours it was called for every revision at least twice and for some revisions three or more times. And in the case of pugs trunk it's pretty expensive too:
[19:12] <Snaury> 59.577  svn get-dir -r2043
[19:12] <Snaury> 61.415  svn get-dir -r2043  (finished)
[19:13] <Snaury> 61.415  svn get-dir -r2042
[19:13] <Snaury> 63.680  svn get-dir -r2042  (finished)
[19:13] <Snaury> Perhaps it could be cached as a whole somehow?
[19:16] <Snaury> (as a proof of three or more times look at the bzr-log-partial.log above, which was a restart after yet another connection loss)
[19:16] <Snaury> And url is http://svn.pugscode.org/pugs/ you can try it yourself, of course.
[19:27] <jelmer> Snaury, I think I may know some way to skip the need to do those calls in a lot of cases
[19:27]  * LarstiQ cheers jelmer on
[19:59] <jelmer> hmm, bzr-svn trunk is freakishly quick now and it's still doing those get-dir requests
[19:59] <LarstiQ> jelmer: what's the improvement?
[19:59] <jelmer> fetches about 7 revisions per second from the pugs repository
[20:00] <LarstiQ> instead of?
[20:00] <jelmer> probably about 1 or 2
[20:01] <LarstiQ> nice
[21:30] <rocky> jelmer: so you've been working on increasing speed of bzr-svn further since the 0.4.12 release?
[21:31] <jelmer> yeah
[21:31] <jelmer> This is all happening in trunk, which will at some point become 0.5
[21:31] <rocky> oh... doesn't 0.4 get released from trunk too or does it live on a special 0.4 branch?
[21:32] <rocky> i was playing with the smart server wsgi setup yesterday until i ran out of steam... seems like it should be easier to setup ;)
[21:33] <rocky> jelmer: don't suppose you have an example standalone py script server that uses wsgiref to serve up the bzr smart server?
[21:33] <jelmer> 0.4 gets released from a separate branch, the 0.4 branch
[21:34] <jelmer> rocky, no sorry, I don't have experience with the wsgi server
[21:39] <luks> I had a plugin that does 'bzr serve --http' using wsgiref some time ago
[21:42] <luks> bzr serve-http actually
[21:42] <luks> http://rafb.net/p/guvLH649.html
[21:42] <luks> dunno if that still works
[21:53] <rocky> luks: oh thanks
[21:54] <luks> rocky: you could fix it, make it configurable and release a proper plugin! :)
[21:54] <rocky> seems kind of silly to me that bzr serve doesn't have something similar to this anyhow... i mean http based protocols are way more flexible ;)
[21:55] <luks> what I wanted was to add per-branch HTTP auth to the WSGI server
[21:55] <luks> but that failed due to lack of interest, and this code is just a leftover
[22:02] <rocky> well atm i'm working on a project that manages multiple trac instances with their relative svn instances and such and i want to extend it for bzr... having my python wsgi app serve up the bzr directly instead of having to rely on apache (for svn) would give me a great deal of flexibility
[22:05] <rocky> are repos that are served up by the bzr wsgi app browseable using a browser?
[22:05]  * rocky tries to get it working to test for himself
[22:05] <mwhudson> probably not, but that should be easy to add
[22:39] <beuno> mwhudson, when you have time, can you take a peak at: https://code.edge.launchpad.net/~beuno/loggerhead/1.6.1/+merge/806
[22:40] <mwhudson> beuno: um, sure, merge it
[22:41] <beuno> that was easy
[22:41] <beuno> and release 1.6.1 to make lifeless happy?
[22:41] <mwhudson> sounds good
[22:43] <beuno> mwhudson, sweet, thanks
[22:54] <beuno> lifeless, https://edge.launchpad.net/loggerhead/1.6/1.6.1
[22:54]  * beuno goes off and leaves the announcement for later
[23:06] <rocky> luks: don't suppose you know of better "serving bzr repos" docs than what's in the user's guide?
[23:25] <rocky> is there anyway to pass in credentials for a basic auth protected url (say in a config file) so you don't have to include them on the command-line ?
[23:33] <lifeless> moin
[23:33] <mwhudson> hi lifeless
[23:34] <beuno> howdy lifeless
[23:35] <beuno> I've made a special Loggerhead release for you  :)
[23:36]  * beuno -> home
[23:51] <poolie> good morning
[23:52] <jelmer> hi Poolie
[23:52] <jelmer> How were your holidays?
[23:53] <poolie> really great
[23:53] <poolie> and you?
[23:56] <jelmer> apart from a rough start (er visit and a leaking tent) very good
[23:58] <poolie> lifeless, spiv, igc, jam, call in 2m?
[23:58] <spiv> Good morning.
[23:58] <spiv> poolie: yeah
[23:59] <mwhudson> spiv: hi, have i talked to you about https://bugs.edge.launchpad.net/bzr/+bug/261315 yet?
[23:59] <spiv> mwhudson: I don't think so
[23:59] <mwhudson> ok
[23:59] <mwhudson> i would really like someone to fix it fairly soon :)


[07:48] <tarunno> Hello all
[07:49] <tarunno> I have a question
[07:49] <tarunno> we have a mailing list at lists.ubuntu.com with which we are having some issues
[07:50] <tarunno> can anyone tell me whom to cantact to resolve those issues,please
[07:50] <YoBoY> good morning
[07:51] <YoBoY> hi tarunno, what kind of issue ?
[07:51] <dholbach> good morning
[07:53] <tarunno> YoBoY: Need to change admin and admin pass type of isues
[07:56] <tarunno> YoBoY: any idea?
[07:56] <YoBoY> tarunno: have you contacted the previous admin of the list ?
[07:59] <tarunno> YoBoY: that is the problem. Due to some personal problems he is not accesssible right now
[07:59] <tarunno> He got sick too
[08:01] <YoBoY> it's a locoteam ML ?
[08:02] <tarunno> yes
[08:03] <YoBoY> The locoteam contact can send a mail to<EMAIL_ADDRESS>and to the lococouncil to ask that type of change.
[08:04] <tarunno> I see!
[08:04] <tarunno> Thanks YoBoY
[08:04] <tarunno> :)
[08:05] <YoBoY> you're welcome, I don't know if this work, but it's a start ;)
[11:36] <bassem> czajkowski, hello
[12:25] <ebel> ah post codes we meet again
[12:26] <ebel> I'm trying to fill in the 'request a loco cd pack', and ireland doesn't have postcodes, but the address form requires a postcode/zip code field.
[12:28] <ebel> heh, the loco cd form accepts "N/A" as a postcode. So it requires a postcode, but doesn't. :) Ah well.
[12:35] <JanC> ebel: many countries also don't have provinces or states, or they have both (and/or they are meaningless in an address)
[12:35] <ebel> I think all forms for addresses should have a <textarea>, big blank space with instruction "Write what should be on the package so the postman can get there"
[12:36] <JanC> +1 on that  ☺
[12:36] <ebel> since everyone knows the correct form of address to put down
[12:37] <JanC> also, might need extra lines/info in case of a business building with several companies in it, etc.
[12:38] <JanC> and they always put the postcode in the wrong place for Belgian addresses too  ;)
[12:38] <JanC> s/always/often/
[12:49] <ebel> nothing infuriated me more than "Your address is invalid", I know where I live. :)
[18:12] <cjohnston> mornin
[20:27] <YoBoY> jono: ping
[20:53] <trinikrono> hello loco


[00:05] <someone_> hey everyone, I'm new here and want to ask, do I have to install audio/video codecs after installing Ubuntu Studio on my HDD?
[00:12] <kryten> !codecs | someone_
[06:56] <Guest62892> hello, can someone tell me how to use my native instrument audio2dj card in ubuntu studio
[06:57] <Guest62892> i just want to be able to ear what i do i music production softwares (for example i am assembling some intyerviews in audio documentary)
[06:58] <rastamanking> can i use addictive keys through wine with midi?
[22:51] <Zulu> hi..i cant get any msi interrupts, eventhough some devices support it. uefi boot works best on this p8z77v-lx mobo with intel gigabit and gtx 770 cards
[22:56] <Zulu_> hi, i dont get any msi interrupts on 14.04, on my p8z77v-lx mobo with i5 3470. uefi boot with intel gigabit and nvidia gtx 770.
[23:49] <tekNorah> Hello! :)
[23:51] <tekNorah> So, I have an older version of Ubuntu Studio and was thinking about upgrading to the newest version since I see that it is an "official" Ubuntu distribution now
[23:55] <tekNorah> I am wondering if anyone has encountered this bug and if the newer version have a fix: When I turn off my screen or switch to a different input on my screen (other PC), and when I come back (turn on or switch back), the mouse arrow is stuck at the same spot it was at before, but I can still move the mouse (like it is invisible).  I have to log off/on in order to get the mouse arrow to move again.


[01:22] <LLStarks> asac. what's the best way to find when and how a change landed in the 1.9.2 branch?
[01:23] <fta> hg blame your/file
[01:23] <fta> or http://mxr.mozilla.org/mozilla1.9.2/
[01:24] <micahg> fta: what do I need to look for in the .rej file?
[01:25] <fta> micahg, it's the part of the original patch that was rejected and that you need to re-add, or drop if it's no longer needed
[01:25] <micahg> well, I'm looking at the file and I can't see what's wrong
[01:26] <fta> often, it's just that the context of the patch changed, so just re-add the changes manually, and quilt refresh afterwards
[01:28] <micahg> fta: would whitespace mess up a patch?
[01:28] <fta> yes, everything different will
[01:28] <LLStarks> fta, this is so frustrating. i know that a trough-border issue was resolved between firefox 3.5.4 and 3.6a1
[01:28] <LLStarks> but i can't drill it down any further
[01:29] <micahg> LLStarks: those releases are not contiguous
[01:29] <LLStarks> i know
[01:29] <LLStarks> but between those branchings
[01:30] <LLStarks> would it be mozilla-central or mozilla-1.9.2?
[01:32] <micahg> 3.6a1 would be mozilla-1.9.2
[01:32] <micahg> mozilla-central is 3.7
[01:32] <LLStarks> well, if the fixed behavior is present in both, where did it originate?
[01:33] <micahg> in both what/
[01:34] <LLStarks> the bug is fixed in both
[01:35] <LLStarks> yet i can't find the commit that fixed the bug
[01:39] <micahg> well
[01:39] <micahg> it depends when it was fixed
[01:39] <micahg> if it was after the branch, it landed in 3.7 first
[01:39] <micahg> before they were the same
[01:39] <micahg> in mxr.mozilla.org, you can search for files and then see who committed what revision
[01:41] <LLStarks> it's fixed in 3.6a1
[01:41] <LLStarks> i'm not sure how much earlier though
[01:44] <micahg> LLStarks: maybe search bugzilla for the bug and see the changeset
[01:45] <LLStarks> my bug is the only relevant one
[01:45] <micahg> why are you looking for it?
[01:45] <LLStarks> to have the fix backported for karmic
[01:46] <LLStarks> the art team wants it
[01:46] <micahg> do you have the bug number for bugzilla?
[01:46] <LLStarks> https://bugzilla.mozilla.org/show_bug.cgi?id=500368
[01:46] <asac> thats definitly not the bug
[01:47] <asac> that was fixed upstream ;)
[01:47] <LLStarks> i know
[01:47] <LLStarks> i'm looking for the commit
[01:47] <asac> i am sure you wont find it that easily ;)
[01:47] <asac> there are probably 2k commits or something ;)
[01:47] <LLStarks> what's with the wink
[01:47] <asac> you need to find the bug :)
[01:47] <LLStarks> you did it, didn't you?
[01:47] <asac> i did it?
[01:48] <LLStarks> i know the bug was elevated
[01:48] <micahg> asac: http://bazaar.launchpad.net/~micahg/firefox/firefox-3.7.head/revision/459
[01:48] <LLStarks> but i lack the technical knowhof to find it
[01:48] <asac> i remember that we did something ... yes.
[01:48]  * micahg finally go tit
[01:48] <asac> but i have no clue ;)
[01:48] <micahg> oops :)
[01:48] <micahg> got it
[01:49] <micahg> that's the nsGnome patch
[01:49] <LLStarks> wait, is that it?
[01:49] <micahg> LLStarks: something else for the umd builds
[01:49] <asac> https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=trough&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=EXPIRED&resolution=MOVED&resol
[01:49] <asac> thats a search for trough with all closed bugs ;)
[01:50] <asac> but i dont see it in there ;)
[01:50] <micahg> asac: should I propose a merge?
[01:50] <LLStarks> could someone have fixed it without even knowing it?
[01:51] <micahg> LLStarks: sure
[01:51] <LLStarks> btw asac, the bug i filed was previously and erroneous marked as worksforme by brosnan
[01:52] <asac> micahg: is the patch done?
[01:52] <asac> and working? ;)
[01:53] <micahg> asac: the first part
[01:53] <micahg> I fixed the gnome fix, now on to the missing dir
[01:54] <LLStarks> micahg, if it was a blind, blanket fix done as part of the evolution of the gtk widget in firefox, would it even be documented in a mailing list or public sphere?
[01:54] <asac> LLStarks: you know ... all is in hg
[01:54] <asac> and bugzilla
[01:54] <asac> thts all
[01:54] <asac> check the commits to
[01:54] <micahg> LLStarks: without a bug or a changeset, you have no idea if it was a side benefit of another patch or explicitely
[01:54] <asac> /widget/src/gtk2/gtk2drawing.c
[01:54] <micahg> fixed
[01:55] <asac> /widget/src/gtk2/nsNativeThemeGTK.cpp
[01:55] <asac> with some luck those files have not been touched so often ;)
[01:55] <LLStarks> i know, i've been looking at changes over the past year
[01:55] <LLStarks> i don't know enough c to parse the files
[01:55] <micahg> asac: does mxr deal with missing files?
[01:56] <asac> summary:     Bug 501104. Handle GTK2 default button borders properly. r+sr=roc
[01:57] <asac> LLStarks: ^^
[01:57] <asac> LLStarks: i dont look at code
[01:57] <asac> just at the changes
[01:57] <asac> mozilla bug Bug 501104
[01:57] <asac> mozilla Bug 501104
[01:57] <LLStarks> bingo
[01:58] <LLStarks> does the canonical agreement with mozilla allow small backports?
[01:58] <LLStarks> from future releases?
[01:58] <asac> no
[01:58] <asac> we need to get it landed upstream
[01:59] <asac> if its too risky for them its too risky for us ;)
[01:59] <asac> which is quite a sensible line ;)
[01:59] <asac> LLStarks: but thats just button borders
[01:59] <asac> i dont think thats your bug
[01:59] <LLStarks> i know
[01:59] <LLStarks> trough-borders
[01:59] <LLStarks> scrollbars and the like
[02:01] <LLStarks> brb
[02:04] <micahg> asac, I think I found the bug for the other one upstream
[02:13] <micahg> asac: mozilla bug 511642 is breaking 3.6
[02:13] <micahg> and 3.7
[02:15] <asac> yeah
[02:15] <asac> so they unified the list
[02:15] <asac> so we need to adjust our patch to patch the new file
[02:15] <asac> browser/installer/package-manifest.in
[02:15] <micahg> yep
[02:16] <micahg> working on it now
[02:16] <asac> did you manage to get first patch done?
[02:16] <asac> want to show me?
[02:16] <micahg> yep
[02:16] <asac> just the patch i mean ;)
[02:16] <asac> and maybe an interdiff
[02:16] <micahg> https://code.edge.launchpad.net/~micahg/firefox/firefox-3.7.head
[02:16] <asac> of the previous to the new patch
[02:16] <asac> micahg: please use topic names ;)
[02:16] <micahg> ??
[02:16] <asac> you now took the same branch name as our branch
[02:17] <asac> this means you cannot keep it after we merged it
[02:17] <asac> well you can keep it
[02:17] <micahg> ok
[02:17] <asac> but you cannot reuse the same name
[02:17] <asac> use topic name
[02:17] <micahg> well
[02:17] <asac> topic names
[02:17] <asac> like firefox-3.7.head.daily-patch-rebase-DATE
[02:17] <micahg> what should I have used for this ff3.7.head.umd20090910
[02:17] <asac> or something else innovative
[02:17] <asac> yes for instance
[02:17] <micahg> ok
[02:17] <micahg> well
[02:17] <micahg> I can push up a new branch
[02:17] <asac> you can rename the branch even in launchpad ;)
[02:18] <asac> doesnt matter. just wanted to explain the problem with not using topic branches ;)
[02:18] <micahg> ok
[02:18] <micahg> done
[02:18] <asac> so launchpad code is completely broken
[02:18] <asac> new url please ;)
[02:18] <asac> i cannot look at the diff anymore now ;)
[02:19] <asac> ah ok
[02:19] <asac> no
[02:19] <asac> ;)
[02:19] <asac> found it
[02:19] <asac> you used my name ;)
[02:19] <micahg> hmm
[02:20] <asac> ok so that patch was just rebased ... no changes needed?
[02:20] <asac> update debian/patches/lp185622_system_path_default_browser.patc
[02:20] <asac> forgot the "h" at the end
[02:20] <asac> but no need to fix that ;)
[02:20] <micahg> I only removed lines
[02:20] <micahg> yes
[02:21] <asac> ok
[02:21] <asac> push the new one ;)
[02:21] <micahg> working on it...
[02:21] <asac> k
[02:21] <micahg> I refreshed the first patch
[02:21] <micahg> the second one is giving me issues
[02:21] <micahg> let me try again
[02:21] <asac> Update lp185622_system_path_default_browser.patch to remove libgnomevfs (Mozilla Bug 294375)
[02:21] <asac> i usually just say:
[02:21] <asac> * adjust patches to new upstream code base
[02:21] <asac>   - update patch1
[02:21] <asac>   - update patch2
[02:22] <asac> and do those in one commit unless some patch needs more love
[02:22] <micahg> ok
[02:22] <asac> but the new patch needs more love
[02:22] <micahg> I thoguht you said to do one fix per patch
[02:22] <asac> because they refactored stuff
[02:22] <asac> micahg: for me "* adjust/rebase patches to new upstream code base" is one fix ;)
[02:22] <micahg> ok
[02:22] <micahg> well
[02:22] <asac> because all together fix the build
[02:22] <asac> ;)
[02:23] <asac> if there is a bug or a more complicated rebase
[02:23] <micahg> I can fix and then repush
[02:23] <asac> no its ok
[02:23] <asac> well
[02:23] <asac> maybe use the adjust syntax ;)
[02:23] <asac> no need to do all in one patch
[02:24] <asac> but i dont mind if its not in changelog as long as its clear that this adjusts/rebases a patch
[02:24] <micahg> asac: I'm still learning the lingo
[02:25] <asac> sure. your comment reads too "complicated" ;)
[02:25] <micahg> I thought it was removing gnomevfs from the patch, but it was really rebasing since we didn't make any changes with gnomevfs
[02:25] <asac> i would think ... oh it was serious work needed ;)
[02:25] <asac> even though it just shuffles bits
[02:25] <asac> yes
[02:25] <asac> thats what i men
[02:25] <asac> mean
[02:25] <asac> a comment like: "* adjust/rebase patches" ... implies: business as usual
[02:26] <asac> everything else would make me wonder: what was this in a year or so ;)
[02:26] <asac> its your private branch so you can just uncommit and push --overwrite
[02:27] <asac> after doing it two or three times
[02:27] <asac> you will know the procedure ;)
[02:27] <micahg> is it not helpful to mention which upstream patches caused the rebase?
[02:27] <asac> its not really rocket science. just a few "best" practices we do with our branches that make live easier to collaborate
[02:28] <asac> micahg: usually not.
[02:28] <asac> its at the committers discretion
[02:28] <asac> for rebasing usually not
[02:28] <asac> but for dropping its nice to say which bug made this obsolete
[02:28] <asac> or if the patch was not a rebase, but needed to be redone differently
[02:29] <micahg> ok
[02:29] <micahg> I got through it
[02:29] <asac> so for this "manifest unification" cause
[02:29] <micahg> working on file 3 of the installer cleanup
[02:29] <asac> it might be reasonable to say that
[02:29] <asac> its not a plain adjust
[02:29] <asac> but "rework patch after upstream landing of bug ..."
[02:29] <asac> or something
[02:29] <asac> maybe also give a word or two how you reworked it if its noteworthy
[02:30] <asac> like "rework patches after upstream landing of bug ...; we move the bits and pieces from the platform specific installer manifest to the new common location and do this and that ..."
[02:30] <asac> ;)
[02:30] <asac> but dont make an art out of it ;)
[02:34] <micahg> ah, I'm done :)
[02:35] <micahg> ok, so now I make another commit
[02:35] <asac> yeah
[02:35] <micahg> or just uncommit and fix everything in the comment :)
[02:35] <micahg> uncom,mit?
[02:35] <asac> i would split it in two commits:
[02:36] <micahg> ok
[02:36] <asac> a) simple patch rebase/addjustment
[02:36] <asac> b) patch changes because of manifest changes
[02:36] <asac> but thats just my opinion
[02:36] <micahg> ok
[02:36] <micahg> will do
[02:36] <asac> if you are sure that your manifest adjustment was good you can also just sell it as a "rebase"
[02:36]  * micahg thinks is good, but it was 3 patches and 1 code change
[02:37] <asac> what do you mean?
[02:37] <asac> my suggestion is
[02:37] <micahg> I had to change bin to @BINPATH@
[02:37] <asac> ah
[02:37] <micahg> in one file
[02:37] <micahg> to match the new style
[02:37] <asac> ok
[02:37] <asac> well. just commit as you think
[02:38] <micahg> so 2 commits or one?
[02:38] <asac> i will see if that makes sense to me ;)
[02:38] <asac> i wouldnt commit a patch change that involved real changes in a normal "adjust all patches to new codebase" commit
[02:39] <asac> but thats me ;
[02:39] <asac> )
[02:39] <asac> but if in doubt. splitting is always good ;)
[02:39] <asac> also gives you more commits and more bzr karma in launchpad ;)
[02:42] <asac> oh no ;) ... just found out that i trashed my gnome-bluetooth upload i prepared in /tmp/ with last reboot
[02:42]  * asac shouldnt reboot
[02:42] <micahg> ok, I just pushed it up
[02:43] <micahg> I noted the mozilla bug for the manifest change
[02:43] <asac> launchpad is slow in updating ... takes a minute i gues
[02:44] <micahg> done
[02:45] <asac> yeah. so the commit message is still not formatted like we do ;)
[02:45] <micahg> brb
[02:45] <micahg> ugh
[02:46] <micahg> sorry
[02:46] <asac> http://bazaar.launchpad.net/~micahg/firefox/firefox-3.7.head.daily-patch-rebase-20090910/changes
[02:46] <asac> look at that
[02:46] <micahg> forgot the *
[02:46] <micahg> should I fix?
[02:46] <asac> also you dont need the "updated patches:" line
[02:46] <asac> because we say:
[02:46] <asac>  - update path/to/file
[02:47] <asac>  - remove path/to/file
[02:47] <asac>  - add path/to/file
[02:47] <micahg> ok
[02:47] <micahg> I'll try again :)
[02:48] <asac> in the meantime i look at the changes
[02:48] <asac> also i usually say: "... after upstream landing of BUG or TOPIC" ;)
[02:48] <asac> or TOPIC (bmo: BUG)
[02:49] <asac> but if the formatting is ok i am fine ;)
[02:50] <asac> +bin/chrome/awesome-branding.jar
[02:50] <asac> thats wrong i think
[02:50] <asac> you need to use templates everywhere in our patch
[02:50] <asac> @BINPATH@
[02:50] <asac> same for the browser_branding patch
[02:51] <micahg> oops
[02:51] <asac> you can edit the patches directly ;)
[02:51] <asac> of course its safer to push and refresh
[02:51] <asac> maybe do that to excersize a bit more ;)
[02:51] <asac> editing patches directly can still be done later ;)
[02:53] <asac> #ifdef XP_UNIX
[02:53] <asac> is the #endif there somewhere?
[02:53] <asac> could be that we dont see it in this patch ;)
[02:53] <micahg> yes
[02:53] <asac> ok
[02:54] <micahg> is it ok that I put it there and not under the ifndef XP_MACOSX?
[02:54] <asac> our patch is not really arch specific
[02:55] <asac> i would think
[02:55] <asac> so could be moved even outside that block
[02:55] <asac> but doesnt relly matter much here
[02:55]  * micahg will try  a test build
[02:56] <asac> cool
[02:56] <asac> thats important
[02:56] <asac> maybe the branding is completely busted now and firefox doesnt work ;)
[02:56] <asac> but i hope its ok
[02:56] <asac> the changes look good to me ;)
[02:56] <micahg> yay!
[02:56] <asac> at least from the technical side
[02:56] <micahg> BTW, 3.6 only needs the manifest changes
[02:57] <asac> if it doesnt work we have to check whats going on now
[02:57] <micahg> I fixed the binpath, now I have to push it up again
[02:57] <asac> fix the commit syntax while you are at it ;)
[02:58] <micahg> I did
[02:58] <asac> good
[02:58] <micahg> BTW, the main problem I had was I didn't know where to fix the .rej file :)
[02:59] <asac> did you figure that out?
[02:59] <micahg> yep, with some help from hyperair
[02:59] <asac> the quiltrc fta gave you had some "use unified rejects" option
[02:59] <asac> you might want to try that at some point
[02:59] <asac> the normal .rej format is odd
[02:59] <asac> but i got used to it
[03:00] <asac> great
[03:00] <asac> that you dound your way ;)
[03:00] <asac> micahg: you forgot a whitespace ;)
[03:00] <asac> indentation
[03:00] <asac> of comment :)
[03:00] <micahg> yeah, I had to fix it in the file and then use your funny diffstat ccommand
[03:00] <asac> you should really look at bzr log | less
[03:00] <micahg> where?
[03:01] <asac> hmm
[03:01] <asac> maybe its the firefox font ;)
[03:01] <asac> its ok ;)
[03:01] <micahg> that's the browser
[03:01] <asac> yeah
[03:01] <asac> so please test a build
[03:01] <asac> and let me know if it works
[03:02] <asac> is xulrunner also coming?
[03:02] <asac> didnt even know it failed ;)
[03:02] <asac> no xul is fine as it seems
[03:02] <asac> ok
[03:03] <micahg> I made an alias for quilt refresh --diffstat
[03:03] <asac> yes. you can also use quiltrc for that ;)
[03:03] <asac> i think everything is ok but the QUILT_PATCHES thing
[03:03] <asac> thats bogus as it seems for the embedded tarball thing here
[03:04] <asac> fta: so firefox-3.7 is still in dep wait state. probably got the 1.9.3~umd as the lower bound today ;)?
[03:05] <micahg> asac: well, it wouldn't bui,ld anywyas
[03:05] <asac> sure
[03:06] <asac> thats for sure i mean ;)
[03:06] <asac> i386 has 14k jobs on 15 ppa builders
[03:06] <asac> ouch
[03:06] <asac> https://edge.launchpad.net/builders
[03:18] <micahg> asac: builds started right away for me
[03:32] <micahg> asac: it built fine :)
[03:34] <micahg> asac: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20090910 Ubuntu/9.04 (jaunty) Minefield/3.7a1pre
[03:37] <asac> does it work?
[03:37] <micahg> yep
[03:38] <asac> try to install abrowser stuff please
[03:38] <asac> micahg: did you install all packages? e.g. also the -branding etc.?
[03:38] <micahg> yeah, I had the ff3.7 branding
[03:38] <micahg> it showed minefield
[03:38] <micahg> now trying abrowser branding
[03:39] <micahg> hmm
[03:39] <micahg> xml error on abrowser
[03:39] <jcastro> asac: yikes, it's like 5 days of back ups for PPAs
[03:40] <asac> micahg: check if downgrading to latest fixes it at all
[03:40] <asac> otherwise its not a bug in your change ;)
[03:42] <micahg> still a problem
[03:42] <micahg> but someone else opened a bug for that issue
[03:42] <micahg> in 3.5
[03:43] <micahg> maybe it's only abrowser related?
[03:43] <asac> could be. there is a problem in 3.5?
[03:44] <micahg> do you have the menu whited out in 3.7?
[03:45] <asac> hmm so abrowser command starts firefox 3.0 with official branding ;)
[03:45] <micahg> on jaunty
[03:45] <micahg> or karmic?
[03:45] <asac> xml error in about help?
[03:45] <asac> err help -> about
[03:45] <asac> thats what i see
[03:46] <asac> seems we miss a logoCopyright entity in our branding pieces
[03:46] <asac> hmm
[03:46] <micahg> well, if you don't have the abrowser-branding installed
[03:46] <asac> those branding pieces get lumped together during tarball creation iirc
[03:46] <asac> micahg: what do you mean?
[03:47] <asac> i installed abrowser-3.5-branding
[03:47] <asac> thats how i installed abrowser ;)
[03:47] <micahg> on jaunyt or karmic?
[03:47] <asac> karmic
[03:47] <asac> and abrowser-3.5 depends on abrowser-3.5-branding
[03:47] <micahg> yeha, that shouldn't show 3.0 anything
[03:48] <asac> thats just the abrowser command
[03:48] <asac> the abrowser-3.5 command works
[03:48] <asac> only thing broken is about help
[03:48] <asac> which afaik is what the 3.5 bug is about
[03:48] <micahg> asac: http://packages.ubuntu.com/search?suite=karmic&arch=any&searchon=contents&keywords=abrowser
[03:48] <micahg> that's why
[03:48] <asac> sure
[03:49] <micahg> should I open a bug?
[03:49] <asac> thats not a big problem ... we just need a bug for that ;)
[03:49] <asac> yes.
[03:49] <asac> "ship unversioned abrowser commandin firefox-3.5 ... or something alike
[03:49] <micahg> and we already have one for the other
[03:49] <micahg> bug 396156
[03:49] <asac> yes
[03:49] <asac> i have to investigate that
[03:51] <micahg> asac: -beta?
[03:51] <micahg> bug 427674
[03:52] <asac> thx
[03:53]  * micahg could probably fix, but I'm already working on 3 different bugs
[03:53] <asac> so have you tried the versioned abrowser command?
[03:53] <micahg> where?
[03:53] <micahg> I tried abrowser-3.7
[03:53] <asac> k
[03:53] <asac> micahg: 3.7 works here
[03:53] <asac> same help -> about issue
[03:54] <asac> but i can useit otherwise
[03:54] <asac> ii  firefox-3.7            3.7~a1~hg20090907r3228 safe and easy web browser from Mozilla
[03:54] <asac> what type of xml error are you seeing?
[03:55] <micahg> logoCopyright
[03:55] <asac> ok thats the help -> about
[03:55] <asac> so not a regression
[03:55] <asac> everyting else works?
[03:55] <asac> good
[03:55] <micahg> yeah
[04:00] <micahg> asac: you need anything else tonight?
[04:00] <asac> ok merged your branch
[04:00] <asac> firefox-3.6 ;)
[04:00] <micahg> right :)
[04:00] <micahg> I have to get some stuff done at work before I go home
[04:00] <asac> ok. i have to sleep anyway
[04:01] <asac> good night
[04:01] <micahg> night
[04:01] <micahg> if I can't sleep later, I'll work on 3.6 and propose a merge
[04:02] <micahg> was the whitespace ok?
[06:48] <micahg> asac: fta: I'm testing 3.6 daily now
[06:49] <torrancew> hi all, i had a question/potential bug report or two
[06:50] <torrancew> can anyone here help with that?
[06:50] <micahg> sure
[06:51] <torrancew> i'm pushing jaunty, 64 bit, with shiretoko straight out of the default repository
[06:52] <micahg> ok
[06:52] <torrancew> i'm pretty extension-happy, when it comes to ff, and in the past few months, i've finally discovered a few wonderful ones in the way of ubiquity, jetpack, weave
[06:52]  * micahg is glad it's a firefox question :)
[06:52]  * micahg forgot this was the mozilla channel :)
[06:52] <torrancew> all of which work flawlessly on my work machine (macbook pushing os x)
[06:53] <torrancew> on my jaunty box, my biggest problem is weave
[06:53] <torrancew> i am not automatically signed in, and even after signing in, it fails at "Starting Sync Server"
[06:53] <micahg> have you tried with a clean profile and just weave?
[06:54] <torrancew> no i have not
[06:54] <torrancew> good point
[06:54] <torrancew> this other one is almost certainly a bug, however
[06:54] <micahg> you know how to make a clean profile?
[06:54] <torrancew> sure do
[06:54] <micahg> great
[06:54] <torrancew> ubiquity crashes my entire system if i run it while compiz is enabled
[06:54] <torrancew> mouse moves, but absolutely nothing responds
[06:55] <torrancew> Ctrl-Alt-<insert keystroke of your choice here>, mouse clicks, nothing.
[06:55] <micahg> can you enable apport
[06:55] <micahg> it totally freezes?
[06:55] <torrancew> totally
[06:55] <torrancew> nothign short of a reboot will save it
[06:55] <torrancew> and it happens as soon as i open ubiquity
[06:55] <micahg> do you have apport enabled?
[06:55] <torrancew> but if i disable compiz, everything is happy
[06:56] <torrancew> i don't believe i do
[06:56] <torrancew> don't remember, honestly
[06:56] <torrancew> command for apport = ?
[06:56] <micahg> sudo force_start=1 /etc/init.d/apport restart
[06:56] <micahg> this'll enable it once
[06:57] <micahg> then just make the crash happen
[06:57] <micahg> if that doesn't work, we can try an strace
[06:57] <torrancew> kk
[06:57] <torrancew> it'll be a few
[06:58] <torrancew> to be clear, i dont' even have tty access once this has happened....
[06:58] <torrancew> but i may be able to ssh...
[06:58] <torrancew> never tried
[06:58] <micahg> 'k I'll be here for a while
[06:58] <micahg> do you have don't zap enabled?
[07:00] <torrancew> i'm not familiar with it
[07:00] <micahg> jaunty disabled the x reset
[07:00] <micahg> and tty access
[07:00] <micahg> there's a package called dontzap that restores it for jaunty
[07:01] <torrancew> i certainly don't have it
[07:01] <torrancew> but i detest that decision
[07:01] <micahg>  !info dontzap jaunty
[07:01] <torrancew> they're not features i use every day, so this may explain why they've been failing when i need them
[07:02] <torrancew> awesome
[07:02] <torrancew> i just ran into my other complaint (non-mozilla related)
[07:02] <torrancew> my mouse randomly ceases to work
[07:03] <micahg> weird
[07:03] <micahg> are you sure the mouse is good?
[07:03] <torrancew> yeah, 64 bit has been a pain, been trying it since january
[07:03] <torrancew> jaunty made some improvements, but not all of them
[07:03]  * micahg is running 64 bit and has been for 1.5 years
[07:03] <torrancew> yep, been using it with ubuntu for 3ish years now
[07:03] <torrancew> changed batteries
[07:04] <torrancew> tried it in windows partition, mac machine, it's fine
[07:04] <torrancew> certain things make it angry
[07:04] <micahg> ok
[07:04] <torrancew> playing half-life in wine, sometimes package management borks it
[07:04] <torrancew> i've heard loads of 64 bit success stories, and i know one day i'll have mine, but it is not this day
[07:05] <torrancew> what's the arg for profile management in ff?
[07:05] <torrancew> --profilemanager?
[07:05] <micahg> firefox-3.5 -ProfileManager
[07:06] <micahg> try #ubuntu-x for help with your mouse
[07:06] <torrancew> kthnx
[07:07] <torrancew> leaving for a bit - been using chatzilla for irc
[07:07] <torrancew> restarting ff
[07:15] <torrancew> micahg: you still around?
[07:16] <micahg> yep
[07:16] <torrancew> cool
[07:16] <torrancew> well a fresh profile fixed weave
[07:16] <micahg> great
[07:16] <torrancew> Somethign i should have tried already, obviously
[07:17] <torrancew> btw, i know there's a way to run multiple ff instances with different profiles, but don't remember how
[07:17] <torrancew> any tips?
[07:17] <micahg> i don't know if that's supported at this time
[07:17] <torrancew> kk
[07:17] <micahg> with prism you can turn a web app into a desktop app
[07:18] <torrancew> well, i'm about to test (recreate) the ubiquity issue
[07:18] <torrancew> assuming that i lose all functionality, as per usual, what should i do to collect the necessary data, and where should i send it?
[07:19] <torrancew> heh
[07:19] <torrancew> prism has been another problem child of mine
[07:19] <torrancew> actually, i'll fire up my dreaded macbook
[07:19] <torrancew> and irc from it
[07:20] <torrancew> let the record state that though i have all 3 flavors of os's, os x is for work only (i'm a mac consultant), and windows is to scratch the occasional brand-new video game itch
[07:20] <torrancew> :-P
[07:21] <torrancew> brb
[07:22] <torrancew> kk
[07:22] <torrancew> shall the games begin?
[07:23] <micahg> sure
[07:23] <torrancew> also, it saddens me that a single keystroke can cripple my system with compiz enabled
[07:23] <torrancew> alright, it's hosed
[07:23] <torrancew> not even any mouse response
[07:24] <torrancew> how can i leverage this situation into some useful info?
[07:24] <micahg> can you get to a tty?
[07:24] <torrancew> nope
[07:24] <torrancew> trying ssh
[07:24] <micahg> reboot and see if apport shows up?
[07:24] <torrancew> i am ssh'd in
[07:24] <torrancew> if that's any help
[07:24] <micahg> did you enable apport?
[07:25] <torrancew> sure did
[07:25] <torrancew> according to top, X is eating all of my cpu
[07:25] <micahg> find the process id of firefox and kill -11 it
[07:25] <torrancew> which is unlikely, given it's quad core 2.6
[07:25] <micahg> not if there's a memory leak
[07:26] <torrancew> kk
[07:26] <torrancew> killed
[07:26] <micahg> is X back?
[07:27] <torrancew> nope
[07:27] <torrancew> still no physical direct access to machine
[07:27] <torrancew> should i try restarting gdm?
[07:27] <micahg> you can try
[07:27] <torrancew> fail
[07:28] <torrancew> thinks it worked, but no change on screen
[07:29] <micahg> ok
[07:29] <micahg> you can try to stop gdm
[07:29] <torrancew> init doesn't successfully do so
[07:29] <torrancew> again, it think it does
[07:31] <torrancew> kill won't term it either
[07:31] <micahg> kill -9 the X process
[07:32] <torrancew> success at last
[07:32] <torrancew> mouse is gone again, but i've got gui and keyboard back
[07:33] <torrancew> upon login, will apport alert me, assuming all went according to plan?
[07:33] <micahg> maybe
[07:33] <micahg> if not, we can try an stace
[07:33] <micahg> strace
[07:33] <torrancew> no apport alert
[07:33] <micahg> ok
[07:34] <torrancew> times like these, i thank gnome-do for enhancing my keyboard-usability
[07:34] <micahg> try launching firefox with:
[07:34] <micahg> firefox-3.5 -f -eopen 2>&1 | tee ~/strace_ff.log
[07:35] <micahg> that'll record a log in your home directory
[07:35] <torrancew> once more with the error inducing?
[07:35] <micahg> yep
[07:35] <torrancew> done
[07:36] <torrancew> kill -11 ff_pid, right?
[07:37] <micahg> it's frozen?
[07:37] <torrancew> oh yeah
[07:37] <micahg> ok, just go straight for x then
[07:37] <torrancew> again, instantly on Meta-Space
[07:39] <torrancew> strace_ff.log contains 2 lines
[07:39] <torrancew> 1 is a ptr to my foxyproxy settings dir
[07:39] <torrancew> the other is ubiquity related
[07:39] <micahg> just 2 lineS?
[07:40] <torrancew> database table: ubiquity_suggestion_memory already exists
[07:40] <torrancew> yep
[07:40] <micahg> weird
[07:40] <torrancew> story of my life my friend.
[07:42] <torrancew> any good advice before i succumb to the sleep gods?
[07:44] <micahg> you can file a bug in firefox-3.5
[07:45] <torrancew> i've been having the issue, even on 3.0
[07:45] <micahg> well
[07:45] <micahg> not quite sure where the bug is
[07:45] <torrancew> i'm thinking compiz
[07:45] <torrancew> it breaks vnc, as well
[07:45] <micahg> ok
[07:46] <micahg> maybe file a bug with compiz
[07:46] <torrancew> alright
[07:46] <torrancew> thanks for the help man
[07:46] <micahg> np
[07:46] <torrancew> to be clear, kill -9 and kill -11
[07:46] <torrancew> what are the flags doing there?
[07:46] <micahg> -9 is a force quite
[07:46] <micahg> quit
[07:47] <torrancew> right
[07:47] <torrancew> and 11?
[07:47] <micahg> -11 is a SIGSEGV
[07:48] <torrancew> gotcha
[07:48] <torrancew> thanks man
[07:48] <torrancew> later
[08:02] <micahg> asac:  lp:~micahg/firefox/firefox-3.6.head.daily-patch-rebase-20090910
[08:02] <micahg> build is here: https://edge.launchpad.net/~micahg/+archive/mozilla-test
[10:04] <eagles0513875> hey guys
[10:40] <bdrung> hi
[10:51] <andv> eagles0513875, there?
[10:52] <eagles0513875> morning andv and bdrung
[10:52] <andv> eagles0513875, are you under kde?
[10:52] <eagles0513875> ya i am
[10:52] <andv> karmic?
[10:52] <eagles0513875> i can never seem to get used to gnome
[10:52] <eagles0513875> ya in a vm
[10:52] <andv> please
[10:52] <andv> open the terminal
[10:52] <eagles0513875> hold on let me start my vm
[10:52] <andv> and give a sudo apt-get install nicotine
[10:52] <eagles0513875> O_o
[10:52] <eagles0513875> im no drug user :P
[10:52] <andv> lol
[10:53] <andv> it's a package
[10:53] <andv> don't worry
[10:53] <eagles0513875> i know just as the brits say taking the piss
[10:53] <andv> eagles0513875, then launch the application in a console
[10:53] <eagles0513875> k
[10:54] <andv> for doing that just open up the console
[10:54] <andv> and write
[10:54] <andv> nicotine
[10:54] <andv> that's the binary name
[10:55] <eagles0513875> k
[11:04] <eagles0513875> andv: didnt know there was a dependency called python-mutagen lol
[11:06] <eagles0513875> andv: its up
[11:06] <eagles0513875> and running from commandline
[11:06] <andv> does it work?
[11:06] <eagles0513875> what is it anyway a torrent app
[11:06] <andv> yeah, a p2p application
[11:06] <andv> eagles0513875, do you have the package python-glade2 installed?
[11:06] <andv> eagles0513875, if yes, apt-get remove it
[11:07] <eagles0513875> i have gnome desktop installed
[11:07] <eagles0513875> if i remove that package the desktop goes with it it seems
[11:08] <andv> damn, I need to test it without that package
[11:09] <eagles0513875> if you want ill purge ubuntu desktop
[11:09] <eagles0513875> its not a problem
[11:09] <eagles0513875> let me purge it
[11:09] <andv> yeah, then re-install it
[11:09] <andv> when the test is done
[11:09] <andv> you're on a vm so np
[11:09] <eagles0513875> exactly
[11:09] <eagles0513875> lol
[11:09] <eagles0513875> and im not on gnome much anyway
[11:11] <eagles0513875> i get an error
[11:12] <andv> paste it
[11:12] <andv> on pastebin
[11:12] <eagles0513875> www.pastebin.com/m6d51ba61
[11:13] <andv> Unknown post id, it may have expired or been deleted
[11:13] <andv> repaste it
[11:13] <eagles0513875> get rid of the www
[11:13] <andv> paste.debian.net
[11:13] <eagles0513875> pastebin.com/m6d51ba61
[11:13] <eagles0513875> http://
[11:13] <andv> k
[11:13] <andv> works
[11:13] <andv> so the python-glade2 dep is needed
[11:13] <eagles0513875> seems so
[11:14] <eagles0513875> let me install the python-glade2 again and see if it runs
[11:14] <andv> ok
[11:16] <eagles0513875> it works with it
[11:16] <andv> mmm...
[11:17] <andv> eagles0513875, open a bug against nicotine
[11:17] <eagles0513875> what would i say in the bug?
[11:19] <andv> nvm, another guy gonna do it
[11:20] <eagles0513875> andv: willing to test other things if need be
[11:20] <andv> ok for now :)
[11:23] <eagles0513875> :)
[11:24]  * gnomefreak already confused. been here for about a 1minute :(
[11:24] <andv> lol
[11:24] <andv> gnomefreak, I've cleaned up the wiki page
[11:25] <gnomefreak> bdrung: im assuming whom ever built our adblock-plus didnt start with Debians version but made it new and it was never pushed to Debian before synced
[11:25] <asac> how are things going?
[11:25] <andv> gnomefreak, firebug is unable to use mozilla-devscripts 0.15
[11:25] <asac> extensionreview doing progressing?
[11:25] <andv> gnomefreak, so leave it
[11:25] <asac> or came to an end ;)?
[11:25] <gnomefreak> andv: thanks sorry for taking mozgest but i didnt find out you wanted it until i got done with it
[11:25] <bdrung> gnomefreak: yes
[11:26] <gnomefreak> andv: works for me.
[11:26]  * gnomefreak not sure why it wouldnt be able to. do we know "why"?
[11:26] <gnomefreak> asac: i think we are caught up on them
[11:26] <asac> https://wiki.ubuntu.com/MozillaTeam/Karmic/ExtensionReview
[11:26]  * gnomefreak chekcing email so maybe ill know
[11:26] <asac> there are 7 extensions
[11:27] <asac> i think we have about 50 ;)
[11:27] <asac> in the archive
[11:27] <asac> maybe nopt that many, but definitly far more
[11:27] <asac> thatn 7 ;)
[11:27] <andv> gnomefreak, it cleans the .xpi file
[11:27] <andv> gnomefreak, before starting the build
[11:27] <gnomefreak> asac: not sure but we can always add them. not a problem. i wont have time to do much of anything today
[11:27] <asac> ok
[11:28] <asac> eagles0513875: how about reviewing a few more of those today? https://code.edge.launchpad.net/firefox-extensions
[11:28] <andv> gnomefreak, np for mozgest, I was trying to find a debdiff / branch to review
[11:28] <andv> gnomefreak, but wasnt able to find one
[11:28] <gnomefreak> andv: maybe a slight rules adjustment?
[11:28] <andv> brb
[11:28] <asac> maybe fast path greasemonkey
[11:28] <asac> 12:27 < seb128> asac, bug #427789
[11:28] <asac> 12:27 < ubottu> Launchpad bug 427789 in firefox-3.5 ""Not compatible with Firefox 3.5.3" displayed after  installing greasemonkey from firefox" [Undecided,New] https://launchpad.net/bugs/427789
[11:28] <eagles0513875> asac: have my lpi 101 exam soon to og for
[11:28] <gnomefreak> as for chatzilla it can be bmodified when we update to 1.1.18/19 depending on if someone wants to update it. i will be gone for at least 1 week when i leave here.
[11:28] <eagles0513875> FLOOD
[11:28] <asac> eagles0513875: ok
[11:29] <eagles0513875> hehe will do some more this afternoon when i get back
[11:30] <gnomefreak> greasemonkey works fine on 3.5.3 as well as 3.5.4~hg20090907r26344+nobinonly-0ubuntu1~umd2
[11:30] <asac> eagles0513875: thx. every extension reviewed like this is a huge win
[11:30] <asac> ;)
[11:30] <asac> we need a complete list in a week or something
[11:30] <eagles0513875> :) i know asac
[11:30] <gnomefreak> unless i modified mine
[11:30] <asac> otherwise time left in this cycle gets low
[11:30] <eagles0513875> damn i will finish today :) hopefully
[11:30] <asac> to do much
[11:31] <asac> thanks a bunch
[11:31] <eagles0513875> no prob
[11:31] <eagles0513875> im running low on time 2 weeks till i start lectures
[11:31] <gnomefreak> asac: just bump install.rdf i would have to look at mine to tell you but it works on 3.5* and 3.6*
[11:31] <asac> andv: gnomefreak: one of you could fix greasemonkey -> update to latest upstream
[11:32] <asac> gnomefreak: it just broke for seb
[11:32] <asac> he had it bumped
[11:32] <gnomefreak> Installed: 0.8.20090123.1-0ubuntu3~jjv as <<< works for both
[11:32] <asac> yes
[11:32] <gnomefreak> ok i havent triedd it this mornoing yet
[11:32] <gnomefreak> morning
[11:32] <asac> anyway. we have to update the package in the archive
[11:32] <asac> no questions asked ;)
[11:32] <asac> gnomefreak: the 3.5.3 update killed seb
[11:33] <gnomefreak> oh it didnt kill it was working after restart. thinking browser but doesnt say
[11:33] <gnomefreak> sounds more like ubfox than greasemonnkey if browser restart fixed it
[11:34] <gnomefreak> well i will do updates and let you know if mine broke too
[11:34] <gnomefreak> hes using upstreams by the sound of it
[11:35] <gnomefreak> * search for greasemonkey
[11:35] <gnomefreak> * install the xpi
[11:35] <gnomefreak> we use deb
[11:35] <gnomefreak> ask him to see if ours works. mine i know is bumped not sure if official has
[11:36] <asac> gnomefreak: he is now using upstrema
[11:36] <asac> beause the package one broken
[11:36] <asac> gnomefreak: no need to ask him
[11:36] <asac> he is coming from our package
[11:36] <asac> and now is urnning upstream
[11:36] <asac> as that works ;)
[11:37] <eagles0513875> asac:  have you see bug 425695 and the comment gnomefreak made on it
[11:37] <eagles0513875> bug 425695
[11:38] <gnomefreak> asac: ah from what i read it sounded like he was using thiers. he didnt mention ours at all. when updates are done ill let you know if it works here. if not i will assume my changes fixed it but never pushed to archive, i dont remember who changed it last. i had worked on it for one of the mass ext. bugs but noone cared about my changes and did it themselves
[11:38] <gnomefreak> eagles0513875: we were just talking about that.'
[11:38] <eagles0513875> ahh
[11:38] <eagles0513875> my bad
[11:38] <eagles0513875> i was just doing what asac had told me to do
[11:39] <gnomefreak> bdrung: push ours and wait for karmic+1 sync (adblock-plus since we can not sync (manully) or automaticly from sid until next cycle
[11:41] <gnomefreak> there should be atleast one ? in there
[11:42] <bdrung> gnomefreak: if the debian package switch to mozilla-devscripts, we could sync
[11:44] <gnomefreak> bdrung: asac might know better but i think they packaged it on thier own. i don thave a sid chroot nor have time to make one. im only here for a couple of hours today
[11:44] <bdrung> gnomefreak: i know better. :p
[11:45] <gnomefreak> :)
[11:45] <asac> bdrung is the man ;)
[11:47] <gnomefreak> bdrung: congrats on MOTU
[11:48] <bdrung> gnomefreak: thanks
[11:49] <gnomefreak> oh no damn next bugday is firefox-3.5 just thinking the amount of email ill get :(
[11:49] <andv> asac, gnomefreak: was on phone sorry
[11:49] <gnomefreak> andv: np
[11:49] <andv> asac, gnomefreak: did you tell me something to check / do?
[11:50] <gnomefreak> andv: i was thinking just a little adjustment in rules but im not sure why it doesnt work with m-d 15
[11:51] <gnomefreak> 0.15 sorry
[11:51] <gnomefreak> what is latest it works with?
[11:51] <andv> it did not have any m-d B-D
[11:51] <andv> that's why it worked
[11:51] <andv> :)
[11:51] <andv> when I've added it it stopped working
[11:51] <asac> andv: yes. more extension reviews ;) ... in particular updating our greasemonkey to latest upstream
[11:51] <gnomefreak> ah that is a fairly good reason :)
[11:52] <asac> bug 427790
[11:52] <andv> asac, greasemonkey? any problem with it?
[11:52] <asac> see the bug
[11:52] <andv> asac, ubottu is not here
[11:52] <andv> ;)
[11:52] <asac> https://bugs.edge.launchpad.net/bugs/427790
[11:52] <gnomefreak> IIRC greasemonkey was a bit of a mess but i havent touched it in a while
[11:53] <asac> while doing that greasmonkey should be properly moved to new mozilla-devscript packaging imo
[11:53] <asac> e.g. just processed as normal
[11:53] <gnomefreak> it may be down a while seems to be having problems
[11:54] <andv> asac, one question, I have a package which doesnt run on kde cause a missing dep
[11:54] <andv> asac, but it is a GTK2 app
[11:54] <andv> asac, so not really designed for kde
[11:54] <andv> asac, should I add it anyway?
[11:54] <andv> asac, e.g for ppl who wanna have both kde and gnome-desktop installed?
[11:55] <asac> packages always need all the required depends
[11:55] <gnomefreak> +1
[11:55] <andv> k
[11:55] <andv> gonna fix it
[11:55] <andv> eagles0513875, please report the bug
[11:55] <asac> ${shlibs:Depends} should usually do that for you
[11:55] <asac> if its a binary dependency
[11:55] <asac> if there are packages on top for a valid reason they must be added too
[11:55] <asac> especially if the program doesnt work at all without it
[11:56] <andv> asac, yeah, it fails to startup with a python-glade2 missing dep error
[11:57] <asac> whats the error you see?
[11:57] <andv> asac, http://pastebin.com/m6d51ba61
[11:57] <asac> oh its python
[11:57] <asac> yeah
[11:57] <asac> needs to be added to depends
[11:57] <andv> yep, python
[11:57] <andv> ok
[11:58] <asac> if its a package from debian also send the debdiff to them
[11:58] <andv> ok
[11:58] <andv> yeah, it's synced from debian
[11:58] <andv> asac, let me open the bugs
[11:58] <andv> asac, does greasemonkey have some problems?
[11:59] <asac> the package is currently not working at all because of that bug
[11:59] <asac> in ffox 3.5
[11:59] <asac> its "disabled as being incompatible"
[11:59] <asac> just update to latest upstream
[11:59] <asac> that should work
[12:00] <andv> ok
[12:00] <andv> added on todos
[12:00] <asac> thx
[12:00] <andv> fixing this nicotine bug
[12:02] <andv> asac, added: https://bugs.edge.launchpad.net/ubuntu/+source/nicotine/+bug/427796
[12:03] <andv> asac, I found this out while testing a backport to approve
[12:03] <andv> ^^
[12:04] <gnomefreak> asac: seems suse fixed the KDE support. for firefox
[12:05] <andv> gnomefreak, is possible to link a bug to each other
[12:06] <andv> if both of them are into LP?
[12:06] <gnomefreak> andv: what do you mean?
[12:06] <andv> gnomefreak, https://bugs.edge.launchpad.net/jaunty-backports/+bug/409979/+distrotask
[12:06] <andv> gnomefreak, I wanted to link it to a bug which is hosted on LP
[12:09] <gnomefreak> andv: not sure.
[12:09] <andv> looks like I can't
[12:09] <gnomefreak> asac: few things. this is OpenSuse KDE intergrations stuff: http://en.opensuse.org/KDE/FirefoxIntegration
[12:10] <gnomefreak> andv: try in #launchpad
[12:10] <asac> i know about that one
[12:10] <asac> i havent seen the patches
[12:10] <andv> asac, gonna fix greasemonkey this evening / night
[12:10] <gnomefreak> asac: the other thing is please look at: https://bugs.launchpad.net/bugs/422745  last i heard there was no separate alterntives for flash
[12:11] <asac> hopefully they upstream them or mconnor takes care that they don't ship that .... otherwise we will get complains for ages ;)
[12:11] <andv> asac, gonna provide you the package when done, for a review
[12:11] <asac> "opensuse ships kde integration .. why no ubuntu"
[12:12] <gnomefreak> asac: IMHO we should wait for a non hacked version anyway
[12:12] <asac> agreed
[12:13] <gnomefreak> the only thing is last i heard they stopped working on it (or alteast came to an impass)
[12:13] <asac> i think the gnash bug is something we should fix
[12:13] <asac> let me see if i didnt do that yet
[12:14] <gnomefreak> wouldnt it be under the xul* alternatives?
[12:15] <asac> iceape is old style mozilla
[12:15] <asac> they dont look there
[12:15] <asac> but its not really the problem here
[12:15] <asac> the problem is something different
[12:18] <gnomefreak> asac: ok, i was going on the way he put it.   WTF is RTE Player 0.2.354.390 and do we support it?
[12:18] <asac> gnomefreak: fixing it now
[12:19] <gnomefreak> gnash?
[12:19] <asac> yes
[12:19] <gnomefreak> asac: ok
[12:20] <eagles0513875> andv: ? what bug
[12:23] <asac> fixed
[12:23] <asac> uploading
[12:23] <eagles0513875> ok
[12:23] <asac> gnomefreak: uplaoded. in case the guy still has the same bug let me know (or other upgrade errors there)
[12:23] <asac> gnash_0.8.5-0ubuntu3_source.changes:
[12:24] <gnomefreak> asac: i saw a few IIRC. i will not be here for at least until the 21st of this month
[12:24] <asac> leaving today?
[12:25] <gnomefreak> oh well time for smoke email locked up
[12:25] <gnomefreak> asac: yes this moring
[12:25] <gnomefreak> morning even
[12:26] <asac> gnomefreak: enjoy your honeymoon!!!
[12:26] <gnomefreak> asac: thanks i hope to :)
[12:27] <gnomefreak> asac: https://bugs.launchpad.net/bugs/427280
[12:27] <gnomefreak> ok smoke for real this time
[12:27] <asac> jdstrand: pitti needs your input on how to copy stuff from ppa to proposed
[12:31] <gnomefreak> didnt think you could
[12:33] <gnomefreak> ok who is Robert Ancell?
[12:33] <gnomefreak> asac: seems ^^ assigned yelp FTBFS to you. im expected because its XUL related
[12:39] <andv> eagles0513875, I did it np
[12:40] <andv> gnomefreak, have fun during your honeymoon!!!
[12:41] <gnomefreak> andv: thanks :) its going to be a while until that happens first fly to NJ than drive into NYC than sunday fly out to Sicily
[12:41] <andv> gnomefreak, aww, I live in udine (italy)
[12:41] <andv> which is quite a bit far away from sicily
[12:42] <gnomefreak> yep it is i wanted venice but she didnt like that idea but she has family in Sicily to i agreed.
[12:43] <andv> I'm 100 kms from venice
[12:43] <andv> so pretty near
[12:43] <andv> from sicily is around 1200
[12:43] <andv> or more
[12:45] <gnomefreak> that is far
[12:45] <andv> yep
[12:45] <andv> ^^
[12:48] <gnomefreak> bdrung: i just sent email to bug report on adblock i know i should have asked it in here but email is what i am most concerned about atm
[12:49] <gnomefreak> im thinking let wait for new upstream version until we push to Sid the more i think of it
[12:49] <bdrung> earlier it is not possible
[12:51] <gnomefreak> bdrung: for Sid?
[12:51]  * gnomefreak not sure what upstream version is atm
[12:51] <bdrung> its current
[12:52] <gnomefreak> bdrung: ok thanks
[12:52]  * gnomefreak coffee smoke than found out whats wrong with apt'dpkg
[12:57] <gnomefreak> asac: with the umd 3.5 greasemonkey works fine (my modified version)
[12:58] <gnomefreak> this is after todays updates
[12:59] <asac> gnomefreak: whats the problem with just updating to whatever is shipped by addons.mozilla.org?
[13:00] <gnomefreak> asac: i can but IIRC it was a mess but i have enough time to look at it
[13:00] <asac> its ok
[13:00] <asac> someone else can do that
[13:00] <asac> enjoy your honeymoon
[13:01] <asac> send us a pic ;)
[13:01] <bdrung> gnomefreak: i have nothing prepared for debian. first step will be to contact the debian maintainer
[13:01] <asac> sitting below the palm trees ;)
[13:01] <asac> not sure where yo going though
[13:01]  * gnomefreak going to Sicily
[13:03] <gnomefreak> karmic repos are screwedc up. its tell me gnome-games-common and others WARNING: The following packages cannot be authenticated! i dont have an ppa for them and Get:1 http://gb.archive.ubuntu.com karmic/main libempathy-gtk-common 2.27.92-0ubuntu2 [444kB] is where its getting them from
[13:03] <asac> thats not nice
[13:03] <asac> i dont know what the reason could be
[13:03] <asac> at best dont upgrade it
[13:03] <asac> try a different mirror
[13:03] <asac> maybe your mirror has bad bits/bytes
[13:04] <gnomefreak> http://paste.ubuntu.com/269115/
[13:04]  * asac listens to "Aces High" ... hasnt heard that for 10 years or so ;)
[13:04] <asac> gnomefreak: dont install
[13:04] <asac> use different mirror
[13:04] <gnomefreak> asac: ok
[13:06] <gnomefreak> trying it.*
[13:08] <gnomefreak> aces high by Iorn Maiden?
[13:08] <asac> yeah!!
[13:08] <gnomefreak> Iron even
[13:11]  * gnomefreak loves them been listening for many years :)
[13:11] <gnomefreak> 2nd metal band i got into (after Metallica)
[13:12] <gnomefreak> andv: are your mirros *it.*?
[13:12] <gnomefreak> mirror even
[13:12] <andv> yes
[13:13] <gnomefreak> im getting a 404 on all of them
[13:13] <gnomefreak> Err http://it.archive.ubuntu.com karmic/main gstreamer0.10-alsa 0.10.24-2       404 Not Found [IP: <IP_ADDRESS> 80]
[13:14] <gnomefreak> update works fine but downloading packages i get the 404
[13:15] <asac> gnomefreak: use archive.ubuntu.com
[13:15] <asac> no language variant
[13:16] <gnomefreak> k that will give me us archive though at least as i understand it it will automaticly get from closest lang.
[13:17] <gnomefreak> us seems to work for once
[13:17] <asac> i dont think so
[13:17] <gnomefreak> ubottu: hi
[13:17] <asac> otherwise just run apt-get update in 1hour on your gb mirror and hope that its fixed
[13:19] <gnomefreak> us is working atm i will cange toi nothing when its done
[13:20] <asac> hehe
[13:20] <asac> ubottu: any new features?
[13:20] <asac> or were you just sick?`
[13:20] <asac> !now
[13:20] <asac> @now
[13:20] <asac> !time
[13:20] <asac> @time
[13:20] <gnomefreak> he crashed and came back crashes again
[13:20] <asac> i want time back
[13:20] <gnomefreak> now back to mormal i hope
[13:24] <gnomefreak> em:maxVersion>3.1b2</em:maxVersion>   needs to be fixed :) that is upstream version. if seb is using upstream and it works im suprized
[13:25] <gnomefreak> version 0.8.20090123.1-fx
[13:26] <gnomefreak> that is latest upstream version as i have in PPA
[13:26] <gnomefreak> no newer version on addons.firefox
[13:26] <gnomefreak> ah forgot (greasemonkey
[13:26] <gnomefreak> 0
[13:27] <andv> asac, are you sure greasemonkey requires a new upstream release?
[13:27] <andv> asac, is greasemonkey-0.8.20090123.1-fx latest?
[13:27] <andv> asac, in archives we have greasemonkey-0.8.20090123.1
[13:27] <asac> andv: i am sure that the upstream .xpi is different from our .upstream
[13:28] <asac> at least the install.rdf is different
[13:28]  * gnomefreak wonders why no newer version. asac tell him to try the version in my PPA sinces it is working here
[13:28] <gnomefreak> andv: it cant
[13:28] <gnomefreak> newest version is in my PPA with fixed install.rdf
[13:28] <gnomefreak> asac: nope
[13:28] <andv> gnomefreak, there is no new upstream release
[13:28] <gnomefreak> i was just looking at it. see pasted lines from install.rdf
[13:28] <andv> Version  	0.8.20090123.1
[13:29] <andv> is the same we have in archive
[13:29] <gnomefreak> .:08:24:38:. <      gnomefreak > em:maxVersion>3.1b2</em:maxVersion>   needs to  be fixed :) that is upstream version. if seb  is using upstream and it works im suprized
[13:29] <andv> from what https://addons.mozilla.org/en-US/firefox/addon/748 says
[13:29] <asac> folkd
[13:29] <asac> folks
[13:29] <asac> just take the upstream .xpi
[13:29] <asac> diff it with our .upstream branch
[13:29] <asac> if its just the install.rdf then we want to just take that change "as new upstream" ;)
[13:29] <asac> no rocket science
[13:30] <asac> but you never know what greasemonkey folks are doing
[13:30] <asac> at least they bumped the maxVersion there
[13:30] <andv> asac, found out
[13:30] <asac> good ;)
[13:30] <andv> asac, why it does not work on ffox3.5
[13:31] <andv> asac, the max version is set to: <em:maxVersion>3.1b2</em:maxVersion>
[13:31] <andv> asac, that should be fixed
[13:31] <gnomefreak> andv: its 3.1pre in upstream not sure what ours has. im looking in my PPA for it but i think i lost it
[13:32] <gnomefreak> that will work using 3.6* IIRC
[13:32] <andv> gnomefreak, where that branch is hosted?
[13:33] <gnomefreak> easy enough to fix. andv it was removed from my PPA or atleast gone atm let me see if i still have branch
[13:33] <gnomefreak> https://code.edge.launchpad.net/~gnomefreak/firefox-extensions/greasemonkey.ubuntu andv
[13:33] <gnomefreak> and mine works great :)
[13:34] <andv> gnomefreak, the fix is just to adjust maxversion
[13:34] <gnomefreak> if someone feels like pushing feel free :) testing for a long time now :)
[13:34] <gnomefreak> andv: yes
[13:34] <gnomefreak> and deps (new changes we need to make
[13:34] <gnomefreak> )*
[13:34] <andv> gnomefreak, if asac is ok with it, I will review / push it
[13:34] <andv> gnomefreak, do it have new m-d stuff?
[13:34] <gnomefreak> andv: let me make the xpi changes first
[13:34] <andv> k
[13:34] <gnomefreak> andv: nope this was before that
[13:35] <andv> gnomefreak, update m-d stuff too
[13:35]  * gnomefreak working on it should be done soon. is ther ea xpi bug on it?
[13:35] <andv> gnomefreak, Depends: firefox | abrowser | firefox-3.5 is wrong, that's why I said that to you
[13:35] <andv> gnomefreak, yes
[13:35] <andv> gnomefreak, there is a bug
[13:35] <andv> wait
[13:36] <andv> gnomefreak, https://bugs.edge.launchpad.net/ubuntu/+source/greasemonkey/+bug/427790
[13:37] <gnomefreak> sebs bug should be a dupe of that. eagles0513875 you never set up an xpi bug for greasemonkey but doesnt matter too much
[13:37] <andv> gnomefreak, when done, update the wiki page as well
[13:38] <andv> gnomefreak, I've added some new fields as well
[13:38] <gnomefreak> andv: ok thanks. please add this one if not already
[13:39] <andv> k
[13:39] <gnomefreak> asac: do you have sebs bug handy?
[13:40] <asac> what do you want?
[13:40] <gnomefreak> i have it
[13:40] <andv> gnomefreak, bug assigned to you
[13:40] <gnomefreak> andv: thanks
[13:40] <andv> np
[13:41] <asac> please dont ask him questions ;)
[13:41] <asac> he is already busy enough
[13:41] <asac> the bug is as it is
[13:41] <asac> just update to latest xpi from upstream
[13:41] <asac> if thats just install.rdf then thats how it is
[13:42] <asac> ah ok duped
[13:42] <asac> good
[13:42] <asac> gnomefreak: no
[13:42] <asac> thats a different bug
[13:42] <gnomefreak> asac: i didnt plan on it
[13:42] <asac> thats not fun
[13:43] <asac> i told seb to file those two separately
[13:43] <asac> dont dupe
[13:43] <gnomefreak> it is same bug
[13:43] <asac> it is not
[13:43] <asac> only do bug 427790
[13:43] <asac> the other bug is something else
[13:43] <gnomefreak> asac: and his fails to work on it due to compat.
[13:44] <gnomefreak> how is that different (same install.rdf changes
[13:44] <asac> gnomefreak: dont bother with that. if you read the bug carefully you will see that its different
[13:44] <asac> bug 427789
[13:44] <asac> thats != 427790
[13:44] <gnomefreak> i just did
[13:45] <asac> yes. then you didnt see the difference
[13:45] <gnomefreak> i didint at first
[13:45] <asac> k
[13:49] <gnomefreak> !info greasemonkey
[13:49] <gnomefreak> just making sure
[13:57]  * asac lunch
[13:58] <gnomefreak> andv: pushing to m-e-d branches
[13:59] <gnomefreak> andv: waiting for it to populate on https://code.edge.launchpad.net/~mozilla-extensions-dev/firefox-extensions/greasemonkey.ubuntu fixed 2 bugs
[14:00] <andv> gnomefreak, did you fix m-d stuff too?
[14:00] <gnomefreak> andv: yes
[14:01] <gnomefreak> andv: right now adding to the wiki
[14:01] <andv> gnomefreak, did you add reference to the wiki into the changelog?
[14:01] <andv> like I did with ubuntu-it-menu
[14:02] <andv> gnomefreak, check ubuntu-it-menu changelog for an example
[14:03] <gnomefreak> andv: no but i will thats easy enough
[14:03] <andv> yep
[14:03] <andv> if not i gonna do it np
[14:04] <gnomefreak> andv: ok please do. im trying to catch up on everything. we need the wiki updated later for other extensions but maybe eagles0513875 was going to do that?
[14:04] <andv> gnomefreak, would be really great to have the wiki page updated with some other extensions
[14:04] <andv> we have 8 now
[14:05] <andv> and as asac said we have more than 40
[14:05] <gnomefreak> andv: yep. but right now im trying to figure this out :)
[14:05] <andv> so please eagles0513875 please add them
[14:05] <andv> add them properly
[14:05] <andv> with right links et on
[14:07] <gnomefreak> shit dont touch it now
[14:10] <gnomefreak> oh wtf
[14:11] <andv> please don't tell it's fucke** now
[14:12] <gnomefreak> i cant seem to get the table to line up for some reason. w
[14:12] <gnomefreak> -w
[14:12] <gnomefreak> andv: why! can you look at it while i go smoke please?
[14:15] <andv> gnomefreak, fixed
[14:16] <andv> gnomefreak, look now
[14:16] <gnomefreak> andv: looking what did you do to fix it?
[14:16] <andv> some white spaces randomly added
[14:17] <gnomefreak> well little off i can fix this part
[14:17] <andv> gnomefreak, fix the bug
[14:17] <andv> gnomefreak, and move it to the right column
[14:17] <gnomefreak> i am
[14:17] <andv> grat
[14:17] <andv> great
[14:21] <gnomefreak> cant im missing something but one minute
[14:22] <andv> just remove the (./) placed in wrong column and replace with the bug url
[14:23] <gnomefreak> nope i end up with it like the table was last time
[14:24] <andv> check for free spaces then
[14:24] <gnomefreak> damnit
[14:27] <gnomefreak> nope that didnt work either
[14:27] <gnomefreak> hmmmm
[14:30] <gnomefreak> ok wtf if i remove the extra (./) and fix spaces it still ends up on another line
[14:30] <andv> a | should be removed somewhere
[14:31] <gnomefreak> fixed
[14:31] <andv> great
[14:31] <gnomefreak> andv: thanks
[14:32] <andv> np
[14:32] <gnomefreak> wikis are still a pain in the ass
[14:32] <andv> gnomefreak, is the branch ready?
[14:32] <gnomefreak> oh crap i think so but one sec
[14:32] <andv> did you update what asac said us?
[14:32] <gnomefreak> ok let me find out what you wanted me to do unless you already did it?
[14:33] <andv> gnomefreak, nope, im leaving
[14:33] <andv> check ubuntu-it-menu changelog for an example
[14:33] <gnomefreak> andv: ok ill look
[14:33] <andv> gnomefreak, then drop me an email with mozgest branch to review / push
[14:33] <gnomefreak> andv: ok
[14:33] <andv> and greasemonkey branch to review / push
[14:34] <gnomefreak> andv: where did you push ubuntu-it-menu to? i thought it was this but i dont see it
[14:35] <gnomefreak> its not https://code.edge.launchpad.net/~mozilla-extensions-dev
[14:35] <andv> gnomefreak, ~ubuntu-dev
[14:36] <gnomefreak> ah ok
[14:45] <gnomefreak> ok updating the branch. pushed waiting for LP to update
[14:45] <gnomefreak> we should add a few things to the bug reports. i will add to wiki i think
[14:46] <andv> ok
[14:46] <andv> as I said drop me an email
[14:46] <andv> I'll catch it
[14:46] <andv> later
[14:47]  * andv off
[14:50] <gnomefreak> asac: please see wiki: https://wiki.ubuntu.com/MozillaTeam/Karmic/ExtensionReview i added a few things to the Checklist section. maybe add an example or a link to example. but i have a few things to do and im gone :)
[14:51] <gnomefreak> example https://code.edge.launchpad.net/~mozilla-extensions-dev/firefox-extensions/greasemonkey.ubuntu but it will be merged so we need a stable place as example
[14:54] <eagles0513875> WOOOOHOOO PASSED MY linux exam part one
[14:56] <gnomefreak> eagles0513875: congrats. you should have email about the extension wiki. we need to add more extensions to the list ( alot more)
[14:57] <eagles0513875> ok
[14:57] <eagles0513875> im under pressure on 2 fronts
[14:58] <gnomefreak> chatzilla cant be done until someone packages seamonkey-1.1.18. i wont be able to upgrade it this month and it needs to be done soonish. some patches issues on nss nspr
[14:58] <eagles0513875> gnomefreak: i could probably package if need be but knowing my luck i would have to try it a few times before its right
[14:59] <gnomefreak> eagles0513875: the nss/nspr is not that of an easy fix. and mips patches need to be dropped as well.
[15:00] <eagles0513875> ahhh ok not a good place for me to start then
[15:02] <gnomefreak> eagles0513875: no not on that. tbird-3 lost tool bar buttons :(
[15:03] <eagles0513875> :(
[15:04] <gnomefreak> i would say best to start with small fixes ojn a package and build it than (just a command unless something major changed
[15:04] <eagles0513875> i need to get karmic up and running on my laptop after i upgrade to 64bit snow leopard cuz right now i cannot install it what so ever
[15:05] <eagles0513875> i woudl upgrade but was told for testing purposes its best to do a clean install
[15:13] <gnomefreak> !info firefox-3.0
[15:18] <gnomefreak> !info firefox-3.0 jaunty
[15:20] <jdstrand> asac: not sure what the problem is, but if I use ubuntu-bug I get: http://paste.ubuntu.com/269195/
[15:28] <gnomefreak> isnt there an open bug on the Xwindow crashes?
[15:28] <gnomefreak> although i dont remember the 607
[15:28] <eagles0513875> btw asac and gnomefreak will work on the extensions this weekend after the funeral tomorrow
[15:29] <asac> jdstrand: yes. thats a known issue i have a bandaid fix for
[15:29] <gnomefreak> eagles0513875: thats fine i will be gone for a week or more
[15:29] <asac> and there is a fix landed on trunk ... it seems to be a race
[15:29] <asac> jdstrand: bug 401055
[15:30] <eagles0513875> asac:  bandaid is good but question is how long will it be before it falls off
[15:30] <gnomefreak> when truck gets fix we will remove bandaid
[15:30] <asac> i would think you have no real qualified opinion on that one :)
[15:30] <asac> gnomefreak is right ;)
[15:30] <jdstrand> asac: thanks
[15:30] <asac> we havent even added a bandaid to ffox 3.5 ... just for that reason: dont hide
[15:32] <gnomefreak> ok guys thats it for me. we are bringing her laptop so i will have some access to email. asac feel free to update SM-1.1.18 with the nss/nspr. iceape from Mike should have the fixes already im guessing just grab patches but i havent had time to look at it or work on it since mike fixed it in Debian
[15:33] <asac> gnomefreak: great. enjoy your holiday. see you back in best shape and fully recharged
[15:33] <asac> 2 weeks you are back?
[15:33] <asac> cu then!
[15:33] <asac> ok folks i was told by boss to take off the rest of the day
[15:34] <asac> so before i get fired i am sliding to weekend mode ;)
[15:36] <gnomefreak> asac: give or take 1 week-whenever we decide to come back. she has off til oct 4th
[15:36] <gnomefreak> asac: have a great weekend.
[15:36] <asac> gnomefreak: where are you going?
[15:37] <gnomefreak> asac: NJ>NYC>NJ>Sicily all this weekend :)
[15:37] <asac> Sicily?
[15:37] <asac> isnt that in italy ;)
[15:38] <asac> wherever. if you are going to a beach or something send a pic ;)
[15:38] <asac> ;)
[15:38] <asac> cu then
[15:40] <gnomefreak> asac: its attached to most southern end. its a different contrey, has its own capital even :)
[15:41] <gnomefreak> i will take pics if we leave hotel ;)
[15:41] <gnomefreak> ok emails done. gone to get ready for airport
[16:01] <fta2> 17h, let's see if it's green today ;)
[16:59] <micahg> ping asac re ff3.6.daily
[17:02] <micahg> asac: I wasn't sure about the things that you mentioned in the merge proposals
[17:02] <micahg> I will do that properly in the future
[17:03] <micahg> I was wondering if that was for trunk only
[17:34] <mconnor> asac: I'm doing what now?
[17:37] <[reed]> mconnor: making sure openSUSE doesn't ship KDE integration patches with Firefox
[17:37] <[reed]> http://en.opensuse.org/KDE/FirefoxIntegration
[17:37] <[reed]> (as in, make sure they upstream the patches)
[17:38] <mconnor> man
[17:38] <mconnor> that's So Not My Job
[17:38] <[reed]> (just repeating what asac/gnomefreak were saying)
[17:39] <mconnor> yeah
[17:39] <mconnor> relayed to appropriate people
[17:40] <[reed]> it looks like an add-on
[17:40] <[reed]> trying to find where the code is now
[17:46] <[reed]> http://www.youtube.com/watch?v=Pyp5bX_NV6k
[17:46] <[reed]> youtube video of it
[17:47] <[reed]> http://gitorious.org/firefox-kde-opensuse/firefox-kde-opensuse/trees/master
[19:23] <fta> micahg, asac: http://launchpadlibrarian.net/31663504/buildlog_ubuntu-jaunty-i386.firefox-3.7_3.7~a1~hg20090911r32412%2Bnobinonly-0ubuntu1~umd1~jaunty_FAILEDTOBUILD.txt.gz
[19:24] <micahg> ugh
[19:24] <micahg> that's a new problem :)
[19:28] <micahg> I'll see what I can do
[19:48] <micahg> fta: I'm testing now
[19:48] <micahg> it's jsut a rebase
[20:10] <micahg> fta: I'm waiting for the test build on LP
[20:18] <micahg> fta: 25 minutes till the test build starts
[21:08] <BUGabundo> guud evening kids
[21:08] <BUGabundo> asac: NM / MM still broken on boot :)
[21:28] <micahg> fta: build succesful and tested
[21:28] <micahg> branch is here: https://code.edge.launchpad.net/~micahg/firefox/firefox-3.7.head.daily-patch-rebase-20090911/+merge/11626
[21:29] <micahg> ping asac ^^^
[21:30]  * BUGabundo stupid 3G
[21:33]  * micahg guesses no one is around to fix the dailies
[21:33] <micahg> hi BUGabundo
[21:33] <BUGabundo> hey micahg