[00:57] <jelmer> hey poolie
[01:16] <poolie> hi jelmer!
[01:16] <poolie> biab
[06:38] <vila> hello all ~
[06:38] <vila> !
[06:50] <poolie> hi vila, jam
[06:51] <jam> morning poolie
[06:51] <jam> and vila
[06:51] <poolie> hi jam
[06:55] <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:57] <jam> vila: the last pqm email I see is Sept 7th.
[06:58] <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
[07:01] <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:05] <vila> mgz: np, I just pinged mthaddon anyway.
[07:05] <vila> mgz, poolie, jam: _o/
[07:11] <mgz> I don't understand bug 871386
[07:12] <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:13] <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:15] <jam> hakermania: you want to create a new series, I think
[07:16] <vila> poolie: you're PP this week ;)
[07:17] <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:18] <jam> The direct link would be: https://launchpad.net/wallpaper-changer/+add-series
[07:19] <poolie> thanks vila
[07:20] <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:21] <poolie> well, i did a decent number of reviews so far today
[07:22] <vila> poolie: haven't checked my mail yet
[07:22] <vila> or rather, all of my mail ;)
[07:27] <poolie> but thanks for the review
[07:27] <poolie> s//reminder
[07:30] <Riddell> morning
[07:31] <mgz> morning Riddell!
[07:33] <poolie> good morning riddell, mgz
[07:37] <vila> Riddell: hey
[07:37] <vila> jam: I thought you targeted bzr.dev but your proposal for request retry are against 2.1 ?
[07:38] <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:42] <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:43] <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:44] <vila> mgz fights with one submission but ended up with an error even with all tests passing
[07:45] <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:47] <jam> hakermania: I didn't see it ealier, just a sec
[07:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:57] <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:59] <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.
[08:08] <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:10] <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:11] <jam> hakermania: there are also "milestones" which is a single snapshot of a release series
[08:12] <hakermania> jam, let me try some things.
[08:14] <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:15] <poolie> vila, 'to start with' towards counting successes?
[08:26] <vila> poolie: yes
[08:26] <vila> poolie: and getting some idea about the rythm
[08:32] <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:34] <jam> hakermania: note we do both in bzr: https://launchpad.net/bzr/+series
[08:34] <jam> we have a stable *series* of releases
[08:36] <hakermania> jam, i see, what's the difference of a milestone and a release? What's a milestone?
[08:37] <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:42] <hakermania> poolie, o.O
[08:46] <mgz> hm, that wasn't the best worded commit message ever, sorry jelmer.
[08:55] <vila> poolie: raw numners: http://paste.ubuntu.com/705308/ except for some spikes it's ~200/day
[08:55] <vila> numbers
[08:57] <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.
[09:02] <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:03] <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:06] <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:07] <hakermania> how do I "mark releases from there from time to time"
[09:07] <hakermania> ?
[09:10] <vila> hakermania: on the milestones only
[09:10] <jml> In lp:udd, does AllQueue.next_job loop on packages forever?
[09:11] <jml> I'm guessing not, but I can't quite tell
[09:12] <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:13] <__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:15] <__bsm__> Any suggestions how to tell bzr it is text file?
[09:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <vila> hakermania: yup, that's what lp is good at, helping people collaborate around projects
[09:29] <vila> hakermania: https://code.launchpad.net/bzr may help you get the picture for bzr too (which branches are associated with which series)
[09:31] <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:32] <poolie> night all
[09:33] <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:34] <vila> hakermania: that's your real name reported by xchat
[09:35] <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:36] <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:37] <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:39] <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:40] <vila> hakermania: your call, just mentioning ;)
[09:41] <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:44] <vila> hehe, I know the feeling :) Yeah, it looks ok (but since I have to write access here, the display is slightly different)
[09:45] <__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:46] <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:47] <__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:49] <vila> hakermania: yup to all :)
[09:50] <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:51] <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:52] <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:53] <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:54] <__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:55] <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:56] <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:57] <jml> heh heh
[10:00] <idnar> heh
[10:00] <jml> vila: do we have Python 2.5 on udd production?
[10:05] <vila> jml: in addition to 2.6.5 you mean ?
[10:05] <jml> vila: what I really mean is, 'can I use "with"?'
[10:06] <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:07] <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:08] <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:09] <vila> jml: the other ~related point is to use name tuples or something for the rows, but one step at a time
[10:11] <mgz> vila: did you get mail about the landing on 2.4 from PQM? at least the merge worked.
[10:13] <jml> vila: yeah.
[10:13] <vila> mgz: not checked yet, but babune is busy
[10:14] <mgz> the big problem is fixed at least, so that's fine
[10:15] <vila> checked, got a bazaar-commit mail from pqm \o/
[10:16] <mgz> okay, so the rt really can be closed now, good good.
[10:17] <mgz> and we'll have a happy fullermd as a side effect.
[10:19]  * vila nods
[10:19] <vila> and an additional heartbeat
[10:21] <vila> mgz: so you changed your mind about test = self ?? It *was* a class attribute
[10:22] <vila> mgz: or would you have preferred an __init__ attribute (which unfortunately cannot be done) ?
[10:29] <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:32] <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:33] <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:34] <mgz> it keeps a scoping a little clearer, and avoids test->class->test->...
[10:36] <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:37] <vila> or is it that it will help your cycle detection stuff ?
[10:39] <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:40] <vila> so we need testcase = None in addition...
[10:41] <mgz> meh, that's an annoyance of overrideAttr we should fix
[10:42] <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:43]  * vila nods
[11:15] <jml> vila: udd cleanup branch up at https://code.launchpad.net/~jml/udd/clean-up-scripts/+merge/78816
[13:29] <vila> jml: not really reviewed but I have some questions
[13:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <vila> it (the url) says don't give a '.py' to scripts, which I agree with
[13:41] <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:42] <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:44] <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:45] <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:46] <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:47] <jml> Hmm.
[13:47] <jml> Well, I don't see how you can safely accept *any* change then.
[13:48] <vila> oh
[13:48] <vila> that's because you don't see the goats
[13:49] <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:50] <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:51] <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:52] <vila> for new packages I think it's still needed, but the corresponding job updates the db and mass_import query it (IIUC)
[13:53] <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:54] <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:55] <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:56] <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:57] <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:59] <jml> vila: I guess so.
[14:03] <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:04] <jml> vila: and it's the same naming structure
[14:04] <vila> that's an honest answer, I like that ;)
[14:05] <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:06] <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:07] <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:08] <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:09] <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:10] <jml> vila: no. It's for maintaining a database locally.
[14:12] <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:13] <jml> vila: thanks.
[14:14] <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:15] <jml> vila: lifeless warned me against that.
[14:45] <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:55]  * mgz looks
[14:55] <mgz> that's an optical illusion
[14:56] <mgz> in the str case, it gives whatever bytes your terminal gave it, which is utf-8
[14:57] <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:58] <mgz> and the escape sequence \xa3 is just a shorter way of saying \u00a3
[15:00] <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:04] <mgz> I've got a bunch of hacks I use when working with text in a python repr
[15:05] <mgz> to save this kind of confusion when looking at reprs
[15:05] <mgz> ^*repl
[15:06] <mgz> Python 3 has a repr that doesn't backslash escape printable unicode characters, and as of 3.3 even mostly works correctly
[15:07] <mgz> then you get into other kinds of unicode hot water though :)
[15:08] <Riddell> whee
[16:44] <daveb_> so, how can I merge, just a subset of commits?
[16:44] <daveb_> and then merge the rest later?
[19:21] <hakermania> vila, heh, im back from the 6-hours-lesson I had -_- I'd stack to what *tagging* is...remember?
[19:37] <lifeless> wgz: hi
[19:38] <lifeless> wgz: btw check out testresources.FixtureResource
[19:38] <lifeless> wgz: its the shim I was talking about
[20:46] <pfsmorigo> hi, how do I revert all changes in a directory locally?
[20:47] <nigelb> bzr revert
[20:48] <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:49] <nigelb> That's beyond wat[B
[20:49] <nigelb> pfsmorigo: That's beyond what I know :)
[22:13] <theDUBBER> www.thedubber.altervista.org
[23:28] <poolie> hi jelmer, hi all
[23:31] <Riddell> morning poolie
[23:32] <poolie> hi
[23:40] <jelmer> hi Riddell, poolie
[23:41] <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:48] <jelmer> poolie: I started with it, but it's not trivial since bzr-builder relies on current quilt
[23:49] <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:50] <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:51] <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:52] <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:55]  * fullermd frowns.
[23:55] <fullermd> When did -x stop working?
[23:56] <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:57] <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:58] <fullermd> Mmm.  bug 268135 and bug 552805 at least...
[23:59] <fullermd> Well, it's only 3+ years old anyway...