[00:25] <poolie> BitSprocket, which bit didn't work?
[00:25] <poolie> what's going wrong?
[00:28] <BitSprocket> It seems that it removed something called 'tree' *unsure* but the files are still marked with the versioning status as if nothing changed.  I tried to export the files but that didn't seem to work either...
[00:29] <poolie> what does 'bzr status' show?
[00:29] <BitSprocket> '... Modified'
[00:30] <poolie> so you did 'bzr rm --keep THING'
[00:30] <poolie> and now 'bzr st' still shows some files under that directory as modified?
[00:30] <poolie> really?
[00:31] <BitSprocket> Yes, but it may be after I've done some more tinkering.  I just tried the bzr rm --keep and now the status says:
[00:31] <BitSprocket> bzr: ERROR: No WorkingTree exists for "file:///home/scott/pytivo/.bzr/checkout/".
[00:31] <poolie> !
[00:31] <poolie> maybe you're in the wrong directory?
[00:32] <BitSprocket> I thought so too so I tried the same steps moving down the directory structure to where the actual files were and did the same thing with the same results.
[00:32] <poolie> in which directory is your actual working tree?
[00:32] <BitSprocket> not sure what you mean by working tree ... sorry
[00:33] <poolie> do you have ~pytivo/trunk or something?
[00:33] <poolie> i mean ~/pytivo/trunk ?
[00:33] <BitSprocket> Ah, yes, its exactly that.
[00:33] <poolie> ok, cd there
[00:33] <BitSprocket> done
[00:33] <poolie> now which directory did you want to un-version?
[00:33] <BitSprocket> trunk and everything below
[00:34] <poolie> !!
[00:34] <poolie> hm
[00:34] <poolie> i think i misunderstood your question
[00:34] <poolie> why do you want to do this?
[00:35] <BitSprocket> Well, I'm learning how to use bzr and I discovered that I created the repository in the wrong directory.  My files are actually located in pytivo/trunk/TheBayer and I don't need version control configured for anything above theBayer.  I figured if I removed the whole thing and started over I would be better off.
[00:36] <poolie> oh i see
[00:36] <poolie> so what is TheBayer?
[00:36] <poolie> all the source is inside that?
[00:36] <BitSprocket> Its a python project that allows me to stream videos to my tivo box from the network.  And yes, that's where the source files are.
[00:36] <poolie> when someone else gets a checkout, do you want them to get a directory called TheBayer, or do you want them to just get the files that you have inside that directory?
[00:37] <BitSprocket> Well, for now, it's a project that I'm using to learn python so for the immediate future it won't be a public repo.  I just wanted to be able to roll back changes if I really fouled things up.
[00:37] <BitSprocket> I suppose that directory and everything below as one package
[00:43] <poolie> ok so really TheBayer is the name of your branch?
[00:43] <poolie> as opposed to trunk?
[00:43] <poolie> that's the codename for the feature or something?
[00:44] <BitSprocket> TheBayer is the name of the project that I downloaded from the web.  It's not really my project, its someone elses work that I'm using to cut my teeth.  No codenames, nothing special.  I believe that's what he named his fork from another project.
[00:45] <BitSprocket> I untarred it and got a directory called TheBayer with all the source in it.
[00:45] <BitSprocket> the pytivo and trunk folders I created myself.
[00:47] <poolie> ok
[00:47] <poolie> so i suggest you do
[00:47] <poolie> cd ~/pytivo/trunk/
[00:47] <poolie> mv TheBayer ../
[00:47] <poolie> cd ../TheBayer
[00:47] <poolie> bzr init; bzr add; bzr commit
[00:48] <BitSprocket> Okay, so if I understand you, you are suggesting I move the folder and create a new repo right?
[00:59] <poolie> yes
[01:00] <BitSprocket> got it...
[01:02] <spiv> Morning.
[01:03] <mneptok> spiv: ahoyhoy
[01:06] <BitSprocket> Hi spiv;GugaDin
[01:16] <meoblast001> if any of you are familiar with TracBzr, i'm getting "Warning:  Error with navigation contributor 'BrowserModule' "
[01:17] <meoblast001> that is, in the Admin/Repositories page
[02:13] <poolie> hi spiv
[02:14] <poolie> spiv, lifeless, one of us should look at https://bugs.launchpad.net/bugs/594275 fairly soon
[02:16] <lifeless> what makes that one critical?
[02:16] <lifeless> (vs other automated imports failing)
[02:16] <lifeless> we need to move the package importer from its current machine too
[02:16] <lifeless> and find a team to own it
[02:18] <lifeless> fixing that particular bug may fix 15 or so imports
[02:18] <lifeless> which would be nice
[02:18] <poolie> lifeless, it makes it critical that it's blocking barry's attempt to do udd
[02:18] <poolie> on inspection a downgrade might be appropriate
[02:43] <lifeless> man, I hate spam
[02:44] <lifeless> and gmail is failing at catching all these twitter 'we've reset your password' mails.
[02:44] <lifeless> It appears that the spammers are bcc'ing all of canonical on each personalised mail!
[02:46] <fullermd> "... twitter ..."   <--- Found your problem.
[02:46] <lifeless> hah
[02:49] <lifeless> vila: btw
[02:49] <lifeless> SYN_SENT2 minutes
[02:50] <lifeless> http://www.dd-wrt.com/wiki/index.php/Router_Slowdown was a quickly found reference for this
[02:50] <lifeless> vila: which suggests to me that the server thread isn't actually accepting when it starts, but has presumably open the socket so it doesn't get rejected either. Or something.
[02:51] <chx> i have created a launchpad branch stacked on top of an earlier tag of another lp branch. i have a local checkout of both for speedy work. I would like to merge all revisions affecting a certain directory. How can I do that? Just doing the merge does the file changes but does not actually merge revisions.
[02:52] <lifeless> thats right, merging only part of a patch is a cherrypick and cannot show up as a full merge.
[02:53] <chx> as said, i would like to merge full revisions, affecting a file / directory ... does that involve lots of scripting trickery :) ?
[02:57] <lifeless> you want to merge a revision, but not its parents, right ?
[03:02] <lifeless> chx: ^?
[03:02] <chx> reading
[03:02] <chx> hrm
[03:03] <chx> i think the answer is yes :)
[03:03] <lifeless> so, thats not a complete merge
[03:03] <chx> oh?
[03:03] <chx> well, yes, it's cherry picking
[03:03] <lifeless> a complete merge merges a revision *and its parents*, recursively
[03:03] <chx> but it's revisions that it merges
[03:03] <lifeless> all the way back to the revisions that your branch already has
[03:03] <chx> which would bring in changes to ohter wiles.
[03:03] <chx> *files
[03:04] <chx> so a) i need to find which revisions affected a file b) merge in just those revisions
[03:04] <chx> right?
[03:05] <lifeless> lets start over
[03:05] <lifeless> what are you doing at the moment, and what is going wrong
[03:06] <chx> heh
[03:07] <chx> let's go step by step
[03:07] <chx> a)  i have created a launchpad branch (sandbox) stacked on top of an earlier tag of another lp branch (trunk)
[03:07] <chx> b) i have checked out both
[03:07] <chx> c) cd sandbox/sites
[03:07] <chx> d) bzr merge ~/examiner/trunk/sites/parc/
[03:08] <chx> e) bzr ci -m 'merged in parc changes to sandbox'
[03:08] <chx> f) check with bzr log -n0 -- oopsie no revisions!
[03:08] <chx> g) bzr uncommit
[03:08] <chx> h) /join #bzr
[03:08] <chx> makes sense?
[03:09] <lifeless> what does bzr root ~/examiner/trunk/sites/parc/
[03:09] <lifeless> print out
[03:10]  * spiv guesses the root is ~/examiner/trunk
[03:11] <chx>  /home/chx/examiner/trunk
[03:11] <lifeless> ok
[03:11] <chx> it's a checkout of lp:~examiner-dev/examiner/trunk
[03:11] <lifeless> chx: that has happened because you merged a subdirectory.
[03:11] <chx> I created the sandbox branch with bzr branch -r tag:Perugina --stacked lp:~examiner-dev/examiner/trunk lp:~examiner-dev/examiner/sandbox if that matters
[03:11] <lifeless> chx: doing that makes it a cherrypick
[03:11] <chx> i see.
[03:11] <lifeless> chx: and cherrypicks *are not recorded in log*
[03:12] <chx> hm
[03:12] <lifeless> you have two options
[03:12] <lifeless> a) don't worry about it not being in log
[03:12] <lifeless> b) don't merge a subdirectory
[03:13] <chx> and if i do bzr merge -c 15932 ../trunk then it'll show up?
[03:13] <lifeless> no
[03:13] <chx> only bzr merge ../trunk will?
[03:13] <lifeless> because -c does a cherrypick in the graph as well, a different sort of cherrypick but still a cherrypick
[03:13] <lifeless> thats right.
[03:14] <chx> ok, so then i might pick a
[03:14] <chx> and hope that when i later do just bzr merge trunk then it will simply figure out that some differences are already in.
[03:15] <chx> it looks like i have no other choice
[03:15] <spiv> Right.  bzr merge can record "revision X (and all parents of X) has been merged", but not "revision X without parents" or "just some subdirectories changed in revision X", or other variations.
[03:15] <spiv> 'bzr merge' will generally avoid reporting conflicts if the exact change to merge already seems to have been applied.
[03:15] <chx> but then bzr merge is awesome and will figure out that some changes are already in.
[03:16] <chx> right.
[03:17] <chx> my heart still aches for darcs but it is so slow :(
[06:35] <poolie> lifeless, oh did i mention that we talked a bit about user models
[06:36] <poolie> there's a file in devnotes about this
[06:36] <poolie> http://doc.bazaar.canonical.com/devnotes/bzr3-user-stories.html
[06:41] <lifeless> cool
[06:44] <spiv> way
[06:44] <spiv> ...that was an odd typing mistake, but let's pretend I meant to say "way cool" :)
[06:49] <poolie> hey spiv :)
[06:56] <poolie> spiv, https://code.edge.launchpad.net/~mbp/bzr/590638-buffering/+merge/27578 is the issue of excessive buffering from last monday
[06:56] <poolie> not urgent
[06:57] <spiv> poolie: thanks!
[06:58] <assad> how to confirm that merge is done and all conflicts resolved?
[06:58] <poolie> assad, 'bzr st'
[07:00] <assad> poolie, i am getting this: pending merge tips: (use -v to see all merge revisions)
[07:00] <poolie> ok
[07:00] <assad> poolie, is the merge over and conflicts resolved?
[07:00] <poolie> try 'bzr conflicts'
[07:00] <poolie> if there are none you're ready for 'bzr commit'
[07:01] <assad> none, thanks
[07:01] <assad> :)
[07:29] <vila> hi all
[07:31] <poolie> hi there vila
[07:31] <poolie> i have a ScriptRunner patch for you
[07:31] <vila> poolie: hey !
[07:31] <poolie> and i guess you already know you're lotzman this week
[07:32] <vila> hmm, looks like I missed a joke somewhere, that's the second time I see 'lotzman' used and I have no idea what it means :) Well, except some relation with patch pilot  that is :)
[07:32] <poolie> it's the Russian word for "pilot" in the sense of someone who helps a ship into a harbor
[07:33] <poolie> bialix told us that when he asked what 'patch pilot' means
[07:33] <vila> haaa, yeah, the first reference was from bialix indeed :)
[07:33] <vila> 'pilote' is the French word for that
[07:34] <poolie> heh
[07:35] <poolie> so https://code.edge.launchpad.net/~mbp/bzr/scripts/+merge/27581 is the one i was thinking of
[07:35] <poolie> and then https://code.edge.launchpad.net/~mbp/bzr/externalbase/+merge/27583 uses scripts quite a lot and to good effect
[07:35] <vila> ok, I'll look into it today
[07:41] <poolie> i don't mean to harrass you there :)
[07:42] <vila> hehe, no harassment taken :)
[07:45]  * mneptok arrives on cue
[07:45] <mneptok> did someone order some harrassment?
[07:59] <assad> poolie, how can i update one branch on launchpad with another branch on launchpad? so that i dont have to first merge my branch and then push the changes to the other branch.
[08:01] <poolie> can you explain more?
[08:01] <vila> assad: A merge requires a working tree, lp have no WT, I'm pretty sure you can't achieve what you want there
[08:01] <spiv> assad: If I'm understanding your question correctly (what exactly do you mean by "update"?), you can't.  What's the problem with pushing the changes?
[08:09] <assad> poolie, i intend to update/push changes to my branch from the parent branch via lp itself. so that i dont have to move files through my machine.
[08:09] <poolie> assad, just for curiousity which project is this?
[08:09] <poolie> assad, no, you can't really do that, you need to push from your machine into the other branch
[08:09] <assad> poolie, ok
[08:10] <poolie> it might be nice if lp let you do the merge remotely but we don't atm
[08:10] <assad> ok
[08:24] <vila> lifeless, spm: How did your pqm fixes went ?
[08:24] <vila> poolie: geee ! No harassment but nothing less than *7* mps !!! :)
[08:26] <spm> hey vila, sadly no progress *yet*, but I am right now about to attempt to apply lifeless' patch and get the package(s) rebuilt. which is step A in this one.
[08:26] <vila> spm: hi ! No harassment, no harassment :) Thanks for the feedback !
[08:27] <spm> :-) np
[10:44] <lifeless> vila: did you see my web link for you in backlog ?
[10:46] <vila> lifeless: yup, thanks
[10:47] <vila> I don't know how to check that on windows though, but I'm about to try to address it anyway by finishing what I started on SmartServer_for_testing first and see from there
[10:49] <lifeless> vila: try changing the timeout in the registry, if the behaviour changes to match, thats what it is
[10:50] <vila> regis..what ? :)
[12:33] <bialix> heya
[12:33] <bialix> bonjour vila !
[12:46] <wgrant> \/win 5
[13:00] <vila> bialix: privet Sacha !
[13:00] <bialix> cool
[13:00] <bialix> privet
[13:01] <bialix> vila: just want to say that I've read your comment to leaking merge proposal and I very impressed
[13:03] <vila> by what ? The number of dormant bugs ? :-) The 22 hours on windows ? :-P I'll get them pass on windows, I tell you ;)
[13:09] <bialix> by the problem and analysis
[13:09] <bialix> did not realized hidden problems
[13:10] <bialix> vila: and yes, 22 hours is a bit tooooooooooooooooooooooooooo much
[13:10] <vila> bialix: ha, yeah, tricky stuff :-/
[13:10] <vila> hehe, don't worry, I'll fix that :)
[13:10] <bialix> cool :-)
[13:11] <vila> but the nice thing is that it should help use more threads in the future (outside of the test servers) while still keeping a python-ish way to describe the processing, still a long way to get there though :-/
[13:17] <bialix> vila: I don't understand though your remark about slicing test suite to keep number of opened sockets below th elimit
[13:18] <vila> bialix: when using --parallel=fork, we spawn several processes, each of them with only a slice of the whole test suite
[13:18] <vila> bialix: so each process see less leaks and is able to finish
[13:19] <bialix> I think limit for opened sockets is limit for all running processes
[13:21] <vila> bialix: Well, it could be on windows but --parallel=fork doesn't work on windows anyway
[13:21] <bialix> hehe, nice
[13:21] <vila> :-/
[13:42] <Lo-lan-do> Hi all :-)
[13:43] <Lo-lan-do> jelmer: Do you know if anyone is planning to bring recent versions of bzr, bzr-svn and loggerhead to backports.org?
[13:43] <jelmer> Lo-lan-do: not that I'm aware of
[13:44] <Lo-lan-do> Thanks. I guess I'll try that myself then.
[13:44] <Kamping_Kaiser> the bzr versions reasonably recent, 'just' all the packages which depend on it are broken as a result :
[13:44] <Kamping_Kaiser> :/
[13:45] <Lo-lan-do> http://bzr.debian.org/loggerhead/pkg-python/python-defaults-debian/annotate/head:/dh_python2? seems to crash somewhere in bzrlib
[13:45] <Lo-lan-do> bzr 2.0.3, loggerhead 1.10 or so
[14:09] <jelmer> Lo-lan-do: I know at least two other people who are interested in bzr and bzrtools in backports
[14:20] <Lo-lan-do> jelmer: Let's see if anyone shouts at my email :-)
[15:25] <Kamping_Kaiser> Lo-lan-do: re your email for bzr backports, one of my last messages to bpo users was about doing bzr package backporst. iirc it contains a list of packages which need rebuilding/changing. i can probably find it if you think it'll help
[17:13] <maxb> Is there really much of a performance penalty in fetching between pack-0.92 and 1.9 formats?
[17:13] <maxb> Or is bzr being a bit over-eager at warning me about format mismatches?
[17:14] <jelmer> maxb: between pack-0.92 and 1.9 it shouldn't be very expensive
[17:14] <maxb> Do you think it's expensive to justify bzr issueing a warning on pull?
[17:34] <parthm> jam: ping
[17:34] <jam> hi parthm
[17:34] <parthm> hi jam.
[17:35] <parthm> i was hoping to complete the lock-url patch. does the 5 sec timeout for LockContention seem ok to you?
[17:36] <jam> so we've certainly gone around on it a lot :)
[17:36] <jam> IMO, the timeout should be on the order of how long it takes to take and release the lock
[17:36] <parthm> jam: yes :) .. i suppose anything is better than 300.
[17:37] <jam> so that 2 people who are doing things that *can* be done won't block eachother
[17:37] <jam> for example, updating branch.conf
[17:37] <jam> also, updating pack-names is done with a physical lock
[17:37] <jam> so we should look at how long it takes to get the lock, update pack-names, and then release the lock
[17:38] <jam> That, I think, is the key thing to watch out for
[17:38] <jam> because if 2 people push to a shared repo, but to different branches
[17:38] <jam> we want that to succeed
[17:39] <parthm> jam: that makes sense.
[17:39] <jam> now *if* that is being performed (not with SFTP requests, for example), then 5s is probably reasonable
[17:40] <parthm> jam: i could do a quick check of doing a push from two terminals into one repo at the same time (with 5s timeout). i suppose that should cover it.
[17:41] <parthm> separate branches.
[17:41] <jam> the ordering is... take the name lock, read the current content, compare it with your own content, write up new pack-names content to a temporary file, and then overwrite the existing file (either with simple POSIX rename, or 'fancy-rename'), unlock
[17:42] <jam> parthm: well, there is a bit more 'exact timing' issues than just manually testing
[17:42] <jam> unless you stress test it with a lot of pushes, etc.
[17:43] <parthm> jam: maybe i can just set the timeout to 10s and set the url patch to 'needs review'. these two are actually separate. i can open a bug on getting a better estimate for timeout.
[17:44] <parthm> i agree that a stress test is probably a good way to tune the timeout.
[17:45] <jam> let me think for a sec
[17:45] <jam> I think I can do a simple test
[17:45] <jam> and have it run against a remove bzr
[17:45] <jam> and just see how things go
[17:46] <jam> and hopefully have you/someone in AU run it
[17:46] <parthm> jam: ok.
[19:04] <MTecknology> I'm trying to run  yes yes
[19:04] <MTecknology> I'm trying to run  yes yes | bzr pull  but it's not being picked up by the ssh agent "Are you sure you want to continue connecting (yes/no)? " any ideas how to get around this?
[19:05] <Lo-lan-do> Run bzr pull by hand and say yes to ssh?
[19:06] <MTecknology> Lo-lan-do: scripting this
[19:06] <Lo-lan-do> SSH should then remember your answer
[19:06] <MTecknology> I need to answer it from a script
[19:07] <Lo-lan-do> Set the StrictHostKeyChecking option to false in your SSH config file?
[19:08] <MTecknology> :D
[19:08] <MTecknology> thanks
[19:08] <Lo-lan-do> (I didn't suggest that, and you found about it yourself, and don't complain if you mess up your security)
[19:09] <MTecknology> :P
[19:09] <MTecknology> I can easily comprehend the issues with it
[19:10] <MTecknology> wide open to man-in-the-middle
[20:36] <bendj> I've got a local branch with a parent of "/repos/pf6".  i want to switch the local banch to use, and be in-sync with, a different parent, "/repos/pf6-617".
[20:36] <bendj>   i entered my local branch, and issued a "bzr switch /repos/pf6-617", and got: bzr: ERROR: Cannot switch a branch, only a checkout.
[20:37] <bendj> hm.  so, how do I make the switch?
[20:42] <lifeless> bendj: I think you have two concepts conflated
[20:42] <lifeless> bendj: 'parent' is used for the 'pull' and 'merge' commands.
[20:42] <lifeless> bendj: switch is used to change a checkout to be a checkout of a different branch
[20:43] <lifeless> bendj: can you describe differerntly what you want to happen, maybe I can suggest a way
[20:49] <bendj> lifeless: I did -- (1) bzr init-repo --no-trees /repos (2) cd /repos (3) bzr branch --no-trees source1 (4) bzr branch --no-trees source2  (5) cd /home (6) bzr branch /repos/source1 mysite (7) cd mysite (8) hack, hack, hack ...
[20:49] <bendj>  so, in my language, /home/mysite has a 'parent' of /repos/source1
[20:49] <bendj> i want to switch it to a 'parent' of /repos/source2
[20:49] <bendj> description make sense?
[20:49] <lifeless> bendj: I think what you wanted to do in step 6 was 'bzr checkout --lightweight /repos/source1 mysite'
[20:50] <lifeless> bendj: I can help you make it like that
[20:50] <lifeless> bendj: first, cd to mysite
[20:50] <bendj> i THINK i may need to convert the /home/mysite branch to a checkout (via bind?), then i can do the switch ...
[20:50] <lifeless> and do 'bzr push :parent'
[20:51] <bendj> lifeless push --> "update a mirror of this branch".  sorry, which mirror gets updated?
[20:51] <lifeless> :parent is an alias for 'the parent of this branch'
[20:51] <lifeless> which according to your commands is /repos/source1
[20:52] <lifeless> by  (6) bzr branch /repos/source1 mysite
[20:52] <bendj> lifeless: yup.  but, isn't that going to attempt to 'make changes' to the parent, aka /repos/source1?
[20:52] <lifeless> bendj: isn't that what you wanted ?
[20:52] <bendj> nope.
[20:53] <lifeless> bendj: Do you want to discard the work you've donein mysite ?
[20:54] <bendj> lifeless context -> i'm attempting to update /home/mysite (a pressflow/drupal site, based off the 'release' trunk @ /repos/source1).
[20:54] <bendj> i want to switch /home/mysite to be bbased off newer 'test' branch source of pressflow @ /repos/source2.
[20:55] <lifeless> have you made changes in mysite itself ?
[20:55] <bendj> scads!
[20:55] <lifeless> then you have the following situation
[20:55] <lifeless> branchA (trunk), branchB(test) and branchC(mysite)
[20:56] <lifeless> these all have unique content
[20:56] <bendj> pls keep typing.  brb .... minor emer
[20:56] <lifeless> switch is a command to well, 'switch out' or totally replace a working area with some other branch - it says (for instance), 'I have mysite, but I really want test.'
[20:56] <lifeless> this isn't what you want to do.
[20:57] <lifeless> What I think you want to do is 'bring in the changes that test made so that I have both the work from test and the work from mysite'
[21:00] <lifeless> the way to do that is 'bzr merge /repos/source2; bzr commit -m "Merge in test"'
[22:18] <bendj> lifeless: thanks.  emer wasn't so minor ...  sorry bout that
[23:12] <mgz> man, I keep breaking things
[23:13] <mgz> should have a precommit hook that runs the tests against all four python implementations
[23:13] <lifeless> :)
[23:13] <lifeless> mgz: that would be nice
[23:13] <lifeless> mgz: I thought about a check-all or something
[23:14] <lifeless> but didn't get the activation energy up
[23:24] <mgz> okay, my list of things to do in the branch is at least diminishing
[23:25] <mgz> only hard thing left is decision about moving/renaming some of this 'utils' stuff
[23:25] <mgz> it's a little annoying currently as now testtools.run and testtools.testresult need utils, which pulls in a bunch of code most of which is only needed for Python 2, and some of it only for the test suite
[23:26] <mgz> I think iterate_tests should move anyway as it's part of the base public api
[23:26] <lifeless> agree
[23:32] <lifeless> mgz: so I think iterate_tests should move; we should leave a forwarder behind
[23:32] <lifeless> mgz: we should split 'end users want' and 'only selftest wants' - but for testtools anything generic end users may still want, because of its rather introspective nature
[23:32] <mgz> yup. there's no fancy deprecater as in bzrlib though, right?
[23:33] <mgz> some of this end users indirectly want, but should only be accessible via say, method on testresult
[23:33] <mgz> otherwise they'd need all this horrible version checking in their code as well
[23:34] <lifeless> that seems to be a swings and roundabout distinction
[23:34] <lifeless> unless its already on unittest.TestResult
[23:34] <lifeless> and if it is, they may want to be able to monkeypatch their own - say twisted.trial.TestResult - so a helper function may be nice anway
[23:34] <mgz> ah, I see.
[23:35] <lifeless> I don't see that they would need version checking
[23:35] <lifeless> it can be in our helper, or in our module or whatever
[23:36] <poolie> hi there jam?
[23:47] <thumper> will bzr run as bzrlib within google appengine?
[23:53] <lifeless> it should
[23:53] <lifeless> obviously without the C extensions
[23:53] <lifeless> I don't think anyone has tried.
[23:54] <mgz> would be interesting to see.
[23:54] <lifeless> GAE is a classic example of why we have a no-C-requirement policy
[23:54] <lifeless> even though I waver on that from time to time
[23:55] <lifeless> I think we could be _so_ much faster if we went pure C, with a python version as a port rather than the primary environment.
[23:57] <davidstrauss> I'm helping a person who's getting "bzr: ERROR: Unsupported protocol for url "ancestor:lp:~pressflow/pressflow/merge-drupal-6.17" when running "bzr diff --old=ancestor:lp:~pressflow/pressflow/merge-drupal-6.17"
[23:59] <thumper> lifeless: having a main function in C with a python fallback seems OK to me...
[23:59] <thumper> lifeless: is this not allowed?


[04:29] <tjaalton> ahasenack: done
[07:12] <dupondje> https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1764819
[07:12] <dupondje> Might be something important to fix? The more people upgrade their windows server, the more people will have issues with freerdp connecting to it ...
[07:23] <dupondje> don't know who would be the best to guy to get this fixed :)
[07:23] <dupondje> Guess we don't want to take the cosmic version for bionic? (which is the best option I guess)
[08:29] <seb128> doko, hey, you didn't reply yesterday about the new theme ... do you think it's possible to have a pre-ack so we can start shipping it? knowing we are the maintainer and commit to fixing issues raised by the review if there is any?
[10:07] <rbasak> bdmurray: SRU reviewing xfce4-terminal in the Bionic queue, I'm not sure what to do about the translation and build system noise. Is that OK?
[10:46] <infinity> rbasak: It's expected for a new upstream.
[12:22] <smb> mvo, you might be interested in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1784843
[12:43] <coreycb> doko: is python3.7-dbg up to speed with debug symbols? i'm getting a coredump but can't make much sense of it.
[12:45] <coreycb> doko: nm user error i think
[12:57] <mvo> smb: thank you, looking!
[13:25] <coreycb> doko: i may need a hand with this: https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1784854
[14:40] <smoser> cjwatson_ or bdmurray i'd appreciate review of https://code.launchpad.net/~smoser/software-properties/trunk.lp1667725-https-signing-key/+merge/351824 . It seems to me to be a general improvement.
[15:40] <smb> mvo, It appears this was just an unfortunate flipping of bits at some point. I did mark my bug as invalid
[15:54] <mvo> smb: thanks for the update! interesstinng
[15:55] <mvo> smb: if you still have the sd card a hash of the snapd binary and snap binary might be interessting to see if the binary on disk got corrupted
[15:56] <smb> mvo, though I have the SD card the first step I tried was a re-install of the dpkg, so that is gone
[15:57] <mvo> smb: ok, no worries. your conclusion sounds right
[16:01] <smb> mvo, After finding that I remembered dpkg --verify and found that a few more things were affected. But all of those much less obvious or likely to notice. I need to make a note to remember doing that next time
[17:14] <xnox> Laney, what is the backing store for lxd for the armhf-on-arm64 runners? i'm trying to reproduce
[17:14] <xnox> compat_uts_machine=armv7l
[17:14] <xnox> bah
[17:14] <xnox> Unable to read extent map for '/usr/lib/systemd/tests/test-sleep': Inappropriate ioctl for device
[17:14] <xnox> Assertion 'test_fiemap(argv[0]) == 0' failed at ../src/test/test-sleep.c:94, function main(). Aborting.
[17:14] <xnox> but failing to do so, on an arm64 bare-metal instance, with lxd container.
[17:15] <xnox> so wondering what is the "backing" store for the containers on the production machines.... dir? btrfs?
[17:30] <xnox> Laney, managed to reproduce =)
[17:30] <xnox> win
[17:30] <xnox> with btrfs backend
[19:23] <slangasek> stgraber: hi, so for LP: #1302192, you several years ago marked ping setuid because "there's currently no good ways to have capabilities be kept in all our images".  Is this still a concern?  This comes up because a customer has noticed /usr/bin/mtr-packet also has fscaps configured.  Should we still not be able to rely on xattr support on all our rootfs types?
[19:28] <stgraber> slangasek: so it mostly depends on how much we care about tarballs and backward compat of squashfs
[19:28] <slangasek> stgraber: GNU tar has a --xattrs option now
[19:29] <stgraber> slangasek: recent squashfs implementations do support xattrs I believe, so as long as our build systems aren't running ancient versions of squashfs-tools that should be fine
[19:29] <slangasek> stgraber: I do see that in the existing pipeline, a newly-launched lxd container ends up without the fscaps but I haven't looked into it
[19:29] <slangasek> stgraber: I guess my question is, if I fix that, do you know of any reasons we shouldn't just require fscaps support as a baseline, and revert the iputils diff?
[19:29] <stgraber> slangasek: right but from what I remember about tarballs, it's an extension which redhat made a while back which isn't strictly compatible with the tar format, so some unpackers may crash
[19:30] <slangasek> stgraber: fair; otoh I don't think we distribute our rootfs as tarball anywhere except to a particular cloud partner?
[19:31] <stgraber> slangasek: LP build chroots are tarballs and we publish a -root.tar.xz for all cloud images on cloud-images.u.c
[19:31] <stgraber> slangasek: the ubuntu-base image on cdimage/releases is also a tarball
[19:33] <stgraber> ah, base and possibly LP chroots may be fine as they likely don't contain iputils
[19:34] <stgraber> looking into tar xattr, looks like the issue is incompatible format for xattrs between GNU tar and libarchive
[19:37] <slangasek> stgraber: and certainly, "fails to restore xattrs on unpack with certain unpackers" is a lesser bug than "fails to unpack with certain unpackers"
[19:37] <stgraber> slangasek: indeed, loosing the xattr is probably acceptable
[19:38] <stgraber> slangasek: I wish xattrs were better tracked in .deb packages though, if we had a .xattr file under /var/lib/dpkg/info/, we could trivially write a tool (cloud-init hook?) that could re-apply them all on startup, or if that fails, make all affected files setuid.
[19:39] <slangasek> stgraber: the root.tar.xz on c-i.u.c, we thought we were dropping, then we had a downstream requirement to bring it back (so it's present again in cosmic).  And it contains mtr-tiny, so is currently affected by this bug, which we either fix by adding xattrs to the tarball or by hacking mtr to not use xattrs (which would be less secure)
[19:42] <stgraber> slangasek: ok, anyway, I'm not opposed to having that delta be dropped, but this needs to be done carefuly, needs to be documented in the 18.10 announcement and we should expect a good pile of bugs as a result of it because people tend to like using tarballs/rsync with their systems and are unlikely to be passing --xattr to both of those right now.
[19:42] <slangasek> stgraber: ok, I think I'm going to post to ubuntu-devel and propose that we standardize on xattrs: yes
[19:43] <stgraber> AFAICT unsquashfs extracts xattrs by default, so that one should be fine
[19:46] <slangasek> rcj: ^^ fyi
[19:53] <rcj> slangasek: thank you
[19:55] <stgraber> slangasek: https://github.com/lxc/lxd/pull/4861 <- LXD side of this
[19:56] <slangasek> stgraber: is that sufficient to fix the fscaps on /usr/bin/mtr-packet?  i.e. the squashfs we're producing is already correct?
[19:57] <stgraber> slangasek: that only changes handling of tarballs and rsync, squashfs is supposedly unpacking xattrs by default which would suggest that your squashfs is bad?
[19:57] <slangasek> ok
[19:57] <stgraber> then again, mksquashfs says that it stores xattrs by default
[19:57] <slangasek> yeah, I will investigate
[19:58] <stgraber> how's the squashfs generated? is it directly coming off the build directory or is that getting repacked somewhere that might go through one of tar, rsync or a fs that's not capable of storing xattrs (or uses fakeroot/fakechroot which I suspect also may not know what an xattr is)
[19:58] <slangasek> it's generated by livecd-rootfs, it ought to be straight from the build dir without any intermediate tar streaming. But I'll dig
[19:59] <stgraber> and that's running as real root?
[19:59] <slangasek> # mount /var/lib/lxd/images/90203fd4cf8732375207ecbde3a1672466dbbfd72a12e39469db9ee6f51b0bbf.rootfs /mnt
[19:59] <slangasek> # getcap /mnt/usr/bin/mtr-packet
[19:59] <slangasek> /mnt/usr/bin/mtr-packet = cap_net_raw+ep
[19:59] <stgraber> oh, good, so the cap is there
[19:59] <slangasek> so the squashfs was good, but it's not visible within the container?
[19:59] <stgraber> what storage backend are you using?
[20:00] <stgraber> zfs has some restrictions on xattrs by default for example
[20:00] <slangasek> it's zfs
[20:01] <stgraber> slangasek: what does "zfs get xattr lxd/images" get you?
[20:01] <slangasek> NAME        PROPERTY  VALUE  SOURCE
[20:01] <slangasek> lxd/images  xattr     on     default
[20:02] <stgraber> ok, I usually set that to "sa" to support a larger set of attributes but I don't know that it'd cause the attr to just be stripped
[20:02] <stgraber> I wonder if it's unsquashfs' manpage lying to us
[20:02]  * stgraber tests
[20:03] <stgraber> oh, or maybe not...
[20:03] <stgraber> it may just be unpriv fscaps causing it
[20:03] <stgraber> lets see
[20:03] <slangasek> stgraber: I ran getcap on the mountpoint on the host also; it's not there
[20:04] <slangasek> $ getcap /var/lib/lxd/storage-pools/lxd/containers/caring-calf/rootfs/usr/bin/mtr-packet
[20:04] <slangasek> $
[20:04] <stgraber> ok, so unsquashfs is the likely suspect then, unless LXD changing permissions caused the kernel to strip the attr which is plausible too
[20:05] <stgraber> yup, that's it, it's the uid/gid remapping that's stripping it...
[20:05] <stgraber> stgraber@castiana:~$ lxc launch ubuntu-daily:cosmic c2 -c security.privileged=true
[20:05] <stgraber> Creating c2
[20:05] <stgraber> Starting c2
[20:05] <stgraber> stgraber@castiana:~$ lxc exec c2 -- getcap /usr/bin/mtr-packet
[20:05] <stgraber> /usr/bin/mtr-packet = cap_net_raw+ep
[20:05] <stgraber> so that's gonna be fun to fix...
[20:06] <slangasek> heh
[20:06] <slangasek> stgraber: feasible fun or infeasible fun? :)
[20:06] <slangasek> if you can't fix it, that puts a damper on a proposal to allow fscaps in packages
[20:07] <stgraber> should be feasible but I'd need to look into hallyn's work on unpriv fscaps
[20:07] <stgraber> I don'
[20:07] <slangasek> ok
[20:07] <stgraber> I can't remember if we can just set it the normal way in the xattrs or if we need to store the namespaced key
[20:07] <stgraber> I suspect we want the namespaced key so that the container user can update the binary later on but that's a bit of a blur in my head now :)
[21:26] <slangasek>        --xattrs-include=PATTERN
[21:26] <slangasek>               Specify the include pattern for xattr keys.  PATTERN is a  POSIX
[21:26] <slangasek>               regular expression.
[21:26] <slangasek> LIES
[21:32] <mwhudson> is it an emacs regular expression?
[21:43] <hallyn> whzzup
[21:47] <hallyn> slangasek: I'm probably misunderstanding, but it sounds like you're expanding a tarball with xattrs in a userns, then expecting to see those from the host;  you'll only see them as xattrs from within a userns which has the same host uid mapped to root
[22:02] <slangasek> hallyn: this is lxd doing the expanding, and it winds up with fscaps disappearing from the rootfs of an unprivileged container (when viewed from either inside or outside)
[22:21] <sladen> ~
[23:07] <rbasak> infinity: did you conclude if you want to accept the nodejs openssl ABI/soname link change?
[23:07] <rbasak> bug 1779863
[23:58] <ogra> hmm, anyone familiar with journald ? ... according to the journald.conf manpage the commented values in journald.conf are the defaults ...
[23:58] <ogra> there are no size limites set in that file which makes me assume there is no upper limit for the logs ...
[23:59] <ogra> the logs are stored in /run ... which in turn is a tmpfs we mount with a fixed size (10% of the RAM it seems)
[23:59] <ogra> so that seems to be my upper limit for the logs ...