=== 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
vilahi all !07:00
pooliehi there, nice to see you!07:01
pooliei'm just reviewing your possible_transports patch07:01
vilaoh great !07:02
pooliewow look at all these patches07:04
pooliehi mgz07:05
vilamgz: _o/07:07
vilapoolie: 'feel free to land with post review' ? I can't parse that, especially the 'with post review' part ;)07:09
poolieah i mean07:09
poolieyou don't need to wait for review07:09
pooliei do appreciate you making an mp, so people can see the diff07:09
vilayeah, I intended to deploy it but wanted to chit-chat with jml... can't remember exactly why though :)07:10
vilaha, good analyze-log script :) 22h20 is how long it takes to catchup the imports for chromium-browser (still failing though)07:13
vilaha crap, jml refactoring broke *all* scripts, the modules are not found anymore07:17
poolieyeah i see07:17
mgzyeah, I wondered about that yesterday when trying to run the importer locally07:17
pooliebut i thought they were all already on jubany07:17
pooliei checked it was up to date with trunk the other day07:18
vilathinking he was the one infecting me with TDD ;)07:18
pooliebut perhaps they had not yet been merged07:18
mgzmoving the script out of the base dir means "udd" is no longer on the path07:18
mgzso you can't run without installing (or setting PYTHONPATH or something)07:18
vilamgz: exactly but not only, jquery.flot.js not found too07:18
vilaI just created bin/udd -> ../udd but that's not enough07:19
vila(not to mentioned hackish ;)07:19
mgzehee, that's even worse than most symlink hacks :)07:19
vilaok, I'll revert it and comment on the mp, too much to fix without guarantee I get them all07:21
mgzcould revert that change for now, and only land it w...07:21
mgz...hen there's a setup.py script to go with it07:21
vilaoh, setup.py, worth thinking about it07:21
vilabut we run from source and it's also a useful thing07:22
vilabah, let's try a bit harder, reverting is not trivial either and is going in the wrong direction anyway07:23
poolievila, mgz, i think it's just us this week so we could talk whenever you like07:23
vilacomfy :)07:24
vilaRiddell is not here either ?07:24
pooliei might be confused but i thought he was going to be en route to uds this week?07:33
vilahmm, by boat ? :-D07:33
poolieexactly, kayak07:34
poolienot really07:34
vilaok, some sanity restored, categorise-failures works07:39
vilaetc scripts 101: you can't remove PATH or you won't do a lot07:41
pooliegz you're in ~bzr-explorer-dev now08:31
mgzpoolie: cool, will land that branch08:47
pooliefeel free to also add a <land it!> button to lp! :)08:47
pooliei'm seriously tempted to do it myself08:48
mgzvila: 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 today08:48
vilamgz: sure thing !08:49
mgzpoolie: but doing it manually is such fun...08:49
vilaI've just fixed the last glitch and the importer is running again08:49
vilaI'm waiting a bit before calling it a win ;)08:50
vila... and stopping it before requeuing chromium-brower...08:50
vilaso, let's deploy builddeb as soon as you're ready08:51
mgzI'm guessing the procedure is basically stop importer, pull, start, then... tell it what package somehow?08:51
vilaso, first thing, read README_DEPLOYMENT to make sure it's accurate08:51
mgzwhich lives...?08:52
vilain lp:udd :)08:52
vilawith a symlink also in place in pkg_import@jubany:/srv/package-import.canonical.com/new/scripts08:52
mgzokay, that tells me the dir.08:53
vilamgz: you know how to connect there ?08:53
mgzyep, I'm there08:53
vilavia ssh + sudo su - pkg_import ?08:53
vilahmm './' is probably missing in front of the etc-init.d-mass-import examples08:54
vilacan you confirm that ?08:54
vilaok, fixed locally (I'll take the notes, you do the work ;)08:55
mgzand in fact, when I stopped it last time, used the script in /etc/init.d/08:55
vilawe should resync them but better use the one in the branch08:56
mgzwhich is I guess just the same thing, or an older copy, or a symlink08:56
vilaan older copy08:56
vilayou haven't stopped it yet right ?08:56
mgzyup, has the wrong path08:56
vilause graceful-stop08:56
mgznot stopped yet.08:56
mgzdoing now08:56
vilayup seeing it08:57
vilaoh, I should mention that,08:57
mgzhow do you monitor a running importer?08:58
vilaI usually have 3 connections to jubany:08:58
vilaoh failure !08:58
vilacrap dpkg-mergechanglogs is not in PATH anymore08:59
vilastopped nevertheless08:59
mgzthere's an old import_package.pyc and .py~1~ in here for some reason...09:00
vilamv dpkg-mergechangelogs bin/ should take care of that but we need a more formal way to track it09:00
vilasomeone did a revert probably09:00
vilaback to monitoring:09:00
mgztail some log?09:01
vila1) tail -F logs/driver/progress_log09:01
vila2) crap, broken now, just a sec09:02
vila2) 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
vila3) in .../scripts: '. ./fixit.sh' to get some shorcuts and setup the env09:04
mgzso, is lp:udd in a usable state now? should I pull in the latest bzr-builddeb?09:05
vilalp:udd is deployed, so, yes, pull the latest builddeb, check that no uncommitted changes are there though09:06
mgzwill do.09:06
mgzone shelve. :)09:07
vilayeah, looking at it ;)09:07
vilait's an old one, should be safe to delete but doesn't hurt to keep it until we fix the dpkg-mergechangelog for good09:07
mgzokay, that's got the fix in question09:08
mgzstart time?09:08
vilastarted ok09:10
vilanotice that it says ' Read 4 in /srv/package-import.canonical.com/new/max_threads'09:10
vilaI changed from the default 8 while debugging the scripts issues09:11
mgzso, how are you running the scripts in bin? I need to do requeue-package next09:11
vilaI use '. ./fixit.sh' first09:11
vilait provides 'requeue'  as a shorcut to requeue-package09:11
mgzI see it.09:12
vilarun 'categorise-failures' to force the status page generation09:12
mgzstop importer first?09:13
vilano they are independent09:13
vilait's useful when you don't want to wait for the crontab to run it09:13
vilaevery 5 minutes (see importer.crontab in lp:udd)09:14
mgzall looks like the same issue in import_dsc09:14
vilabut you can stop the importer too as the failure seem to spread09:14
vilayou'll be able to requeue all the related failures by doing 'requeue --all <one-package-that-failed>'09:15
vilagood thing I didn't requeue chromium :)09:15
vilaone sucessful import still ;)09:16
mgzlooking for blame.09:16
vilanow, the usual choice is to either revert to a known-working rev and restart or fix before restarting09:17
vilait'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 stuff09:18
mgzprobably in lp:udd09:18
mgzhm, nope, the singular->plural was a builddeb change09:22
mgzvila: bzr diff to see possible fix09:23
mgzwill let a few go past before requeuing09:24
vilaoh, 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
vilanope, try requeuing one that failed instead09:25
vilarequeue --priority paraview09:25
vila--priority will ensure it's run asap09:25
vilaif you run categorize-failures now it should appear in outstanding jobs09:27
mgzrun, but, where am I looking?09:28
vilaoh, that was related to multiple tarballs, we should check with jelmer telling him we've deployed that09:29
vilawhich one did you requeue ?09:29
mgzparaview, was the last one in the log09:29
vilaoh, sorry, that generates the status page09:29
mgzcurrently pending09:29
vilarunning already09:30
mgzI must be being blind then, didn't see current jobs on status09:30
mgz*running, even, yeah09:30
vilatop of the page09:30
vila4 running09:30
vila30 outstanding jobs09:30
vilaand in the last 50 failures you've got the ones related to extract_upstream_tree09:31
mgz...I'm now not sure if I needed that refresh or if I was just being blind09:31
vilago with refresh ;)09:31
mgztail is looking happy.09:31
vilathe fact that this page also refreshes itself from time to time doesn't help ;)09:31
mgzwill let paraview go through, then requeue the one I wanted and all those that hit that issue09:32
vilayup, that's the idea09:32
vilayou'll requeue them with: 'requeue --all polyglot'09:33
vilaadding --priority as you see fit09:33
vila--all will requeue all packages that share the same failure signature09:33
poolie ok, i should go, good night09:34
mgznight poolie!09:34
vilapoolie: g'night !09:34
mgzparaview done.09:34
mgzokay, everything set up I think.09:36
vilabump max_threads to 8 (echo 8 >../max_threads)09:36
vilacategorize-failures again to see the effect (or look in the logs)09:38
mgzyeah, following log09:38
vilaI'll requeue the ones related to dpkg-merge...09:39
vila...and I'll requeue chromium-browser once the outstanding jobs are (will be ?) done09:40
vilaha great lxc fails09:40
mgz...lock contention on lxc?09:40
viladid you see that ?09:40
mgz...great as in, really was good, or great as in, annoying?09:41
vilain some cases (for yet unknown reasons) an exception manage to escape the finally clause where the lock is released09:41
vilagreat 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
mgzhey, I think my test package went through okay while I was distracted09:42
mgzhow do we see sucesses? (...apart from in the log)09:42
vilato resolve: look at the traceback, it gaves hints about where the lock is still pending, in this case 'precise'09:42
vilayou don't, it's a bug I'm working on, let me find the number09:43
vilabug #83169909:43
ubot5Launchpad bug 831699 in Ubuntu Distributed Development "no report/log of successful packages" [High,In progress] https://launchpad.net/bugs/83169909:43
vilaso, cd ../updates/lxc/precise09:44
mgzpygobject also had an unhappy lock experience09:44
vilayup, same issue09:44
vilabzr info -v09:44
vilait's a local lock so 'bzr breack-lock'09:44
mgzokay, I'll requeue all the other UnicodeDecodeError packages, and hopefully a couple of them will fail with new nicer errors09:44
vilatwo locks broken09:45
vilasometimes it's a remote one and I do 'bzr break-lock :push'09:45
mgzlibproxy is a different issue09:45
vilatwo broken locks for pygobject too09:46
vilaand requeued09:46
vilarats another failure ;-/09:47
* vila blinks, that's an unknown one09:48
mgzall unicodedecodeerror packages queued09:48
vilawill need to repro locally09:48
vilacan you land your fix on lp:udd ?09:48
mgz51, 10, 5, 309:49
mgz^will do09:50
vilahmm, the lxc failure spreads09:50
vilasomething changed in the merge hook09:51
mgzyeah seems like it09:51
vilaprobably worth stopping the importer when all your jobs have passed09:52
mgzhuh, it's doing paraview again09:53
vilathere is a bug there (not filed), some jobs seem to be re-processed for no good reasons09:54
mgzoh, probably because I did requeue --all on a similarly failing package after it had succeeded?09:54
vilanope, it shouldn't it's more obscure than that09:54
vilaI've seen jobs being re-processed without being involved in anything recent09:55
vilamgz: mwhahaha, conflicts in bzr-builddeb locally10:02
vilamgz: import pdb; pdb.set_trace() in bzrtools_import.py getmembers :)10:02
vilaI went there trying to diagnose some unicode issue at one point ;) I should have tried harder ;)10:05
vilamgz: did you note the revno before upgrading builddeb on jubany ?10:07
mgzshould I just push to lp:udd?10:08
mgzvila: ...no, but I think you told me it yesterday10:08
vilayou rock !10:08
vilayup 61310:09
mgzhm, a bunch of these current packages aren't doing anything new10:11
mgzmaybe should stop, fix the merge hook issue, then see if I can get some non-utf8 filename failures10:12
vilamgz: yup, I'm trying to reproduce locally with lxc buno success so far10:21
vilas/buno/but no/10:21
vilamgz: you just got one !10:22
vila2 even :)10:22
vilamake that 310:23
vilaof, what's you trick ? ;-P10:23
vilas/you/your/ :-(10:23
vilabah, can't reproduce locally as it's code involved when pushing only ;_/10:24
mgzwhat the hell paraview is going through for like the fourth time10:24
vilayeah and outstanding jobs up to 120 (was down to 70)10:25
vilaso, categorize_failures requeue some but I suspect some cruft in the db10:26
mgzso, these will be packages with real filename encoding issues: <http://package-import.ubuntu.com/status/08eff66a5fe37a967e2f2b06210cc608.html>10:26
vilareal as in ?10:26
mgzas in, not utf-810:26
vilawill never be able to encode ?10:26
mgzmost of the ~70 failures should now pass10:27
mgzand the subset that don't will be listed there10:27
mgzbasically, bzr core needs a strategy for handling that edge case, so the package importer failing is reasonable10:28
mgzthe 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, encoding10:29
mgzbut I suspect that won't be worthwhile10:29
vila..and may not be enough (I suspect this should be attached to each file in some cases)10:29
vilalibperl5i-perl also enjoys being processed10:30
vilaqcomicbook too10:30
vilaeerk and libjgrapht0.6-java enve more !10:31
vilaok, so, this issue is now really bad10:31
mgzI have run categorise-failures several times, will stop doing that10:32
viladown to 69 outstanding jobs, don't run.. yeah me too, let's stop :)10:32
vilathere are some basic tests for db now and one FIXME is mentioning something related10:33
* vila back to the merge hook issue10:33
vilaok, I think I got it10:36
vilamgz: two bugs: dpkg-merchangelogs was not in PATH anymore, the merge hook can't find it but returns a single value instead of 210:41
vilamgz: we can stop the importer ;)10:41
mgzwhat happens to the current queue when it's stopped?10:42
vilait's in the db (meta.db JOBS_TABLE)10:42
vila4 more failures for you :)10:43
vilaerr 310:43
mgzyep, seeing them10:44
mgzperhaps a latin-1 fallback in the importer wouldn't be so bad.10:44
vilayeah, add an NFD too ;)10:45
vilaI forgot which package, but I'm pretty sure there is one with a contrib/docs/xxxx.pdf where xxx is in NFD10:45
vilasome db related one10:46
mgzaaaa, that error message is so much nicer10:46
mgzreminds me, I should improve UnicodeError display is bzrlib10:46
vilamgz: bzr diff on builddeb for the fix10:47
mgzhave we got a bug for it? we've talked about it before10:47
vilamgz: oh yes please !10:47
vilaI don't think so,10:47
vilabut there should a place where all unicode exceptions can be trapped their *args* put to good use10:47
vilai.e. the broken string is args[0] IIRC10:48
vilabut it's not displayed by default (strange idea)10:48
mgzdiff looks reasonable, is this the right end of the interface to change?10:48
vilaI'm 90% sure as it's a recent change and match the error we see10:49
mgzyep, looks more unambiguously correct with more context10:50
vilahmpf, it was still running :-}10:53
mgzthe last job was being slow :)10:54
vilayeah, chromium would have been even slower :)10:57
mgzopenclipart... I fear a little for the contents of that branch10:57
vilaoh crap, I pushed to lp:bzr-builddeb :-(10:57
mgzquick, uncommit! :)10:58
vilajelmer: so sorry about that :-/10:58
vilajelmer: the fix is trivial though, shouldn't be a problem ?10:58
vilamgz: anyway, in this case, 4 fourth terminal with: 'tail -F logs/packages/openclipart' :)10:59
mgzparaview is in the queue again...11:00
* mgz switches tails11:00
* vila switches to lunch ;)11:06
vilamgz: this import looks like it will take some time to finish anyway11:07
mgzI'll restart if I notice it's done before you return11:08
vilamgz: 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
mgz...bzr-builddeb just needs to be pulled, right?11:10
vilataking care about the pending change yes11:14
mgzvila: all done, also requeued the packages with affected by the tuple unpacking issue11:50
vilamgz: yup, still there for a couple of minutes, they fail with lockcontention :-011:50
mgz...but they seem to now all be failing with the lock...11:50
vilaprobably time to find a better way to addres that :)11:50
vilaI'll look into it when I get back11:52
viladelayed again :)12:08
vilamgz: panic in the driver we may need to kill hard12:24
mgzha, normalisation kills the world12:26
mgzdid a hard stop12:27
vilamee too :-/ But it seems I'm still receiving output from tail -F12:27
mgzthere was a *lot*12:28
mgzit's basically in infinte log loop12:28
vilabug in mass-import then ?12:29
mgzprinting the failure triggered a complaint about normalisation caused a failure...12:29
vilabad bad bad12:29
vilagood we encountered it while online12:30
mgzwas going well till that, a bunch of packages imported, and a bunch more failed with useful errors12:30
mgzthe invalid normalisation error class in bzr should really use repr12:31
mgz326570836 is a lot of bytes of log12:31
mgzmanually truncating that a bit wouldn't hurt12:32
* mgz logs out of jubany for a short food break12:32
vilano, please leave it there as evidence for forensics, it will be log'rotated when needed anyway12:35
vilaI'm already rsync'ing it12:35
vilawe had cases like that long ago, it's not an issue in itself12:36
rom1Hi all12:57
=== yofel_ is now known as yofel
rom1Is there a hook triggering once a checkout is done completely ?12:58
rom1I have tried post_pull, post_branch_change, but none of them is triggered after the .bzr/checkout directory is made12:58
vilarom1: I don't think there is such a hook yet, patches or bug welcome !13:03
rom1that's what i thought : thx vila !13:03
vilamgz: http://paste.ubuntu.com/718773/ should fix the issue, weird that we never encountered the case though13:04
mgzvila: the replace is redundant13:05
mgzotherwise looks about right13:05
vilameh ? The one I delete ?13:05
* mgz bops self on head13:06
vilabah, sorry you don't have the context here13:06
mgzyes, the code you're deleting is wrong13:06
mgzthat it triggered a loop though is still a bit concerning13:08
=== med_out is now known as medberry
vilamgz: look at the method itself, this was the last place we use unicode_output13:09
vilamgz: I suspect some similar case happened in the paste leading to the introduction of ascii_output to avoid the problem13:09
vilas/paste/past/ :)13:10
vilare-starting with max_threads = 213:10
mgzyeah, seen13:10
vilahu ho13:10
viladandling scripts/main_lock, never see that before13:13
vilawow, we'll now soon enough, praat requeued13:13
vilahmm, otrs2 and console-tools didn't finish, they are still running13:15
vilaone more trick to monitor: 5) run top ordered by MEM used13:17
vilathat's how I found back otrs2 and console-tools (you need to add cmdline to the displayed columns)13:18
vilathose two orphan imports...13:18
jmlvila: sorry13: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 sequence13:19
vilajml: hehe, too soon to be sorry, join the fun fixing the fallouts ;-p13:20
vilajml: kidding, I think we nailed them down13:20
jmlvila: cool. thanks.13:20
vilajml: your way to remind me why you TDD-infected me is naughty though ;-D13:21
vilamgz: in the mean time, the importer fail to start the already running imports so we should be safe...13:23
mgzokay, first one back can try again13:24
* vila nods13:24
jmlvila: :)13:25
mgz^I do 5) all the time on this box :)13:25
ccxCZcan anyone help me with bzr-git failing? http://paste.pocoo.org/show/497924/13:31
ccxCZseems like https://bugs.launchpad.net/bzr-git/+bug/706990 but that should be fixed in bzr-git I have13:34
ubot5Ubuntu 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
mgzccxCZ: the traceback *is* different13:38
mgzccxCZ: bug 84925013:39
ubot5Launchpad bug 849250 in Bazaar Git Plugin "pull into remote git branch fails" [Low,Fix committed] https://launchpad.net/bugs/84925013:39
mgzyou need 0.6.313:39
ccxCZseems if I just do branch, it works13:39
mgz...which I'm not sure when jelmer plans to release13:40
mgz+affectsmetoo that bug at least.13:41
mgzokay, now I need to get going.13:41
ccxCZseems eadd fails consistently though13:43
ccxCZdoesn't seem to be the same bug to me13:46
mgzccxCZ: the line in question with the bug is that one13:47
ccxCZyeah, 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
ccxCZdoes lp allow some formatting? I guess the traceback should at least be monospaced13:52
=== zyga is now known as zyga-afk
james_wmgz, would you have a minute to review https://code.launchpad.net/~james-w/udd/config-location/+merge/80337 ?14:15
james_wvila, you've experience related to ^ I think?14:15
=== aurora|afw is now known as AuroraBorealis
james_wvila, https://code.launchpad.net/~james-w/udd/base_dir-config/+merge/80350 removes one of your FIXMEs if you would take a look15:34
=== zyga-afk is now known as zyga
vilaMcough> finally back :-}15:40
mgzgra, that was annoying15:47
mgzwill have a look at those udd branches unless vila gets there first15:47
vilajames_w: I won't be able to look at them today, but probably tomorrow15:52
vilajames_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 though15:53
james_woh, there were issues?15:54
vilawell, if you look at lp:udd recent revisions I'm sure you will spot the fixes ;)15:54
james_wdo you have an idea what form those smoketests would take?15:55
vilafrom 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
vilamass-import itself could to with a dedicated import-package simplified replacement15:56
vilaimport-package is the trickiest15:56
jmlyou know what would make that easier?15:58
jmlthe changes in the branches that james_w has proposed15:59
vilaheeh chiken and egg16:00
vilaunit tests for paths covering these changes will be a significant relief too ;)16:00
jmlvila: I think there are tests, in fact.16:01
jmlvila: 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
vilajml: tests that exercised the paths ? I don't think so. Even the config tests are very basic16:04
james_wthere aren't tests for the values, no16:04
vilajml: you know the udd/iconfig already allows you to define more specific values in locations.conf right ?16:15
jmlvila: No, I don't.16:15
jmlvila: oh, wait, yes16:15
jmlvila: but that's a really bad idea for running a production service16:15
vilai.e. in the short term you don't *need* an out-of-tree config16:15
vilaha right, but that's more long term16:15
jmlvila: not really16:16
jmlvila: long term is you guys coming up with an effective test suite so you can be confident about accepting contributions :)16:16
mgzright, lets have one more go at the package import queue16:16
jmlvila: we're planning on deploying sooner than that :P16:16
vilajml: yeah for more production services with no effective test suite ?16:17
vilamore 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 options16:20
mgzah good, it's nearly there16:20
james_wthe first branch adds the support for an alternative config file16:20
james_wthe second is just to remove the hardcoding of base_path16:20
james_was an alternative config file doesn't help us with hardcoded paths16:21
james_wwith both we can have the alternative config and all the sysadmins to configure all the important paths to their liking16:21
vilaI understand that james_w , I'm talking about an alternative started long ago which would get rid of paths :-/16:23
vilafamily 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 time16:23
thumperabentley: hi16:23
thumperabentley: I have a pipeline question16:24
thumperabentley: 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
vilajml, james_w : oh, and tell me where I can look at the other service code, I'm sure it will be far clearer16:24
mgzoo, symlink failure on ikiwiki16:25
jmlvila: lp:pkgme-binary. It probably won't make it clearer.16:29
abentleythumper: You can compare two pipes with "bzr missing", but there isn't something that checks the whole pipeline.16:35
abentleythumper: But "bzr pump" is a no-op if there's nothing to pump.16:36
thumpermight be a nice to have though16:36
abentleythumper: yeah, I think so.  Could you file a bug describing the UI you'd like to see?16:37
thumperabentley: sure... although in the middle of a 13 branch pipeline right now :)16:38
thumperpre-merge trunk fix ups16:38
james_wvila, 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 towards16:38
vilajames_w: basically: get rid of udd.paths by turning them into config options. From there we can focus on the config file handling16:52
jmlvila: I'm surprised. there's already so much redundant stuff in the config file16:53
jmlvila: why would it be a good thing to make them independent options?16:53
* jml → lunch16:53
=== deryck is now known as deryck[lunch]
=== beuno-lunch is now known as beuno
vilajml: the redundant stuff is a different issue, you want to redefine root_dir right ? So, it's a config option.17:18
mgzvila: you stopping the importer?17:22
mgzgnome-games is the last one I wanted to see through17:22
mgzhopefully won't be too much longer :)17:22
vilamgz: yup, sorry, didn't know you were looking, console-tools was stuck for too long17:22
vilamgz: and still mentioned in the running jobs while not under the mass-import control => too much weird stuff17:23
vilaso: stop/start to see17:23
mgzI'm just going to do a quick post to the dd list about the unicode status17:24
vilayup, would be nice, I've seen two different signatures but don't know how to interpret them (yet)17:24
vilamgz: ha ! acidbase I think is the one with NFD path17:25
mgzyeah, there's one more like it too17:27
mgz*two more17:27
mgzokay, gnome-games succeeded17:30
mgzamusing that was the last packaged through, given the original bug report was about it.17:30
vilahuh ?17:34
vilamgz: gnome-games is still running17:34
mgzhm, looked finished from the package log17:34
mgzbut you're right, the driver hasn't got there yet17:35
vilamore data in the package log as we speak ;)17:35
vilawhere are you looking ?17:35
mgzI was clearly being over-eager :)17:35
mgzokay, will save draft and send this email when I get back later17:35
vilamgz: but looking at the log it went far further this time17:37
vilamgz: it failed in the dapper era and is now in the gutsy one17:37
mgzright, time for me to head off, will check in a bit later17:41
jelmerhi *17:53
james_whi jelmer18:08
BlackDexHello 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
BlackDexAnd when i use SVN to check out the same repo, it works as it should18:08
BlackDexUsing Ubuntu oneiric18:09
jelmerBlackDex: hi18:11
BlackDexjelmer: Hello18:11
jelmerBlackDex: how does svn prompt for credentials?18:12
jelmerbzr should be able to use the credentials stored in ~/.subversion18:12
BlackDexIt asked once, and now it doesn't any more so i know they are saved18:12
jelmerBlackDex: how did it ask though, using a simple password prompt?18:13
jelmer(on the commandline)18:13
BlackDexjelmer: That i can't remember18:15
exarkunis there a way to use a file url to access and svn repository using bzr-svn?18:15
BlackDexi can remove/rename the .subversion and try again18:15
jelmerexarkun: it should support file URLs and local paths18:15
BlackDexjelmer: It asked on the prompt via the cli18:17
exarkunAh, indeed.  Thanks.18:17
BlackDexAlthough if i check. There is a file in "~/.subversion/auth/svn.simple"18:20
BlackDexAnd there i see it is using gnome-keyring but it has my username in it and the correct info18:20
BlackDexas far as i can tel18:20
BlackDexbut not the password it self18:20
jelmerBlackDex: ah, we don't integrate with gnome-keyring well yet so that's probably the issue18:21
jmlvila: I seriously don't get why you want us to add more variables to the config file that no one actually wants to configure18:21
BlackDexstrange.. it worked under natty18:23
vilajml: you don't want to redefine root_dir ???18:24
=== deryck[lunch] is now known as deryck
jmlvila: root_dir, no. base_dir, yes. download_cache_dir, hell no.18:24
exarkunif "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
vilajml: yes, base_dir from which all the other paths are derived from (including root_dir, the names confused me)18:27
jmlvila: 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
vilajml: I'll be fine if they are all  calculated from base_dir, making them config options is one possible way to get there18:30
vilajml: yes, me neither18:30
vilabut if I have to (and today I have) I'd rather have all the definitions in a single place18:31
jelmerexarkun: newer versions of bzr-svn are somewhat more efficient in that regard18:31
jelmervila: hi18:31
jelmervila: I think I saw something about the rollout of a new bzr-builddeb18:31
jmlvila: so maybe let's move the things we don't want to configure out of the config file18:31
vilajelmer: hey, we've deployed a newer buildeb on jubany, is it ok to retry the multiple tarballs imports18:32
exarkunjelmer: So it's just slow (~5 minutes to branch) until I upgrade?18:32
vilajml: and separate base_dir from the others ?18:32
jelmerexarkun: it might be related to the number of tags in the twisted repo18:32
jelmervila: yeah, go for it18:33
jmlvila: well, if it's the only thing that needs to be configured, then yes.18:33
jelmervila: worst that can happen is that they still fail I guess?18:33
vilajelmer: roughly yes, but it's funnier to requeue them if there is some hope it's useful ;)18:33
vilajml: what if one site want to put web_base_dir somewhere else ? They will still have to chnage the code ?18:34
vilajml: the hierarchy about where the log files are stored have already changed18:35
jmlvila: then we'll deal with that use-case when we get to it?18:35
jelmervila: 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 ones18:35
vilajml: we *did* get to it, maxb created udd/paths by starting centralizing them18:35
jmlvila: ok, so I'm confused18:36
vilas/centralizing/to centralize/18:36
jmlvila: what do you want?18:36
vilaif 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 configured18: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 dir18:38
vilamore nightmare for testers18:38
vilaor any other alternate installation really18:39
vilaunless you want a setup.py ? or a proper package ?18:39
vilaand I still don't know how to add comments on symlinks and I really like having comments to describe such a hierarchy18:40
jmlwell, the start of having a proper package is getting the config file out of the branch18:40
vilajml: it was out of the branch and as such made the deployment harder18:40
BlackDexjelmer: In Natty i had to manualy gif my username and password, now i just get an error..18:41
BlackDexBut i try to config it so it doesn't use gnome-keyring now18:41
maxbWhy would we ever want a "proper" package?18:41
jmlvila: what do you suggest we do for our deployment then?18:41
jmlvila: maintain a fork?18:41
jmljust for the config?18:41
vilahaving your config file override the one in the branch and maintain it as you see fit18:42
jmlevery single setting18:42
jmlbetter not miss one18:42
maxbActually, what if we remove all the path configuration. ALL of it. Just find paths relative to the running script18:42
vilauntil we can make the options depend on each other as mentioned in the config file18:43
jelmerBlackDex: I think the difference is that svn now uses gnome-keyring by default18:43
jmlwait 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
vilajml: at which point you'll have only to define the differences which should be very narrow18:43
vilameh, 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 now18:44
james_wisn'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
jelmerBlackDex: svn in oneiric that is18:46
vilajames_w: yup, I have only minor (if even) objections to that one18:46
jelmervila: can you requeue the multi-tarball packages?18:46
vilajelmer: asap but I'm waiting for the importer to gracefully stop right now18:47
james_wvila, cool18:47
jmlvila: what sort of tests do you want for the other branch? self.assertEqual(paths.web_dir, os.path.join(root_dir, "www"))?18:47
BlackDexjelmer: It also seems i can't force it to store it as plaintext18:48
vilajames_w: i.e. if a config file is found take it, otherwise use the old one is perfectly fine with me18:48
BlackDexjelmer: Well there is only one way to bypass all this.. by putting the username and password in the branch.conf in front of the URL18:50
vilajml: 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 deployment18:50
vilajml: 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
BlackDexjelmer: If i want to create a bug report, where should i report this bug?? bzr-svn or bzr?18:52
jmlvila: ok.18:53
vilajml: 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 ;-P18:56
vilaand it's EOD ;)18:56
jmlvila: understood :)18:57
james_wvila, is http://paste.ubuntu.com/719082/ like what you are thinking for unit tests?18:59
vilajames_w: eeerk, base_dir is already define there but we still don't use it :-/19:03
vilajml: by the way, expanding the options *is* available in bzr-2.419:03
vilajml: which bzr version do you use or require for you pkgme ?19:04
james_wvila, defined where?19:04
jmlvila: I think anything better than 1.14 would work19:04
vilain pkgimport.conf19:04
james_wyes, and this branch makes it use it I thought?19:04
vilajml: hehe, seriously, are you constrained by some LTS support or something ?19:04
james_wthe second branch that I submitted19:05
jmlvila: probably we'll deploy on the IS standard: lucid19:05
james_wwe can ask for a newer bzr if it's needed, but we're not interested in making use of the expansion behaviour19:07
vilajml: urgh rmadison bzr =>  2.119:07
james_wand neither is package-import as far as I am aware19:07
james_wso I don't feel the need to do the work to allow configuration of paths that no-one wants to change at this point19:07
james_wwe do want to configure the base dir though19:08
james_wI think maxb's suggestion makes sense, but I don't know why I didn't just do that in the first place :-)19:08
james_wbut I can see that wanting to put the output somewhere other than where the code lives would desirable19:10
james_weven if it's not how it's deployed on package-import19:10
vilajames_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_wwe certainly could, but there was a big FIXME in the code when we found this, so we thought we would FIXIT19:12
james_wand perhaps IS will want to deploy to the same machine, we don't know yet19:13
vilajames_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 step19:19
james_wok, thanks19:20
lamalexhi, how to i delete my launchpad login info?19:54
peitschiemorning all :)22:56
pooliehi all23:14
jelmerhi poolie23:41
pooliehi there, how's cali?23:42
jelmersunny :)23:42
* jelmer bets Sydney is even sunnier23:47
pooliemm, not today, ~14C and cloudy23:48
poolieit was 36C and sunny on monday23:48
fullermdFortunately, we don't have any of those "C"'s in this country.  Sounds like a commit plot to me.23:49
jelmerfullermd: I'm in your country but I'm sticking to SI, thankyouverymuch. :-P23:49
fullermdOnoes.  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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!