[00:00] <dub> sorry I dont have time
[00:03] <dub> I'll bypass it and let the user log one if they feel the need
[00:04] <dub> might I suggest that you dont use tcp/80 if you're not doing http and if you are use expires
[00:13] <lifeless> dub: we're doing HTTP
[00:14] <lifeless> dub: and expires is orthogonal to the issue @ hand; VCS data doesn't have a strict semantic value for expires
[00:14] <lifeless> expires wouldn't help us at all
[00:15] <dub> expires is the only way to reliably prevent caching
[00:15] <dub> in my limited experience anyway
[00:17] <lifeless> dub: no-cache does it fine
[00:18] <lifeless> we don't care if caches cache, we cache bust. We have to because there are folk that run caches that don't conform to the rfc's
[00:18] <dub> if you say so. yet you seem to have an application that causes caching issues
[00:18] <lifeless> no
[00:18] <lifeless> failing to process specific http messages != caching issue
[00:18] <dub> we cache several gbps and I dont know of other problem apps
[00:18] <dub> expires fixes all stale data type problems
[00:18] <lifeless> sure, but this is a proxy issue, not a caching issue
[00:19] <lifeless> I repeat, its not a stale data issue, not if it looks like rbistolfi's issue.
[00:19] <dub> regardless, i've spent enough time on this, thanks for your assistnace
[00:19] <lifeless> anytme
[00:19] <lifeless> please do encourage your user to file a bug
[00:21] <dub> will do
[00:43] <igc> morning
[00:44] <igc> hi lifeless
[00:44] <lifeless> hi igc
[01:10] <verterok> igc, lifeless: hi!
[01:11] <verterok> igc: OS X 10.4 DMG's uploaded. hopefully I'll get Leopard DMG for tomorrow (actually as soon I reboot my "work laptop" into OS X :/ )
[01:11] <igc> verterok: well done and thank you
[01:13] <verterok> igc: np
[01:17] <spm> lifeless: ref upgrading the bzr pqm chroot to hardy; any probs at your end if we stop pqm while the upgrade is done? or would you prefer a less intrusive cutover? I image it'd take an hour or two max.
[01:22] <lifeless> spm: stop it
[01:22] <spm> lifeless: ta
[01:22] <lifeless> spm: I presume you'll take a backup in case we have to roll back?
[01:23] <spm> lifeless: heh. 1st thing pjdc did - how big is the chroot vs how much space do we have :-)
[01:32] <verterok> igc: http://developer.apple.com/mac/library/DOCUMENTATION/Carbon/Conceptual/ProvidingUserAssitAppleHelp/authoring_help/authoring_help_book.html#//apple_ref/doc/uid/TP30000903-CH206-CIHEAADH
[01:33] <verterok> igc: ^ there is a description of the layout/format required by the Mac Help viewer
[02:02] <jrwren> dash: thanks! I'll bet uncommit is how I got multiple heads.
[02:04] <spm> lifeless: the upgrade is done. Can you fire in a trivial request so we can verify how much we've broken?
[02:11] <robert_ancell> Can anyone tell me what is wrong with the branch lp:~ubuntu-desktop/gdm/ubuntu.  When I try and push it says the branches are diverged and when I look at https://code.edge.launchpad.net/~ubuntu-desktop/gdm/ubuntu it says LP is processing changes for this branch
[02:13] <zsquareplusc> someone else seems to have pushed up new revisions
[02:14] <zsquareplusc> you probably need to "merge"
[02:14] <spm> robert_ancell: ahhh. that'd possibly be related to an issue we're having atm. see #launchpad.
[02:15] <robert_ancell> spm, ok, thanks
[02:21] <lifeless> spm: do we have python-subunit installed now?
[02:22] <spm> lifeless: indeed we do!
[02:25] <lifeless> ok,  I'll do something shortly
[02:26] <lifeless> lunch is begging first
[02:26] <fullermd> Ooh, what a good idea.
[02:31] <lifeless> http://paste.ubuntu.com/280891/
[02:31] <lifeless> I need someone to audit that
[02:31] <lifeless> I think its robust and clear; I'd like it to be moreso
[02:33] <spiv> lifeless: the layout and invariants section are inconsistent about saying MD5HASH vs. HASH
[02:33] <spiv> lifeless: the meaning of "There is always 1 and only one match for:
[02:33] <spiv> " and the following bullet list isn't obvious to me.
[02:34] <lifeless> I'll clean it up. the intent is that only one of the following statements is true
[02:34] <lifeless> I hope you have the spare cycles to also logic check it ;)
[02:34] <spiv> "- current" isn't a statement, though?
[02:34] <lifeless> its a file
[02:34] <lifeless> as per layout
[02:35] <lifeless> so 'there is a file called current'
[02:35] <lifeless> bbs
[02:35] <spiv> So just say that ;)
[02:37] <spiv> e.g. "There is always: - a file called 'current'; - exactly 1 file matching '*.check'; - exactly 1 file matching HASH.{current,delete}"
[02:39] <spiv> It might be worth saying upfront in the Invariants section if the intent is that this recovery will be performed automatically, or if it will need human intervention.  I'm guessing you intend automatic (I hope so :)
[02:42] <spiv> In the insert operations, it's not clear what "check if the insert should complete", and jumping ahead to the commentary still doesn't make it clear exactly what the check is, or what the check is for.
[02:45] <spiv> In read sequence, what about the (small) race between listing *.check and opening the result vs. another process renaming foo.check?
[02:45] <spiv> I assume the answer there is the same as in the next bullet; loop.
[02:45] <spiv> s/;/:/
[02:46] <spiv> What does "Closing a dirstate" mean?
[02:47] <spiv> What about multiple concurrent processes attempting recovery of the same dirstate?
[02:48] <spiv> Your markup is a bit inconsistent about using \n or \\n
[02:48] <spiv> Typo: "remaned"
[02:49] <lifeless> spiv: I intend to make automatic recovery possible, I don't intend to do so in the initial spike
[02:50] <lifeless> spiv: well, any policy that someone might implement, such as stat cache updates, policy checks, what have you
[02:50] <spiv> What happens in during insert if "mv current foo.check" fails (due to concurrent insert)?
[02:50] <lifeless> this is good - thanks
[02:50] <spiv> lifeless: so "don't write new file if stat cache has barely changed?
[02:51] <lifeless> more 'dont trash someone elses changes'
[02:51] <lifeless> its a critical section, the only time you can be sure noone else inserts (unless they invoke recovery concurrently, and that would be a mess
[02:52] <lifeless> so, listing *.check and the .check rename happening, - loop
[02:52]  * lifeless pages up and starts implementing improvements
[02:53] <spiv> "errors can be removed" probably should be "errors can be ignored"?
[02:57] <spiv> I'm not sure how "dont trash someone elses changes" fits with "check if the insert should complete".  If you got as far as the "rename current statefilename.check" succeeding, then as you say you're in the critical section, so how can there be other changes that could be inadvertently trashed?
[02:57] <spiv> Ok, read it all now.
[02:59] <spiv> In my ideal world, I think maybe there'd be some sort of formal proof, or at least exhaustive state diagram, to demonstrate that all states are unambiguous in the face of concurrency.  That would be a lot of work, though.
[03:00] <spiv> But it is just complex enough that I can't feel 100% sure that it's robust on a single read-through, although it seems plausible that it is.  (With some assumptions about what the FS guarantees, of course...)
[03:01] <spiv> (And I don't see any obvious simplifications you could make to the design.)
[03:02] <spiv> So, I worry a little about bugs in edge-cases.  I guess they are likely to have easy-to-repair consequences if they do happen.
[03:03] <lifeless> so stat cache updates
[03:03] <lifeless> say you have two writers A and B
[03:03] <lifeless> they both concurrently prepare an update
[03:03] <lifeless> A is doing a stat cache update
[03:03] <lifeless> we don't know what B is doing
[03:04] <lifeless> B wins the race on 'mv current HASH.check'
[03:04] <lifeless> and thus completes its insert first
[03:04] <lifeless> now, A has a new state file it wants to write
[03:05] <lifeless> so once A is in the critical section
[03:05] <lifeless> it can reliably see that the pointer has changed
[03:05] <spiv> Oh, so it's a check that the renamed current has the same pointer we think it has?
[03:05] <lifeless> if we care, yes
[03:05] <lifeless> a stat cache update cares that its unchanged
[03:05] <spiv> We need to care, I think, or else we risk losing semantic changes from B.
[03:05] <lifeless> a 'merge' or 'add' or whathaveyou doesn't care if the pointer changed.
[03:06] <lifeless> spiv: so there is a lockdir lock surrounding the WT still
[03:06] <lifeless> spiv: only one semantic writer is permitted.
[03:06] <spiv> Ah, ok.  That's worth mentioning briefly then :)
[03:07] <spiv> So a stat cache update cares that it's unchanged because otherwise there may be a semantic change from another process?
[03:08] <lifeless> right
[03:08] <lifeless> I'm writing prose about this at the top of the docstring
[03:08] <spiv> But an 'add' or whatever doesn't mind, because it will have first read the pointer inside the semantic lockdir write lock?
[03:08] <lifeless> no
[03:08] <lifeless> an add doesn't care because it is happy to trash stat cache updates
[03:09] <lifeless> and it knows noone else is allowed to be an 'add' concurrently.
[03:09] <spiv> That's what I meant!
[03:09] <lifeless> ok, but its not what you said :)
[03:09] <lifeless> [the old pointer value /doesn't matter/ to logicalwriters
[03:09] <spiv> It's inferring from its ownership of the semantic write lock that the only possible concurrent changes were stat cache only.
[03:09] <lifeless> yes
[03:10] <lifeless> thank you very much
[03:10] <lifeless> I'm sure it will need more polishing, but I feel its clearer now.
[03:10] <lifeless> and I'm glad you didn't find conceptual holes
[03:11] <spiv> That's ok, I know how hard it is to write precise and clear text about complex state machines :)
[03:11] <spiv> Not yet ;)
[03:11] <lifeless> with that, I'm going back to full screen editing;
[03:11] <lifeless> oh
[03:11] <lifeless> do you have anything that needs to land?
[03:11] <lifeless> spm needs a guinea pig
[03:12] <spiv> lifeless: Actually, I'm a little uncertain about how automatic recovery would interact with concurrent inserts.
[03:13] <lifeless> spiv: so, automatic recovery would want to be a logical writer - and thus hold the external lock
[03:13] <lifeless> There Can Be Only One
[03:13] <spiv> lifeless: i.e. how can a process tell "I need to do a recovery" apart from "another process is mid-insert"?  Via the semantic write-lock?
[03:13] <spiv> Ok.
[03:13] <lifeless> spiv: I think it boils down to time
[03:13] <spm> lifeless: is no rush; is more if we do it sooner vs later; but worst case we have a backup that can be failed to.
[03:13] <lifeless> the critical section should be _very fast_
[03:13] <lifeless> so waiting a second (say) and then offering would be appropriate.
[03:14] <spiv> "should" :)
[03:14] <spiv> Yeah, I think prompting the user is necessary.
[03:14] <lifeless> anyhow, as I say, I'm designing to permit, not to implement automatic recovery.
[03:14] <lifeless> like break-lock
[03:14] <spiv> I'm thinking someone will try this on sshfs over a crappy, slow link at some point :)
[03:14] <lifeless> the idea is to fail rarely, and only when the machine crashed
[03:14] <lifeless> or that FTP server we had the other week
[03:14] <spiv> Yep.
[03:14] <lifeless> the one that took up to 10 minutes to delete files
[03:15] <lifeless> There's a limit to which I'll design for that. Obviously-broken is not ok :)
[03:15] <lifeless> I think this will work well on windows.
[03:15] <lifeless> and Unix
[03:19] <lifeless> spiv: so, do you have any to-land branches?
[03:20] <spiv> lifeless: no, but apparently you do: https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279
[03:21] <lifeless> blah :P
[03:21] <lifeless> no I don't
[03:21] <lifeless> thats landed
[03:22] <abentley> lifeless: you gave me a "needs fixing" on https://code.edge.launchpad.net/~abentley/bzr/fix_get_mtime/+merge/10544 but I replied that the requested fix wasn't suitable.  Could you please comment?
[03:22] <spiv> lifeless: if you review https://code.edge.launchpad.net/~spiv/bzr/paramiko-keyboard-interactive/+merge/12559 I will...
[03:22] <spiv> lifeless: (it's short)
[03:22] <lifeless> abentley: will do
[03:23] <spiv> lifeless: I can easily enough make an uncontroversial branch that removes some unused import lines if you like
[03:23] <lifeless> beuno: / abentley: https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279 - why is the 'change status' edit link at the far right
[03:23] <lifeless> when on e.g. +me the edit thing is beside fields
[03:23] <spiv> lifeless: it's just a matter of pointing mwhudson's pyflakes branch at practically any file in bzrlib :)
[03:23] <abentley> lifeless: rockstar misunderstood an aspect of the 3.0 migration.
[03:23] <lifeless> ok
[03:24] <lifeless> is there a bug for that form, or would you like me to file one?
[03:24]  * spiv mumbles "affects me too"
[03:25] <abentley> lifeless: I'm not sure, but rockstar is aware that it needs to be changed.
[03:25] <lifeless> ok, no need to for pointless bit-setting then ;)
[03:25] <lifeless> spiv: doit
[03:26] <spiv> lifeless: on the trivial imports, or the paramiko (or both?)
[03:26] <spiv> (I'm doing the trivial atm :)
[03:26] <lifeless> paramiko
[03:26] <spiv> lifeless: cool, thanks
[03:29] <barry> spiv: hello!
[03:29] <spiv> barry: good afternoon :)
[03:29] <lifeless> abentley: I've commented; you may need to escalate to Martin - I think its worth writing the code to do the path calculations
[03:30] <barry> spiv: good evening :)
[03:30] <spiv> :)
[03:30] <barry> spiv: can i play dumb user and maybe we can walk through the upgrade instructions?
[03:30] <spiv> barry: I have a message from the future for you: Tuesday is a good day :)
[03:30] <lifeless> abentley: but my only data is years old now when I got close to inventory-free commits at 0.92 time
[03:30] <barry> :)
[03:30] <lifeless> beuno: have you read the upgrade guide?
[03:30] <lifeless> bah
[03:30] <lifeless> barry: ^
[03:30] <spiv> barry: sounds good.
[03:31] <barry> lifeless: sort of, but there are some holes missing that i think we should fill to make life easier for the next person
[03:31] <barry> let me bring up the instructions on this box
[03:32] <barry> spiv: let's start here: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html#migrating-branches-on-launchpad
[03:32] <barry> #1.  i nominate myself )
[03:32] <barry> er, :)
[03:32] <barry> #2.  "unset the current trunk from being the development focus"
[03:33] <lifeless> oh right, today is tuesday
[03:33] <SamB_XP_> lifeless: is not!
[03:33] <SamB_XP_> it's still monday
[03:33] <barry> spiv: i think we need a lot more detail there.  unfortunately it is not obvious how to do this on launchpad
[03:33] <barry> spiv: and, while i think i know how to do it, even then it's not 100% clear
[03:34] <barry> spiv: so, let's try to do it and then let's document it so it's really easy for the next person
[03:34] <barry> spiv: i start by going here: https://edge.launchpad.net/mailman
[03:34] <barry> spiv: i click on 'Change detals'
[03:35] <barry> spiv: i scroll down to Development focus
[03:35] <barry> spiv: i click on the pull down menu
[03:35] <barry> spiv: uh oh, i've hit my first snag.  i cannot "unset" this, i can only assign it to a different series, none of which are correct
[03:35]  * spiv tries to play along on another project on staging
[03:36]  * barry waits
[03:37] <abentley> barry: You used to be able to set the branch associated with the dev focus via the registry pages.  You could set it to blank there.  I think this has been removed in 3.0
[03:37] <spiv> barry: yeah, I see that too.
[03:38] <barry> abentley: is that hiding somewhere behind a url hack perhaps?
[03:38] <barry> abentley: iow, maybe the functionality is still there but the link to the page to do that got lost
[03:38] <abentley> barry: You would know about the secret URLs of registry pages better than me.
[03:38]  * barry has seen that in a couple of instances
[03:38] <barry> abentley: heh
[03:40] <barry> spiv: okay, so we've hit our first snag.  i'm updating my copy of the code to see if there's a hidden page somewhere for this.  if not, i will file a bug
[03:41] <spiv> barry: https://edge.launchpad.net/mailman/3.0/+edit and blank the branch, maybe?  (try on staging perhaps)
[03:41] <barry> spiv: good idea!
[03:41] <spiv> barry: I hope you're keeping notes :)
[03:41] <barry> spiv: i log all my irc sessions :)
[03:42] <spiv> Close enough!
[03:42] <rockstar> lifeless, the fix for moving change status is about to hit PQM (it's in ec2test now)
[03:42] <barry> spiv: yep, i think that's it.  https://code.staging.launchpad.net/mailman
[03:42] <barry> "A development focus branch hasn't been specified"
[03:44] <barry> spiv: iirc, i will have to push my migrated branch under a name other than "3.0" because the latter is pack-0.92 and shouldn't be changed due to any stacking going on
[03:44] <barry> spiv: so moving forward my dev focus branch will have to be something else unfortunately.  right?
[03:46] <lifeless> rockstar: cool
[03:46] <lifeless> barry: you can upgrade in-place too, which the guide doesn't documented
[03:46]  * lifeless thinks in-place is nicer
[03:46] <spiv> barry: Hmm, I'm not sure.  Launchpad might be smart enough there, but I'm not certain.  mwhudson, abentley, do you guys know?
[03:47] <lifeless> but its a problem if contributors don't upgrade their stacked branches
[03:47] <lifeless> spiv: lp doesn't rewrite the stack-on
[03:47] <lifeless> spiv: so no, its not smart enough
[03:47] <spiv> Drat.
[03:47] <spiv> mwhudson, abentley: turns out lifeless knows everything :)
[03:47] <barry> lifeless: yes, in-place would be nicer.  in this particular case, there is only one unmerged branch potentially stacked on it, and i can't merge it into my 0.92 branch anyway
[03:48] <spiv> barry: So, sadly, yes.  Unless you upgrade in-place, as lifeless says.
[03:48] <spiv> It might be good to mention that as an option in the upgrade guide, but at the same time overwhelming people with options isn't so good either.
[03:48] <barry> spiv: okay.  let's try this.  let's finish the instructions as written, and then try an in-place upgrade.  then someone <wink> can document both
[03:49] <barry> spiv: so actually, now i need to grab a copy of the trunk and do the migration.  talk to you tomorrow :)
[03:49]  * barry is guessing it will take a while
[03:50] <spiv> lifeless: btw: http://pqm.bazaar-vcs.org/
[03:50] <lifeless> barry: winking isn't gonig to help :P
[03:50] <lifeless> spiv: looks hopeful
[03:50] <lifeless> spiv: next patch, turn on --subunit ;)
[03:51] <barry> lifeless: i'll be happy to document the steps.  is doc.bazaar-vcs.org a wiki?
[03:51] <lifeless> no
[03:51] <lifeless> the upgrade guide is a branch somewhere
[03:51] <lifeless> I suspect it may even be a separate project, and if thats so I have no idea where it is
[03:51] <spiv> Isn't it part of the docs in bzr's source?
[03:51] <tedg> I need some help "decoding" an error.  http://pastebin.ubuntu.com/280929/
[03:52] <spiv> doc/en/upgrade-guide ?
[03:52] <tedg> I'm unsure of where to start looking.  I'm thinking by the 17000 number there it's looking for an older SVN revsion than I have?
[03:52] <spiv> tedg: on what command?
[03:52] <tedg> spiv: bzr gannotate configure.ac
[03:53] <SamB_XP_> tedg: it would ;-)
[03:53] <tedg> Normal annotate gives approximately the same error.
[03:53] <SamB_XP_> that, too, is expected
[03:53] <SamB_XP_> I mean, that you would get the same error
[03:53] <SamB_XP_> not that you would get an error ...
[03:53] <tedg> Oh, good. I was confused :)
[03:53] <spiv> tedg: yes, it appears that revision of that file is not present in your repo
[03:54] <tedg> spiv: So how do I decode that revision number into something useful?
[03:54] <spiv> Possibly due to a bug in the bzr-svn conversion?  /me checks if that is on Launchpad
[03:54] <spiv> tedg: not sure what you mean by "useful" in this context?
[03:54] <tedg> Well, it's not a conversion yet.  But hopefully will be soon... so I'm trying to get bugs out first.
[03:54] <SamB_XP_> whatever it is it sounds like a bug!
[03:54] <tedg> spiv: i.e., it's a missing SVN version.
[03:55] <tedg> spiv: Or, it was because I used bzr-svn to merge in a branch that somehow it figured out about.
[03:55] <SamB_XP_> tedg: how can you have a missing svn version ?
[03:55] <tedg> spiv: Or, it's just foobar :)
[03:55] <SamB_XP_> also that's spelled fubar
[03:56] <barry> lifeless: i will at least email the public mailing list when i figure it out.  can you explain "migrate in-place" though?
[03:56] <tedg> SamB_XP_: So the history of the repo is that it was converted from CVS.  But the way that SF did it is that they lumped everything into one repo, which was split out -- so there is a discontinuity around revision 20K which I believe that bzr-svn just sees as "the beginning of time"
[03:56] <lifeless> there's also a mythic button on LP that says 'doit'
[03:57] <tedg> Which honestly, is kinda fine.  As long as it's really "the beginning of time."
[03:58] <SamB_XP_> tedg: that sounds kinda crazy ...
[03:58] <tedg> SamB_XP_: People who know me, will not disagree with you on that one. :)
[03:58] <SamB_XP_> what happens if you try to checkout the previous revision with SVN itself?
[03:59] <tedg> Well, yes.  You kinda have to know the previous layout, which wasn't a "standard SVN layout" as it was in CVS.
[03:59] <spiv> tedg: so there's a missing record in bzr's database.  It's for the configure.ac file introduced in SVN 17075, and it's modification you made to it in revision<EMAIL_ADDRESS>[04:00] <spiv> tedg: I'm not sure why it's absent, but it's almost certainly due a bug somewhere along the line :(
[04:03] <tedg> Ah, I see now.  It looks like the first SVK cherry-pick is the issue: http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/configure.ac?view=log
[04:03] <tedg> Which means there are most definitely other files with this problem.
[04:03] <spiv> Oh, if you're trying to round-trip via the SVN repo, that might explain it I guess.
[04:04]  * barry -> sleep
[04:04] <spiv> That would presumably make all the foreign revisions be ghosts.
[04:04] <barry> spiv, lifeless, abentley thanks.  we'll pick this up again tomorrow.  the future awaits
[04:04] <tedg> spiv: No, not round trip in that regard.  The problem is that SVK (not SVN) did some very funny things with how it merged in.
[04:05] <lifeless> night barry
[04:05] <tedg> spiv: It records complex merges as odd copies with changes.  Borders on evil :)
[04:05] <spiv> barry: g'night
[04:06] <tedg> So if I could find all these "oddities" by hand.  Could I fix them with something like the rebase plugin?
[04:06] <tedg> If I assumed that I'd never go back to SVN again.
[04:10] <tedg> For those who are curious here's the rev where the repo was converted from CVS to SVN and rearranged: http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=10643
[04:15]  * igc lunch
[04:19] <spiv> tedg: so, that particular data appears to still exist in lp:~ted/inkscape/devbuild
[04:19] <spiv> (and some of your other Launchpad branches)
[04:20] <spiv> tedg: so if you rebranch that into your local repo that might be enough to fix it (i.e. to copy the data that is missing locally)
[04:25] <lifeless> 50% there
[04:25] <lifeless> .oO
[04:25] <lifeless> interface tests passing
[04:29] <abentley> lifeless: I've replied.  The gist is that you're asking for complicated code that will only be used in a corner case and usually won't prevent a path<->id map being generated.
[04:45] <tedg> spiv: Sorry, I walked away... I'll give that a try!
[04:46] <tedg> spiv: Just to be curious, how did you find that out?
[04:46] <lifeless> does anyone here have a windows machine?
[04:46] <rbistolfi> Peng_, lifeless: Sorry I got an emergency and I was afk
[04:46] <rbistolfi> re: http://pastie.org/633561
[04:46] <rbistolfi> I am not behind a proxy and I dont know if it is a privete branch, I just found it in launchpad
[04:47] <lifeless> rbistolfi: its not
[04:47] <Peng_> I branched it, so I guess it's not a private branch.
[04:47] <Peng_> Eh, there we go.
[04:47] <lifeless> rbistolfi: the error you have looks like a interecepting proxy to us
[04:47] <abentley> lifeless: I have a windows machine.
[04:47] <lifeless> abentley: I need to know what exception dirstate raises
[04:47] <Peng_> Or, something just went Horribly Wrong with the connection.
[04:47] <lifeless> could you do a small test for me?
[04:48] <abentley> lifeless: Okay.
[04:48] <lifeless> given a bzrlib wt4 tree at path foo
[04:48] <lifeless> state1 = bzrlib.dirstate.DirState.on_file('foo/.bzr/checkout/dirstate')
[04:48] <lifeless> state1.lock_read()
[04:48] <lifeless> state2 = bzrlib.dirstate.DirState.on_file('foo/.bzr/checkout/dirstate')
[04:49] <lifeless> state2.lock_write()
[04:49] <spiv> tedg: http://paste.ubuntu.com/280963/
[04:49] <lifeless> the last line should raise something from bzrlib.errors
[04:49] <rbistolfi> lifeless, Peng_: thanks, I will try to branch from a server I admin connected to another isp, maybe I am being intercepted after all
[04:49] <lifeless> you'll want to state1.unlock(), and you're done.
[04:49] <tedg> spiv: Didn't go well: bug 438509
[04:50] <lifeless> I should say, wt4 or newer, anything dirstate based
[04:50] <spiv> tedg: oh wow, I haven't seen that assert triggered before
[04:51] <tedg> I assume I get some kind of award? ;)
[04:51] <spiv> tedg: I wonder if that's a symptom of the same problem, I suppose it could be...
[04:51] <abentley> lifeless: I have 1.2.0dev0 on my Windows box, and it seems to be broken, too.
[04:51] <lifeless> abentley: bzrlib is broken, or the python I gave you is broken?
[04:52] <abentley> lifeless: bzrlib is broken.  "bzr init foo" fails.
[04:52] <lifeless> oh, eep
[04:52] <lifeless> abentley: is the tree you have there dirstate based? if so you don't need to init...
[04:53] <abentley> lifeless: It is a lightweight checkout from an ext3 partition which has since been reformatted.
[04:53] <lifeless> works for me
[04:53] <lifeless> as long as it has a dirstate file the results should be useful
[04:54] <lifeless> windows OS locks will mutually exclude the two locks
[04:54] <lifeless> I just need to catch the error so my test for dirstate2 doesn't blowup on windows
[04:56] <spiv> tedg: I wonder if making a new shared repository ("bzr init-repo --1.9-rich-root") and branching lp:~ted/inkscape/devbuild into that and then your other local branches would work better?
[04:56] <abentley> lifeless: I get errors.LockContention
[04:56] <lifeless> thank you very much
[04:56] <abentley> lifeless: You're welcome.
[04:57] <spiv> tedg: FWIW, bzr 2.0.0 should be much more aggressive about preventing incomplete data to be committed in the first place.
[04:57] <tedg> spiv: No, similar error.  Are the details useful?
[04:58] <spiv> Obviously that doesn't help your existing situation (unless you have a time machine), but I thought I should reassure you a little bit :)
[04:58] <tedg> spiv: I am running 2.0 now... should I reimport the repo?
[04:58] <spiv> tedg: Did it fail on the first branch?
[04:59] <tedg> spiv: I had a copy of devbuild locally in a shared repo, I then branch the branch in the new shared repo over.
[04:59] <spiv> tedg: please use the copy from Launchpad
[05:00] <spiv> Because we know that that copy has that missing record in its repo.
[05:00] <spiv> "bzr check" on your local repos might be interesting, probably it will report the same issue.
[05:01] <spiv> I just successfully branched lp:~ted/inkscape/devbuild from Launchpad, so it appears that that copy isn't missing anything that it is supposed to have.
[05:02] <lifeless> ok, dirstate2 works
[05:02] <lifeless> time to put a tree on it and user-level test it
[05:02] <spiv> lifeless: nice
[05:03] <lifeless> I just wish we'd not been scraping performance issues right up to 2.0.0
[05:03] <lifeless> this would have been so nice to have in there
[05:04] <spiv> lifeless: yeah.
[05:04] <lifeless> I've had this in my head for about a year
[05:04] <lifeless> as a 'TUIT' problem
[05:06] <rbistolfi> lifeless, Peng_: well if I tunnel my conection through Miami I can branch it just find, I think that fits well with the proxy theory. I have pretty much the same setup in both machines.
[05:06] <rbistolfi> s/find/fine/
[05:07] <Peng_> You can avoid the issue, and get a speed boost, if you get a LP account and use bzr+ssh.
[05:07] <rbistolfi> I will do, tyvm
[05:20] <tedg> spiv: Okay, so branching that way makes the error MUCH larger: http://pastebin.ubuntu.com/280979/
[05:20] <tedg> spiv: Still running the check.
[05:21] <spiv> tedg: hmm, looks like text versions from the original SVN import are missing somehow!
[05:21] <spiv> Very odd.
[05:22] <spiv> Oh, that's interesting; one way the missing text revisions were svn-v4:..., the other they are svn-v3-trunk:...
[05:23] <tedg> So could it be a disagreement between versions of the SVN plugin?
[05:23] <spiv> I wonder if a "bzr svn-upgrade" somewhere along the line is part of the cause...
[05:24] <tedg> I don't think there is a svn-upgrade.
[05:26] <spiv> Hmm, I'm sure there used to be a command that would rebase revisions from an older version of a plugin to use the new mapping.
[05:26] <spiv> s/a plugin/the svn plugin/
[05:27] <spiv> Yes, there was definitely a "bzr svn-upgrade" in the past, I wonder why it's gone now.
[05:27] <spiv> Ah, it's now "bzr foreign-mapping-upgrade"
[05:33] <tedg> spiv: I don't seem to have that command, is it in a plugin?
[05:33] <tedg> The bzr check is still running... is there a point I should give up?
[05:34] <lifeless> spiv: your patch landed?
[05:39] <tedg> spiv: It seems to be in rebase.  But I can't get it to work.
[05:40] <tedg> It basically says the SVN repository isn't a repository.
[05:40] <igc> bbiab
[05:40] <spiv> lifeless: yes
[05:41] <spiv> tedg: I'm not very familiar with it, I was just speculating that it may have been involved in the history of this branch.
[05:41] <tedg> I think I'm going to try a new import tonight with the new and shiny 2.0 and see if that helps... start fresh tomorrow.
[05:42] <tedg> spiv, thanks for your help!
[05:42] <spiv> tedg: you're welcome, sorry I couldn't be more helpful
[05:55] <lifeless> \o/
[05:55] <lifeless> WTFormat7 passes interface tests
[05:56] <fullermd> Does that mean it works right, or that the tests have insufficient coverage?  :p
[05:57] <lifeless> fullermd: bit of both
[05:58] <lifeless> fullermd: I suspect that its possible to make it delete the HASH file for the current pointer with a sufficiently clever flip-flop state change at the moment
[05:58] <lifeless> fullermd: so I want to add a random seed to the state files
[05:58] <lifeless> fullermd: or tweak that more, before folk are doing more than play with it as a shiny shiny
[06:00] <lifeless> fullermd: however, you can do a diff while a commit editor is open
[06:02] <spiv> lifeless: oh yeah, that reminds me
[06:02] <spiv> lifeless: I was also going to ask about two concurrent stat cache updates to the same state
[06:02] <spiv> Which may be why you want some random bits in the filenames?
[06:02] <lifeless> spiv: same issue ;)
[06:03]  * spiv nods
[06:03] <lifeless> yes
[06:03] <lifeless> in practice, doing 'bzr add foo' 'bzr rm foo' with no other changes can flip flop
[06:04] <lifeless> doing 'bzr diff' and keeping the process alive in a GUI in between could cause something that sees the old state around
[06:04] <lifeless> but I'm /not sure/ you can force destructive behaviour without being able to run stat fingerprints backwards
[06:05] <lifeless> I think simply putting the 'lazy delete' inside the 'I own the current file' "mutex" may be sufficient.
[06:05] <lifeless> though if we start doing that I may simply start using regular lockdirs to do the locking, though they will be a lot slower.
[06:15] <lifeless> its fun to close 6 bugs with one push :)
[06:21] <lifeless> heh, I lied, 7
[06:31] <lifeless> poolie: are you here, or is it just a bot?
[06:34] <lifeless> spiv: https://code.edge.launchpad.net/~lifeless/bzr/dirstate2 :)
[06:35] <lifeless> note the bug list ;)
[06:40] <lifeless> ahhh bugspam
[07:35] <vila> hi all
[07:57] <igc> hi vila
[07:57] <igc> out for a bit - bbl
[07:58] <bialix> hello all
[07:59] <bialix> (ru) people asking about comparison of 2a format to hg/git: storage size, speed. Is there already exists one, or planned?
[07:59] <vila> hello bialix
[07:59] <bialix> bonjour vila
[08:00] <fullermd> I'm not aware of a useful existing one.  fast-import probably makes it a lot easier to put one together though.
[08:00] <vila> igc ran tests and should have a few numbers
[08:01] <vila> but, AIUI, there is no absolute rule here, what I understand is that 2a has sizes comparable with hg/git, sometimes better, sometimes worse, but always in a reasonable amount
[08:02] <vila> for speed, things are even more unclear as benchmarks are like statistics...
[08:02] <vila> now, all of that is also highly subjective and on that front people seem quite happy :D
[08:03] <bialix> it seems so
[08:03] <bialix> but anyway I'd better asking
[08:03] <fullermd> A historical problem with those sort of comparisons is that they're often done on trees with no history.  I'd be very happy to never see such a thing again...
[08:04] <bialix> fullermd: IIUC fast-import should be a key here
[08:04] <fullermd> ("Oh, look, I benchmarked VCS A, B, and C on importing two tarballs of a project.  Now we all know what's faster and smaller.")
[08:04] <bialix> convert the same repo into different systems
[08:04] <bialix> tarball is a wrong attempt IMO
[08:04] <fullermd> Yah.
[08:04] <vila> fullermd: hmm, I don't think that's the case anymore but may be the more recent benchmarks need more exposure...
[08:05] <lifeless> I saw someone test a single commit benchmark just riday
[08:05] <lifeless> *friday*
[08:05] <lifeless> :)
[08:05] <fullermd> Yeah, they come up with painful regularity out around the Interblog.
[08:06] <fullermd> 'course, historically, we wouldn't want to argue against that, since it painted bzr in a better light than otherwise   :|
[08:07] <lifeless> by which you mean only slightly worse than tar?
[08:07] <vila> the last benchmarks igc produced showed that bzr was not the best for all operations, I think that's enough to make it an honest one :D
[08:08] <fullermd> Back around 1.0, we had claims of speed and size comparable to brands G and H.  And the benchmarks to back them up; we were of similar overall speed and similar (or better!) size on disk!
[08:08] <fullermd> ... for projects with one revision...
[08:11] <bialix> so, good benchmark will depend on how good and robust fast-import conversion
[08:12] <spiv> vila: can you help with testing my fix for https://bugs.launchpad.net/bugs/433846 ?
[08:12] <vila> spiv: I still haven't a working windows setup :-/
[08:12] <fullermd> Yah, without some way of getting as-nearly-as-practical identical sizable histories in both tools, any benchmark is going to be of very limited use.
[08:12] <vila> spiv: that what you need here right ?
[08:12] <fullermd> Luckily, fast-import fills that niche nicely   :)
[08:13] <spiv> vila: that would be ideal
[08:13] <spiv> vila: it's not really Windows-specific, but it would be nice to test a scenario as close to the actual reporters as possible.
[08:13] <spiv> vila: if you don't have working Windows I'll do some Windows-less testing myself.  Thanks.
[08:14] <vila> spiv: you're welcome :-/
[08:14] <spiv> vila: (alternatively, if you can push a button and produce a test Windows installer with that fix we can offer to the reporter, that would do ;)
[08:14] <vila> lol
[08:15] <bialix> lol
[08:15] <fm> i just hit http://pastebin.com/m6fa4b0de
[08:15] <vila> spiv: unfortunately even the installer builds are failing on kerguelen for quite a few days now :-/ And they are outdated anyway AIUI
[08:17] <fm> vila: can you look at the backtrace?
[08:17] <bialix> fm: bzr unable to version control fifo
[08:17] <fm> but it gives an internal error ...
[08:19] <bialix> file a bug please
[08:19] <bialix> bzr should not allow you to add fifo in first place
[08:20] <bialix> or maybe some of your entries was plain file/symlink and now fifo
[08:20] <fullermd> Hm, it'd be fun to be able to 'revert' a FIFO...
[08:23] <vila> fm: definitely a bug to be filed, bzr shouldn't backtrace, as a workaround, try to identify which file is a fifo and bzr ignore it
[08:23] <fm> bialix: https://bugs.launchpad.net/bzr/+bug/438569
[08:24] <vila> great
[09:00] <BjornT> jelmer: i'm trying to use bzr-git to branch from github, but after exactly 5 minutes i get this error: http://paste.ubuntu.com/281091/
[09:00] <BjornT> jelmer: do you know why that would be? i can access github using git without any problems
[10:45] <jelmer> BjornT: bzr/bzr-git doesn't support rsync-style URLs
[10:46] <jelmer> BjornT: and it is not yet possible to fetch individual branches (as we have no way to address branches that are not on the filesystem)
[10:46] <jelmer> BjornT: you might want to try 'bzr branch git://github.com/bjornt/windmill.git'
[10:47] <jelmer> BjornT: or s/branch/git-import/ (for all branches, not just HEAD)
[10:51] <Tak> jelmer: ping
[11:11] <jelmer> Tak: pong
[11:11] <Tak> hi
[11:12] <Tak> would you like for me to merge your 2.0 changes before merging 2.0 into ... what is that called, mainline?
[11:12] <jelmer> Tak: please do
[11:12] <jelmer> Tak: yeah, mainline/trunk/ whatever you want to call it :-)
[11:13] <Tak> yeah, I have a habit of referring to my development branch as "trunk", plus there's another one actually labeled "trunk" I think ... :-P
[11:13] <Tak> ok, doing that now
[11:20] <gioele> Hello
[11:21] <Tak> hello gioele
[11:25] <gioele> What is the state of keyword expansion? bzr help content-filters does not says nothing specific about keyword expansion. Also, in the wiki there are only old (2004/2005) blueprints
[11:27] <spiv> gioele: I think you need the bzr-keywords plugin (https://launchpad.net/bzr-keywords)
[11:27] <spiv> gioele: which hooks into the content filtering feature in core bzr
[11:41] <gioele> Do lightweight checkouts have to be in the same format of the remote branch?
[11:43] <beuno> gioele, it probably needs to at least be rich-root or non-rich-root
[11:43] <beuno> and, different formats will likely make it slower
[11:51] <eLBati> hi
[13:51] <eLBati> I can't understand why this happens
[13:51] <eLBati> 8# bzr checkin -vm "first translation" index.rst
[13:51] <eLBati> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~openerp-community/openobject-doc/doc/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[13:51] <eLBati> launchpad-login is set
[13:55] <eLBati> but what is checkin trying to do? shouldn't it do a local checkin?
[14:17] <eLBati> uhm it does so with every command
[14:20] <mzz> eLBati: what does "bzr info" say?
[14:20] <vila> eLBati: you created a checkout from a branch you can't commit to
[14:20] <mzz> eLBati: I'm guessing you created a checkout where you wanted a branch
[14:20] <Lo-lan-do> Hi all
[14:21] <Lo-lan-do> jelmer, james_w: I'd like to upload loggerhead to unstable and add myself as an uploader if it's all right with you.
[14:21] <mzz> eLBati: if that's indeed what happened I think you can use "bzr reconfigure" to turn it into a regular standalone branch you can commit to
[14:22] <Lo-lan-do> jelmer, james_w: Also, I'll need to get it into bpo at some point, do you have a procedure for that?
[14:22] <eLBati> mzz, yes it's a checkout
[14:22] <eLBati> so, with a checkout I can't commit?
[14:22] <mzz> eLBati: you can only commit to a checkout if you can commit to the thing it is a checkout of
[14:23] <mzz> eLBati: (it commits to the branch the checkout is "bound" to first, then locally)
[14:25] <mzz> eLBati: to avoid this use "bzr branch" (or the alias "bzr get") to create a standalone copy of the remote branch instead of "bzr checkout"
[14:26] <jelmer> Lo-lan-do: please do
[14:26] <jelmer> Lo-lan-do: we don't have any procedure for bpo uploads
[14:27] <eLBati> thanks mzz
[14:29] <Lo-lan-do> jelmer: I don't even know how to do an upload to bpo :-)  I'll read up on that.
[14:30] <james_w> hey Lo-lan-do
[14:30] <james_w> does loggerhead now use the system yui correctly?
[14:30] <Lo-lan-do> james_w: It does, but unfortunately the system yui isn't the same as the one expected by loggerhead.
[14:31] <Lo-lan-do> LH uses 3.0rc2, whereas sid only has 2.7something.
[14:32] <Lo-lan-do> So unless --use-cdn is used, some of the Ajaxy things are broken.
[14:33] <Lo-lan-do> I guess I could add a check for the presence of an appropriate version, and add the --use-cdn switch if needed.
[14:35] <eLBati> what is target configuration of bzr reconfigure?
[14:38] <Lo-lan-do> eLBati: It's what you want to turn your directory into.
[14:41] <Lo-lan-do> jelmer, james_w: Any thoughts about this automated use of remote YUI?
[14:42] <james_w> I'm not sure it would go down well in some comments
[14:42] <james_w> some contexts I mean
[14:42] <james_w> I'm not sure we should be using the system one if it is the wrong version
[14:43] <james_w> 2 and 3 are basically different projects as I understand it, so trying to force it seems unnecessary
[14:43] <Lo-lan-do> jaldhar tells me he'll upload yui 3 soonish.
[14:43] <eLBati> thanks Lo-lan-do
[14:43] <james_w> cool
[14:44] <Lo-lan-do> I guess I could revert the "use system yui" patch until then…
[14:52] <Lo-lan-do> Oh well, I'll just document the "feature" until yui3 appears, and then I'll use a versioned dependency.
[14:54] <eLBati> mzz, # bzr reconfigure --branch
[14:54] <eLBati> bzr: ERROR: Working tree "..." has uncommitted changes
[14:54] <mzz> eLBati: --standalone
[14:54] <eLBati> I just did a checkout
[14:54] <mzz> eLBati: I know. bzr reconfigure --standalone
[14:55] <mzz> or "bzr unbind", actually.
[14:57] <eLBati> thanks mzz
[15:28] <eLBati> if I have uncommited changes, how could I undo such changes and get the repository version of files?
[15:29] <dash> you can do "bzr revert" if you want to remove those changes
[15:29] <dash> or "bzr shelve" if you want to save them for later
[15:34] <eLBati> thanks
[16:04] <igc> night all
[16:14] <Tak> can one dpush from an unbound checkout?
[16:14] <jelmer> Tak: yes
[16:14] <jelmer> Tak: unbound checkout == standalone branch
[16:15] <Tak> yeah - I didn't know if there were some internal semantics that would make it work differently
[16:15] <Tak> thanks
[16:18] <mzz> an unbound (heavyweight) checkout *is* a standalone branch, so I don't know what kind of "internal semantics" you mean
[16:19] <mzz> (they're not equivalent or the like, unbinding the checkout turned it into exactly a standalone branch)
[17:00] <awilkins> Yeesh, --2a might be the New Hotness, but it repacks a lot slower than older formats
[17:01] <awilkins> It's just taken 15 minutes to repack ~800MB
[17:04] <mathrick> hi
[17:04] <mathrick> http://pastebin.com/m6d14728b
[17:04] <mathrick> what gives?
[17:04] <mathrick> it's not an error that makes any sense to me
[17:06] <Lo-lan-do> mathrick: You're in a repo, not in a branch inside that repo.
[17:07] <Lo-lan-do> The branches are probably in a subdir?
[17:07] <idnar> heh, that's ironic, I just did that myself about 2 minutes ago
[17:08] <mathrick> Lo-lan-do: oh, so that means I forgot to init that dir. No good :(
[17:08] <mathrick> thanks
[17:08] <idnar> the message is a bit confusing
[17:08] <mathrick> it is
[17:08] <idnar> although I immediately figured out my problem when I saw what directory I was in
[17:09] <mathrick> I thought I had it init'd already
[17:10] <mathrick> hmm
[17:10] <mathrick> is there an option to make bzr add symlinks by their pointed-to contents?
[17:10] <mathrick> add/commit, really
[17:11] <mathrick> oh, it's the incremental commit plugin interfering
[17:22] <Tak> hooray!
[17:23] <Tak> my mysterious bzr-svn crash was being caused by the dbus plugin
[17:28] <awilkins> ubottu: #43805
[17:28] <awilkins> ubottu: #438805
[17:28] <awilkins> Gah
[17:28] <mathrick> ubottu: bug #43805
[17:28] <awilkins> https://bugs.launchpad.net/bzr/+bug/438805
[17:29] <mathrick> hmm
[17:29] <mathrick> ubottu: bug #43805 in bzr
[17:29] <mathrick> it doesn't seem to understand that
[17:29] <awilkins> Wrong bug number ... they're globally unique per LP instance AFAIK
[17:30] <mathrick> oh
[17:30] <awilkins> Just doing a `bzr check` on the repository that's provoking the problem
[17:30] <mathrick> right
[17:30] <mathrick> okay, thanks for the help, gotta be going
[18:47] <tolstoy> Anyone having issues running on Snow Leopard using the installer?
[18:48] <tolstoy> bzr: ERROR: Unsupported protocol for url "sftp://kirwin@host/path/to/code/": Unable to import paramiko (required for sftp support): No module named paramiko
[18:53] <tolstoy> Who put together the installer anyway? No one to email!
[18:55] <kirkland> is there a way to pass -uc -us to bzr builddeb ?
[18:55] <kirkland> it didn't "just work"
[19:03] <tolstoy> jfroy|work: Hi, I'm the one with the snow leopard error from twitter.
[19:04] <jfroy|work> tolstoy: hey
[19:04] <jfroy|work> so basically I didn't include paramiko in the 10.6 installer.
[19:04] <jfroy|work> And it seems that was the wrong decision.
[19:04] <tolstoy> Yeah.
[19:04] <jfroy|work> The initial thought being that the bazaar installer should only install bazaar and nothing else.
[19:04] <tolstoy> Heh. ;)
[19:05] <tolstoy> Well, you know how people are about dependency hell.....
[19:06] <tolstoy> Seems like there should at least be enough there to support all the commands.
[19:06] <tolstoy> I just tried "bzr miss sftp://me@host:/path/to/project" and it errors out.
[19:06] <jfroy|work> well it's not that it doesn't support all the commands
[19:06] <jfroy|work> it just won't support sftp transports
[19:06] <tolstoy> Isn't sftp kind of fundamental? (I don't really know. I've always used it, though.)
[19:07] <jfroy|work> I don't use it ever.
[19:07] <LarstiQ> jfroy|work: or ssh in certain cases
[19:07] <jfroy|work> I use the smart server or work with svn repositories.
[19:07] <Lo-lan-do> Isn't "dependency hell" kind of 1998?
[19:07] <jfroy|work> Lo-lan-do: unfortunately, Mac OS X doesn't really have a good story w/r to dependency management.
[19:07] <tolstoy> Exactly.
[19:08] <jfroy|work> Well not for binary packages anyways.
[19:08] <jfroy|work> In any case, I'm going to bake another installer.
[19:08] <tolstoy> That would be awesome.
[19:09] <tolstoy> Hm. The only other thing I could think of is a bzr command to settle dependencies on its own.
[19:09] <tolstoy> Which seems kind of, well, out of scope.
[19:11] <jfroy|work> no
[19:11] <jfroy|work> a better idea would be for bzr to offer to install those dependencies
[19:12] <jfroy|work> something like "SFTP support requires Paramiko, which you do not have installed. Would you like to from PyPI? Yes | No", and if yes run sudo easy_install paramiko
[19:12] <jfroy|work> done
[19:12] <jfroy|work> that would be classy
[19:12] <jfroy|work> and broken on Linux and Windows, but that's a detail :p
[19:12] <tolstoy> Heh. Works for me.
[19:13] <jfroy|work> verterok: ping
[19:13] <tolstoy> You could even keep stats, and if practically everyone always installs paramiko, might as well bundle it in the original install.
[19:13] <verterok> jfroy|work: pong
[19:13] <jfroy|work> verterok: did you push a new packaging branch and all. Might want to rebake the 10.6 installer using that.
[19:14] <verterok> jfroy|work: I started working on something, lp:~verterok/+junk/OSX-package
[19:15] <verterok> jfroy|work: it adds the "download all stuff before build" script
[19:15] <jfroy|work> ok, I'll just use my setup for now just to quickly rebake
[19:15] <verterok> jfroy|work: ok :)
[19:24] <jfroy|work> baking....
[19:24] <jfroy|work> pretty easy to do now once that the infrastructure is in place :)
[19:25] <jfroy|work> one further improvements would be to use remote packages for optional installs (to keep the download small)
[19:25] <jfroy|work> and sign the packages
[19:25] <jfroy|work> *and another to sign
[19:30] <james_w> kirkland: "bzr builddeb -S -- -uc -us"
[19:30] <james_w> annoying I know
[19:30] <kirkland> james_w: ah, thanks
[19:30] <james_w> it will "just work" one day
[19:43] <jfroy|work> And there we go, new installer up.
[19:43] <jfroy|work> Enjoy your paramiko flavored goodness.
[19:43] <jfroy|work> tolstoy:
[19:43] <tolstoy> I'll give it a try! Thanks.
[19:44] <tolstoy> jfroy|work: http://bazaar-vcs.org/MacOSXDownloads, right?
[19:44] <jfroy|work> yeah
[19:44] <jfroy|work> it's feeding off my blog right now.
[19:44] <tolstoy> It is larger.
[19:44] <jfroy|work> which scares me :p
[19:46] <tolstoy>   from sha import *
[19:46] <tolstoy>    /Library/Python/2.6/site-packages/Crypto/Hash/SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
[19:46] <tolstoy>   from sha import *
[19:46] <tolstoy> I think it works, but there's that "interesting" output. ;)
[19:46] <tolstoy> jfroy|work: This has got to be such a headache for you.
[20:05] <tolstoy> jfroy|work: Maybe link against the Python 2.5 lib? Seems to be installed on my Snow Leopard, anyway.
[20:06] <Pilky> tolstoy: I think he links against 2.6 as that allows for 64 bit
[20:06] <Pilky> tolstoy: I think 2.5 is only 32 bit on snow leopard
[20:06] <tolstoy> Ah (drkirwin here). It seems reasonable. Wonder why there's the deprecation warning, then?
[20:07] <Pilky> could be that it is deprecated, but paramiko hasn't been updated to use hashlib?
[20:09] <fullermd> No, that's from pycrypto.  It needs a patch to not throw deprecation warnings against py2.6.
[20:09] <fullermd> It works, it's just noisy.
[20:10] <tolstoy> Right. I was able to push my changes.
[21:04] <jfroy|work> tolstoy: I target Python 2.6 on SL because it's the default interpreter and because it's 64-bit
[21:04] <jfroy|work> and bzr eats memory like candy
[21:09] <tolstoy> jfroy|work: Works for me. Well, except for those pesky deprecation warnings.
[21:14] <mwhudson> jelmer: does bzr-git support accessing git over http?
[21:17] <jelmer> mwhudson: no, not yet
[21:17] <mwhudson> rockstar: ^^
[21:17] <jelmer> mwhudson: bug 373688
[21:21] <Meths> I'm getting a file lock issue using bzr (1.18) shelve on Windows, even after a reboot, are there any known issues with shelve?
[21:30] <tolstoy> Well, gotta go.
[21:32] <tolstoy> jfroy|work: I'll see if there's a new package later this afternoon (PST) that fixes the deprecation working. I mean, if it's in the works.
[21:32] <jfroy|work> There isn't, it's a problem with PyCrypto.
[21:33] <tolstoy> Oh. So all snow leopard BZR users will have to see those messages indefinitely?
[22:01] <tolstoy> So, bzr, on snow leopard, using the installer, spews deprecation messages for every sftp operation.
[22:01] <tolstoy> How should I report that? Launchpad bug?
[22:01] <tolstoy> It's not an installer issue?
[22:06] <bialix> tolstoy: at least you can send message to main bzr ML or to bzr-mac one
[22:07] <tolstoy> Okay. I didn't realize there was a bzr-mac list. I'll look it up.
[22:48] <lifeless> moin
[22:49] <RAOF> mushi mushi.
[22:50] <lifeless> mmm sushi sushi
[22:51] <RAOF> Not for breakfast, thanks.
[23:07] <dkobozev> hi all. i have a workflow-related question.
[23:08] <dkobozev> i'm working on a php website. i have a bunch of php files that should go into public_html folder. plus, i have a database schema file and a db dump with test data.
[23:09] <dkobozev> the latter two shouldn't go into public_html, obviously. what would be the best way to manage these with bzr?
[23:12] <dkobozev> creating two separate branches - one for php files, one for db files - seems very impractical.
[23:14] <fullermd> I use a single branch, but use scripts to deploy the files that need to be deployed.
[23:15] <dkobozev> like post-commit hooks in svn?
[23:15] <fullermd> No, like Makefiles.
[23:16] <fullermd> I (speaking for nobody but myself, natch) am a firm believer in separation of VCS and deployment.
[23:17] <dkobozev> so you would keep both php and db files in public_html in my case?
[23:17] <fullermd> No, I'd keep both in the _bzr branch_.  And the bzr branch out of public_html.
[23:17] <dkobozev> got it.
[23:17] <fullermd> Then I do the equivalent of a 'make install' to copy the files into place for deployment.
[23:18] <fullermd> (though my dev environment is actually often a symlink into the subdir of the branch where the files are)
[23:18] <fullermd> But that's just local anyway.
[23:18] <dkobozev> i like the symlink idea...
[23:20] <fullermd> Yeah, it streamlines the dev process.
[23:20] <dkobozev> are there any security implications to having a symlink to a branch subdir vs copying the files to public_html?
[23:20] <fullermd> Though it sometimes requires a little fiddling, since what's in the branch isn't always directly workable (another reason for the install scripts)
[23:21] <fullermd> Well, if you copied everything under that subdir, it would be equivalent.
[23:21] <jelmer> lifeless: What's the easiest way to get my key in the PQM updated?
[23:21] <fullermd> Hard to say much beyond that; it's pretty case-by-case what exactly is where.
[23:22] <fullermd> But the root of my branches 'typically' has two dirs, a db/ where the database schema and such live, and a src/ which is roughly a mirror of how the deployed files look.
[23:23] <fullermd> (there are differences, e.g. which config files are enabled in different deployments, which the Makefiles handle)
[23:24] <dkobozev> yeah, config files is another consideration. i usually do not put them under version control at all, which is not nice sometimes.
[23:24] <fullermd> My default skeleton that I branch from for new projects has a live.conf and a dev.conf.  The install process symlinks one or the other (as appropriate) to the 'real' config file name.
[23:25] <fullermd> And in manual environments, I .bzrignore the 'real' name and symlink as appropriate, or have the code default to loading the dev if the normal name isn't there, or various other permutations.
[23:26] <fullermd> By not deploying via VCS, I'm freed from having to have the stuff under version control be an exact replica of the deployed state, which gives me flexibility for those sort of customizations.
[23:26] <fullermd> The downside, which people who swing the other way will point out, is that now I have two systems to deal with (and probably one of them to maintain myself).
[23:27] <dkobozev> what language do you use to write your install scripts? bash?
[23:27] <fullermd> For me, that's trivial overhead with big gains.  I can see that the scales may be reversed for other people.
[23:27] <fullermd> At the moment, they tend to be Makefile's, so the real work is done by gobs of standard *nix utils (mostly install(1)).
[23:28] <fullermd> Though special cases sometimes call for more specific sh scripts or throwing something together with awk or perl or...
[23:28] <dkobozev> i'd say it would have to be a pretty big project for such heavy machinery :)
[23:29] <fullermd> I do my best to slaughter all the special cases, but they keep creeping in under the door at night...
[23:32] <dkobozev> you pointed me in an interesting direction. somehow, i never considered tools such as make for web development.
[23:34] <fullermd> Always look at every possible tool for a job, and ask yourself, "Will using this make people think I'm a giant nerd?"
[23:35] <fullermd> If the answer is 'hell yeah', wallow in it   8-}
[23:36] <lifeless> jelmer: make sure its updated on the keyservers, and ping spm
[23:38] <dkobozev> true enough. but i also dislike killing flies with nukes and napalm :)
[23:39] <dkobozev> and thanks for the symlink suggestion. i'll use that or something similar.
[23:39] <jelmer> lifeless: thanks
[23:46] <fullermd> Pfft.  The surest way to kill a fly is to destroy the planet it's on!
[23:47] <abentley> lifeless: What's the correct URL to submit to the 2.0 branch?  I tried bzr+ssh://bazaar.launchpad.com/~bzr-pqm/bzr/2.0
[23:49] <lifeless> abentley: I think its http; its in the docs
[23:49] <lifeless> I'll just check my locations, one sec
[23:49] <lifeless> http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
[23:49] <lifeless> abentley: ^
[23:50] <abentley> lifeless: Thanks.
[23:50] <dkobozev> fullermd: if it's worth doing, it's worth over-doing, eh?
[23:50] <lifeless> black holes
[23:50] <lifeless> only way to be sure
[23:51] <lifeless> jelmer: bug 438959
[23:51] <lifeless> jelmer: seems valid to me: user does something, gets error.
[23:51] <jelmer> lifeless: it's still valid, but assigned to bzr
[23:51] <jelmer> lifeless: not bzr-svn
[23:51] <lifeless> ok
[23:51] <lifeless> thanks
[23:58] <jelmer> ls


[17:23] <MatthewPocock[m]> Hi - I have ubuntu studio installed, and an old mce usb midi keyboard plugged in but can't work out the voodoo needed to get everything working.
[17:24] <MatthewPocock[m]> actually, I have no sound at all right now - playing a youtube video isn't making noise
[17:26] <MatthewPocock[m]> so perhaps all audio is going to my headphone jack rather than via hdmi to my monitor?
[17:29] <MatthewPocock[m]> JACK backend is set to alsa
[17:41] <MatthewPocock[m]> ok, and the pulse audio volume control doesn't seem to know anything about any outputs either :(
[17:41] <MatthewPocock[m]> so something has broken when I installed studio - I have no idea what to try
[17:55] <JochenWonttell[m> that is many problems which may have even more reasons
[17:56] <JochenWonttell[m> maybe it's start would be to open a terminal and type lsusb to check if the keyboard is recognised by the system at all
[17:56] <JochenWonttell[m> s/it's/a/
[17:59] <JochenWonttell[m> in my experience Jack audio server and Pulse audio do not work at the same time
[19:25] <MatthewPocock[m]> the keyboard is recognised - however, it isn't even producing sound for a youtube video


[03:28] <lotuspsychje> good morning
[05:46] <marcoagpinto> The cola demon is here!
[07:43] <lordievader> Good morning
[07:44] <marcoagpinto> morning
[20:05] <oerheks> It is not Wobbly-Windows, but oke popey ... https://twitter.com/popey/status/1309432475131801600 nice feature


[08:22] -queuebot:#ubuntu-release- New: accepted libfm-qt [amd64] (impish-proposed) [0.17.1-0ubuntu1]
[08:22] -queuebot:#ubuntu-release- New: accepted libfm-qt [armhf] (impish-proposed) [0.17.1-0ubuntu1]
[08:22] -queuebot:#ubuntu-release- New: accepted libfm-qt [riscv64] (impish-proposed) [0.17.1-0ubuntu1]
[08:22] -queuebot:#ubuntu-release- New: accepted passwdqc [amd64] (impish-proposed) [2.0.2-0build1]
[08:22] -queuebot:#ubuntu-release- New: accepted passwdqc [armhf] (impish-proposed) [2.0.2-0build1]
[08:22] -queuebot:#ubuntu-release- New: accepted passwdqc [riscv64] (impish-proposed) [2.0.2-0build1]
[08:22] -queuebot:#ubuntu-release- New: accepted plasma-optimus [amd64] (impish-proposed) [21.10.0-0ubuntu1]
[08:22] -queuebot:#ubuntu-release- New: accepted libfm-qt [arm64] (impish-proposed) [0.17.1-0ubuntu1]
[08:22] -queuebot:#ubuntu-release- New: accepted libfm-qt [s390x] (impish-proposed) [0.17.1-0ubuntu1]
[08:22] -queuebot:#ubuntu-release- New: accepted passwdqc [ppc64el] (impish-proposed) [2.0.2-0build1]
[08:22] -queuebot:#ubuntu-release- New: accepted libfm-qt [ppc64el] (impish-proposed) [0.17.1-0ubuntu1]
[08:22] -queuebot:#ubuntu-release- New: accepted passwdqc [s390x] (impish-proposed) [2.0.2-0build1]
[08:22] -queuebot:#ubuntu-release- New: accepted passwdqc [arm64] (impish-proposed) [2.0.2-0build1]


[06:50] <brlin> Hello!  I would like to ask whether this is the proper channel to ask problems reguarding the ubuntu.com hosted services?  The Ubuntu Pastebin service <https://paste.ubuntu.com> to be particular?


[01:57] <nikolaptop> heey
[04:58] <ovrflw0x> should i install plasma 5 kubuntu?
[04:58] <ovrflw0x> is it buggy?
[05:09] <ovrflw0x> where is 14.10 plasma 5 kubuntu torrent?
[05:38] <Blue1> I am having trouble getting the kubuntu desktop to display on a projector -- I get this http://picpaste.com/projector-D1ds7iMg.jpg willpaper only -- it worked correctly with debian squeeze, and also with windows 7 starter -- I tried this on 2 different projectors at 2 different locations.   Does not appear to be a hardware issue.
[07:38] <ahjolinna> hello, does anyone else have problem with kubuntu 15.04 UEFI installation? it seems to install just fine but my ultrabook can't boot into it. I tried beta ISO and yesterday's daily ISO also
[07:41] <valorie> ahjolinna: there was a bug report about that in launchpad
[07:42] <valorie> it will help if you search for that and add your input
[07:43] <ahjolinna> I just hate launchpad, but fine
[07:44] <valorie> thank you for your contribution, ahjolinna
[07:53] <ahjolinna> valorie: I didn't find any bug report that reflects my problem, maybe I have to make a new one...oh sigh
[07:56] <valorie> it is worth the trouble, for sure
[07:57] <valorie> we want a perfect 15.04 rollout if possible
[08:05] <ahjolinna> valorie: I wonder what log files are needed...I haven't used ubuntu based distro in years, feels weird...I have been using chakraOS (arch'ish based) for 3 years now , but I got kicked out from the team -_-
[08:07] <valorie> well, the easiest way to file is to use `ubuntu-bug package`from the cli
[09:21] <lordievader> Good morning.
[10:20] <hoelk> The hardware mouse buttons of my thinkpad map to the wrong click events, any idea how i can reassign them?
[10:31] <v3nd3tta``> darn i cant wait for 15.04 until 23.04...
[10:34] <v3nd3tta``> i'm gonna have a taste with virtualbox ;)
[10:54] <v3nd3tta``> mh, installer - disk setup - i think kubuntu will use more than "1.0 B" x)
[11:00] <abraham> hmm..
[13:37] <BluesKaj> Hey folks
[14:19] <azack> Hey
[14:19] <azack> How come there is no torrent for kubuntu
[14:19] <azack> every other distro can be downloaded via torrent
[14:19] <azack> I am trying to get Kubuntu 14.10 64, but no torrent
[14:19] <Pici> !torrents
[14:21] <azack> That dir is empty
[14:21] <azack> wait not it's not
[14:21] <azack> I am stupid
[14:21] <azack> Does that one use Plasma 4 or 5 though?
[14:22] <soee> Utopic uses KDE 4
[14:22] <soee> Vivid Beta 2 uses Plasma 5
[14:22] <azack> but which plasma?
[14:22] <azack> Oh
[14:23] <azack> I only see beta 1
[14:23] <azack> Is there a torrent for beta 2 ?
[14:23] <azack> http://torrent.ubuntu.com/kubuntu/releases/vivid/beta-1/desktop/
[14:24] <soee> azack: yes sorry, there is only Beta 1 :)
[14:25] <azack> THanks
[14:25] <azack> I will download vivid beta 1
[14:25] <soee> sure, its pretty stable and nice :)
[14:25] <azack> I am on ElementaryOS atm
[14:25] <azack> It's a nightmare
[14:25] <azack> I do not recommend is just yet
[14:25] <soee> oh i heard a lot of good words about it
[14:26] <soee> anyway ots not for me - im KDE and Plasma lover :)
[14:26] <azack> Icons missing
[14:26] <azack> faulty fonts
[14:26] <azack> Broken settings
[14:34] <joan> how can I troubleshoot bluetooth? I'm on kubuntu 14.10 (3.16.0-31-generic #43-Ubuntu SMP Tue Mar 10), bluetooth is running, lsusb yields this: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode), but when I try to start bluetooth services (bluedevil, o transfer files service), the PC says "protocol dead unexpectedly
[14:34] <joan> To be more specific: can I try any bluetooth thing on the terminal, independently from KDE stuff?
[15:27] <joan> how can I turn on bluetooth at the task bar?
[16:04] <Walex2> joan: the KDE Blutooth frontend is one of many, and there is indeed a set of command line tools to troubleshoot
[16:04] <Walex2> joan: the ones you want to start with are 'hciconfig' and 'hcitool'
[16:06] <joan> yes, I've triedthem, but the problem seems to affect the dongle:  ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
[16:09] <joan> Walex2, indeed, I upgraded from 14.04 to 14.10 because it was apparently a kernel problem, but upgrading didn't solve the problem. And it *did* work... argh
[16:12] <Walex2> joan: in all these cases of occasional incompatibibility the best solution by far is to get another one.
[16:13] <Walex2> joan: sometimes, whether it is BT or WiFi or fancy mice etc. one has to try 2-3 before finding one without bugs or compatiblity issues.
[16:13] <joan> on the other hand, if I turn off bluetooth from the taskbar, there's no human way to turn it off, I have to hciconfig hciX reset in order to get the bluetooth icon again
[16:14] <Walex2> joan: that's indeed strange. Maybe the dongle's fimware is just buggy. Most USB sticks of any type have buggy firmware. USB firmware gets written by the lowest bidder in Taiwan...
[16:15] <joan> Walex2, yeah, but it worked like a charm after some kernel upgrade...
[16:16] <joan> Walex2, after -> *before*
[16:17] <Walex2> joan: sometimes things work randonly too.
[16:18] <joan> Walex2, yeah, that's the annoying thing, :(
[17:47] <nicofrand> hi
[17:50] <nicofrand> while doing apt-get update && apt-get dist-upgrade the update is stuck at "Found memtest86+ image: /boot/memtest86+.bin" (see: http://pastebin.com/BUNd2t5F). Does anyone has an idea on how to resolve this ? I am afraid to shutdown/reboot my computer
[18:45] <Bronze> Is kubuntu still being actively supported?
[18:45] <Bronze> last release 2013, Wiki faw page empty
[18:45] <Bronze> *faq
[18:46] <Bronze> sorry, last release May 2014
[18:49] <Pici> Bronze: Sure: http://www.kubuntu.org/
[18:50] <Pici> (I don't use Kubuntu myself though)
[18:50] <Bronze> Pici: that's where i just came from
[18:50] <Pici> 14.10 is 2014.October, not May
[18:51] <Bronze> Kubuntu 14.04 LTS Submitted on Thu, 2014-04-17
[18:52] <Bronze> late tentry on http://www.kubuntu.org/news/kubuntu-14.04
[18:53] <nicofrand> no one can help me with my linux-image issue ?
[19:07] <afteoyo_> Hello
[19:07] <afteoyo_> I am trying to install Kubuntu 14.10 Plasma 5
[19:07] <afteoyo_> When I boot from my live usb I get this http://i.imgur.com/cWSj4Ih.png
[19:08] <afteoyo_> I tried startx but that didn't works
[19:08] <BluesKaj> afteoyo_, which method are you using?
[19:08] <afteoyo_> What do you mean by method?
[19:09] <afteoyo_> I am booting from a USB
[19:09] <afteoyo_> defualt method
[19:09] <afteoyo_> there is no compatibility method
[19:11] <afteoyo_> !PLEH
[19:12] <BluesKaj> afteoyo_, which image did you choose for the usb ?
[19:12] <afteoyo_> Kubuntu 14.10 Plasma 5 64bit
[19:12] <BluesKaj> and how did you install it on th eusb?
[19:13] <BluesKaj> usb rather
[19:13] <afteoyo_> Universal USB installer
[19:13] <afteoyo_> A programm for windows
[19:13] <BluesKaj> best to use dd
[19:13] <afteoyo_> ?
[19:14] <BluesKaj> on 14.10
[19:14] <afteoyo_> I am on Win7 atm shoudl I boot into my elementaryOS partition?
[19:14] <BluesKaj> so you don't have 14.10 installed at all yet
[19:14] <afteoyo_> so I can dd it?
[19:15] <afteoyo_> I do not like elementary OS
[19:16] <BluesKaj> does elemntary have disk creator ?
[19:17] <BluesKaj> never mind dd for now
[19:17] <afteoyo_> Okay I will try 15.04 Plasma 5 first, if that fails I will resort to the dd
[19:24] <aftereyo> BluesKaj, 15.04 Gave me the same error
[19:24] <aftereyo> I will try thy the dd method
[19:25] <BluesKaj> do you have infop about how to use dd?
[19:25] <aftereyo> I have the man pages :D
[19:25] <BluesKaj> info
[19:25] <BluesKaj> ok
[19:25] <aftereyo> And as usual I only need about 1% of the man pages info
[19:26] <aftereyo> Wow, that is a lot of information
[19:28] <BluesKaj> a suggestion, dd if=/dev/cdrom of=/dev/usb/kubuntu.iso bs=1M
[19:29] <aftereyo> I am following this guide http://askubuntu.com/a/376430
[19:29] <BluesKaj>  /dev/cdrom is the source in this example it, probly in your Downloads file
[19:30] <BluesKaj> ok if you wish
[19:31] <aftereyo> I just don't want to burden you already, :D I am sure I will desire your help at a later point
[19:38] <aftereyo> Hmm
[19:38] <aftereyo> my usb drive is not mounted at /media
[19:39] <joan> Oh come on, I had to fool my Xiaomi Redmi Smartphone to accept .epub files from kubuntu 14.10
[19:39] <joan> transfer them as pdf and then rename
[19:41] <aftereyo> Where would my usb be mounted BluesKaj ?
[19:43] <aftereyo> do I want to mount to sdb or sdb1?
[19:44] <bprompt> joan:   over usb-storage transfer?
[19:45] <aftereyo> going with sdb
[19:45] <aftereyo> command is running?
[19:45] <aftereyo> Am I not supposed to see any output?
[19:49] <BluesKaj> aftereyo,  from which command?
[19:50] <aftereyo> dd
[19:50] <aftereyo> sudo dd if=/dev/sdb of=kubuntu-15.04-beta1-desktop-amd64.iso bs=1M
[19:53] <bprompt> ?
[19:54] <BluesKaj> aftereyo, that command should take only about 10 mins or less to finish
[19:55] <aftereyo> It just finished
[19:55] <aftereyo> How can I verifiy it worked correctly?
[19:58] <bprompt> aftereyo:    you could always try to mount it, with -> mount -o loop YOURFILE.iso  /mnt  <--- then "cd" to it and check it about
[19:58] <aftereyo> Okay, I will boot into it
[19:58] <aftereyo> 15.04, risky frisky
[19:58] <aftereyo> plasma 5 risky ^ 2
[19:59] <bprompt> aftereyo:    what are you doing anway?    burning an .iso to a usb stick?
[19:59] <aftereyo> Making a boot able usb
[19:59] <bprompt> sudo dd if=/dev/sdb of=kubuntu-15.04-beta1-desktop-amd64.iso bs=1M   <--- looks more like  you're dumping a usb stick into an .iso, which is not really the same thing
[20:01] <aftereyo> OMG
[20:01] <aftereyo> what did I do?
[20:01] <aftereyo> mayor@oxen:~/Downloads$ sudo dd if=/dev/sdb of=kubuntu-15.04-beta1-desktop-amd64.iso bs=1M
[20:01] <aftereyo> 15073+0 records in
[20:01] <aftereyo> 15073+0 records out
[20:01] <aftereyo><PHONE_NUMBER>8 bytes (16 GB) copied, 616.672 s, 25.6 MB/s
[20:01] <unopaste> aftereyo you have been muted for 60 seconds as it looks like you are pasting lots of lines into the channel, please use http://paste.ubuntu.com and paste just the URL of your data here when you are unmuted
[20:03] <aftereyo> Yep, the iso file is now 16gb,
[20:03] <aftereyo> which was the size of the usb driver
[20:03] <bprompt> 16gbs of "blank" pretty much, since "dd" transfers cluster by cluster, regardless of content size
[20:04] <aftereyo> Yeah, Now I have to re download the torrent
[20:04] <aftereyo> thanks for pointing that out
[20:04] <bprompt> hmmm
[20:04] <bprompt> you didn't use a copy of it?   tsk tsk tsk
[20:04] <aftereyo> I wasn't expecting for this
[20:05] <bprompt> If you don't learn life's simple law, your well being will suffer many flaws. For, if you always believe what you've always been taught, you 'll always think what you've always thought and you'll always do what you've always done and you'll always get what you always got.   ~~ T. Fry ~~
[20:07] <aftereyo> I will keep that in mind bprompt
[20:07] <BluesKaj> ok back, got a memory leak in 15.04, after the latest kernel version upgrade
[20:08] <BluesKaj> RAM was maxed out
[20:08] <bprompt> "is Ryback dead?" ... "yes" ... "did you see the body?"    "hmm nope, I assume he was because ...."    "never assume, assumption is the mother of all messups"   ---- steven seagal's movie
[20:08]  * bprompt ducks
[20:09] <aftereyo> BluesKaj, did you hear?
[20:09] <aftereyo> I copied the USB drive into the ISO instead
[20:09] <aftereyo> so back to square one
[20:09] <aftereyo> Is this a sign I am not ready 15.04 plasma 5?
[20:09] <aftereyo> Someone tell me I am in way over my head
[20:10] <bprompt> aftereyo:    A pessimist see the difficulty in every opportunity; an optimist see the opportunity in every difficulty.   ~~  Winston Churchill ~~
[20:10] <aftereyo> bprompt, you recite many wise things, but none of them are yours ;)
[20:11] <bprompt> well, the steven seagal one, was sorta, not really, it was in the movie :P
[20:11] <bprompt> aftereyo: We should be careful to get out of an experience only the wisdom that is in it - and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one anymore. ~~ Mark Twain ~~
[20:11] <bprompt> heheehe
[20:12] <bprompt> aftereyo:   to err, is to learn, just get it again, make a copy, use that, and redo the "dd" :)
[20:12] <BluesKaj> aftereyo, no you just need to make sure to copy just the image/iso file to the usb stick
[20:13] <aftereyo> "Trust, but verify."  ~~ Ronald Reagan ~~
[20:13] <BluesKaj> bprompt, your example is a helluva way to learn:)
[20:13] <aftereyo> I should have double checked your sample command BluesKaj
[20:13] <bprompt> aftereyo:     the redownload may take .... say  dunno 2hrs... so.... hey! remember you wanted to watch "The English Patient" again?   well, just go get some popcorn, when he gets out of the desert, the torrent will be done =)
[20:14] <bprompt> BluesKaj:  =)
[20:14] <BluesKaj> not my style
[20:14] <aftereyo> I am not familiar with the show
[20:14] <bprompt> aftereyo:   ok.. "Forrest Gump" then
[20:14] <aftereyo> Oh I see bprompt you are saying I shouldn't jsut give up.
[20:15] <bprompt> aftereyo:   We should be careful to get out of an experience only the wisdom that is in it - and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one anymore.      ~~ Mark Twain ~~
[20:15] <aftereyo> bprompt, seen it once already
[20:15] <aftereyo> I want to wait before I see it again
[20:15] <aftereyo> so I can enjoy it in all of its beauty again
[20:17] <aftereyo> bprompt, are you in the US?
 "Trust, but verify."  ~~ Ronald Reagan ~~     <---- sounds like " I love you honey, now if you just sign this prenuptial agreement"
[20:19] <aftereyo> That's a far stretch
[20:20] <bprompt> yes, us west coast =)
[20:21] <aftereyo> Cool
[20:21] <aftereyo> I want to move to the west coast one day
[20:21] <aftereyo> I am sick of the East coast
[20:23] <aftereyo> 20 minutes on the download
[20:24] <aftereyo> would 15.04 P5 be more stable than 14.10 P5?
[20:25] <bprompt> let's see... we're in 03-15....  and this is 15.04   hmmm, wild guessing... I'd think not, then again, that's the norm
[20:28] <aftereyo> I really just want P5 on an ubuntu based distro
[20:28] <aftereyo> Even debian based would be fine
[20:29] <BluesKaj> ubuntu is debian based
[20:29] <aftereyo> I know
[20:31] <aftereyo> If I want P5 couldn't I just use Linux Mint 17.1 and install plasma5? on that
[20:33] <BluesKaj> maybe, dunno much about mint
[20:34] <OerHeks> Mint is slower.
[20:34] <aftereyo> nope,  I cannot
[20:35] <aftereyo> OerHeks, why do you think that?
[20:35] <BluesKaj> if you have kde on mint it might be
[20:38] <aftereyo> I think I will install Kubuntu 14.10 P4 and then upgrade to P%
[20:38] <BluesKaj> aftereyo, https://forum.kde.org/viewtopic.php?f=289&t=122157
[20:40] <aftereyo> Oh boy
[20:40] <aftereyo> I think I must wait
[20:40] <aftereyo> P5 is not stable enough yet
[20:42] <BluesKaj> done for the day here...later
[20:45] <aftereyo> bye
[20:48] <bprompt> aftereyo:    bear in  mind that 15.04   stands for "20"15   and 04"th month of the year", we're in march, or the 3rd one, thus
[20:52] <joan> bprompt, bluetooth transfer
[20:53] <joan> bprompt, there must be any file blocking feature activated
[20:54] <bprompt> joan:   on the phone, maybe..... iirc    the bluetooth doesn't concern with any file extensions or types
[20:55] <joan> bprompt, yes, that's my guess too, I'll have to investigate it, but I *hate* this gadgets, argh!
[22:42] <vbgunz> anyone know why I changed out my gtx 570 to a 960 and the 960 refuses to use the nvidia binary driver? I open driver manager and nothing shows up in there? I removed everything nvidia and reinstalled but I just can't use the driver. anyone know why?
[22:49] <Kaliraa> vbgunz: Did you install the proprietary driver from Nvidia's website, or from Muon?
[22:49] <vbgunz> from the terminal
[22:49] <vbgunz> pretty much install nvidia 331
[22:49] <Kaliraa> I mean
[22:49] <Kaliraa> From the Ubuntu repos, though, right?
[22:49] <vbgunz> yeah
[22:49] <soee> vbgunz: what Kubuntu version, are you using 2 gpus or one
[22:50] <vbgunz> 14.10, 1 gpu
[22:50] <vbgunz> hmm, when I open the driver manager nothing pops up in there, that's gotta be broken right?
[22:52] <soee> vbgunz: shoudl work in 14.10
[22:53] <vbgunz> yeah, sucks, I'm gonna test a usb stick of plasma 5
[23:03] <valorie> oh my, the next ppa is deprecated - we should never tell people to use it