| jelmer | hey poolie | 00:57 |
|---|---|---|
| poolie | hi jelmer! | 01:16 |
| poolie | biab | 01:16 |
| vila | hello all ~ | 06:38 |
| vila | ! | 06:38 |
| poolie | hi vila, jam | 06:50 |
| jam | morning poolie | 06:51 |
| jam | and vila | 06:51 |
| poolie | hi jam | 06:51 |
| vila | anybody managed to land something recently ? mgz and I believe rt #48346 has broken pqm | 06:55 |
| vila | for values of recently starting at last Friday | 06:55 |
| jam | vila: the last pqm email I see is Sept 7th. | 06:57 |
| jam | so at least those emails have been broken | 06:58 |
| vila | jam: yup, me too (see rt), first root cause. But then bzr-email was.... upgraded/reconfigured and now the submissions are failing | 06:58 |
| mgz | morning all | 07:01 |
| vila | ha crap, I thought mgz commented on the rt, looks like he failed to connect there then | 07:01 |
| mgz | I didn't comment, no | 07:01 |
| vila | mgz: np, I just pinged mthaddon anyway. | 07:05 |
| vila | mgz, poolie, jam: _o/ | 07:05 |
| mgz | I don't understand bug 871386 | 07:11 |
| ubot5 | Launchpad bug 871386 in Bazaar "recipe fails to build" [Undecided,Incomplete] https://launchpad.net/bugs/871386 | 07:11 |
| mgz | last two lines of traceback make it look like a non-ascii symlink, but I can't actually find one in the branch | 07:12 |
| mgz | so maybe it's a bzr-git or submodules or something else problem | 07:12 |
| hakermania | Hey, how do I tell lp that I changed version and I'm now developing the 2.2 one and not the 2.1 for example? | 07:13 |
| hakermania | And then, in the project page in lp, in the place of the trunk there will be another dot, saying 2.2.... I can't figure it out :P | 07:13 |
| jam | hakermania: you want to create a new series, I think | 07:15 |
| vila | poolie: you're PP this week ;) | 07:16 |
| hakermania | jam, How will I? | 07:17 |
| jam | hakermania: what's the project? I'll try to give you URLs | 07:17 |
| hakermania | jam, https://launchpad.net/wallpaper-changer Thanks! | 07:17 |
| jam | hakermania: if you go to that page, and look at the timeline, underneath it should be a "Register a series" | 07:17 |
| jam | The direct link would be: https://launchpad.net/wallpaper-changer/+add-series | 07:18 |
| poolie | thanks vila | 07:19 |
| vila | poolie: there are still a couple of reviews I should finish, already on it | 07:20 |
| hakermania | jam, well, and now I'll give it the same name and info but next version number? | 07:20 |
| vila | reminder for packagers and installer builders: 2.5b2 has been frozen !! | 07:20 |
| poolie | well, i did a decent number of reviews so far today | 07:21 |
| vila | poolie: haven't checked my mail yet | 07:22 |
| vila | or rather, all of my mail ;) | 07:22 |
| poolie | but thanks for the review | 07:27 |
| poolie | s//reminder | 07:27 |
| Riddell | morning | 07:30 |
| mgz | morning Riddell! | 07:31 |
| poolie | good morning riddell, mgz | 07:33 |
| vila | Riddell: hey | 07:37 |
| vila | jam: I thought you targeted bzr.dev but your proposal for request retry are against 2.1 ? | 07:37 |
| vila | proposalS even | 07:38 |
| jam | vila: everything is currently targetted to 2.1 because that will give clean diffs | 07:38 |
| jam | I don't plan on landing that before updating it to target bzr.dev | 07:38 |
| vila | ha, thanks for confirming | 07:38 |
| vila | we can't land anything currently anyway | 07:38 |
| poolie | jam, eliz just wrote about bzr pulls from savannah timing out after an hour | 07:42 |
| poolie | could there be anything in bzr related to that? | 07:42 |
| jam | poolie: I'm pretty sure savannah said that they explicitly timeout the inetd stuff at 1 hour | 07:42 |
| jam | I could be wrong | 07:42 |
| jam | but I remember in the bug discussion that savannah was unhappy about idle connections | 07:43 |
| jam | because they wanted to limit to something like 40 active conns | 07:43 |
| jam | vila: 6202 Patch Queue Manager 2011-10-06 [merge] | 07:43 |
| jam | Is the last merge I've seen | 07:43 |
| jam | so nothing in trunk since friday | 07:43 |
| vila | yup | 07:43 |
| vila | mgz fights with one submission but ended up with an error even with all tests passing | 07:44 |
| hakermania | jam, sorry for saying it again, but you may not notice, don't know. I asked you whether in the new series registration I set the same name and info and change only the version :) | 07:45 |
| jam | hakermania: I didn't see it ealier, just a sec | 07:47 |
| jam | hakermania: name is the name of the series, so in your case, I think you want "2.2" | 07:48 |
| jam | summary can be whatever you want, it is meant to describe the series | 07:48 |
| jam | and 'branch' is whatever branch you want to be the 2.2 series branch. | 07:48 |
| jam | this may just be your development branch | 07:48 |
| jam | but you may have a separate release branch | 07:48 |
| jam | the way *bzr* does it, is that we have 'trunk' where active development is done | 07:48 |
| jam | which then gets periodically snapshotted into a stable branch | 07:48 |
| poolie | Riddell: hi, shall we have a chat? | 07:49 |
| mgz | do you want me to reopen your email rt then vila on the basis that might have borked pqm? | 07:49 |
| Riddell | poolie: ok, mumble? | 07:49 |
| poolie | sip? | 07:49 |
| Riddell | sip doesn't like me :( | 07:49 |
| vila | mgz: I tried to re-open but I don't have enough rights :-/ | 07:50 |
| mgz | ...maybe just file a new one? | 07:50 |
| vila | mgz: addind your data there and adding you as a CC should still be possibl | 07:50 |
| vila | e | 07:50 |
| jam | mgz: it is still funny to see your full name :) | 07:50 |
| vila | I'm tracking mthaddon in #launchpad-ops anyway, you can job the chase if you want ;) | 07:51 |
| mgz | ehehe, yes jam I'm still adjusting to it myself | 07:51 |
| jam | not used to seeing your own name? | 07:51 |
| mgz | ...it showing up in commit messages, not the name itself, I've had long enough with it now. | 07:52 |
| jam | :) | 07:52 |
| hakermania | jam, that's weird, I don't remember where I set the revisions to go to the '2.1' release, and even when I click on the 'Change Details' of the current trunk in the 'Name:' field I had set 'trunk', and not 2.1 o.O | 07:52 |
| jam | hakermania: you are looking for 'development focus' ? | 07:52 |
| vila | mgz: mthaddon is there, join us | 07:52 |
| hakermania | jam, what do you mean? I am just using bzr and lp's trunk system so as to update online the developing unstable code, so I assume we are saying the same thing. | 07:53 |
| jam | hakermania: I guess I don't understand your statement: " I don't remember where I set the revisions to go to the '2.1' release" | 07:57 |
| hakermania | jam, when I started uploading the development focus I should have somewhere set the release to be 2.1, lp could not know by itself. And I haven't set it as the 'Name:' of the series as you suggest me to set it (for the 2.2 version). In the 2.1 version in the 'Name:' field I've set 'trunk' and not 2.1 so I assume there's another way to set the version. | 07:59 |
| vila | poolie: to start with, I'll focus on getting numbers for the past month[s] , I'll look at getting these numbers produced in real time once I get a better idea about how it was worked until now | 08:08 |
| vila | poolie: we have something like ~60GB of logs to play with (or ~300MG if we look at the driver's log only, but they start mentioning the success only recently) | 08:10 |
| jam | hakermania: there are also "milestones" which is a single snapshot of a release series | 08:11 |
| hakermania | jam, let me try some things. | 08:12 |
| hakermania | jam, please go here: https://launchpad.net/wallpaper-changer and see what is created by creating a new series: https://launchpad.net/wallpaper-changer I actually want this ->https://launchpad.net/sni-qt/trunk | 08:14 |
| poolie | vila, 'to start with' towards counting successes? | 08:15 |
| vila | poolie: yes | 08:26 |
| vila | poolie: and getting some idea about the rythm | 08:26 |
| jam | hakermania: then what you want is to go to: https://launchpad.net/wallpaper-changer/trunk and find the "Create milestone" or "Create release" links | 08:32 |
| jam | about the middle of the page | 08:32 |
| hakermania | cool | 08:32 |
| jam | you can delete the series | 08:32 |
| jam | hakermania: note we do both in bzr: https://launchpad.net/bzr/+series | 08:34 |
| jam | we have a stable *series* of releases | 08:34 |
| hakermania | jam, i see, what's the difference of a milestone and a release? What's a milestone? | 08:36 |
| poolie | a milestone that has been released has a release | 08:37 |
| poolie | a milestone that's in the future is just a milestone | 08:37 |
| hakermania | poolie, o.O | 08:42 |
| mgz | hm, that wasn't the best worded commit message ever, sorry jelmer. | 08:46 |
| vila | poolie: raw numners: http://paste.ubuntu.com/705308/ except for some spikes it's ~200/day | 08:55 |
| vila | numbers | 08:55 |
| jam | hakermania: a milestone is a projected future release | 08:57 |
| jam | "I will release 2.3 in February next year" | 08:57 |
| hakermania | Oh, that's what I need :D | 08:57 |
| jam | and these are the bugs I want to fix in it, etc. | 08:57 |
| hakermania | jam, thanks, you are very helpful, now how do I get bzr to upload revisions to this milestone and not to the previous one? Will it automatically? | 09:02 |
| jam | hakermania: *bzr* pushes revisions to trunk | 09:02 |
| hakermania | jam, which means :O? | 09:03 |
| jam | you never push revisions to milestones | 09:03 |
| jam | and you weren't doing it before | 09:03 |
| vila | hakermania: milestones are attached to a series, each series has an associated branch, it could be the same one for all series, but if you want to maintain separate series, you'll define different branches | 09:03 |
| jam | so I'm not sure what you want it to be doing | 09:03 |
| hakermania | jam, vila, thanks for the info, what a basically want to achieve is to have online the developing code of the next release! | 09:06 |
| hakermania | What's the right way to do it? | 09:06 |
| jam | right, you'll generally just push stuff to 'trunk', and then mark releases from there from time to time | 09:06 |
| hakermania | how do I "mark releases from there from time to time" | 09:07 |
| hakermania | ? | 09:07 |
| vila | hakermania: on the milestones only | 09:10 |
| jml | In lp:udd, does AllQueue.next_job loop on packages forever? | 09:10 |
| jml | I'm guessing not, but I can't quite tell | 09:11 |
| hakermania | vila, Ok, so, now I will continue pushing the developing code. Sometime this code will be stable and I will be ready for the next release. I will create a milestone then giving it the name of the release (2.2)? | 09:12 |
| __bsm__ | Hi to all, I have one user question. Using bzr 2.4 on Win xP, issue is that I cannot diff ps1 file (windows powershell) because bzr cosinder it as binary | 09:13 |
| __bsm__ | Any suggestions how to tell bzr it is text file? | 09:15 |
| vila | hakermania: yup, you get the idea | 09:16 |
| hakermania | vila, jam, thanks for the help, I have to keep these info somewhere now because till the release I'll forget :P | 09:16 |
| vila | hakermania: hehe, the trick I use for bzr itself, is to create milestones ahead of time with rough estimate dates | 09:17 |
| TimMiao | hi there, I just installed the bzr 2.4.1 on my macbook air, would anyone please tell me how could I can remove it from system? thank you in advance! | 09:17 |
| vila | hakermania: as the expected release date approaches, I refine the dates | 09:17 |
| poolie | TimMiao: how did you install it? | 09:18 |
| vila | hakermania: also the https://launchpad.net/bzr/+milestones page is a rough planning that helps me keeping track of what is coming | 09:18 |
| TimMiao | poolie: I downloaded from bzr website, mount the downloaded file, and then double click the .mpkg file, follow the wizard to finish the installation. | 09:19 |
| TimMiao | poolie: now I can't see the installed bzr in Application folder, and I don't know how to remove it from system | 09:20 |
| hakermania | vila, I thought that you create the milestone only when the release is ready. So, can you create a milestone, set an 'expected date' and when the release is ready to set the milestone to 'released' or something? | 09:21 |
| hakermania | vila, and 'released' goes to? PPAs? | 09:21 |
| vila | hakermania: yup, you can't release without a milestone but you can create the milestone ahead of time | 09:21 |
| vila | hakermania: out of scope | 09:22 |
| vila | hakermania: what a release allow you to produce is project specific | 09:22 |
| __bsm__ | I changed file assoc in Win to notepad.exe, still bzr does not treat it as text file | 09:22 |
| hakermania | vila, :P But 'released' means that a new version is available. Is it up to me the 'where'? | 09:22 |
| vila | hakermania: yes | 09:22 |
| vila | hakermania: for bzr, for example, once the release is created, I upload the source tarball | 09:23 |
| poolie | TimMiao: sorry i don't know much about macs | 09:23 |
| vila | hakermania: I then tell the packagers and installer builders to go ahead from there | 09:23 |
| poolie | is there no system uninstall facility? | 09:23 |
| poolie | suggest you search for the 'bzr' executable and 'bzrlib' directory | 09:23 |
| TimMiao | poolie: thank you | 09:23 |
| hakermania | vila, how do you get someone to build the package for you? I do all the job myself :P | 09:23 |
| vila | hakermania: hehe, we have some really fine people around ;) | 09:24 |
| vila | hakermania: if you look at https://launchpad.net/bzr/2.5/2.5b2 (our latest release to date) | 09:24 |
| vila | hakermania: you'll see the tarball and the windows installers | 09:25 |
| vila | hakermania: I uploaded the tarball last Thursday, jam uploaded the windows installers a couple of hours ago | 09:25 |
| vila | hakermania: the mac installer will probably follow | 09:25 |
| hakermania | vila, I see. | 09:26 |
| vila | hakermania: as for the packages themselves, they may not be tracked on this page, but they will refer to 2.5b2 and may use the tarball uploaded there | 09:26 |
| vila | hakermania: the release stuff here is really targeted at upstream releases | 09:27 |
| hakermania | vila, so it's up to cooperation | 09:27 |
| vila | hmm, well, that's not true, but I think it's easier for you to think about it this way to start with | 09:27 |
| vila | hakermania: yup, that's what lp is good at, helping people collaborate around projects | 09:28 |
| vila | hakermania: https://code.launchpad.net/bzr may help you get the picture for bzr too (which branches are associated with which series) | 09:29 |
| hakermania | vila, what I do is build/fix the code, push it now and then, when something has been accomplished, make a new release, send the code to lp to make the PPAs, I get from there the DEBs and I put them to sourceforge, I then update everywhere the links (site, forum signatures etc) and then I (will) send the package to REVU for inclusion to 12.04 :P Too much to do :/ | 09:31 |
| poolie | night all | 09:32 |
| vila | hakermania: you're 'purple' ? It's hard to keep context with all you nicks ;) | 09:33 |
| vila | s/you/your/ | 09:33 |
| vila | bah, the second one | 09:33 |
| hakermania | vila, puple? what? I'm hakermania | 09:33 |
| hakermania | Do you see me as 'purple'? | 09:33 |
| vila | hakermania: that's your real name reported by xchat | 09:34 |
| hakermania | weird, I've registered this nickname(hakermania), from now on consider purple==hakermania = true | 09:35 |
| vila | hakermania: may be just a coincidence... but I seem to remember a pur... ok | 09:35 |
| vila | so, for "to lp to make the PPAs, I get from there the DEBs and I put them to sourceforge", why don't you just tell your users to use the PPA ? | 09:36 |
| vila | hakermania: and the PPA may be able to use recipes so the builds occur automatically | 09:36 |
| vila | hakermania: you also define different PPAs for daily, beta and stable and have different policies to populate them | 09:37 |
| vila | s/you also/you can also/ | 09:37 |
| vila | or may :) | 09:37 |
| hakermania | vila, because there are far too many unexperienced users out there, imagine that there are folks out there that don't know whether they have gnome 2 or 3. We had too many emails saying the program's not working while they actually used the wrong version (gnome 2 instead of 3 or vice versa). Also, I use PPAs only for stable releases. Oh, and also in the site I put the sourceforge's links because there package seems more well-organized. | 09:39 |
| hakermania | Every version has its own folder, its own readme file, it's good. | 09:39 |
| vila | hakermania: your call, just mentioning ;) | 09:40 |
| hakermania | vila, Does it look good: https://launchpad.net/wallpaper-changer/trunk ? After the code's stable I release the milestone? ALl OK? | 09:41 |
| hakermania | I'm anxious about it a little bit :/ | 09:41 |
| vila | hehe, I know the feeling :) Yeah, it looks ok (but since I have to write access here, the display is slightly different) | 09:44 |
| __bsm__ | I have one user question. Using bzr 2.4 | 09:45 |
| __bsm__ | on Win xP, issue is that I cannot diff ps1 file | 09:45 |
| __bsm__ | (windows powershell) because bzr cosinder it as | 09:45 |
| __bsm__ | binary, any suggestions? | 09:45 |
| vila | hakermania: you probably have a (+) Release now button for 2.2 that I don't see myself | 09:45 |
| hakermania | vila, I do | 09:45 |
| vila | hakermania: you're all good then I think | 09:45 |
| vila | __bsm__: what encoding is used for this file ? utf-16 is not handled as text so far in bzr, if you don't need it, try utf-8 instead | 09:46 |
| __bsm__ | vila, thanks, I will check now | 09:47 |
| hakermania | vila, nice, but when the new release is out, will I just continue to push the code simply? Maybe I will create a new milestone for the next release :)? Am I right? And when I "(+) Release now" the milestone will this be shown on the 'overview' page of the project? Sorry for the so many questions, I just want to be sure. And thanks. | 09:47 |
| vila | hakermania: yup to all :) | 09:49 |
| hakermania | vila, perfect | 09:50 |
| vila | hakermania: you probably want to *tag* your release too | 09:50 |
| hakermania | vila, what's this :P | 09:50 |
| vila | hakermania: as there is no other explicit way to find the revision corresponding to a milestone that I know of | 09:50 |
| vila | hakermania: bzr tag wallpaper-changer (bzr help tag, bzr help tags for details) | 09:51 |
| jml | hmm. | 09:51 |
| jml | has anyone run "branch_branches_from_lp" in a while? | 09:51 |
| jml | because it looks broken in trun | 09:51 |
| jml | k | 09:51 |
| hakermania | vila, oh yes, that would be nice. | 09:51 |
| vila | hakermania: ghaa, 'bzr tag wallch-2.2' or something | 09:51 |
| hakermania | vila, do I run this before the last push that corresponds to the new release? | 09:52 |
| vila | hakermania: exactly | 09:52 |
| vila | hakermania: or not | 09:52 |
| vila | hakermania: you tag an older revision | 09:52 |
| hakermania | vila, so first I push the code, then tag it... | 09:53 |
| vila | hakermania: you *can* tag an older revision | 09:53 |
| vila | hakermania: no, it's better to tag it first | 09:53 |
| vila | hakermania: but if you forget, you can catch up | 09:53 |
| __bsm__ | vila, encoding was UCS-2 Big Endian, I converted it to UTF-8, committed two revisions, and diff now works, thank you, | 09:53 |
| __bsm__ | i cannot compare to prefious commits, but it will work for future | 09:54 |
| vila | jml: sorry, where is this function ? | 09:54 |
| hakermania | vila, I don't get you. *Tagging* is a way to show which revisions is for which version. Ok, so, let's say I have a rather stable code now, and I push it to create the next revision. After the push, I tag it to show that this revision is the last one for the version 2.2. Or not :P ? | 09:54 |
| jml | vila: it's a script. | 09:54 |
| jml | vila: in the top-level | 09:54 |
| vila | jml: of ? udd ? lp ? bzr ? | 09:54 |
| jml | vila: I'm just doing a branch now that moves the code out of those scripts into udd/scripts/ | 09:55 |
| jml | vila: of udd, sorry | 09:55 |
| vila | ha | 09:55 |
| vila | jml: rings no bell as you can see :) Let me have a look | 09:55 |
| jml | vila: basically, it says distribution_name in a function where it should say distribution.name | 09:55 |
| jml | vila: but comments say the script is used mostly for debugging | 09:55 |
| vila | the initial comment says "debug purposes" | 09:55 |
| jml | yeah. | 09:56 |
| jml | I'm guessing james_w hasn't needed to debug stuff for a while :) | 09:56 |
| vila | jml: qblame says maxb only, may suffer from bitrot :) | 09:56 |
| jml | yeah. | 09:56 |
| vila | the script, not max | 09:56 |
| jml | heh heh | 09:57 |
| idnar | heh | 10:00 |
| jml | vila: do we have Python 2.5 on udd production? | 10:00 |
| vila | jml: in addition to 2.6.5 you mean ? | 10:05 |
| jml | vila: what I really mean is, 'can I use "with"?' | 10:05 |
| vila | jml: yes, I even have a wip to use wip replacing all the try commit/except rollback/finally close for the db cursors | 10:06 |
| vila | s/use wip/use with/ | 10:07 |
| jml | vila: oh cool. | 10:07 |
| jml | vila: I was thinking of doing the same thing | 10:07 |
| vila | jml: :) I'd like to add the smallest set of tests I can find to go with it | 10:08 |
| jml | vila: oh | 10:08 |
| jml | vila: that's a drag. | 10:08 |
| vila | jml: the other ~related point is to use name tuples or something for the rows, but one step at a time | 10:09 |
| mgz | vila: did you get mail about the landing on 2.4 from PQM? at least the merge worked. | 10:11 |
| jml | vila: yeah. | 10:13 |
| vila | mgz: not checked yet, but babune is busy | 10:13 |
| mgz | the big problem is fixed at least, so that's fine | 10:14 |
| vila | checked, got a bazaar-commit mail from pqm \o/ | 10:15 |
| mgz | okay, so the rt really can be closed now, good good. | 10:16 |
| mgz | and we'll have a happy fullermd as a side effect. | 10:17 |
| * vila nods | 10:19 | |
| vila | and an additional heartbeat | 10:19 |
| vila | mgz: so you changed your mind about test = self ?? It *was* a class attribute | 10:21 |
| vila | mgz: or would you have preferred an __init__ attribute (which unfortunately cannot be done) ? | 10:22 |
| fullermd | The world is better for everyone when fullermd is happy. | 10:29 |
| fullermd | Well, for me anyway. Which is close enough to "everyone" as far as I'm concerned... | 10:29 |
| mgz | vila: I thought self.overrideAttr(InnerClass, "testcase", self) was the best option I think | 10:32 |
| mgz | given you couldn't put it on the instance | 10:32 |
| vila | ha ! That one. | 10:33 |
| vila | hmm, a bit weird to use overrideAttr for a class that is embedded in the test itself though | 10:33 |
| mgz | it keeps a scoping a little clearer, and avoids test->class->test->... | 10:34 |
| vila | I don't get it, it needs to be done after the class declaration so is less clear than inside of it as testcase = self | 10:36 |
| vila | or is it that it will help your cycle detection stuff ? | 10:37 |
| mgz | yep, you need the gc to clean up the test if you leave a copy of self on an inner class | 10:39 |
| vila | mgz: bah, doesn't work: AttributeError: class FailingDuringResponseHandler has no attribute 'testcase' | 10:39 |
| vila | so we need testcase = None in addition... | 10:40 |
| mgz | meh, that's an annoyance of overrideAttr we should fix | 10:41 |
| mgz | but I wouldn't worry about changing that now vila | 10:42 |
| mgz | I can poke this stuff after it's on 2.5 with the tests actually being cleaned up properly | 10:42 |
| * vila nods | 10:43 | |
| jml | vila: udd cleanup branch up at https://code.launchpad.net/~jml/udd/clean-up-scripts/+merge/78816 | 11:15 |
| === medberry is now known as med_out | ||
| vila | jml: not really reviewed but I have some questions | 13:29 |
| jml | of course | 13:30 |
| vila | jml: I posted them, but we can discuss here, | 13:30 |
| jml | vila: ok. I'll pull up the page. | 13:30 |
| vila | jml: the most annoying bit is having the same name in both places and different parts of the whole importer referring to different paths | 13:31 |
| jml | vila: sorry, I don't quite understand | 13:31 |
| vila | jml: I understand (and value !) the desire to make them easier to test but the added scripts seem to be... a bit empty for no good reason | 13:32 |
| vila | jml: which part ? | 13:32 |
| jml | vila: they aren't empty. I've mostly bzr moved the things out of the tree into a package | 13:32 |
| jml | vila: and then created near-empty scripts that call them | 13:32 |
| jml | oh, maybe that's what you meant | 13:32 |
| vila | yes | 13:32 |
| vila | the mostly empty ones are... why do we need them ? | 13:33 |
| jml | vila: well, it's either that or use entry points and buildout | 13:33 |
| vila | buildout ? | 13:33 |
| jml | vila: you need something to execute | 13:33 |
| jml | vila: executing python scripts that are inside packages is yuck. | 13:33 |
| vila | ha | 13:33 |
| vila | oh | 13:33 |
| jml | vila: I was thinking in a separate branch that the scripts in top-level right now could be moved into bin/ and renamed to be a little nicer. | 13:34 |
| vila | but I've seen many packages (may be not many, but some) using the __name__ == main idiom to know they are run as a script while still allowing import | 13:34 |
| jml | vila: but I don't want to change the interface in this branch | 13:34 |
| jml | vila: yeah, but no one likes using them | 13:34 |
| vila | oh | 13:34 |
| jml | vila: e.g. 'python -m testtools.run <foo>' | 13:35 |
| jml | *blech* | 13:35 |
| vila | hmm, the one I had in mind was... unittest ? | 13:35 |
| jml | vila: yeah, it's the same | 13:35 |
| jml | vila: these things are scripts, the public interface should look like any executable | 13:35 |
| vila | hmm | 13:36 |
| jml | vila: the advantage of having very small executable Python scripts is that you don't have to test them. | 13:36 |
| vila | different names for the scripts then may be, but the other trend was to move the basic functions out of the scripts anyway | 13:36 |
| jml | vila: and also, if we want to merge some of the Python modules, we can | 13:37 |
| vila | right | 13:37 |
| jml | move code out of udd.scripts.list_packages into udd.icommon for instance | 13:37 |
| jml | this is, in some ways, an intermediate refactoring. | 13:37 |
| vila | intermediate step then but both trends go in the same direction | 13:37 |
| vila | hehe, yeah | 13:37 |
| jml | yeah. | 13:37 |
| vila | oh right | 13:38 |
| vila | then the logic becomes clearer but they don't deserve to go under udd/scripts then, they should just go under udd | 13:38 |
| jml | vila: also, I still largely believe that this document is right: http://as.ynchrono.us/2007/12/filesystem-structure-of-python-project_21.html | 13:39 |
| jml | vila: well... | 13:39 |
| vila | ha, let me read that | 13:39 |
| jml | vila: I guess so. Some of them are very scripty. | 13:39 |
| vila | it (the url) says don't give a '.py' to scripts, which I agree with | 13:40 |
| vila | can be done separately but we may need a TODO to keep track | 13:41 |
| vila | bah, and the REAME is bit-rotting too | 13:41 |
| jml | yeah. | 13:41 |
| jml | We can file bugs, or I can just do the *.py thing right now. | 13:42 |
| jml | But I don't want to do that before this branch lands. | 13:42 |
| vila | jml: my BIGGEST issue is that these changes are not testable, not even as smoke tests (but I'm not blaming anybody here, just explaining my lack of enthusiasm ;) | 13:44 |
| jml | vila: ah yes. | 13:44 |
| jml | vila: well, of course, the thing is that the old code wasn't testable either. | 13:44 |
| * vila nods | 13:44 | |
| vila | but I said anybody :) | 13:44 |
| jml | vila: making a change like this is necessary to making them testable | 13:45 |
| vila | this stuff works, not the same as testable, but still a valuable kind of test | 13:45 |
| jml | vila: and even if, say, I added a bunch of tests, we wouldn't be guaranteeing against regressions | 13:45 |
| jml | because I'd just be making up what I thought the behaviour should be :) | 13:45 |
| vila | it will help yes, I agree, my issue is how can I safely accept this | 13:45 |
| jml | hmm. | 13:45 |
| vila | hehe | 13:45 |
| jml | Well, we could run the scripts. | 13:46 |
| jml | If you have a staging environment, we could try that | 13:46 |
| vila | bah, not even, the only staging (local) one I have cannot write to lp (or chaos is around the corner) | 13:46 |
| jml | Hmm. | 13:47 |
| jml | Well, I don't see how you can safely accept *any* change then. | 13:47 |
| vila | oh | 13:48 |
| vila | that's because you don't see the goats | 13:48 |
| jml | vila: heh | 13:49 |
| vila | jml: more seriously, did you run them locally, which ones ? | 13:49 |
| jml | vila: no, I haven't yet. | 13:49 |
| jml | vila: the changes are self-evidently correct :P | 13:49 |
| jml | (I'll run them now) | 13:49 |
| jml | except, ugh, I'm *still* part-way through my database run. | 13:49 |
| vila | jml: can you do that, tell me the ones you didn't and I'll aprove, land, deploy and see what breaks | 13:50 |
| vila | argh | 13:50 |
| vila | jml: my rough estimates for the importer is that it takes 36 hours before starting again | 13:50 |
| vila | jml: depending on what you really do as an import, this could of course be far shorter | 13:51 |
| jml | vila: does it just loop forever? | 13:51 |
| vila | mass_import ? Yes ! | 13:51 |
| jml | vila: as in, it goes through all packages again once it's done? | 13:51 |
| vila | it runs unattended | 13:51 |
| vila | yes | 13:51 |
| jml | vila: I thought it needed constant fuelling from new cronjob runs. | 13:51 |
| vila | for new packages I think it's still needed, but the corresponding job updates the db and mass_import query it (IIUC) | 13:52 |
| vila | hmm | 13:53 |
| vila | looking at one of your scripts, importing 'main' ? Why not a more descriptive name ? | 13:53 |
| jml | Because it *is* descriptive? | 13:53 |
| vila | main ? For a script yes, but if we intend to merge this script-wanting-to-be-part-of-packages, less | 13:54 |
| jml | then we can rename it when we do that merging? | 13:54 |
| vila | fair enough ;) | 13:55 |
| jml | We could have a module called builtins and change all of the scripts to be cmd_foo and then rename main to run() if you'd like :) | 13:55 |
| vila | oh | 13:55 |
| vila | I thought about making the importer a bzr plugin if you really want to know ;) | 13:55 |
| jml | vila: yeah, I thought about it too | 13:56 |
| jml | vila: but then I realized you'd need sub-sub-commands. | 13:56 |
| vila | there was too much stuff in the scripts to tackle it safely though ;) | 13:56 |
| vila | for what ? | 13:56 |
| jml | vila: bzr udd list-packages | 13:56 |
| jml | I guess you could just have a prefix or something | 13:56 |
| vila | oh, I thought about bzr list-packages directly, it's not as if this will be distributed widely | 13:57 |
| vila | but it could also be udd-list-packages, there is not much to share into the udd command | 13:57 |
| vila | not use | 13:57 |
| vila | nor use | 13:57 |
| jml | vila: I guess so. | 13:59 |
| vila | jml: but jokes aside, why not make a builtin.py and indeed rename the mains into cmd_xxx ? | 14:03 |
| vila | jml: not making it a plugin doesn't mean we can't use some naming conventions ahead of time | 14:03 |
| vila | so many negatives >-/ | 14:03 |
| jml | vila: mostly because that's more work | 14:03 |
| jml | vila: and it's the same naming structure | 14:04 |
| vila | that's an honest answer, I like that ;) | 14:04 |
| jml | udd.scripts -> udd.builtins; module_name -> cmd_module_name; main -> run | 14:05 |
| vila | not even the run part for now | 14:05 |
| jml | With the bonus of having to disentangle naming clashes from the existing scpts. | 14:05 |
| jml | scripts. | 14:05 |
| vila | keep the separate modules | 14:05 |
| vila | bah, don't answer | 14:05 |
| vila | no, I understand | 14:06 |
| vila | but a TODO explaining the road ahead still sounds easy and valuable | 14:06 |
| jml | OK. I'll do that. | 14:06 |
| vila | great | 14:06 |
| vila | let me know when you managed to run them locally as smoke tests and which ones are left to test, | 14:07 |
| vila | from there I can land.deploy and be ready | 14:07 |
| jml | Thanks. | 14:08 |
| vila | jml: and when you have time, a private discussion about what you're doing in *your* pkgimport.import_script will probably help me help you ;) | 14:08 |
| jml | vila: oh, it doesn't have to be private | 14:09 |
| jml | vila: I'm downloading source packages and extracting the *.symbols files from them | 14:09 |
| vila | and you upload nothing ? | 14:09 |
| jml | vila: no. It's for maintaining a database locally. | 14:10 |
| vila | jml: to know when you've processed all packages, search for "All packages requeued, start again" in your logs/driver/progress_log file | 14:12 |
| vila | jml: it's in AllQueue in mass_import | 14:12 |
| jml | vila: thanks. | 14:13 |
| vila | jml: if you want to make it faster, you can raise the number of threads (default to 8), beware of bug #724893 though (unless you already ran into something like that) | 14:14 |
| ubot5 | Launchpad bug 724893 in Ubuntu Distributed Development "concurrent db access are not handled" [Medium,Confirmed] https://launchpad.net/bugs/724893 | 14:14 |
| jml | vila: lifeless warned me against that. | 14:15 |
| Riddell | mgz: unicode question, why does the str one seem to give utf8 bytes while the unicode one gives latin-1 bytes? http://paste.kde.org/132169/ | 14:45 |
| * mgz looks | 14:55 | |
| mgz | that's an optical illusion | 14:55 |
| mgz | in the str case, it gives whatever bytes your terminal gave it, which is utf-8 | 14:56 |
| mgz | in the unicode case, it decodes those bytes to a unicode characters, of 2 or 4 bytes each depending on the platform | 14:57 |
| mgz | however, the python 2 repr only prints ascii for both str and unicode | 14:57 |
| mgz | and the escape sequence \xa3 is just a shorter way of saying \u00a3 | 14:58 |
| mgz | so, u'a\xa3a' is really a 3 character * 4 byte value | 15:00 |
| mgz | and 'a\xc2\xa3a' is a 4 character * 1 byte value | 15:00 |
| Riddell | ah, so unicode repr being different from str repr is what I was missing | 15:00 |
| Riddell | unicode, always strangely more complex than you think :) | 15:00 |
| mgz | I've got a bunch of hacks I use when working with text in a python repr | 15:04 |
| mgz | to save this kind of confusion when looking at reprs | 15:05 |
| mgz | ^*repl | 15:05 |
| mgz | Python 3 has a repr that doesn't backslash escape printable unicode characters, and as of 3.3 even mostly works correctly | 15:06 |
| mgz | then you get into other kinds of unicode hot water though :) | 15:07 |
| Riddell | whee | 15:08 |
| === zyga is now known as zyga-afk | ||
| daveb_ | so, how can I merge, just a subset of commits? | 16:44 |
| daveb_ | and then merge the rest later? | 16:44 |
| === daveb_ is now known as croepha | ||
| === deryck is now known as deryck[lunch] | ||
| === zyga-afk is now known as zyga | ||
| === deryck[lunch] is now known as deryck | ||
| hakermania | vila, heh, im back from the 6-hours-lesson I had -_- I'd stack to what *tagging* is...remember? | 19:21 |
| lifeless | wgz: hi | 19:37 |
| lifeless | wgz: btw check out testresources.FixtureResource | 19:38 |
| lifeless | wgz: its the shim I was talking about | 19:38 |
| === yofel_ is now known as yofel | ||
| pfsmorigo | hi, how do I revert all changes in a directory locally? | 20:46 |
| nigelb | bzr revert | 20:47 |
| pfsmorigo | nigelb: gives me error: bzr: ERROR: Cannot lock LockDir(http://bzr.savannah.gnu.org/r/grub/trunk/grub/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 20:48 |
| nigelb | That's beyond wat[B | 20:49 |
| nigelb | pfsmorigo: That's beyond what I know :) | 20:49 |
| === jpds_ is now known as jpds | ||
| theDUBBER | www.thedubber.altervista.org | 22:13 |
| poolie | hi jelmer, hi all | 23:28 |
| Riddell | morning poolie | 23:31 |
| poolie | hi | 23:32 |
| jelmer | hi Riddell, poolie | 23:40 |
| poolie | hi jelmer | 23:41 |
| poolie | jelmer if you get a chance can you try to get the hardy buildd backports done? | 23:41 |
| poolie | (if you didn't already) | 23:41 |
| poolie | not necessarily tonight :) | 23:41 |
| jelmer | poolie: I started with it, but it's not trivial since bzr-builder relies on current quilt | 23:48 |
| jelmer | I'm hoping to upload a new package tomorrow | 23:49 |
| poolie | hm | 23:49 |
| poolie | quilt's only a build dependency? | 23:49 |
| jelmer | for bzr, yes | 23:49 |
| poolie | hm | 23:49 |
| jelmer | but bzr-builder uses it at run-time | 23:49 |
| poolie | ah | 23:49 |
| poolie | perhaps we should just backport quilt? | 23:50 |
| jelmer | There's already an up to date bzr in the canonical-bazaar/cat-proposed PPA | 23:50 |
| poolie | is it controversial only because it would have to go into cat for everything? | 23:50 |
| poolie | maybe we could have a separate ppa for this? | 23:50 |
| jelmer | poolie: That's what I did earlier, but lamont prefers to not introduce a new quilt as it might break other stuff | 23:50 |
| poolie | would putting it in a buildd-specific ppa reduce that risk sufficiently? | 23:51 |
| jelmer | poolie: I'm not sure, from my experience it's very hard to get stuff changed on the buildds | 23:51 |
| poolie | yeah so it seems | 23:51 |
| poolie | obviously we have to be careful but otoh this is blocking at least some users at present | 23:51 |
| jelmer | so I think just fixing bzr-builder to work with an older quilt would be a lot quicker | 23:52 |
| poolie | ok, so it's feasible but just not trivial? | 23:52 |
| jelmer | yep | 23:52 |
| * fullermd frowns. | 23:55 | |
| fullermd | When did -x stop working? | 23:55 |
| poolie | seems to have worked for you there :) | 23:56 |
| fullermd | Oh, I see. It works, it just lies its butt off about what it's doing. That seems... suboptimal. | 23:56 |
| Noldorin | hi jelmer | 23:56 |
| poolie | for which command? | 23:57 |
| Noldorin | jelmer, not going to pester you about bzr-git today heh...just had a quick question :-) | 23:57 |
| fullermd | ci | 23:57 |
| jelmer | hi Noldorin | 23:57 |
| Noldorin | jelmer, does git have an equivalent to bzr's lightweight checkouts? | 23:57 |
| fullermd | Mmm. bug 268135 and bug 552805 at least... | 23:58 |
| ubot5 | Launchpad bug 268135 in Bazaar "bzr commit -x doesn't change the --show-diff output (iter_changes does not support excludes)" [Medium,Confirmed] https://launchpad.net/bugs/268135 | 23:58 |
| ubot5 | Launchpad bug 552805 in Bazaar "Commit message template does not exclude files" [Medium,Confirmed] https://launchpad.net/bugs/552805 | 23:58 |
| fullermd | Well, it's only 3+ years old anyway... | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!