[00:57] hey poolie [01:16] hi jelmer! [01:16] biab [06:38] hello all ~ [06:38] ! [06:50] hi vila, jam [06:51] morning poolie [06:51] and vila [06:51] hi jam [06:55] anybody managed to land something recently ? mgz and I believe rt #48346 has broken pqm [06:55] for values of recently starting at last Friday [06:57] vila: the last pqm email I see is Sept 7th. [06:58] so at least those emails have been broken [06:58] jam: yup, me too (see rt), first root cause. But then bzr-email was.... upgraded/reconfigured and now the submissions are failing [07:01] morning all [07:01] ha crap, I thought mgz commented on the rt, looks like he failed to connect there then [07:01] I didn't comment, no [07:05] mgz: np, I just pinged mthaddon anyway. [07:05] mgz, poolie, jam: _o/ [07:11] I don't understand bug 871386 [07:11] Launchpad bug 871386 in Bazaar "recipe fails to build" [Undecided,Incomplete] https://launchpad.net/bugs/871386 [07:12] 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] so maybe it's a bzr-git or submodules or something else problem [07:13] 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] 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] hakermania: you want to create a new series, I think [07:16] poolie: you're PP this week ;) [07:17] jam, How will I? [07:17] hakermania: what's the project? I'll try to give you URLs [07:17] jam, https://launchpad.net/wallpaper-changer Thanks! [07:17] hakermania: if you go to that page, and look at the timeline, underneath it should be a "Register a series" [07:18] The direct link would be: https://launchpad.net/wallpaper-changer/+add-series [07:19] thanks vila [07:20] poolie: there are still a couple of reviews I should finish, already on it [07:20] jam, well, and now I'll give it the same name and info but next version number? [07:20] reminder for packagers and installer builders: 2.5b2 has been frozen !! [07:21] well, i did a decent number of reviews so far today [07:22] poolie: haven't checked my mail yet [07:22] or rather, all of my mail ;) [07:27] but thanks for the review [07:27] s//reminder [07:30] morning [07:31] morning Riddell! [07:33] good morning riddell, mgz [07:37] Riddell: hey [07:37] jam: I thought you targeted bzr.dev but your proposal for request retry are against 2.1 ? [07:38] proposalS even [07:38] vila: everything is currently targetted to 2.1 because that will give clean diffs [07:38] I don't plan on landing that before updating it to target bzr.dev [07:38] ha, thanks for confirming [07:38] we can't land anything currently anyway [07:42] jam, eliz just wrote about bzr pulls from savannah timing out after an hour [07:42] could there be anything in bzr related to that? [07:42] poolie: I'm pretty sure savannah said that they explicitly timeout the inetd stuff at 1 hour [07:42] I could be wrong [07:43] but I remember in the bug discussion that savannah was unhappy about idle connections [07:43] because they wanted to limit to something like 40 active conns [07:43] vila: 6202 Patch Queue Manager 2011-10-06 [merge] [07:43] Is the last merge I've seen [07:43] so nothing in trunk since friday [07:43] yup [07:44] mgz fights with one submission but ended up with an error even with all tests passing [07:45] 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] hakermania: I didn't see it ealier, just a sec [07:48] hakermania: name is the name of the series, so in your case, I think you want "2.2" [07:48] summary can be whatever you want, it is meant to describe the series [07:48] and 'branch' is whatever branch you want to be the 2.2 series branch. [07:48] this may just be your development branch [07:48] but you may have a separate release branch [07:48] the way *bzr* does it, is that we have 'trunk' where active development is done [07:48] which then gets periodically snapshotted into a stable branch [07:49] Riddell: hi, shall we have a chat? [07:49] do you want me to reopen your email rt then vila on the basis that might have borked pqm? [07:49] poolie: ok, mumble? [07:49] sip? [07:49] sip doesn't like me :( [07:50] mgz: I tried to re-open but I don't have enough rights :-/ [07:50] ...maybe just file a new one? [07:50] mgz: addind your data there and adding you as a CC should still be possibl [07:50] e [07:50] mgz: it is still funny to see your full name :) [07:51] I'm tracking mthaddon in #launchpad-ops anyway, you can job the chase if you want ;) [07:51] ehehe, yes jam I'm still adjusting to it myself [07:51] not used to seeing your own name? [07:52] ...it showing up in commit messages, not the name itself, I've had long enough with it now. [07:52] :) [07:52] 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] hakermania: you are looking for 'development focus' ? [07:52] mgz: mthaddon is there, join us [07:53] 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] 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] 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] 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] 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] hakermania: there are also "milestones" which is a single snapshot of a release series [08:12] jam, let me try some things. [08:14] 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] vila, 'to start with' towards counting successes? [08:26] poolie: yes [08:26] poolie: and getting some idea about the rythm [08:32] 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] about the middle of the page [08:32] cool [08:32] you can delete the series [08:34] hakermania: note we do both in bzr: https://launchpad.net/bzr/+series [08:34] we have a stable *series* of releases [08:36] jam, i see, what's the difference of a milestone and a release? What's a milestone? [08:37] a milestone that has been released has a release [08:37] a milestone that's in the future is just a milestone [08:42] poolie, o.O [08:46] hm, that wasn't the best worded commit message ever, sorry jelmer. [08:55] poolie: raw numners: http://paste.ubuntu.com/705308/ except for some spikes it's ~200/day [08:55] numbers [08:57] hakermania: a milestone is a projected future release [08:57] "I will release 2.3 in February next year" [08:57] Oh, that's what I need :D [08:57] and these are the bugs I want to fix in it, etc. [09:02] 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] hakermania: *bzr* pushes revisions to trunk [09:03] jam, which means :O? [09:03] you never push revisions to milestones [09:03] and you weren't doing it before [09:03] 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] so I'm not sure what you want it to be doing [09:06] 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] What's the right way to do it? [09:06] right, you'll generally just push stuff to 'trunk', and then mark releases from there from time to time [09:07] how do I "mark releases from there from time to time" [09:07] ? [09:10] hakermania: on the milestones only [09:10] In lp:udd, does AllQueue.next_job loop on packages forever? [09:11] I'm guessing not, but I can't quite tell [09:12] 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] hakermania: yup, you get the idea [09:16] vila, jam, thanks for the help, I have to keep these info somewhere now because till the release I'll forget :P [09:17] hakermania: hehe, the trick I use for bzr itself, is to create milestones ahead of time with rough estimate dates [09:17] 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] hakermania: as the expected release date approaches, I refine the dates [09:18] TimMiao: how did you install it? [09:18] hakermania: also the https://launchpad.net/bzr/+milestones page is a rough planning that helps me keeping track of what is coming [09:19] 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] 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] 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] vila, and 'released' goes to? PPAs? [09:21] hakermania: yup, you can't release without a milestone but you can create the milestone ahead of time [09:22] hakermania: out of scope [09:22] 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] vila, :P But 'released' means that a new version is available. Is it up to me the 'where'? [09:22] hakermania: yes [09:23] hakermania: for bzr, for example, once the release is created, I upload the source tarball [09:23] TimMiao: sorry i don't know much about macs [09:23] hakermania: I then tell the packagers and installer builders to go ahead from there [09:23] is there no system uninstall facility? [09:23] suggest you search for the 'bzr' executable and 'bzrlib' directory [09:23] poolie: thank you [09:23] vila, how do you get someone to build the package for you? I do all the job myself :P [09:24] hakermania: hehe, we have some really fine people around ;) [09:24] hakermania: if you look at https://launchpad.net/bzr/2.5/2.5b2 (our latest release to date) [09:25] hakermania: you'll see the tarball and the windows installers [09:25] hakermania: I uploaded the tarball last Thursday, jam uploaded the windows installers a couple of hours ago [09:25] hakermania: the mac installer will probably follow [09:26] vila, I see. [09:26] 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] hakermania: the release stuff here is really targeted at upstream releases [09:27] vila, so it's up to cooperation [09:27] 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] hakermania: yup, that's what lp is good at, helping people collaborate around projects [09:29] hakermania: https://code.launchpad.net/bzr may help you get the picture for bzr too (which branches are associated with which series) [09:31] 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] night all [09:33] hakermania: you're 'purple' ? It's hard to keep context with all you nicks ;) [09:33] s/you/your/ [09:33] bah, the second one [09:33] vila, puple? what? I'm hakermania [09:33] Do you see me as 'purple'? [09:34] hakermania: that's your real name reported by xchat [09:35] weird, I've registered this nickname(hakermania), from now on consider purple==hakermania = true [09:35] hakermania: may be just a coincidence... but I seem to remember a pur... ok [09:36] 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] hakermania: and the PPA may be able to use recipes so the builds occur automatically [09:37] hakermania: you also define different PPAs for daily, beta and stable and have different policies to populate them [09:37] s/you also/you can also/ [09:37] or may :) [09:39] 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] Every version has its own folder, its own readme file, it's good. [09:40] hakermania: your call, just mentioning ;) [09:41] vila, Does it look good: https://launchpad.net/wallpaper-changer/trunk ? After the code's stable I release the milestone? ALl OK? [09:41] I'm anxious about it a little bit :/ [09:44] 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] hakermania: you probably have a (+) Release now button for 2.2 that I don't see myself [09:45] vila, I do [09:45] hakermania: you're all good then I think [09:46] __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] 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] hakermania: yup to all :) [09:50] vila, perfect [09:50] hakermania: you probably want to *tag* your release too [09:50] vila, what's this :P [09:50] hakermania: as there is no other explicit way to find the revision corresponding to a milestone that I know of [09:51] hakermania: bzr tag wallpaper-changer (bzr help tag, bzr help tags for details) [09:51] hmm. [09:51] has anyone run "branch_branches_from_lp" in a while? [09:51] because it looks broken in trun [09:51] k [09:51] vila, oh yes, that would be nice. [09:51] hakermania: ghaa, 'bzr tag wallch-2.2' or something [09:52] vila, do I run this before the last push that corresponds to the new release? [09:52] hakermania: exactly [09:52] hakermania: or not [09:52] hakermania: you tag an older revision [09:53] vila, so first I push the code, then tag it... [09:53] hakermania: you *can* tag an older revision [09:53] hakermania: no, it's better to tag it first [09:53] 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] jml: sorry, where is this function ? [09:54] 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] vila: it's a script. [09:54] vila: in the top-level [09:54] jml: of ? udd ? lp ? bzr ? [09:55] vila: I'm just doing a branch now that moves the code out of those scripts into udd/scripts/ [09:55] vila: of udd, sorry [09:55] ha [09:55] jml: rings no bell as you can see :) Let me have a look [09:55] vila: basically, it says distribution_name in a function where it should say distribution.name [09:55] vila: but comments say the script is used mostly for debugging [09:55] the initial comment says "debug purposes" [09:56] yeah. [09:56] I'm guessing james_w hasn't needed to debug stuff for a while :) [09:56] jml: qblame says maxb only, may suffer from bitrot :) [09:56] yeah. [09:56] the script, not max [09:57] heh heh [10:00] heh [10:00] vila: do we have Python 2.5 on udd production? [10:05] jml: in addition to 2.6.5 you mean ? [10:05] vila: what I really mean is, 'can I use "with"?' [10:06] 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] s/use wip/use with/ [10:07] vila: oh cool. [10:07] vila: I was thinking of doing the same thing [10:08] jml: :) I'd like to add the smallest set of tests I can find to go with it [10:08] vila: oh [10:08] vila: that's a drag. [10:09] jml: the other ~related point is to use name tuples or something for the rows, but one step at a time [10:11] vila: did you get mail about the landing on 2.4 from PQM? at least the merge worked. [10:13] vila: yeah. [10:13] mgz: not checked yet, but babune is busy [10:14] the big problem is fixed at least, so that's fine [10:15] checked, got a bazaar-commit mail from pqm \o/ [10:16] okay, so the rt really can be closed now, good good. [10:17] and we'll have a happy fullermd as a side effect. [10:19] * vila nods [10:19] and an additional heartbeat [10:21] mgz: so you changed your mind about test = self ?? It *was* a class attribute [10:22] mgz: or would you have preferred an __init__ attribute (which unfortunately cannot be done) ? [10:29] The world is better for everyone when fullermd is happy. [10:29] Well, for me anyway. Which is close enough to "everyone" as far as I'm concerned... [10:32] vila: I thought self.overrideAttr(InnerClass, "testcase", self) was the best option I think [10:32] given you couldn't put it on the instance [10:33] ha ! That one. [10:33] hmm, a bit weird to use overrideAttr for a class that is embedded in the test itself though [10:34] it keeps a scoping a little clearer, and avoids test->class->test->... [10:36] 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] or is it that it will help your cycle detection stuff ? [10:39] yep, you need the gc to clean up the test if you leave a copy of self on an inner class [10:39] mgz: bah, doesn't work: AttributeError: class FailingDuringResponseHandler has no attribute 'testcase' [10:40] so we need testcase = None in addition... [10:41] meh, that's an annoyance of overrideAttr we should fix [10:42] but I wouldn't worry about changing that now vila [10:42] 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] vila: udd cleanup branch up at https://code.launchpad.net/~jml/udd/clean-up-scripts/+merge/78816 === medberry is now known as med_out [13:29] jml: not really reviewed but I have some questions [13:30] of course [13:30] jml: I posted them, but we can discuss here, [13:30] vila: ok. I'll pull up the page. [13:31] 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] vila: sorry, I don't quite understand [13:32] 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] jml: which part ? [13:32] vila: they aren't empty. I've mostly bzr moved the things out of the tree into a package [13:32] vila: and then created near-empty scripts that call them [13:32] oh, maybe that's what you meant [13:32] yes [13:33] the mostly empty ones are... why do we need them ? [13:33] vila: well, it's either that or use entry points and buildout [13:33] buildout ? [13:33] vila: you need something to execute [13:33] vila: executing python scripts that are inside packages is yuck. [13:33] ha [13:33] oh [13:34] 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] 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] vila: but I don't want to change the interface in this branch [13:34] vila: yeah, but no one likes using them [13:34] oh [13:35] vila: e.g. 'python -m testtools.run ' [13:35] *blech* [13:35] hmm, the one I had in mind was... unittest ? [13:35] vila: yeah, it's the same [13:35] vila: these things are scripts, the public interface should look like any executable [13:36] hmm [13:36] vila: the advantage of having very small executable Python scripts is that you don't have to test them. [13:36] 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] vila: and also, if we want to merge some of the Python modules, we can [13:37] right [13:37] move code out of udd.scripts.list_packages into udd.icommon for instance [13:37] this is, in some ways, an intermediate refactoring. [13:37] intermediate step then but both trends go in the same direction [13:37] hehe, yeah [13:37] yeah. [13:38] oh right [13:38] then the logic becomes clearer but they don't deserve to go under udd/scripts then, they should just go under udd [13:39] 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] vila: well... [13:39] ha, let me read that [13:39] vila: I guess so. Some of them are very scripty. [13:40] it (the url) says don't give a '.py' to scripts, which I agree with [13:41] can be done separately but we may need a TODO to keep track [13:41] bah, and the REAME is bit-rotting too [13:41] yeah. [13:42] We can file bugs, or I can just do the *.py thing right now. [13:42] But I don't want to do that before this branch lands. [13:44] 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] vila: ah yes. [13:44] vila: well, of course, the thing is that the old code wasn't testable either. [13:44] * vila nods [13:44] but I said anybody :) [13:45] vila: making a change like this is necessary to making them testable [13:45] this stuff works, not the same as testable, but still a valuable kind of test [13:45] vila: and even if, say, I added a bunch of tests, we wouldn't be guaranteeing against regressions [13:45] because I'd just be making up what I thought the behaviour should be :) [13:45] it will help yes, I agree, my issue is how can I safely accept this [13:45] hmm. [13:45] hehe [13:46] Well, we could run the scripts. [13:46] If you have a staging environment, we could try that [13:46] bah, not even, the only staging (local) one I have cannot write to lp (or chaos is around the corner) [13:47] Hmm. [13:47] Well, I don't see how you can safely accept *any* change then. [13:48] oh [13:48] that's because you don't see the goats [13:49] vila: heh [13:49] jml: more seriously, did you run them locally, which ones ? [13:49] vila: no, I haven't yet. [13:49] vila: the changes are self-evidently correct :P [13:49] (I'll run them now) [13:49] except, ugh, I'm *still* part-way through my database run. [13:50] jml: can you do that, tell me the ones you didn't and I'll aprove, land, deploy and see what breaks [13:50] argh [13:50] jml: my rough estimates for the importer is that it takes 36 hours before starting again [13:51] jml: depending on what you really do as an import, this could of course be far shorter [13:51] vila: does it just loop forever? [13:51] mass_import ? Yes ! [13:51] vila: as in, it goes through all packages again once it's done? [13:51] it runs unattended [13:51] yes [13:51] vila: I thought it needed constant fuelling from new cronjob runs. [13:52] for new packages I think it's still needed, but the corresponding job updates the db and mass_import query it (IIUC) [13:53] hmm [13:53] looking at one of your scripts, importing 'main' ? Why not a more descriptive name ? [13:53] Because it *is* descriptive? [13:54] main ? For a script yes, but if we intend to merge this script-wanting-to-be-part-of-packages, less [13:54] then we can rename it when we do that merging? [13:55] fair enough ;) [13:55] 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] oh [13:55] I thought about making the importer a bzr plugin if you really want to know ;) [13:56] vila: yeah, I thought about it too [13:56] vila: but then I realized you'd need sub-sub-commands. [13:56] there was too much stuff in the scripts to tackle it safely though ;) [13:56] for what ? [13:56] vila: bzr udd list-packages [13:56] I guess you could just have a prefix or something [13:57] oh, I thought about bzr list-packages directly, it's not as if this will be distributed widely [13:57] but it could also be udd-list-packages, there is not much to share into the udd command [13:57] not use [13:57] nor use [13:59] vila: I guess so. [14:03] jml: but jokes aside, why not make a builtin.py and indeed rename the mains into cmd_xxx ? [14:03] jml: not making it a plugin doesn't mean we can't use some naming conventions ahead of time [14:03] so many negatives >-/ [14:03] vila: mostly because that's more work [14:04] vila: and it's the same naming structure [14:04] that's an honest answer, I like that ;) [14:05] udd.scripts -> udd.builtins; module_name -> cmd_module_name; main -> run [14:05] not even the run part for now [14:05] With the bonus of having to disentangle naming clashes from the existing scpts. [14:05] scripts. [14:05] keep the separate modules [14:05] bah, don't answer [14:06] no, I understand [14:06] but a TODO explaining the road ahead still sounds easy and valuable [14:06] OK. I'll do that. [14:06] great [14:07] let me know when you managed to run them locally as smoke tests and which ones are left to test, [14:07] from there I can land.deploy and be ready [14:08] Thanks. [14:08] 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] vila: oh, it doesn't have to be private [14:09] vila: I'm downloading source packages and extracting the *.symbols files from them [14:09] and you upload nothing ? [14:10]