[05:58] <micahg> debfx: is there a version of firefox-kde-support yet for 4.0?
[09:38] <debfx> micahg: there are no changes necessary
[09:38] <debfx> the current firefox-kde-support package works fine with firefox 4.0
[16:00] <micahg> debfx: k, thanks, sorry I didn't have a chance to merge your changes yet, I'll get to it over the weekend
[19:46] <micahg> chrisccoulson: good news, TB 3.1.5 seems pretty stable
[19:47] <micahg> chrisccoulson: I just realized that when I've been bumping nss/nspr, I haven't been updating debian/control
[19:47] <chrisccoulson> micahg - i wouldn't worry too much about that
[19:47] <micahg> which I guess isn't an issue since if it's not met, it should use in source
[19:48] <chrisccoulson> yeah, that's fine
[19:49] <micahg> chrisccoulson: After UDS, I think I'll set up a blog so I can blog about team topics
[19:50] <chrisccoulson> i keep thinking about that, but then i'd probably struggle to get people to follow it ;)
[19:50] <micahg> chrisccoulson: you can add it to the planet
[19:50] <chrisccoulson> yeah, that's true i suppose
[19:55] <fta> dpm, i think i will split my translators notes
[19:56] <fta> dpm, put the ID on one side, and the rest on the other (#. vs #: or the opposite) but i'm not sure which is which in LP
[19:58] <dpm> fta, I think it's a great idea, it's less clutter for translators. It should go like this:
[19:58] <dpm> #. comments
[19:58] <dpm> #: IDs
[19:59] <fta> that would mean 1 line of #: and several of #.
[20:01] <fta> too bad lp doesn't <pre> the #:
[20:01] <fta> i mean #.
[20:07] <dpm> fta, I'm not sure I follow, is there a problem with several #. lines?
[20:08] <fta> dpm, yep, everything ends up in 1 single line, it's just ugly and difficult to read
[20:10] <dpm> fta, would it help if you would wrap the #. comments in several #. lines (or perhaps you do that already?)?
[20:13] <fta> dpm, http://paste.ubuntu.com/508224/
[20:14] <dpm> fta, so you are saying that you are importing this and the #. comments all end up in one line?
[20:16] <dpm> fta, btw, I don't think it matters much, but generally #. comments go on top of #: source locations (the opposite of the pasted bit of pot file you've shown me)
[20:16] <fta> dpm, yes, told danilos already, he said he meant to look nice but missed that case and i should just go and fix it
[20:16] <fta> it looks like this: http://paste.ubuntu.com/508229/
[20:17] <fta> can't screenshot, he removed everything, the page is empty now
[20:17] <dpm> fta, that's fine, I understand it from the pastebin
[20:18] <dpm> ugh, it looks a bit ugly, but if that's the way it is now in LP, so be it
[20:18] <fta> it's 1 line patch in lp i assume (just add <pre> </pre>)
[20:19] <fta> if i knew where to look, i'd do it
[20:19] <dpm> fta, do you know if there is a bug for it alredy?
[20:19] <fta> i don't think there's one
[20:20] <dpm> fta, if that helps (unless you haven't looked already), here's more info on Launchpad Translations hacking: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions/LaunchpadTranslationsUnderTheHood
[20:20] <dpm> https://dev.launchpad.net/Hacking
[20:21] <dpm> fta, danilo is away tomorrow, but henninge is a LP Translations hacker and will be there. He might be able to tell you where to look at
[20:22] <fta> i can probably find it with a grep ;)
[20:23] <dpm> if you don't mind downloading 600 MB worth of LP code + deps ;)
[20:26] <fta> already did it once (wanted to package it) but gave up because it's not ready
[20:27] <fta> never will, they don't want it to be packaged
[20:27]  * micahg wanted to package it as well
[20:31] <fta> micahg, and? how far did you go?
[20:47] <micahg> fta: filed a bug :)
[20:47] <fta> micahg, won't fix? ;)
[20:48] <micahg> fta: well, did they explicitely say they don't want it packaged?
[20:48] <micahg> I know they don't consider it a priority
[20:48] <fta> micahg, yes, to avoid splitting the community or something like that
[23:55] <micahg> chrisccoulson: simple seamonkey crash fix that I couldn't do: https://bug522635.bugzilla.mozilla.org/attachment.cgi?id=481492


[05:30] <Dooleyjlt> Hello, I was going to ask about update manager asking about the original install medium and I suddenly remembered that there is a setting for that.  Strange thing is when I inserted the original install flash drive that I installed from about 4 days ago it would not recognize it and kept asking for the install cd and I installed it from the flash drive in the first place. all fine now but any ideas as to why not recognizing
[05:30] <Dooleyjlt> the install media? or is it when it asks for the CD it actually wants physical media?
[05:37] <diogenes_> Dooleyjlt, you need to disable the cd repository in software & updates or to comment it out in /etc/apt/sources.list
[05:51] <Dooleyjlt> I did, I remembered after just a few minutes, I was just wondering why it wouldn't recognize the mounted flashdrive I installed it from? just a glitch where it actually looks for the physical disk?
[05:51] <Dooleyjlt> I thank you very much though
[05:59] <Dooleyjlt> good night/morning/day to all I am outta here


[12:06] <abentley> lifeless: So you're saying lines are evil?
[12:09] <lifeless> abentley: I'm saying there is a significant cost in changing representations (outside of C ?) and that we probably want to really aim for one representation end to end at some point
[12:10] <lifeless> oh right ;)
[12:11] <abentley> I agree that end-to-end is a useful goal, but it's hard to imagine how to reconcile that with delta compression.
[12:12] <lifeless> hg seem to delta on bytes
[12:12] <abentley> I suppose binary delta compression could work.
[12:13] <lifeless> the C library they wrote does a line split without copying
[12:13] <lifeless> or something
[12:13] <lifeless> certainly they don't seem to do splitlines() during commit
[12:13] <lifeless> I have pack commit at 3.5x hg commit, I'm trying to pull it down to < 2x
[12:15] <ddaa> is the "atexit.register(_rmtree_temp_dir, root)" in TestCaseWithMemoryTransport still present in current bzr?
[12:15] <ddaa> it's causing pain with the launchpad test suite
[12:16] <ddaa> generally, please do not use atexit for test suite cleanup... it's gross
[12:16] <lifeless> I don't recall a patch removing that anytime recently
[12:16] <lifeless> mind you I don't recall putting that in ;)
[12:16] <ddaa> lifeless: I know you have better taste that that, I was broadcasting
[12:17] <abentley> To answer your question "whats the difference between [get_matching_blocks output]  and our deltas today", get_matching_blocks doesn't produce a delta, just match regions.  Knit deltas can't directly produce get_matching_blocks output (but if you have the fulltexts, then they can accelerate that).  Multiparent deltas with a single parent can produce get_matching_blocks output, but with multiple parents, they can't.
[12:18] <lifeless> get_matching_blocks is whitespace-ignoring specific right ?
[12:18] <abentley> No, it's generic.  It's what we use for everything.
[12:19] <abentley> knit deltas, annotation, diff.
[12:19] <lifeless> if we implement diff -w
[12:19] <lifeless> or annotate -w
[12:19] <lifeless> -w ignores whitespace so "    foo = 'bar' "   and "    foo = 'bar'" are considered to match
[12:21] <abentley> I'm not quite sure what you're asking, but having pre-calculated get_matching_blocks output would allow us to dramatically reduce the regions we compare for arbitrary diffs.
[12:22] <abentley> Or annotate, for that matter.
[12:22] <lifeless> presumably via composition of these regions
[12:22] <abentley> Yes.
[12:23] <lifeless> I'll think about this some
[12:24] <abentley> It seems like we may have over-optimized "annotate".
[12:24] <lifeless> I think we should be able to get diff performance up to where hg have it on arbitrary texts before we implement caching.
[12:24] <lifeless> annotate - possibly yes
[12:25] <abentley> While it's nice to be fast, it doesn't have to be as fast as fulltext access.
[12:26] <abentley> And for annotate merge, you don't need annotations for most lines, and you don't need precise annotations for lines that were introduced by common ancestors.
[12:26] <lifeless> yup
[12:28] <abentley> So possibly storing get_matching_blocks regions is better than caching annotations.
[12:30] <lifeless> it would be less data for sure
[12:31] <lifeless> do we have an uncached annotate facility still ?
[12:31] <lifeless> or do I have to recreate it to disable the annotation cache in packs?
[12:33] <abentley> I thought only bzrtools did that, until we got weaves.
[12:33] <abentley> Anyhow, I do have the bzrtools code, but I bet it's pretty dated.
[12:34] <abentley> There is the reannotate code, though.
[12:34] <abentley> That should do the trick.
[12:35] <abentley> It annotates from parents to children, not from children to parents.
[12:37] <lifeless> so full history ?
[12:37] <lifeless> anyhow, we're going to need a cacheless annotate routine somewhere
[12:37] <abentley> Well, if you had an annotated fulltext of an ancestor, it could work from that.
[12:38] <abentley> And for merge purposes, you could start at a common ancestor.
[12:39] <abentley> But if you want the full annotation with no cache, you have to go through history anyway.
[12:41] <lifeless> yes full history all sides
[12:42] <lifeless> with the potential to stop early if we go from child -> parent
[12:57] <BryceLeo> anyone had a problem installing the new bzr via synaptic in ubuntu?
[12:58] <BryceLeo> feisty fawn if it matters
[12:59] <abentley> Well, there was a problem reported this morning, but I'm unclear whether it applies to Feisty.
[01:00] <abentley> Does it say "error in control file: `Files' value not specified"?
[01:02] <BryceLeo> yup
[01:02] <BryceLeo> i think i've got a fix
[01:02] <BryceLeo> yup it's super simple
[01:03] <BryceLeo> let me pasebin it right quick
[01:04] <lifeless> BryceLeo: fixed packages are already building
[01:10] <BryceLeo> awesome
[01:10] <BryceLeo> well i've got a patch if anyone wants it now
[01:11] <BryceLeo> haha now if only you guys could fix why the python binding for gtkmozembed crashes with https
[01:12] <lifeless> hahah
[01:12] <lifeless> just figured out why GzipFile is _so_ slow
[01:12] <lifeless> it overrides the default compression level for zlib
[01:12] <lifeless> GzipFile('foo', 'wb') == gzip -9
[01:12] <BryceLeo> whoops
[01:13] <lifeless> q: why is bzr slow
[01:13] <lifeless> a: stdlib fuckage
[01:13] <Peng> Don't the docs say it uses the zlib default?
[01:14] <lifeless> it does; but if you aren't the one choosing to use a tool, do you read the docstring?
[01:14] <lifeless> its surprising for library bindings to differ between languages
[01:15] <Peng> Oh, GzipFile does say it defaults to 9.
[01:15] <abentley> That doesn't explain why it's so slow for decompression, though.
[01:15] <lifeless> I haven't looked into that yet
[01:16] <lifeless> but changing it to the default, we're only 2 seconds slower - 38 vs 36
[01:17] <abentley> Slower than raw zlib?
[01:22] <lifeless> slower than 'gzip -c mozilla.tar > /dev/null'
[01:23] <abentley> Ah, cool.
[01:24] <lifeless> so I'm just testing the change in data size
[01:30] <abentley> Well, I'm kind of at loose ends.  If there's some packs work I can do without sync problems, I'd be happy to join in.
[01:31] <lifeless> ahha 127MB
[01:31] <lifeless> this patch going up for review :)
[01:31] <lifeless> abentley: getting the ability to annotate without cached annotations seems to save nearly 1/5 of our current commit time
[01:32] <lifeless> abentley: so that would be a good thing, and seems to be unlikely to collide
[01:35] <abentley> 127MB is the size change?
[01:39] <abentley> lifeless: btw, please review my reconcile change.
[01:40] <abentley> Also, does your latest in "http://people.ubuntu.com/%7Erobertc/pack-repository.knits/" have no annotation?
[01:42] <lifeless> no, I only played with that locally
[01:42] <lifeless> 127M is the new repo size
[01:42] <lifeless> the old repo size was 140M
[01:42] <lifeless> so its actually smaller ;)
[01:43] <abentley> That makes no sense...
[01:44] <abentley> I'm realizing that child->parent order also matches our expected data ordering better.
[01:44] <lifeless> [01:44] <lifeless> --- bzrlib/repofmt/pack_repo.py 2007-08-28 02:18:13 +0000
[01:44] <lifeless> +++ bzrlib/repofmt/pack_repo.py 2007-08-30 03:44:59 +0000
[01:44] <lifeless> @@ -1035,7 +1035,7 @@
[01:44] <lifeless>              self.weavestore._file_mode,
[01:44] <lifeless>              index=knit_index,
[01:44] <lifeless>              access_method=knit_access,
[01:44] <lifeless> -            **self.weavestore._versionedfile_kwargs)
[01:44] <lifeless> +            factory=knit.KnitPlainFactory())
[01:44] <lifeless> thats the patch to drop annotations - I haven't committed because I expect it to break tests left, right and centre
[01:45] <lifeless> your updated reconcile patch - yes, I will review it
[01:46] <abentley> Okay.  I will go break some tests >:)
[01:48] <abentley> !?! "bzr selftest annotate" and nothing breaks.
[01:49] <abentley> I don't think you're intelligent, ubotu, believe me.
[01:51] <fullermd> Man, this channel is never satisfied.  Tests don't pass, people complain.  Tests pass, people complain...
[01:51] <abentley> Why are you guys so intent on changing iter_changes?  The only case where it's expensive to determine whether a file has changed is when the stat value has changed, but the st_size has not.
[01:55] <lifeless> abentley: the annotate tests are probably not strict enough then; at the repo level the API call to the knit will work
[01:55] <lifeless> abentley: but it will annotate the entire file as changed in the last commit :(
[01:56] <abentley> Sounds pretty nuts.
[01:56] <lifeless> abentley: so that when we hit that case, we don't end up e.g. sha1summing an entire iso twice
[01:56] <lifeless> abentley: yeah, supporting annotate() on knits that don't have annotation data in them *is* nuts IMO but its what the original interface offered.
[02:00] <lifeless> bbiab
[02:07] <lifeless> poolie: quick call ?
[02:08] <poolie> sure
[02:33] <spiv> abentley, lifeless: what's the status of the bad parent references work?  I currently have a patch that's marked "resubmit" because it doesn't take broken history like bzr.dev's into account.
[02:34] <abentley> spiv: robert's said he'll review my new patch.
[02:34] <spiv> Ah good.  Are you still of the opinion that smart server fetching should compensate for this?
[02:36] <abentley> I think it should not fail silently.  It can fail noisily or succeed silently-- your pick.
[02:37] <spiv> i.e. pulling from a broken repo should not silenty break my repo?
[02:37] <abentley> Yes.
[02:37] <spiv> Makes sense.
[02:42] <lifeless> spiv: there is a flag on the repository indicating it can suffer from this form of corruption
[02:43] <lifeless> spiv: so if it is set you'll need to check that the knit parents match the last modified in the parent's ancestries.
[02:44] <lifeless> this is expensive, so we may want to do a format bump just to ensure that we have a format without the flag set
[02:44] <lifeless> abentley: ^ does this make sense to you ?
[02:44] <lifeless> spiv: wanna quick chat ?
[02:44] <spiv> lifeless: yeah, that'd be good
[02:44] <lifeless> k, I'll ring
[02:44] <spiv> ta
[02:46] <abentley> lifeless: Yes, that makes sense to me.
[02:48] <abentley> Hmm.  Maybe it could be a supplemental flag?
[02:49] <abentley> Because it would still be readable by older clients.
[03:04] <lifeless> abentley: I meant a flag on the object, not on disk
[03:04] <lifeless> abentley: thinking about it some more with spiv; we think the client can check if the delta basis is present and error if its not
[03:05] <abentley> I meant the format bump you were talking about.
[03:05] <lifeless> abentley: no, I don't think it can be a supplemental flag or older clients will write to the repo too
[03:05] <lifeless> abentley: and could then introduce this defect
[03:05] <abentley> Oh, drat.
[03:06] <lifeless> igc: compression fix has landed
[03:06] <igc> lifeless: excellent - just checked pqm 5 mins ago checking its progress :-)
[03:07] <abentley> Anyhow, I was surprised you said it was expensive to detect this, and I agree it makes sense to error on missing delta basis.
[03:14] <abentley> spiv: Would it make sense to provide a way to do dumb fetch?
[03:16] <lifeless> abentley: by dumb you mean the current knit join approach ?
[03:16] <abentley> Yeah.
[03:16] <abentley> For people who can't reconcile the source repo.
[03:17] <abentley> But I also mean, just using the dumb transport.
[03:18] <abentley> But this is only likely to affect initial branches anyhow.
[03:18] <lifeless> I think that might be reasonable but given that few people run bzr+ssh-only repo's anyhow
[03:24] <lifeless> igc: pushed a pack repo that has the compression fix too, to my 'repository' branch.
[03:25] <igc> lifeless: thanks. I'm interested in a pack repo with annotations separated next :-)
[03:26] <abentley> igc: I'm working on stripping annotations completely.
[03:26] <igc> abentley: from knits?
[03:27] <abentley> From packs.
[03:27] <igc> I guess I was assuming that would be a format bump and it may as well come with the pack stuff?
[03:27] <igc> cool
[03:28] <abentley> Yeah.  We'll see.  It may not be performant without at least caching get_matching_blocks.
[03:31] <abentley> But since we can extract that from our delta formats, who knows?
[03:32] <Peng> Stripping annotations from packs? As in 'bzr annotate'?
[03:32] <lifeless> igc: I pasted the patch for that here
[03:32] <igc> code,code,code ... measure,measure,measure ... code,code,code ...
[03:33] <igc> lifeless: ok, I'll grab it later - just trying to get an options patch out right now
[03:34] <abentley> Peng: yes.  It's a significant cost when committing large trees.  We promise not to break anything.
[03:34] <fullermd> It doesn't break anything; all the tests still pass   ;)
[03:45] <Peng> abentley: But will it make bzr annotate slow?
[03:45] <lifeless> Peng: s/?/er?/
[03:45] <lifeless> yes
[03:45] <Peng> Even slower?
[03:46] <Peng> Yuck.
[03:46] <Peng> One thing I liked about bzr was speedy annotations, and now it'll be worse than hg.
[03:46] <Peng> I know I know, I'd be whining about slow commits if you didn't do this. :P
[03:46] <abentley> Why do you think it will be slower than hg?
[03:47] <lifeless> why do you say it'll be worse than hg ?
[03:47] <Peng> I don't know.
[03:47] <Peng> I compared it some time.
[03:48] <Peng> Hold on.
[03:55] <Peng> ....
[03:57] <Peng> Hey, where can I get a copy of the repository branch new enough to access the repository branch?
[03:59] <abentley> http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ ?
[03:59] <lifeless> yup
[03:59] <lifeless> Peng: see my dogfooding mails to the list
[04:00] <Peng> I didn't think that branch was up-to-date enough.
[04:00] <NamNguyen> abentley: what does auto_merge.py do?
[04:00] <lifeless> Peng: I've explicitly stated that I keep it up to date enough to read the other branch
[04:01] <lifeless> Peng: its the bootstrap
[04:01] <Peng> Oh.
[04:02] <abentley> NamNguyen: It marks merge requests merged if they have been merged into the mainline.
[04:02] <NamNguyen> abentley: how is that done? i looked at the code but didn't understand it much
[04:03] <Peng> Okay, I get it.
[04:03] <NamNguyen> something to do with merge_id, is it supposed to be unique?
[04:03] <Peng> I need to throw out my old branch of repository, and get it again?
[04:03] <abentley> No, not merge_id.
[04:04] <abentley> First it downloads the latest version of the mainline.
[04:04] <abentley> Then it finds which revisions are newly part of the mainline's ancestry.
[04:05] <poolie> lifeless, are you going to upload a new 0.90 deb?
[04:05] <abentley> Actually, it just finds which revisions are part of the mainline's ancestry.
[04:05] <lifeless> poolie: yes when I don't get md5 errors from the deb archive during build
[04:05] <abentley> Then it looks at the merge requests, and sees whether their head revision is in the mainline's ancestry.
[04:06] <lifeless> Peng: Please read the mails with [PACKS]  in the them on the list.
[04:06] <lifeless> Peng: they contain all the relevant info
[04:08] <Peng> Blaaah.
[04:09] <NamNguyen> abentley: suppose that two merge requests branched from a same revision
[04:09] <abentley> I don't know what you mean by "branched".
[04:10] <NamNguyen> they come from a same revision
[04:10] <abentley> The only thing that matters is the head revision-- the newest revision in the merge request.
[04:10] <abentley> So you have two merge requests trying to submit exactly the same change?
[04:11] <NamNguyen> different change
[04:11] <abentley> Where they branched from doesn't matter.
[04:12] <NamNguyen> isn't the head revision the parent revision?
[04:12] <abentley> No.
[04:12] <abentley> The head revision is the youngest revision.
[04:12] <abentley> If the merge request has a bundle, all the other revisions in it will be ancestors of the head revision.
[04:13] <NamNguyen> and when this bundle is merged, is the revision id kept unchanged?
[04:14] <NamNguyen> its revision ids
[04:16] <abentley> Yes, revision ids are never altered.
[04:18] <NamNguyen> i see, so the idea of automerge is to check all outstanding merge requests' latest revision ids to see if they are in the branch
[04:19] <abentley> Right.
[04:22] <lifeless> Peng: if you've read the mail and are lost I'll happily help you
[04:22] <lifeless> Peng: but I don't have time to simply be repeating myself sorry
[04:22] <Peng> lifeless: Yeah, I get it. I need to get a mail client up and running and start reading the list. :P
[04:23] <lifeless> Peng: gmane has it
[04:25] <Peng> I can't get Gmane to load at the moment.
[04:25] <Peng> I'm reading the list on lists.ubuntu.com.
[04:25] <lifeless> ok
[04:29] <Peng> Okay!
[04:29] <poolie> are the generated html files going to be called .htm or .html?
[04:29] <poolie> i thought we agreed to change it to .html?
[04:30] <sri> sup
[04:30] <poolie> hi
[04:30] <Peng> Annotating a 1000-line file with 1600 revisions, user time:
[04:30] <Peng> bzr knits: 1.1 seconds
[04:30] <Peng> bzr packs: 3.6
[04:30] <Peng> hg: 4.0
[04:31] <Peng> Bzr 0.90 was a few msec faster than the pack version in a knit branch. :P
[04:32] <abentley> poolie: They're html, but no one has updated the online documentation.
[04:32] <abentley> igc was looking into it last I heard.
[04:32] <poolie> the cron job is running, but maybe it's not copying them across
[04:34] <igc> poolie: the doc usually gets updated as part of the release rollout
[04:35] <lifeless> Peng: ms differences are sampling noise
[04:35] <igc> I've been meaning to ask you about where James got up to
[04:35] <lifeless> Peng: the 3.6 seconds is due to the single text index not doing partial loads
[04:36] <Peng> lifeless: Will that be improved in the future?
[04:36] <lifeless> yes
[04:36] <Peng> Yeah, you're right, it was just noise.
[04:37] <Peng> lifeless: Okies.
[04:37] <Peng> lifeless: But removing annotation data will make it slower ..
[04:37] <lifeless> thats right.
[04:37] <lifeless> but every file version has to get committed by definition
[04:37] <lifeless> only some get annotated
[04:38] <lifeless> so we could for instance have a background task to generate an annotation cache
[04:38] <lifeless> fire off a thread as a commit hook
[04:38] <Peng> Huh.
[04:38] <lifeless> or cache different data that helps annotations as abentley mentions
[04:38] <lifeless> lots of options
[04:39] <lifeless> but removing 20% overhead during commit that is only sometimes used seems like a pretty good idea
[04:40] <Peng> Yeah, it does.
[04:40] <Peng> I just liked having fast annotations. :P
[04:40] <lifeless> e.g.
[04:40] <lifeless> if you ask for an annotation of file X, we cacn cache the results
[04:40] <ubotu> New bug: #135770 in bzr (main) "bzr faild ti install (dup-of: 135891)" [Undecided,New]  https://launchpad.net/bugs/135770
[04:41] <Peng> Removing 20% overhead from commits won't change if they're "fast" or "slow", but the change will make annotating "slow" instead of "fast".
[04:41] <Peng> Anyway, I don't want to stop you or anything.
[04:41] <Peng> Just sayin'.
[04:41] <lifeless> the way you get from slow to fast commits is by stripping overhead thats not needed
[04:42] <Peng> Well sure. It's a significant improvement and that's a good thing. But commits going from 1s to 0.8 is still "fast", and 10 to 8 is still "slow".
[04:42] <Peng> But annotating going from 1 second to 4 is "fast" to "slow".
[04:43] <Peng> Anyway, I'll shut up.
[04:43] <Peng> The change is a good idea.
[04:43] <Peng> I just hope that you'll be able to keep annotating as fast as possible! :)
[04:46] <abentley> lifeless: Got annotation of plain knits tested and working.  Where do you want it?  Technically, it could even go in bzr.dev, I guess.
[04:47] <lifeless> abentley: bzr.dev :)
[04:48] <lifeless> abentley: I want to keep the branch as small as possible at all times
[04:48] <abentley> Aw, drat.  I'll hafta cherrypick.
[05:59] <abentley> igc: It seems as though the path must start with 'callgrind.out', not just the basename.
[06:00] <igc> in my code you mean? If so, I'll fix that
[06:03] <poolie> i'm looking into why the docs aren't visible
[06:03] <igc> thanks poolie
[06:04] <poolie> they are being built; they might not be copied to the right directory, or something like that
[06:11] <poolie> ok i think that's ok now
[06:25] <abentley> Awesome.  Now we have a copy of NEWS to point people at.
[06:27] <abentley> lifeless: I've got the new annotation code using precalculated get_matching blocks everywhere possible.
[06:27] <lifeless> abentley: you're on fire
[06:27] <abentley> That too.
[06:27] <igc> abentley: +1 to that
[06:28] <abentley> But without matching blocks for the righthand parent of merges, there are still 279 calls.  And that's 40% of runtime.
[06:29] <lifeless> whats your test file, NEWS?
[06:29] <abentley> Yep.
[06:29] <abentley> revision 2000
[06:29] <abentley> That still takes 13 seconds.
[06:30] <abentley> So I don't want to go higher.
[06:31] <abentley> I'm not storing any new data, just using the knit deltas to extract get_matching_blocks output.  Which is why the 40%.
[06:31] <abentley> Because knit deltas only tell us about the left parent.
[06:33] <lifeless> man python you suck
[06:33] <lifeless> a$ python -m timeit 's = [] ; s.append((200, 300)); s.pop()'
[06:33] <lifeless> 1000000 loops, best of 3: 0.874 usec per loop
[06:33] <lifeless> $ python -m timeit 's = [] ; s.append((200, 300)); del s[-1] '
[06:33] <lifeless> 1000000 loops, best of 3: 0.528 usec per loop
[06:33] <abentley> Sheesh
[06:33] <lifeless> $ python -m timeit 's = [] ; s.append((200, 300))'
[06:33] <lifeless> 1000000 loops, best of 3: 0.398 usec per loop
[06:34] <lifeless> .130 to do del s[-1] , .480 to do s.pop()
[06:35] <fullermd> If it helps, it takes my system longer to do the pops than it takes yours to do the whole bunch   :p
[06:35] <lifeless> fullermd: do you see the same relative costs?
[06:35] <fullermd> ~1 -> ~2.3.
[06:35] <fullermd> Well, ~1 - ~1.25 - ~2.3.
[06:36] <fullermd> Eyeballs similarish, yah.
[06:36] <lifeless> copy n paste is easier :)
[06:36] <fullermd> Little over double cost for pop, 'bout 25% more for del.  Close enough.
[06:39] <poolie> lifeless, thanks for making a sid/gutsy repo
[06:41] <abentley> lifeless, poolie: I've started work on a NEWS-specific text merge, but no ETA on completion yet.
[06:45] <abentley> Annotating the latest version of NEWS takes 1m25.767.  Eeps.
[06:45] <abentley> g'night.
[06:50] <poolie> lifeless, i think splitting the news might make it easier for people developing across releases
[06:50] <poolie> because their changes would not accidentally end up in a different release
[07:02] <igc> poolie: thanks for the doc stuff. It looks good except that the 'latest' link is still pointing to some older doc?
[07:02] <poolie> thanks, fixed ?
[07:03] <igc> poolie: yes, assuming latest means 'current release', not 'development'
[07:04] <lifeless> latest is not clear
[07:04] <igc> we do have bzr.dev for that
[07:04] <igc> I'd prefer 'current' to 'latest' my self
[07:04] <poolie> maybe we should just get rid of that link and let people who want the latest look at bzr.dev?
[07:04] <igc> that would do
[07:04] <igc> 2nd thoughts ...
[07:04] <igc> I'd like a 'current' link
[07:05] <lifeless> latest was meant to mean current release
[07:05] <lifeless> I didn't think about clarity enoug at the tome I think
[07:05] <igc> it's need IMO, I just don't like the name
[07:10] <poolie> can someone glance at<EMAIL_ADDRESS>[07:10] <poolie> please
[07:11] <beuno> please :D
[07:14] <beuno> btw, is bundlebuggy a custom thing?  it's marvelous  :D
[07:17] <Peng> beuno: Yes, but it's open source.
[07:18] <beuno> Peng, aaah, well, it's a great idea/implementation
[07:18] <Peng> Totally. :)
[07:26] <igc> poolie: that looks fine to me. I'll approve it in BB
[07:30] <poolie> igc, thanks
[07:30] <beuno> yay!  does the bug close my itself in LP?
[07:30] <poolie> which bug?
[07:31] <beuno> the one that the patch is for, #107155
[07:31] <lifeless>  python -m timeit '{1:2, 2:3, 3:4}'
[07:31] <lifeless> 1000000 loops, best of 3: 0.584 usec per loop
[07:31] <lifeless>  python -m timeit 'dict(((1,2), (2,3), (3,4)))'
[07:31] <lifeless> 100000 loops, best of 3: 2.15 usec per loop
[07:32] <fullermd> 'bout the same ratio here.
[07:33] <lifeless> just the inner tuple there is tuple is 0.177
[07:39] <lifeless> ok, bye. I need to pack
[07:39] <beuno> aaaaanyway, time I get some sleep, ping me if you need anything else with the patch, night all  :D
[07:40] <poolie> beuno, i've just sent it off
[07:41] <beuno> poolie, great, thanks a bunch, I'll close the bug then
[07:41] <poolie> spiv, quick call?
[07:42] <spiv> poolie: sounds good.  Two minutes?
[07:42] <poolie> sure, call me when you're ready
[07:42] <poolie> igc, i like custom_help()
[07:43] <igc> thanks
[08:08] <igc> spiv: is<EMAIL_ADDRESS>merged into the bzr.dev yet?
[08:09] <poolie> igc, would you like a catchup call? when were you going to finish today?
[08:09] <spiv> igc: not yet, thanks for the reminder.
[08:10] <igc> poolie: don't mind either way. Need to wrap up around 6 tonight
[08:10] <poolie> ok, can we talk about 5:30?
[08:10] <igc> sure
[08:10] <poolie> cool
[08:10] <poolie> i'm stepping out for a bit
[08:11] <igc> poolie: before you go ...
[08:11] <igc> I'm about to do some reviews
[08:11] <igc> any preferences for which ones?
[08:16] <poolie> not in particular, though i do think doing some is a good idea
[08:16] <poolie> i'm just doing yours
[08:17] <igc> ok - I'll do the --change one from Lucas and the pre-commit hook one
[09:32] <NamNguyen> igc, thanks for reviewing the patch for pre_commit hook
[09:32] <NamNguyen> does a commit to CommitBuilder actually commits anything?
[09:33] <NamNguyen> or does it only flag that a commit is done, ready to be flushed out to disk
[09:36] <igc> few minutes - on phone
[09:44] <siretart> is there a spec or bug or something for the 'bzr cp' feature?
[09:45] <siretart> I'm trying to maintain file templates in a bzr branch. after I change the template, I want all changes I was doing there to be merged into copies of that file. is that possible with bzr?
[09:46] <poolie> siretart, i believe there is a spec discussing how it could work, but it is not implemented atm
[09:46] <poolie> one of the issues is how to determine what changes should propagate or not
[09:46] <siretart> I'd like to subscribe to the spec. do you remember how it was called?
[09:47] <poolie> no
[09:47] <siretart> I imagine that it is tough, though ;)
[09:50] <igc> NamNguyen: CommitBuilder.commit does the actual commit to disk
[09:50] <igc> See bzrlib/repository.py
[09:50] <fullermd> Well, it's probably not especially easy to do, but working out (and agreeing onn) what it should do is even harder   :)
[09:52] <NamNguyen> igc: but if there's an exception in a precommit hook, the whole commit seems to be discarded
[09:52] <NamNguyen> i can be wrong here, but isn't there some kind of rolling back mechanism?
[09:54] <igc> NamNguyen: looking closer, it looks like self.branch.set_last_revision_info is the final piece of the puzzle ...
[09:54] <igc> until that final bit is written, the data is on disk by not linked in it seems
[09:54] <igc> s/by/but/
[09:55] <NamNguyen> igc: i'm trying to find out if the file is truncated after all
[09:55] <igc> NamNguyen: so apologies - you could be fine after all ...
[09:56] <NamNguyen> igc: but that might increase the size of the repo if it's not undone
[09:56] <igc> Maybe - we do have a gc command though
[09:56] <NamNguyen> but then, the next time you commit, it will be written over the same place as the discarded commit
[09:57] <NamNguyen> so i think it all works out
[09:57] <igc> NamNguyen: my suggestion is to ping abentley in a few hours and get his opinion on precise location ...
[09:57] <NamNguyen> okay
[09:57] <igc> he did approve your code *and* he knows the commit code really well
[09:57] <NamNguyen> he reviewed it twice, but no harm pester him to do it again
[09:58] <igc> don't ask him to review the code - just double check on that bit and the consequences of ...
[09:58] <igc> an exception in the pre-commit hook
[09:58] <igc> I guess he'll say "all ok" in which case ...
[09:59] <NamNguyen> alright, i'll ask him
[09:59] <igc> that's great - well done on your first bzr patch!
[10:00] <igc> I'll be happy to merge it Monday.
[10:00] <NamNguyen> i look forward to handing in more patches :D
[10:00] <igc> If you want to update the hook doc though before then, even better still
[10:00] <igc> I look forward to receiving them :-)
[10:04] <igc> Well, time to go after another good week in the wonderful world of Bazaar ...
[10:05] <igc> great to see 0.90 ship and lots of neat stuff coming in 0.91 and 0.92
[10:05] <igc> Have a good weekend all
[10:18] <poolie> night all
[12:14] <mwhudson> so
[12:14] <mwhudson> is there a way to tell bzr/bzrlib to set a timeout on the sockets it creates?
[12:15] <mwhudson> or, to ask what i really want to know: not wait for more than some interval (a minute?) for a response from the remote server?
[12:31] <NamNguyen> mwhudson, with python 2.5, yes
[12:32] <mwhudson> NamNguyen: ?
[12:32] <NamNguyen> socket.setdefaulttimeout(60)
[12:32] <mwhudson> that's possible in 2.4 already
[12:32] <NamNguyen> maybe you can put it in your sitecustomize.py
[12:32] <mwhudson> i suppose we could do that
[12:32] <NamNguyen> oh? hah, my bad
[12:33] <mwhudson> this is code that calls bzrlib apis, so it could just do that during start up
[12:33] <mwhudson> this branch: https://code.launchpad.net/~ypodim/teleporter/teleporter keeps tripping launchpad up
[12:51] <matkor> jelmer: Can you merge one typo fix from  https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? I emailed phanatic but seems be busy, TIA
[12:51] <jelmer> matkor: sure
[02:42] <ignas> hi
[04:30] <hacklberry> hi, where could i get more details about bzr "smart merging"?
[04:40] <z1pp1ty> i'm looking to use bazaar to do something like this...
[04:40] <z1pp1ty> working copy -- bzr --> local svn repo -- svn --> remote svn repo
[04:40] <z1pp1ty> I assume it can be done, but are there docs anywhere on how to do something like this?
[04:55] <hacklberry>  where could one get more details about bzr "smart merging"?
[05:05] <bwinton> Hacklberry: Google?
[05:06] <bwinton> From http://bazaar-vcs.org/BazaarBook#features:
[05:06] <bwinton> Smart Merging
[05:06] <bwinton>     * Merge knows and merges only whats missing.
[05:06] <bwinton>     * Merge minimizes spurious conflicts.
[05:06] <bwinton>     * Merge is not tricked by identical changes.
[05:10] <hacklberry> well the reason why i asked is that when i try to merge into a 'main' branch from 2 branches merge is actually 'tricked by identical changes'
[05:10] <bwinton> Sweet!  Do you have a test case?
[05:11] <hacklberry> what i tried is quite simple - i really think i misunderstood something
[05:11] <hacklberry> i merge from branch A where i added 3 lines:
[05:11] <hacklberry> xxx
[05:12] <hacklberry> yyy
[05:12] <hacklberry> zzz
[05:12] <hacklberry> now on branch B i added 3 lines as well:
[05:12] <hacklberry> qqq
[05:12] <hacklberry> yyy
[05:12] <hacklberry> zzz
[05:12] <hacklberry> and when i tried to merge branch B
[05:13] <bwinton> Ahhh...  Well, those aren't exactly identical changes...
[05:13] <hacklberry> he - as i said i misunderstood it then
[05:13] <bwinton> If you had committed yyy and zzz in a different step on both branches, then you'ld probably get what you were looking for...
[05:14] <bwinton> i.e. branch A gets yyy + zzz, then gets xxx.  Branch B gets yyy + zzz, then gets qqq...
[05:14] <luks> just wondering, what would you expect to be the correct merge here?
[05:14] <bwinton> (Now, I haven't tried that myself, but my intuition is that that should work.)
[05:15] <hacklberry> well i was expecting merge to see that those changes are coming from diff sources
[05:15] <hacklberry> i was trying to add:
[05:15] <luks> I mean the result
[05:15] <luks> I personally can see three possible merges: xxxyyyzzzqqqyyyzz or qqqyyyzzxxxyyyzzz or xxxqqqyyyzzz or qqqxxxyyyzzz
[05:15] <luks> and all of them seem wrong to me
[05:15] <bwinton> (Psst, luks, that's four merges...)
[05:16] <luks> er, four :)
[05:16] <luks> I had only three initially
[05:16] <hacklberry> int foo() {
[05:16] <bwinton> Nasty off-by-one error you got there...  :)
[05:16] <hacklberry> return 0;
[05:16] <hacklberry> }
[05:16] <hacklberry> on one branch
[05:16] <hacklberry> int bar() {
[05:16] <hacklberry> return 0;
[05:16] <hacklberry> }
[05:17] <hacklberry> on second branch (both forked from main branch)
[05:17] <hacklberry> and then i merged into main from branch A
[05:18] <luks> so let's say some algorithm would merge them, in what other?
[05:18] <luks> foo and then bar, or the other way around?
[05:18] <hacklberry> so when merging from B i was expecting merge to pickup that the changes are different, and mark the whole
[05:18] <hacklberry> int bar() {
[05:18] <hacklberry> return 0;
[05:18] <hacklberry> }
[05:19] <hacklberry> as a block
[05:19] <luks> and it marked only the function definition, right?
[05:19] <hacklberry> so i can then manually merge in some tool like kdiff3
[05:19] <hacklberry> yes exactly
[05:19] <luks> hm
[05:20] <hacklberry> that's how i understood ' Merge is not tricked by identical changes'
[05:23] <hacklberry> "You may say I'm a dreamer, but I'm not the only one." :-)
[05:23] <luks> hm, I see
[05:24] <luks> weave merge marks only the function definitions, merge3 marks whole functions
[05:24] <luks> but isn't --merge3 the default?
[05:25] <hacklberry> i tried all 3 algorithms
[05:25] <hacklberry> but kdiff3 displayed the same
[05:27] <hacklberry> i thought that bzr uses some unique ids for every change
[05:28] <hacklberry> so a line of text like abcd from 2 diff sources will be treated as 2 diff entries even if the content is the same
[05:28] <luks> I think the 3-way merge should do exactly that
[05:29] <luks> (and it does here)
[05:29] <hacklberry> ok i m going to try again then
[05:30] <hacklberry> i mean in the morning :-) it is 1:30am here, i live in Canberra
[06:47] <radix> whoah
[06:48] <radix> I just got a warning saying that my Python interpreter doesn't support en_US.UTF-8
[06:48] <radix> (during a bzr push)
[07:01] <radix> strangely enough, python -c 'from bzrlib.osutils import get_user_encoding; print get_user_encoding()' prints "UTF-8" with no warning
[07:03] <dato> was it a bzr push over bzr+ssh? then what matters is if the target system supports en_US.UTF-8, afaik
[07:04] <radix> ah, interesting, yes
[07:05] <radix> thanks a lot dato :)
[07:05] <dato> no problem
[07:44] <nx> LarstiQ: ping
[08:09] <synic> after a 'bzr up', how can I see what files were changed?
[08:12] <james_w> synic: do you remember what revision you were on previously? Do the command tell you how many you just got?
[08:12] <james_w> if you know then bzr status -r-6.. should tell you
[08:12] <james_w> another way is bzr log -v and then just read the log messages and see which files were changed.
[08:16] <synic> k
[08:28] <jelmer> synic: we also plan to let it output the changes in the future, unless -q is specified
[08:47] <synic> jelmer: is there any way to output the changes during update with a flag?  -v maybe?
[08:50] <ubotu> New bug: #136445 in bzr "Please provide an easy way to ask "What did you just do?"" [Wishlist,New]  https://launchpad.net/bugs/136445
[08:52] <bwinton> Now that's an awesome bug...
[08:52] <bwinton> bzr wtf-just-happened-there
[08:53] <jelmer> synic: Not yet
[08:56] <synic> jelmer: ok
[09:10] <Peng> That bug is a good idea. Before I fully got into the habit of using 'bzr pull -v', I wouldn't be able to find out what all was pulled.
[09:10] <Peng> Maybe just printing the old revision during those command would be good enough.
[09:10] <Peng> Like, where it says "Now on", it could say "Started at" too.
[09:40] <synic> can you checkout a specific directory in a branch?
[09:42] <Peng> synic: No.
[09:46] <mtaylor> anybody know what the status of the visual studio plugin - https://launchpad.net/bzr-visualstudio - is?
[09:50] <nx> mtaylor: yep
[09:50] <nx> I'm the developer
[09:51] <mtaylor> nx: cool. is it ready for people to use/poke at?
[09:52] <nx> go ahead. it's still lacking some features, but those that are implemented should work well
[09:52] <mtaylor> nx: sweet. I'll give it a spin then
[09:52] <mtaylor> nx: should I branch trunk ?
[09:53] <nx> banquet.status is the latest code
[09:53] <nx> I haven't managed to create an installer yet; you'll need to have the VSSDK installed to run from the branch
[09:54] <mtaylor> ok. I think I've got that installed on this box
[10:00] <mtaylor> nx:  when I try to open the .sln file, I get errors about not being able to open the Project files...
[10:02] <nx> what's the exact error message? do you have the SP1 installed?
[10:03] <mtaylor> nx: Unable to read the project file 'Banquet.csproj'
[10:03] <mtaylor> nx: but I might not have sp1 installed. let me check
[10:04] <nx> right, i forgot you need to set a environment variable named VisualStudioIntegration that points to the VisualStudioIntegration directory in the VSSDk directory
[10:04] <nx> sorry
[10:05] <nx> or just open the csproj file and replace $(VisualStudioIntegration) with that path
[10:05] <mtaylor> ah, ok
[10:11] <bwinton> Has anyone here run bzr on Python 3.0 yet?
[10:12] <radix> aggggggggggh
[10:12] <radix> it's already started
[10:12] <dato> hahaha
[10:13] <bwinton> Hey, give me some credit.  I've had the 3.0a1 announcement page sitting in my browser since 9:00 this morning!
[10:13] <radix> we are doomed, Guido has killed us all
[10:13] <bwinton> Heh.  I think you're thinking of Python 4000, with sys.kill_us_all()...
[10:13] <radix> bwinton: it is impossible to run most existing Python code on python 3
[10:14] <bwinton> Sure, but the 2to3 tool gets you part (most?) of the way there.  I was wondering how far it got bzr...
[10:14] <radix> ah. ok. so really you wanted to ask if anybody has ported bzr to python 3 yet :-)
[10:15] <bwinton> radix: If you want to be technical about it...  ;)
[10:15] <bwinton> Actually, I think I was even further behind than that.  I really wanted to ask if anyone had looked into porting bzr to python 3 yet.
[11:44] <lifeless> LarstiQ: ping


[23:36] <sebsebseb> SineDeviance: someone got some currupted  data files issue or something with 9.10,  the one that's mentioned in the release notes
[23:36] <ctmjr> dtownhero: thank you
[23:36] <maco> ive lost data to ext4 before
[23:36] <maco> 3 times
[23:36] <sebsebseb> SineDeviance: when doing Ext4
[23:36] <sebsebseb> maco: oh you as well hmm
[23:36] <SineDeviance> okay, i think i'll go with ext3 then
[23:36] <SineDeviance> thanks!
[23:36] <sebsebseb> SineDeviance: hang on
[23:36] <Fizix> sisif, oh those pesky hibernation modes! Sisif, what filesystem are you using on your machine?
[23:37] <sebsebseb> SineDeviance: you could go with XFS instead, that has the Ext4 advantages
[23:37] <sisif> Fizix : ext4
[23:37] <sebsebseb> SineDeviance: and been around much longer
[23:37] <jacquesdupontd> i know i'm a bad guy and i should stop caring about losing time with people giving you answers of newbie
[23:37] <maco> sebsebseb: i still use ext4 for my system. ive just started actually keeping backups now
[23:37] <sebsebseb> SineDeviance: just not that many Ubuntu users use it
[23:37] <SineDeviance> sebsebseb, also ext4 isn't readable in windows with the ext fs driver, is it?
[23:37] <maco> SineDeviance: not htat im aware
[23:37] <Fizix> Sisif, some people have a problem with EXt4, try going to ext3. It does journaling too but doesn't have some of the fancier support for solid-state harddrives
[23:37] <sebsebseb> SineDeviance: I think there is the driver, but it won't work well at all
[23:37] <SineDeviance> okay... yeah i guess i'll go with ext3 for compatibility then...
[23:37] <SineDeviance> thanks everyone
[23:38] <Fizix> NP
[23:38] <boxxy_> do you think there's a script in Ubuntu that sets /proc/sys/net/ipv6/bindv6only to 0 once it boots? As it always goes back to 0, even if I set 1, after a reboot......... :/
[23:38] <ratatim> When I click on Unetbootin it won't load. What should I do?
[23:38] <sebsebseb> SineDeviance: go with Ext4 since it's the default for 9.10, or go with what maco says which is I don't know yet, but she tends to know her stuff
[23:38] <sisif> Fizix : I don`t need support for SSD.
[23:38] <SineDeviance> sebsebseb, im not installing 9.10. i am install crunchbang which is based on 9.04
[23:38] <sebsebseb> SineDeviance: oh
[23:38] <SineDeviance> yeah
[23:38] <sisif> Fizix : is there any way to delete the hibernation file(s) so I can just boot it nornaly ?
[23:38] <mdg> SineDeviance: I have CB on a old laptop
[23:38] <Fizix> sisif, then I'd say switch to ext3 in the interim if your only problem is in hibernation
[23:38] <dtownhero> jacquesdupontd, thing is, you're wrong and to stubborn to take advice. I'm sure you can figure it out on your own with the 5 years of linux logged...
[23:38] <sebsebseb> SineDeviance: well in that case wrong channel really,  and maybe Ext3
[23:39] <maco> sebsebseb: the setup i mentioned means that while / might go, your /home should be ok. so your data is safer, but your boot is fastr, and if / breaks...meh, reinstalling is easier than getting back lost user dat
[23:39] <maco> *data
[23:39] <Fizix> Sisif, I'm sure there is, but I'm not knowledgeable enough for that one.
[23:39] <SineDeviance> sebsebseb, well yeah, i know it's the wrong channel technically but they use the same kernel and such as 9.04 default so i figured it would still apply. anyways, thanks :D
[23:39] <sisif> Fizix : the irony, this was the 1st time i tried hibernation. I usually go for Suspend.
[23:39] <sebsebseb> maco: well / can be done in Ext4 and  /home can be done in Ext3,  I never had issues with Ext4 myself though
[23:39] <sebsebseb> SineDeviance: ok well
[23:40] <maco> sebsebseb: yeah thats how i did my brother' and mom's computers
[23:40] <ratatim> Can someone tell me how to run Unetbootin? I downloaded it to my desktop and when I click on it nothing is happening
[23:40] <sebsebseb> SineDeviance: back up your stuff and Ext4 in  Crunchang/9.04 sure why not
[23:40] <burkmat_> ratatim, try running `chmod +x filename` on it
[23:40] <MarkGil> Hi, is it possible to use ulimit to restrict memory usage of rogue programs from the init scripts?  rsyslog is wasting lots of memory, and on a embedded sheevaplug, it's not great
[23:40] <sebsebseb> SineDeviance: then you get speed improvements, but there is a slight chance of data loss or something
[23:40] <Fizix> sisif, since the both filesystems (ext3 and 4) are journaling filesystems, you can hibernate for either/or. You may have better luck with 3
[23:40] <jacquesdupontd> dtownhero, you're right that's what i'm diong
[23:40] <ratatim> burkmat_: thanks i'll see if that helps
[23:41] <sebsebseb> SineDeviance: or have Ext3,  and slower boot up, and don't have to think about data loss at all
[23:41] <MarkGil> It's sorted hinted here, but does not really tell me know to do it.  http://wiki.rsyslog.com/index.php/Reducing_memory_usage
[23:41] <magmarules> unn all this effor and still ... anyone knows how to diactivate the Whobby effect when "scaling" windows to change app/window ?
[23:41] <losha> SineDeviance: ext4 isn't readable in windows, or lots of 3rd party things like super grub disk, older live cds, other linux distros etc.
[23:41] <sebsebseb> SineDeviance: also I woudn't recommend sharing your Linux partitions with Windows, after all a Windows virus could then delete stuff from those as well
[23:41] <ratatim> burkmat_: when I run that command it says "no such file or directory"
[23:42] <SineDeviance> okay, yeah i'l go with ext3 then
[23:42] <sebsebseb> SineDeviance: oh you were on here with two names?
[23:42] <SineDeviance> i need them to be readable in windows with the ext fs driver
[23:42] <Fizix> SineDeviance, that sounds like the safest bet to me
[23:42] <SineDeviance> sebsebseb, no i got disconnected
[23:42] <jacquesdupontd> dtownhero, i think i'm better at helping cause i can't stop getting anoyed of the time i loose explaining all to people that wants absolutely to answer you even if they don't know anything about what you're asking
[23:42] <sebsebseb> SineDeviance: why?
[23:42] <sisif> Any one here hasanyh idea on how I may delete a failed hibrnation image from my swap using a LiveCD?
[23:42] <burkmat_> ratatim, well... replace "filename" with the actual filename?
[23:42] <dusty1> hey its me again i have yet another real stupid question can i change my icon that is part of my application menu to something else?
[23:42] <RetianFes> Is it possible to pin Konversation to the mail icon on the tab bar when it's not running like Empathy does?
[23:42] <sebsebseb> maybe you missed this then
[23:42] <sebsebseb> SineDeviance: also I woudn't recommend sharing your Linux partitions with Windows, after all a Windows virus could then delete stuff from those as well
[23:42] <ratatim> burkmat_: that's what I did.
[23:43] <SineDeviance> sebsebseb, right, but i mount them in ro
[23:43] <SineDeviance> so there's no danger
[23:43] <sebsebseb> SineDeviance: in what?
[23:43] <SineDeviance> linux is my main OS
[23:43] <Fizix> SineDeviance, sebebseb brings up a good point.
[23:43] <SineDeviance> sebsebseb, in windows. the fs driver gives you the option to mount partitions read-only
[23:43] <SineDeviance> which i do
[23:43] <burkmat_> ratatim, ...are you sure the file is in the directory you're in?
[23:43] <dtownhero> that was one angry retarded frenchman...
[23:43] <losha> sisif: can't you just reformat the swap partition using gparted?
[23:43] <sebsebseb> SineDeviance: oh I see, well as far as I know that driver does not work well with Ext4
[23:44] <sisif> losha : I don`t know. That`s why I`m asking :P
[23:44] <SineDeviance> sebsebseb, yeah, on the internets it says it only supports ext3
[23:44] <dusty1> hey its me again i have yet another real stupid question can i change my icon that is part of my application menu to something else?
[23:44] <sebsebseb> SineDeviance: you coudl do / in Ext4
[23:44] <sebsebseb> SineDeviance: a seperate data partition :) to share with Windows and not read only if you like
[23:44] <losha> sisif: then let me rephrase: try reformatting the swap partition using gparted....
[23:44] <SineDeviance> sebsebseb, it also says that the kernel that comes with 9.04 has ext4 issues
[23:44] <ratatim> burkmat_: i don't know... how do I find out? haha sorry i'm not too knowledgeable to command
[23:44] <sebsebseb> SineDeviance: or  /home and read only when it comes to Windows
[23:44] <ctmjr> dtownhero: yes it was classic example of not seeing the forest because the trees are in his way
[23:44] <sisif> losha : haha. Nicely said :)
[23:44] <jcp> how do i redirect both stdout and stderr to a file?
[23:44] <sebsebseb> SineDeviance: /  Ext4    home  or data partition Ext3
[23:44] <burkmat_> ratatim, ah... well, where is the Unetbootin file located?
[23:44] <jcp> without overwriting the file
[23:45] <goose> is there a way I can control my fan speed on my ubuntu server box? (preferably one that does not involve ramming a screwdriver into the fan to stop the blades from spinning entirely :p)
[23:45] <Fizix> If you want to go super-geek, you can have another linux OS running inside of Windows via a virtual machine... that should be able to see your other partition, no?
[23:45] <dtownhero> heh
[23:45] <jcp> i want to write to the end of the file, not overwrite the file
[23:45] <gandhi> 1> file 2> file
[23:45] <sebsebseb> SineDeviance: yes and that's what I put, the kernel apparnatlly has issues
[23:45] <jcp> script &>> file ?
[23:45] <sebsebseb> SineDeviance: ,but if your  data partitions are in Ext3 that should be fine for sure
[23:45] <ratatim> burkmat_: well it's on my desktop. It should be in the desktop directory or what-not
[23:45] <maco> Fizix: no
[23:45] <SineDeviance> sebsebseb, i already have a 1tb external drive in ntfs so i guess that could be a shared partition. but sometimes it's just easier to copy directly than to copy twice :D
[23:45] <maco> Fizix: a vm cant see what the host cant see
[23:45] <burkmat_> ratatim, Alright. Try running `chmod +x Desktop/filename` then.
[23:45] <sebsebseb> SineDeviance: I did Ext4 for / and /home and no issues,  but others  have had
[23:45] <VCoolio> jcp: >> adds, > overwrites
[23:45] <ratatim> burkmat_: ok i'll see what that does
[23:46] <Fizix> maco, ahh ok, I always wondered that. Thank you for that info
[23:46] <sisif> losha : guess what. The swap partion is locked under gparted :P
[23:46] <jcp> VCoolio: but i want it to write both stderr and stdout, will that work?
[23:46] <SineDeviance> well, it's installing
[23:46] <sebsebseb> SineDeviance: in fat the only issue when it came to Ext4  was when Vista deleted my seperate /home partition twice, well I installed it twice
[23:46] <sebsebseb> SineDeviance: second time I coudn't recover all data that I had put on it, or whatever, but oh well, nothing important
[23:46] <sebsebseb> SineDeviance: on the new  /home I had created I mean
[23:46] <jrib> jcp: why not just try what you said? :)  (it works on zsh, probably the same on bash)
[23:46] <SineDeviance> sebsebseb, ouch
[23:47]  * Fizix has been running with a Vista Ultimate and Ubuntu dual-boot/partition for several years now without a hiccup.
[23:47] <ratatim> burkmat_: I got this error message when i tried running it again:   "7z not found. This is required for either install mode. Install the "p7zip-full" package or your distribution's equivalent"
[23:47] <jcp> jrib: i wasnt sure if that would work, i was asking, but i'll do that
[23:47] <Fizix> ratatim, try sudo apt-get install p7zip-full  ??
[23:47] <howie_> hey
[23:47] <sebsebseb> Fizix: I had  no issues with Vista Home Premium, untill I decided to re install recently, and it fighted over where it wanted to go, and bye bye my  seperate   Ext4  /home both times, even though I had told it to install in the space that wasn't being used
[23:47] <jrib> jcp: you try with a test command and file of course
[23:48] <howie_> ok
[23:48] <burkmat_> ratatim, Ah... Well then, run `sudo apt-get install p7zip-full` and try again. ;) I'm off to bed, so can't help you anymore.  If so, that may have taken care of the issue....
[23:48] <sebsebseb> ActionParsnip: ,but then I think, maybe I want to play some 3D Windows game in the future on this computer,  a virtual machine won't be good enough
[23:48] <blue0488> I can't get snowballZ can any one help?
[23:48] <goose> (repeat from a few minutes ago) is there a way I can control my fan speed on my ubuntu server box? (preferably one that does not involve ramming a screwdriver into the fan to stop the blades from spinning entirely :p)
[23:48] <dusty1> hmm i suppose no one can help me :(
[23:48] <howie_> vnm,
[23:48] <howie_> yumdmdd
[23:48] <howie_> d
[23:48] <howie_> d
[23:48] <howie_> d
[23:48] <howie_> d
[23:48] <howie_> d
[23:48] <howie_> d
[23:48] <Fizix> sebsebseb, ahh I see. I've never re-installed Vista without also re-installing Ubuntu; I've never install Vista after I already had Ubuntu loaded. That's a bummer. Yea I headr M$ is whack like that.
[23:48] <howie_> d
[23:49] <FloodBot4> howie_: Please don't flood, use http://paste.ubuntu.com to paste, don't use Enter as punctuation.
[23:49] <goose> !ops | howie_ is a nonsensical troll
[23:49] <sisif> losha : yeah. I managed to format it. Let`s see what happens now ..
[23:49] <ActionParsnip> sebsebseb: penumbra and frets on fire is all i need :D
[23:49] <maco> !ops | howie_ is typing gibberih
[23:49] <sebsebseb> ActionParsnip: penumbra not heard of that
[23:49] <ratatim> fizix: thanks for helping me out too
[23:49] <goose> beat you to it maco ;p
[23:49] <maco> goose: aye you win
[23:49] <ActionParsnip> sebsebseb: its a paid for game but the demo is real good. well worth the cash
[23:49]  * Fizix sets mode: +awesome Fizix
[23:49] <maco> jrib: *snort* your kick message is the appeal process?
[23:49] <sebsebseb> Fizix: yes that's what I did,  Vista first then Ubuntu,  and I did it twice two re installs, because...
[23:50] <sebsebseb> Fizix: of both OS's
[23:50] <jrib> maco: on bans anyway
[23:50] <blue0488> can some one help me get snowballZ to work?
[23:50] <Fizix> sebsebseb: Well I'll definitely keep that in mind next time I feel like nuking Vista, thank you.
[23:50] <buttons840> my /lib/lsb/init-functions appears to be incomplete, can i get a fresh version, is this something standard or it is different on all distros/machines?
[23:50] <VCoolio> jcp: did it work already? as a mod of output to null try something like >>/path/to/file 2>>&1
[23:50] <sebsebseb> ActionParsnip: well maybe it is to some extent,  since  then you will be supporting a game company that actsauly bothers making for Desktop Linux?
[23:50] <janmigue> hola tengo un problema , alguno de ustedes puede jugar el juego youville de facebook utilizando el fash player 10 en ubuntu 9.10 ????
[23:51] <jrib> !es | janmigue
[23:51] <sebsebseb> Fizix: well maybe it was since Vista wasn't on my first partition, that I got these issues
[23:51] <tehloki_> I had ubuntu installed in an ext4 partition and winxp installed in an ntfs partition. I deleted the ntfs partition and created a 200gb fat32 partition and left 50gb unpartitioned, then installed windows 7 to the unpartitioned space. Now I have 4 primary partitions and none of them will boot. I just get "disk error" whenever I try. However, I can boot from a Live CD and see that all my partitions are there. What do I do?
[23:51] <sebsebseb> Fizix: that was probably it in fact
[23:51] <Altreus[Hireme]> Karmic server edition; installed xserver-xorg from apt; Radeon 9200 PRO "No valid linear framebuffer address" -- any help? google is not helping
[23:51] <ActionParsnip> sebsebseb: yes the game runs natively :D
[23:51] <tehloki_> do i have too many primary partitions?
[23:51] <ActionParsnip> tehloki_: you cna have 4 primnary partitions
[23:51] <buttons840> tehloki_, maybe reinstall grub, i don't know
[23:51] <Fizix> tehloki_, if you have 4, no.
[23:52] <tehloki_> I
[23:52] <mr> i
[23:52] <tehloki_> I've reinstalled grub on the ext4 partition.
[23:52] <tehloki_> still doesn't boot.
[23:52] <goose> (repeat from a few minutes ago) is there a way I can control my fan speed on my ubuntu server box? (preferably one that does not involve ramming a screwdriver into the fan to stop the blades from spinning entirely :p)
[23:52] <mr> i
[23:52] <tehloki_> is this something wrong with my hard disk? i can see all the files from the windows installation and my linux installation.
[23:52] <tehloki_> or maybe my bios...
[23:53] <Snausages> goose: been through this one? http://ubuntuforums.org/showthread.php?t=42737
[23:53] <Altreus[Hireme]> it works with vesa driver
[23:53] <Altreus[Hireme]> I guess I could try proprietary ATI
[23:53] <Fizix> tehloki_, did you just install Ubuntu and now it's not working?
[23:53] <tehloki_> I'm going to try deleting the windows install, reinstalling grub again, and booting
[23:54] <tehloki_> Fizix: I just installed windows 7 and now neither OS will boot
[23:54] <tehloki_> even after reinstalling grub
[23:54] <Fizix> tehloki_, M$ whipes my stuff out too. The safest way to do a dual-boot is always to have Windows installed first, then put Ubuntu on top of that.
[23:55] <Altreus[Hireme]> oh the proprietary fglrx driver does not support my card
[23:55] <tehloki_> wait, should i be reinstalling grub on the ext4 partition or the swap partition
[23:55] <Altreus[Hireme]> nor apparently does the open-source one :P
[23:55] <ratatim> Unetbootin can't seem to find the .iso image on my desktop. even when I choose the desktop directory. what should i do?
[23:56] <madcheeze> wow all, the updates screwed my system up bad...
[23:56] <madcheeze> complete crash
[23:56] <madcheeze> wouldnt launch x at all
[23:56] <ratatim> madcheeze: hey could you tell me why Unetbootin wont find my iso image?
[23:56] <madcheeze> ratatim, where is your image located?
[23:57] <ratatim> madcheeze: on the desktop. should be in the desktop directory but when i use unetbootin it doesnt show.
[23:57] <madcheeze> i think i interrupted the update
[23:57] <madcheeze> ratatim, did you choose the iso option in the middle?
[23:58] <ratatim> madcheeze: yes i did
[23:58] <madcheeze> ratatim, then click the three dots to the right, and navigate to your desktop
[23:58] <madcheeze> ratatim, it should show your iso image
[23:58] <madcheeze> ratatim, is it an iso or an .img file?
[23:58] <ratatim> madcheeze: that's what i've been trying but its not there. It goes to root then to desktop then nothing is there. it's an .iso file
[23:59] <sebsebseb> maco: Going back to earlier briefly.  / in Ext4 and  /home in Ext3,  I thought about that when I found out that Ext4 is dodgy in 9.04 since the kernel and that.  However I guess Ext4 is good enough now, or 9.10 woudn't be using it as the default file system?
[23:59] <madcheeze> ratatim, thats weird.
[23:59] <madcheeze> ratatim, windows?
[23:59] <ratatim> madcheeze: yeah tell me about it. I run 8.04. I'm trying to upgrade to 8.10 using a usb drive


[05:55] <mborzecki> morning
[06:06] <pstolowski> morning
[06:08] <_moep_> good morning
[07:04] <mborzecki> pstolowski: would you like to take a look at some c code? https://github.com/snapcore/snapd/pull/10547
[07:05] <mborzecki> pstolowski: and maybe this one too: https://github.com/snapcore/snapd/pull/10540 ;)
[07:05] <mborzecki> let's swap reviews 🙂 i can do some of yours
[07:07] <pstolowski> mborzecki: sure, 2 meetings soon, will review afterwards
[09:43] <mborzecki> pstolowski: forget the C parts, can you take a look at https://github.com/snapcore/snapd/pull/10510 it's parts of the boot/devicestate, we can chat if you need some intro about the things that are supposed to happen there
[11:32] <pstolowski> +1 with a few nitpicks
[11:32]  * pstolowski lunch
[13:16] <cachio_> mborzecki, hi
[13:16] <cachio_> mborzecki, this is the error I see in tests https://paste.ubuntu.com/p/FpXBSYrBfS/
[13:17] <cachio_> snapd.service: Got notification message from PID 32489, but reception only permitted for main PID 30393
[13:17] <cachio_> ERROR Post http://0/v1/service-control: dial unix /run/user/0/snapd-session-agent.socket: connect: connection refused
[13:20] <mvo> can someone "review" 10553 please? should be trivial
[13:23] <pstolowski> +1


[12:09] <nand> thorwil: hey! here you can see the tour I made with your artwork : http://devel.ideatorrent.org/tour/1
[12:12] <thorwil> hi nand
[12:13] <thorwil> oh, it would have been good to know about that selection rectangle
[12:14] <thorwil> nand: luckily you got the size/padding right :)
[12:14] <nand> all is CSS controlled :)
[12:15] <nand> and it even fits on 800x600!
[12:15] <nand> the screenshot part is fitting itself (in width) to the screen.
[12:15] <nand> idea I got from the digg tour :)
[12:15] <thorwil> nand: i wonder though if the bulb would be better off without the halo on the selection colour
[12:17] <nand> looks nice to me
[12:18] <thorwil> nand: the vertical positions are off
[12:18] <thorwil> the labels are not on on line
[12:18] <thorwil> one line
[12:19] <nand> Indeed. I'll bottom-align them
[12:29] <nand> that's better. (checked locally)
[12:31] <thorwil> nand: you need to take the descender of the p from Participate into account
[12:31] <nand> I have added some bottom padding to the others :)
[12:33] <thorwil> nand: can you make the Next button be bottom-aligned with bottom of the screenshot?
[12:34] <nand> you find it better that way?
[12:35] <thorwil> better than jumping around
[12:36] <thorwil> otherwise i would use a just-text next after 1 or 2 empyt lines after the text
[12:37] <thorwil> hmm, https://launchpad.net/+tour/index is quite different
[12:44] <nand> thorwil: ok you can now see the changes
[12:45] <nand> launchpad has much more ressources than me, it's not fair competition :)
[12:45] <thorwil> well their tour looks a bit pale :)
[12:46] <thorwil> nand: Participate is about 2 pixels too low
[12:47] <thorwil> you better measure the difference to get it exact. allthough i would include the padding in the images to have an easier time
[12:49]  * nand took use the gimp to check
[12:49] <nand> should be ok now :)
[12:50] <thorwil> i see no change yet
[12:52] <nand> didn't commited yet. Don't want to flood the branch with one-line revisions :)
[19:09] <thorwil> oh man
[19:09] <thorwil> nand: http://ubuntuforums.org/showpost.php?p=5557341&postcount=249 ;)
[19:38] <nand> thorwil: If there was something like this, but only for real packaged themes submissions, not mockup, and where votes could be cast after download of the theme, the end result may be of some interest. Plus it would motivate people to actually package things. Well, IMO
[19:39] <thorwil> perhaps
[23:38] <decko> Hi guys
[23:38] <decko> Someone here working with NewHuman theme?


 How would we triage this?
[23:43] <hggdh> sccman: this is probably something that upstream will have to do.
[23:44] <hggdh> sccman: you can open (if not yet there) an upstream bug (referring to the LP one), and comment in LP that this is a feature request that upstream must consider
[23:44] <hggdh> and link the upstream bug in LP
[23:45] <sccman> How do I do that?
[23:45] <hggdh> sccman: what? open the upstream bug, link it to LP?
[23:46] <sccman> Both.
[23:46] <sccman> I'm new to everything.
[23:47] <hggdh> sccman: the fact it is a feature request does not mean it cannot have a bug on LP
[23:49] <sccman> Oh wait they forwarded it as upstream. It's an old post xD
[23:50] <hggdh> sccman: yes
[23:50] <hggdh> sccman: I re-opened it
[23:51] <sccman> Hmm
[23:51] <sccman> Why?
[23:52] <sccman> Just trying to help :)
[23:53] <hggdh> yes, and we do thank you.
[23:53] <sccman> How can I help?
[23:54] <hggdh> hold on a sec, let me get some links
[23:54] <sccman> I tried looking on the Triage page and it said to mark it as Invalid based on the chart.
[23:54] <sccman> If it's a feature.
[23:55] <hggdh> sccman: a good starting point is https://wiki.ubuntu.com/Bugs
[23:55] <hggdh> https://wiki.ubuntu.com/Bugs/Triage gives an introduction to triaging, Ubuntu-style
[23:56] <sccman> Right.
[23:56] <sccman> https://wiki.ubuntu.com/Bugs/Triage/Charts
[23:56] <sccman> It says to mark it as Invalid. How come it shouldn't be marked as Invalid?
[23:57] <hggdh> hold on, it should not say that
[23:58] <hggdh> yes, this chart is slightly outdated. We do accept feature requests as bugs, but the original poster will have to understand *we* will not work on it
[23:59] <hggdh> (apart from opening it upstream and/or linking to an upstream request
[23:59] <hggdh> this is sort of fuzzy, though. Welcome to the marvelous world of triaging