| === r0bby is now known as robbyoconnor | ||
| wgz | happy unmorning | 06:50 |
|---|---|---|
| wgz | bus time. | 07:39 |
| vila | hi all ! | 07:56 |
| mgz | morning! | 09:23 |
| vila | mgz: hey ! | 09:23 |
| vila | mgz: Is this the day you can tweak the pqm conf ? :-D | 09:23 |
| mgz | yes. | 09:24 |
| mgz | ...though, did we get anything out of mthaddon about where the right place to look is? | 09:24 |
| mthaddon | eh? | 09:25 |
| vila | mthaddon: there is a config file for pqm where we can set some bzr options to avoid conflicts in our news file, we don't know where exactly but we know the settings are wrong or not recognized :) | 09:26 |
| mthaddon | vila: so what do you want to see? | 09:27 |
| vila | mthaddon: the pain point for us is that the submission fails, we merge locally (with the right settings and hence no conflicts) and resubmit | 09:27 |
| vila | mthaddon: it's probably either a locations.conf or pqm.conf file which mentions the various branches | 09:28 |
| mthaddon | vila: sure, but what value are you interested in in the PQM config? | 09:28 |
| vila | more probably locations.conf, the misunderstandings we have is which one is taken into account when the merge occurs | 09:28 |
| mthaddon | pqm@cupuasso:~$ cat .bazaar/locations.conf | 09:29 |
| mthaddon | [/srv/pqm.bazaar-vcs.org/archives/thelove] | 09:29 |
| mthaddon | post_commit_to = bazaar-commits@lists.canonical.com | 09:29 |
| mthaddon | that's all there is in locations.conf | 09:29 |
| vila | hmm, are the 2.x branches *below* thelove ? | 09:31 |
| mthaddon | vila: that's the entire contents of the file | 09:31 |
| mgz | the one we looked at previously was https://pastebin.canonical.com/57193/ | 09:32 |
| mgz | which is not the current one, then. | 09:33 |
| mthaddon | so that was probably from the previous server | 09:33 |
| vila | right, so we need more sections there for trunk at least, and ideally for 2.4, 2.3 etc | 09:33 |
| mgz | okay, that's what we need to know, can bug gnuoy in a second to do the changes we want | 09:34 |
| mthaddon | vila, mgz: can you create an RT with what you need - we'll want to make sure the added configs are puppetised | 09:34 |
| mthaddon | please don't just have it added manually, or it'll fail if we ever have to move PQM again | 09:34 |
| vila | so [/srv/pqm.bazaar-vcs.org/archives/thelove/+trunk] (not sure about the + there :-/) | 09:34 |
| * vila nods | 09:34 | |
| vila | and news_merge_files = doc/en/release-notes/bzr-2.5.txt there (which will need to be updated when we start the 2.6 series, so definitely we want that to be puppetised) | 09:35 |
| mgz | do we want a section per release with the right files, or how would be best to manage this vila? | 09:37 |
| vila | jelmer, mgz: no laughing about my ignorance for url encoding in section names for locations.conf please ;-P | 09:37 |
| vila | one section per branch, I'm not sure pqm always preserve them so putting this option in branch.conf may be brittle (and I'm not even sure it's queried) | 09:38 |
| vila | them == the branches | 09:38 |
| mgz | okay, if you file the rt vila, I'll assist as needed when making the changes | 09:44 |
| vila | ha, let see if I can do that with an email mentioning the right people in CC | 09:45 |
| vila | mgz: sent, let me know if you receive it *and* if you also get notices from rt after that | 09:53 |
| mgz | vila: first mail arrived | 10:13 |
| vila | mgz: cool, note that these settings comes from a known working laptop so apart from the section names that needs to be updated it should be good | 10:19 |
| mgz | I think we don't need anything before 2.3 now | 10:21 |
| vila | we shouldn't | 10:21 |
| vila | on the other hand... if it doesn't seem too much trouble to add them too (if only to remember where the switch from NEWS occurred) | 10:23 |
| mgz | that's true, but it might be knowledge the l-osas could do without | 10:26 |
| vila | up to you :) | 10:27 |
| mgz | is tools/http_client.py still used by anyone or anything? | 10:58 |
| vila | I don't think so | 10:59 |
| jelmer | me neither | 11:00 |
| vila | blow it away, it's under version control :) | 11:00 |
| mgz | jelmer, can you paste whatever pqm complained about with your ssl branch to the mp? | 11:09 |
| mgz | seeing 'sent to pqm by email' as the last comment when nexting through approved reviews in hydrazine is slightly confusing | 11:09 |
| jelmer | mgz: so, I tried twice | 11:22 |
| jelmer | and both times I got an error from subunit saying that the test runner fell over | 11:23 |
| mgz | fun... putting what it said in the mp certainly seems useful then | 11:34 |
| jelmer | mgz: sure | 11:56 |
| jelmer | vila: hmm, did we not always apply quilt patches in udd? | 11:56 |
| vila | jelmer: hmm, my understanding was that the packagers decided what they track... applied or unapplied | 12:13 |
| vila | but to be honest I don't know where exactly this is done | 12:13 |
| jelmer | vila: we have to have a policy on what we do when we import packages though | 12:16 |
| vila | should we ? Or should we have an option so packagers can still decide ? | 12:17 |
| jelmer | vila: we already have a policy at the moment :) I'm just trying to find out if that policy has changed at some point | 12:18 |
| vila | I'd say go with whatever works for you as long as it doesn't break existing workflows | 12:18 |
| vila | oh, we have ? Always apply ? | 12:18 |
| jelmer | vila: this is about whether we version with patches applied (and create .pc/) or not | 12:18 |
| jelmer | nevermind, found it | 12:19 |
| jelmer | we only apply patches for 3.0 (quilt) packages, not for packages that use other patch systems | 12:19 |
| vila | I thought .pc wasn't required if either all patches were applied or not (i.e. required only when some of them are applied) | 12:19 |
| vila | ha | 12:19 |
| vila | but then we apply them all, right ? | 12:19 |
| jelmer | I think .pc is always required if some patches are applied | 12:20 |
| jelmer | I would like to see us move to not applying patches, but I'm not sure what the best approach to that is | 12:20 |
| vila | and applying them automatically when needed ? I thought barry was preferring working with patches applied... | 12:23 |
| jelmer | vila: yes, hooks for e.g. transform to apply them when we create a checkout or update | 12:23 |
| * vila freaks a bit about conflicts... | 12:24 | |
| jelmer | if applying one of them fails we just warn the user and let them deal with applying the patch | 12:25 |
| vila | and do so (from the hook) only if not conflicts are present right ? | 12:26 |
| jelmer | right, or if there are no conflicts present involving the files touched by the patch | 12:30 |
| vila | more delicate to get right and entering a thin ice zone | 12:35 |
| vila | the usual pain point is: you have uncommitted changes, do something, and suddenly you cannot revert this 'something' and you cry | 12:36 |
| * vila wishes there was an easy way to do some sort of commit-so-I-can-revert-but-dont-pollute-my-history | 12:37 | |
| fullermd | That's what colo is for ;p | 12:40 |
| mgz | +15/-1312 | 12:40 |
| jelmer | vila: you can go back since the state is tracked in .pc/ | 12:47 |
| vila | jelmer: oh, so if quilt create conflicts you can't 'bzr resolve' them ? | 12:49 |
| vila | mgz: ?? | 12:49 |
| vila | fullermd: almost ;) | 12:49 |
| mgz | left a few merge proposals for you to review while I have lunch vila :) | 12:50 |
| vila | pfew, I would not have guessed ;) | 12:50 |
| mgz | whoops, that's the problem with doing lots of merge proposals at once, I mixed up the descriptions... | 14:16 |
| vila | hehe, for once, may be you could have done a single one ;) | 14:16 |
| vila | mgz: and what is the python name ? utf-8 (lowercase ?) | 14:28 |
| mgz | yup. | 14:33 |
| vila | k | 14:35 |
| mgz | saves worrying about the nine billion names of ascii | 14:39 |
| mgz | slight hyperbole, with case and dash normalisation already done, python accepts: | 14:41 |
| mgz | ['iso_ir_6', 'ansi_x3_4_1968', 'ibm367', 'iso646_us', 'us', 'cp367', '646', 'us_ascii', 'csascii', 'ansi_x3.4_1986', 'iso_646.irv_1991', 'ansi_x3.4_1968'] | 14:41 |
| vila | 86 or 68 ? To catch tyops ? | 14:43 |
| Wiz_KeeD | hey guys | 14:52 |
| Wiz_KeeD | can any of you tell me how i can go back 1 revision with bzr? | 14:52 |
| Wiz_KeeD | i just made a pull and i think there are some bugs | 14:52 |
| mgz | vila: pqm news merge | 15:01 |
| mgz | with your new fancy config path segment thing | 15:02 |
| mgz | ah, nope, doesn't help for trunk... | 15:02 |
| * mgz scratches thought | 15:02 | |
| vila | put some trust in the old one, it has worked for quite some time :) | 15:03 |
| vila | err, by old one I didn't mean me or fullermd, but the old locations.conf ;) | 15:03 |
| mgz | vila: where's our current document for things to do when creating a new bzr series? | 15:04 |
| vila | releasing.txt but there is a losa wiki page, let me see | 15:04 |
| Wiz_KeeD | can anyone tell me how i can revert to the version before i did pull? | 15:05 |
| vila | Wiz_KeeD: bzr pull --overwrite -r<my-precious> | 15:07 |
| Wiz_KeeD | what's my previous? :)) | 15:07 |
| Wiz_KeeD | the number of the former revision | 15:07 |
| vila | precious :) | 15:07 |
| vila | generally yes | 15:07 |
| Wiz_KeeD | how do i find out which one was it | 15:07 |
| vila | if you have the bzr-tiplog plugin installed 'bzr tiplog' will tell you, | 15:08 |
| vila | otherwise, 'bzr pull' *did* tell you which version was current before the pull | 15:08 |
| vila | if you didn't notice, .bzr.log should still contain it | 15:08 |
| vila | 'bzr info' will tell you where to find it | 15:08 |
| vila | (the .bzr.log file that is) | 15:08 |
| vila | alternatively, try 'bzr qlog' and see which one it was | 15:09 |
| Wiz_KeeD | unknow command | 15:09 |
| vila | (qlog is part of the qbzr plugin and you will love it ;) | 15:09 |
| Wiz_KeeD | apt-get install qbzr? | 15:10 |
| vila | should do | 15:10 |
| Wiz_KeeD | bzr info doesn't tell me about the log | 15:11 |
| vila | meh, typo, I meant 'bzr version' | 15:12 |
| mgz | vila: was there any other reason not to use branch.conf for the news merge other than we were worried about it not working? | 15:13 |
| vila | yes, | 15:15 |
| vila | I'm not sure the branches on pqm are not scratched on occasion | 15:15 |
| vila | meh, too many negatives | 15:15 |
| vila | I suspect, the branches on pqm can be deleted sometimes | 15:15 |
| mgz | they may be, but it seems like there's config setup to populate them with the right values | 15:16 |
| vila | really ? | 15:16 |
| vila | how ? | 15:17 |
| mgz | various puppety thingies | 15:18 |
| * mgz keeps it technical | 15:18 | |
| vila | hehe | 15:19 |
| vila | all I'd like to know is whether a branch.conf file is created of if bzrlib is involved to populate it | 15:19 |
| Wiz_KeeD | i see no version number in the log | 15:20 |
| vila | Wiz_KeeD: can you find the offending pull ? | 15:20 |
| Wiz_KeeD | how can i do that? | 15:20 |
| vila | in the log file, each command output additional info, starting with its name and the parameters used | 15:23 |
| mgz | news merge puppet changes made, we should try something to see if it works in a sec vila | 15:25 |
| vila | \o/ err, no wait -o- | 15:27 |
| Wiz_KeeD | wut? | 15:28 |
| mgz | vila: done. have you got a change we can land that would fail without news merge, but succeeds with it? | 15:35 |
| vila | ha ! | 15:38 |
| vila | no :) | 15:38 |
| vila | https://code.launchpad.net/~vila/bzr/832046-globs-store-ordered/+merge/86734 possibly :) | 15:39 |
| vila | or may be I can tweak it for this purpose | 15:40 |
| mgz | that would be neat. | 15:41 |
| vila | Wiz_KeeD: bah, I mixed uncommit, pull and a merge proposal that wanted to display the revision *before* the pull | 15:41 |
| vila | Wiz_KeeD: qlog is your best bet to find your previous revision now | 15:42 |
| Wiz_KeeD | lol... | 15:42 |
| mgz | bug 912344 looks like one for you vila | 15:51 |
| ubot5 | Launchpad bug 912344 in QBzr "Bazaar explorer crashes when in browse and I try to show annotate on a file" [Undecided,New] https://launchpad.net/bugs/912344 | 15:51 |
| mgz | did set_user_option accept numbers previously? | 15:52 |
| vila | it should | 15:55 |
| vila | meh, or not ?? | 15:57 |
| vila | wow, so, bug #912344 is a bug in bzr that is triggered only for smart branches | 16:06 |
| ubot5 | Launchpad bug 912344 in QBzr "Bazaar explorer crashes when in browse and I try to show annotate on a file" [Undecided,New] https://launchpad.net/bugs/912344 | 16:06 |
| vila | the new implementation shouldn't suffer from it | 16:06 |
| vila | the trick is... better explain that on the bug ;) | 16:07 |
| vila | mgz: got it conflicting without the setting and merging properly with | 16:20 |
| vila | mgz: I'll need to properly restore the right order after merge :) | 16:20 |
| mgz | vila: net | 16:23 |
| mgz | +a | 16:23 |
| vila | care to review it ? ;-p | 16:24 |
| vila | I think I've addressed the points raised in the discussions | 16:25 |
| vila | mgz: ^ | 16:29 |
| vila | jelmer: you did review my monster cleanup ! You're a hero :-D | 16:42 |
| === abentley__ is now known as abentley | ||
| mgz | vila: what do you want reviewed sorry? | 16:45 |
| mgz | the globs branch? | 16:45 |
| vila | https://code.launchpad.net/~vila/bzr/832046-globs-store-ordered/+merge/86734 | 16:45 |
| vila | oh crap, I should push the tweak | 16:45 |
| vila | done | 16:46 |
| mgz | approved, let's try it out | 16:48 |
| vila | the new tests shouldn't break on windows... unless local_path_from_url involves disk access ? | 16:50 |
| mgz | local_path_from_url may throw on an invalid file:/// url, which those are on windows | 16:52 |
| mgz | I'd test it, but I'm afh | 16:52 |
| mgz | so, may as well let babune tell us | 16:52 |
| vila | k, will monitor | 16:52 |
| === yofel_ is now known as yofel | ||
| vila | mgz: osx slave is a bit busted but the last run add 2 more failures you may want to look at http://babune.ladeuil.net:24842/job/selftest-osx-10.6/400/ | 17:00 |
| mgz | thanks vila, will check | 17:01 |
| vila | hmm, 3 even, the 8 other are weird, I should have looked sooner :-/ | 17:02 |
| mgz | vila: the two test_locale failures are a deliberate change, just missed updating/killing the tests | 17:10 |
| vila | cool | 17:10 |
| vila | the test_mv_dirs_non_ascii looks older | 17:11 |
| mgz | the bb.test_commit failure might need a require-filessystem-that-doesn't-normalise | 17:11 |
| mgz | it's a new test, that just happens to hit our existing osx non-ascii filename issues | 17:12 |
| mgz | do you know how this is handled elsewhere? | 17:12 |
| vila | the others appear when I fix the race in revno 6337 ???? non-sense | 17:13 |
| vila | justasec, I think there is a feature already for that no ? | 17:13 |
| vila | nope, but CaseInsCasePresFilenameFeature should give some hints | 17:14 |
| mgz | or I can work around by not using a character that decomposes :) | 17:15 |
| mgz | \xa7 is the best! | 17:16 |
| vila | ... and lose the opportunity to fix a bug ? ;) | 17:16 |
| vila | or is it really a bug in the test ? | 17:16 |
| mgz | ...I may tackle the root issue at a future junction :) | 17:16 |
| vila | hehe | 17:16 |
| mgz | it's the bug with all handling of names on OSX where NFC(s)!=NFD(s) | 17:17 |
| vila | with ExpectedFailure_on_osx: :) | 17:18 |
| mgz | in this case it's not the issue we're concerned about, so there's no point tickling it in the test | 17:20 |
| vila | I was kidding ;) | 17:21 |
| mgz | :) | 17:23 |
| mgz | I'm not sure what to do about the locale tests for OSX | 17:24 |
| mgz | previously on OSX, if LANG was none, we used utf-8 | 17:25 |
| mgz | now we also use UTF-8 if LANG is C or something bogus | 17:25 |
| vila | sounds reasonable | 17:26 |
| vila | right now, I'm connected to an osx host via ssh and locale is C | 17:26 |
| mgz | but I XXXed for nix rather than doing the same change, as it's less pervasively unicode supporting | 17:26 |
| vila | but it's pretty hard to get there ;) Most of the time you get some utf8 variant | 17:27 |
| vila | well, when I say locale is C... http://paste.ubuntu.com/793954/ | 17:28 |
| * vila blinks | 17:34 | |
| vila | getaddrinfo doesn't recognize 'localhost' but still accept '127.0.0.1 | 17:34 |
| vila | on osx that is, but still, end of internet predicted or what ? | 17:34 |
| mgz | heh. well, use the number then, and be happy. | 17:35 |
| mgz | fix for one of the failures sent, home time now. | 17:36 |
| vila | AFAIK we used the name for years... Have a safe trip ! | 17:36 |
| vila | wgz: In case you read the logs, the merge failed with a conflict in the release notes :-/ | 17:50 |
| === deryck is now known as deryck[lunch] | ||
| wgz | vila: any sign from pqm if the news merge was invoked at all? | 18:34 |
| wgz | I know that spiv tried previously to get it enabled and ran into some issue, but I don't know what it was. | 18:35 |
| wgz | hm, my last merge failed too, on: | 18:39 |
| wgz | error: bzrlib.plugins.launchpad.test_lp_directory.TestDebuntuExpansions.test_bogus_distro [ multipart | 18:39 |
| wgz | InvalidHttpResponse: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway | 18:39 |
| jelmer | intermittent issue with launchpad availability? | 18:42 |
| jelmer | it's pretty bad we have tests that connect to launchpad :-/ | 18:42 |
| wgz | yeah... | 18:43 |
| === Quintasan_ is now known as Quintasan | ||
| === deryck[lunch] is now known as deryck | ||
| vila | <vila> wgz: In case you read the logs, the merge failed with a conflict in the release notes :-/ | 19:59 |
| vila | mgz, jelmer: for pqm, yes, test suites can be far more agile than what we do on pqm, we should make the launchpad tests run only when some flag is active | 20:01 |
| wgz | vila: I replied :) | 20:02 |
| vila | ha, sorry, misunderstood | 20:02 |
| vila | so, the mail is pretty terse and I don't think the plugin outputs anything outside of the log so... | 20:03 |
| vila | Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.5.txt | 20:03 |
| vila | is all I have ;) | 20:03 |
| vila | wgz: did you set the options in branch.conf or locations.conf (both should work anyway, I've checked the code) | 20:04 |
| wgz | vila: branch.conf | 20:11 |
| vila | my little daemon giggles... but refuses to tell me why, damn it | 20:12 |
| spiv | wgz: the issue was "turned it on but nothing happened" | 23:02 |
| spiv | wgz: and it wasn't really worth sinking a heap of time into trying to debug it | 23:03 |
| lifeless | remember that pqm uses a temp dir to do the work | 23:03 |
| Noldorin | hi jelmer | 23:16 |
| wgz | spiv: well, at least that's consistent with today's observations then... :) | 23:27 |
| spiv | wgz: we backed out the changes that attempted to turn it on | 23:36 |
| spiv | wgz: also, we changed to the release-notes layout for news since then | 23:37 |
| spiv | wgz: so the old config wouldn't have triggered anyway if it had been working as intended. | 23:37 |
| spiv | (Also, because we now have a file per release series the conflicts aren't as common/painful) | 23:38 |
| wgz | spiv: I still need to merge bzr.dev before writing release notes for too many of my branches, but the plugin may not be a complete panacea there | 23:47 |
| wgz | the change we tried today set the location to the right place in each of the active branches' branch.conf | 23:48 |
| spiv | wgz: well, it's easy enough to find out how much it hels | 23:48 |
| spiv | *helps | 23:48 |
| spiv | wgz: when you find a merge that fails due to a conflict, retry it locally with the plugin configured and see if it takes care of it :) | 23:49 |
| wgz | well, it seemed to not have any effect at all... how do we distinguish pqm not having the plugin enabled and the plugin not having done useful resolution? | 23:49 |
| wgz | vila tried the merge locally before submitting the test branch | 23:49 |
| spiv | wgz: right, that's partly why it's a PITA to debug. I *think* the plugin now at least logs something to .bzr.log | 23:49 |
| spiv | There's a bug about making it explicitly say something on stdout as part of the merge output | 23:50 |
| wgz | we'll have another crack tomorrow... but stdout for merge plugins would be nice indeed. | 23:50 |
| spiv | Something like: M doc/release-notes/bzr-2.6.txt [merged with news_merge] | 23:50 |
| spiv | You should at least be able to verify that the plugin is being *loaded* by looking at .bzr.log | 23:52 |
| wgz | hopefully the .bzr.log for pqm operations is straight forward to access | 23:56 |
| wgz | thanks for the input spiv! | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!