| CarlFK | bzr revert -r 0; bzr pull - will that get me current rev? | 00:01 |
|---|---|---|
| CarlFK | I was doing some revert's looking for a bug, now i need to get back to 'trunk | 00:02 |
| fullermd | Highly doubtful. What's wrong with just 'revert'? | 00:19 |
| * fullermd isn't really here, just dropping by... | 00:19 | |
| CarlFK | revert did stuff. pull says "No revisions to pull." - did revert get the new commits ? | 00:27 |
| poolie | good luck to her, vila | 00:33 |
| poolie | CarlFK: 'revert -r 0' will take you back to an empty tree, which is strange | 00:33 |
| poolie | if you just want the currenty tree, use plain 'revert' | 00:33 |
| CarlFK | that's what I need. thanks | 00:34 |
| poolie | thanks for the release, too, vila | 00:36 |
| === medberry is now known as med_out | ||
| simosx | Is there a page with git + bzr equivalent commands? I want to perform a 'git reset --hard' in bzr and am looking for the command. | 09:02 |
| vila | simosx: I don't know any such page. What does reset --hard ? | 09:08 |
| vila | maxb: regarding bug #795703, this is what I meant http://paste.ubuntu.com/628306/ | 09:09 |
| ubot5 | Launchpad bug 795703 in Ubuntu Distributed Development "jubany fixups relating to misplaced tags (AssertionError:<module>:main:find_unimported_versions:check)" [Undecided,New] https://launchpad.net/bugs/795703 | 09:09 |
| vila | Riddell: _o/ | 09:09 |
| Riddell | good morning | 09:10 |
| Riddell | today is a good day to code | 09:10 |
| vila | :) | 09:11 |
| simosx | vila: 'git reset --hard' will reset any modified files to the repository initial state. | 09:12 |
| simosx | vila: what I want to do is to reject my repository modifications (which were not committed) so that I can start over. | 09:14 |
| vila | simosx: both the working tree (file content on disk) and the branch pointer (where should the history start) ? | 09:14 |
| vila | ha, right, so just 'bzr revert' then | 09:14 |
| vila | check 'bzr help revert' | 09:15 |
| maxb | Hi vila | 09:15 |
| simosx | vila: thanks, it worked! | 09:15 |
| vila | hey maxb ! Trying to clear the pi queue a bit | 09:17 |
| maxb | For me, the main reasons I did not want to add any helpers to the udd branch for bug 795703 are: I don't want to write a general tool when I'm uncertain of the need, and, the intent of my changetag and removetag definitions is clear even without looking at the implementation | 09:17 |
| ubot5 | Launchpad bug 795703 in Ubuntu Distributed Development "jubany fixups relating to misplaced tags (AssertionError:<module>:main:find_unimported_versions:check)" [Undecided,New] https://launchpad.net/bugs/795703 | 09:17 |
| maxb | I have decided to not care about the pi queue until bug 797008 is fixed (Monday) | 09:18 |
| ubot5 | Launchpad bug 797008 in cgal (Ubuntu) "Sync cgal 3.8-1 (multiverse) from Debian unstable (non-free)" [Wishlist,Fix released] https://launchpad.net/bugs/797008 | 09:18 |
| vila | maxb: I got that, read my last comment ? | 09:18 |
| maxb | uh | 09:18 |
| maxb | bug 797088 | 09:18 |
| ubot5 | Launchpad bug 797088 in Ubuntu Distributed Development "Launchpad has removed privileges that UDD importer requires to function" [Critical,New] https://launchpad.net/bugs/797088 | 09:18 |
| vila | maxb: ha, right, it's needed to change the tags too ? | 09:18 |
| maxb | Well, in most cases, changing the tags will allow a formerly broken import to proceed, which will most likely result in it wanting to create new branches | 09:19 |
| vila | bah, yeah, of course | 09:19 |
| maxb | That's only a "likely". Some of them could probably complete successfully | 09:20 |
| vila | ok, anyway, my point is not to write a generic tool but to focus on avoiding user errors, you know, the kind that happen when people make tyops | 09:20 |
| vila | and also collect data about how we fix issues in a more central place than the bugs | 09:21 |
| vila | maxb: so, the script I pasted above is intended to be sourced so 1) we/I don't have to remember to set PYTHONPATH, BZR_PLUGINS and so forth each time I need to issue such a command, 2) collect the patterns | 09:25 |
| === marienz is now known as 92AAC5BT0 | ||
| vila | maxb: any feedback before I propose it or should I just fdi ? | 09:26 |
| maxb | Re typos - what extra checking were you envisaging in this case? Re data collection - I agree recording repeated failure cases is good - but I don't think changetag and removetag scripts would accomplish that. | 09:26 |
| === 92AAC5BT0 is now known as marienz | ||
| maxb | Uh, what paste? I don't see it | 09:27 |
| vila | grr, damn xchat | 09:27 |
| maxb | oh, now I do | 09:27 |
| maxb | just way up ^^^^^ there | 09:27 |
| vila | ha, good, I thought I forgot to type enter somewhere | 09:28 |
| maxb | hmm | 09:28 |
| maxb | OK, I have several different observations about that | 09:29 |
| maxb | One, I really dislike that the various python scripts require certain environment variables to be set to work properly | 09:29 |
| maxb | My preferred way to address that would be making them not require that, rather than adding wrappers which set those envvars | 09:29 |
| maxb | A number of the scripts already contain sys.path manipulation towards this goal | 09:30 |
| vila | yeah sure, I agree with that but practicality beats purity, I want a working solution *now*, I sear I want to make it right later | 09:30 |
| vila | s/sear/swear/ | 09:31 |
| vila | And I really mean it | 09:31 |
| maxb | Two, do ubuntu: and debianlp: work from jubany? Plain lp: does not, which is why I've been writing all commands in bug reports as bzr+ssh://bazaar.launchpad.net/+branch/ since the London sprint | 09:31 |
| vila | hence my efforts around pkgimport.conf. Your refactoring of icommon goes in the same direction and I appreciate that | 09:32 |
| vila | maxb: yes they do (at least they appear to for 'bzr tags') | 09:32 |
| vila | maxb: I suspect it depends on the commands. Did you already tried for 'tag' ? | 09:32 |
| maxb | hmm.... but, are they giving you a readonly http transport? | 09:32 |
| vila | dunno, certainly the same behavior than for lp:, that can be fixed easily in fixit.sh and we should fix it in bzr too (but we'll always lag on jubany which is still using 2.3) | 09:34 |
| maxb | Additionally, I do not like ubuntu: and debianlp: - it feels very unnecessary to introduce yet another syntax. Especially for debianlp: which saves only one character over lp:debian/ | 09:36 |
| vila | maxb: implementation detail ;) | 09:36 |
| vila | ha no, it leaks in the echo's | 09:37 |
| maxb | OK, I have more to say about implementation details, but only that | 09:37 |
| vila | no no, keep going, I'll fix that | 09:37 |
| maxb | For example: | 09:37 |
| maxb | * If it is intended to be sourced, it should not have a #! line | 09:37 |
| vila | ! | 09:38 |
| maxb | * Using == inside a shell [ a == b ] is a bashism, so I try to always write [ a = b ] | 09:38 |
| maxb | * I'm quite picky about my shell quoting, and in this case $@ is not sufficiently quoted - should be "$@" | 09:39 |
| vila | maxb: but isn't that forbidding adding more flags ? | 09:39 |
| maxb | No, "$@" is magic, and expands to multiple arguments | 09:39 |
| vila | wow, in all shells ? | 09:40 |
| maxb | In all shells likely to be encountered in a modern Linux distribution :-) | 09:40 |
| vila | ok | 09:41 |
| vila | about being picky, why don't you use ${xxx} instead of $xxx ? | 09:41 |
| maxb | Why would I use a longer syntax if the shorter one is completely equivalent :-) | 09:42 |
| maxb | I am picky about quoting just in case my variables ever end up containing spaces or shell metacharacters in their values | 09:43 |
| maxb | However, the use of braces around a variable or not is verifiably right or wrong just by looking at the code, without having to consider variable values | 09:44 |
| vila | right, but it means it's not completely equivalent indeed :) | 09:45 |
| vila | fair enough, we have the same concern about different cases ;) | 09:46 |
| === shadeslayer_ is now known as shadeslayer | ||
| vila | maxb: we probably want to restart mass_import next time we pull on jubany. Not strictly needed but I dislike running code that is not on disk anymore | 09:58 |
| maxb | Yes... I have not pushed that point because I'm still moving stuff around even more | 09:59 |
| vila | maxb: ok, keep going ! ;) That was just a reminder for all parties involved ;) We need a losa to restart it | 10:00 |
| maxb | !? | 10:00 |
| maxb | really? | 10:00 |
| maxb | That seems.... silly | 10:00 |
| maxb | Especially given we don't need a LOSA to stop it | 10:00 |
| vila | well, that's the way it is... | 10:02 |
| maxb | Blah | 10:03 |
| vila | Don't get me started on that :) | 10:03 |
| maxb | I'm glad my workplace is much better about not blocking people on an overworked subset of people with root@ | 10:04 |
| maxb | Hmm. technically we could stop mass_import.py and restart it. Just not via sysvinit :-) | 10:05 |
| maxb | Aaaanyway.... | 10:06 |
| maxb | Why do we need to run the imports with LANG="en_GB.UTF-8"? | 10:06 |
| maxb | Is it just in an attempt to make bzr happy about unicode filenames? | 10:07 |
| maxb | Because it doesn't seem to actually accomplish that | 10:07 |
| vila | probably, the locale is not set otherwise | 10:07 |
| vila | huh ? | 10:08 |
| maxb | When I retried the import of the UnicodeDecodeError failures, approximately one third completed successfully for me locally | 10:08 |
| vila | ha, well, running with an appropriate local doesn't mean there is no more unicode bugs in bzr ;-} | 10:09 |
| maxb | I'm fairly sure I was using bzr 2.3.3 at the time | 10:09 |
| maxb | Isn't jubany on that too? | 10:10 |
| vila | 2.3.1 | 10:11 |
| maxb | hmm | 10:11 |
| * maxb afk ----> office | 10:12 | |
| vila | maxb: have a nice day and thanks for the feedback | 10:13 |
| maxb | you're welcome - looking forward to a nice decrease in the failure count come Monday | 10:41 |
| jelmer | vila: hah, you noticed the extra self.debug() too | 11:39 |
| vila | jelmer: well, while validating the release for once and when babune turned red, yes, I noticed ;0) | 12:30 |
| vila | jelmer: I'm cursed. This happens *only * when I don't run the tests just one last time to be sure ;) | 12:30 |
| jelmer | vila: :) | 12:31 |
| jelmer | vila: I patched it out in the Debian packages (just uploaded) | 12:32 |
| fullermd | Well, if you ran the tests one fewer time, it wouldn't turn red :p | 12:32 |
| vila | jelmer: because you *had* to or just because you noticed ? (And yes, I thought about builds and was wondering which testtools versions were in the wiled) | 12:32 |
| vila | fullermd: hehe, babune has its own life, I'm only serving it ;( | 12:33 |
| vila | rhaa :-) | 12:33 |
| fullermd | Vger seeks the Creator? :p | 12:33 |
| jelmer | vila: I had to, Debian has a newer version of testtools | 12:33 |
| vila | fullermd: hehe | 12:34 |
| jelmer | vila: thanks for doing the release btw | 12:35 |
| jelmer | vila: There are a few more failures on the debian buildds because of missing homedirectories | 12:35 |
| jelmer | vila: this seems to happen every other release; would it perhaps be possible to have a nonexistant home directory on one of the babune slaves? | 12:35 |
| vila | jelmer: yeah, that's a deeper issue but one we may consider to be an isolation one | 12:36 |
| vila | jelmer: hmm, no ${HOME} at all will be tricky to setup, but running with HOME unset may be doable | 12:37 |
| jelmer | vila: With $HOME set to a nonexistant directory perhaps? | 12:37 |
| jelmer | that's what happens on the buildds at least | 12:38 |
| vila | trying locally this fails early with: failed to open trace file: [Errno 2] No such file or directory: '/foobar/.bzr.log' :) | 12:40 |
| vila | ok, with BZR_LOG set it's running | 12:41 |
| vila | jelmer: hmm, but no failures... | 12:45 |
| jelmer | vila: whoa, it's already done running the testsuite? | 12:45 |
| vila | Ran 26750 tests in 212.707s | 12:46 |
| vila | re-trying without BZR_PLUGIN_PATH (since HOME is invalid there are no plugins there) shouldn't be different but let's see | 12:46 |
| jelmer | File "/build/buildd-bzr_2.4.0~beta4-1-i386-H_tSaY/bzr-2.4.0~beta4/build/lib.linux-i686-2.6/bzrlib/tests/__init__.py", line 2164, in _subprocess_log_cleanup | 12:47 |
| jelmer | with open(log_file_path, 'rb') as log_file: | 12:47 |
| jelmer | IOError: [Errno 2] No such file or directory: '/home/buildd/.bzr.log' | 12:47 |
| * vila checks /foobar really doesn't exist | 12:47 | |
| vila | ARGH, it catches plugins installed system-wide, qbzr windows all over the screen 8-) | 12:49 |
| vila | right, but still no failures related to HOME (if I remember correctly the failures expected from qbzr) | 12:50 |
| vila | jelmer: summary: I can't reproduce. Wth is going on then ? | 12:51 |
| vila | jelmer: did you fix some of those (then how) or are you just ignoring them ? | 12:53 |
| jelmer | vila: I'm trying to reproduce it here as well but failing | 12:53 |
| jelmer | https://buildd.debian.org/fetch.cgi?pkg=bzr&arch=i386&ver=2.4.0~beta4-1&stamp=1308309988&file=log is the log from the buildd | 12:54 |
| jelmer | HOME is set to something that doesn't exist, and we override BZR_HOME to point at something that does exist | 12:54 |
| vila | lol, I didn't see "graphical" boxes like that for... 20 years ? :D | 12:55 |
| vila | ...and clearly there are nicer that all the fancy stuff kids use today... | 12:55 |
| jelmer | vila: :) | 13:00 |
| * jelmer still remembers the "Alt" numbers for generating most of those | 13:01 | |
| vila | jelmer: hey ! But this is running with BZR_HOME=debian/bzrhome (I won't mention -user in BZR_PLUGIN_PATH ;-p) how come we end up with /home/buildd ... | 13:01 |
| jelmer | vila: /home/buildd is the home directory of the user that runs the process (a path that doesn't actually exist) | 13:01 |
| vila | I got that, but... isn't BZR_HOME supposed to override HOME... or is it only for .bazaar ? | 13:02 |
| vila | jelmer: this sounds like a genuine bug to me, you should file one (ot three) ;) | 13:09 |
| vila | trace._get_bzr_log_filename() respect BZR_LOG and BZR_HOME (unless none is set in which case it fallbacks to os.path.expanduser('~') which may do the wrong thing here | 13:11 |
| jelmer | vila: I think BZR_HOME is only for ~/.bazaar | 13:11 |
| vila | jelmer: no, just checked ;) see ^^ | 13:11 |
| vila | jelmer: this one is really puzzling... I can imagine that the log file is recorded in the cleanups even if it's not written too but I can't find an explanation for the wrong path... | 13:16 |
| vila | jelmer: i.e. it may that the fix is simply to catch NoSuchFile but that will be masking a deeper issue... | 13:17 |
| vila | like a test isolation bug *except* that TestExceptionReporting directly inherit from TestCase where we unset HOME... | 13:18 |
| vila | BAH ! | 13:18 |
| vila | Stoopid vila ! | 13:18 |
| vila | repeat after me: you should never use TestCase if you need disk resources ! | 13:18 |
| fullermd | Hm. So, if I removed all the TestCase's in my local bzr, I'd have more disk resources? | 13:19 |
| vila | right, especially under /tmp ;) | 13:20 |
| vila | jelmer: didn't we allow trace.mutter() and friends to fail silently recently ? | 13:21 |
| vila | jelmer: did you file a bug or should I ? I still don't understand how we end up with a bad path, but I see why we end up with a path | 13:31 |
| jelmer | vila: I think the problem really is in the cleanup code | 13:31 |
| vila | jelmer: there is an isolation issue escaping me but there are already bugs to fix that will address your problem | 13:31 |
| vila | partly | 13:31 |
| jelmer | vila: which requires the path to always exist - previously it used a testtools method which didn't as far as I can tell | 13:31 |
| vila | well, the issue is that it capture a path that is not used and fail to catch NoSuchFile, that's one bug | 13:32 |
| vila | a second one is that some test use TestCase when they really want TestCaseInTempDir at least | 13:33 |
| vila | a third one is this bogus path | 13:33 |
| vila | for the first one, I'm not sure we should check the file exist (at that doesn't mean it won't be written to later by the test) | 13:34 |
| vila | so we may want to catch NoSuchFile, *but* that will mask the other two which is bad | 13:34 |
| jelmer | hmm | 13:37 |
| jam | hi all, I just uploaded the bzr-2.4b4-1-setup.exe | 13:41 |
| jam | anyone care to give it a quick spin so I can see if it is good enough to shut down the build machine? | 13:41 |
| fullermd | You need to make some change and upload a new one. It's _sooo_ close to a palindrome... | 13:41 |
| vila | oooooh, let's prey for a bug ;) | 13:42 |
| jam | 2.4b4-2 is still not a palindrome | 13:42 |
| vila | jam: did you remove the infamous self.debug() ? | 13:42 |
| fullermd | Blech. I only prey on things with fewer than 6 legs. | 13:42 |
| jam | vila: I used whatever you tagged as 2.4b4 | 13:42 |
| jam | so probably not | 13:42 |
| jam | we'd first have to change the numbering scheme | 13:42 |
| jam | since 2.4b4-2 isn't 2.4b4.2 | 13:42 |
| vila | when I say it out loud I don't pronounce the dots ;) | 13:43 |
| jam | vila: funny, I do. "two point four bee four dash one" | 13:44 |
| fullermd | Dit, Dat, and Dot. | 13:44 |
| vila | jam: that may have to do with a cultural thing :) | 13:45 |
| jam | I might say "bzr two four" | 13:45 |
| jam | but the b and final dash mess things up | 13:45 |
| vila | s/[.-\/#/ ftw | 13:46 |
| Riddell | jam: so you need a test of getting the file from launchpad and installing on windows? | 13:46 |
| vila | crap | 13:46 |
| vila | s/[.-]/#/ ftw | 13:46 |
| * vila notes Riddell stepped up to build windows installers | 13:47 | |
| vila | :-P | 13:47 |
| Riddell | test! I said test! | 13:47 |
| vila | I heard 'I can' and 'windows' :D | 13:48 |
| maxb | aww | 13:49 |
| maxb | You scared him away | 13:49 |
| vila | LOL | 13:49 |
| maxb | beta-ppa/natty uploaded | 13:50 |
| * maxb goes in search of lunch before doing the other series | 13:50 | |
| vila | nahhh, he tried the installer while being connected on IRC, we'll soon get our emordnilap | 13:50 |
| fullermd | It's a doubly fun palindrome, really, because even as you say it, you know that it's not really true that 2 4 is before 2 ;) | 13:53 |
| vila | yeah, it will become true only for 2.4b4-25 | 13:54 |
| fullermd | Well, you never know... it IS windows, so maybe we'll end up there :p | 13:54 |
| vila | yeah, you're allowed a few false starts when learning how to build them, definitely a sign for Riddell | 13:56 |
| === luks_ is now known as luks | ||
| Riddell | jam: installs and working fine | 14:09 |
| Riddell | windows is painful, takes 10 minutes to start up as it does updates setup, 10 minutes to log in as it does updates config then 10 minutes to shut down as it does updates install | 14:10 |
| Riddell | given a revision id how do I get the revision number? branch.revision_id_to_revno() doesn't work for commits from merged branches | 14:11 |
| vila | . o O ( 15:08 - 14:47 = 21 minutes, 30 minutes lost in windows, ~10 minutes download + tests => Riddell *owns* a time machine, damn it !) | 14:13 |
| fullermd | It's not really a time machine, just relativity. Windows is so dense that when you get close to it, time slows down. | 14:13 |
| Riddell | :) | 14:13 |
| Riddell | I'm not convinced by the widget theme used by bzr explorer, it doesn't seem to fit in with much of windows, but maybe that's just normal for windows | 14:15 |
| mdeslaur | I get bug #798688 with the bzr in natty-proposed | 14:19 |
| ubot5 | Launchpad bug 798688 in bzr (Ubuntu) "possible regression in natty-proposed" [Undecided,New] https://launchpad.net/bugs/798688 | 14:19 |
| jelmer | mdeslaur: hi | 14:19 |
| mdeslaur | hi jelmer | 14:19 |
| jelmer | mdeslaur: "bzr up" there works fine with 2.3.1? | 14:21 |
| mdeslaur | jelmer: let me try, one sec | 14:21 |
| mdeslaur | jelmer: oh, hrm, this is what I get with 2.3.1: | 14:22 |
| mdeslaur | mdeslaur@mdlinux:~/uct/ubuntu-cve-tracker$ bzr update | 14:22 |
| mdeslaur | Unable to obtain lock held by sbeattie@bazaar.launchpad.net | 14:22 |
| mdeslaur | at crowberry [process #31170], acquired 4 hours, 22 minutes ago. | 14:22 |
| mdeslaur | See "bzr help break-lock" for more. | 14:22 |
| mdeslaur | bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/ | 14:22 |
| mdeslaur | jelmer: much clearer | 14:22 |
| jelmer | mdeslaur: ah, hmm | 14:23 |
| jelmer | mdeslaur: thanks for the bug report | 14:23 |
| jelmer | time to abort that sru I guess :-/ | 14:23 |
| mdeslaur | jelmer: I'll add that to the bug | 14:23 |
| mdeslaur | jelmer: ok, thanks, I'll downgrade for now | 14:24 |
| jam | Riddell: thanks for the sanity check | 14:25 |
| jam | did you check that bzr+ssh worked? | 14:25 |
| jam | (py2exe and setuputils don't get along very well, so every so often I forget to easy_install -Z and an updated package is removed from the installer) | 14:26 |
| vila | jelmer: ok, got the bogus path explanation | 14:27 |
| jelmer | vila: cool - what was it? | 14:28 |
| vila | jelmer: BZR_HOME is set to None by the test (as does HOME) *but* os.path.expanduser('~') *still* returns it (probably from /etc/passwd or something) | 14:29 |
| Riddell | jam: no, should I just try a checkout? | 14:29 |
| vila | jelmer: so, using TestCase instead of TestCaseInTempDir is really the root cause | 14:29 |
| jam | Riddell: just 'bzr info lp:bzr' is enough | 14:29 |
| vila | jelmer: even if the symptom is confusing | 14:29 |
| jam | just making sure that Paramiko is available | 14:29 |
| vila | cough | 14:29 |
| jelmer | vila: ah! | 14:30 |
| vila | Riddell: make sure you did bzr launchpad-login or you will default to http | 14:30 |
| vila | jelmer: I'm working on a patch | 14:30 |
| jelmer | vila: great :) | 14:30 |
| vila | jelmer: I just need a bug # ;) | 14:31 |
| jelmer | vila: happy to file one | 14:32 |
| vila | jelmer: confirmed, in posixpath the comments are lying like hell, even with HOME unset they access pwd.getpwuid(os.getuid()).pw_dir | 14:32 |
| vila | jelmer: hmm, so the root root cause is a side-effect of spiv's clever trick to collect subprocess log files | 14:34 |
| jelmer | vila: bug 798698 | 14:34 |
| ubot5 | Launchpad bug 798698 in Bazaar " bzrlib.tests.test_selftest.TestStartBzrSubProcess test break if $HOME does not exist" [Medium,Triaged] https://launchpad.net/bugs/798698 | 14:34 |
| jelmer | vila: yeah, the use of "with" there suggests it was recently changed :) | 14:34 |
| vila | switching to TestCaseInTempDir still sounds like the easiest path despite the cost (not that many tests impacted) | 14:35 |
| vila | the funny thing is that (may be while reviewing it but recently anyway) I realized that *defining* run_bzr on TestCase was a bit weird as it's quite hard to run bzr without any disk access (config files, log files, etc) | 14:36 |
| vila | but trying to move it to TestCaseInTmpDir revealed some valid use cases, so I punted. I should have tried harder ;) | 14:37 |
| vila | jelmer: great thanks | 14:37 |
| Riddell | jam: unable to authenticate to ssh host as use jr@... | 14:42 |
| Riddell | I've no idea how to import my ssh keys into windows | 14:42 |
| jam | Riddell: well, you may not have your key, but at least it didn't tell you it couldn't try | 14:42 |
| vila | jelmer: hehe, now that I'm fixing the bug, I *can* reproduce it :D | 14:42 |
| vila | bah | 14:42 |
| Riddell | groovy | 14:42 |
| jam | Riddell: I could walk you through it if you care, but that is enough of a test for what I needed | 14:42 |
| Riddell | then I don't care :) | 14:43 |
| vila | with a first fix (wrong obvously :), I reproduce the bug | 14:43 |
| vila | haaaaa, finally, I understand... | 14:46 |
| vila | jelmer: except for your build, the tests were succeeding because they wrongly grabbed ~/.bzr.log | 14:46 |
| vila | so we need to catch NoSuchFile after all _/ | 14:47 |
| vila | :-/ | 14:47 |
| jelmer | vila: ahh :-/ | 14:47 |
| vila | owwww, to add insult to injury, I now find: XXX: Testtools 0.9.5 doesn't have the content_from_file helper which is why I ended up leaving a self.debug() yesterday >-/ | 14:49 |
| vila | jelmer: do you have a way to reproduce or do you need a true release to do that / | 14:54 |
| vila | ? | 14:54 |
| jelmer | vila: I don't really have a way to test other than to do a new upload to Debian | 14:55 |
| jelmer | vila: (doesn't have to be an upstream bzr release) | 14:55 |
| vila | right, so the fix is at lp:~vila/bzr/798698-bogus-log-files but needs polish | 14:56 |
| vila | jelmer: there was really two bugs: test_exceptions needs a log file (I still don't know how it can succeed without one, I suspect we tolerate having no .bzr.log file) | 14:57 |
| vila | so it should use TestCaseInTempDir | 14:58 |
| vila | TestStartBzrSubProcess ~stubs run_bzr, so it should inhibits _subprocess_log_cleanup (totally avoiding the issue) | 14:58 |
| jelmer | vila: Thanks | 14:59 |
| vila | waitase | 14:59 |
| jelmer | hmm? | 14:59 |
| vila | use revno 5987 | 14:59 |
| vila | TestStartBzrSubProcess can still use TestCase | 15:00 |
| vila | jelmer: now to write test for that.... | 15:03 |
| vila | jelmer: I think you were right from the beginning, having a build slave may be the easiest (surprisingly ;) | 15:03 |
| vila | I need a setup where the user exist but has no home but it still able to run selftest 8-) | 15:04 |
| workthrick | hiya, what's the place I'm supposed to dump extra libs in for the win32 standalone bzr? | 15:11 |
| workthrick | ahh, it was plugins/$plugin/_lib as I thought, it's just that bzr branch lp:dulwhich does not result in a pure lib directory structure | 15:16 |
| jelmer | hi workthrick | 15:27 |
| workthrick | hey jelmer | 15:30 |
| workthrick | I was a tad busy and didn't really have the time to work on git-fileids | 15:30 |
| Riddell | jamesh: could you take a look at the bzrlib/gpg.py verify method I added sometime, to make sure I'm using gpgme in a sane way? | 16:15 |
| === med_out is now known as med | ||
| === med is now known as medberry | ||
| maxb | jelmer: Hi. At some point between pushing 2.4.0~beta4-1 and -2 today, you somehow moved the 2.4.0~beta4-1 tag to a revision that is not in the alioth branch | 19:00 |
| maxb | jubany request - please requeue_package.py euca2ools | 19:45 |
| maxb | flacoste has changed stuff that should allow the importer to create *Debian* official links now (but not Ubuntu until the next deploy) | 19:45 |
| james_w | maxb, done | 19:55 |
| maxb | looks like it has successfully pushed back :-) | 19:57 |
| maxb | requeue_package.py bootchart clementine cqrlog extundelete fonts-oldstandard gerris glade gnome-desktop3 gtksourceview3 haskell-cookie haskell-cryptohash haskell-lambdabot-utils haskell-largeword haskell-monadrandom haskell-ranged-sets helium hunspell-ml jalv jcaptcha key-mon letodms libirc-utils-perl libjemmy2-java libnet-dropbox-api-perl libpam4j libsocket-linux-perl localizer openvrml php-letodms-core python-coverage-test-runner python-llfuse r-b | 20:00 |
| maxb | ioc-edger rt-extension-assettracker ruby-activeresource-2.3 ruby-activesupport-2.3 ruby-git ruby-highline ruby-hoe ruby-rails-2.3 ruby-shoulda skytools3 virtualbox xyscan | 20:00 |
| maxb | ^ the rest of the ones which have a good chance of succeeding now | 20:00 |
| james_w | is it r-bioc-edger in the middle there? | 20:01 |
| maxb | yes | 20:01 |
| maxb | curse silly protocols with arbitrary length limits :-) | 20:01 |
| james_w | done | 20:01 |
| james_w | we should really make this a push button that you can press :-) | 20:02 |
| maxb | Hmm... maybe - usually a requeue alone is not enough though | 20:03 |
| maxb | I'd have to become a core-dev first :-) | 20:03 |
| james_w | yeah, I don't think we could easily get rid of shell access completely, but if you could trigger requeue_package calls it would be a start | 20:04 |
| maxb | Hmm, so euca2ools failed again, but it seems to have updated the oneiric branch before it died, so I'm calling that a partial success :-) | 20:05 |
| james_w | heh | 20:06 |
| maxb | Hmm, I should make the status page display the result of SELECT COUNT(*) FROM commits | 20:07 |
| maxb | To quantify the number of packages with branches sitting on jubany waiting to be pushed back, if only the pushback run would not die | 20:07 |
| === yofel_ is now known as yofel | ||
| === medberry is now known as med_out | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!