[00:01] Okay, branch..revision_id_to_revno() worked for that one. But it fails for files like README. [00:01] dotted revnos aren't handled by that api; I think there is another newer api [00:02] there has been some stuff on the list recently too, about this [00:02] I'll take a look there then, thanks. [00:04] jelmer: Can I use the 0.6.0 release of subvertpy with bzr-svn 0.5-trunk? [00:04] enigma42, yes [00:04] jelmer: OK. [00:05] jelmer: Where do I install subvertpy? [00:05] enigma42, somewhere in your python path (./setup.py install usually does the right thing) [00:05] OK. [00:07] jelmer: Is there a way to install it unprivileged? [00:07] jelmer: LIke in "~/.python" or something like that? [00:07] enigma42, yeah, you can specify a different directory using the --root option [00:07] enigma42, but you'll have to set PYTHONPATH appropriately to use bzr-svn then [00:07] Oh, OK. [00:09] --homedir isn't it? [00:14] jelmer: OK. I use "checkinstall" to create a deb and installed it that way. [00:17] lifeless: bzr + ssh, more specifically its SSHSuprocess objects. do you know why os.read(stdin.fileno()...) was preferred over sdin.read(.. ? [00:20] lifeless: i have some questions about hooks too when you have some spare cycles [00:21] Jc2k: just ask [00:21] I'm at LCA, but will do my best [00:21] dunno wh we use os.read there, annotate may help? [00:22] Aha, branch.get_revision_id_to_revno_map()[inv.revision]. [00:22] ah ok. os.read seems to return something, but maybe not as much as you asked for. in that regard stdin.read is nicer. [00:23] lifeless: my question was about a plugin i threw together as "bzr-hookless-email reloaded" [00:24] lifeless: i replied to a post on bazaar ml about bzr-hookless-email with my thoughts, it might be easier to look at that [00:25] lifeless: basically im reusing Branch.hooks in a different context, and thats slightly evil of me but means that i have a way to make something like bzr-cia "just work" with a bzr-hookless-email type arrangement [00:25] (out of process hooks) [00:27] jelmer: Great! The latest 0.5-trunk pushed and pulled just fine. [00:27] Great :-) [00:27] jelmer: Thanks for your help. [00:29] Excellent. 4 down, 1 to go. [00:30] jelmer: OK. Same problem about branches diverging again. [00:30] enigma42, what is the error there exactly? [00:31] and what does e.g. "bzr missing" say? [00:31] Here's the symptom. Before I clear the cache, I can do a "push" or "pull" and there will be not changes. [00:31] Then I clear the cache. [00:31] Then it says they diverge. [00:32] It says I'm missing 40 revisions. [00:32] Basically, everything that has been committed since I first pulled down the branch. [00:32] So, SVN has all the revisions. [00:33] And the bzr branch has all the same revisions. [00:33] But the revision IDs don't match. [00:33] The IDs I'm getting from SVN are now different than the IDs in bzr. [00:33] enigma42: But it doesn't report that you have 40 *extra* revisions as well? [00:34] Yes. [00:34] I'm missing 40 and I have 40 extra. [00:34] Example: [00:34] From bzr: [00:34] revno: 73 [00:34] revision-id: bhatpr@pbhat1-20090122095933-d3cmuadsx8jepmna [00:34] parent: bhatpr@pbhat1-20090122094625-kq5y49s9uqagx459 [00:34] And from SVN: [00:34] revno: 73 [00:34] revision-id: svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:sys-data-analyzer/trunk:9671 [00:34] parent: svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:sys-data-analyzer/trunk:9670 [00:35] So, somehow the ID got lost. [00:35] The branch format is: Standalone branch (format: rich-root-pack) [00:35] Does it need to be something like 1-9-rich-root? [00:35] no, that shouldn't matter [00:36] what subversion version is the server running? [00:36] It's svn 1.4 via collabnet [00:36] not recently downgraded or anything? [00:36] No. [00:37] It's about to be upgraded to 1.5 this weekend. [00:37] so bzr-svn uses svn file properties? [00:37] I'm thinking so. [00:38] enigma42: The repository is not public I assume? [00:38] Unfortunately, no. [00:38] enigma42: If you run e.g. "svn diff -c ", do you see any bzr-svn properties? [00:38] OK. Let me try. [00:40] No, I don't see any bzr-svn properties. [00:40] I'm going to try putting the old cache back in place real quick to see what happens. === spiv is now known as hypatia [00:41] Yeah. With the restored cache, it's happy again. [00:42] enigma42, if you run "svn log --xml --with-all-revprops" on the last revision, do you see any bzr properties? [00:42] Let me try. [00:43] Yeah. [00:43] They are showing up as revprops. [00:43] But bzr-svn thinks it's a 1.4 server because it complains about needing to upgrade to 1.5 === hypatia is now known as spiv [00:45] jelmer: I tried using the ubuntu pastbin, but it's complaining about the xml. [00:46] jelmer: Want an email? [00:47] enigma42: No, thanks - I'm pretty sure this is related to the 1.4/1.5 logic [00:47] Oh, OK. [00:47] Let me know if you want more information. [00:48] enigma42, since when have you been using 0.5 ? [00:48] Well...the version I was using previously was checked out Dec 27. [00:48] But, I've used a variety of versions in the last several months. [00:49] Basically, I've been using bzr-svn since April. [00:49] I can't remember the first version I used. [00:49] It may have been 0.3.x...but I can't remember. [00:49] enigma42, and when was the first of these 20 revisions that are now out of sync? [00:50] Every revision commited to the branch since I checked out the branch on Jan 9 [00:51] Using the version from Dec 27 [00:51] enigma42, is there a bzr:see-revprops file property set on the branch root ? [00:52] Let me check. [00:53] Yes. [00:53] There is a bzr:see-revprops file property there now. [00:53] Is it possible to do a bzr log on a file property? [00:53] Ack. [00:53] I mean an "svn log" on a file property. [00:54] enigma42: no, I don't think that's possible [00:54] OK. [00:54] what are the contents of that property ? It should be a svn revno [00:54] It is: 9576 [00:55] The lastest rev in subversion is: 9725 [00:55] Little more info.. [00:55] This project used to be in /trunk/backoffice/sys-data-analyzer [00:56] Then, as part of our transition to using bzr as a team, I did an "svn copy /trunk/backoffice/sys-data-analyzer /sys-data-analyzer/trunk" [00:56] Then, I did a branch on "/sys-data-analyzer/trunk" to build the bzr branch the rest of the team uses. [00:57] And I run a script to push changes back into svn for corporate compliance. ;-) [00:57] ah :-) [00:57] So, it's a branch has been moved in subversion. That branch had not previously been touched with bzr-svn until after I moved it. [00:58] And it has only been touched wtih the bzr-svn version from Dec 27 [00:58] So what it seems to come down to is that bzr-svn should be looking at that bzr:see-revprops property (since this is svn 1.4) [00:58] and that property has the correct value [00:58] but it's not reading it for some reason [00:59] Is there some logging I can turn on? [00:59] Other than the transport stuff? [01:01] no, but this patch should add some: [01:02] http://samba.org/~jelmer/tmp/bzr-svn-revprop-mutter.diff [01:02] OK. Let me apply it. [01:04] OK. [01:04] It's patched.... [01:04] Do you want me to move the cache out of the way? [01:04] Start with an empty cache? [01:05] yeah, please [01:06] OK....doing a bzr missing [01:08] OK...where should I look for the log? [01:09] It says I'm missing 43 revisions and I have 43 extra revisions. [01:09] check ~/.bzr.log [01:09] OK [01:09] that should give some extra data [01:09] Want me to pastbin it? [01:09] please do [01:11] OK...just a minute....I'll post it.... [01:13] http://pastebin.ubuntu.com/108427/ [01:14] OK...I'm going to put my old svn-cache back for now. [01:14] I've got to run....I'll be back on IRC tomorrow. [01:14] ah, I think I've got it [01:15] Cool! [01:15] I'll leave it logged in.... [01:15] If you post a fix, I'll pull it down and try it out in a couple of hours. [01:16] enigma42, http://samba.org/~jelmer/tmp/fix-changes-root.diff [01:16] OK....let me try. [01:16] you'll need to revert the patch I posted earlier [01:16] OK. [01:16] I'll re-export from trunk. [01:17] OK...here goes.... [01:17] REbuilding the cache.... [01:18] Nice! [01:18] Branches are up to date! [01:18] Woohoo! :-D [01:18] cool :-) [01:19] Thank you so much! [01:19] Thanks for confirming, that was a pretty stupid bug [01:19] No problem. I'm happy I could help out. :-D [01:19] I'll do a full sync of all the different repos later and make sure all is well. [01:19] Thanks again. [01:19] I've been really pleased with 0.5 [01:20] np [01:20] Following copies is great! [01:20] Well...I'm off for now....bye.... === enigma42 is now known as enigma_afk [01:45] is there a short cut to go to the bottom thread of a loom from the top thread? [01:48] nm, found it [01:48] down-thread [thread-name] === jfroy|work is now known as jfroy === jfroy is now known as jfroy|work [03:36] * thumper has found a weirdness [03:36] in locations.conf I have a default push location set with append path [03:37] for one of my branches, I wanted this slightly different [03:37] so `bzr push --remember xyz` [03:37] however bzr tells me that value xyz is masked by locations.conf [03:37] surely if I say --remember, it should override a default??? [03:39] thumper: --remember sets stuff in branch.conf and locations.conf wins over branch.conf [03:39] there was a thread about this on the mailing list a few months back [03:39] poos [03:39] (i don't understand the reasoning) [04:15] interesting... [04:15] http://paste.ubuntu.com/108451/ [04:15] jelmer: ^ may interest you. Thats invoking git-cat-file per object [04:18] morning kiko [04:24] jelmer: how are we meant to access the dulwich that is in bzr-git? [04:24] jelmer: b.p.git.dulwich ? [04:30] * igc out for a few hours [05:16] why does the ppa repository for hardy remove bzrtools? [05:32] j^, once the updated bzrtools gets installed, then it won't remove them. [06:54] hi all [08:30] PPA for Intrepid seems to have been broken (bzrtools is 1.10, bzr is 1.11). [08:32] mcfletch: are you actively using something from bzrtools? If not, then you could un-install it [for now] and get around the problem\ [08:32] * AfC is using bzr 1.11 from PPA but didn't see your problem as I don't have bzrtools installed [08:37] Hmm, interesting, aptitude was telling me it was "broken"... I actually switched back to 1.6 to commit the changes... will try again... [08:41] Ah, I was reading the "recommended" as "required" and the second confirmation as a "you can't do that, choose something else"... guess I shouldn't updates software at 3am. [08:41] thanks for the clue-stick. [09:26] jelmer: Using a fresh checkout with bzr-svn 0.5.0~rc1+bzr does work, unlike 0.4.16, and all that fails is a reconcile (check works fine, which is odd). I can then branch that existing local branch locally, and it will work fine. But then checking it out once it's pushed to LP fails with a 'No such file'. I'm very confused. === kiko is now known as kiko-afk === asac_ is now known as asac [12:44] Hi all [12:45] hi Lo-lan-do [12:46] We're debating the ol' git-vs-bzr debate for starting a new project, and I wondered how functional the bzr-git plugin was (or was expected to get soonish) [12:46] Lo-lan-do: guess who's working on it :-) [12:47] jelmer? Well, he'll be happy to get rid of me for bzr-svn, but maybe I'll switch to pester him on bzr-git :-) [12:47] heh [12:50] Lo-lan-do: it's kind-of functional now, and improving quickly [12:50] Lo-lan-do: I'm not sure how differences in bzr and git limit it though [12:50] Does it work both ways? [12:50] ie, commit to git from bzr and vice-versa? [12:51] not sure [12:51] I imagine it will work like bzr-svn does [12:58] But with less svn-induced wonkiness, I should think. [12:58] The bzr and git data models are fundamentally so similar that there should be a lot fewer impedance mismatches. [12:59] I'll give it a try, I guess. We've agreed to have both so far until we can test how interoperable they are. [13:22] I've got a question regarding 'bzr join': after joining a tree, is the sub-tree fully contained in the parent branch? I mean can I remove the .bzr-directory of the joined tree? [13:27] hi. i've made a branch of my project, and i want the branch to become the new trunk. what's the best way to do this? [13:27] (the branch was made to port the project from c++ to c, so i don't think merging is viable) [13:28] 'trunk' in really unrelevant in bzr [13:28] so just delete trunk and copy the branch so it's a new trunk? [13:29] what trunk? [13:29] :( [13:29] it depends on your setup [13:29] they're all just branches with different names, eh? [13:29] yes [13:29] Merging could still be viable. Or you could mv away the old trunk and stick it in its place. Or you could pull or push it over the existing trunk. Or just advertise that the trunk is a different place now. Or... [13:30] fullermd: well the files have new names now that they're in c and not cpp [13:30] that doesn't really matter to bzr [13:30] Well, but you branched off that to start with, right? [13:31] So the only difference between merging and switching is that in one case, the bighugechange happens in one mainline rev, and in the other it's spread over N mainline revs. [13:33] (which isn't to say that you necessary _want_ to do it via merge; but it's just as viable an option, depending on details, as the others) [13:34] wgrant, you need the 0.5 branch, rather than the rc [13:34] I tried to 'join' a tree but I get an error: "bzr:ERROR: Cannot join FooBar. Trees have the same root". What am I doing wrong? [13:45] we're chatting about the bzr home page; some notes are in gobby.ubuntu.com if anyone's interested [13:45] what's the common way of creating tags in bzr? i'm used to copying to project/tags from svn, but it seems bzr just gives the current (or a specified) revision a name. is this how it's supposed to be done? [13:46] jelmer: I'm running r2355 at the moment; do I need later? [13:47] wgrant, no, I think that should be sufficient [13:47] wgrant, what's the error you're getting exactly === Mario__ is now known as pygi [13:49] jelmer: On the checkout from LP: [13:49] bzr: ERROR: No such file: ('1123@2b9c9e99-6f39-0410-b283-7f802c844ae2:trunk:ivle%2Futil.py', 'svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:branches%2Fstorm:1132') [13:49] and the backtrace? [13:49] The checkout doesn't give one. [13:50] The reconcile on the original local copy does; do you want that? [13:50] ah, ok [13:50] wgrant, I'll try that here locally [13:50] jelmer: Thanks. [13:51] sjokkis: with the tags command [13:56] wgrant, reconcile passes successfully here [13:56] jelmer: Huh. I'll try checking out again on another box. [14:05] how can i export a revision with the original file dates? [14:07] bzr doesn't version ctime/atime/mtime [14:09] is this a planned feature? [14:09] I doubt it, for the complexities of making it work cross-platform [14:10] it would probably confuse build systems, too [14:10] so i have no possibility to see the original file time? [14:10] what do you mean by 'original'? [14:11] Well, the time of commit is known. So theoretically, export could set file mtimes to the time of last change. [14:11] bob2: the time the file was changed [14:11] Of course, in any but very carefully crafted cases, the time of commit would be different from the mtime of the file when it was committed, and I'm pretty sure that isn't stored. But do you really care about the difference? [14:11] bond`: bzr log filename [14:12] vila: ping [14:12] jam: pong [14:13] bob2: thats ok, i'd like to see something which 'svn export' or 'hg archive' does [14:16] * fullermd points at bug 262261 [14:16] Launchpad bug 262261 in bzr "Should use the revision timestamp when exporting" [Unknown,Confirmed] https://launchpad.net/bugs/262261 [14:22] fullermd: that's what i mean [14:34] jelmer: http://pastebin.com/d3e21e522 is what I get when reconciling a fresh checkout from svn trunk. It really works fine for you? [14:35] wgrant, a clean branch created from http://ivle.googlecode.com/svn/trunk/ using bzr-svn reconciles fine for me [14:35] wgrant, can you perhaps try a clean import, after removing ~/.bazaar/svn-cache ? [14:35] But... but... [14:35] jelmer: That's what I tried. [14:35] wgrant, and if you try with a newer bzr-svn? [14:36] I don't think there's actually any fixes recently that could affect this though.. [14:36] jelmer: I looked at stuff post-2355, and it doesn't look relevant... [14:36] * wgrant removes stuff from subversion.conf. [14:37] wgrant, I'm just trying to eliminate things that could cause it to work for me but not for you [14:38] jelmer: You're running bzr 1.11, or bzr.dev? [14:38] wgrant, bzr.dev [14:58] jelmer: OK, removing all svn-related config didn't work; trying with latest bzr-svn trunk now... === beaumonta is now known as abeaumont [15:09] hi, how do i go undo all changes i've done since the last commit? [15:09] sjokkis, "bzr revert" [15:13] oh. that was simple. thanks [15:15] jelmer: It still doesn't work... Do we blame bzr 1.11? [15:15] * wgrant should go to bed ~now. [15:15] wgrant, not sure :-( Is there any chance you can try with bzr.dev ? [15:16] jelmer: I'll hopefully try tomorrow (I'm gone for a week after that). [15:16] Thanks for your help! [15:16] k [15:16] np [15:26] I had some trouble with my bzr installation and I can't figure out how to fix it [15:27] sudo apt-get install bzr .... seems to work [15:27] but then: bzr [15:27] bash: /home/john/bin/bzr: No such file or directory [15:29] looks like you have a dangling symlink there [15:29] yeah i removed it [15:29] and you still get that error? [15:32] yeah...im hunting for the symlink...it has to be somewhere [15:33] found it [15:33] :-) [15:33] argh [15:34] hey jdobrien [15:34] hi guys [15:34] hi LarstiQ [15:34] jdobrien: you may need to type 'rehash' [15:35] hash -r? [15:36] hi LarstiQ, poolie [15:36] hey jelmer :) [15:36] LarstiQ: thanks [15:37] The following packages have unmet dependencies: [15:37] bzrtools: Depends: bzr (< 1.11~) but 1.11-1~bazaar1~intrepid1 is to be installed [15:37] E: Broken packages [15:38] hi poolie [15:41] john@Monolith:/usr$ bzr version [15:41] Bazaar (bzr) 1.11 [15:49] kfogel, hi [15:50] jelmer: just responding to the web site summary mail === Pieter_ is now known as Pieter [16:00] kfogel, Actually, I had a Subversion question [16:01] kfogel, I've been pulling my hair out trying to use svn_wc_process_committed() [16:01] kfogel, it seems to require that the files it's called on are already marked unchanged. Is that correct? [16:09] jelmer: can you ask me in #svn? (and rephrase -- I confess I didn't quite understand the question :-) ) [16:09] thx [16:09] kfogel, yeah, np === andreas__ is now known as ahasenack [16:41] ERROR: selected file commit of merges is not supported yet. [16:41] Is that true? [16:41] just trying to bzr commit -x PathToExclude [16:45] jrwren, yes, that's correct - cherrypick merges are not yet supported [16:46] this is really hurting me now :( [16:46] plus its something my svn loving, bzr hating coworkers can hang over my head :( === bac is now known as bac_lunch [17:01] https://savannah.gnu.org/support/index.php?106612 ("Preparation for switching Emacs from CVS to bzr on Savannah.") [17:01] thought people here might be interested [17:04] ooooo [17:04] people still use cvs? [17:05] They could have switched to GNU Arch... [17:05] kfogel: Nice! [17:06] kfogel: I've been wondering about the bzr support on Savannah, e.g. it would be nice if they could run loggerhead [17:07] jelmer: I think they do, but it's in beta [17:07] that's part of what I'm asking in that issue [17:09] A new loggerhead release with some of the proposed patches merged in would help, in that regard *hint* *hint* [17:11] (I'm probably going to become more and more annoying about loggerhead in the near future :-) [17:12] * jelmer is eagerly waiting for the first non-start-loggerhead release.. [17:32] kfogel: Are you still looking for an editor for the scenarios on the wiki ? (Sorry, just catching up with list email) [17:33] yes! [17:33] kfogel, I'm happy to edit some of the scenarios about topics I'm familiar with [17:33] jelmer: an aggressive editor -- that is, one who can not only edit scenarios, but take out / add scenarios based on list discussion. [17:33] My initial list of scenarios is *not* to be treated as gospel. quite the opposite. [17:34] jelmer: it sounds like when you say "edit" you mean what I think of as "write" [17:34] ? [17:35] kfogel: Yes, sorry [17:37] please do! [17:37] jelmer: the reason is that the other purpose (perhaps the real purpose?) of the scenarios is to help us figure out what stories bzr doesn't know how to tell yet. [17:38] For example, just trying to write the one-off bugfix scenario has exposed that we don't, actually, *have* a recommended way to go about this that everyone agrees on. [17:38] It's important to find that out. [17:38] kfogel: Ah, right [17:39] jelmer: so, you write the scenarios you feel comfortable with. Then we see if people say "Wait, that's not how I'd do it!" [17:40] will do :-) I actually already see two existing scenarios I would object to.. [17:45] I've added http://bazaar-vcs.org/Scenarios/ConvertFromSVN === enigma1 is now known as enigma42 [18:03] How does one fix conflicting tags? Delete it and pull again? [18:06] Peng_: I just ran across that too. [18:06] I got a "conflicting tag" message when using bzr-svn. [18:07] I delete the tag from the repo, deleted it from svn, retagged the repo and then pushed. [18:07] It seemed fine until the second push. [18:07] When I got the message again. [18:09] I went ahead and deleted them. Blah. [18:09] jelmer: Any idea on how I could track down the "conflicting tag" error? [18:09] * Peng_ does it to another copy of the branch too. [18:09] jelmer: How do I see what rev svn thinks the tag is pointing to? [18:10] enigma42, bzr tags --show-ids [18:13] So, I get this: 0.11 svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:frame-broker/trunk:9425 [18:14] SVN thinks the tag is set to 9425? [18:14] Is there a way to ask SVN to see revision project/tags/0.11 is pointing to? [18:17] oh hai [18:17] jelmer: Oh...I think my issues is related to the bad id problem we found yesterday. [18:17] # bzr ci -m "wut" alternatives/abort.7.gz [18:17] bzr: ERROR: Not a branch: "/usr/share/postgresql/8.3/man/man7/abort.7.gz/". [18:17] has anyone seen that? i can't reproduce it locally [18:18] It looks like the revision id in svn is different than the revision ID in the bzr branch. [18:18] elmo, I think I've seen that [18:18] elmo, And caused by some plugin I had installed [18:18] elmo, What plugins are installed on the host where you get that error? [18:18] enigma42, Ah, that would explain it [18:19] jelmer: just bzr tools [18:19] ah, actually I can reproduce it locally [18:19] let me try with bzr 1.11 [18:20] jelmer: I'm re-branching off SVN...I'll see what happens... [18:22] jelmer: OK...Now I have a new issue: bzr: ERROR: The branch svn+https://sequoia.csd200a.com/svn/sequoia/frame-broker/trunk has no revision None. [18:23] So, it's refusing to make a branch. [18:23] ... [18:23] enigma42: That's most likely fallout from the problem we fixed yesterday (a tag referring to a nonexisting revision?) [18:24] So, I should be able to fixup the svn reprop? [18:24] enigma42, Any chance you can comment out the bit in bzrlib/builtins.py where it prints that message by catching NoSuchRevision? [18:24] jelmer: OK...let me try. [18:25] jelmer: I just hit bug 308353 again, with the latest trunk (more or less). :\ [18:25] Launchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Medium,Fix released] https://launchpad.net/bugs/308353 [18:25] jelmer: Grabbing a source copy of bzr so I can comment it out. [18:25] le sigh [18:25] Peng, which URL? [18:25] jelmer: it's https://bugs.launchpad.net/bzr/+bug/128562, FWIW [18:25] Launchpad bug 128562 in bzr "bzr commit FILE breaks when given symlink as argument" [Medium,Confirmed] [18:25] (and is still broken in bzr 1.11) [18:26] elmo, ahh [18:26] jelmer: Same URL (lighttpd-1.4.x) [18:26] Peng_, just doing a clean branch? [18:27] jelmer: No, "bzr pull". [18:28] Err, wait a minute. I hit *something*, but I'm not sure it's the same something. [18:28] jelmer: Do you want me to comment out the whole "except" block? [18:29] jelmer: It looks like it deletes the tree, prints the message, and raises a different error. [18:29] jelmer: Sorry, my mistake. It was just the bzr-search error I get. I forgot that it indexes the branch on "pull", and most of the traceback went off my screen. [18:29] hello all [18:30] abentley, if you're here - http://bazaar-vcs.org/WritingPlugins used to advise people to merge their plugins into bzrtools [18:30] i removed it [18:30] it's an option but i don't think we want it to be a catch-all [18:30] enigma42, yes, please [18:30] enigma42, that should make it show the proper traceback [18:31] Peng_, Ah, so this is the same problem you reported a bug for earlier? [18:31]