[11:36] <ghostcube> Hi folks, tried to install Kubuntu 21.04 oldschool, by using a DVD, i tried to install with enabled secure boot on a not used ssd, windows uses another ssd. But thats not the Problem, the dvd isnt booting into installer it just stops because of kernel errors. Anything known about installing on a Gigabyte Aorus Ultra X570 Chipset?
[11:36] <ghostcube> Fastboot and everything else inside bios and windows arew disabled and shouldnt effekt the boot prozess cause its just another ssd thats getting used
[12:07] <BluesKaj> Hi all
[12:44] <user|52> how to start surfshark vpn?
[13:43] <mparillo> https://www.google.com/search?q=how+to+start+surfshark+vpn+linux ?


[15:38] <mup> Bug #1786965 opened: juju deploy bundle model comparison doesn't take into account still-deploying units <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1786965>
[15:38] <mup> Bug #1786967 opened: Cannot target zone constraints in juju deploy bundle with MAAS provider <juju-core:New> <https://launchpad.net/bugs/1786967>
[22:30] <mup> Bug #1786965 changed: juju deploy bundle model comparison doesn't take into account still-deploying units <bundles> <canonical-bootstack> <juju:Triaged> <https://launchpad.net/bugs/1786965>


[03:34] <FloatingGoat> holstein:
[03:34] <FloatingGoat> cool
[03:35] <holstein> FloatingGoat: yo
[03:35] <FloatingGoat> just got a record player
[03:36] <holstein> nice
[03:36] <FloatingGoat> I think I need a pre-amp though
[03:36] <holstein> i got one of those things that allows a record player to go to a normal input
[03:36] <holstein> FloatingGoat: hehe
[03:36] <holstein> yeah, i have that thing you need
[03:36] <holstein> i got 2 of them
[03:36] <holstein> i just cant find the other one
[03:36] <FloatingGoat> i buy
[03:36] <FloatingGoat> haha
[03:36] <holstein> yeah... they are cheap
[03:36] <holstein> i dont think you want to cover shipping
[03:37] <holstein> im in NC
[03:37] <holstein> asheville
[03:37] <holstein> where are you?
[03:37] <FloatingGoat> NC?
[03:37] <FloatingGoat> i mean
[03:38] <FloatingGoat> north carolina
[03:38] <FloatingGoat> im in MN
[03:38] <holstein> yeah, i dont think you want to pay shipping
[03:38] <holstein> i think you can get one for cheap
[03:38] <FloatingGoat> 20 bucks
[03:38] <FloatingGoat> also
[03:38] <holstein> or, just get an amplifier with phono input
[03:38] <FloatingGoat> postal service>shipping
[03:39] <holstein> a stereo amplifier
[03:39] <FloatingGoat> hmm
[03:39] <FloatingGoat> almost good idea
[03:39] <FloatingGoat> but we dont have that kind of space
[03:39] <holstein> ive tripped over functional ones of those near trash cans
[03:39] <holstein> FloatingGoat: for free?.. you might make space for free :)
[03:39] <holstein> anyways.. you got options
[03:39] <FloatingGoat> haha
[03:39] <FloatingGoat> where do i get this amp for free?
[03:40] <FloatingGoat> would a guitar amp work also?
[03:40] <holstein> hell, ive thrown one out
[03:40] <holstein> FloatingGoat: nope
[03:40] <holstein> look on craigslist too
[03:40] <holstein> local
[03:40] <FloatingGoat> welp
[03:40] <holstein> shipping is what'll kill you on this piddly stuff
[03:40] <FloatingGoat> could get a behringer amp with audiophile rave reviews, 20 bucks
[03:40] <holstein> you want a phone gain balancer or whtaever its called, or something with a phono out
[03:40] <FloatingGoat> i mean
[03:40] <FloatingGoat> pre-amp
[03:41] <holstein> FloatingGoat: nah
[03:41] <holstein> that wont do it
[03:41] <holstein> i mean, get it if you need it
[03:41] <holstein> but thats not what you need
[03:42] <FloatingGoat> http://www.amazon.com/Behringer-PP400-Ultra-Compact-Phono-Preamp/dp/B000H2BC4E/ref=pd_cp_e_1
[03:42] <holstein> this is what i have 2 of
[03:42] <holstein> http://www.amazon.com/gp/aw/d/B00005T3FF
[03:42] <holstein> FloatingGoat: OH yeah
[03:42] <holstein> that'll do it too
[03:42] <holstein> i was thinking of other behringer gear
[03:42] <FloatingGoat> it has 5/5 across the board
[03:43] <FloatingGoat> is 20 bucks worth it?
[03:44] <holstein> eh, not bad
[03:44] <holstein> whats shipping?
[03:44] <holstein> free?
[03:44] <holstein> you can probably fool around and find something cheap/free that'll do it
[03:44] <holstein> but that'll be fine and dandy
[03:45] <holstein> you'll never sell it
[03:45] <holstein> but, its only 20 bucks
[03:46] <FloatingGoat> wellp
[03:46] <FloatingGoat> gettin real close to
[03:46] <FloatingGoat> a record player
[03:46] <FloatingGoat> worth 80 bucks
[03:46] <FloatingGoat> that wont sell like that
[03:46] <FloatingGoat> sorry was flippin the disk
[03:46] <FloatingGoat> I do it with care!
[03:47] <holstein> hehe
[03:47] <FloatingGoat> welp yeah
[03:47] <FloatingGoat> i mean at this rate maybe i should have bought the AT in the first place
[03:48] <FloatingGoat> only 40 bucks into this thing though
[03:48] <FloatingGoat> the unit itself i got from a guy down the street
[03:48] <FloatingGoat> 25 bucks
[03:49] <FloatingGoat> then i bought a new catridge, stylus, and headcase. 15 bucks (no lie)
[03:50] <holstein> yeah... i gave up on vinyl years ago
[03:50] <holstein> too big, and too much stuff to keep up with
[03:50] <FloatingGoat> im just gettin started!
[03:50] <FloatingGoat> too big?
[03:50] <holstein> go for it !
[03:50] <holstein> yeah... data is really small :)
[03:51] <FloatingGoat> indeed
[03:51] <FloatingGoat> idk
[03:51] <FloatingGoat> i like it
[03:51] <FloatingGoat> like playing it
[03:51] <FloatingGoat> like listening
[03:51] <FloatingGoat> hey
[03:51] <FloatingGoat> have you heard of turntable?
[03:52] <holstein> yup
[03:53] <holstein> 2 turntables and a microphone...
[03:53] <holstein> i thought thats what you were talking about
[03:53] <holstein> a record player
[03:53] <holstein> phonograph?
[03:53] <holstein> maybe those are not all quite the same thing
[03:53] <FloatingGoat> no
[03:53] <FloatingGoat> turntable.fm
[03:54] <FloatingGoat> http://turntable.fm
[03:55] <holstein> oh... lol
[03:55] <holstein> havent heard of that
[03:55] <holstein> is that re-recorded vinyl?
[03:56] <FloatingGoat> nope
[03:56] <FloatingGoat> its where you play songs in your personal collection
[03:56] <FloatingGoat> in front of people
[03:56] <FloatingGoat> and they judge you
[03:57] <FloatingGoat> or judge the song
[03:57] <FloatingGoat> you get points if they think its awesome
[03:57] <FloatingGoat> sounds simple and maybe a little dumb, but its damn addicting
[03:57] <holstein> lol
[03:57] <holstein> you get judged playing music?
[03:57] <FloatingGoat> well
[03:57] <FloatingGoat> like
[03:57] <FloatingGoat> you can play your own songs
[03:57] <holstein> like, playing other peoples music?
[03:57] <FloatingGoat> or
[03:58] <holstein> like a mix tape?
[03:58] <FloatingGoat> yeah other peoples
[03:58] <FloatingGoat> you have a queue
[03:58] <FloatingGoat> you can upload songs
[03:58] <FloatingGoat> or use the ones on turntable
[03:58] <FloatingGoat> which they have a nice selection
[03:58] <FloatingGoat> you just have to try it
[03:59] <FloatingGoat> you also get to hear a lot of new music
[04:02] <FloatingGoat> holstein: you take turns playing
[04:02] <holstein> interesting
[04:04] <FloatingGoat> all im saying is dont try it unless you got time
[04:04] <holstein> hehe
[04:16] <FloatingGoat> you like ulrich schnauss?
[04:17]  * holstein checking out 'clear day'
[04:18] <FloatingGoat> lol
[04:19] <FloatingGoat> I havent heard that one
[04:19] <FloatingGoat> i recomend
[04:19] <FloatingGoat> goodbye
[04:19] <FloatingGoat> stars
[04:19] <FloatingGoat> between us and them
[04:19] <FloatingGoat> as if you've never been away!
[04:19] <holstein> now im checking out 'a million miles away'
[04:19] <holstein> yeah, not bad
[04:20] <holstein> im not crazy about that whole genre
[04:20] <FloatingGoat> havent heard that either
[04:20] <holstein> really doesnt move me much
[04:20] <holstein> but, its good
[04:20] <FloatingGoat> Blumenqiese neben autobahn is what got me into it
[04:20] <FloatingGoat> what kind of genre?
[04:20] <holstein> techno-ish pop loop or whatever
[04:21] <FloatingGoat> hmm
[04:21] <FloatingGoat> i think its more melodic centered
[04:21] <FloatingGoat> i mean
[04:21] <holstein> sure... im just an acoustic guy
[04:22] <holstein> i mean, i can recognize, and appreciate good music
[04:22] <holstein> but, gun to my head, its not my thing
[04:22] <FloatingGoat> ulrich hater!
[04:22] <FloatingGoat> lol
[04:22] <FloatingGoat> well
[04:22] <FloatingGoat> try the song on my own
[04:22] <holstein> lol
[04:22] <FloatingGoat> its a bit diff
[04:23] <FloatingGoat> holstein: http://www.youtube.com/watch?v=QT4lVohBh0I
[04:24] <holstein> the acoustic-pop loop or whatever ;)
[04:24] <holstein> nah.. im kidding
[04:24] <holstein> i like that OK
[04:27] <FloatingGoat> haha
[04:27] <FloatingGoat> the guy comes off as a bit of a bunghole
[04:27] <FloatingGoat> I got him on facebook and stuff
[04:27] <holstein> maybe just something inpersonal about the video
[04:28] <holstein> oh... i see
[04:28] <holstein> other places
[04:28] <FloatingGoat> but its a real good musician non-the less
[04:29] <FloatingGoat> you wouldnt think because of his rough beginings.
[04:29] <holstein> yeah, he can play
[04:30] <FloatingGoat> moved from iran, to germany, to the US, deported from the US in 2001 cause of where he is from.
[04:30] <FloatingGoat> finally gaining canadian citizenship
[04:30] <FloatingGoat> but not allowed back into US for quite a time
[04:31] <FloatingGoat> he was deported because of 911 to clarify
[04:31] <FloatingGoat> anyway yeah he can play
[04:44] <FloatingGoat> holstein:
[04:44] <FloatingGoat> what do i do when my needle gets dust on it?
[04:56] <holstein> FloatingGoat: you clean it right?
[04:56] <holstein> we had a velvet thingy
[04:56] <holstein> not sure what that was for though
[04:56]  * holstein shrugs
[07:43] <tlm> Weird can't get sound out of either the speakers or headphone jack on an Acer Travelmate 2413LCi, LSHW = http://pastebin.com/dT4aHNbk I found it junked, replaced the Broadcom wifi with an Intel card, oddly, the ethernet jack also doesn't work, not recognized by the router.
[14:00] <holstein> tlm: could be the motherboard is bad then
[14:02] <holstein> i would check out a LIVE cd... i usually use a few different ones... the normal buntu LIVE cd (usually the latest and the LTS) and knoppix. i would run lspci see if it shows up there, then aplay -l and arecord -l
[14:02] <holstein> i would also see if i could get the system itself to make sound (like in the bios) before the OS boots
[14:02] <holstein> i wouldnt expect much with JACK + the netbook
[14:03] <holstein> i use it, but not for anything that requires low latency
[14:03] <holstein> since you dug that out of the trash, mabye get you one of thesehttp://www.behringer.com/EN/Products/UCA202.aspx
[14:04] <holstein> assuming the USB works, or put it back where you found it ;)
[14:04] <holstein> i just bought a few used netbooks for around $125 US on craigslist
[19:32] <joao> hi, daughter loves openshot...did a movie teaching our dog the jumping trick and asks to do to the time freeze special effect
[19:33] <joao> I am looking for other editing app but can't find one, maybe this is called something else.TIA
[21:24] <holstein> joao: ?
[21:24] <holstein> another video editing application?
[21:25] <holstein> you should be able to open the software center, or whatever else you use to manager pacakges (synaptic for example) and search for a video editor
[21:26] <holstein> pitivi, kino, virtualdub... also jaycut online are a few i have messed with
[22:02] <tlm> Weird can't get sound out of either the speakers or headphone jack on an Acer Travelmate 2413LCi, LSHW = http://pastebin.com/dT4aHNbk APLAY and LPCI = http://pastebin.com/1TtPGvAA I found it junked, replaced the Broadcom wifi with an Intel card, oddly, the ethernet jack also doesn't work, not recognized by the router.
[22:14] <joao> holstein, sorry
[22:15] <joao> the problem is to find one that does the freeze special effect and rewind


[09:11] <killermoehre> hi. at $COMPANY, we use bazaar for our internal development. now the problem appeared, that some repository needs over 500 seconds to download, while the cli says: "Inserting stream:Estimate 751/2255" with no progress. AFAIK any other repository runs well. any advice?
[09:13] <fullermd> What's it doing during that time?  Churning the disk, slamming the network, chewing the CPU?
[09:14] <killermoehre> fullermd: nothing. it takes it RAM share at the repo server (the checkout is via the ssh transport), but the disk and network is idling
[09:14] <killermoehre> no cpu usage, too
[09:15] <killermoehre> fullermd: you could think someone stopped the job (no, nobody does this)
[09:16] <fullermd> Check both server and client side?
[09:16] <killermoehre> fullermd: both server and client side
[09:17] <killermoehre> fullermd: would you mind to prefix posts for me with my username, so I get a higlight? this would be really nice :)
[09:22] <killermoehre> fullermd: at the server side, the .bzr.log with some debug flags says "Adding the key (<bzrlib.btree_index.BTreeGraphIndex object at 0x22e7f10>, 23942126, 8836427) to an LRUSizeCache failed. value 62761550 is too big to fit in a the cache with size 41943040 52428800", client says "inserting substream: texts", after that both went idling
[09:24] <fullermd> killermoehre: What, to sort it out from all the other conversations happening here?   :p
[09:25] <fullermd> killermoehre: I'm pretty sure that's more of a diagnostic message than an error, so probably ignorable.
[09:26] <fullermd> killermoehre: Still, I have a hard time imagining how both sides could be sitting around doing nothing.  Something's waiting on something.2, and that's either because something.2 is feasting on some resource, something is broken, or things are deadlocked.
[09:26] <fullermd> If (3), then it'll never get anywhere, and points to a ginormous bug.  I doubt it.  (2) is always possible, but is also ginormous bug I haven't seen.  So I'm guessing (1) is the case somewhere.
[09:27] <killermoehre> fullermd: I don't see the numbers you're referring ^^
[09:28] <fullermd> killermoehre: Just the 3 things I mentioned in the prior line.
[09:32] <killermoehre> fullermd: well, I don't see any kind of resource usage, but maybe you can hint me something. the server is a debian7 with bzr 2.6.0dev2, the clients are very different, but features all the same problem, so I think it's a problem with the server.
[09:33] <killermoehre> and now I see with a test at the server, that a local checkout hangs, too
[09:34] <fullermd> top for CPU, iostat for disk, netstat for network.  The more other stuff is being done by the system, of course, the harder to sort out what's happening with bzr itself...
[09:34] <fullermd> If something's memory constrained, there's always the chance it's falling into swap.  That would completely tank performance, but you'd probably notice the pagein/out activity pretty easily.
[09:35] <killermoehre> fullermd: yeah, 100% cpu! success, I found something
[09:35] <killermoehre> and constant growing RAM usage
[09:35] <killermoehre> or not
[09:35] <killermoehre> but enough RAM usage
[09:35] <zyga> killermoehre: what is the version of the repository you are branching from?
[09:35] <zyga> killermoehre: maybe you can upgrade / pack it?
[09:36] <killermoehre> to be fair, this is a VM with 476MB RAM
[09:36] <fullermd> Well, 2000-some texts isn't particularly large, so it's probably not a pure history size filling stuff up.  Big files in the history?
[09:36] <killermoehre> fullermd: how can I check? I'm only the admin, I don't use bzr very often
[09:36] <fullermd> That _is_ a bit tight RAMwise by modern standards.  'course, it's enough if it's not paging in and out of swap, but it probably can still kill your page cache etc...
[09:37] <fullermd> killermoehre: Well, by just knowing what's in the code/whatever is being versioned.  Images, binaries, ISO's, core dumps, etc?
[09:37] <killermoehre> fullermd: should be just php code
[09:37] <fullermd> 2000 texts of program source code is tiny, but if it's multi-meg images, that's a whole 'nother matter.
[09:39] <fullermd> After doing a branch, you should have a repo with a single pack in it.  How big is that pack?
[09:39] <killermoehre> fullermd: pack?
[09:40] <fullermd> ll .bzr/repository/packs/
[09:41] <killermoehre> fullermd: 32MB
[09:42] <fullermd> OK, even a 2002-era memory size shouldn't have too much trouble with _that_.
[09:42] <fullermd> So let's look at zyga's first suggestion; format mismatch.  Look at 'info' on the source repo, see what format it says it's in.
[09:43] <killermoehre> fullermd, zyga: format says 2a
[09:45] <fullermd> Well, that should be OK, unless you're branching it in _to_ an old format repo, which is pretty unlikely.
[09:45] <fullermd> (would probably take some conscious effort to squirrel things up)
[09:45] <killermoehre> fullermd: I don't think so I do this with a new checkout
[09:54] <fullermd> killermoehre: Well, that's all my particularly good ideas.  It's not a tiny repo, but it's not huge either, so I wouldn't expect massive waits on it putting stuff together.
[09:54] <fullermd> Of course, VM does mean all kinds of constrained environment, so "all the CPU available for a long time" might not really be all that much in larger terms...
[09:55] <killermoehre> fullermd: as I said, I don't see anything in vmstat, too
[09:56] <killermoehre> zyga: do you have another idea?
[09:56] <zyga> killermoehre: not really
[09:57] <zyga> killermoehre: try bzr pack on the remote end
[09:57] <zyga> killermoehre: see if that helps
[09:57] <fullermd> VM as in virtual machine; the CPU churnings in top.
[09:57] <zyga> killermoehre: use a shared repo locally to avoid the traffic in the first place
[09:57] <killermoehre> zyga: well, we have multiple developers and they want to checkout the repo first to have it local ^^
[09:58] <fullermd> For comparison, here's a local repo I have of a project full of PHP and SQL files, but with a bunch of images thrown in too.  The history is about 37 megs.  pack takes about 30 seconds.
[09:58] <killermoehre> fullermd: I can't see the cpu utilization if I do a remote checkout
[09:59] <zyga> killermoehre: doing a checkout or a branch?
[09:59] <zyga> killermoehre: checkouts are pretty crap IMHO
[09:59] <killermoehre> zyga: checkout
[10:00] <killermoehre> funfact: a lightwight checkout runs fast
[10:00] <zyga> killermoehre: checkouts are horrible, don't use them unless you really have to
[10:00] <zyga> killermoehre: everything about them is wrong IMHO
[10:00] <killermoehre> zyga: it's the way the devs work here
[10:00] <killermoehre> I can't change this
[10:00] <killermoehre> I'm just the admin
[10:00] <fullermd> Checkouts are awesome.  Lightweight checkouts, now, of non-local branches, are nutso.
[10:01] <fullermd> The CPU burning may be on the server side, not the client.
[10:01] <killermoehre> fullermd: the bzr pack takes 100% cpu at the server
[10:01] <killermoehre> funny
[10:01] <zyga> killermoehre: it runs once and then stops
[10:01] <fullermd> Well, yeah; pack is CPU bound, unless you have _really_ slow disks.
[10:01] <zyga> killermoehre: recommend your developers not to use checkouts, they probably don't need them and are just used to "svn"
[10:01] <fullermd> And most VM hosts don't have ESDI controllers, so yours probably aren't that slow   ;p
[10:02] <fullermd> A heavy checkout ain't gonna be any slower than a branch.
[10:03] <zyga> fullermd: the point with checkouts is that they are against the spirit of distribution, just do a local branch, use a shared repository to get local, low-cost branching, push branches back, that's the most efficient bzr workflow
[10:03] <zyga> centralized checkouts are all evil, no way to CI, single point of contention, I cannot understand why people even use that
[10:03] <killermoehre> zyga: right now the workflow is "checkout → developing → merging with the local checkout → after developing is done, merging with the repo"
[10:04] <zyga> killermoehre: branch, hack, merge || rebase, push, have CI merge it
[10:04] <zyga> killermoehre: (push to new branch on the far end)
[10:04] <fullermd> Pfui.  Checkouts are an _excellent_ mechanism to coordinate work on shared branches.  The only rational alternatives are just manually implementing the checkout workflow, and that's silly.
[10:04] <zyga> killermoehre: anyway
[10:04] <zyga> fullermd: I have yet to see a case where a checkout is worth anything over CI gatekeeper
[10:04] <zyga> fullermd: but perhasps in some specal cases that makes sense
[10:04] <killermoehre> zyga: CI?
[10:04] <fullermd> "not being nutso"   :)
[10:04] <zyga> fullermd: for me checkouts are slow and crappy
[10:05] <zyga> killermoehre: http://en.wikipedia.org/wiki/Continuous_integration
[10:05] <killermoehre> zyga: ah, ok
[10:05] <killermoehre> zyga: I don't think this is appliable right now here
[10:06] <zyga> killermoehre: well, you have what you have then
[10:06] <zyga> killermoehre: slow stuff
[10:06] <killermoehre> fullermd: the pack now hangs at "\ repacking texts:texts 147/650"
[10:06] <killermoehre> can I see which file this is?
[10:07] <killermoehre> or what bzr does there?
[10:07] <fullermd> It's not hung, it's just digesting.
[10:08] <killermoehre> fullermd: hanging := no visable output of success or computing
[10:08] <zyga> killermoehre: it's not hang, it's just compressing, wait
[10:08] <killermoehre> zyga: any way to see what it's compressing?
[10:08] <killermoehre> hmm … lsof
[10:09] <fullermd> Won't tell you anything useful.
[10:09] <killermoehre> right -__
[10:09] <killermoehre> right -__
[10:09] <killermoehre> right -_-
[10:09] <killermoehre> argh!
[10:10] <fullermd> It's extracting the texts out of the existing packs, and re-compressing them into new.  Maybe verbose logging can tell you text ids, but without a lot of digging that still won't tell you anything too useful.
[10:11] <killermoehre> fullermd: so this is an internal action and probably the problem can only be solved by throwing more resources at the machine?
[10:12] <fullermd> Probably.  How long did the pack take?
[10:14] <killermoehre> fullermd: if I read the ~/.bzr.log right, it took  810 seconds
[10:15] <killermoehre> well, I have multiple debug flags enabled, so this value could be a little to high for production use
[10:16] <fullermd> 810 seconds?  For a 36 meg repo?  So 24 times as long as on my workstation here?
[10:17] <fullermd> I guess it's possible the contents could be pathological somehow.  But yeah, I'd guess the more likely answer is "time to retire that Pentium II".
[10:17] <killermoehre> fullermd: again, it's a VM. two cores at 3GHz
[10:18] <killermoehre> brb, coffee wants to come out
[10:19] <fullermd> Well, pack isn't multithreaded, so 2 cores wouldn't be much different from 1.
[10:20] <fullermd> But either it's _really_ busy with something else, or that's a 3 GHz single-issue in-order core with no cache, 'cuz I'm only on a not particularly awe-inspiring 3.7.
[10:20] <fullermd> Or, as above, possibly an ultra-pathological set of contents.  But I'd be pretty surprised at that sort of disparity.
[10:26] <fullermd> I do love VM's, but the species does generally describe an animal that's oversubscribed to heck and back, and gets really cranky when subjected to much load.  And, absent aforementioned magic, that repo really shouldn't be much load.
[10:28] <fullermd> A lot of possible pathologies could be come up with to explain things running like molasses, but they're a pretty far reach.  Running out of suds is endemic to the VM world, and accounts for it.
[10:32] <killermoehre> fullermd: well, the hosting server has 8 cores and 8 GB RAM, summed up the machines uses 10 cores and 7.5 GB RAM.
[10:35] <zyga> killermoehre: re-do that operation on your $laptop
[10:35] <zyga> killermoehre: (just before the pack)
[10:35] <zyga> killermoehre: if you wonder about virtualization impact
[10:36] <killermoehre> zyga: the "bzr pack" at the checkout I did?
[10:38] <zyga> killermoehre: not at the checkout
[10:38] <zyga> killermoehre: you need the original branch, if you still have it
[10:38] <fullermd> The checkout will do fine.
[10:38] <fullermd> (assuming it's not a light one, of course.  But that's silly anyway)
[10:39] <killermoehre> fullermd, zyga: started a bzr pack at my $laptop in the checkout I did. seems to "hang", too
[10:39] <killermoehre> I will see how long it takes
[10:41] <killermoehre> still running …
[10:42] <killermoehre> I like how bzr is logging everything
[10:44] <killermoehre> and still running … six minutes now
[10:45] <fullermd> That really sounds excessive.  It's got the CPU nailed the whole time?
[11:02] <killermoehre> fullermd: yes
[11:03] <killermoehre> fullermd: sorry for the delay. sometimes other work interferes ^^
[11:03] <fullermd> .bzr.log probably has some info about the counts of things being dealt with.
[11:03] <fullermd> On my ~37 meg repo here, I've got numbers like
[11:03] <fullermd> 0.158  repacking 8809 revisions
[11:03] <fullermd> 3.278  repacking 8809 inventories
[11:03] <fullermd> 4.600  repacking chk: 8717 id_to_entry roots, 1426 p_id_map roots, 41320 total keys
[11:03] <fullermd> 14.405  repacking 30226 texts
[11:03] <fullermd> 29.317  repacking 0 signatures
[11:03] <fullermd> (and there it's done)
[11:05] <killermoehre> fullermd: http://sprunge.us/MMMK
[11:06] <killermoehre> fullermd: I'm killermoehre and /home/killermoehre/tmp/repository/ is the directory where the checkout is
[11:08] <fullermd> Almost 10 minutes to repack 251 texts?  Crazymuffin.
[11:09] <fullermd> The cache overflows aren't _good_, but having 3 of 'em in the whole process doesn't seem like it would make a sizable difference.
[11:10] <killermoehre> fullermd: what are those "texts"?
[11:10] <fullermd> Versions of files, basically.
[11:11] <fullermd> So 219 revisions and 251 texts means you're changing roughly 1.15 files per commit.
[11:12] <killermoehre> fullermd: the devs did
[11:12] <killermoehre> fullermd: I never touched the source
[11:12] <fullermd> Of course, OTOH, they're obviously pretty big.  251 texts compressing down to 36 megs means (assuming revs etc take up no space, which to a first approximation they do) means that each text after delta compression is taking up about 143k.  That's hyuge.
[11:12] <fullermd> Compare my ~37 meg repo with 30k texts, so each is taking up about 1k.
[11:14] <killermoehre> fullermd: so what do you suggest? delete the history of this repository?
[11:14] <fullermd> So I suspect there's some significant churn on big files, which usually either means binary or generated stuff (as human-maintained text hardly ever gets THAT big and mobile)
[11:16] <fullermd> Well, that would hack around the issue, certainly.
[11:16] <fullermd> I don't s'pose it's a sharable repo.
[11:17] <killermoehre> fullermd: sharable repo?
[11:17] <fullermd> As in you can give somebody else access to it.
[11:18] <killermoehre> fullermd: no. it have to stay in-company
[11:18]  * fullermd nods.
[11:18] <killermoehre> I would be killed (at least fired) if I would give access to it for extern
[11:18] <fullermd> Hey, you gotta sacrifice sometimes   ;p
[11:19] <killermoehre> fullermd: with a whole checkout I can go back to any previous revision, right?
[11:19] <fullermd> At any rate, that sorta size sounds a couple sigma off the norm, but I'm still a bit surprised it's that slow.
[11:20] <fullermd> Even accounting for my workstation, while not all that screamingly fast, being almost certainly significantly gruntier than your laptop, a factor of 20 difference seems well outside the lines.
[11:21] <fullermd> (how's that for tortured sentence construction?)
[11:21] <fullermd> Yes, you can.
[11:21] <killermoehre> fullermd: (I'm german. we invented tortured sentence constructions ;) )
[11:22] <killermoehre> fullermd: how can access previous revisions?
[11:22] <fullermd> Depending on particulars, usually via update or revert.
[11:24] <fullermd> update being more for things like "shuffle my whole WT over to this revision for experimentation", revert more for "slam this file back to the state of that rev for committing a backout"
[11:24] <fullermd> (as a first approximation; endless details and special cases of course)
[11:25] <killermoehre> fullermd: well, I want to find out, which file is why causing this behavior
[11:25] <fullermd> How big is the existing working tree?
[11:25] <killermoehre> fullermd: I can't tell the devs "you fucked this up, live with it"
[11:25] <fullermd> (a quick mental 'du .' - 'du .bzr' will give you a working approximation)
[11:27] <killermoehre> fullermd: 252kB
[11:27] <fullermd> Basically, there are 2 possible extremes.  One is that it's a bunch of big files and/or massive changes in each commit.  In that case, well, there's nothing much you can do, it's just how your project goes.
[11:27] <killermoehre> fullermd: echo $(($(du -s . | awk '{print $1}') - $(du -s .bzr | awk '{print $1}')))
[11:28] <fullermd> The other is that somewhere back in history, somebody accidentally committed a giant .iso or .core or the like, and then later noticed and removed it because it shouldn't have been there.  In that case, you can in concept rewrite the history without it, and get rid of the deadweight.
[11:29] <killermoehre> fullermd: any easy way to find the biggest file in bzr history?
[11:29] <fullermd> Well, that's not huge.
[11:30] <fullermd> Not directly.  You could try pulling up a 'bzr log -v' then looking through it for 'removed' lines and seeing if any of the files that have been removed look suspicious.
[11:30] <fullermd> It sounds like the latter, really.  252k of size, if it were completely changed every one of the 219 revs, would total up to 55 megs before compression, which is only twice the size of your fully compressed repo.
[11:31] <fullermd> So there's probably some big stuff piled up in the history.
[11:34] <killermoehre> fullermd: seems like in the first revision some sql dumps were added, which were removed in the second revision
[11:34] <fullermd> Sounds like a likely culprit.  A "bzr diff -c1 | diffstat" could confirm it.
[11:34] <fullermd> (giving you a quick eyeball of the size of the files)
[11:37] <killermoehre> fullermd: 45 files changed, 7351 insertions(+)
[11:38] <killermoehre> fullermd: at -c2, I got "41 files changed, 1 insertion(+), 6731 deletions(-)"
[11:38] <fullermd> And SQL dumps often have ultra long lines, so those ~7000 lines can mean a _lot_ of data.
[11:39] <fullermd> Yep, I'd call that a safe bet for the bloatsource.
[11:40] <fullermd> Getting rid of it would mean redoing the history without those files.  That means everyone's branch/checkouts would need redoing, and anybody's outstanding work in unmerged branches would have to be rebased on top of the redone history.
[11:41] <fullermd> Which may be anything from "trivial" to "fiendishly involved", depending on your particular workflows etc.
[11:41] <killermoehre> hrmpf
[11:42] <fullermd> Doing it will probably involved some invocation of something in the rewrite plugin, possibly on top of a little manual setup.  But that gets deep into details; I don't have a recipe offhand, so it would probably take some experimentation.
[11:43] <killermoehre> fullermd: well, experimentation would be … bad
[11:43] <fullermd> Well, obviously you'd make a scratch branch for the experimentation.  It would be _bad_, just potentially time-consuming.
[11:44] <killermoehre> fullermd: so I have to say the devs "a other dev not working here anymore screwed off. you're out of luck". i CAN LIVE WITH THT
[11:44] <killermoehre> sorry for the caps
[11:44] <fullermd> That's why god made devs-who-left-the-company   ;)
[11:45] <killermoehre> fullermd: at least it's not my or the machine fault
[11:47] <killermoehre> fullermd: thank you very much for your time and help and the insight into bzr. should you ever need help with xfce, don't hestiate to ask in #xfce :D
[11:48] <fullermd> np   :)
[11:49] <fullermd> Though I'm afraid ctwm would be terribly disappointed in me if I left it for some newfangled upstart wm   ;>
[14:03] <fullermd> vila: Hey, you won First Commit Of 2014.  Does that come with a trophy, or just a little brass nameplate?  ;)
[14:04] <vila> fullermd: hehe, no nothing, pure glory ;) (And even there...)
[14:06] <fullermd> Not even a cake?  Jeez, what a buzzkill.


[00:21] <jelmer> 'morning poolie, wgz
[00:21] <jelmer> I'm sure a pangolin is safer than riding an ocelot.. :-)
[00:21] <poolie> hi there
[00:59] <wgz> Noldorin: bug 906109
[00:59] <wgz> I think I put most of the relevent things in there
[00:59] <wgz> making lockdir error reporting a little less lame would probably be generally helpful
[01:02] <Noldorin> wgz, cheers
[07:22] <poolie> vila, hi?
[07:33] <vila> hi all !
[07:33] <vila> poolie: hey !
[07:33] <poolie> hi there
[09:03] <mgz> morning all!
[09:05] <poolie> hi mgz
[09:13] <poolie> ok good night
[09:14] <mgz> night poolie :)
[09:54] <jml> hi
[09:54] <jml> I just answered my own question
[09:55] <jml> apparently I have to update my bzr plugin.
[09:55] <jml> shame on you all!
[10:01] <vila> mgz: hi !
[10:01] <vila> jml: ECONTEXT ??
[10:01] <jml> cannot import name get_trees_and_branches_to_diff
[10:01] <jml> have to update lp:difftodo to call the right API
[10:01] <vila> no deprecation warnings ?
[10:02] <jml> vila: I didn't get any visible ones when running oneiric, no.
[10:03] <jml> vila: might have been in the log though
[10:03] <vila> :-/
[10:08] <mgz> ~_~
[10:09] <jml> anyway, it's been fixed. small enough change.
[10:17] <mgz> odd, lp just told me "bzr+ssh://bazaar.launchpad.net/~gz/bzr/" was not a branch
[10:17] <mgz> when I was actually trying to operate on a (non-existant) child of that
[11:16] <mgz> meh, the locale module is a mess
[11:17] <mgz> the osx not being like posix bug is fixed in 2.7 at least
[11:58] <jelmer> garr, how do I fix the path used for relative paths when using imp.load_module() ?
[12:01] <mgz> why are you using imp.load_module?
[12:01] <jelmer> mgz: loading plugins
[12:02] <mgz> ah.
[12:02] <jelmer> mgz: and because I'm an imp.
[12:03] <jelmer> mgz: we actually discover the kind of a plugin when we scan the plugin directories, and then discard that and actually use "exec 'import ...'" at the moment
[12:04] <jelmer> which then scans all plugin directories again, statting for .so, module.so, .py and .pyc everywhere
[12:04] <mgz> yeah, that's what I thought we did (exec)
[12:05] <mgz> fiddle with sys.path then use __import__?
[12:05]  * mgz throws out more bad ideas for bzrlib.plugin
[12:07] <jelmer> mgz: getting it to work is actually pretty easy - just passing path and description to _load_plugin_module, and calling imp.load_module there
[12:07] <jelmer> mgz: the trouble is that that for some reason breaks relative imports
[12:09] <mgz> you have a pathname that's relative, and it fails?
[12:09] <mgz> (as in, the third argument to load_module)
[12:10] <Sarkle> Hello
[12:11] <jelmer> mgz: I don't have a relative path name actually
[12:11] <jelmer> should it be relative?
[12:12] <mgz> I was wondering what the difference between cases that work and cases that don't is.
[12:13] <jelmer> I haven't seen cases where it does work yet, but it's an interesting point.
[12:30] <jelmer> found it, we were returning the info for the init file rather than the package
[12:31] <mgz> cool.
[12:31] <jelmer> mgz: thanks for the teddybearing :)
[12:35] <mgz> hm, I wonder how many more things changing the setlocale behaviour will break
[12:35] <mgz> I guess that pretty much all bzrlib users other than the bzr script don't call it
[12:46] <mgz> bug 570495
[12:56] <jelmer> mgz: changing the setlocale behaviour in bzrlib?
[13:04] <mgz> jelmer: well, changing some assumptions at least
[13:05] <mgz> bah, using DEPRECATED_PARAMETER seems more likely to break things than help
[13:23] <roryy> argh. i'm trying to add a test for bug 185211, but if i use UTF-8 encoded strings an unrelated problem happens with building the dirstate, and with unicode strings the bug isn't triggered
[13:24] <roryy> it's not always hugely clear when strings should be unicode and when not
[13:24] <jelmer> roryy: I think we're reasonably consistent, but it's probably not very well documented
[13:25]  * mgz giggles a little
[13:26] <mgz> rorry, try just a blackbox test to start with?
[13:26] <mgz> that should give you a way into fixing the bug, it's hard to write a good unit test for an issue when it's not clear what level the problem is at
[13:27] <roryy> i have the fix
[13:27] <mgz> oo, diff? :)
[13:27] <mgz> then I can probably help you with the test
[13:27] <roryy> sure;  it's not very complicated
[13:28] <mgz> in fact, just post an mp with the blackbox test and the change, and we can go from there
[13:28] <mgz> I think I'm even pilot this week
[13:30] <mgz> look at the current tests in bzrlib/tests/blackbox/test_mv.py for the basics
[13:30] <mgz> the ones at the bottom are nearly what you want already
[13:30] <roryy> http://pastebin.com/qsUsgm2E
[13:30] <roryy> ok, it should be easy to make a test based off of the error reproduction script
[13:31] <mgz> roryy: ahahha
[13:31] <roryy> it just looked like the dirstate tests have an *ideal* place for it, if it weren't for this utf-8 weirdness
[13:32] <mgz> yeah, we probably want both anyway, so starting with blackbox is not bad.
[13:35] <vila> mgz: can you update bug #839461 now that 0.9.8 have been deployed on pqm ?
[13:38] <lalatenduM> Hi, I want to fix bugs in https://code.launchpad.net/ubuntu/+source/guake
[13:39] <mgz> vila: sure, will put in my results from the other day as well
[13:39] <lalatenduM> but dont know how to import code from launchpad using bazzaar
[13:39] <lalatenduM> bazaar*
[13:40] <vila> mgz: thanks, my understanding is that it's not critical anymore and I suspect that's the main point of poolie's question
[13:40] <jelmer> hi lalatenduM
[13:40] <lalatenduM> so need  your help
[13:40] <lalatenduM> hi jelmer
[13:41] <jelmer> lalatenduM: are you trying to check out the packaging branch?
[13:42] <lalatenduM> yes, but i am not sure which branch i should chekout if i want to do bug fixing
[13:42] <jelmer> lalatenduM: presumably ubuntu:guake
[13:42] <jelmer> lalatenduM: e.g. "bzr branch ubuntu:guake guake"
[13:45] <lalatenduM> thanks
[13:45] <lalatenduM> let me try this..
[13:52] <lalatenduM> yes..
[13:52] <lalatenduM> it works
[13:56] <lalatenduM> thanks jelmer
[13:56] <jelmer> you're welcome
[14:09] <mgz> good, I think I'm in net code deleted still for the morning
[14:09] <mgz> wonder what else can be got rid of after lunch...
[14:10] <mgz> and... jelmer has already fixed my docstring complaint on his future import branch
[14:11] <mgz> ...which I seem to have not actually posted?
[14:11] <jelmer> mgz: you didn't, but I noticed it myself too
[14:12] <jelmer> mgz: with regard to your branch no_locale_hacks_570495
[14:12] <jelmer> I will say that the code looks prettier, but I'm not sure about what it actually does
[14:47] <mgz> jelmer: I shall try and explain a little more in the mp :)
[14:54] <lalatenduM> jelmer, can you please point me to the code branch of "bzr branch ubuntu:guake guake" in launchpad
[14:54] <lalatenduM> i can't find it lp
[14:54] <lalatenduM> *in lp
[14:56] <jelmer> lalatenduM: http://code.launchpad.net/ubuntu/+source/guake should have all branches relevant for the guake package
[14:57] <lalatenduM> according to http://doc.bazaar.canonical.com/beta/en/tutorials/using_bazaar_with_launchpad.html, "bzr branch lp:project-name/series" should be the syntax
[14:58] <lalatenduM> but i did something else
[14:58] <lalatenduM> i.e. bzr branch ubuntu:guake guake
[14:59] <lalatenduM> i am not able to co relate both sysntax'
[14:59] <lalatenduM> syntax*
[15:05] <vila> jelmer: regarding the error message, the initial issue is that "skipping {file} (larger than {add.maximim} of {20MB} bytes) " is bogus, (of what ?). How about "skipping {file}, larger than {add.maximim} ( {20MB} bytes)"  ?
[15:06] <jelmer> lalatenduM: that's for upstream projects; ubuntu:pkg is a shorthand for lp:ubuntu/pkg
[15:06] <jelmer> vila: Is that message really bogus? it seems valid English to me
[15:07] <jelmer> let's ask a native speaker :)
[15:07] <jelmer> mgz: ^
[15:07] <vila> hehe, yeah :)
[15:07] <hrw> hi
[15:07] <hrw> jelmer: did you tried to use git bzr to merge bzr branches?
[15:07] <jelmer> hi hrw, what's up?
[15:08] <hrw> jelmer: I have criss-cross merge and bzr gaves me 8 conflicting files never mind that those conflicts are fixed in branch which I merge in
[15:08] <jelmer> hrw: what do you mean with git bzr?
[15:08] <hrw> jelmer: bzr::lp: one
[15:09] <jelmer> git after git-remote-bzr?
[15:09] <hrw> yes
[15:09] <jelmer> hrw: if you're merging in bzr, where does git come into the picture?
[15:10] <hrw> I have lp:~hrw/ubuntu/precise/gcc-4.6/gcc-linaro-ci-native branch which base on lp:ubuntu/gcc-4.6 + lot of changes. recently I merged lp:ubuntu/gcc-4.6 into it, fixed conflicts and pushed.
[15:10] <lalatenduM> jelmer: that explains it ubuntu:pkg is a shorthand for lp:ubuntu/pkg
[15:10] <hrw> now I want to merge lp:~hrw/ubuntu/precise/gcc-4.6/gcc-linaro-ci-native into lp:~hrw/ubuntu/precise/gcc-4.6/gcc-linaro-ci-cross
[15:10] <lalatenduM> thanks
[15:10] <hrw> ci-cross one and ci-native one have same base but some differences
[15:11] <hrw> jelmer: and I am thinking about doing git tree with both branches as separate ones + merge them in git
[15:13] <hrw> jelmer: but git/bzr fails on 'git remote update': http://pastebin.com/WpeT1RGD
[15:13] <hrw> jelmer: same for ci-native
[15:14] <jelmer> hrw: going through git means losing all bzr metadata
[15:14] <jelmer> hrw: so I wouldn't recommend doing this until git-remote-bzr supports roundtripping bzr metadata
[15:15] <hrw> k
[15:17] <hrw> is bzr and merges between few branches asking for problems?
[15:17] <hrw> I have branch-upstream + branch-c/branch-n. both -c and -n branched from upstream and merge them and each other
[15:21] <mgz> vila, jelmer: not having the parens at all would be good, and maybe statng what add.max actually is (the name of a config option), but the current does make sense
[15:22] <jelmer> hrw: that should be fine - you're getting conflicts in that case?
[15:22] <jelmer> hrw: if you're doing criss-cross merges, you may want "bzr merge --lca"
[15:22] <hrw> jelmer: --weave and --lca == same
[15:23] <jml> you guys are running pkgimport with bzr as a branch dependency, right?
[15:25] <vila> mgz: ok, so either I'll leave it as is or you can give me your proposed phrasing and I'll take that
[15:25] <vila> jml: by setting PYTHONPATH yes
[15:26] <vila> jml: by the way, I've tested udd trunk with your changes locally and will deploy it next time I can
[15:26] <jml> vila: hurrah.
[15:27] <jelmer> hrw: same results you mean? They're definitely different merge algorithms.
[15:28] <hrw> jelmer: same as '8 files conflicted'
[15:28] <hrw> jelmer: now I am merging file after file and see same merges which I did in ci-native (which I merge into)
[15:30] <jelmer> hrw: right, that's often an issue with criss-cross merges
[15:30] <jelmer> hrw: you might want to post to the list about this, I'm not really an expert on merge algorithms
[15:31] <hrw> jelmer: can you give me email to ml?
[15:31] <jelmer> hrw<EMAIL_ADDRESS>[15:31] <lalatenduM> jelmer: after I imported code from lp. I have created a personal branch at https://code.launchpad.net/~then4way/+junk/guake
[15:31] <jelmer> hrw: or, if you have a short script of reproducing it for a merge that you think we should be handling better, please file a bug
[15:31] <lalatenduM> and pushed the code to it
[15:32] <lalatenduM> bzr push --use-existing lp:~then4way/+junk/guake
[15:33] <hrw> will report bug
[15:33] <lalatenduM> For maintaining a version system, i think i have to do "bzr init;bzr add; bzr commit -m "Initial Import"". Right?
[15:34] <lalatenduM> I have used wincvs, perforce but new to bzr
[15:37] <jelmer> lalatenduM: yep
[15:37] <lalatenduM> thanks
[15:40] <hrw> bug 906370
[15:41] <hrw> I do not have better idea for title at the moment
[15:45] <jelmer> mgz: I'm going to approve your locale branch
[15:45] <jelmer> mgz: be aware though, that we'll assign all encoding-related bugs to you for the next couple of months :P
[15:48] <mgz> ehehe
[15:56] <mgz> anyone want to review my "oops, I completely broke windows" branch?
[15:57] <mgz> jelmer: I'm also interested in if you have debugging ideas for tracking actual socket connections
[15:58] <mgz> as I still need to work out if the gap between transport tracking old and new is real or bogus connections
[16:10] <jelmer> mgz: hmm
[16:12] <jelmer> mgz: it doesn't seem particularly tricky to me - we just have to call out to a new hook when we create a socket or ask somebody else (curl, paramiko, ...) to create one for us
[16:12] <jelmer> mgz:  your last sentence doesn't parse for me
[16:13] <mgz> hm, okay
[16:13] <mgz> basically, I did some testing on... Friday? that got me a list of transports seen by both the old get_transport hack and the new hook
[16:14] <jelmer> ah
[16:14] <jelmer> mgz: ... and you saw a difference?
[16:14] <mgz> I want to work out which of the differences are due to bugs fixed (a transport that wasn't connected now not tracked),
[16:15] <mgz> and which are due to bugs created (a transport that is connected now not tracked)
[16:15] <jelmer> mgz: I guess as long as you're just interested in seeing what the difference is
[16:16] <jelmer> mgz: you could move the body of get_transport_from_url() into a new method, and have that method's return value indicate whether it reused an existing transport
[16:16] <jelmer> ... and then use that method in bzrlib.tests as well, and discard anything that reused an existing transport
[16:18] <mgz> I think I cover that already by using set()
[16:19] <mgz> but perhaps not.
[16:19] <mgz> hm, no, _reuse_for does get a new instance
[16:25] <mgz> so, eg, currently bb.test_branch.TestRemoteBranch.test_branch_local_remote sees 4 _SharedConnection objects
[16:27] <mgz> and with the hook the same test has 3 _SharedConnection objects
[16:30] <jelmer> hmm
[16:31] <jelmer> can you tell what the classes of those connections are?
[16:32] <mgz> yup, paramiko.SFTPClient in this case.
[16:33] <mgz> and using that as the key gives different results again
[16:35] <vila> mgz: forget about SFTPClient, they use a dedicated thread that you cannot track, they are the cause of the last known  leak IIRC
[16:36] <mgz> but we can see if the connection actually happens I trust?
[16:36] <vila> the hook should be more precise in this case though
[16:36] <vila> hmm, I think so, the shared connection is not the socket itself but rather the paramiko transport object right ?
[16:37] <mgz> yup.
[16:37] <vila> so I think you get one only after the connection really occurs
[16:37] <mgz> and if we have one do we known the underlying sock... cool
[16:37] <vila> 90% sure
[16:38] <vila> do we have a disconnect() implemented there ?
[16:39] <vila> bah, certainly, so you may not precisely track the underlying socket, but it's good enough as paramiko will close it later (in theory)
[16:40] <mgz> yup, the hook looks good here
[16:41] <mgz> the difference is on the following transport:
[16:41] <vila> mgz: sry, my memory is failing me again, did you end up fixing the news_merge config on pqm ?
[16:41] <mgz> ('sftp://foo@<IP_ADDRESS>:39740/tmp/testbzr-PK83Bv.tmp/bzrlib.tests.blackbox.test_branch.TestRemoteBranch.test_branch_local_remote/work/', None, None)
[16:41] <mgz> vila: nope, we need to know where the real locations.conf is
[16:42] <vila> ha, right, mthaddon should know
[16:42] <mgz> ^that's (transport.base, transport._shared_connection.connection, transport._shared_connection.base)
[16:42] <mgz> so, it's a transport that gets created but never connects
[16:44] <mgz> next, the http case...
[16:44] <vila> transport._shared_connection.base ??? What's that used for ?
[16:45] <mgz> no idea, I thought I'd print it to see
[16:45] <mgz> 's always None in this case
[16:48] <vila> weird, both 'connection' and 'credentials'  is used as an opaque container are supposed to be opaque and transport specific but still related to the connection, having a 'base' there.... sounds bogus
[16:48] <vila> nm, unrelated to your work anyway
[16:50] <mgz> ...looks like it's just used by the smart server?
[16:51] <vila> it should probably be part of either connection or credentials
[16:54] <hrw> help? I created small recipe to test something. It uses lp:ubuntu/gcc-4.6 as base branch and then merges my lp:~hrw/+junk/ci-gcc-cross-armel branch into it. my branch contains one commit which adds debian/target file. But on 'bzr dailydeb' run I am getting merge conflicts... on directory ;(
[16:55] <hrw> http://pastebin.com/mLEmqPpr is output and recipe
[17:07] <jelmer> hrw: looking...
[17:08] <hrw> jelmer: thanks
[17:08] <jelmer> hrw: is lp:~hrw/+junk/ci-gcc-cross-armel actually derived from lp:ubuntu/gcc-4.6 ?
[17:08] <hrw> jelmer: not at all
[17:08] <jelmer> hrw: it doesn't appear to be, so the identity of the debian/ directory is different.
[17:09] <hrw> jelmer: so I should base on gcc-4.6 and remove all files in one commit to get same result but mergeable?
[17:09] <jelmer> hrw: I'd recommend creating lp:~hrw/+junk/ci-gcc-cross-armel as a branch that derives from lp:ubuntu/gcc-4.6 and actually adds the the file that way
[17:09] <hrw> jelmer: I want to not do any changes in my branch - just to have one file there so launchpad will do all work for me
[17:10] <jelmer> hrw: right, my suggestion should do that
[17:10] <hrw> ok
[17:10] <jelmer> hrw: just create lp:~hrw/+junk/ci-gcc-cross-armel as a clone of lp:ubuntu/gcc-4.6 with one additional commit that adds debian/target.
[17:11] <hrw> jelmer: this way I would have to update my branch each time when lp:ubuntu/gcc-4.6 is updated.
[17:11] <hrw> jelmer: will try my idea
[17:11] <jelmer> hrw: no
[17:11] <jelmer> hrw: launchpad will happily merge, as long as nobody creates a target file in lp:ubuntu/gcc-4.6
[17:12] <jelmer> if somebody creates a target file in lp:ubuntu/gcc-4.6 then it will (correctly) conflict
[17:13] <hrw> jelmer: ah. now I see - had to think a moment
[17:22] <achiang> hello, should 'bzr launchpad-login' be expected to work in a console environment? (remote server)
[17:22] <jelmer> achiang: hi
[17:22] <jelmer> achiang: yes
[17:23] <achiang> jelmer: hm, perhaps i'm just hitting an issue in precise?
[17:23] <achiang> ubuntu@server-3424:~/Projects$ bzr launchpad-login achiang
[17:23] <achiang> WARNING: gnome-keyring:: no socket to connect to
[17:23] <jelmer> achiang: what are you seeing?
[17:23] <jelmer> achiang: are there any plugins installed on the remote server ("bzr plugins") ?
[17:24] <hrw> jelmer: it works - thanks
[17:24] <achiang> jelmer: http://pastebin.ubuntu.com/775503/
[17:28] <mgz> vila: okay, I think I'm caught up with your thinking on the post_connect hook
[17:30] <jelmer> achiang: hmm, I don't think any of those use gnome-keyring
[17:31] <achiang> jelmer: trying to recreate with an older version of ubuntu now
[17:31] <jelmer> achiang: my guess is that we're loading launchpadlib and that's using gnome-keyring
[17:31] <jelmer> lp-login shouldn't actually be using launchpadlib though
[17:33]  * achiang patiently waits for another openstack instance to start up
[17:43] <achiang> jelmer: ok, as a test, i tried natty, and bzr launchpad-login works fine in headless mode
[17:44] <hrw> bye
[17:44] <achiang> jelmer: shall i file a bug?
[17:48] <jelmer> achiang: please do
[17:48] <achiang> jelmer: ok, will do
[17:48] <jelmer> achiang: can you perhaps run "bzr --profile-imports lp-login ... 2>x" and pastebin x ?
[17:50] <achiang> jelmer: what plugin provides profile-imports?
[17:50] <jelmer> achiang: sorry, nevermind. it requires a lp:bzr checkout
[17:50] <jelmer> I forgot about that
[17:51] <achiang> ok
[18:14] <Noldorin_> hi folks
[18:16] <jelmer> hi Noldorin_
[18:16] <Noldorin_> jelmer, hey
[18:22] <achiang> jelmer: https://bugs.launchpad.net/bzr/+bug/906452 ; it probably needs to go into the proper bucket, etc.
[18:27] <jelmer> achiang: oh, it doesn't actually let you continue? I thought it just warned
[18:27] <jelmer> achiang: in that case, can you run "BZR_PDB=1 bzr lp-login ..." ?
[18:30] <achiang> jelmer: oh! maybe it does let you continue. i didn't realize that was just a warning
[18:30] <achiang> jelmer: um, except the big huge WARNING on the command line
[18:31] <achiang> not sure why my brain turned off
[18:31] <achiang> jelmer: yes, so it does actually work
[18:31] <jelmer> cool, that warning is still odd though
[18:32] <jelmer> I'll change the title on the bug report though, thanks for filing it
[18:32] <achiang> jelmer: thanks
[19:44] <ggherdov> hi all, how do I run just a single unit test from bzrlib/tests ?
[19:48] <ggherdov> the page http://doc.bazaar.canonical.com/developers/testing.html isn't quite clear about it, it mention testrepository but... well... there is no cut-and-pasteable commands :-)
[19:49] <jelmer> ggherdov: ./bzr selftest <python-path>
[19:49] <jelmer> ggherdov: e.g. ./bzr selftest bzrlib.tests.test_foo
[19:49] <ggherdov> jelmer: thx. trying right away!
[19:53] <ggherdov> jelmer: enigmatic answer, http://pastebin.com/cDmWYfV6
[19:53] <ggherdov> 0 tests ?
[19:53] <ggherdov> can I make it more verbose?
[20:00] <jelmer> ggherdov: verbose in what way?
[20:01] <jelmer> ggherdov: the test you specified doesn't exist
[20:01] <ggherdov> ah.
[20:01] <jelmer> ggherdov: I think you want bzrlib.tests.test_merge.TestPlanMerge.test_plan_merge_tail_ancestors
[20:02] <ggherdov> you are right.
[20:02] <ggherdov> '-.-
[20:23] <Noldorin_> hi wgz
[20:46] <wgz> Noldorin_: didn't mention yesterday, another option is just using the cygwin bzr package: <http://cygwin.com/packages/bzr/>
[20:46] <wgz> ggherdov: use -s too! see `bzr help selftest`
[20:47] <ggherdov> wgz: thank, checking it
[21:01] <poolie> hi jelmer, wgz
[21:01] <wgz> hey poolie!
[21:16] <jelmer> 'evening poolie, wgz
[21:28] <Noldorin_> wgz, lol, nooow you say ;-)
[21:29] <Noldorin_> wgz, that would probably do the job yeah :-)
[21:29] <Noldorin_> cheers
[21:42] <Noldorin_> hi poolie
[21:42] <Noldorin_> haven't seen you around in a while
[21:43] <poolie> hi there
[21:43] <Noldorin_> wgz, i mean, it would do everything i want right? :-)
[21:43] <poolie> i have been taking some holidays
[21:43] <poolie> but i'm back for a few days now
[21:43] <Noldorin_> ah nice
[21:43] <Noldorin_> well deserved i think
[21:43] <Noldorin_> yeah
[21:43] <Noldorin_> before Christmas i suppoe.
[21:45] <Noldorin_> well-timed :-P
[21:54] <iamfuzz> Is there a way in bzr to have it automatically checkout and nest another branch, i.e. submodules (IIRC) in svn?
[21:54] <iamfuzz> we keep our packaging in one branch and code in another, and I was curious if there was a way to have the bzr checkout do such a thing
[21:55] <poolie> iamfuzz, for the specific case of packaging you might like to use bzr builder
[21:55] <poolie> http://doc.bazaar.canonical.com/plugins/en/builder-plugin.html
[21:55] <poolie> which is what we use for ubuntu recipes
[21:55] <poolie> otherwise http://doc.bazaar.canonical.com/plugins/en/scmproj-plugin.html
[21:55] <iamfuzz> many thanks, I'll givem a read
[22:17] <Noldorin_> poolie, so, do you think it would be possible to stage a dev version of launchpad on y win2k8r2 box?
[22:50] <poolie> Noldorin_, hi, do you mean running it natively on windows?
[22:50] <poolie> it might be fairly hard
[22:50] <poolie> there are probably a lot of unix assumptions
[22:50] <poolie> Noldorin_, i would probably run ubuntu in a vm to start with
[22:51] <Noldorin_> poolie, hmm how about cygwin??
[22:52] <poolie> well
[22:52] <poolie> what are you trying to accomplish?
[22:52] <poolie> to be able to fix bugs or add features to lp?
[23:09] <poolie> Noldorin_, so i think i can guarantee it will not just work under cygwin
[23:09] <poolie> the problems might be surmountable
[23:10] <poolie> i think it would be at least days to get everything installed and working
[23:10] <poolie> it depends a bit on whether you want to run just one thing or the whole deal
[23:57] <Noldorin_> poolie, sorry, back now
[23:57] <Noldorin_> poolie, yeah, so by far the easiest would be a Ubuntu VM eh?


[07:13] <StevenK> guruprasad: Hi! Did you have more luck with the second verification?
[09:19] <guruprasad> StevenK, I am just starting my day now. Will do this in a short while from now and get back to you asap.
[09:45] <guruprasad> StevenK, cjwatson and I were able to verify the signed message that you sent us, thereby confirming that you are indeed the owner of the account. I have requested the SSO team to help you regain access to your account. I will let you know once this is done.