=== mnepton is now known as mneptok [00:31] spiv so shall i just retry? you're not hitting this locally? [00:33] poolie_: I haven't tried locally, but it's totally unrelated to what that patch touches. [00:33] It looks like some sort of dependency issue in the test environment. === poolie_ is now known as poolie [00:34] * poolie burns more coal [00:47] I prefer burning midnight oil, myself. [00:48] hi afc [00:48] i started a new ec2 instance [00:48] i wonder what actually ultimately fuels them [00:48] poolie: spiv: james would like the importer shutdown to -> lucid for you [00:53] Sounds like a good thing. [00:54] underway now [00:54] maxb^ [02:00] spiv, are you busy? [02:00] could you have a look at fixing the ppa daily build failures [02:00] eg https://launchpadlibrarian.net/75172413/buildlog_ubuntu-maverick-amd64.bzr_2.4.0~beta5-0~bazaar1~maverick1_FAILEDTOBUILD.txt.gz [02:01] some shallow problem with meliae it seems [02:09] Hmm. [02:14] At a glance it looks like the meliae package is broken on amd64? [02:53] yes it does [02:56] package importer is not running jobs atm, i'm working on it [03:32] poolie: hi. [04:09] http://paste.debian.net/122834/ [04:10] hm, my text went missing [04:10] does bzr-buildpackage require tags in the repo before it will build? paste above has it failing to find debian/chagnelog [04:36] Kamping_Kaiser: it might require it's versioned in the same tree [04:36] what does 'bzr st debian/changelog' show? [05:17] poolie: nothing returns [05:17] what was the context? [05:20] i have a bunch of /debian/ dirs in a bzr brfanch (Standalone tree (format: 2a)). if i try and dpkg-buildpackage any of them it returns that error [05:20] it occrus to me that it might be disliking having all packages in one branch? [05:21] it could well do [05:21] that is not a typical setup [05:21] probably at least arguably a bug [05:21] Kamping_Kaiser: so $(bzr root)/debian/changelog doesn't exist? That sounds likely. [05:23] spiv: no it doens't. [05:23] (doesnt exist) [05:26] it would be nice if the error could be a little more verbose, and or br-builddeb had an option to use $PWD/debian. do either of those seem like valid bugs to you? [05:52] if an error's confusing i'd say that's almost always a bug [05:52] the second is perhaps worth filing [05:53] i think it has a pretty strong opinion of one branch per source package so i'm not sure if it's likely to be fixed [05:54] ok. i'll file them and see what returns [05:54] thanks both :) [06:18] which packages are they for curiousity? [06:18] something of your own? [07:11] jelmer, hi, I spoke the other day to poolie and jam who let on that you might be able to give me some pointers regarding bzr-rewrite? [07:24] hi all, despite today a national holiday, I didn't feel like putting heads on pikes (death penalty have been abolished for good reasons) so I'll be around instead ;) [07:24] s//being/ [07:25] Aw, man. [07:25] * fullermd reluctantly puts his pike away. [07:26] fullermd: there are better ways these days :) [07:26] http://www.internetevolution.com/video.asp?section_id=1361&doc_id=207380 comes to mind... [07:27] Better, maybe, but not as much fun. [07:28] Oh, ew. You want to put heads on Flash?! [07:28] That's disgusting. [07:30] Some want to put flash on pikes, is it better ? ;) [07:32] See, that would be a holiday worth celebrating :p [07:38] hi vila [07:39] hi fullermd [07:59] vila, i wonder if i should shut down the importer until lp is back up [08:00] in fact i think i will [08:05] poolie_: good idea [08:09] hi jam [08:12] hola [08:12] hi there [08:19] poolie_: rather than shutting it down, just echoing 0 to max_threads works too, and is a bit easier to undo later [08:20] jam: btw, do you know you have a copy of the udd scripts owned by jameinel, not pkg_import, in /srv/package-import.canonical.com/new/test-scripts/ ? [08:22] vila: I noticed that your latest change to /etc/init.d/mass-import hasn't been deployed yet - I suppose you'll need to RT it or grab a LOSA informally [08:22] (?) [08:22] and morning all :-) [08:23] arnetheduck: hi [08:30] hi jelmer [08:30] maxb how 'easier to undo'? [08:30] Well, mass-import isn't running right now, yes? [08:31] And starting it either requires a LOSA, or a bit of creative tweaking [08:32] i think i can just start it? [08:33] just running that as pkg_import seems to work [08:33] oh [08:34] I didn't count on start-stop-daemon being that clever [08:35] 'morning maxb, poolie [08:36] i just added documentation saying this :) [08:36] vila invoked a losa last time we needed to restart mass-import. I assumed from the way the init script was written that it wouldn't run as non-root [08:37] it is a bit unusually [08:38] spiv: Any news on append-revisions-only? [08:47] yay, lp is back up [08:47] of course, it forgot who I was again [08:51] again? [09:00] vila, you fell off [09:09] ooh [09:09] so as a side effect of going lucid, we've also moved to bzr 2.4b4 [09:11] and a sane version of launchpadlib too [09:16] jelmer: How would you feel about the daily-ppa bzr build having the python-dbg support removed? It's looking challenging to support back to lucid [09:24] hmm [09:24] maxb: I'd like to stay as close as possible to the official packaging to be able to catch problems [09:24] perhaps we can split the recipe and have a separate branch that removes the -dbg package for <= lucid ? [09:28] well [09:28] It's problematic for maverick too [09:29] Although there only because there's no meliae-dbg, and the testsuite feature doesn't skip the meliae tests on the debug interpreter [09:44] maxb, so does everything seem to be working ok? [09:44] i'm going to head out in a bit [09:45] poolie, maxb: I don't remember the details but at some point not running as root was a no-go, may be things have been fixed since then ? [09:45] spiv, your patch landed [09:45] vila huh? [09:45] poolie: we're talking about mass-import on jubany right ? [09:46] yes [09:46] starting it not as root seems to work [09:46] great. That wasn't the case in the past [09:47] how did you launch it ? /etc/init.d/mass-import start or using mass_import.py directly ? [09:52] lucid ? jubanu runs lucid ? Since when ? New hardware too or just upgrade ? [09:59] jelmer, hi, I'm considering writing a plugin that replays a complete branch history while applying a script to the working tree for each commit - in other words I want to end up with the same sequence of commits including all commit properties and merges, but with different file data (depending on the script)...I was wondering if any parts of the bzr-rewrite plugin might help with this? [10:00] jam: seen my last comments about the 2.3.4 blocking bug ? I agree with you, just wanted to make sure you're ok with landing the patch as is and addressing the larger issues in a followup [10:05] maxb: We could use the same branch for lucid and maverick [10:06] maxb: maybe just with a bzr-daily and a bzr-daily-pre-natty recipe? [10:06] arnetheduck: hi [10:06] arnetheduck: You might be able to reuse some bits from the current bzr-rewrite, or at least get some inspiration from there. [10:07] arnetheduck: the current code is a bit more complex than it needs to be though [10:08] jam: ping [10:08] jelmer: heh, indeed, I had a quick look but nothing obvious came up on the first perusal so asking seemed like a better idea =) [11:00] jelmer: you were saying that there are long-term plans to polish loom. do you know of any detail attached to those plans? [11:00] poolie: ^ [11:01] jml: everybody seems to agree we want to make looms rock, that having them better supported in core would be nice, and that they would be an awesome way to represent quilts in debian packages [11:01] but as far as I know there are only vague plans at this point [11:02] right. no specs for exactly what 'rock' means here, for example [11:13] jml: 'rock' should include the ability to share looms, including merging them [11:14] vila: agreed. but I guess I meant a list of things somewhere other than random IRC comments :0 [11:14] jml: bugs.launchpad.net/bzr-loom, I guess ;) [11:16] yeah yeah [11:16] because everyone knows that the full list of bugs is all you ever need to do focused work [11:17] spiv: wait till you see my specs for making Launchpad rock! [11:17] Uhoh. The UDD importer seems to have lost the ability to write to debian branches. [11:21] binged flacoste on #launchpad to fix [11:33] maxb: sounds like poolie's change to change credentials to the pkg_import robot [11:34] yes [11:35] jam: ping [11:41] hey vila [11:41] sorry about the delay [11:41] for some reason IRC isn't actually making noise for me [11:41] I have the "beep when someone says your name" checked... :( [11:41] jam: np ;) As long as we meet in the end :) [11:41] :-/ [11:42] I hate it when it stopped working for me [11:42] stops even [11:42] anyway [11:42] so, about bug #786980, I'd like to double-check you're ok to land the patch as is and handle the other issues in a follow-up [11:42] Launchpad bug 786980 in Bazaar 2.3 "bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction" [High,In progress] https://launchpad.net/bugs/786980 [11:43] jam: I've added some comments to the review since your last one [11:46] reading now [11:46] thanks [11:48] vila: I think we talked past eachother a bit. I asked for more tests, and you said "I agree with that but I don't think the stable branch is the place to add more fixes" [11:49] I don't actually think we have more bugs in edge cases [11:49] just lack of test coverage. [11:49] ha [11:49] And if we *have* bugs, then we should be fixing them on the stable branch anywaay [11:49] hmm [11:49] and the 'update' thing is because I didn't realize you had extra commits on master branch [11:49] it is a bit hard to make that clear in tests, unfortunately. [11:49] well, I think we have more bugs, including storing url-encoded urls in the config files [11:50] so yeah, we weren't talking about the same things [11:50] I think they *should* be stored url encoded... [11:50] why ? [11:50] because URLs aren't UTF-8 strings [11:50] and 7-bit URLs fit just fine in a UTF-8 file. [11:50] but the config files are [11:51] and we get their content as unicode... [11:51] and I'm concerned about what people will put there [11:51] even if in this case bzr itself is storing them, a user can still edit them [11:52] but I don't feel like fixing this kind of bug in 2.3 [11:52] vila: interpreting parts of a URL that we don't control is dangerous [11:52] exactly [11:52] as anyone can put their repo at "http://host/latin-1/repo/.bzr" [11:53] so trying to decode "latin-1" can fail [11:53] so it should stay encoded (as the user gave it to us) [11:53] and we shouldn't try to fake that we understand it [11:53] that's the point [11:54] users are likely to give them in their own encoding from the command-line (whereas internally bzr will attempt to store them as... well, I'm not entirely sure but probably url-encoded [11:55] (reading log: "'update' thing is because I didn't realize you had extra commits", ha good, thanks for confirming) [11:56] vila: URLs don't have the 8th bit set. psuedo-URLs might [11:56] we should be storing URLs [11:56] yes they come out of the config system as ascii [11:56] sory [11:56] as unicode [11:57] but we can safely '.encode(ascii)' them [11:57] hmm [11:57] yeah, that avoids the issue but url-encoded is not user-friendly [11:58] and whatever we chose, another bug is that we should raise a user error if we can't properly decide an url in a config file [11:58] s/decide/decode/ [12:00] so this kind of problems (how do we store/retrieve URLs from config files) has ramifications far beyond this proposal which makes me a bit uncomfortable [12:00] vila: ATM, you can't supply a non-URL-encoded URL [12:00] you can supply a Unicode (ish) local path [12:00] you can, just edit the config file [12:00] we can consider that illegal, you can't pass them on the command line [12:01] I think overhauling this is *way* outside a stable release [12:01] ha good [12:01] certainly [12:01] but that was never what I asked for [12:01] I was asking for tests covering stuff like "~user" [12:01] right, but I couldn't understand where your drew the line [12:02] "valid URL" should match "valid URL" [12:02] but ~user *is* a non-URL-encoded URL [12:02] no, ~user is valid, IIRC [12:02] I'll check [12:02] well, +branch definitely isn't valid [12:03] but I need to check too :) [12:03] http://www.ietf.org/rfc/rfc1738.txt [12:03] yup, exact same link :) [12:03] says "~" is unsafe and "must always be encoded within a URL" [12:07] jam: That's a very ancient RFC [12:07] The more modern ones all agree that unencoded ~ is right and proper [12:07] maxb: urls ? [12:07] http://tools.ietf.org/html/rfc3986 ? [12:07] ttp://www.ietf.org/rfc/rfc3986.txt [12:08] jam: see 2.3 and 2.4 of http://www.ietf.org/rfc/rfc3986.txt [12:08] unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" [12:08] vila: Use the htmlified rfc browser at http://tools.ietf.org/html/rfc1738 - and click through to the obsoleted by [12:09] hm, well that would work if the things in the obsoleted by field actually made sense [12:10] maxb: yeah, thanks, they kind of make sense if you include Updated by [12:10] and even then, it doesn't describe *what* is obsoleted by what [12:10] hehe, that's the nice part of dealing with RFCs :) [12:20] wow, so http://tools.ietf.org/html/rfc3986 has a red warning 'Errata Exist' but they aren't applied to the displayed text :-/ [12:20] vila: anyway, you can land it, I'd like a bit more tests, but we ca ndo that on trunk if you feel strongly. [12:22] jam: ok thanks, I think this fix is enough to unblock the SRU which is my main target here [12:23] there is still uncertainity in this area which would be nice to address so I'll see what adding tests reveal (or not) and see from there whether it's ok to add them to trunk or whether I encounter other bugs (that I could then file) [12:27] jam: what stays unclear for me is how I should write such tests: specifically how do I introduce a distortion between what bzr stores and what is later retrieved... [12:28] jam: do you have an idea about why/when bould_location lost its final slash ? [12:34] vila: I haven't seen anything specifically that indicates we dropped the final slash. [12:34] We've been pretty good about Transport.base always having a trailing slash. [12:34] right, but the bug reports were about people lacking the final slash in their config files [12:36] a previous fix has activated the code path where we compare the urls, but it works ok if the branch is created from scratch [12:37] so the url present in the bug reporters config files has been created earlier at a point where there wasn't a final slash [12:37] and yes, transport._base should always have one (AFAICS) === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno === zyga is now known as zyga-afk [17:42] revno for bzr-2.3.4 ? 5656 :D [17:48] And to be clear: 2.3.4 has gone gold, tarball uploaded on launchpad, email sent to ML, so: installers/packages needed ! ;) [18:12] hrm I haven't finished 2.4b5 yet :-/ [18:12] (complications with sid changes to the packaging) [18:16] Shucks, another boring lplibrarian number. No fun at all... [18:21] Trying to use bzr-builder and I think I'm missing something.. [18:21] http://paste.ubuntu.com/644279/ [18:21] It doesn't seem to modify debian/changelog after 'bzr build recipe foo' .. foo/debian/changelog is identical to the one from the nest-part that I did. [18:22] SpamapS: I think you want "bzr dailydeb" [18:22] bzr build doesn't use deb-version AFAIK [18:23] Hmm ok I thought bzr build would allow me to inspect and build it [18:24] SpamapS: bzr dailydeb only creates a source package IIUC [18:24] ahh --no-build is what I want [18:24] no dailydeb builds by default as it failed for me. [18:25] jelmer: I see the point though, build just squishes the pieces together, whereas dailydeb does something with them. [18:27] jelmer: cool.. the recipe actually works fine. :) [18:28] jelmer: thanks for the reassurance. :) [18:48] fullermd: you should file a bug, I'm sure there is a way to fix it by creating a bzr lp-xxx command to get the right url [18:48] fullermd: or is requiring *a* bzr to do that a no-go ? [19:19] * jelmer waves to vila [19:19] vila: ?? ECONTEXT... [19:20] fullermd: "another boring lplibrarian number" [19:20] vila: how's RMLL? [19:21] fullermd: Isn't the issue related to a url that you can't reliably use ? [19:21] What would a lp-xxx command have to do with that? I mean, you don't upload the tarballs via bzr, right? So it's not like you could pick an unboring one there... [19:22] Oh, it's not an "issue". Just boring is all. "75242790" is just no fun at all. [19:23] fullermd: http://launchpad.net/bzr/2.3/2.3.4/+download/bzr-2.3.4.tar.gz [19:23] fullermd: why don't you use that ? [19:23] fullermd: just to refresh my memory [19:23] Because ports exlicitly doesn't follow redirects, so I have to resolve through to the lplibrarian URL to put into the Makefile. [19:24] "exlicitly doesn't follow redirects" ?? What's the rationale ? [19:25] I think one major one was to avoid user confusion in the face of "friendly" servers that 302 to a "gee, I dunno what you were looking for" page instead of just 404'ing or the like. [19:25] (and thus winding up with a ".tar.gz" that contains 15k of HTML, and mysteriously fails the checksum tests, etc) [19:26] hmm and no config option to disable that ? [19:27] There aren't that many evil sites (bogus redirects) and tarball are not hosted there ? Aren't they ? ;) [19:27] Oh, I could big-hammer it in various ways. Overwrite the fetch(1) args, say. But there'd have to be a lot more compelling reason than "save me typing a command and C&P'ing a big number every month or two". [19:27] Enough that I remember it having come up at some point in the distant past. [19:29] Oh right, so you were Shuck'ing here so I know I could mention the BSD port in the official announcement [19:29] * vila furiously takes notes to *not* forget [19:29] :p [19:30] I was just hoping for a palindrome or a perfect number or something... shine a little light into my day. === yofel_ is now known as yofel [19:42] mgz: I just setup an oneiric chroot on babune : http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/lastFailedBuild/ [19:42] mgz: I'm pretty sure I read some emails were you talked about a fix [19:42] I thought oneiric was the one with the broken python? [19:43] yup, that's it, I follow the mails to the python site [19:43] followed [19:43] ah, it is. but... I'm suprised selftest runs at all. [19:43] have a look :) [19:44] only 43 identical failures, so your fix should be enough [19:44] what I didn't remember is if/when python will be fixed on oneiric [19:44] I don't remember, grr [19:44] I can hack around in bzr if we need to, did I understand correctly that it had some non-release version of python 2.7 though? [19:45] who ? oneiric ? [19:45] yeah. [19:46] no idea [19:46] jelmer runs oneiric [19:46] ha wait, stoopid [19:46] I can reproduce the issue on oneiric, fwiw [19:46] jelmer: `python -V`? [19:47] jel... :) [19:47] Python 2.7.2+ [19:47] not much help :) [19:47] the '+' is what I thought. [19:47] it's a upstream snapshot from 20110709 apparently [19:48] so, they built some version from hg rather than tarball. [19:48] yep [19:50] so, what I don't know is how long that funky version is planning on lingering around. if they are going to update python, there's not much point working around in bzr a problem that existed for two weeks on python trunk. [19:51] but it's not hard to do, so I can propose a change if that helps anyone out. [19:52] mgz: let's wait a bit [19:52] or rather, let see who we can poke to know if/when the oneiric python will be fixed [19:52] jelmer, maxb: any idea ? [19:56] mgz: do you have the url for the python bug ? [19:57] [19:57] excellent, thanks [19:58] my heat hurts from writing javascript all day. [19:59] I am going to get some coffee and see if that helps. [19:59] mgz: heat eh? [19:59] curly braces, I think. [20:00] curly braces turns heads into heat ? [20:01] like, burning them ? [20:01] Should be a cultural thing... we used to put them on pikes around couple of centuries ago [20:03] Far more civilized to use barracudas. [20:07] not according to the barracudas... [20:20] jelmer: already fixing bug #810701 ? [20:20] Launchpad bug 810701 in Bazaar "i18n.install fails in fails some situations" [High,In progress] https://launchpad.net/bugs/810701 [20:21] vila: yep [20:21] and simplifying some of the i18n code in the process [20:22] if lang is not None in i18n.py should be enough [20:22] ha great [20:22] I think I saw another report of that [20:22] don't know if it was a bug entry though [20:23] ah, mailing list. [20:24] https://lists.ubuntu.com/archives/bazaar/2011q3/073189.html [20:26] mgz: thanks for the heads-up, replying [20:30] ooooh, fireworks time ! I forgot :) [20:30] vila: huh, what's the occasion? [20:30] wait, it's november? [20:30] what happened to the summer ;_; [20:31] we put heads on pikes, dance in the street and so on [20:31] celebrating freedom and getting rid of tyrans [20:31] hmm [20:32] I think celebrating actually blowing something up is just wrong, you need to celebrate nearly but not quite blowing something up. [20:32] may be we need to do it again instead of celebrating it ;) [20:32] What, celebrate failure? That's not for another 8 days. [20:34] * fullermd points at the obligatory http://www.qwantz.com/index.php?comic=955 [20:35] wow, my own Juliet is born on the Pi approximation day ! And I didn't notice earlier... [20:35] hey... [20:36] i'm trying to do a daily build [20:36] and having some trouble [20:36] vila: I think that makes you a bad father. Or a bad mathematician, maybe. One or the other. [20:36] http://paste.ubuntu.com/644352/ [20:37] i have 2 issues initially [20:38] a.) i can't get '{debupstream}' to work [20:38] Committed revision 453. [20:38] bzr: ERROR: Invalid deb-version: {debupstream}+452+5: Invalid version string '{debupstream}+452+5' [20:38] then, if i just say "forget that" [20:39] b.) if I have '1.3.1-0ubuntu11' in the version, then it insists that the euca2ools branch have a 'upstream-1.3.1' tag in it [20:39] smoser: you can prevent b) by passing --allow-fallback-to-native [20:40] a) is probably bug 801618 [20:40] Launchpad bug 801618 in bzr-builder "{debupstream} no longer looks at non-base branches for debian/changelog" [Critical,In progress] https://launchpad.net/bugs/801618 [20:41] hi jelmer [20:41] hey James [20:41] have you seen bug 809412? [20:42] Launchpad bug 809412 in bzr-builder "{debupstream} isn't working in a local recipe" [Undecided,New] https://launchpad.net/bugs/809412 [20:42] so given those two things, how is it iexpected that soeone would build an upstream branch ? [20:43] i think i might be hitting that. [20:43] james_w: I hadn't yet, it's a dupe of 801618 [20:43] jelmer, I wasn't sure, as he uses {debupstream:packaging} [20:45] james_w: oh, I hadn't seen that yet [20:46] smoser: Either add a upstream-FOO tag or specify --allow-fallback-to-native if you're ok with building a native package [20:46] smoser: The debupstream is the top item on my todo list (just got back from leave) and should be resolved soon. [20:46] well 2 things sucks about tag. [20:46] a.) i can't tag lp:euca2ools (no write access there) [20:47] b.) there isn't actually even a tag that would make sense... their bzr branch and releases were not tied together. [20:48] smoser: --allow-fallback-to-native makes the most sense in that case then, I guess [20:48] i guess the only option is allow fallback to native, which is fine , i just want something for now. [20:48] how do i add that to the recipe? [20:48] it's specified on the command-line to "bzr dailydeb" [20:48] and, would there be some other way to utilize the fact that lp:ubuntu/euca2ools *does* have a sane upstream-1.3.1 tag ? [20:48] jelmer, right, but i want to push that to launchpad [20:49] smoser: launchpad runs an older version of bzr-builder that implicitly uses --allow-fallback-to-native [20:49] :) [20:49] smoser: can you file a bug about looking for upstream-FOO tags in other branches? [20:50] sure [20:50] and we think that the {debupsream} would work ther ealso ? [20:51] yeah, the {debupstream} bug is not present in the bzr-builder on launchpad [20:51] so if i hadnt' tried to test this locally i'd have a couple hours of my life back [20:51] :) [20:51] (it's actually what's preventing the deployment of the new bzr-builder to launchpad) [20:51] smoser: sorry about that :-/ [20:51] well that will teach me to try to test something before pushing [20:52] thanks for your help, though, jelmer [21:02] jelmer, bug 810740 [21:02] Launchpad bug 810740 in bzr-builder (Ubuntu) "support obtaining tag upstream-VERSION from other repository" [Undecided,New] https://launchpad.net/bugs/810740 [21:02] smoser: thanks! [21:02] you could probably add more context there. [21:02] i'm not really sure i knwo what i'm talking about or explained myself clearly [21:03] smoser: I think that's a pretty good explanation of it === zyga-afk is now known as zyga [21:32] hi all [21:32] hey poolie! [21:32] hey mgz [21:32] how are you? [21:33] did you get anywhere with my test-errors branch with the unicode failures? [21:33] otherwise i might try to finish it today [21:34] only as far as tracking down the failures, I did mean to have a look at which changes need making [21:34] but have been buried in curly braces [21:35] I'm a little scared of what bad habits I'll have picked up when I get back to python. [21:44] poolie: hey ! [21:44] definitely bed time for me :) [21:44] I spent some time in a c codebase that did "func (args);" (notice the space), and then I started doing that in python :( [21:44] hi there [21:44] doesn't that work? [21:45] night vila! [21:45] what, that space? it does, but it looks really weird [21:46]