| KombuchaKip | Just to confirm, there is still no way to edit a previous commit log entry (viz. #210142)? | 06:59 |
|---|---|---|
| vila | KombuchaKip: confirmed (unless you can uncommit and re-commit) | 07:47 |
| vila | hi all ! | 07:47 |
| * fullermd vila at waves. | 07:52 | |
| * vila waves back at fullermd and wonders . o O (He cannot be in the same TZ anymore...) | 07:54 | |
| fullermd | Pfui. TZ's are for the little people. | 07:56 |
| didrocks | vila: hey, how are you? | 08:12 |
| vila | didrocks: fine, thanks, may I help ? | 08:12 |
| didrocks | vila: I guess you may, yes! | 08:13 |
| vila | good, consider yourself helped | 08:13 |
| didrocks | vila: the tarmac merger for unity is blocking on a bzr traceback | 08:13 |
| vila | :) | 08:13 |
| didrocks | :p | 08:13 |
| vila | care to pastebin it ? | 08:13 |
| vila | !paste | 08:13 |
| ubot5 | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 08:13 |
| didrocks | vila: http://paste.ubuntu.com/855099/ | 08:13 |
| didrocks | vila: hey, how are you? the first time I encounter that | 08:14 |
| didrocks | vila: I guess you need the offending branch! | 08:14 |
| didrocks | vila: I think it's tarmac at the end using an empty --author or something like that? | 08:15 |
| vila | well, this looks like a tarmac traceback, a '\n' in an author looks indeed wrong | 08:15 |
| didrocks | vila: so basically, that would mean tarmac try to bzr commit --author "foo\n" ? | 08:15 |
| didrocks | (just need to know where to start to look at) | 08:16 |
| vila | from the traceback, yes | 08:16 |
| didrocks | ok, that's all I needed to know! | 08:17 |
| didrocks | thanks vila :) | 08:17 |
| vila | you're welcome ;) | 08:17 |
| didrocks | vila: ok, found it | 08:45 |
| didrocks | vila: apparently rev.get_apparent_authors() in bzrlib can returns some \n | 08:46 |
| didrocks | there was this code in tarmac: | 08:46 |
| vila | 8-/ | 08:46 |
| didrocks | apparent_authors = rev.get_apparent_authors() | 08:46 |
| didrocks | for author in apparent_authors: | 08:46 |
| didrocks | author.replace('\n', '') | 08:46 |
| didrocks | the last line, to workaround the issue, should be: author = author.replace('\n', '') | 08:46 |
| mgz | morning all! | 08:59 |
| vila | hi mgz | 09:08 |
| vila | didrocks: nice catch | 09:08 |
| didrocks | vila: I'm wonering why rev.get_apparent_authors() gives authorname with \n (as it's about merging already existing commits) | 09:09 |
| vila | didrocks: still worth a bug against bzr IMHO, either we should accept (and filter) '\n' or we shouldn't output them | 09:09 |
| didrocks | wondering* | 09:09 |
| didrocks | vila: agreed | 09:09 |
| didrocks | vila: will open one | 09:09 |
| vila | thanks | 09:09 |
| didrocks | vila: and I have a branch with this! :) | 09:09 |
| didrocks | (as an example) | 09:10 |
| vila | a bzr one or a tarmac one ? | 09:10 |
| didrocks | bzr one | 09:10 |
| vila | oh, as a bug reproducing one :) | 09:10 |
| didrocks | lucky you, isn't it? :-) | 09:10 |
| vila | yeah, great ! | 09:10 |
| didrocks | will open it shortly | 09:10 |
| vila | 2.5.0 frozen, build installers and packages ! | 11:23 |
| fullermd | Sos, that's more than 10 million files later on lplibrarian. | 11:24 |
| fullermd | Hm. Y'know that tarball is more than 2 meg bigger than 2.4.2? Is that right? | 11:26 |
| jelmer | fullermd: what has changed? | 11:26 |
| fullermd | Hm. Well, all the stuff in po/ is new, and that's over 8 meg before compression. I guess that's it. | 11:29 |
| jelmer | ah, yep | 11:29 |
| fullermd | It's really hard to find a current bzrtools from the LP page :| | 11:30 |
| fullermd | The series and download link say the latest is 2.3.0, which I know isn't true. But I always have to dig around for a while before finding the current. | 11:30 |
| fullermd | Hm. The build process gives a 'some compiled extensions could not be loaded' error at the end every time. Doesn't once installed though. .bzr.log doesn't say anthing about what failed. | 11:41 |
| fullermd | I don't remember seeing that before. Is that just some new quirk of the build process? | 11:41 |
| vila | fullermd: translations ? | 11:55 |
| vila | (was for the 2m, yeah, you noticed) | 11:56 |
| vila | hmm, 'some extensions could not be loaded' rings no bells, on the other hand, I'm not sure I start from scratch often enough to have encountered it | 11:57 |
| vila | fullermd: did the warning also appear in .bzr.log and if yes for which command ? | 11:58 |
| fullermd | Happens every time I ./setup.py build. | 11:58 |
| fullermd | (even when there's nothing new to do) | 11:58 |
| fullermd | It does, but it doesn't say anything about it. | 11:58 |
| fullermd | Fri 2012-02-24 05:58:40 -0600 | 11:58 |
| fullermd | [25588] 2012-02-24 05:58:41.025 WARNING: bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703> | 11:58 |
| fullermd | That's the full extent of it. | 11:58 |
| vila | meh | 11:58 |
| vila | test leak ? | 11:59 |
| fullermd | Doubt it. build doesn't run the test suite. | 11:59 |
| fullermd | It's right at the end of the output | 11:59 |
| fullermd | [...] | 11:59 |
| fullermd | running build_mo | 11:59 |
| fullermd | bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703> | 11:59 |
| fullermd | Does it not do that for you? | 11:59 |
| * vila tries to reproduce in a clean env | 11:59 | |
| vila | ha, got it | 12:00 |
| vila | right, so, no command probably hints that it's a direct bzrlib use, I'd bet for some translation script which do not care about extensions | 12:01 |
| vila | ./tools/generate_docs.py man, bingo | 12:03 |
| vila | fullermd: so, harmless | 12:03 |
| vila | uselessly annoying though | 12:04 |
| vila | fullermd: can be worked around by running make first | 12:05 |
| fullermd | I figured. So I recklessly sent the update in anyway. | 12:11 |
| vila | hehe | 12:11 |
| vila | thanks for your attention to details *anyway* ;-p | 12:12 |
| fullermd | Hey, nit-picking stuff that doesn't really matter is my middle name. | 12:12 |
| fullermd | (makes filling out forms a PITA, true, but otherwise it's kinda fun) | 12:13 |
| vila | ooooh, 'd' for Details, got it ;) | 12:14 |
| fullermd | Well, *I* would pick the d for Details. But my parents picked it, so it was probably more like d for "dammit, will you shut up about the stupid details already?" | 12:14 |
| vila | Where is my milk ? Why is it too cold ? Kind of remarks ? | 12:15 |
| fullermd | Dad?! | 12:16 |
| * vila rewinds the tape to listen again... | 12:16 | |
| vila | jelmer: sphinx is already a hard dependency in debian/ubuntu ? | 12:19 |
| jelmer | vila: no, but it will be used if present | 12:19 |
| jelmer | vila: I'd either have to add a "Build-Conflicts: python-sphinx" or a patch to disable the sphinx tests | 12:19 |
| jelmer | I'm a bit wary of doing the first because it means everybody who wants to build the bzr debian package has to uninstall sphinx first | 12:20 |
| vila | ha, right, so a packager trying to build locally may encounter the issue, sorry, missed that | 12:20 |
| vila | yup, go for disabling the tests, I think the longer term fix will be to use the provided texinfo builder and only resort to ours for the older sphinx versions (including tests) | 12:21 |
| fullermd | Oh, crud. I missed the .mo files... | 12:21 |
| vila | fullermd: not a big deal for 2.5.0 I think | 12:21 |
| fullermd | I mean in the package plist. It is a deal :p | 12:21 |
| vila | fullermd: we'll see how it goes for 2.5.1 | 12:21 |
| vila | fullermd: up to you, what I meant is that translations are just starting so most of the strings will still appear in english anyway | 12:22 |
| vila | fullermd: of course if not carrying the .no files breaks bzr usage, it's a bigger deal ;) | 12:23 |
| fullermd | No, other way around. | 12:23 |
| fullermd | They're installed, but without them in the plist they don't get removed on uninstall. | 12:23 |
| vila | ouch | 12:24 |
| fullermd | Yeah, that's what I'll be feeling when somebody notices :p | 12:26 |
| * fullermd tries to quickly sneak in the change before anybody notices the PR... | 12:26 | |
| fullermd | Well, that takes some of the fun out of updating. Used to be, I could just look at $PYTHON_SITELIB/bzrlib and know I'd caught 'em all. | 12:30 |
| vila | :) | 12:32 |
| jelmer | vila: I'm getting a bunch of test failures in bzrlib.tests.test_btree | 12:41 |
| jelmer | vila: we haven't changed any of that code recently, have we? | 12:41 |
| jelmer | http://pastebin.ubuntu.com/855321/ | 12:42 |
| vila | rings no bell | 12:42 |
| * vila looks | 12:42 | |
| * vila looks again | 12:43 | |
| vila | wth ? | 12:43 |
| vila | jelmer: during a build ? | 12:43 |
| jelmer | vila: yes | 12:44 |
| jelmer | build of 2.5.0 | 12:44 |
| vila | jelmer: do you know the last successful build to narrow the search ? | 12:44 |
| vila | my first suspicion will be around extensions but we didn't change anything there either AFAIR | 12:45 |
| jelmer | vila: let me see if it's spurious first | 12:45 |
| vila | even spurious will be worrying there :-/ | 12:46 |
| jelmer | yeah, I agree | 12:46 |
| vila | jelmer: any news of these failures ? | 13:23 |
| jelmer | vila: yep | 13:24 |
| jelmer | vila: it's reproducible | 13:24 |
| jelmer | but I can only reproduce it on sid, not on precise | 13:24 |
| vila | wow, kind of rules out bzr itself no ? | 13:25 |
| vila | cpython ? pyrex ? | 13:25 |
| jelmer | vila: It seems hard to speculate about that at this point. | 13:26 |
| jelmer | vila: cython | 13:26 |
| vila | oh no, I left a pdb.set_trace() in bzrlib/doc_generate/builders/texinfo.py and it found its way into the tar.gz :-( | 13:28 |
| mgz | whoops | 13:29 |
| jelmer | vila: hmm, I don't see a significant difference in the cython and python versions on si and precise | 13:31 |
| vila | hmm, so, I can think of only two cases where this will trigger: 1) trying to use the texinfo builder (no big deal, even where we use sphinx we don't use the texinfo builder) 2) When running the full test suite where sphinx is installed which is already a filed bug | 13:31 |
| vila | jelmer: and between the generated C files between <last-known-working> and 2.5.0 ? | 13:32 |
| vila | but may be the extensions idea is a red herring, I can't reproduce so I'm guessing wildly I can be completely off | 13:33 |
| vila | jelmer, mgz: I'll remove the offending pdb.set_trace() from the 2.5 *branch*, that will need to be merged on trunk | 13:34 |
| vila | jelmer, mgz: it also demonstrates that pqm doesn't care :-} | 13:34 |
| vila | jelmer: even if you disable the texinfo tests, you may want to get rid of the pdb too, just in case (and sorry again about that) | 13:38 |
| vila | I don't think it's worth releasing 2.5.1 just for that | 13:38 |
| jelmer | let's see what the cause is of this btree test failure, too | 13:45 |
| vila | jelmer: yup, 2.5.0 won't be released next week anyway (only the week after) but it would be good to fix the failure before pushing to debian/ubuntu in the mean time | 13:47 |
| vila | looking at bzr diff -r bzr-2.5b5..6478 ( to avoid the .mo noise) reveals nothing regarding indices, did you try reproducing with 2.5b1 or something like that ? | 13:55 |
| jelmer | vila: up to 2.5b5 everything built fine in sid | 13:57 |
| jelmer | perhaps I can try rebuilding 2.5b5, maybe something in sid has changed | 13:57 |
| vila | yup, that was my suggestion | 13:57 |
| vila | good to know 2.5b5 built well though | 13:57 |
| vila | EOD'ing, EOW'ing, have fun guys ! | 14:23 |
| mgz | heh, needless outrage on the mailing list followed immediately by a whoops sorry message | 15:29 |
| jelmer | :) | 15:40 |
| * jelmer is still stumped by the test failure | 15:50 | |
| mgz | go artur/me takes a look | 15:52 |
| mgz | ...at the test failure | 15:52 |
| mgz | ...the btree ones from the pastebin up there right? | 15:53 |
| mgz | looks like a cython type issue on a 64 bit build? | 15:54 |
| jelmer | perhaps | 15:55 |
| jelmer | but why is it only happening on recent snapshots of debian sid and not on precise? | 15:55 |
| mgz | what's the exact machine those failures are from? | 15:56 |
| mgz | and the cython version? | 15:56 |
| jelmer | chroot on my desktop machine | 15:56 |
| jelmer | a sid chroot on my desktop machine (x86_64) | 15:56 |
| mgz | your desktop is... amd64? | 15:56 |
| mgz | hm... some of the failures make that look less likely | 16:00 |
| * mgz double checks the put_file implementation | 16:00 | |
| mgz | jelmer: well, osutils.pumpfile is technically borked | 16:04 |
| mgz | but I'm not sure if fixing that will help you? | 16:04 |
| mgz | hack the tests to get an actual byte diff output perhaps? | 16:05 |
| mgz | or I can patch either atomicfile or osutils to be completely correct | 16:06 |
| jelmer | mgz: hmm | 16:07 |
| jelmer | I do vaguely recall we changed something in pumpfile - do you remember? | 16:07 |
| mgz | well, the most apparent problem seems to be this in atomicfile: | 16:08 |
| mgz | def write(self, data): | 16:08 |
| mgz | """Write some data to the file. Like file.write()""" | 16:08 |
| mgz | os.write(self._fd, data) | 16:08 |
| mgz | that's not like file.write at all, doesn't handle short writes or interrupts | 16:08 |
| mgz | why you'd be hitting it when no one else has though I do not know. | 16:08 |
| jelmer | some recent python change in sid perhaps | 16:09 |
| mgz | anyway, easy enough to turn into a loop and see if it affects the failures | 16:10 |
| mgz | see osutils.send_all for an approximate template | 16:11 |
| mgz | if not, we really need to know which bytes are actually missing, rather than just that the expected count is too low | 16:13 |
| jelmer | I'm not sure if I have enough time to debug it just now, so I think I might just file a bug about it for now. | 16:14 |
| mgz | if I wave a patch at you, can you apply and see if it changes things? | 16:14 |
| jelmer | mgz: sure | 16:14 |
| mgz | okay, sec | 16:15 |
| mgz | oh, and are the failures completely reliable and unchanging, did you notice? | 16:15 |
| mgz | would suggest this theory is wrong. | 16:16 |
| jelmer | mgz: yes, they seem to be consistent | 16:17 |
| === yofel_ is now known as yofel | ||
| * jelmer was wondering if perhaps it was a \r\n<->\n issue | 16:18 | |
| mgz | yeah, me too, but I don't see how we'd get that on nix and not windows | 16:18 |
| mgz | okay, rebuilding extensions, apart from the 64bitness this box should be setup similarly to yours | 16:22 |
| mgz | and I have the failure | 16:24 |
| mgz | ace. | 16:24 |
| jelmer | ah, good | 16:24 |
| mgz | hm, I also get this: | 16:26 |
| mgz | failed to load compiled extension: .../bzrlib/_static_tuple_c.so: undefined symbol: __Pyx_PyIdentifier_FromString | 16:26 |
| * mgz does make realclean to be sure | 16:27 | |
| mgz | still there, will deal with later | 16:30 |
| mgz | jelmer: okay, new theory | 16:55 |
| mgz | we've got an updated zlib that compresses very slightly better | 16:56 |
| jelmer | I guess that's possible | 16:57 |
| jelmer | let me try installing the sid one on precise and see if that breaks things | 16:57 |
| jelmer | mgz: yes, that's it | 17:05 |
| * jelmer files a bug | 17:06 | |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| dOxxx | howdy | 21:50 |
| dOxxx | so the whole ssl cacert thing... any idea how I would go about test it? | 21:51 |
| wgz | dOxxx: just giving a https url as a branch location is okay for starts | 22:21 |
| wgz | vila had a test site that had some extra things like self signed certs but I can't find it right now | 22:22 |
| dOxxx | wgz: can you give an example URL from like launchpad? | 22:22 |
| wgz | `bzr info https://bazaar.launchpad.net/notabranch` for instace | 22:25 |
| dOxxx | aha, I see. thanks. | 22:26 |
| dOxxx | of course now if I could get sphinx to work, maybe I could get somewhere..... ;_; | 22:26 |
| wgz | have you seen the log from earlier today? | 22:27 |
| dOxxx | no? | 22:27 |
| wgz | vila had some sphinxy points | 22:27 |
| dOxxx | for me, it just breaks into pdb when sphinx is invoked by the bzr build | 22:27 |
| wgz | http://irclogs.ubuntu.com/2012/02/24/%23bzr.html#t11:23 | 22:29 |
| wgz | yeah, he realised after making the tarball | 22:29 |
| wgz | http://irclogs.ubuntu.com/2012/02/24/%23bzr.html#t13:28 | 22:29 |
| dOxxx | hmmm | 22:30 |
| dOxxx | so I have to run `./tools/generate_docs.py man` before the main bzr setup.py? | 22:30 |
| wgz | whatever works to get you past that | 22:32 |
| dOxxx | eugh no the pdb thing is something else | 22:32 |
| dOxxx | *sigh* | 22:33 |
| dOxxx | it's the second thing you linked | 22:33 |
| dOxxx | vila makes my life hard :P | 22:35 |
| wgz | you certainly deserve a small piece of cake when you're done | 22:36 |
| dOxxx | wgz: sorry to bother you, but you're the only one around :) | 22:40 |
| dOxxx | wgz: any idea what the error 'Builder 'texinfo' is a builtin builder' means from sphinx? | 22:41 |
| wgz | I'm happy to be bothered :) | 22:42 |
| wgz | that's the thing talked about in the log right? | 22:42 |
| wgz | bzr registers its own texinfo builder for sphinx, | 22:43 |
| wgz | but the newer version of sphinx has added one to the builders it provides builtin | 22:43 |
| dOxxx | yeah so it would appear | 22:44 |
| wgz | I agree it's not clear what the right short term fix is | 22:44 |
| wgz | you should be able to run the build process without generating the tex stuff from what I gather? | 22:44 |
| dOxxx | maybe I should try reverting to an older version of sphinx | 22:44 |
| dOxxx | well then I don't get documentation... | 22:45 |
| wgz | that's all that seems to be suggested, beyond "try and see at some point in the future if the builtin one will work for us" | 22:45 |
| dOxxx | I'm building the OS x installer, so I need to include docs | 22:45 |
| wgz | ...ah, and you depend on that rather than the html? | 22:45 |
| dOxxx | so it's only the pdf? | 22:46 |
| dOxxx | that causes this problem | 22:46 |
| * wgz hasn't looked at your process in detail yet, I just crib from your nice list of plugin versions when doing windows installers | 22:46 | |
| dOxxx | I build both html and pdf, so users have a choice of which they prefer | 22:46 |
| dOxxx | heh | 22:46 |
| wgz | that seems possible | 22:47 |
| dOxxx | since pdf is pretty well supported on os x | 22:47 |
| wgz | trying a sphinx downgrade seems sensible | 22:47 |
| wgz | as I agree osxy people likely expect pdf | 22:47 |
| wgz | okay, I've got to eat something, but am around, so keep throwing questions in here as you need | 22:47 |
| dOxxx | thanks! | 22:48 |
| dOxxx | halleluja! downgrading to 1.0 seems to have worked | 22:50 |
| dOxxx | I spoke too soon | 22:50 |
| dOxxx | wgz: so using sphinx 1.0 crashes with some other error and just running 'make html-sphinx' still gives the texinfo is a builtin error | 22:56 |
| dOxxx | is there any alternate way of building the html docs? | 22:56 |
| dOxxx | ah, 'make html-docs' | 22:58 |
| wgz | so, the smart thing for this release is just to not do the pdf docs? | 23:26 |
| wgz | would be nice if sphinx were a little less... volatile | 23:26 |
| === _thumper_ is now known as thumper | ||
| dOxxx | wgz: I'm doing a build with just html docs but I'm going to have to rework the packager layout as well since it's expecting pdf docs | 23:31 |
| dOxxx | hmm actually no | 23:32 |
| dOxxx | the packager doesn't install the docs | 23:32 |
| dOxxx | I leave them in the disk image | 23:32 |
| dOxxx | so maybe this won't be so bad... | 23:32 |
| wgz | well, would be nice if one thing at least was simpler than expected this evening | 23:34 |
| fullermd | As long as that's happening, can I have a pony too? | 23:34 |
| wgz | certainly, as long as it doesn't need sphinx to build | 23:35 |
| dOxxx | one last thing to try to get sphinx working.... | 23:36 |
| fullermd | Sweet. I shall name him Gumdrops, and he will follow me everywhere and bite people who cut me off in traffic. | 23:37 |
| dOxxx | afk dinner while my build crash & burns | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!