| === medberry is now known as med_out | ||
| === AuroraBorealis is now known as aurora|afw | ||
| === med_out is now known as medberry | ||
| === medberry is now known as med_out | ||
| === yofel_ is now known as yofel | ||
| vila | hi all ! | 07:00 |
|---|---|---|
| poolie | hi there, nice to see you! | 07:01 |
| poolie | i'm just reviewing your possible_transports patch | 07:01 |
| vila | oh great ! | 07:02 |
| poolie | done | 07:04 |
| poolie | wow look at all these patches | 07:04 |
| mgz | morning! | 07:05 |
| poolie | hi mgz | 07:05 |
| vila | mgz: _o/ | 07:07 |
| vila | poolie: 'feel free to land with post review' ? I can't parse that, especially the 'with post review' part ;) | 07:09 |
| poolie | ah i mean | 07:09 |
| poolie | you don't need to wait for review | 07:09 |
| vila | oh | 07:09 |
| poolie | i do appreciate you making an mp, so people can see the diff | 07:09 |
| vila | yeah, I intended to deploy it but wanted to chit-chat with jml... can't remember exactly why though :) | 07:10 |
| vila | ha, good analyze-log script :) 22h20 is how long it takes to catchup the imports for chromium-browser (still failing though) | 07:13 |
| vila | ha crap, jml refactoring broke *all* scripts, the modules are not found anymore | 07:17 |
| poolie | yeah i see | 07:17 |
| mgz | yeah, I wondered about that yesterday when trying to run the importer locally | 07:17 |
| poolie | but i thought they were all already on jubany | 07:17 |
| poolie | i checked it was up to date with trunk the other day | 07:18 |
| vila | thinking he was the one infecting me with TDD ;) | 07:18 |
| poolie | but perhaps they had not yet been merged | 07:18 |
| mgz | moving the script out of the base dir means "udd" is no longer on the path | 07:18 |
| mgz | so you can't run without installing (or setting PYTHONPATH or something) | 07:18 |
| vila | mgz: exactly but not only, jquery.flot.js not found too | 07:18 |
| vila | I just created bin/udd -> ../udd but that's not enough | 07:19 |
| vila | (not to mentioned hackish ;) | 07:19 |
| mgz | ehee, that's even worse than most symlink hacks :) | 07:19 |
| vila | ok, I'll revert it and comment on the mp, too much to fix without guarantee I get them all | 07:21 |
| mgz | could revert that change for now, and only land it w... | 07:21 |
| mgz | ...hen there's a setup.py script to go with it | 07:21 |
| vila | :) | 07:21 |
| vila | oh, setup.py, worth thinking about it | 07:21 |
| vila | but we run from source and it's also a useful thing | 07:22 |
| vila | bah, let's try a bit harder, reverting is not trivial either and is going in the wrong direction anyway | 07:23 |
| poolie | vila, mgz, i think it's just us this week so we could talk whenever you like | 07:23 |
| vila | comfy :) | 07:24 |
| vila | Riddell is not here either ? | 07:24 |
| poolie | i might be confused but i thought he was going to be en route to uds this week? | 07:33 |
| vila | hmm, by boat ? :-D | 07:33 |
| poolie | exactly, kayak | 07:34 |
| vila | wow | 07:34 |
| poolie | not really | 07:34 |
| vila | hehe | 07:36 |
| vila | ok, some sanity restored, categorise-failures works | 07:39 |
| vila | etc scripts 101: you can't remove PATH or you won't do a lot | 07:41 |
| poolie | gz you're in ~bzr-explorer-dev now | 08:31 |
| mgz | poolie: cool, will land that branch | 08:47 |
| poolie | feel free to also add a <land it!> button to lp! :) | 08:47 |
| poolie | i'm seriously tempted to do it myself | 08:48 |
| mgz | vila: so, if you could walk me through what to do to deploy the latest bzr-builddeb in jubany and requeue one of the failing packages some time today | 08:48 |
| vila | mgz: sure thing ! | 08:49 |
| mgz | poolie: but doing it manually is such fun... | 08:49 |
| vila | I've just fixed the last glitch and the importer is running again | 08:49 |
| vila | I'm waiting a bit before calling it a win ;) | 08:50 |
| vila | ... and stopping it before requeuing chromium-brower... | 08:50 |
| vila | so, let's deploy builddeb as soon as you're ready | 08:51 |
| mgz | I'm guessing the procedure is basically stop importer, pull, start, then... tell it what package somehow? | 08:51 |
| vila | yup | 08:51 |
| vila | so, first thing, read README_DEPLOYMENT to make sure it's accurate | 08:51 |
| mgz | which lives...? | 08:52 |
| vila | in lp:udd :) | 08:52 |
| vila | with a symlink also in place in pkg_import@jubany:/srv/package-import.canonical.com/new/scripts | 08:52 |
| mgz | okay, that tells me the dir. | 08:53 |
| vila | mgz: you know how to connect there ? | 08:53 |
| mgz | yep, I'm there | 08:53 |
| vila | via ssh + sudo su - pkg_import ? | 08:53 |
| vila | k | 08:53 |
| vila | hmm './' is probably missing in front of the etc-init.d-mass-import examples | 08:54 |
| vila | can you confirm that ? | 08:54 |
| mgz | yup. | 08:54 |
| vila | ok, fixed locally (I'll take the notes, you do the work ;) | 08:55 |
| mgz | and in fact, when I stopped it last time, used the script in /etc/init.d/ | 08:55 |
| vila | we should resync them but better use the one in the branch | 08:56 |
| mgz | which is I guess just the same thing, or an older copy, or a symlink | 08:56 |
| vila | an older copy | 08:56 |
| vila | you haven't stopped it yet right ? | 08:56 |
| mgz | yup, has the wrong path | 08:56 |
| vila | use graceful-stop | 08:56 |
| mgz | not stopped yet. | 08:56 |
| vila | k | 08:56 |
| mgz | doing now | 08:56 |
| vila | yup seeing it | 08:57 |
| vila | oh, I should mention that, | 08:57 |
| mgz | how do you monitor a running importer? | 08:58 |
| vila | I usually have 3 connections to jubany: | 08:58 |
| vila | oh failure ! | 08:58 |
| vila | crap dpkg-mergechanglogs is not in PATH anymore | 08:59 |
| vila | stopped nevertheless | 08:59 |
| mgz | there's an old import_package.pyc and .py~1~ in here for some reason... | 09:00 |
| vila | mv dpkg-mergechangelogs bin/ should take care of that but we need a more formal way to track it | 09:00 |
| vila | someone did a revert probably | 09:00 |
| vila | back to monitoring: | 09:00 |
| mgz | tail some log? | 09:01 |
| vila | 1) tail -F logs/driver/progress_log | 09:01 |
| vila | 2) crap, broken now, just a sec | 09:02 |
| vila | 2) export PYTHONPATH=${HOME}/src/udd/trunk ; (ssh -AY jubany.canonical.com tail -F /srv/package-import.canonical.com/new/logs/driver/progress_log) | ~/src/udd/trunk/bin/analyze-log - | 09:03 |
| vila | 3) in .../scripts: '. ./fixit.sh' to get some shorcuts and setup the env | 09:04 |
| mgz | okay. | 09:04 |
| mgz | so, is lp:udd in a usable state now? should I pull in the latest bzr-builddeb? | 09:05 |
| vila | lp:udd is deployed, so, yes, pull the latest builddeb, check that no uncommitted changes are there though | 09:06 |
| mgz | will do. | 09:06 |
| mgz | one shelve. :) | 09:07 |
| vila | yeah, looking at it ;) | 09:07 |
| vila | it's an old one, should be safe to delete but doesn't hurt to keep it until we fix the dpkg-mergechangelog for good | 09:07 |
| mgz | okay, that's got the fix in question | 09:08 |
| mgz | start time? | 09:08 |
| vila | yup | 09:08 |
| vila | started ok | 09:10 |
| vila | notice that it says ' Read 4 in /srv/package-import.canonical.com/new/max_threads' | 09:10 |
| vila | I changed from the default 8 while debugging the scripts issues | 09:11 |
| mgz | so, how are you running the scripts in bin? I need to do requeue-package next | 09:11 |
| mgz | ^right | 09:11 |
| vila | I use '. ./fixit.sh' first | 09:11 |
| mgz | k | 09:11 |
| vila | it provides 'requeue' as a shorcut to requeue-package | 09:11 |
| mgz | done. | 09:12 |
| vila | failure | 09:12 |
| mgz | I see it. | 09:12 |
| vila | run 'categorise-failures' to force the status page generation | 09:12 |
| mgz | stop importer first? | 09:13 |
| vila | yup | 09:13 |
| vila | err | 09:13 |
| vila | no they are independent | 09:13 |
| vila | it's useful when you don't want to wait for the crontab to run it | 09:13 |
| vila | every 5 minutes (see importer.crontab in lp:udd) | 09:14 |
| mgz | done | 09:14 |
| mgz | all looks like the same issue in import_dsc | 09:14 |
| vila | but you can stop the importer too as the failure seem to spread | 09:14 |
| vila | you'll be able to requeue all the related failures by doing 'requeue --all <one-package-that-failed>' | 09:15 |
| vila | good thing I didn't requeue chromium :) | 09:15 |
| vila | one sucessful import still ;) | 09:16 |
| mgz | looking for blame. | 09:16 |
| vila | hehe | 09:16 |
| vila | now, the usual choice is to either revert to a known-working rev and restart or fix before restarting | 09:17 |
| vila | it's ok to fix locally and only then do a merge proposal because the importer is stopped and we don't want to accumulate too much stuff | 09:18 |
| mgz | probably in lp:udd | 09:18 |
| mgz | hm, nope, the singular->plural was a builddeb change | 09:22 |
| mgz | vila: bzr diff to see possible fix | 09:23 |
| vila | +1 | 09:24 |
| mgz | starting | 09:24 |
| mgz | will let a few go past before requeuing | 09:24 |
| vila | oh, I couldn't commit on jubany last time I tried and didn't investigate a workaround (just so you won't be surprised) | 09:24 |
| vila | nope, try requeuing one that failed instead | 09:25 |
| vila | with: | 09:25 |
| vila | requeue --priority paraview | 09:25 |
| vila | --priority will ensure it's run asap | 09:25 |
| mgz | done | 09:27 |
| vila | if you run categorize-failures now it should appear in outstanding jobs | 09:27 |
| mgz | run, but, where am I looking? | 09:28 |
| vila | oh, that was related to multiple tarballs, we should check with jelmer telling him we've deployed that | 09:29 |
| vila | which one did you requeue ? | 09:29 |
| mgz | paraview, was the last one in the log | 09:29 |
| vila | oh, sorry, that generates the status page | 09:29 |
| mgz | currently pending | 09:29 |
| vila | running already | 09:30 |
| mgz | I must be being blind then, didn't see current jobs on status | 09:30 |
| mgz | *running, even, yeah | 09:30 |
| vila | top of the page | 09:30 |
| vila | 4 running | 09:30 |
| vila | 30 outstanding jobs | 09:30 |
| vila | and in the last 50 failures you've got the ones related to extract_upstream_tree | 09:31 |
| mgz | ...I'm now not sure if I needed that refresh or if I was just being blind | 09:31 |
| vila | go with refresh ;) | 09:31 |
| mgz | tail is looking happy. | 09:31 |
| vila | the fact that this page also refreshes itself from time to time doesn't help ;) | 09:31 |
| mgz | will let paraview go through, then requeue the one I wanted and all those that hit that issue | 09:32 |
| vila | yup, that's the idea | 09:32 |
| vila | you'll requeue them with: 'requeue --all polyglot' | 09:33 |
| vila | adding --priority as you see fit | 09:33 |
| vila | --all will requeue all packages that share the same failure signature | 09:33 |
| poolie | ok, i should go, good night | 09:34 |
| mgz | night poolie! | 09:34 |
| vila | poolie: g'night ! | 09:34 |
| mgz | paraview done. | 09:34 |
| vila | \o/ | 09:36 |
| mgz | okay, everything set up I think. | 09:36 |
| vila | bump max_threads to 8 (echo 8 >../max_threads) | 09:36 |
| mgz | done. | 09:36 |
| vila | categorize-failures again to see the effect (or look in the logs) | 09:38 |
| mgz | yeah, following log | 09:38 |
| vila | k | 09:38 |
| vila | I'll requeue the ones related to dpkg-merge... | 09:39 |
| vila | ...and I'll requeue chromium-browser once the outstanding jobs are (will be ?) done | 09:40 |
| vila | ha great lxc fails | 09:40 |
| mgz | ...lock contention on lxc? | 09:40 |
| vila | did you see that ? | 09:40 |
| vila | yup | 09:40 |
| mgz | ...great as in, really was good, or great as in, annoying? | 09:41 |
| vila | in some cases (for yet unknown reasons) an exception manage to escape the finally clause where the lock is released | 09:41 |
| vila | great to explain the issue and how I resolve it (hackish, needs to investigate one day and make it more robust, should probably file a bug) | 09:42 |
| mgz | hey, I think my test package went through okay while I was distracted | 09:42 |
| mgz | how do we see sucesses? (...apart from in the log) | 09:42 |
| vila | to resolve: look at the traceback, it gaves hints about where the lock is still pending, in this case 'precise' | 09:42 |
| vila | you don't, it's a bug I'm working on, let me find the number | 09:43 |
| vila | bug #831699 | 09:43 |
| ubot5 | Launchpad bug 831699 in Ubuntu Distributed Development "no report/log of successful packages" [High,In progress] https://launchpad.net/bugs/831699 | 09:43 |
| vila | so, cd ../updates/lxc/precise | 09:44 |
| mgz | pygobject also had an unhappy lock experience | 09:44 |
| vila | yup, same issue | 09:44 |
| vila | bzr info -v | 09:44 |
| vila | it's a local lock so 'bzr breack-lock' | 09:44 |
| mgz | okay, I'll requeue all the other UnicodeDecodeError packages, and hopefully a couple of them will fail with new nicer errors | 09:44 |
| vila | two locks broken | 09:45 |
| vila | sometimes it's a remote one and I do 'bzr break-lock :push' | 09:45 |
| mgz | libproxy is a different issue | 09:45 |
| vila | two broken locks for pygobject too | 09:46 |
| vila | and requeued | 09:46 |
| vila | rats another failure ;-/ | 09:47 |
| * vila blinks, that's an unknown one | 09:48 | |
| mgz | all unicodedecodeerror packages queued | 09:48 |
| vila | will need to repro locally | 09:48 |
| vila | can you land your fix on lp:udd ? | 09:48 |
| mgz | 51, 10, 5, 3 | 09:49 |
| mgz | ^will do | 09:50 |
| vila | hmm, the lxc failure spreads | 09:50 |
| vila | something changed in the merge hook | 09:51 |
| mgz | yeah seems like it | 09:51 |
| vila | probably worth stopping the importer when all your jobs have passed | 09:52 |
| mgz | huh, it's doing paraview again | 09:53 |
| vila | ha | 09:53 |
| vila | there is a bug there (not filed), some jobs seem to be re-processed for no good reasons | 09:54 |
| mgz | oh, probably because I did requeue --all on a similarly failing package after it had succeeded? | 09:54 |
| vila | nope, it shouldn't it's more obscure than that | 09:54 |
| vila | I've seen jobs being re-processed without being involved in anything recent | 09:55 |
| vila | mgz: mwhahaha, conflicts in bzr-builddeb locally | 10:02 |
| vila | mgz: import pdb; pdb.set_trace() in bzrtools_import.py getmembers :) | 10:02 |
| mgz | hehe | 10:03 |
| vila | I went there trying to diagnose some unicode issue at one point ;) I should have tried harder ;) | 10:05 |
| vila | mgz: did you note the revno before upgrading builddeb on jubany ? | 10:07 |
| mgz | should I just push to lp:udd? | 10:08 |
| mgz | vila: ...no, but I think you told me it yesterday | 10:08 |
| mgz | r613? | 10:08 |
| vila | you rock ! | 10:08 |
| vila | yup 613 | 10:09 |
| mgz | hm, a bunch of these current packages aren't doing anything new | 10:11 |
| mgz | maybe should stop, fix the merge hook issue, then see if I can get some non-utf8 filename failures | 10:12 |
| vila | mgz: yup, I'm trying to reproduce locally with lxc buno success so far | 10:21 |
| vila | s/buno/but no/ | 10:21 |
| vila | mgz: you just got one ! | 10:22 |
| vila | 2 even :) | 10:22 |
| vila | make that 3 | 10:23 |
| vila | of, what's you trick ? ;-P | 10:23 |
| vila | s/of/ok/ | 10:23 |
| vila | s/you/your/ :-( | 10:23 |
| mgz | woho! | 10:24 |
| vila | bah, can't reproduce locally as it's code involved when pushing only ;_/ | 10:24 |
| mgz | what the hell paraview is going through for like the fourth time | 10:24 |
| vila | yeah and outstanding jobs up to 120 (was down to 70) | 10:25 |
| vila | so, categorize_failures requeue some but I suspect some cruft in the db | 10:26 |
| mgz | so, these will be packages with real filename encoding issues: <http://package-import.ubuntu.com/status/08eff66a5fe37a967e2f2b06210cc608.html> | 10:26 |
| vila | real as in ? | 10:26 |
| mgz | as in, not utf-8 | 10:26 |
| vila | will never be able to encode ? | 10:26 |
| mgz | most of the ~70 failures should now pass | 10:27 |
| mgz | and the subset that don't will be listed there | 10:27 |
| mgz | basically, bzr core needs a strategy for handling that edge case, so the package importer failing is reasonable | 10:28 |
| mgz | the only other option would be to have a way of attaching a different encoding to the package metadata if they're using a valid, but non-utf-8, encoding | 10:29 |
| mgz | but I suspect that won't be worthwhile | 10:29 |
| vila | ..and may not be enough (I suspect this should be attached to each file in some cases) | 10:29 |
| vila | libperl5i-perl also enjoys being processed | 10:30 |
| vila | qcomicbook too | 10:30 |
| vila | eerk and libjgrapht0.6-java enve more ! | 10:31 |
| vila | ok, so, this issue is now really bad | 10:31 |
| mgz | I have run categorise-failures several times, will stop doing that | 10:32 |
| vila | down to 69 outstanding jobs, don't run.. yeah me too, let's stop :) | 10:32 |
| vila | there are some basic tests for db now and one FIXME is mentioning something related | 10:33 |
| * vila back to the merge hook issue | 10:33 | |
| vila | ok, I think I got it | 10:36 |
| vila | mgz: two bugs: dpkg-merchangelogs was not in PATH anymore, the merge hook can't find it but returns a single value instead of 2 | 10:41 |
| vila | mgz: we can stop the importer ;) | 10:41 |
| vila | DONE | 10:41 |
| mgz | what happens to the current queue when it's stopped? | 10:42 |
| vila | it's in the db (meta.db JOBS_TABLE) | 10:42 |
| mgz | cool. | 10:43 |
| vila | 4 more failures for you :) | 10:43 |
| vila | err 3 | 10:43 |
| mgz | yep, seeing them | 10:44 |
| mgz | perhaps a latin-1 fallback in the importer wouldn't be so bad. | 10:44 |
| vila | yeah, add an NFD too ;) | 10:45 |
| vila | I forgot which package, but I'm pretty sure there is one with a contrib/docs/xxxx.pdf where xxx is in NFD | 10:45 |
| mgz | heh | 10:45 |
| vila | some db related one | 10:46 |
| mgz | aaaa, that error message is so much nicer | 10:46 |
| mgz | reminds me, I should improve UnicodeError display is bzrlib | 10:46 |
| vila | mgz: bzr diff on builddeb for the fix | 10:47 |
| mgz | have we got a bug for it? we've talked about it before | 10:47 |
| vila | mgz: oh yes please ! | 10:47 |
| vila | I don't think so, | 10:47 |
| vila | but there should a place where all unicode exceptions can be trapped their *args* put to good use | 10:47 |
| vila | i.e. the broken string is args[0] IIRC | 10:48 |
| vila | but it's not displayed by default (strange idea) | 10:48 |
| mgz | diff looks reasonable, is this the right end of the interface to change? | 10:48 |
| vila | I'm 90% sure as it's a recent change and match the error we see | 10:49 |
| mgz | yep, looks more unambiguously correct with more context | 10:50 |
| mgz | goforit | 10:50 |
| vila | hmpf, it was still running :-} | 10:53 |
| mgz | the last job was being slow :) | 10:54 |
| vila | yeah, chromium would have been even slower :) | 10:57 |
| mgz | openclipart... I fear a little for the contents of that branch | 10:57 |
| vila | oh crap, I pushed to lp:bzr-builddeb :-( | 10:57 |
| mgz | quick, uncommit! :) | 10:58 |
| vila | jelmer: so sorry about that :-/ | 10:58 |
| vila | jelmer: the fix is trivial though, shouldn't be a problem ? | 10:58 |
| vila | ETOOMANYBRANCHES | 10:58 |
| vila | mgz: anyway, in this case, 4 fourth terminal with: 'tail -F logs/packages/openclipart' :) | 10:59 |
| mgz | paraview is in the queue again... | 11:00 |
| * mgz switches tails | 11:00 | |
| * vila switches to lunch ;) | 11:06 | |
| vila | mgz: this import looks like it will take some time to finish anyway | 11:07 |
| mgz | :) | 11:07 |
| mgz | I'll restart if I notice it's done before you return | 11:08 |
| vila | mgz: I have some shopping to do after lunch, I'll ping you when I'm back, feel free to play around as you like (my fix needs to be deployed first though) | 11:08 |
| vila | k | 11:08 |
| mgz | ...bzr-builddeb just needs to be pulled, right? | 11:10 |
| vila | taking care about the pending change yes | 11:14 |
| mgz | vila: all done, also requeued the packages with affected by the tuple unpacking issue | 11:50 |
| vila | mgz: yup, still there for a couple of minutes, they fail with lockcontention :-0 | 11:50 |
| mgz | ...but they seem to now all be failing with the lock... | 11:50 |
| vila | probably time to find a better way to addres that :) | 11:50 |
| vila | I'll look into it when I get back | 11:52 |
| vila | delayed again :) | 12:08 |
| vila | huho | 12:23 |
| vila | mgz: panic in the driver we may need to kill hard | 12:24 |
| mgz | woha! | 12:25 |
| mgz | ha, normalisation kills the world | 12:26 |
| mgz | did a hard stop | 12:27 |
| vila | mee too :-/ But it seems I'm still receiving output from tail -F | 12:27 |
| mgz | there was a *lot* | 12:28 |
| mgz | it's basically in infinte log loop | 12:28 |
| vila | bug in mass-import then ? | 12:29 |
| mgz | printing the failure triggered a complaint about normalisation caused a failure... | 12:29 |
| mgz | yeah | 12:29 |
| vila | bad bad bad | 12:29 |
| vila | good we encountered it while online | 12:30 |
| mgz | was going well till that, a bunch of packages imported, and a bunch more failed with useful errors | 12:30 |
| mgz | the invalid normalisation error class in bzr should really use repr | 12:31 |
| mgz | 326570836 is a lot of bytes of log | 12:31 |
| mgz | manually truncating that a bit wouldn't hurt | 12:32 |
| * mgz logs out of jubany for a short food break | 12:32 | |
| vila | no, please leave it there as evidence for forensics, it will be log'rotated when needed anyway | 12:35 |
| vila | I'm already rsync'ing it | 12:35 |
| vila | we had cases like that long ago, it's not an issue in itself | 12:36 |
| rom1 | Hi all | 12:57 |
| === yofel_ is now known as yofel | ||
| rom1 | Is there a hook triggering once a checkout is done completely ? | 12:58 |
| rom1 | I have tried post_pull, post_branch_change, but none of them is triggered after the .bzr/checkout directory is made | 12:58 |
| vila | rom1: I don't think there is such a hook yet, patches or bug welcome ! | 13:03 |
| rom1 | that's what i thought : thx vila ! | 13:03 |
| vila | mgz: http://paste.ubuntu.com/718773/ should fix the issue, weird that we never encountered the case though | 13:04 |
| mgz | vila: the replace is redundant | 13:05 |
| mgz | otherwise looks about right | 13:05 |
| vila | meh ? The one I delete ? | 13:05 |
| * mgz bops self on head | 13:06 | |
| vila | bah, sorry you don't have the context here | 13:06 |
| mgz | yes, the code you're deleting is wrong | 13:06 |
| mgz | that it triggered a loop though is still a bit concerning | 13:08 |
| === med_out is now known as medberry | ||
| vila | mgz: look at the method itself, this was the last place we use unicode_output | 13:09 |
| vila | mgz: I suspect some similar case happened in the paste leading to the introduction of ascii_output to avoid the problem | 13:09 |
| vila | s/paste/past/ :) | 13:10 |
| vila | re-starting with max_threads = 2 | 13:10 |
| mgz | yeah, seen | 13:10 |
| vila | hu ho | 13:10 |
| vila | dandling scripts/main_lock, never see that before | 13:13 |
| vila | wow, we'll now soon enough, praat requeued | 13:13 |
| vila | hmm, otrs2 and console-tools didn't finish, they are still running | 13:15 |
| vila | one more trick to monitor: 5) run top ordered by MEM used | 13:17 |
| vila | that's how I found back otrs2 and console-tools (you need to add cmdline to the displayed columns) | 13:18 |
| vila | those two orphan imports... | 13:18 |
| jml | vila: sorry | 13:19 |
| vila | ... will finish... eventually... but won't be marked as such in the db ??? May be another cause of those random imports coming out of sequence | 13:19 |
| vila | jml: hehe, too soon to be sorry, join the fun fixing the fallouts ;-p | 13:20 |
| vila | jml: kidding, I think we nailed them down | 13:20 |
| jml | vila: cool. thanks. | 13:20 |
| vila | jml: your way to remind me why you TDD-infected me is naughty though ;-D | 13:21 |
| vila | mgz: in the mean time, the importer fail to start the already running imports so we should be safe... | 13:23 |
| vila | bbiab | 13:23 |
| mgz | okay, first one back can try again | 13:24 |
| * vila nods | 13:24 | |
| jml | vila: :) | 13:25 |
| mgz | ^I do 5) all the time on this box :) | 13:25 |
| ccxCZ | can anyone help me with bzr-git failing? http://paste.pocoo.org/show/497924/ | 13:31 |
| ccxCZ | seems like https://bugs.launchpad.net/bzr-git/+bug/706990 but that should be fixed in bzr-git I have | 13:34 |
| ubot5 | Ubuntu bug 706990 in Bazaar Git Plugin "git-import fails on remote repository with AttributeError: 'RemoteGitRepository' object has no attribute '_git'" [Critical,Fix released] | 13:34 |
| mgz | ccxCZ: the traceback *is* different | 13:38 |
| mgz | ccxCZ: bug 849250 | 13:39 |
| ubot5 | Launchpad bug 849250 in Bazaar Git Plugin "pull into remote git branch fails" [Low,Fix committed] https://launchpad.net/bugs/849250 | 13:39 |
| mgz | you need 0.6.3 | 13:39 |
| ccxCZ | seems if I just do branch, it works | 13:39 |
| mgz | ...which I'm not sure when jelmer plans to release | 13:40 |
| mgz | +affectsmetoo that bug at least. | 13:41 |
| mgz | okay, now I need to get going. | 13:41 |
| ccxCZ | seems eadd fails consistently though | 13:43 |
| ccxCZ | doesn't seem to be the same bug to me | 13:46 |
| mgz | ccxCZ: the line in question with the bug is that one | 13:47 |
| ccxCZ | yeah, in the end it ends up in the same function, failing on the same row, should I post my traceback there, or just +1 it? | 13:49 |
| ccxCZ | does lp allow some formatting? I guess the traceback should at least be monospaced | 13:52 |
| === zyga is now known as zyga-afk | ||
| james_w | mgz, would you have a minute to review https://code.launchpad.net/~james-w/udd/config-location/+merge/80337 ? | 14:15 |
| james_w | vila, you've experience related to ^ I think? | 14:15 |
| === aurora|afw is now known as AuroraBorealis | ||
| james_w | vila, https://code.launchpad.net/~james-w/udd/base_dir-config/+merge/80350 removes one of your FIXMEs if you would take a look | 15:34 |
| === zyga-afk is now known as zyga | ||
| vila | Mcough> finally back :-} | 15:40 |
| mgz | gra, that was annoying | 15:47 |
| mgz | will have a look at those udd branches unless vila gets there first | 15:47 |
| vila | james_w: I won't be able to look at them today, but probably tomorrow | 15:52 |
| vila | james_w: on the overall and given the issues we had this morning I really like to have basic smoke tests so this kind of refactoring can be done safely without breaking horribly in production though | 15:53 |
| james_w | oh, there were issues? | 15:54 |
| vila | well, if you look at lp:udd recent revisions I'm sure you will spot the fixes ;) | 15:54 |
| james_w | :-) | 15:55 |
| james_w | do you have an idea what form those smoketests would take? | 15:55 |
| vila | from the top of my head, we have 5 or 6 scripts that should runnable with a minimum setup in the db (the ones from crontab) | 15:56 |
| vila | mass-import itself could to with a dedicated import-package simplified replacement | 15:56 |
| vila | import-package is the trickiest | 15:56 |
| james_w | yeah | 15:58 |
| jml | you know what would make that easier? | 15:58 |
| jml | the changes in the branches that james_w has proposed | 15:59 |
| vila | heeh chiken and egg | 16:00 |
| vila | unit tests for paths covering these changes will be a significant relief too ;) | 16:00 |
| jml | vila: I think there are tests, in fact. | 16:01 |
| jml | vila: again, a part of the work that james_w has done is to make some of this more testable. | 16:01 |
| === beuno is now known as beuno-lunch | ||
| vila | jml: tests that exercised the paths ? I don't think so. Even the config tests are very basic | 16:04 |
| james_w | there aren't tests for the values, no | 16:04 |
| vila | jml: you know the udd/iconfig already allows you to define more specific values in locations.conf right ? | 16:15 |
| jml | vila: No, I don't. | 16:15 |
| jml | vila: oh, wait, yes | 16:15 |
| jml | vila: but that's a really bad idea for running a production service | 16:15 |
| vila | i.e. in the short term you don't *need* an out-of-tree config | 16:15 |
| vila | ha right, but that's more long term | 16:15 |
| jml | vila: not really | 16:16 |
| jml | vila: long term is you guys coming up with an effective test suite so you can be confident about accepting contributions :) | 16:16 |
| mgz | right, lets have one more go at the package import queue | 16:16 |
| jml | vila: we're planning on deploying sooner than that :P | 16:16 |
| vila | jml: yeah for more production services with no effective test suite ? | 16:17 |
| vila | :-p | 16:17 |
| vila | more seriously, it seems allowing paths.paths to be monkey patched (which I suspect is your short term target) is more risky than allowing iconfig.Iconfig to use a different config file (which can indeed be out of tree) as long the paths are turned into config options | 16:20 |
| mgz | ah good, it's nearly there | 16:20 |
| james_w | the first branch adds the support for an alternative config file | 16:20 |
| james_w | the second is just to remove the hardcoding of base_path | 16:20 |
| james_w | as an alternative config file doesn't help us with hardcoded paths | 16:21 |
| james_w | with both we can have the alternative config and all the sysadmins to configure all the important paths to their liking | 16:21 |
| vila | I understand that james_w , I'm talking about an alternative started long ago which would get rid of paths :-/ | 16:23 |
| vila | family time here, don't let me block you, go ahead with the branches, Ill catch up, but please, do some basic testing first so it doesn't blow up at deploy time | 16:23 |
| thumper | abentley: hi | 16:23 |
| thumper | abentley: I have a pipeline question | 16:24 |
| thumper | abentley: is there a command to check my pipeline to see if any previous pips has revisions that aren't in the next pipe? | 16:24 |
| vila | jml, james_w : oh, and tell me where I can look at the other service code, I'm sure it will be far clearer | 16:24 |
| mgz | oo, symlink failure on ikiwiki | 16:25 |
| jml | vila: lp:pkgme-binary. It probably won't make it clearer. | 16:29 |
| abentley | thumper: You can compare two pipes with "bzr missing", but there isn't something that checks the whole pipeline. | 16:35 |
| abentley | thumper: But "bzr pump" is a no-op if there's nothing to pump. | 16:36 |
| thumper | ok | 16:36 |
| thumper | cool | 16:36 |
| thumper | might be a nice to have though | 16:36 |
| abentley | thumper: yeah, I think so. Could you file a bug describing the UI you'd like to see? | 16:37 |
| thumper | abentley: sure... although in the middle of a 13 branch pipeline right now :) | 16:38 |
| thumper | pre-merge trunk fix ups | 16:38 |
| james_w | vila, I'm not sure I understand what the alternative you are proposing is. I'd like to consider it if it's something you've been working towards | 16:38 |
| vila | james_w: basically: get rid of udd.paths by turning them into config options. From there we can focus on the config file handling | 16:52 |
| jml | vila: I'm surprised. there's already so much redundant stuff in the config file | 16:53 |
| jml | vila: why would it be a good thing to make them independent options? | 16:53 |
| * jml → lunch | 16:53 | |
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| vila | jml: the redundant stuff is a different issue, you want to redefine root_dir right ? So, it's a config option. | 17:18 |
| mgz | vila: you stopping the importer? | 17:22 |
| mgz | gnome-games is the last one I wanted to see through | 17:22 |
| mgz | hopefully won't be too much longer :) | 17:22 |
| vila | mgz: yup, sorry, didn't know you were looking, console-tools was stuck for too long | 17:22 |
| vila | mgz: and still mentioned in the running jobs while not under the mass-import control => too much weird stuff | 17:23 |
| vila | so: stop/start to see | 17:23 |
| mgz | yeah | 17:23 |
| mgz | I'm just going to do a quick post to the dd list about the unicode status | 17:24 |
| vila | yup, would be nice, I've seen two different signatures but don't know how to interpret them (yet) | 17:24 |
| vila | mgz: ha ! acidbase I think is the one with NFD path | 17:25 |
| mgz | yeah, there's one more like it too | 17:27 |
| mgz | *two more | 17:27 |
| mgz | okay, gnome-games succeeded | 17:30 |
| mgz | amusing that was the last packaged through, given the original bug report was about it. | 17:30 |
| vila | huh ? | 17:34 |
| vila | mgz: gnome-games is still running | 17:34 |
| mgz | hm, looked finished from the package log | 17:34 |
| mgz | but you're right, the driver hasn't got there yet | 17:35 |
| vila | more data in the package log as we speak ;) | 17:35 |
| vila | where are you looking ? | 17:35 |
| mgz | I was clearly being over-eager :) | 17:35 |
| mgz | okay, will save draft and send this email when I get back later | 17:35 |
| vila | mgz: but looking at the log it went far further this time | 17:37 |
| vila | mgz: it failed in the dapper era and is now in the gutsy one | 17:37 |
| mgz | right, time for me to head off, will check in a bit later | 17:41 |
| jelmer | hi * | 17:53 |
| james_w | hi jelmer | 18:08 |
| BlackDex | Hello there.. I get the following error: bzr: ERROR: Permission denied: ".": OPTIONS of 'https://*': authorization failed: Could not authenticate to server: rejected Basic challenge (https://*) | 18:08 |
| BlackDex | And when i use SVN to check out the same repo, it works as it should | 18:08 |
| BlackDex | Using Ubuntu oneiric | 18:09 |
| jelmer | BlackDex: hi | 18:11 |
| BlackDex | jelmer: Hello | 18:11 |
| jelmer | BlackDex: how does svn prompt for credentials? | 18:12 |
| jelmer | bzr should be able to use the credentials stored in ~/.subversion | 18:12 |
| BlackDex | It asked once, and now it doesn't any more so i know they are saved | 18:12 |
| jelmer | BlackDex: how did it ask though, using a simple password prompt? | 18:13 |
| jelmer | (on the commandline) | 18:13 |
| BlackDex | jelmer: That i can't remember | 18:15 |
| exarkun | is there a way to use a file url to access and svn repository using bzr-svn? | 18:15 |
| exarkun | /and/an/ | 18:15 |
| BlackDex | i can remove/rename the .subversion and try again | 18:15 |
| jelmer | exarkun: it should support file URLs and local paths | 18:15 |
| BlackDex | jelmer: It asked on the prompt via the cli | 18:17 |
| exarkun | Ah, indeed. Thanks. | 18:17 |
| BlackDex | Although if i check. There is a file in "~/.subversion/auth/svn.simple" | 18:20 |
| BlackDex | And there i see it is using gnome-keyring but it has my username in it and the correct info | 18:20 |
| BlackDex | as far as i can tel | 18:20 |
| BlackDex | but not the password it self | 18:20 |
| jelmer | BlackDex: ah, we don't integrate with gnome-keyring well yet so that's probably the issue | 18:21 |
| jml | vila: I seriously don't get why you want us to add more variables to the config file that no one actually wants to configure | 18:21 |
| BlackDex | strange.. it worked under natty | 18:23 |
| vila | jml: you don't want to redefine root_dir ??? | 18:24 |
| === deryck[lunch] is now known as deryck | ||
| jml | vila: root_dir, no. base_dir, yes. download_cache_dir, hell no. | 18:24 |
| exarkun | if "discovering tags" is taking ages when checking out an svn branch with bzr/bzr-svn, is there something that should be configured that would make it faster? | 18:24 |
| vila | jml: yes, base_dir from which all the other paths are derived from (including root_dir, the names confused me) | 18:27 |
| jml | vila: right. I don't want to configure download_cache_dir or debian_diffs_dir or any of those other things separately from configuring base_dir. | 18:30 |
| vila | jml: I'll be fine if they are all calculated from base_dir, making them config options is one possible way to get there | 18:30 |
| vila | jml: yes, me neither | 18:30 |
| vila | but if I have to (and today I have) I'd rather have all the definitions in a single place | 18:31 |
| jelmer | exarkun: newer versions of bzr-svn are somewhat more efficient in that regard | 18:31 |
| jelmer | vila: hi | 18:31 |
| jelmer | vila: I think I saw something about the rollout of a new bzr-builddeb | 18:31 |
| jml | vila: so maybe let's move the things we don't want to configure out of the config file | 18:31 |
| vila | jelmer: hey, we've deployed a newer buildeb on jubany, is it ok to retry the multiple tarballs imports | 18:32 |
| exarkun | jelmer: So it's just slow (~5 minutes to branch) until I upgrade? | 18:32 |
| vila | jml: and separate base_dir from the others ? | 18:32 |
| jelmer | exarkun: it might be related to the number of tags in the twisted repo | 18:32 |
| jelmer | vila: yeah, go for it | 18:33 |
| jml | vila: well, if it's the only thing that needs to be configured, then yes. | 18:33 |
| jelmer | vila: worst that can happen is that they still fail I guess? | 18:33 |
| vila | jelmer: roughly yes, but it's funnier to requeue them if there is some hope it's useful ;) | 18:33 |
| vila | jml: what if one site want to put web_base_dir somewhere else ? They will still have to chnage the code ? | 18:34 |
| vila | jml: the hierarchy about where the log files are stored have already changed | 18:35 |
| jml | vila: then we'll deal with that use-case when we get to it? | 18:35 |
| jelmer | vila: I haven't tried it on a large number of packages yet, but I think it should work - at least for a fair number of the currently failing ones | 18:35 |
| vila | jml: we *did* get to it, maxb created udd/paths by starting centralizing them | 18:35 |
| jml | vila: ok, so I'm confused | 18:36 |
| vila | s/centralizing/to centralize/ | 18:36 |
| jml | vila: what do you want? | 18:36 |
| vila | if we change the way we access the paths (as james_w proposed) I'd rather change it to something that makes it clear that these paths *can* be configured | 18:37 |
| * maxb thinks there should just be one config var, for the root of the tree. People can use symlinks if they must for the rest :-) | 18:38 | |
| maxb | *especially* the various paths within the www dir | 18:38 |
| vila | more nightmare for testers | 18:38 |
| vila | or any other alternate installation really | 18:39 |
| vila | unless you want a setup.py ? or a proper package ? | 18:39 |
| vila | and I still don't know how to add comments on symlinks and I really like having comments to describe such a hierarchy | 18:40 |
| jml | well, the start of having a proper package is getting the config file out of the branch | 18:40 |
| vila | jml: it was out of the branch and as such made the deployment harder | 18:40 |
| BlackDex | jelmer: In Natty i had to manualy gif my username and password, now i just get an error.. | 18:41 |
| BlackDex | But i try to config it so it doesn't use gnome-keyring now | 18:41 |
| maxb | Why would we ever want a "proper" package? | 18:41 |
| jml | vila: what do you suggest we do for our deployment then? | 18:41 |
| jml | vila: maintain a fork? | 18:41 |
| jml | just for the config? | 18:41 |
| vila | nope | 18:41 |
| vila | having your config file override the one in the branch and maintain it as you see fit | 18:42 |
| jml | every single setting | 18:42 |
| jml | better not miss one | 18:42 |
| maxb | Actually, what if we remove all the path configuration. ALL of it. Just find paths relative to the running script | 18:42 |
| vila | until we can make the options depend on each other as mentioned in the config file | 18:43 |
| jelmer | BlackDex: I think the difference is that svn now uses gnome-keyring by default | 18:43 |
| jml | wait for a facility to allow a config file to do something that code can already do, just in case someone comes along who wants to customize something? | 18:43 |
| vila | jml: at which point you'll have only to define the differences which should be very narrow | 18:43 |
| vila | meh, I'm not the one asking for the change right now, I want to have it for tests but just create the same /srv dir for now | 18:44 |
| james_w | isn't https://code.launchpad.net/~james-w/udd/config-location/+merge/80337 allowing for having a config file that overrides the one in the branch? | 18:44 |
| jelmer | BlackDex: svn in oneiric that is | 18:46 |
| vila | james_w: yup, I have only minor (if even) objections to that one | 18:46 |
| jelmer | vila: can you requeue the multi-tarball packages? | 18:46 |
| vila | jelmer: asap but I'm waiting for the importer to gracefully stop right now | 18:47 |
| james_w | vila, cool | 18:47 |
| jml | vila: what sort of tests do you want for the other branch? self.assertEqual(paths.web_dir, os.path.join(root_dir, "www"))? | 18:47 |
| BlackDex | jelmer: It also seems i can't force it to store it as plaintext | 18:48 |
| vila | james_w: i.e. if a config file is found take it, otherwise use the old one is perfectly fine with me | 18:48 |
| BlackDex | jelmer: Well there is only one way to bypass all this.. by putting the username and password in the branch.conf in front of the URL | 18:50 |
| vila | jml: for unit tests, yeah, make sure we still produce the same as before, smoke tests that all scripts are still behaving correctly are more important though, failing that, tell me it still run for your deployment | 18:50 |
| vila | s/it/they/ | 18:50 |
| vila | jml: that's where I have most fears, these paths where collected from scripts where they were evaluated very early, they should all be more dynamic now. So making them use base_dir *should* work, but the only way to be sure... | 18:52 |
| BlackDex | jelmer: If i want to create a bug report, where should i report this bug?? bzr-svn or bzr? | 18:52 |
| jml | vila: ok. | 18:53 |
| vila | jml: sorry to sound picky here, but right now, I'm waiting for an import to finish so I can restart the importer one last time hopefully fixing the last issue introduced by deploying PATH/PYTHONPATH shuffling across the scripts ;-P | 18:56 |
| vila | and it's EOD ;) | 18:56 |
| jml | vila: understood :) | 18:57 |
| james_w | vila, is http://paste.ubuntu.com/719082/ like what you are thinking for unit tests? | 18:59 |
| vila | james_w: eeerk, base_dir is already define there but we still don't use it :-/ | 19:03 |
| vila | grr | 19:03 |
| vila | jml: by the way, expanding the options *is* available in bzr-2.4 | 19:03 |
| vila | jml: which bzr version do you use or require for you pkgme ? | 19:04 |
| james_w | vila, defined where? | 19:04 |
| jml | vila: I think anything better than 1.14 would work | 19:04 |
| vila | in pkgimport.conf | 19:04 |
| james_w | yes, and this branch makes it use it I thought? | 19:04 |
| vila | jml: hehe, seriously, are you constrained by some LTS support or something ? | 19:04 |
| james_w | the second branch that I submitted | 19:05 |
| jml | vila: probably we'll deploy on the IS standard: lucid | 19:05 |
| james_w | we can ask for a newer bzr if it's needed, but we're not interested in making use of the expansion behaviour | 19:07 |
| vila | jml: urgh rmadison bzr => 2.1 | 19:07 |
| james_w | and neither is package-import as far as I am aware | 19:07 |
| james_w | so I don't feel the need to do the work to allow configuration of paths that no-one wants to change at this point | 19:07 |
| james_w | we do want to configure the base dir though | 19:08 |
| james_w | I think maxb's suggestion makes sense, but I don't know why I didn't just do that in the first place :-) | 19:08 |
| jml | brb | 19:09 |
| james_w | but I can see that wanting to put the output somewhere other than where the code lives would desirable | 19:10 |
| james_w | even if it's not how it's deployed on package-import | 19:10 |
| vila | james_w: then I think I kind of miss the point of your proposal, why not create a symlink from /srv/pack.... to where you want your new deployment to live and be done with it ? | 19:11 |
| james_w | we certainly could, but there was a big FIXME in the code when we found this, so we thought we would FIXIT | 19:12 |
| james_w | and perhaps IS will want to deploy to the same machine, we don't know yet | 19:13 |
| vila | james_w: well, back to .... go ahead :) I will be able to redefine base_dir in locations.conf with your proposals so it's already a good step | 19:19 |
| james_w | ok, thanks | 19:20 |
| lamalex | hi, how to i delete my launchpad login info? | 19:54 |
| peitschie | morning all :) | 22:56 |
| poolie | hi all | 23:14 |
| jelmer | hi poolie | 23:41 |
| poolie | hi there, how's cali? | 23:42 |
| jelmer | sunny :) | 23:42 |
| * jelmer bets Sydney is even sunnier | 23:47 | |
| poolie | mm, not today, ~14C and cloudy | 23:48 |
| poolie | it was 36C and sunny on monday | 23:48 |
| fullermd | Fortunately, we don't have any of those "C"'s in this country. Sounds like a commit plot to me. | 23:49 |
| jelmer | fullermd: I'm in your country but I'm sticking to SI, thankyouverymuch. :-P | 23:49 |
| fullermd | Onoes. The Red Invasion proceeds :( | 23:50 |
| peitschie | (I'm late to the party... but you can tell you work with source control too much when your mistype "commie" as "commit" jelmer :P) | 23:59 |
| poolie | :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!