/srv/irclogs.ubuntu.com/2011/02/11/#bzr.txt

mkanatjam: pqm was a customized branch for launchpad specifically.00:12
mkanatjam: It had changes that were only relevant to Launchpad.00:12
mkanatjam: I have a feeling mwhudson didn't actually look over your merge code.00:14
mkanatSince it was immediately obvious to me that some of those things should not have been merged back into the main loggerhead.00:15
mkanatjam: It's also slightly mysterious why certain things were there that weren't on experimental, like HACKING.00:15
mkanatjam: It's possible that when doing the merge you restored files that were removed on experimental, since pqm was based on the stable branch, not on trunk.00:16
=== Ursinha is now known as Ursinha-afk
lifelessmkanat: this is part of sorting out th emess00:30
mkanatlifeless: Sure.00:30
mkanatlifeless: I'm sure that jam and mwhudson will be able to figure it all out.00:30
mkanatI actually noticed the problem immediately when it was posted, but I'm not on contract anymore and I figured that somebody would notice it too.00:33
mkanatOnce this particular merge is handled it should be fine from here on out.00:33
mkanatjam: BTW, I noticed that you've been keeping up the tests now, which is so awesome. :-)00:34
mkanatjam: That was exactly what I was going to do next if I'd had a few more hours. :-)00:35
pooliehi mkanat, lifeless, jam00:39
mkanatHey poolie.00:39
mkanatI've left ~loggerhead-team for now--if anybody has specific questions that they want my feedback on, feel free to subscribe me directly or request review from me directly.00:52
palhmbsI'm stuck!01:00
* palhmbs puts his hand up... how do I get my bzr branch uploaded to launchpad.... bzr push lp:~john.doe/+junk/myproject -- just says bzr: ERROR: Invalid url supplied to transport !!01:01
mkanatpalhmbs: You need a project first.01:01
mkanatpalhmbs: Then it would be like lp:~john.doe/myproject/trunk01:02
palhmbsI have created a PPA -- do I -- bzr push lp:~palhmbs/~palhmbs/+archive/ppa-for-gtg ??01:02
maxbNo, +junk should work01:02
maxbpalhmbs: branches and PPAs do not directly relate01:02
palhmbsah - I see...01:03
palhmbsso I have to set a location for my branch... under .bzr ?01:03
maxb'bzr push lp:~palhmbs/+junk/anythin' should just work, assuming you have registered a SSH key with launchpad01:04
* palhmbs has tried using groundcontrol... which got me logged in, but no further01:04
spivpalhmbs: does "bzr plugins" list the "launchpad" plugin?01:04
palhmbsspiv, yep - launchpad 2.2.101:04
maxbpalhmbs: Could you try 'bzr push bzr+ssh://bazaar.launchpad.net/~palhmbs/+junk/something' ?01:05
spivpalhmbs: is that the full text of the error?01:06
palhmbsI've even wrote a ~/.ssh/config -- to help identify01:07
spivpalhmbs: that error suggests to me that you have some sort of typo in your URL, e.g. if I typo my username in the URL I get 'bzr: ERROR: Invalid url supplied to transport: "lp:~spivv/+junk/hmm": No such person or team: spivv'01:07
palhmbsspiv, no -- fulltext is:  bzr: ERROR: Invalid url supplied to transport: "lp:~palhmbs/ppa-for-gtg/trunk": No such project: ppa-for-gtg01:08
palhmbsI did try -- bzr push sftp://palhmbs@bazaar.launchpad.net/~palhmbs/ppa-for-gtg -- but got -- bzr: ERROR: Permission denied: "/~palhmbs/ppa-for-gtg": [Errno 13] mkdir failed01:08
spivpalhmbs: ah, that's your problem: "No such project: ppa-for-gtg"01:08
palhmbsso um, where does it go when you push to +junk ??01:09
spivpalhmbs: when you push to +junk it goes to +junk01:09
palhmbsbecause bzr push bzr+ssh: -- is working... :-001:09
spivpalhmbs: you'd also be able to use "lp:~palhmbs/+junk/something" I'm sure01:10
spivpalhmbs: "+junk" is basically a special name for "no associated project"01:10
palhmbsthanks - right np01:10
spivpalhmbs: otherwise that part of the URL has to be the name of an actual project on Launchpad01:10
palhmbsand I have to package specially for a PPA...01:12
palhmbsI see... I think -> b <- thumbs up01:12
palhmbsah well - my code can live in junk for awhile.01:15
mwhudsonyes, i have to admit i went by the description more than the diff for jam's branch01:20
jbowtieI think there's a revision in my repository that *should* be the head revision for the current branch, but isn't.  Can anyone remind me how to locate it?01:45
mwhudsonjbowtie: bzr heads --dead01:48
mwhudsonwhich is in bzrtools01:48
jbowtiemwhudson: thanks, I don't have bzrtools installed on this server, is why I couldn't find it.01:51
mwhudsonnp01:51
jbowtieOK, I do have a dead head, can I reattach it?01:56
mwhudsonif you already have a branch that should have that as a head, i think bzr pull -r $dead_head in the branch should be all it takes01:57
jbowtiemwhudson: Hmm, didn't work. Looks like I will have to investigate further.02:02
mwhudsonjbowtie: what failed?02:03
mwhudsonmaybe you need --overwrite or something, or maybe you should do 'bzr init new-branch; cd new-branch; bzr pull -r revid:$dead_head'02:03
mwhudsonah, i forgot the "revid:" bit before02:04
jbowtiemwhudson: Trying with overwrite; I knew enough to put in "revid:"02:07
jbowtiemwhudson: It's trying to pull from the parent branch in a foreign vcs instead of pulling the existing rev from the repository.02:09
mwhudsonoh02:09
mwhudson!02:09
mwhudsonjbowtie: pull -r revid:$deadhead .02:10
mwhudsonthat . is important :)02:10
jbowtieBrilliant, that did it.02:10
mwhudsongood!02:11
jbowtieInteresting, there are two other dead heads that are missing from the branch history. I might need to write a splice command to insert them where they belong.02:15
thumperhmm...02:25
thumperI want to add an existing branch as a pipe in a pipeline02:25
thumpernot so easy it seems02:25
mwhudsonthumper: probably easiest to move the branch out of the way, add the pipe, and then move the branch back?02:35
thumpermwhudson: I just did add-pipe oldbranch-copy, then pulled the other branch into it02:35
thumperI really should file a bug on pipelines02:36
mwhudsonah righ02:36
mwhudsont02:36
mwhudsonyeah02:36
thumperbug 71682602:42
ubot5Launchpad bug 716826 in bzr-pipeline "Should be able to add an existing branch to a pipeline" [Undecided,New] https://launchpad.net/bugs/71682602:42
maxbIs there a document I can read which outlines bzr's architecture concerning unicode and bytestrings?02:45
maxbe.g. is revision.message supposed to be a utf8 bytestring or a unicode object. Likewise file-ids. etc.02:46
* maxb is trying to rescue bzr-xmloutput02:46
pooliemaxb i think this is discussed in HACKING02:48
pooliegenerally, ids are utf8 byte strings02:48
poolie(because they are normally opaque)02:48
pooliemessages, filenames, etc should match the general python advice of converting from bytes to unicode on entry/exit of the program02:49
maxbah.... I grepped doc/developer/ and found not much :-)02:51
lifelessjam: I think I may have fixed the spam on proposals to lp:loggerhead02:55
lifelessjam: please let me know if you get another02:55
=== oubiwann_ is now known as oubiwann
jamlifeless: I got one about 3 hours ago, but that predates your message from 30min ago03:27
lifelessyeah, I changed it 30 minutes ago03:28
lifelessit may be incomplete03:28
lifelessat which point I'll be asking thumper03:28
lifelessand then following htat reading code t figure out wtf the rules are03:28
* thumper looks up here03:28
jamlifeless: just got a rejected message as of 1min ago03:48
lifelessbah03:48
lifelesswhat list ?03:48
jamlaunchpad-bugs-owner@lists.canonical.com03:49
jamlooks like it was trying to send to "launchpad-bugs@lists.ubuntu.com"03:50
jamX-Launchpad-Message-Rationale: Subscriber @loggerhead-team03:50
lifeless~launchpad03:50
lifelesssigh03:50
lifelesswhat branch03:50
jamlifeless: that was trunk-into-experimental, so the target should be ~loggerhead-team/launchpad/experimental03:52
jamI don't know about others yet03:52
jamthough I'll be proposing something tonight03:52
lifelessthey need to be configured individually03:52
lifelessright, changed the subscription for loggerhead team to 'no email'03:53
lifelessmmm03:53
lifelessactually, I'll try a direct sub + no email on that03:53
lifelessthis is a fraking annoying list config03:53
lifelessfingers crossed03:54
lifelessmwhudson: hi03:57
lifelessmwhudson: what stops us using loggerhead as an egg?03:57
mwhudsonlifeless: probably nothing03:57
lifelessdoes lp import it as a bzr plugin, or as a top level item?03:57
mwhudsontop level currently03:57
lifelesscool03:58
lifelessok, we might want to do that soon03:58
mwhudsonotherwise my answer would have been different :-)03:58
mwhudsonyeah, should be easy03:58
maxbjam: ooi, why would PQM be good for lp:loggerhead (compared with pretty much all the other bzr plugins in Launchpad not using it) ?04:02
pooliemaxb, what do you mean?04:02
jammaxb: because *I* want it?04:02
jampoolie: none of the bzr plugins use a bot to manage trunk04:03
poolieif you want to set one up i'd rather we try this on tarmac04:03
maxbIndeed. I am just curious as to the motivation for doing loggerhead differently04:03
jampoolie: well, I don't want to maintain it..04:03
jamor have it running on my personal hardware, etc.04:03
jamI certainly don't want to have to be online for people to land things04:04
poolieand you feel you'd have to maintain it if it was tarmac but not pqm?04:04
poolieno, i don't think you should either04:04
poolieand i think enforcement of the test suite would be good04:04
jampoolie: does canonical have Tarmac running in the DC somewhere?04:04
poolieyes, i believe other teams are using it04:04
poolieu1 iirc04:04
jamsince I've poked on the project, it was always run on personal hardware04:04
jambut that was a while ago04:04
jamlifeless: so far, I can't tell the colorscheme difference between old-trunk and pqm, I'm still trying to figure out the screeshots you would want04:05
jamlooks pretty identical to me04:05
jamstupid, that's because I reverted it to experimental's tip, where I had already merged the trunk updates....04:06
jamstupid stupid04:06
jamlifeless: pqm's loggerhead uses orange, Experimental uses blue04:07
jamfor the menus at least04:07
lifelessso, I'd like someone - curtis perhaps, or huwshimi, to be briefed on the situation, and make a recommendation.04:10
=== Meths_ is now known as Meths
=== Meths_ is now known as Meths
lifelessjam: does the raw controller output the byte content directly, or does it htmlise it just without annotation ?06:01
jamlifeless: raw content06:02
jamno html06:02
jamsame as /download but not Content-disposition: Attachment06:02
lifelessin which case thats an experimental only thing, right ?06:02
lifelessits not in trunk yet06:02
jamlifeless: I believe so06:02
lifelesscool06:03
lifelessI won't leap on it in a panic then :)06:03
jamlifeless: thats the xss concern?06:03
lifelessyes06:04
lifelessI know there is a similar answer to lps, but we need to write the glue - which includes adding a API for allocating the time limited tokens and gluing that into the Application06:05
vilahi all !07:32
mr-russHi,07:37
mr-russmore questions today.07:37
mr-russWhen converting from SVN, can I get tags converted bzr tags rather than branches?07:38
lifeless   exarkun@divmod.com-20110209125926-8d98psdzhqru0vrs07:39
pooliemr-russ, i think bzr svn-import can/will do that?07:54
mr-russK, I used svn2bzr.py and it's not created a shared repo or tags that do what I want.07:55
mr-russwill look further at svn-import.07:55
mr-russWhat is the implication of non-determinsic revisions?07:55
mr-russI got a little worried when reading that in the docs as I don't know the implications of it.07:55
mr-russsvn$ bzr svn-import civian08:00
mr-russUsing repository layout: trunk008:00
mr-russbzr: ERROR: exceptions.TypeError: fetch() got an unexpected keyword argument 'needed'08:00
mr-russ??08:00
pooliethat looks a lot like an out-of-date plugin08:01
poolieplease file a bug with the traceback from .bzr.log and paste the number here08:01
mr-russjust installed against lucid.08:01
poolieor just update bzr-svn08:01
mr-russwill file bug now.  is there a fast way from command line to do it?08:01
mr-russit fails because I wasn't importing into a repository.08:02
mr-russwhich it didn't complain about.08:02
poolieah, well, that's a bug worth filing08:24
pooliebut lucid's a bit old, and it might be fixed by now08:24
pooliethere's a ppa with newer builds of bzr and plugins08:24
Lo-lan-doHi all :-)09:29
Lo-lan-doIt seems that bzr diff --using "wdiff -n" ceased working recently…  Is that known?09:29
Lo-lan-doIt apparently tries to run a command called "wdiff -n", rather than running wdiff with a -n option.09:30
Lo-lan-dostrace shows: execve("/home/roland/bin/wdiff -n", ["wdiff -n", "/tmp/bzr-diff-Gf9RoE/old/Makefil"...,09:31
jelmerLo-lan-do: not sure - can you file a bug?09:31
Lo-lan-doSure09:32
mr-russI migrated from svn, my tags are now showing in bzr tags;  as TagName  ?09:57
mr-russI thought, there are not version numbers, so the tag is useless.  I'll delete those tags.09:58
mr-russwhen I delete a tag and try and commit, it tells me nothing has changed.  How do I commit and push/pull tag changes?09:58
mr-russbzr 2.1.x lucid installation09:58
jelmermr-russ: you can use them, but since they have no relation to the curretn revisin tip we can't print a revision number09:58
jelmermr-russ: tags are independent of commits in bzr09:58
mr-russreally.09:58
jelmerafter a tag has been deleted there's no need to do a commit09:59
mr-russhow to I keep tags in sync between people.09:59
mr-russget push the tag delete.09:59
mr-russHow do I push the tag addition or deletion,  as push says, no revisions to push.09:59
mr-russhttps://lists.ubuntu.com/archives/ubuntu-mobile/2008-March/001625.html10:01
jelmerpush will actually push new tags even if there were no revisions pushed10:01
mr-russhopefully that comment is true.10:01
mr-russNot exactly noob friendly though.10:02
jelmeryes, the push ui should be clearer if it actually updated any tags10:02
mr-russanother question about my ? tags.  How do I use them.  If I bzr update -r tag:Release_1_1  I get;10:03
mr-russbzr: ERROR: branch has no revision svn-v4:deb830e7-bb10-0410-bcbb-ea420f43d34b:tags/Release_1_1:1610:03
mr-russbzr update --revision only works for a revision in the branch history10:03
mr-russjelmer: You said I could use them, however I'm not sure how to.10:04
jelmere.g. 'bzr branch yourbranch -rtag:Release_1_1 newbranch'10:06
jelmerdepending on how the branch was cloned it might not have copied all the tag contents though10:06
jelmersvn-import should have copied all the tag contents10:06
mr-russyeah, but I put that on a remote shared repository.  I think branched trunk.10:07
mr-russ$ bzr branch . -r tag:Release_1_1 ../civian-1.110:08
mr-russbzr: ERROR: The branch . has no revision <RevisionSpec_tag tag:Release_1_1>.10:08
mr-russso trunk doesn't have the tag revision information?10:08
mr-russI think I was better off when not attempting to import from svn.10:08
jelmermr-russ: svn-import will import all the tags, and there's an open bug about 'bzr branch' importing all the tags even if they're not pointing at revisions in the branch itself10:10
mr-russokay.  I might just delete them as they are confusing and move along.10:11
jelmerif you're doing a conversion, I'd recommend svn-import10:11
jelmerif you're just trying to contribute to an existing svn branch, bzr branch10:11
mr-russI ran svn-import to convert a repository.  Put that repository using scp on another server.  then did bzr branch remote_location;  bzr tags10:12
mr-russand have the ?'s10:12
mr-russinteresting.  delete tags, bzr push.  tags gone.  bzr pull, tags back.10:13
bialixheya10:14
* bialix looking for vila10:14
bialixbonjour vila10:15
vilahey bialix !10:15
bialixI have question about our internal config machinery10:15
vila.me all ears10:16
vilabialix: I'm still holding my breath, don't be too long ;)10:20
* fullermd waves vila around by the ears.10:20
vilaouch10:20
vilaI'm not *that* small anymore you know !10:20
fullermdWell, it's probably more comfortable than bialix jamming our internal config machinery into them...10:20
bialixsorry10:21
bialixphone call10:21
vilahaa, ok, np10:21
* vila breathes again10:21
* vila goes to polishing config rough edges a bit more to ease with ears10:22
bialixBug 71638410:22
ubot5Launchpad bug 716384 in QBzr "size of qdiff windows invoked from qcommit (pending merge) is default" [Undecided,Invalid] https://launchpad.net/bugs/71638410:22
bialixvila: in qbzr.conf I have such line10:22
bialixdiff_window_maximized = True10:22
bialixin qbzr/lib/utils.py we trying to read it10:22
bialixis_maximized = config.get_option(name + "_window_maximized")10:23
bialixthe bug is:10:23
bialixfirst time the option read as u'True' (unicode sting)10:23
bialixsecond time the option read as bool True10:23
bialixwhy?10:23
vilaO_o10:24
fullermdThe machines...  they're taking over!10:25
vilaerr, short answer will be use get_user_options_as_bool10:25
bialixvila: you mean always use another method?10:25
vilabialix: I mean stop relying on configobj, use bzrlib.config ;)10:26
bialixbzrlib.config does not have the method to delete options10:27
bialixor it has now?10:27
vilabialix: more half-seriously, configobj can be weird, I can't answer precisely, that may be a configobj bug, but you could probably avoid it using bzrlib.config10:27
vilait has now10:27
vilawell, not all cases are covered but the ones you use should be (not all sections can be reached now I think)10:28
bialixI need Gary to talk about10:28
vilaerr, looking at the code, even sections are supported10:28
vilaso the missing bit is probably only in 'bzr config' actually10:29
vilai..e: you don't have to care10:29
vila'bzr config' doesn't support qbzr.conf either anyway10:29
vilaby the way, if you move to bzrlib.config only, the long term plan is that qbzr options should be supported by bazaar.conf, locations.conf, branch.conf, zoo.conf by prefixing them by 'qbzr.',  i.e. qbzr.log_window.size and the like10:31
vilaor even qbzr.log.window.size or whatever10:32
vilanot sure it makes sense to have branch specific window locations though10:32
bialixщл10:33
bialixok10:33
vilabut at least you'll get the opportunity to decide and won't need to handle an additional config file anymore10:33
bialixthank you vila10:33
bialixI need to talk with Gary first10:33
maxbit may be better to not put gui sizing caching in bazaar.conf10:34
bialixhe has changed our internal config machinery a lot in the recent times10:34
maxbit irks me that bzr-gtk does10:34
bialixmaxb: it's not actually10:34
maxbas this makes sharing a bazaar.conf between machines messy10:35
bialixbtw vila, if configobj so weird as I think what if the same bug will be hit by bzr core with reading bool option twice?10:35
bialixah, I see10:36
vilabialix: well, get_user_option_as_bool with return either a bool or None, but never a string10:36
bialixyou have explicit check that incoming value is a string in bool_from_string10:37
bialixactually that method returns either object itself (bool) or convert from string10:37
vilamaxb: yup, that's one thing that should be considered. The idea is that you define ConfigOptions specifying in which files they can appear10:37
bialixI'm going to adopt that function only for now10:38
vilabialix: use the one from ui and you'll be fine until you migrate to bzrlib.config10:38
bialixok10:38
bialixmany thanks10:38
bialixeven talking to wise man help to understand the problem and solutions10:39
vilamaxb: deciding in which file config options should be allowed become trickier when remote branches or repos are involved (not to mention bazaar.conf and locations.conf on a smart server...)10:40
vilamaxb: and that's ignoring the side-effects if both  smart and a dumb server are used for the same branch (with config files access allowed for the smart server but not for the dumb one...)10:41
bialixvila: ok, another problem10:51
bialixit seems configobj can't store to config bool value10:51
bialixdo you have set_option_as_bool in bzrlib.config?10:52
bialixconfigobj -> :-/10:58
maxbHi poolie  - thanks for the ~maxb/bzr/make-lp-mirror-work review - was that "good, I'll PQM it later when I have a moment" or "good, find someone on IRC to PQM it" ?11:03
fullermdSpeaking of qbzr, what's up with the fix on bug 715067?  Shouldn't it fall back to bzrlib?11:08
ubot5Launchpad bug 715067 in QBzr "No module named configobj error with debian patched bzr-2.3.0" [High,Confirmed] https://launchpad.net/bugs/71506711:08
jelmerhi jam11:08
bialixvila: bzr config --scope <-- ???11:09
bialixwhat scope could be?11:09
bialixfullermd: yes, it should11:09
jelmermaxb: I think poolie is off for his evening, I can have a look at landing it11:09
bialixactually it should use copy from bzrlib first11:10
vilabialix: afk abit, will answer later11:11
jelmerspiv: still there?11:12
bialixvila: np11:13
vilabialix: so, set_user_option is enough, we store only strings and there is probably a '%s' somewhere in configobj for turning bools into proper strings11:17
bialixvila: apparently it's not11:17
bialixI mean configobj lost boolean options for me11:18
vilabzrlib.config11:18
bialixok. I understood you11:18
bialixalready sent mail to Gary asking11:18
vilathe idea is that only strings are handled in files, get_user_option_as_xxx just convert for convenience, every{thing,one} else should deal with strings and only strings11:19
vilaunicode even, stored as utf-8 in config files11:20
bialixthe idea is perfect, but the reality is not11:20
* bialix is not happy11:22
spivjelmer: sort of11:25
Miika--Hello! I first added accidentally some files to my bzr repo and then I did bzr revert and added right files and committed. But thing is, that I really didn't know what revert does... So all the work I hadn't changed was gone from working copy... Is there any way to get them back?12:52
jelmerMiika--: revert should have created backup files for all the files it reverted12:53
Lo-lan-doLook for the *.~1~ files12:53
Miika--Oh, thanks a lot. Everything ok.12:55
jelmermaxb: hi12:57
maxbhi12:57
jelmermaxb: One of the points of the daily builds is to catch the test failures, I'd rather not mask them by running the tests in a UTF8 locale12:58
maxbjelmer: bzr-xmloutput's encoding behaviour is pretty broken internally. As far as I can tell, the entire plugin is only sanely usable in a UTF-8 locale at all. It needs a major internal overhaul for sane encoding behaviour12:59
jelmermaxb: if it's really that bad I think we should probably not ship it at all, or at the very least it would've been nice to discuss this change upfront13:00
maxbThe reason I felt comfortable directly committing the change was that I believed that there was absolutely no possibility of the testsuite passing otherwise - was I wrong in that belief?13:03
pindongahi, I want to write a python script that uses a bzr plugin internally... is there an easy way to access a plugin's code, as that resides not in the standard python path?13:03
pindongaI was thinking of using some utility of bzrlib to get to the plugin maybe?13:04
jelmermaxb: that's not wrong, but the goal is to actually fix the test failures rather than hiding them13:04
maxbAgreed - I wouldn't have done that to mask test failures, I only thought it a reasonable course of action because the actual non-test plugin code is just outright broken in non-UTF8 locales, so at least this makes the tests test the current capabilities of the plugin13:05
maxbpindonga: import bzrlib.plugin; bzrlib.plugin.load_plugins(); import bzrlib.plugins.myplugin13:06
pindongamaxb, great! thanks13:07
jelmermaxb: Fixing the plugin for non-utf8 locales isn't impossible, so it would've been nice to discuss this.13:09
jelmermaxb: Anyway, not to take away from all the other nice work you've done on getting the daily builds working again.13:12
jelmermaxb: Are you going to forward the bzr-dbus patch upstream?13:12
maxbjelmer: Understood. Again - the only reason I even considered this committable was because I thought I was taking the packaging from a state of being completely unbuildable on any buildd - and thus I couldn't possibly be making things worse, since I *believe* it could never build before.13:13
maxbHave the bzr-xmloutput tests ever passed on a buildd before?13:14
jelmermaxb: no, which is exactly why I didn't mind that they were failing - bzr-xmloutput simply wouldn't land in the daily builds PPA until the plugin was fixed13:15
maxb<jelmer> maxb: Are you going to forward the bzr-dbus patch upstream?  --- whoops, I pushed it but forgot to merge-propose. Done.13:16
=== oubiwann is now known as oubiwann_
jelmermaxb: r=me13:20
maxbRegarding the bzr-xmloutput tests - since it's present in ubuntu and debian, I think it's a net improvement to be able to run the tests on build in a forced UTF8 locale than not being able to run the tests on build at all13:21
maxbBut yes, it's not a good final state to remain it.13:21
* maxb --> lunch13:22
jelmermaxb: why the extra PYTHONPATH override in bzr-dbus' debian/rules /13:27
jelmer'morning jam13:29
vilajelmer: hi almost-PP ;) I'm not sure jam is up yet, there have been random reconnections for a couple of hours13:56
maxbjelmer: slightly pointless here, I suppose. It's there because I copied the concept from something I was working on for bzr itself, where it lets the compiled extensions be loaded.13:57
jelmermaxb: ah, ok13:58
fullermdYeah, who in his TZ would be up at this time of day?   :p13:59
* jelmer has learned to stop looking for a correlation between location and timezone13:59
jelmervila: heh, ok14:00
vilafullermd: between you and jelmer, I long ago stopped trying to correlate presence here and TZs14:02
vilahmm, I should have included myself in this list ;)14:02
fullermdNah, _we_ never tell you anything.  Why should you?14:04
vilaI don't need anybody to listen to when I talk here ? Is that what you're saying ?14:05
fullermdEh?  Who said that?14:06
jelmerDid somebody say something?14:07
guilhembijelmer: hello! I'm reading a debian changelog:14:10
guilhembi  [ Jelmer Vernooij ]14:10
guilhembi  * Cherrypick fix for compatibility with python2.7 >= 2.7.1-2.  LP: #69388014:10
guilhembi  * Switch to python-support. Closes: #56846214:10
guilhembi  * Add missing build dependency on python-configobj.14:10
guilhembi  * Make dependency on python-testtools versioned (>= 0.9.5).14:10
guilhembi  * Re-remove included elementtree and configobj. Closes: #555343, #55533614:11
guilhembi...14:11
guilhembi -- Jelmer Vernooij <jelmer@debian.org>  Fri, 21 Jan 2011 22:08:19 +010014:11
guilhembiSo in the debian version of bzr, bzr's configobj is removed. Is that "deviation" from the stock bzr expected to stay?14:11
guilhembiI'm asking, because it caught us: we have a plugin which does14:12
guilhembi"from bzrlib.util.configobj import configobj"14:12
guilhembiand it always worked, and it still works with bzr.dev or the normal bzr installs, but not with Debian's latest bzr...14:12
guilhembiWe solved it by falling back to the system configobj if bzr's is missing, but I thought I'd ask...14:13
guilhembieof14:13
jelmerguilhembi: it's actually been there in the past as well, but because of a regression we still shipped it14:13
jelmerguilhembi: we could import the system configobj to bzrlib.util.configobj, but one of the concerns is that the system configobj isn't exactly the same as the one that is shipped with bzr14:14
guilhembijelmer: won't there be deviations over time: if bzr's configobj behaves differently from the system configobj, bzr will break on Debian...?14:15
guilhembiOr is there a plan to delete configobj from the stock bzr too, to be consistent everywhere?14:15
jelmerguilhembi: we can verify it's sufficient for bzr - we run the testsuite to do so14:15
guilhembiok...14:16
jelmerguilhembi: I don't think there are any plans to remove it from stock bzr, but we should probably make it private14:16
maxbI was going to try to insert some sort of compatibility, but it turns out it's not trivial to alias a python module under a different name.14:17
maxbYou can make it work, I think, if you're willing to assume everyone uses "from bzrlib.util.configobj import configobj", but you can't make it fully compatible such that "import bzrlib.util.configobj.configobj" works as it did before the removal14:19
jamjelmer, vila: Well, I did reconnect to IRC, but I wasn't really online yet. I think my son was playing with my laptop while I was sleeping.14:46
vilahaaaa, this explains all these branch deletions then, I was wondering...14:47
vilajam: morning :)14:47
jammaxb, guilhembi: On Debian and Ubuntu we plan on using the system configobj if possible. I believe we just didn't want to require people running from source to have it installed. (We did the same for ElementTree a long time back.) As for divergence... that is why we run the tests as part of the build process now.14:48
jamvila: oh noes! my super-important-but-not-backed-up work14:48
jamvila: I guess it's bzr revert for me14:48
vila:)14:48
maxbjam: I think the problem here is more that by placing copies within bzrlib.util, they become part of bzrlib's API in the perception of plugin authors14:49
guilhembimaxb: indeed, in the latest qbzr:14:53
guilhembi./lib/util.py:from bzrlib.util.configobj import configobj14:53
guilhembi(http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/)14:53
guilhembithat will break on Debian, unless Debian has a custom qbzr?14:53
jelmerDebian has a patched qbzr, but the qbzr devs are also fixing it upstream14:54
fullermdYeah, right now it's fixed so it doesn't work on my non-Debian system   :p14:55
jelmerfullermd: what's a non-Debian system ? :P14:55
fullermdjelmer: It's a thing with up to date software   :p14:56
ssandberghi! when bzrgtk is installed, is there a way to detect from a pre-commit hook of another plugin whether this was a gcommit or a commit ?15:05
jelmerssandberg: not really - why would you want to?15:07
jelmerssandberg: I mean, you could inspect the stack..15:07
ssandbergjelmer, the plugin needs to display a message. would be nice if the message was a dialog for gcommit and a text for commit15:07
=== Ursinha is now known as Ursinha-lunch
jammaxb: everything in util is 3rd party code, hence the 'util' section. So the general recommendation is to do stuff like "try import foo except ImportError: import bzrlib.util.foo" or something along those lines.15:12
jam(possibly reversed)15:12
maxbRight, but is that actually stated as a mandatory rule of bzrlib api compatibility?15:13
=== rubbs_ is now known as rubbs
=== tchan1 is now known as tchan
=== bac` is now known as bac
jmlhello15:41
jmljust another vote for fixing that thing where merging branches that delete directories that contain build artifacts causes conflicts.15:41
vilajml: you haven't paying attention to bzr.orphan_policy=move don't you ?15:43
vilas//been/15:43
vilaerr, bzr.transform.orphan_policy=move15:44
jmlvila: no. it's been a long time since I've read NEWS file, and I don't recall seeing it mentioned in release announcements.15:44
vilajml: it's off by default :-/15:44
vilajml: I thought you were subscribed to the relevant bug and every day since I landed the fix I waited for your feedback ;-(15:45
jmlvila: I saw that it had been split into two bugs and lots of talk about possible ways of fixing but nothing about it actually being fixed. maybe it slipped by.15:46
vilahmm, I don' remember the details... oooh, now that you mention it, yeah a more complete solution has been asked for, but for your particular case, the config option should do15:48
vilajml: as always, bugs and feedback welcome ;)15:48
vilajml: and sorry for not telling you more directly, I didn't realize you missed it15:48
jmlvila: np.15:48
=== beuno is now known as beuno-lunch
=== Ursinha-lunch is now known as Ursinha
vilajelmer: I didn;t dream after all: bzr-builddeb 2.6+bzr518~lucid116:38
jelmervila: ah, the daily builds have 2.6 :-/16:39
vilayeah, so the upstream should too no ?16:39
vilajelmer: and sorry for not pointing you there yesterday, Alzheimer... you'll see... pain...16:40
jelmerno, the daily builds debs have it completely wrong - they claim to be /post/-2.616:40
jelmervila: hey, you're talking to the guy who probably actually set it to 2.6 in that recipe...16:40
vilalol16:40
vilathanks, I feel better ;)16:41
vilagrr, no whoami set, grr16:43
jelmervila: What, and bzr let you commit without a whoami set??16:43
vilahehe, no indeed16:43
vilabut in this particular case I don't want to set one... err... let me explain :)16:44
vilaon my local package importer I don't want a whoami set in bazaar.conf, except that I'm fixing a bug and I need to commit...16:44
vilaand I don't think I can set one in branch.conf... let's try locations.conf16:45
vilaYes !16:46
vila<evil grin>16:46
jelmerhehe16:47
vilajelmer: point is (playing the devil's advocate), the actual behaviour suits me :)16:47
jelmervila: would it have been sufficient if it just warned?16:48
vilaif we add a warning, we may think about adding an option for restoring the *actual* behavior16:48
vilain that precise case no16:48
jelmerI guess we can have a tri-state option ("strict", "guess", "warning") that defaults to "warning" ?16:48
vilaI want to stay without a default whoami because I'm paranoid here, I don't want to commit anything so I won't push anything to lp16:48
vilabut that's one a good reason to keep the actual behaviour as the default one, hence the option mentioned above16:49
jelmerjam: hi16:50
jelmerjam: I'm digging into my lazy hooks work again, and am wondering if your comments on lp:~jelmer/bzr/lazy-hooks-pt1 were perhaps intended for lp:~jelmer/bzr/lazy-hooks ?16:50
jamjelmer: possibly16:53
=== beuno-lunch is now known as beuno
vilajam: did you get some feedback on the forked server ?17:24
jamvila: I've put up a lot here: https://wiki.canonical.com/IncidentReports/2011-02-11-Codehosting-Forking-Service-Down17:24
jamfrom what I can glean from the logs17:24
jambut there is a 30-min gap where we don't have any logs... :(17:25
jamand things are fine before it, and failing after it17:25
jamthe forking service itself was up and running and still servicing connections until it was stopped17:25
jamso it might be bugs in the Twisted code I wrote17:25
jamby the time it started failing (that I can see) it seems that Conch was out of file-handles17:25
vilaha, right, so, AIUI, there was some 'no more fd available' at some point17:25
jammaybe we have a handle leak in there17:25
vilayup17:25
jamvila: well, there were a lot of "no random entropy source available" which could have been masking no-more fd17:26
jambut there was one no more fd at some point17:26
vilaright, that was the piece of info I wanted to make sure you had17:26
jamvila: any idea why os.urandom would be failing?17:32
jamI was trying to check the Python source code, but it looks to me like "urandom" is only available for #MS_WINDOWS and #__VMS, but that doesn't make any sense, since I see it on babune17:33
vilaO_o17:33
jambut the code tries os.urandom before it tries to open the file17:33
vila/dev/urandom exists here indeed17:34
jamvila: so, in "os.py" if there isn't a built-in random, it creates one by opening /dev/urandom17:34
jambuilt-in urandom17:34
jamhowever, that also doesn't make sense, since Babune says it is a builtin function17:35
jamah wait, that is locally, let me check babune again17:35
jamit is the native one17:35
jamwhich opens the file17:35
jamvila: so... if open() is failing, then you will, indeed, get secureRandom failures17:36
jamnow the question is how do you find those...17:37
vilajam: IMHO you'd better check on the code hosting host, it probably runs lucid for one so babune may not be the best reference17:38
vilahosting host...17:38
=== pickscrape__ is now known as pickscrape
jamvila: I just checked the python source code. I'm not worried about it, I doubt it changes much17:59
jam/usr/lib/python26/os.py17:59
jamImplements 'urandom' in pure python by opening /dev/urandom17:59
vilabzr 2.3.0 is still in the upload queue :-/18:06
vilawhat;s the process from there ? Is it automatic or should someone approve something ?18:07
jelmer_vila: which upload queue?18:07
=== jelmer_ is now known as jelmer
vilahttps://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=&start=3018:07
jelmerI think it needs an archive admin to look at it18:09
jelmeruhm18:09
jelmerI think it needs be looked at by an archive admin18:09
* vila summons archive admins18:12
* vila needs more goats18:12
jelmerhehe18:13
fullermdI've got a chicken with a mean temper; is that close enough?18:15
vilafullermd: what ? You're supposed to be my goat official provider remember ?18:17
vilanokia/microsoft and now no more goats >-/18:17
vilaI can live without a mobile phone but...18:18
jelmermaemo was great in that it could run bzr-gtk out of the box :)18:19
fullermdSadly, work has got my goat.18:19
vilawow, you mean you work with no goat at all now ? Scary...18:21
fullermdWell, wandering around bleating about it won't help anything, so...18:22
jelmervila: I'm trying to add a function somewhere that returns an old bzr format (e.g. one that uses old style locking, or doesn't support stacking)18:23
jelmervila: and I'm not sure where to put it. bzrlib.tests.TestCase already has enough stuff on it. Would it work as a fixture?18:24
vilajelmer: whatever you chose, make sure it's well hidden ;)18:24
vilafixtures sounds like a better place than test case, especially if you prefix it when you use it ;-D18:25
jelmervila: did you see my comment about the contact address for udd?18:52
vilano ?18:52
jelmervila: it still mentions james as the contact address in case of broken imports at the moment18:53
jelmervila: s/it/the web page/18:53
vilahmm, right (how did I miss that 8-/)18:54
vilas//#bzr on freenode / ?18:54
jelmervila: in the MP18:54
vilaooh, I see your comment now, I often have a hard time when you don't leave a blank line ;-/18:55
vilabut do we want to put a real email there ?18:56
vilaI thought james_w put his name (instead of his email) to avoid spam ?18:56
=== deryck is now known as deryck[lunch]
jelmervila: Perhaps we could just mention the list, or the bug tracker18:57
jelmerI'll try to remember to leave a blank line next time :)18:57
vilajelmer: the bug tracker is now mentioned, I was about to put an URL for the list, but the page contains the email, so i think I will just put the email ;)19:00
jelmerwfm :)19:00
cody-somervilleIs there a document that describes bzr error codes?19:05
cody-somervilleIt seems like 3 is used when there are no changes to commit AND when the bound branch is out of date with the master branch.19:05
jelmercody-somerville: IIRC we use three different exit codes - success, failure and success but e.g. differences (for bzr diff)19:15
jamcody-somerville: we only really use 0, 1, 319:46
jamcody-somerville: and I'm pretty sure we don't distinguish for those particular cases19:47
shakaranHi, I would contribute with bazaar translating the docs to spanish, where should I start for find the files, maybe on rosetta launchpad?19:48
fullermdI'm pretty sure it's all in a branch somewhere; I don't believe the bzr project uses Rosetta.19:58
=== Ursinha is now known as Ursinha-afk
cody-somervilleOdd.20:41
cody-somervilleI just did an update of a branch that fetched a single small revision, that took 7.675s. Doing it again took 7.970s immediately after (tree is up to date).20:43
lifelessmost of that is probably ssh handshaking20:43
lifeless+ bzr invocation on the server side20:43
lifelesswe have an improvement in the works but it blew up when we deployed it last night20:43
cody-somervilleah, cool.20:44
jamcody-somerville: "time echo hello | ssh bazaar.launchpad.net bzr serve --inet --directory=/ --allow-writes"20:47
jamthat gives the baseline time for bzr to handshake to the server20:47
jamhi lifeless20:48
lifelesshi jam20:48
jamlifeless: the symptoms all point to a file-descriptor leak, but I haven't been able to reproduce it yet.20:50
lifelessjam: ouch20:50
lifelessunreproducable issues suck20:51
jamyep20:51
=== Ursinha-afk is now known as Ursinha
jamlifeless: argh... 'make run_codehosting' dump the file handles I'm using. Spawn 20 connections, it goes up to 60, next connection, back down to 12,13,14, perfectly clean21:17
lifelessjam: its using 3 fds per connection ?21:17
jamlifeless: stdin, stdout, stderr, yes21:20
lifelessjam: how long does it hold them open ?21:20
vila. o O (A thread with its 3 subprocess file handles not join'ed  ?.... ? ... ? 40% bet)21:20
jamat the time the forking service was shutdown it claimed to have 138 children active21:21
jamthat is about 400 file handles21:21
lifelessaccounted for, yes.21:21
lifelessdid we get an lsof ?21:21
jamlifeless: we didn't get any extra debug info, AFAIK21:21
vilahmm, I'm pretty sure wgrant pointed to a graph with ~300 connections21:21
jamI wasn't around21:21
lifelessso21:22
lifelesswe have this live on qastaging21:22
lifelesshammer that?21:22
vila+121:22
vilawith hammer >> 30021:22
jamlifeless: I did a hammer of it when we were deploying it, running 10+ concurrent connections for ~10 hours and didn't see it21:22
jambut yes, we can do more21:22
jamvila: I'm checking https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/ now21:23
vilajam: if it's related to some limits setting you may run 10 years if you're below21:23
jamvila: sure, but getting 300 concurrent connections is way over what we've generally seen. 138 is high21:23
jamit is certainly possible21:23
jamlifeless: I can say that for "echo hello | ..." the file handles are closed ~ as soon as the process exits21:24
lifelessour log files should tell us the concurrency we see21:24
vilahmm, I think the graph was showing an average of ~26021:24
lifelessjam: hang on21:24
jamlifeless: they do, but it is a bit tricky21:24
jamvila: just waiting for lpstats to actually graph something21:24
lifelessjam: why are the file handles kept open in the parent at all ?21:24
jamlifeless: to ferry the content from the bzr process to the client21:24
jamsame as before21:24
jamno more file handles than we used to have21:24
jamjust to a different process21:25
lifelessok21:25
* lifeless is imaginging a design where once handed off the fds are only needed by the bzr-sftp service21:25
lifelessless handshaking as well21:25
vilajam: meh, me too, wth ?21:25
lifelesslpstats has a linear-growth design21:26
lifelesswe're pushing its capacity21:26
vila. o O (Or spwan a clone once you reach too many fds)21:26
lifelessfirst thing I think is what jam is already doinig - reproduce21:26
jamvila: or run multiple front end services load balanced across instances... ooh look, already working on that :)21:27
vila:)21:27
vilajam: well done ;)21:27
jamlifeless: right. As for lpstats, not having intermediate filtered content is a bit of a pain. Just a denormalized table with pre-averaged samples by day or something would probably make a big difference21:27
jamvila: https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/ link is cached now21:28
jamspikes of active connections up to 36021:28
jambut the important ones *should* be Active Smartserver Processes21:28
vilayup, same here, not the one wgrant showed me, 100% sure21:28
jamwhich is pretty much always under 100, usually under 9021:28
jamor even average of about 4021:28
vilahttps://lpstats.canonical.com/graphs/CrowberryProcesses/20110211/20110212/nocache/21:28
jamI don't really know how those are computed, though21:28
vila~sure the fork server was killed at the peak21:29
jamvila: the peak of 360 I see is back on 2011-01-2921:29
jambut I'm checking your graph21:29
jamvila: the # of processes21:29
jamthere is ~200 baseline processes on Crowberry21:30
vilaindeed21:30
jamso that is only 320 - 20021:30
jamor 120 new bzr processes21:30
vilawhen this was occurring I couldn't even get 'bzr info lp: xxx' working21:30
jamvila: well, some people could21:30
vilajam: not 'bzr pull lp:bzr'21:30
jamI saw connections made and finished21:30
vilahmm21:31
jamit depended when a connection would close so that handles would free up21:31
jamand then get used by the next connection21:31
lifelessjam: how well did it perform before it went bang, do we know ?21:31
jamvila: there does seem to be an issue with child processes not terminating immediately.21:31
vilaat the time it was switched off, nobody in the #launchpad-ops mentioned a successful connection which was part of the decision to switch it off21:31
jamlifeless: very hard to tell from this graph: https://lpstats.canonical.com/graphs/CodehostingPerformance/20110211/20110212/21:32
vilajam: I just give you my feeling, better check the irc logs...21:32
jamthe problem is the 23s spike drowns out the numbers21:32
jamvila: sure. I'm just going through the disk logs and seeing a new connection come in, and successfully exit21:32
jamI don't doubt that it could have been a 90% failure rate21:32
jamlooking at bzr-sftp.log21:32
jamlots of "I can't open a new file"21:33
jamI don't know what would have happened if we just restarted without disabling the forking code21:33
vilathen that's an additional data point, not all of my connections failed, the other only hung21:33
jamATM, I'm wondering if there is a failure condition that is leaving the spawned bzr processes still alive21:33
vilajam: yeah, *I* would have wait a bit longer, but it's  easier to say when your finger is not on the trigger21:34
jamvila: what really bothers me is that the 30 minutes that are probably the most interesting, are just completely missing from the logs21:34
jamsomewhere between bzr-sftp.log.10 and bzr-sft.log.1121:34
jamI see the process get started, things get handled fine21:35
vilajam: on the flip side, *I* wasn't expecting troubles either, so when they showed up...21:35
jamand then 11:01 ish, they are all dying with no file handles available21:35
jamvila: what also concerns me about: https://lpstats.canonical.com/graphs/CrowberryProcesses/20110210/20110212/21:35
jamis that the baseline has moved21:35
jameven after restarting the machine21:35
jamit was 200-24021:35
jamit is now 260-28021:36
vilajam: yeah, I encounter the same problem when my HDD died and they were no trace in the logs because.... well, the systeme couldn't tell me...21:36
vilajam: blame the p-i ?21:36
* vila hopes jam can connect my replies to his remarks :-/21:37
vilajam: I'm long EOD, take my thoughts as random inputs, I offer no guarantee on their technical merit ;)21:38
fullermdvila: Well, they'd still be written to the other drive in your RAID, right?   :p21:38
vilafullermd: indeed not, and the more I think about it, the less I'm tempted by RAID as a substitute for good backups and admin mods versioning :-P21:39
jamvila: serve different purposes. but certainly important21:42
jamRAID won't save you from rm -rf /21:42
jambackups don't save you from hardware crashes21:43
jamespecially hot-swap RAID21:43
fullermdActually, the one time I did that (intentionally; the box was being decomissioned), it blew away something the system needed before it got done.  So rm -rf / saved me from rm -rf /   :p21:43
vilafullermd: hehe, doesn't feel the same when you really tried it ;)21:44
vilajam: but yeah sure21:46
vilamy current experiment starts from the assumption that we crossed the point where you can archive what matters for... ever21:46
jamfullermd: certainly, I can imagine it removing a kernel module that it wanted to read, etc.21:47
vilaso I have ~10 full backups of the important family data21:47
jamvila: except how can you archive those 10 backups... wait21:47
fullermdWell, I dunno what it ended up being.  But it stopped cold before it finished the rm.21:47
fullermd'course, I've also induced hard "failures" by putting small pieces of metal at very high speeds through the drive.  Not while it was running though; maybe I should try that sometime...21:48
vilafullermd: err, how did you achieve the high speed then ?21:49
vilafullermd: Or is it just a way to say you *throw* them ?21:49
fullermdExtremely exothermic chemical reaction inside a small brass case.21:49
vila:)21:49
vilabra what ?21:49
fullermdi.e., I shot it   :p21:50
vilahehe, indeed , for same value of throw ;-D21:52
* vila off... really ;)21:53
wgrantjam: Sorry, I was more concerned about getting codehosting back up. Did minimal gathering of what processes were around, and then restarted everything.22:00
wgrantjam: Some connections did succeed.22:00
jamwgrant: I understand22:00
wgrantBut then hung.22:00
jamjust hard to debug the next day with only so much logging22:01
wgrantMost were dropped during kex.22:01
wgrantYeah.22:01
wgrantThere also seems to be 30 minutes of logs missing.22:01
wgrantPossibly because it couldn't open the new one.22:01
jamwgrant: dropping during kex because it was trying to open /dev/urandom and couldn't open another file22:01
jamwgrant: possible. A bit odd that it succeeded 30min later when it was still failing to open files22:01
wgrantjam: Really good timing, maybe?22:02
jamwgrant: certainly possible22:02
jamIt does seem to hold open a log file22:02
jamsince there were lots of failures in the next log22:02
wgrantRight.22:05
wgrantI initially thought the quick rotation meant that the rsync had missed a log.22:05
wgrantBut it was confirmed that that was not the case; the log really is missing.22:05
=== Ursinha is now known as Ursinha-afk
wgrantjam: FWIW things were already going wrong in the bit before the missing log.22:15
jamwgrant: the previous log shows no failures22:15
wgrantjam: I couldn't see anything relevant in the log, but the connection time graph showed that things were bad.22:15
jamwgrant: AIUI the connection time graph is only computed every 5-10 minutes or so, so not very good granularity22:16
jambut sure22:16
wgrantHmm.22:16
jamI certainly could say that things were close to dying at the point, since it was unable to open the log file22:16
wgrantWe should get the actual data points.22:16
wgrantTrue.22:16
maxbjelmer: I'm confused. Why is the bzr-builddeb-daily recipe set to a 2.5.1~ based version?23:04
maxb(Given that 2.6 is tagged and in maverick/natty/sid/wheezy23:07
jelmermaxb: consistency with its changelog23:10
jelmermaxb: we need to ping james_w about this23:11

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!