[16:07] <mup> Bug #1834978 changed: [2.5] too many rndc reload during commissioning <sts> <MAAS:New> <bind9 (Ubuntu):New> <https://launchpad.net/bugs/1834978>
[16:13] <mup> Bug #1834978 opened: [2.5] too many rndc reload during commissioning <sts> <MAAS:New> <bind9 (Ubuntu):New> <https://launchpad.net/bugs/1834978>
[16:19] <mup> Bug #1834978 changed: [2.5] too many rndc reload during commissioning <sts> <MAAS:New> <bind9 (Ubuntu):New> <https://launchpad.net/bugs/1834978>
[16:25] <mup> Bug #1834978 opened: [2.5] too many rndc reload during commissioning <sts> <MAAS:New> <bind9 (Ubuntu):New> <https://launchpad.net/bugs/1834978>
[16:31] <mup> Bug #1834978 changed: [2.5] too many rndc reload during commissioning <sts> <MAAS:New> <bind9 (Ubuntu):New> <https://launchpad.net/bugs/1834978>
[16:34] <mup> Bug #1838663 opened: Bug with the power configuration of the maas controller <MAAS:New> <https://launchpad.net/bugs/1838663>
[19:48] <ryan> Hi there, I've working on debugging an issue with an installed MaaS instance at $WORKPLACE.  after upgrade to MaaS 2.6, it seems that the generated dhcpd.conf does not include the boot filename options for any other vlans/subnets outside of the one the MaaS vlan itself is in.
[19:49] <ryan> We manually modified the config and copied the bootfile options to another subnet section of the config and lo-and-behold, we finally saw a machine on that subnet succesfully PXE-boot.  I've scoured through the MaaS docs and google'd until my fingers bleed, maybe I've missed something.  Has anyone here seen a similar issue?
[19:51] <ryan> *outside of the one the MaaS server itself is in* first sentence should have read. apologies :/
[19:57] <ryan> from my backup of the /var/lib/maas directory before the update to 2.6, it seems that dhcpd.conf used to be generated with the boot filename options in the global part of dhcpd.conf.  now after update, it only generates the boot filename options in the subnet section that MaaS itself is in.
[20:58] <ltrager> ryan: I believe this is expected so devices on other vlans/subnets don't PXE boot when they shouldn't
[20:58] <ltrager> ryan: you could add a custom DHCP snippet to get them back
[20:58] <ltrager> ryan: if you think thats wrong please file a bug :)


[15:58] <nacc_> o/ (a little early)
[15:59] <caribou> \o (one minute ahead)
[16:01] <powersj> o/
[16:02] <cpaelzer> o/
[16:02] <smoser> o/
[16:02] <nacc> #startmeeting ubuntu-server-team
[16:02] <meetingology> Meeting started Tue Jul 12 16:02:20 2016 UTC.  The chair is nacc. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:02] <meetingology> Available commands: action commands idea info link nick
[16:02] <nacc> #topic Review ACTION points from previous meeting
[16:02] <rbasak> o/
[16:03] <jgrimm> o/
[16:03] <nacc> afaict, there were no previous action points?
[16:03] <nacc> #topic Yakkety Development
[16:03] <nacc> #link https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule
[16:03] <nacc> anything on yakkety to discuss?
[16:03] <caribou> nacc: yes;
[16:04] <caribou> nacc: do you remember the clamav git tree issue ?
[16:04] <nacc> caribou: off the top of my head, no :)
[16:04] <nacc> caribou: was that the one that went backwards in the publishing history?
[16:04] <caribou> nacc: neverming
[16:05] <caribou> nacc: different issue, I'm the one with wired crossed :)
[16:05] <nacc> caribou: :)
[16:06] <rharper>  o/
[16:06] <caribou> The clamav merge MP is just waiting for final review
[16:06] <nacc> caribou: ah great; i'll try and take a look later today (although rbasak still has to do the actual sponsorship :)
[16:06] <nacc> anyone else with any yakkety discussion?
[16:07] <nacc> #subtopic Release Bugs
[16:07] <nacc> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-x-tracking-bug-tasks.html#ubuntu-server
[16:07] <nacc> (note i fixed the wiki irccommands page, which still had -w as the link)
[16:07] <rbasak> Sorry, I've been focused entirely on MySQL. I'm coming out of that hole now. I'm coming out of that hole now though. I hope to catch up on reviews and sponsoring this week.
[16:07] <nacc> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-y-tracking-bug-tasks.html#ubuntu-server
[16:08] <caribou> rbasak:  I can upload clamav if it can help
[16:08] <nacc> rbasak: as we had discussed earlier, i'll try and at least help with the reviews; have you had a cahnce to push your import-linter?
[16:08] <rbasak> nacc: no, I should do that. Sorry.
[16:08] <nacc> rbasak: np; just want to make sure we're on the same set of tools
[16:08] <cpaelzer> looking at the bugs, there are two new libvirt bugs - who is looking at them atm - smb?
[16:09] <rbasak> nacc: pushed
[16:10] <nacc> rbasak: thanks!
[16:11] <jgrimm> cpaelzer, are you looking at y or x report? wrt to your libvirt question
[16:11] <cpaelzer> x
[16:11] <cpaelzer> I havent read the details, just checked the new/unassigned ones and seeing two libvirt
[16:12] <cpaelzer> bug 1571209
[16:12] <nacc> i think that's LP: #1561019 and LP: #1571209
[16:12] <nacc> :)
[16:12] <cpaelzer> yes
[16:12] <jgrimm> second one has definitely been around awhile
[16:12] <nacc> I believe hallyn had looked at the cpu flags one
[16:12] <nacc> jgrimm: i think that's the one i was mentioning to you before as to whether someone should pick it back up
[16:12] <jgrimm> ah, ok will look at it offline
[16:13] <jgrimm> give me an action
[16:13] <jgrimm> to check whether it needs some assigned t
[16:13] <nacc> #action jgrimm to review libvirt bugs (LP: #1561019) for reassignment
[16:13] <meetingology> ACTION: jgrimm to review libvirt bugs (LP: #1561019) for reassignment
[16:13] <jgrimm> tx
[16:13] <nacc> if nothing else, moving on
[16:14] <nacc> #topic Server & Cloud Bugs (caribou)
[16:14] <caribou> been quite busy with four kdump-tools bugs on s390x & ppc64el
[16:14] <caribou> hoping to SRU them shortly
[16:14] <nacc> caribou: all related to that reworking? or new bugs?
[16:14] <caribou> nacc: bug fixed in yakkety mostly & one new bug
[16:15] <nacc> caribou: ah ok
[16:15] <caribou> so SRU for all of them
[16:15] <nacc> caribou: do you have a good testing environment across all the arches for kdump/kexec (and all the myriad of combinations for backing storage)?
[16:15] <caribou> I can list them here if needed
[16:15] <caribou> nacc: short answer : no :)
[16:16] <nacc> caribou: heh :)
[16:16] <nacc> was just wondering
[16:16] <caribou> I've been working on DEP8 tests but they're to unstable to be pushed to the archive
[16:16] <caribou> they all require forcing a kernel crash and qemu tends not to be able to recover correctly, hence blocking the test
[16:17] <nacc> yep, makes sense
[16:17] <jgrimm> caribou, very nice
[16:17] <caribou> oh, and one new upstream sosreport release
[16:17] <caribou> that's all I have
[16:18] <caribou> still want the bug numbers ?
[16:18] <nacc> i guess it doesn't hurt to record them
[16:18] <caribou> LP: #1571590 LP: #1568952 LP: #1599561 LP: #1570775
[16:19] <nacc> caribou: thanks!
[16:19] <nacc> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
[16:19] <arges> nothing to report. everything is awesome.
[16:19] <nacc> yay!
[16:19] <nacc> #topic Upcoming Call For Papers
[16:20] <nacc> #topic Ubuntu Server Team Events
[16:20] <nacc> nothing planned afaik
[16:20] <nacc> #topic Open Discussion
[16:21] <powersj> quick qa update: ppc64 vm is working now after resolving proxy issues with IS. Curtin ppc64 can now be run on it. I manually modified the jenkins tests, but need to go back and update it through Jenkins Job Builder today.
[16:21] <powersj> Quickly looking at curtin-vmtest failure (403) that has gone on since March and then will start looking at cloud-init-ci work.
[16:21] <nacc> powersj: oh sorry!
[16:21] <nacc> #topic Weekly Updates & Questions for the QA Team
[16:21] <nacc> powersj: great to hear!
[16:22] <powersj> thx would also still like to meet with folks to ask questions and gather thoughts
[16:22] <nacc> powersj: i think you're always welcome to ask on IRC and on the ML (or here, tbh)
[16:22] <powersj> k
[16:22] <nacc> #topic Open Discussion
[16:23] <nacc> flipping back to the open discussion, anyone have anything?
[16:23] <nacc> #topic Announce next meeting date, time and chair
[16:23] <nacc> coreycb is currently set to chair, jul 19 at 16:00 UTC
[16:24] <nacc> non-server team bug folks are done, we'll switch topics to that
[16:24] <nacc> #topic Assigned merges/bugwork (rbasak)
[16:24] <rbasak> I need to defer again, sorry. I will dedicate a day to catch up this week in time for next week's meeting.
[16:24] <coreycb> nacc, got it, I'll make a note of it :)
[16:24] <nacc> rbasak: np, i will try and help out too, now that we have a shared spreadhseet
[16:24] <rbasak> Thanks, appreciated.
[16:24] <nacc> coreycb: i'll also send you a reminder email :)
[16:24] <coreycb> nacc, thanks
[16:25] <teward> *late again*
[16:25] <nacc> alright, thanks everyone!
[16:25] <nacc> teward: oh did you want to bring up any nginx stuff?
[16:25] <teward> nacc: all detailed in my blog post, but for the future we're going to have to track mainline again
[16:25] <teward> just for the radar: it's for the openssl problems seen in Debian
[16:26] <teward> and it's a tricky merge - call for testing in a week on the ML if anyone wants to test
[16:26] <nacc> teward: ok, thanks for the update!
[16:26] <nacc> #endmeeting
[16:26] <meetingology> Meeting ended Tue Jul 12 16:26:22 2016 UTC.
[16:26] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-07-12-16.02.moin.txt
[16:26] <teward> (via PPAs first, before I even consider including in the repos)
[16:26] <teward> *goes back to figuring out why said merge is failing to build*
[16:26] <nacc> teward: ack (i'll adjust in the meeting logs)
[16:27] <teward> nacc: no problem, it's become an issue on the radar more given other ubuntu-devel-discuss / ubuntu-server ML threads
[16:27] <nacc> teward: yep, makes sense
[16:27] <teward> and Debian-level threads (experimental is rolling openssl 1.1.0 now, and they want to make sure things 'build' before it's made available
[16:29] <jgrimm> thanks nacc


 I'm curious -- has an alternate approach been introduced since I was last current, or is that still the only branching model from a UI perspective?
[00:07] <Kamping_Kaiser> i think its the same
[07:03] <sabdfl> nDuff: you can work differently, if you prefer
[07:03] <sabdfl> you can have a shared repo which has all the revisions for all of your branches
[07:04] <sabdfl> and "treeless" branches inside that. those are subdirectories, but just include the branch info, so they are basically invisible
[07:04] <sabdfl> then, you can have a single checkout of one of the branches somewhere, which is where you work
[07:04] <sabdfl> and you can "switch" that checkout from branch to branch
[07:04] <sabdfl> when you switch, the working directory gets changed to reflect the tip of the branch you just switched to
[07:05] <sabdfl> and then when you commit, the new revision goes into the shared repository, and metadata for it is added to the branch you are working on
[07:05] <sabdfl> does that make sense? shout if i have not explained it well
[07:06] <sabdfl> but this is one of the beauties of bzr - the pieces are orthogonal, so you can have a workflow that suits you
[07:06] <sabdfl> much more easily than any of the other dvcs'
[07:06] <cammoblammo> Umm, sabdfl, nDuff posted that abut eight hours ago. It's a pretty good explanation though, and I found it quite useful!
[07:07] <sabdfl> cammoblammo: thank you! he's still logged in as nDuff so perhaps he'll spot the response later
[07:07] <cammoblammo> ;-)
[08:31] <timely> hello world
[08:32] <timely> can someone help me get lost in bzr documentation?
[08:34] <timely> alternatively, can i edit the bzr wiki w/o some magical bits?
[08:37] <sabdfl> timely: you can easily do both, i think
[08:37] <sabdfl> are you wanting to contribute to the docs or the wiki?
[08:39] <timely> i don't really want to do either. but there are grammatical errors on http://bazaar-vcs.org/Integrating_with_Bazaar so i figure if it doesn't require lots of effort, i'm willing to make a wiki account to make some changes
[08:39] <timely> i'm trying to write some perl based integration to 'dead bzr trees'
[08:39] <timely> i.e. a file system copy of a bzr repository (where there may or may not be a valid or useful instance of bzr installed)
[08:40] <timely> mostly, i need to be able to figure out how to generate links to what i guess is bzr web
[08:40] <timely> although i have no idea what its formal name is
[08:41] <timely> probably loggerhead actually, i guess
[08:43] <timely> nice (503) http://www.lag.net/branches/loggerhead/loggerhead_dev/
[08:43] <timely> (empty) http://www.lag.net/robey/code/loggerhead/
[08:43]  * timely sighs
[08:43] <TFKyle> timely: might want to look at the branches on launchpad
[08:45] <timely> i
[08:45] <timely> 'm there
[08:45] <timely> i'm quite lost
[08:45] <timely> all i want to know is
[08:46] <timely> given (.bzr/*, path/filename) how to calculate a url for a "log view" pinned to path/filename for the version controlled by .bzr/* and an annotation view for the same
[08:46] <timely> i do not intend to read 1000 branches of a project just to figure out there's no useful documentation :)
[08:49] <timely> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/98826 seems to be what i want
[08:49] <timely> although i can't figure out if the loggerhead i have available supports it
[08:51] <timely> certainly the one i'm talking to is generating the other url format... which is amazingly unhelpful :(
[08:52] <timely> anyway... do i need to do more than simply create a wiki account to edit that first url?
[08:53] <timely> if not, i'll create an account and change it. otherwise, i'll stop considering
[08:53] <timely> https://code.launchpad.net/loggerhead it says You can _browse the source code _for ...
[08:54] <timely> is that part of loggerhead's content or is that launchpad itself being clever?
[08:56] <jml> timely: the link from code.launchpad.net is generated by Launchpad.
[08:56] <jml> timely: but maybe I'm misunderstanding the question?
[08:57] <timely> the space after 'code' is underlined as part of the link
[08:57] <timely> one doesn't typically do that. it's an error in the html
[08:57] <jml> timely: right. that's a bug.
[08:58] <timely> either because someone left a space in raw html, an input field, or in the generator
[08:58] <timely> but i need to know which  :)
[08:58] <jml> timely: I'm not sure why you need to know.
[08:58] <timely> i only want to send one report to the right team :), but i will report it :)
[08:59] <jml> timely: oh I can file the bug.
[08:59] <timely> ok :)
[08:59] <jml> timely: I'm on the relevant team :)
[09:00] <jml> timely: https://bugs.launchpad.net/launchpad-bazaar/+bug/236452
[09:01] <timely> :)
[09:02] <timely> ok, so http://bazaar-vcs.org/Integrating_with_Bazaar Committing Changes
[09:02] <timely> To commit only certain files, we need to provide a list of filenames which we want committing, eg:
[09:03] <timely> should be  "we want committed" or "we want to commit"
[09:04] <timely> fwiw, "e.g." should be spelled w/ <period>s (always)
[09:04] <jml> timely: you should just be able to edit the wiki page.
[09:04] <jml> timely: and yes I agree with both of your points.
[09:05]  * timely tries to create an account
[09:05] <timely> gah
[09:07] <timely> oh brother
[09:07] <timely> if i error in changing the wiki page, it clears all my changes and says "please specify a password"
[09:07] <timely> how helpful...
[09:12]  * timely tries to figure out what to make of "spread over itself"
[09:12] <timely> it sounds like a harlot
[09:12] <timely> distributed between itself (?)
[09:15] <timely> Removing Files
[09:16] <timely> You can remove multiple files at once.
[09:16] <timely> what does "at once" mean?
[09:16] <timely> does it mean "together" or "immediately"?
[09:16] <jml> together.
[09:16] <timely> originally i assumed the latter, but.. thanks
[09:16] <jml> "at the same time"
[09:16] <timely> should i take a lock on this url so that i don't collide with anyone else? :)
[09:16] <jml> keep hitting preview.
[09:17] <timely> i'm using TextEdit.app because my browser sucks :)
[09:17] <jml> "This gives us a WorkingTree object, which has various methods spread over itself, and its parent classes MutableTree and Tree" could be rephrased to:
[09:17] <timely> note that there's an instance of "its" that should be "it's" somewhere nearby (already fixed locally)
[09:18] <timely> (this page clearly wasn't written by someone who cares about English :)
[09:18] <jml> "This gives us a WorkingTree object, which has methods provided by itself and by its parent classes: MutableTree and Tree."
[09:18] <timely> sold
[09:19] <timely> You can rename one file to a different name
[09:20] <timely> ... can i rename one file to the same name ? :~(
[09:20] <jml> "You can change the name of a single file"
[09:20] <timely> thanks
[09:20] <timely> sorry, it's a lot easier for me to spot bugs than come up w/ proper fixes :(
[09:21] <jml> timely: btw, looking at the changelog for the page, lots of changes are made by people who don't speak English as their first language.
[09:21] <timely> fwiw, the document isn't sure if it's speaking in second or first person plural
[09:21] <timely> (you can, we)
[09:21] <timely> if you have a preference ...
[09:22] <jml> timely: I'd default to "you", but just pick whatever you think is best.
[09:22] <timely> you sounds fine, i'll do that later
[09:22] <timely> active voice i presume?
[09:22] <timely> actually,
[09:23]  * timely goes back and start attacking we's
[09:23] <jml> timely: standardizing on voice doesn't bother me so much. who cares as long as it sounds good.
[09:23] <jml> but sure, active works.
[09:24] <timely> gah.. note to self, watch out for misuse of a(n)
[09:33] <timely> will preview tell me if i hit a conflict? :)
[09:33] <timely> IMPORTANT: This should be avoided wherever possible, as it scales with the
[09:33] <timely> length of history::
[09:34] <timely> "scales" ... alternative suggestion? typically people think of "scales" as a positive thing
[09:38] <timely> http://bazaar-vcs.org/Integrating_with_Bazaar?action=diff&rev2=34&rev1=33
[09:38] <timely> i hope that's not too bad
[09:38] <timely> sadly it doesn't really help me w/ my original problem... but :)
[09:40] <timely> eww, loggerhead actually requires its own webserver?
[09:43] <jml> timely: re 'scales': there's not enough info to suggest a replacement.
[09:44] <jml> timely: "the time/memory/bandwidth this takes increases proportionally to the length of history."
[09:44] <jml> timely: I don't know which one.
[09:44] <jml> timely: re loggerhead: it runs it's own webserver but you don't have to present it to the wold
[09:44] <jml> world, rather.
[09:44] <jml> you can use Apache's ProxyPass features.
[09:45] <timely> context was the performance behavior of "branch.revision_history()"
[09:46] <timely> can it actually be bandwidth? i.e. could i be talking to a remote bzr?
[09:46] <timely> increases proportionally is indeed better
[09:47] <jml> timely: you definitely could be talking to a remote repository.
[09:47] <jml> timely: branch = Branch.open('http://example.com/some/branch') works just fine.
[09:49] <timely> so i guess i should copy your entire string... ok, when i'm done figuring out which bzrs i actually have locally, i'll worry about that
[09:49] <jml> timely: oh that reminds me.
[09:50] <jml> timely: using Python to interact with Bazaar will be faster, easier and more flexible than using Perl.
[09:50] <timely> that's nice
[09:50] <timely> sadly, this is just support for an existing tool
[09:50] <jml> timely: I just thought I'd mention it :)
[09:50] <timely> and i'm not going to teach myself python just to integrate with one vcs
[09:50] <timely> which i will use almost never
[09:51]  * timely nods
[09:51] <sabdfl> timely: fwiw, you can use Bzr with most VCS's, if that makes it worth learning more Python
[09:51] <timely> no
[09:51] <timely> :)
[09:51] <timely> for my day job, i use c++/js
[09:52] <sabdfl> and which vcs there?
[09:52] <timely> in my free time, i work on a fairly old and relatively stable tool (mxr.mozilla.org)
[09:52] <timely> well, at times it's using hg, or git, or cvs, or svn, or bzr, or non vcs'd stuff
[09:52] <timely> i think i have trees from p4
[09:53] <timely> and typically the integration hooks aren't things that are really known or usefully knowable from most tools
[09:53] <timely> since it's "where's your web ui" "how do i ask for blame" "how do i ask for log"
[09:53] <timely> those are rarely usefully standardized (if ever)
[09:53] <sabdfl> true
[09:53] <timely> heck, in a lot of cases there's no link between the vcs and the web ui at all :0
[09:54] <timely> as for pull commands, my standard cases don't use simple pulls
[09:54] <timely> they use complicated (or very complicated) checkout scripts
[09:54] <timely> sorry... i'm the edge case... i know most people do benefit from such hints...
[09:55] <pygi> ok, quick question folks
[09:55] <pygi> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Elibburnia-team/libisofs/mainline/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
[09:55] <pygi> when I try to push to lp:libisofs
[09:55] <pygi> I also tried lp:///libisofs
[09:56] <beuno> pygi, you need to run:  bzr launchpad-login username
[09:56] <beuno> it's defaulting to http as you haven't set up a username  :)
[09:56]  * timely presumes it needs  https
[09:56] <sabdfl> it will switch to bzr+ssh when you have logged in, assuming you've setup an ssh key
[09:58] <beuno> AFAIK, bzr 1.5 does a better job at explaining this. Are you using 1.3, pygi?
[09:58] <pygi> beuno, on this machine, yes :)
[09:58]  * sabdfl thinks we should push bzr 2.0 out to stable distros when it's baked
[09:58] <pygi> sabdfl, beuno : thanks ;)
[09:59] <beuno> sabdfl, at this rate, it sould be able to get into Lenny, and, well, I presume you'll be able to get it into Hardy as well  :)
[09:59] <gour> pygi: opet se srećemo ;)
[09:59] <pygi> gour, hehe :)
[10:00] <timely> can i ask questions about loggerhead here? (again, i don't speak python)
[10:00] <pygi> timely, you can try :)
[10:00] <jml> timely: yeah, this is the best channel for loggerhead questions.
[10:00] <timely> i read the README and made a loggerhead.conf
[10:00] <timely> i did not run make because the README made no mention of it
[10:00] <gour> pygi: kupih samsunga 204...prži sve u 16. stara pržilica mi izderala par cd/dvd-a
[10:00] <timely> it did say to run start-loggerhead
[10:01] <timely> File "./start-loggerhead.py", line 3, in ? ... ImportError: No module named pkg_resources
[10:01] <pygi> sudo apt-get install python-pkg-resources ? :)
[10:01] <timely> i don't own this computer (i never own computers), i did not configure or install bzr (although some random unknown version is installed), there are many random (unspecified/unknown) versions of python here
[10:01] <timely> no :)
[10:02] <beuno> timely, loggerhead has a set of dependencies which aren't very clearly layed out. You need turbogears and sqlite to start with
[10:02] <beuno> let me check what else
[10:02] <timely> keep in mind what i said. i don't own this box. that means i'm not and can not be root :)
[10:02] <beuno> timely, ah, that may be a problem then  :)
[10:02] <sabdfl> timely: then ask your admin to pop in here?
[10:02] <timely> i'm not specifying the linux distribution (it is linux)
[10:03] <timely> in general when things are installed by the admin, they make things worse, not better :)
[10:03] <timely> so, if there are instructions for local install, i'll follow them :)
[10:03] <timely> it's 2am, i'd hope he's sleeping :)
[10:04] <beuno> timely, well, loggerhead is complicated enough to get working with root access, I suspect that with just local install, it may prove to be a challenge
[10:05] <timely> ...
[10:05] <beuno> we'de really like to trim down dependencies for it, but it currently has a set of performance issues which are more pressing
[10:05] <timely> note: if i actually could get the admin here, i could just ask him to upgrade his loggerhead install :)
[10:06] <timely> in which case... why would i bother setting it up in the first place? :)
[10:06] <timely> also... something that needs root access doesn't exactly inspire trust :)
[10:06] <pygi> beuno, he could install py and all the deps in   his home dir
[10:06] <timely> [timeless@landfill mxr-test]$ which hg
[10:06] <beuno> timely, there is another web interface for bzr: http://bazaar-vcs.org/WebInterface
[10:07] <timely>  /home/timeless/bin/hg
[10:07] <beuno> http://goffredo-baroncelli.homelinux.net/bazaar
[10:07] <timely> beuno: ... the point of this is to integrate w/ existing things...
[10:07] <timely> i suppose i could setup that one just to integrate w/ it
[10:07] <beuno> it's basically a plugin for bzr, so it should work pretty much out of the box
[10:08] <timely> but my target is integrating http://mxr-test.landfill.bugzilla.org/bugzilla-bzr/source/ with http://bzr.everythingsolved.com/bugzilla/trunk/changes
[10:09] <beuno> interesting
[10:09] <timely> otoh, there's also bugzillamozilla-bzr which doesn't seem to have any web ui
[10:09] <timely> so i suppose i can simply run WebInterface for that and integrate w/ it first
[10:10] <beuno> timely, there is some work going on in Loggerhead (I've been doing lots of it these past weeks), so it should be looking better very soon
[10:10] <timely> maybe i should leave an email address and you can ping me when i should look again..
[10:10] <timely> i was getting annoyed w/ hg and decided i'd look to see how hard integrating bzr would be
[10:11] <timely> it doesn't seem promising :)
[10:11] <beuno> timely, well, bzr does have an xml-output plugin, which is commonly used to integrate into different external tools
[10:11]  * jml is going offline.
[10:11] <timely> http://mxr-test.landfill.bugzilla.org/mozilla-central/source/xpcom/Makefile.in
[10:11] <beuno> maybe that is worth looking at
[10:12] <jml> timely: good luck with the integration.
[10:12] <timely> the integration for hg is basically the "HG Log" and "HG Blame" links at the top
[10:12] <timely> jml: thanks
[10:12] <timely> beuno: how many output flavors does the plugin generate?
[10:13] <timely> so far i've seen 2 different .bzr formats
[10:13] <timely> and i have no faith in xml flavors
[10:13] <timely> (i've also seen and support 2 .svn formats)
[10:13] <beuno> timely, it doesn't relate to bzr's format, it works on a higher level
[10:13] <timely> yes, but have you *changed* the xml it generates?
[10:14] <timely> and will you change it *again*?
[10:14] <timely> the wonderful thing about xml is that no one seems to care about not breaking compatibility
[10:14] <timely> just like internal repo formats
[10:14] <beuno> timely, it hasn't in at least 8 months, and, it's commonly used, so we're *very* careful not to
[10:14] <timely> 8months? hah
[10:14] <timely> the projects i work on are 10+years old :)
[10:15] <timely> things that only change every 8months....
[10:15] <timely> that'd set me back years :)
[10:15] <beuno> I've been using it for over a year in integrating into a PHP aplication, and the Eclipse integration uses it too
[10:15] <timely> but yeah, i understand... and if every month you say it hasn't changed in 8+n months, then eventually that's a good thing :)
[10:15] <beuno> timely, well, the plugin is barely over a year old, so...
[10:15] <timely> sorry, i'm jaded...
[10:15] <beuno> heh
[10:15] <beuno> you can always *not* upgrade and keep using the same format
[10:16] <timely> nope
[10:16] <timely> i don't control what other people use
[10:16] <timely> i'm a middle person
[10:16] <timely> if someone tries to use my tool, they'll use it w/ whichever version of other tools their distro provides
[10:16] <timely> which on average will be *different* from the one i picked
[10:16] <timely> and no. i don't want someone forking mxr
[10:16] <timely> there are already way too many forks of lxr, thank you very much :)
[10:17] <beuno> alright, well, what can we do to help you?
[10:17] <timely> well... do most of these web uis accept the "global repo version" for any file path?
[10:18] <timely> (minus the ones that seem to require some private id instead of a file path)
[10:18] <timely> if so, how do i get that?
[10:18] <timely> i really suspect all i need is that one identifier
[10:18] <timely> (and a non sucky version of loggerhead, which seems to be something i'll have to sleep on)
[10:18] <beuno> well, it uses file_ids, but it wouldn't be too hard for it to accept paths as well
[10:19] <LarstiQ> which gets fun with history viewing, the path in _this_ version, or in _that_ version?
[10:19] <timely> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/98826
[10:19] <timely> LarstiQ: why is it fun?
[10:19] <timely> i only ever have a single version of the repo in front of me
[10:20] <beuno> if you'd like, you can drop me an email (or, to the public bzr list), with what you need, and I can try and fit it in
[10:20] <beuno> LarstiQ, I think he just wants HEAD
[10:20] <timely> a user says "<file here>" "<show me log> for it"
[10:20] <timely> i'm not sure it's necessarily head
[10:20] <timely> although i don't want to look up your definition of HEAD
[10:20] <timely> but i can assure you that the repo will be in a state so whichever it is, the repo will know
[10:20] <LarstiQ> timely: I don't know how mxr works, does it not do any navigating in history at all?
[10:20] <timely> correct
[10:21] <timely> it merely links to someone else who provides that
[10:21] <timely> all it works on is a flat checkout of a <foopy>
[10:21] <timely> how convoluted foopy may be depends on the checkout scripts
[10:22] <timely> there might be a mix of .hg,.svn,.git,.bzr,CVS,.p4,nothing w/ random inconsistent versions for CVS and SVN
[10:22] <LarstiQ> ugh
[10:22] <LarstiQ> well, not your problem then.
[10:22] <timely> right... it's not a problem
[10:22] <timely> as long as i can get the identifier that defines the .bzr state for the directory containing the file
[10:22] <timely> i'm perfectly happy
[10:23] <timely> and i believe *that* shouldn't be so hard
[10:23] <LarstiQ> right
[10:24]  * timely presumes that bzr pull for an unmodified .bzr is functionally equivalent to cvs update for an unmodified CVS
[10:25] <LarstiQ> timely: ignoring weird cvs update corner cases, yeah
[10:25] <timely> then why didn't it work? ;-)
[10:25] <LarstiQ> "just give me the same state as they have over there, kxthbye"
[10:26] <timely> [timeless@landfill bugzilla]$ [ -d .bzr ] && bzr pull
[10:26] <timely> bzr: ERROR: No pull location known or specified.
[10:26] <LarstiQ> timely: I don't know, what is it not doing you expected it to do?
[10:26] <LarstiQ> timely: right, as the error said
[10:26] <timely> my cwd is the parent of http://mxr-test.landfill.bugzilla.org/bugzilla-bzr/source/.bzr/
[10:26] <LarstiQ> timely: it doesn't know where to pull from
[10:27] <timely> man says:
[10:27] <timely>        bzr pull [LOCATION]
[10:27] <timely>               Turn this branch into a mirror of another branch.
[10:27] <timely> traditionally [] means optional
[10:27] <timely> am i misreading man?
[10:27] <LarstiQ> timely: it is optional if the pull location is remembered
[10:27] <timely> http://mxr-test.landfill.bugzilla.org/bugzilla-bzr/source/.bzr/branch/bound
[10:27] <timely> exists
[10:27] <timely> and points to what i think is the right answer
[10:27] <LarstiQ> timely: you're using a checkout?
[10:27] <LarstiQ> timely: try 'bzr update' instead then
[10:28] <timely> ok, that worked
[10:28] <LarstiQ> if you're always using checkouts, stick with update
[10:29] <LarstiQ> timely: just to have mentioned it, although you don't need it, if you do 'bzr pull <location>' once, it will remember that as the pull location.
[10:30] <LarstiQ> timely: If you want to then once pull from somewhere else, 'bzr pull <location2>' will get data from location2 but still remember location1 as where it should normally pull from
[10:30] <LarstiQ> timely: bzr pull <location2> --remember to override that
[10:31] <timely> so what did i do wrong the first time such that it didn't remember?
[10:31] <timely> also, does bzr update understand if it's talking to a tty?
[10:32] <timely> specifically, i don't mind the output at the end where it says what merged, but i don't want the progress indicator since this is being redirected to a file
[10:33] <beuno> timely, adding --quite should do the trick
[10:34] <timely> --quiet / -q, i found that
[10:34] <timely> but i kinda expect that to silence everything
[10:34] <timely> oops
[10:34]  * timely kicks self
[10:34]  * timely has a slightly too greedy regexp
[10:34]  * timely tries to figure out how to handle it
[10:35] <LarstiQ> or you can use BZR_PROGRESS_BAR=tty,dummy,none,dots
[10:35] <beuno> well, I'm off to bed again
[10:36] <LarstiQ> beuno: sleep well
[10:36] <beuno> timely, if you have any remaining questions/requests on loggerhead, don't hesitate to mail the list, or myself<EMAIL_ADDRESS>[10:36] <LarstiQ> timely: why pull didn't have a pull location at first, you used a checkout instead of a standalone branch, which is a different model
[10:36] <beuno> LarstiQ, thanks, and good to see you around here  :)
[10:36] <LarstiQ> timely: if you were to 'bzr branch <foo>' instead of 'bzr checkout <foo>', it would have it's default pull location set
[10:37] <LarstiQ> timely: if you try do pull in a checkout, it will instead run pull on the branch it is bound to
[10:37]  * timely boggles
[10:38] <timely> distributed rcs is too complicated for my tiny little mind
[10:38] <timely> beuno: thanks,
[10:39] <LarstiQ> timely: well, you're mixing centralized and decentralized workflows :)
[10:40] <timely> well... i'm a readonly consumer
[10:40] <timely> i should only ever have one upstream, and i just want the latest and greatest
[10:40] <timely> oh, and i'm a robot, did i mention that?
[10:40] <timely> thinking is really way too complicated for me :)
[10:41] <LarstiQ> timely: right, so 'bzr checkout <upstream>' once, 'bzr update' always after that, should cover your use case perfectly.
[10:41] <timely> right, which is probably why i used bzr checkout in the first place
[10:41] <timely> stupid question. would it hurt bzr to suggest "did you mean bzr update" when i do bzr pull?
[10:41] <timely> if this tool were an opensolaris tool, i suspect it'd have said that
[10:42] <timely> note: that's a non interactive error, the user should be forced to type the correct thing at a new prompt
[10:43] <LarstiQ> timely: maybe
[10:43] <timely> in unrelated bits, can i demote a pull to a checkout?
[10:44] <timely> since i think the second bzr repo i made was a branch instead of a checkout
[10:44] <LarstiQ> timely: detecting the case where you're in a checkout and have no pull location would be doable. But what if the pull location _is_ set?
[10:44] <LarstiQ> timely: you can convert a standalone branch into a checkout and vice versa with bind/unbind
[10:44] <timely> i'm not sure what that means :)
[10:44] <timely> (to the former)
[10:45] <timely> (which doesn't mean i can't parse your English, just that i don't speak bzr)
[10:45] <LarstiQ> timely: that means I'm not sure if suggesting to use update instead of pull is a good thing to try to do.
[10:45] <timely> no, that part i understood
[10:46] <timely> what i don't understand is what it means conceptually to have both a checkout and a pull source
[10:46] <LarstiQ> timely: Ah.
[10:47] <LarstiQ> timely: Are you sure you want to know this? It gets rather decentralized :)
[10:47] <timely> i'll live, if it means i get a chance to convince you to improve the error reporting :)
[10:47] <timely> all of the work i'm doing these days is decentralized
[10:48] <LarstiQ> ok
[10:48] <timely> but... i don't drink, so stop if it sounds like you'll force me to drink :)
[10:48] <LarstiQ> timely: First, remembering a pull location or the bound branch is just storing data, that in itself doesn't change the behaviour.
[10:49] <timely> "which behavior" :)
[10:49] <LarstiQ> timely: right. The behaviour of it beign a standalone branch or a checkout.
[10:50] <LarstiQ> timely: In a standalone branch, your workflow would be: branch once, pull/push after that, respectively to the remembered pull and push locations.
[10:51] <LarstiQ> timely: in a checkout, your workflow would usually be to checkout once, or otherwise bind a standalone branch, and then use update/commit for sending over revisions.
[10:51] <LarstiQ> timely: (obviously, in a standalone branch you also need to commit, but the act of sending it across the wire is decoupled into pull, whereas with a checkout a commit makes a new revision _and_ pushes it out to the master)
[10:52] <LarstiQ> timely: Now, using pull in a checkout is also possible, but it doesn't do the same thing as in a standalone branch.
[10:53] <LarstiQ> timely: pull in a checkout will update the branch it is bound to, as well as the local version
[10:53] <LarstiQ> unless I've been gone too long and I'm severely mistaken
[10:54] <LarstiQ> timely: as beuno said, I haven't been around in a while
[10:54]  * timely missed that last bit by beuno
[10:54] <timely> but ok :)
[10:54] <LarstiQ> anyway
[10:56] <LarstiQ> timely: I'm going to start my day in a couple of minutes, do you have enough information for now?
[10:57] <timely> so pull in a checkout is kinda like changing branches (but potentially or likely changing repos which isn't something that i care about)
[10:58] <timely> i  think it's a non issue
[10:58] <timely> anyone doing pull in a plain checkout will get an error the first time
[10:58] <timely> with a suggestion to do update
[10:58] <timely> anyone who actively uses pull w/ a url "knows what they're doing"
[10:58] <timely> and the next time they do a pull, they'll get what they want
[10:59] <timely> however, anyone doing pull in a checkout w/o a url doesn't know what they're doing
[10:59] <LarstiQ> I'm not so sure.
[10:59] <timely> (i.e. me) and just wants an error w/ a suggestion
[10:59] <LarstiQ> timely: it's perfectly legitimate to run pull without any arguments in a checkout.
[10:59] <timely> but it errors!
[11:00] <timely> that's what started this conversation :)
[11:00] <LarstiQ> timely: only in this very specific case
[11:01] <LarstiQ> timely: And as I said, that can be detected and warned about. But I fear there are more cases where someone doesn't know what they're doing and we can not detect it.
[11:01] <timely> personally, my general view is that you should add warnings/errors where possible
[11:01] <LarstiQ> timely: but yeah, I don't know.
[11:02] <timely> instead of throwing up your hands and saying "we can't be perfect"
[11:03]  * LarstiQ can't think this through right now.
[11:03] <timely>    bzr pull [LOCATION]
[11:03] <timely>            --remember                Remember the specified location as a
[11:03] <timely>                                      default.
[11:03] <LarstiQ> timely: but feel free to suggest it to someone who has actually been working on bzr lately :P
[11:03] <timely> English nit: "how many defaults can bzr have for a single repo"?
[11:03] <timely> "a default" ^
[11:04] <LarstiQ> timely: unlimited
[11:04] <LarstiQ> but I see what you're getting at.
[11:04] <timely> good. because i really don't want to hear the explanation for your answer :)
[11:05] <LarstiQ> there is no limited to the amount of branches in a repository ;P
[11:05] <LarstiQ> I do think you meant to say branch, and in that case, it's not unlimited.
[11:05] <LarstiQ> vcs lingo yay
[11:05] <timely> i didn't say branch
[11:06] <LarstiQ> right
[11:06] <timely> oh
[11:06] <LarstiQ> timely: and the default is on a per branch basis.
[11:06] <timely> bah. i was trying to be so careful
[11:06] <timely> i should have said .bzr/
[11:06] <timely> would that have been any more or less ambiguous?
[11:07] <LarstiQ> well, there is {.bzr/repository,foo/.bzr/branch} etc
[11:07] <LarstiQ> timely: more ambiguous
[11:07] <timely> gah.
[11:07] <LarstiQ> timely: You find a .bzr in 3 locations: repositories, branches, and working trees.
[11:07] <timely> i'll settle for you understanding what i meant and praying you'll find someone who can fix the docs to be less strange :)
[11:08] <LarstiQ> you find 'a default' strange?
[11:08] <timely> yes
[11:08] <LarstiQ> I'm not native enough to do so.
[11:08] <timely> normally you'd write "the default"
[11:09] <timely> if you don't mean "the default" then you should write "the default for <x>"
[11:09] <LarstiQ> right
[11:09] <LarstiQ> that is possible
[11:09] <timely> part of the definition or meaning of default is that it is the *one* that would happen
[11:09] <LarstiQ> 'for this branch.'
[11:09] <timely> it's supposed to be unique
[11:09] <LarstiQ> timely: per thingy
[11:09] <timely> so it isn't legal to say "a default"
[11:09] <LarstiQ> eh, I disagree :)
[11:09] <timely> because "a default" implies that there's more than one
[11:09] <LarstiQ> but there is! In the context of stuff to remember for a branch.
[11:10] <timely> pull in the context as "the default for the branch"
[11:10] <LarstiQ> I can see your viewpoint, sure.
[11:11] <LarstiQ> timely: and I wouldn't mind a patch for it, but I won't be doing it myself.
[11:11] <timely> i'll write one if i can figure out how
[11:12] <timely> do i checkout or branch ;-?
[11:12] <LarstiQ> with that, I can help you.
[11:12] <LarstiQ> timely: branch.
[11:12] <timely> grr
[11:12] <timely> ok, so much for me not teaching mxr about bzr branching
[11:12] <LarstiQ> timely: you want to commit in this case
[11:13] <LarstiQ> timely: you don't have access to upstream to do that.
[11:13] <timely> gimme a bit, i need to switch computers to one which will have a different mxr and probably a different bzr
[11:13] <LarstiQ> timely: a checkout is possible, but then you have to commit --local, or unbind
[11:13] <timely> -bash: bzr: command not found
[11:13] <timely> this is going to be so much fun
[11:13] <LarstiQ> luckily, bzr works very well from source, no need to install
[11:14] <timely> someone said the same thing about hg
[11:14] <timely> they were wrong
[11:14] <timely> python doesn't work very well from anywhere :)
[11:14] <LarstiQ> hg needs to compile things
[11:14] <timely> nah
[11:14] <timely> the problem w/ hg was python include paths
[11:14] <timely> nothing to do w/ building
[11:14] <timely> everything to do w/ the fact that once it was built, it wouldn't run
[11:14] <timely> c.f. loggerhead
[11:15] <LarstiQ> Ok, no clue about that, I only know their diff algorithm is written in C.
[11:15]  * timely shrugs
[11:15] <timely> it's pluggable, but let's stick to bzr
[11:15] <LarstiQ> timely: right
[11:15] <timely> you can eat the runtime bridge when i come to it :)
[11:16] <timely> https://launchpad.net/bzr/1.5/1.5/+download/bzr-1.5.tar.gz ?
[11:16] <LarstiQ> timely: download source, unpack, possibly symlink or alias 'bzr' to unpacked-source/bzr, and go
[11:16] <LarstiQ> timely: that should work I guess
[11:16] <timely> 03:16:24 ERROR 303: See Other.
[11:16] <timely> yeah right
[11:16] <LarstiQ> timely: just to be sure, what python version do you have there?
[11:16] <timely> Python 2.3.5 (#2, Oct 16 2006, 19:19:48)
[11:17] <timely> :)
[11:17] <LarstiQ> ugh
[11:17] <LarstiQ> I'm afraid that won't really do.
[11:17] <timely> i have python2.2 if you prefer ;-)
[11:17] <LarstiQ> No, I prefer 3.0 ;P
[11:17] <LarstiQ> Nah, 2.4 or 2.5
[11:17] <timely> python2.4 maybe?
[11:17] <timely> that i have
[11:17] <timely> it isn't the default...
[11:17] <timely> Python 2.4.4 (#2, Apr 29 2008, 08:45:14)
[11:18] <timely> python3.0 is useful in that it isn't compatible w/ 2.x
[11:18] <LarstiQ> is it in your PATH?
[11:18] <LarstiQ> timely: right, I was joking
[11:18] <timely> except of course, 2.5/2.4/2.3 aren't really compatible w/ eachother either
[11:18] <LarstiQ> timely: it not being compatible is the exact reason of existance
[11:18] <timely> each time someone tries to change the default, a half dozen apps break here
[11:18]  * LarstiQ shrugs
[11:18] <timely> yeah yeah
[11:19] <timely> [sanjay]$ which python2.4 => /usr/bin/python2.4
[11:19] <LarstiQ> I'm assuming /usr/bin is in your PATH :)
[11:19]  * timely loves how python gave a timestamp but didn't mention a timezone
[11:19] <timely> heh... for now anyway
[11:19] <timely> until perl taint makes me take it away ;-)
[11:20] <timely> so anyway... i got 303 which broke wget
[11:20] <timely> which is um... cute
[11:21] <LarstiQ> timely: my wget follows 303
[11:21] <timely> oh
[11:21]  * timely wonders if this is a shell problem
[11:21] <LarstiQ> timely: https://launchpadlibrarian.net/14566578/bzr-1.5.tar.gz
[11:21] <LarstiQ> try that
[11:22] <timely> that works better
[11:23] <LarstiQ> timely: got it unpacked?
[11:23] <timely> ok, i am here: http://timeless.justdave.net/mxr-test/bzr/source/
[11:25] <timely> ok, so... arg
[11:25]  * timely sighs
[11:25]  * timely tries to remember the syntax
[11:26] <LarstiQ> doh
[11:26] <LarstiQ> Location isn't specific to pull.
[11:27] <LarstiQ> timely: http://timeless.justdave.net/mxr-test/bzr/source/bzrlib/option.py +538
[11:27] <LarstiQ> timely: and http://timeless.justdave.net/mxr-test/bzr/source/bzrlib/builtins.py for the actual commands
[11:28] <timely> fwiw, the search engine should work now :)
[11:28] <LarstiQ> timely: you'll notice the 'remember' option being used in several commands
[11:29] <timely> "the default for this command" ?
[11:29] <LarstiQ> hmm, the default location for this command maybe
[11:30] <LarstiQ> timely: nice to see LXR isn't actually as dead as a parrot as I thought.
[11:30] <LarstiQ> timely: oh, it seems you could do a pull specific help if you really wanted to.
[11:31] <LarstiQ> timely: ala http://timeless.justdave.net/mxr-test/bzr/source/bzrlib/builtins.py#4268
[11:31] <LarstiQ> timely: to see that in action, look at 'bzr help send' or 'bzr help bundle' output
[11:32] <timely> so um... real life calls
[11:32] <timely> (quite literally actually)
[11:32] <LarstiQ> yeah, here as well
[11:33] <timely> well, i claim the global option was buggy
[11:33] <timely> since 'a default' is never right :)
[11:33] <timely> but we can do two changes
[11:33] <timely> one "the default for this command" for global and something more specific for pull
[11:33] <LarstiQ> right
[11:33] <LarstiQ> your call :)
[11:33] <timely> anyway, glad you aren't having trouble using mxr :)
[11:34]  * LarstiQ used to use lxr
[11:34] <timely> the name change was just to slightly reduce the confusion about how different we are from the other 2 forks
[11:34] <timely> which are fairly dead and so far forked from us that well...
[11:34] <timely> anyway, quickly. how do i build? :)
[11:34] <LarstiQ> build what?
[11:35] <LarstiQ> bzr?  A, B or C. OR A, B, or C. but NOT X, or Y.
[11:40] <timely> btw, i had to fix mxr just to give you that link...
[11:40] <LarstiQ> I see it as a bijzin and not a list.
[11:40] <timely> bijzin?!
[11:40] <LarstiQ> But hey, you're the English native speaker ;)
[11:40] <LarstiQ> timely: no clue what that is called in English.
[11:41] <LarstiQ> timely: read that as: I don't really care, but if you're willing to spend effort on things like that, I'm not stopping you.
[11:41] <timely> ok :)
[11:41] <timely> anyway, that's why i grab sources
[11:41] <timely> if i'm going to make changes, i'll probably make lots
[11:41] <LarstiQ> it costs more energy to argue for an alternative in my eyes correct reading than just accepting your patches :)
[11:42] <timely> although whether i manage to upstream them is another story
[11:42] <timely> i think you can find my tt forks on that mxr somewhere
[11:42]  * timely hits the wiki warning that cloning bzr takes time
[11:44] <LarstiQ> timely: can you manage from here? If so I'll get back to real life again.
[11:44] <timely> yeah
[11:44] <LarstiQ> k, see you later perhaps
[11:45] <timely> only other question is how changes should be sent
[11:45] <timely> some sort of thing showing 1000 commits, one commit per file
[11:45] <timely> or one commit per style change for the repo
[11:45] <timely> or one commit for the whole repo
[11:46] <LarstiQ> one branch per topic
[11:46] <LarstiQ> bzr send will roll all the commits up
[11:46] <timely> do branches mean distinct parents of .bzr's?
[11:47] <timely> or can i sorta commit into the same repo swapping branches as i go
[11:47] <LarstiQ> timely: I think you're conflating repo and branch
[11:47] <timely> dh is picky about non web served content that it thinks is "Backup"
[11:47] <timely> to me, "repo" is something that contains something like .hg/ or .git/
[11:48] <timely> my goal is to make sure i don't have to have 5 copies of the thing that holds a "clone" of upstream (because i hit space quotas)
[11:48] <timely> and also to make sure i don't have to republish (to avoid hitting "not web content" dreamhost hosting rules)
[11:48] <LarstiQ> every branch (.bzr/branch) that lives in a directory tree under a dir that has a .bzr/repository, will use _that_ .bzr/repository to store its revisions
[11:49] <LarstiQ> timely: you'll find `bzr init-repo` helpful then
[11:49] <LarstiQ> timely: but if you're doing documentation style changes, I'd fit all of that in one branch
[11:49] <timely> ok
[11:50] <timely> that simplifies matters :)
[11:50] <LarstiQ> that is what I meant per topic, the topic being 'documentation style' in this case, or bug-12345 in another, or nested-trees feature, etc
[11:52] <LarstiQ> timely: but why does dreamhost factor in?
[11:52] <timely> well, each host i have has rules
[11:52] <timely> my personal box runs 10.3.9
[11:53] <timely> the usual rule is "nothing i want to do works there"
[11:53] <timely> landfill.bugzilla.org's rule is "must be mozilla related" (bzr isn't)
[11:53] <timely> dreamhost (timeless.justdave.net)
[11:53] <timely> 's rule is "must be web content"
[11:53] <timely> i have other boxes, most of them have rules "no free space available"
[11:53] <LarstiQ> hmm.
[11:53]  * LarstiQ just works on his laptop.
[11:54] <timely> my laptop's rule is "for work purposes"
[11:54] <timely> bzr doesn't fit there either ;-)
[11:54] <timely> it also falls into "no free space available"
[11:54] <LarstiQ> well, if that makes you happy.
[11:54] <timely> (and probably doesn't have python)
[11:54] <timely> oh, dunno about happy. but it is life :)
[11:54] <timely> happy is going to the beach, which is what i'll do now :)
[11:54] <LarstiQ> timely: ok, ciao
[11:55] <timely> oh, how do i set my committer name?
[11:56] <LarstiQ> bzr whoami 'Wouter van Heyst<EMAIL_ADDRESS>[11:56] <timely>     ~/.bazaar/bazaar.conf [DEFAULT] email=... ?
[11:56] <LarstiQ> or that
[11:57] <timely> timeless.justdave.net FTP <timeless@sanjay>
[11:57] <timely> is not what i want to be :)
[11:57] <LarstiQ> timely: you can set your committer id per branch, ~/.bazaar/bazaar.conf will have the default
[11:58] <LarstiQ> So, run 'bzr whoami <foo>' from outside a branch, and it will set the default
[11:58] <timely> oh well
[11:58]  * timely manually created the file
[11:58] <LarstiQ> and it turns out also from inside, ah well
[11:59] <LarstiQ> --branch to set it locally instead of globally
[11:59] <LarstiQ> aaaanyway
[11:59] <LarstiQ> timely: you can check what it is with `bzr whoami`
[12:00] <timely> ok. first commit done
[12:00] <timely> beach!
[12:00] <LarstiQ> mind fuck festival!
[12:01] <LarstiQ> http://mindfuckmondays.com/ for other people in the area of Den Haag
[12:01]  * LarstiQ is gone
[13:42] <Pieter> Hey all. I did some repository size benchmarks on repos with full history (http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html) instead of just a tarball import as done on the benchmark page.
[13:42] <Pieter> I think this is a lot more realistic benchmark than done at http://bazaar-vcs.org/Benchmarks/SpaceEfficiency. Perhaps you should update the website?
[13:46] <bob2> might want to post that to the list
[13:46] <gour> interesting results...
[13:47] <gour> there is some room for improvement in bzr, it seems
[13:48] <bob2> did increasing the window size help git much?
[13:52] <Pieter> I did some benches on that.. when you go from 10 to 50 you can get a 2x improvements
[13:52] <Pieter> 50 to 100 perhaps another 2x
[13:52] <Pieter> but after that not much improvement
[13:53] <gour> Pieter: which repo format you use for bzr?
[13:55] <Pieter>     repository: Packs containing knits without subtree support
[15:05] <pygi> poolie, around perhaps in any change? :)
[15:06] <pygi> chance*
[16:20] <adaran> hey everyone
[16:21] <adaran> is there any document that someone can point me to that explains the "philosophy" (not ideology) behind bazaar?
[16:21] <adaran> all i can find at the moment are howtos, tutorials and other stuff =/
[18:14] <rockstar> Does this error make any sense to anyone?  http://pastebin.com/m483b7ade
[18:19] <cody-somerville> rockstar, try breaking the lock manually?
[18:25] <jumpkick> what do people usually use for the <name> portion of their branch name?  trunk? main?
[18:28] <Pilky> jumpkick: you mean the main development branch? we use dev for our open source project, for my personal projects I haven't settled on one yet
[19:34] <rockstar> cody-somerville, break lock doesn't fix it.  Tried that already
[19:37] <beuno> rockstar, it's a bug between bzr versions (you're probably using 1.5, and LP has 1.3)
[19:37] <beuno> rockstar, https://bugs.edge.launchpad.net/bzr/+bug/236380
[19:40] <rockstar> beuno, wierd.  So why can I branch from some projects, and no others?
[19:41] <beuno> rockstar, I'm not sure yet, it has something to do with the way the smart server handles it
[19:41] <beuno> you can, as a workaround, branch using http, and then push with bzr+ssh
[19:43] <rockstar> beuno, ah, alright, that makes sense.
[19:57] <xif> Hi!
[19:57] <xif> I have a few questions about Bazaar.
[19:57] <xif> First of all, what's the best way to get the current revision of a repository?
[19:58] <Pilky> the revision number?
[19:58] <Pilky> bzr revno
[19:58] <xif> yeah
[19:58] <Pilky> though you can only get the revision of a branch, not a repository
[19:59] <xif> Pilky: yeah, `bzr revno` seems to be the thing
[19:59] <xif> (that's what I want, really :)
[19:59] <xif> btw, is there a nice way of doing this from Python?
[19:59] <xif> (just curious)
[19:59] <Pilky> that I wouldn't know
[20:00] <luks_> b.last_revision()[0]
[20:00] <luks_> or [1], not sure
[20:00] <luks_> (where b is a Branch instance)
[20:00]  * xif nods
[20:01] <luks_> er, or maybe b.last_revision_info()
[20:01] <xif> thanks. another question: there were significant changes in the format of the actual files storing the bzr data over the last several version, right?
[20:01] <luks_> but it's definitely one of those :)
[20:01] <beuno> xif, http://bazaar-vcs.org/Integrating_with_Bazaar  may be fun to loot at
[20:01] <beuno> xif, there hasn't been any changes since 0.92
[20:01] <beuno> so it's been very stable for some time now
[20:02] <xif> yeah, unfortunately, the latest for Gutsy is still 0.90
[20:02] <beuno> xif, PPA's are your friend
[20:02] <beuno> https://launchpad.net/~bzr/+archive
[20:02] <xif> so there might be some chance of some members of the team needing to interact with 0.90 branches
[20:03] <xif> what would happen if someone tries to negotiate a 0.90-created branch with 1.5?
[20:03] <beuno> well, they wouldn't be able to, I guess
[20:03] <xif> OK, is there a chance of a silent failure?
[20:03] <xif> i.e. corrupting a branch?
[20:03] <beuno> but, the improvements since 0.90 justify the upgrade
[20:03] <luks_> what? current bzr supports all older formats
[20:03] <beuno> no, it should be explicit about the bzr not understanding the format
[20:04] <LarstiQ> beuno: ehm, 1.5 reading 0.90 should be fine?
[20:04] <beuno> luks_, but not the other way around
[20:04] <LarstiQ> right, right
[20:04] <beuno> ah, right
[20:04] <beuno> sorry
[20:04] <beuno> xif, listen to the more-awake people  ^
[20:04] <xif> hehe
[20:04]  * Pilky hands beuno some coffee
[20:04] <xif> OK, so if 1.5 pulls data from 0.90, it would in fact convert it to the new format?
[20:04] <luks_> no, it would use the old format
[20:07] <LarstiQ> xif: it can pull from an old branch into a new one, or if you freshly branch, it should use the old format iirc
[20:07] <beuno> yeah, I still use a few branches on LP that haven't been upgraded, and it's transparent
[20:10] <xif> LarstiQ, luks: OK, but it seems even in that case, there shouldn't be any problems.
[20:11] <xif> of course, it would be best if everyone made sure to use 1.5
[20:11] <xif> but corruptions or fatal errors trying to pull/push data shouldn't occur, according to you.
[20:11] <luks> definitely not
[20:11] <xif> thanks a lot :)
[20:11] <luks> either it will tell you it doesn't support that format, or it will work well
[20:12] <xif> what were the changes 0.90 => 0.92 btw?
[20:12] <gour> @localtime gour
[20:20] <gour> igc: hi, i just updated 'darcs-support' bug with some new & interesting info
[20:23] <timelyx> hello world
[20:24] <timelyx> in bzr rel notes there's a reference to "Tortise" i'm assuming it means Tortoise am i wrong?
[20:32] <fperez> Howdy, I have a question regarding how to do what the abandoned 'bzr graft' plugin did... Anyone who might be able to help?
[20:32] <fperez> URL for graft: http://spacepants.org/src/bzrgraft
[20:36] <timelyx> indeed, it's a typo :)
[20:40] <Pieter> fperez: have you tried the bzr-rebase plugin?
[20:40] <fperez> Pieter: yup, unsuccessfully so far...
[20:41] <fperez> The problem is that the two branches are chronologically contiguous, but one was started 'from scratch' with no history.
[20:41] <fperez> Rebase won't let me do it because it detects no common parents.
[20:41] <fperez> I'll give a bit more detail now: I'm the lead of the ipython project, and we recently switched from svn to bzr.
[20:42] <fperez> When testing the switch, our SVN server was having memory problems and launchpad could never complete a full download of the svn history to start working from.
[20:42] <fperez> So one of the ipython devs just made an initial bzr import with zero svn history and uploaded that  to launchpad, so we could see if we liked the workflow.
[20:43] <fperez> Now we're happy and we want to fully abandon the svn support, but we'd like to bring the old history in (years) and merge it with the recent work done in bzr (3 months).
[20:43] <fperez> So bzr-graft sounds exactly made for this, but unfortunately it doesn't load in current bzr.
[20:44] <fperez> I don't have the time to basically rewrite graft, so I was wondering if an alternative solution exists.  If I'm mis-using rebase (I'm no expert) I'll be happy to try again.  I can give details of the problems I'm seeing.
[20:46] <LarstiQ> fperez: oef
[20:46] <LarstiQ> fperez: I'd write to the list about this.
[20:47] <fperez> OK, that was my next move to try just now.  I was just wondering if I was missing something obvious that a guru could quickly spot. Thanks.
[20:50] <LarstiQ> it's not something that I'd immediately know how to approach
[20:51] <fperez> No problem, I appreciate the feedback.  bzr-graft is intended to do *precisely* this, so it's a shame it has bitrotted.  But I just don't have the time to resurrect it for a one-off effort.  It would be great if that plugin was maintained in the core: the code looked actually pretty small, so I'm sure for someone who knows the bzr API it would be easy work.
[21:02]  * timelyx frowns
[21:02] <timelyx> is there a difference between ``a``, 'a', and "a" in the README files of bzr?
[21:04] <Peng> The files are ReST, or however it's capitalized. I think ``a`` means <code/>, and the others are meaningless.
[21:06] <timelyx> thanks
[21:06] <timelyx> did bzr pick en-gb for all content? and is en-us content considered buggy?
[21:06]  * timelyx frowns
[21:06] <timelyx> robert collins /looked/ like an en-gb er
[21:06] <timelyx>      generalises the ``exclude_suite_by_re`` function. (Robert Collins)
[21:06] <timelyx>      randomized copy of the input suite. (Robert Collins)
[21:07]  * timelyx will need to get an en-gb dict
[21:10] <Peng> Canonical is in the U.K., and I think many of the developers are Australian.
[21:19] <timelyx> ok
[21:23] <schierbeck> hi guys
[22:19] <timelyx> does bzr have a concept of a 'teste'?
[22:31] <pickscrape> I'm just trying to get the diffstat plugin working. It's using diff_cmd_helper, which was removed in r3410 (apparently deprecated before 1.1)
[22:31] <pickscrape> Anyone know what I might use in place of it?
[22:39] <LarstiQ> pickscrape: DiffTree? Have a look at the call chain for cmd_diff from bzrlib/builtins.py
[22:41] <pickscrape> LarstiQ: thanks. (my first foray into bzrlib, this)
[22:49] <LarstiQ> pickscrape: you're welcome
[22:50] <LarstiQ> pickscrape: alternatively, use gannotate to find out what replaced diff_cmd_helper around the same time it got removed
[22:50] <LarstiQ> or at deprecation time probably
[22:55] <pickscrape> Hmm, would I be right in thinking that if a function name starts with an underscore it's considered 'private' and shouldn't be called from within plugins?
[22:57] <pickscrape> It was deprecated in 3072.1.1, and all functions added in that revision are underscored. I'm going to look at the code that was calling it for clues...
[23:00] <LarstiQ> pickscrape: yes, you are right
[23:11] <pickscrape> Aha! I've got it working! (I think)
[23:12] <pickscrape> Any idea if this is sensible? show_diff_trees(bzrdir.open_branch().basis_tree(), bzrdir.open_workingtree(), out, file_list)
[23:12] <pickscrape> It's the bzrdir.open_branch().basis_tree() part that I dug up myself, and may be completely incorrect
[23:54] <poolie> hello
[23:54] <beuno> morning poolie