| poolie | i don't think i did make sampledata | 00:00 |
|---|---|---|
| poolie | let's see what bzr says | 00:00 |
| lifeless | poolie: did you merge db-devel perhaps? | 00:00 |
| poolie | i did, on the 19th | 00:01 |
| lifeless | that will explain it. | 00:01 |
| poolie | perhaps i should rebase my changes onto devel | 00:01 |
| lifeless | yes please | 00:01 |
| lifeless | gary_poster: /expander | 00:04 |
| lifeless | gary_poster: should that perhaps be /+expander ? | 00:04 |
| gary_poster | lifeless: yes, almost certainly | 00:04 |
| gary_poster | Please feel free to change on LEP (or not) | 00:04 |
| * gary_poster needs to run | 00:05 | |
| lifeless | ciao | 00:05 |
| gary_poster | bye | 00:05 |
| thumper | lifeless: gee, not even a whoop for lp:launchpad changing | 02:02 |
| thumper | I feel deflated :P | 02:03 |
| lifeless | thumper: whoop | 02:09 |
| lifeless | thumper: with leave on monday, I'm feeling a little flat out today | 02:09 |
| thumper | :-( | 03:25 |
| thumper | http 500 on https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging | 03:25 |
| thumper | second time lucky | 03:25 |
| * thumper afk | 03:46 | |
| StevenK | wgrant: Do you happen to be around? | 07:25 |
| wgrant | StevenK: Hi. | 07:30 |
| StevenK | wgrant: Hai | 07:30 |
| StevenK | wgrant: Can you have a squiz at https://code.edge.launchpad.net/~stevenk/launchpad/db-add-distro-parent/+merge/41430? | 07:30 |
| wgrant | 48+Derived Distroseries | 07:31 |
| wgrant | 49+-------------------- | 07:31 |
| wgrant | 50+ | 07:31 |
| wgrant | 51+Distroseries can be derived from other distroseries. This is completly | 07:31 |
| wgrant | 52+different from the derivation mentioned above. | 07:31 |
| StevenK | Yes, I need to fix that bit | 07:31 |
| wgrant | StevenK: What sort of review do you desire? | 07:32 |
| StevenK | wgrant: Basically, "Do you think it's crack?" | 07:32 |
| wgrant | StevenK: Has it been fully specced out? | 07:33 |
| wgrant | If not, it is crack. | 07:33 |
| wgrant | I haven't seen an analysis of all of the cases. | 07:34 |
| StevenK | I think it's a good plan, because .parent is overloaded and this derivation work is making it be more so | 07:34 |
| wgrant | Right, I agree. | 07:35 |
| wgrant | But I'd like to see it fully thought through first... | 07:35 |
| wgrant | We need to do something like this. | 07:35 |
| StevenK | We do have a LEP :-) | 07:35 |
| StevenK | wgrant: doctest twiddled, fwiw | 07:57 |
| lifeless | jkakar: hi? | 08:22 |
| jkakar | lifeless: Hi! | 08:24 |
| lifeless | https://dev.launchpad.net/LEP/PersistenceLayer may interest you | 08:24 |
| jkakar | lifeless: Cool, thanks, will check it out! | 08:26 |
| jkakar | "How will we measure how well we have done? It Will Be Obvious." <-- Cute. | 08:38 |
| === almaisan-away is now known as al-maisan | ||
| adeuring | good morning | 09:02 |
| mrevell | Hello | 09:04 |
| jtv | hi mrevell! | 09:31 |
| mrevell | Hi there jtv, how are you? | 09:31 |
| jtv | fine, thanks—you? | 09:31 |
| === al-maisan is now known as almaisan-away | ||
| bigjools | hello | 09:53 |
| jml | hi | 10:08 |
| jml | I ran a bunch of tests on ec2 last night | 10:08 |
| jml | they all passed | 10:08 |
| jml | but the test run had a non-zero exit code | 10:08 |
| bigjools | jml: sorry forgot to tell you about the test run yesterday, everything seemed ok. At least I got the usual amount of local failures I get. | 10:14 |
| bigjools | but whether they are different failures on the same tests I don't know. I get 60 codehosting tests failing | 10:15 |
| jml | bigjools: thanks. | 10:36 |
| bigjools | I need to figure out my local failures at some point ... | 10:36 |
| bigjools | jml: loads of my codehosting tests fail because they are trying to open /usr/lib/python2.6/dist-packages/bzr which does not exist, any ideas? | 10:39 |
| bigjools | this is when it runs some bzr commands | 10:39 |
| jml | hmm | 10:39 |
| jml | yeah, I have an idea | 10:39 |
| jml | but it's only half-formed | 10:39 |
| * jml pokes a bit | 10:39 | |
| bigjools | it's doing a "bzr push -d first branch-address" | 10:40 |
| jml | bigjools: lp.codehosting.get_bzr_path is either buggy or your environment is buggy | 10:40 |
| jml | bigjools: try running it in ./bin/ipy to see what you get | 10:40 |
| jml | bigjools: also, try 'ls eggs/bzr-2.2.0-py2.6*/EGG-INFO/scripts' | 10:42 |
| bigjools | "bzr" | 10:42 |
| bigjools | when needs running in ipy, exactly? | 10:43 |
| bigjools | what, even | 10:44 |
| jml | bigjools: lp.codehosting.get_bzr_path() | 10:48 |
| bigjools | jml: it returns the non-existent path | 10:50 |
| jml | bigjools: yay, the bug is isolated | 10:50 |
| bigjools | :) | 10:50 |
| jml | bigjools: I guess step through that with pdb and see what's misbehaving | 10:50 |
| jml | bigjools: basically, it looks like you are getting system bzr rather than the bzr in eggs | 10:51 |
| bigjools | I am going to remove the egg and re-generate it, it worked with a similar bunch of test failures | 10:51 |
| jml | bigjools: a fine plan | 10:51 |
| bigjools | I am tempted to blow all the eggs away, it'll clean up all the old crap | 10:52 |
| jml | bigjools: that could also work | 10:56 |
| bigjools | we need a development story for that | 10:57 |
| bigjools | yay, it works now | 10:57 |
| bigjools | thanks jml | 10:57 |
| jml | bigjools: np | 10:57 |
| jml | bigjools: can I persuade you to run the lp.codehosting tests with that new version of Twisted? | 10:58 |
| bigjools | jml: am doing so as we type :) | 10:59 |
| jml | bigjools: thanks :) | 10:59 |
| === matsubara-afk is now known as matsubara | ||
| bigjools | what's the magic command to make my download-cache get, err, downloaded again? | 11:32 |
| jml | bigjools: as in, to get a fresh one? | 11:33 |
| bigjools | yes | 11:33 |
| jml | bzr co --lightweight bzr+ssh://bazaar.launchpad.net/~launchpad/lp-source-dependencies/trunk/ download-cache | 11:33 |
| bigjools | of course, it's a checkout | 11:35 |
| jml | rather than say, a Debian archive, yes :) | 11:36 |
| bigjools | well, we've got so many different ways of getting dependencies now, it's hard to remember what does what | 11:36 |
| jml | definitely | 11:36 |
| jml | I was just thinking that it would kind of make sense to distribute the eggs as a debian archive | 11:36 |
| maxb | ! | 11:37 |
| bigjools | download-cache is a bit of a misnomer isn't it ... | 11:38 |
| jml | bigjools: I believe the default buildout behaviour is to fetch code from pypi and run that | 11:38 |
| jml | maxb: well, storing immutable tarballs in a bzr branch isn't exactly sensible either. | 11:39 |
| jelmer | jml: It doesn't seem to work like that, at least not here. | 11:39 |
| jml | jelmer: what doesn't work like what? | 11:39 |
| jelmer | Sorry, that was a bit vague. I meant buildout doesn't seem to fetch code from pypi for me. I have to have it in the download cache. | 11:40 |
| jml | that's because we have 'install-from-cache = true' in our buildout.cfg | 11:40 |
| jelmer | ah, ok. | 11:41 |
| jelmer | Means it's no longer effictively a cache though :-) | 11:41 |
| jml | quite so. | 11:41 |
| jml | it's a sensible name in the broader context of what buildout does, but not for our use. | 11:42 |
| jelmer | jml: I think shipping the eggs in a deb is a good idea. it's far from ideal but better then what we have at the moment. | 11:43 |
| jelmer | It also means it will be easier to e.g. move some of the eggs into their own proper package. | 11:43 |
| jelmer | jml: where would you have the package install them though? In a Launchpad-specific directory that lp adds to its PYTHONPATH, or to the system python path? | 11:44 |
| bigjools | that lp-source-dependencies is also carring loads of old versions, which is kinda annoying to download | 11:44 |
| bigjools | carrying, even | 11:44 |
| jelmer | it doesn't make sense that we create a heavyweight rather than a lightweight checkout | 11:45 |
| jml | jelmer: mine's lightweight :) | 11:45 |
| bigjools | so's mine | 11:45 |
| jml | ahh right, I'm just reminded of what actual advantage eggs have over packages: rollback | 11:46 |
| bigjools | you can do that easy with packages | 11:46 |
| bigjools | and it's audited properly | 11:46 |
| jml | jelmer: hey, did you get my email about testing packages etc? | 11:54 |
| jelmer | jml: yep. Thanks for setting that up | 11:55 |
| jml | my pleasure | 11:55 |
| jml | as mentioned, the actual working daily builds are probably packaging nightmares | 11:55 |
| jml | and most of the things aren't actually working | 11:56 |
| jml | jelmer: so I'd appreciate it if you or others who actually know what you're doing could take a look and fixinate | 11:56 |
| jelmer | jml: I'll see if I can contribute. Ideally we'd set these up to merge in their Debian packaging branch as well , that way we (and by we I mean lifeless, as he's the Debian maintainer) only have to do the work once. | 11:57 |
| jml | jelmer: that'd be great. | 11:57 |
| jml | oh | 11:57 |
| jml | that reminds me | 11:57 |
| jml | jelmer: the testr in that PPA has incremental output display, I think. | 11:58 |
| jelmer | jml: I should mention, I still find daily builds a bit hard to work with in practice because it's hard to easily find out what packages are working on which are broken. | 11:58 |
| jelmer | jml: Ah, neat. | 11:58 |
| jml | jelmer: can you clarify? | 11:58 |
| * jml really wants daily builds to be _easy_ to work with in practice | 11:59 | |
| jml | although tbh, probably the best thing we can do is reduce the end-to-end latency | 12:00 |
| jelmer | jml: I have a lot of daily builds, in particular related to bzr. It's very hard to get an idea of which ones are currently broken. | 12:00 |
| jml | ahhh | 12:00 |
| jml | yeah, I can see why that would be a thing | 12:01 |
| jml | jelmer: have you filed a bug about it? | 12:01 |
| jelmer | jml: The list of recipes doesn't show which ones have last produced a source packge successfully and it also doesn't show for which resulting source packages binary packages could be built. | 12:01 |
| jml | nor indeed which have failing binary build steps | 12:02 |
| jelmer | jml: I filed bug 669260 about this earlier. | 12:03 |
| _mup_ | Bug #669260: last build result in recipe overview page <recipe> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/669260> | 12:03 |
| jml | jelmer: ta | 12:04 |
| jml | bugs folk, is there a tag for https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications ? | 12:15 |
| bigjools | jml: so I see some test errors with the new Twisted | 12:17 |
| bigjools | I'll re-run with the old one just to make sure | 12:18 |
| jml | bigjools: thanks. could you also paste the errors? | 12:18 |
| bigjools | yep, once I confirm | 12:19 |
| === Ursinha-afk is now known as Ursinha | ||
| bigjools | jml: http://pastebin.ubuntu.com/536278/ | 12:44 |
| bigjools | w/o new Twisted they are passing | 12:44 |
| * bigjools -> lunch | 12:44 | |
| jml | bigjools: thanks | 12:44 |
| === mrevell is now known as mrevell-lunch | ||
| === Ursinha is now known as Ursinha-afk | ||
| === mrevell-lunch is now known as mrevell | ||
| === almaisan-away is now known as al-maisan | ||
| jml | jelmer: and 'testr failing --list' too | 14:09 |
| jml | flacoste: http://people.canonical.com/~jml/Tests-finished-each-minute.png ; http://people.canonical.com/~jml/Tests-finished-each-ten-minutes.png ; http://people.canonical.com/~jml/Tests-finished-each-hour.png | 14:47 |
| jml | mrevell: ^ | 14:47 |
| * mrevell l;ooks | 14:47 | |
| jml | flacoste: http://paste.ubuntu.com/536318/ | 14:48 |
| bigjools | jml: so do you remember that what seemed to a pointless xmlrpc "echo" command that the buildd-manager issued at the start of every build? | 15:54 |
| === salgado is now known as salgado-lunch | ||
| === matsubara is now known as matsubara-lunch | ||
| jml | bigjools: vaguely | 16:20 |
| jml | bigjools: does it have something to do with our mystery connect() timeout? | 16:20 |
| bigjools | jml: I think I found why it was there | 16:20 |
| jml | allenap: hi | 16:20 |
| bigjools | you guessed.....wisely | 16:20 |
| jml | bigjools: I need to know more. | 16:20 |
| bigjools | the first packet to the Xen slaves is sometimes discarded | 16:21 |
| bigjools | I have a test script that demonstrates this | 16:21 |
| jml | bigjools: may I see the script? | 16:22 |
| jml | allenap: the build just broke with that error we saw a while ago, eh? | 16:22 |
| allenap | jml: Yep :) | 16:22 |
| bigjools | jml: http://pastebin.ubuntu.com/536317/ which calls out to http://pastebin.ubuntu.com/536317/ | 16:22 |
| bigjools | err that';s the same | 16:23 |
| allenap | jml: Shall we try kicking it off again, and I'll have a go at the fix you suggested in the "ec2 land submission problems" thread? | 16:23 |
| jml | allenap: just pulling up the thread... I seem to remember saying something about it | 16:23 |
| bigjools | jml: well anyway there's a top-level script that resets the slave and then immediately calls that one | 16:23 |
| jml | bigjools: is the xmlrpc server running inside an instance? | 16:24 |
| jml | bigjools: a xen instance, that is | 16:24 |
| bigjools | jml: the reset script does not exit until it's running | 16:24 |
| jml | allenap: I would suggest applying the fix before retrying | 16:24 |
| allenap | jml: Okay, I'll have a bash at that now. | 16:25 |
| jml | allenap: I mean, it's not that hard, and it might make our branches land ~3.5 hrs earlier :) | 16:25 |
| allenap | jml: Oh yes :) I'll email the list too. | 16:26 |
| jml | bigjools: sorry, I don't really know what the reset script does or why exiting matters | 16:26 |
| jml | bigjools: also, in what way is that paste different from the script I put on the bug? (is it just that it actually works & reports a little better?) | 16:27 |
| jml | allenap: thanks! | 16:27 |
| bigjools | jml: it restarts the Xen guest and then waits until the slave manager responds with a BuilderStatus.IDLE. At that point we know for sure it's up and working. Afterwards we poke it with that script which sometimes fails with the first connection. | 16:27 |
| bigjools | jml: it logs the first packet failures | 16:28 |
| jml | bigjools: were we only seeing the error against Xen guest slaves? | 16:28 |
| bigjools | yep | 16:28 |
| jml | nice | 16:28 |
| jml | bigjools: so I guess putting the echo (or even a TCP connect & disconnect) back in, with a nice big fat comment of course, would fix the issue | 16:29 |
| bigjools | jml: lp:~julian-edwards/launchpad/timeouts-feature-bug-681426 | 16:29 |
| jml | bigjools: oh, is there a bug for the issue with xen discarding packets? | 16:29 |
| bigjools | :) | 16:29 |
| jml | surely someone else must have noticed this... | 16:30 |
| bigjools | https://bugs.edge.launchpad.net/launchpad-buildd/+bug/586359 | 16:30 |
| _mup_ | Bug #586359: Virtual builders are sometimes very slow to accept connections <Launchpad Auto Build System:Triaged> <https://launchpad.net/bugs/586359> | 16:30 |
| bigjools | jml: I saw some PDF describing packets dropped from the DMA ring when system load is too high | 16:30 |
| jml | bigjools: I meant a bug against xen -- it's not actually a canonical.buildd issue is it? | 16:31 |
| jml | zoinks | 16:31 |
| bigjools | we're not sure exactly where the bug is | 16:31 |
| bigjools | we need to prove that first | 16:31 |
| bigjools | but it looks very suspicious | 16:31 |
| jml | so 586359 stays open even when the builder has the workaround? | 16:31 |
| bigjools | yeah, I need to add a soyuz task | 16:32 |
| jml | *nod* | 16:32 |
| jml | bigjools: well, you have my sincerest preliminary congratulations :) | 16:32 |
| bigjools | jml: team effort, I can't take all the kudos | 16:33 |
| bigjools | but thanks :) | 16:33 |
| === al-maisan is now known as almaisan-away | ||
| === matsubara-lunch is now known as matsubara | ||
| allenap | jml: Could you sanity check my branch? https://code.launchpad.net/~allenap/launchpad/zope-test-in-subprocess-unicode-issue/+merge/41886 | 16:59 |
| jml | allenap: I have to look up what codecs.getreader does now :) | 17:02 |
| jml | allenap: have you tried running a subclass of ZopeTestInSubprocess? | 17:04 |
| lifeless | morning | 17:06 |
| bigjools | morning lifeless | 17:06 |
| allenap | jml: I've run all the tests that rely on it and they ran fine. | 17:06 |
| jml | allenap: cool. | 17:06 |
| jml | lifeless: good morning. | 17:06 |
| === beuno is now known as beuno-lunch | ||
| allenap | jml: Thanks for that. Shall I just lp-land --testfix it now? | 17:07 |
| jml | allenap: deffo | 17:07 |
| bigjools | jml: care to look at https://code.launchpad.net/~julian-edwards/launchpad/timeouts-feature-bug-681426/+merge/41881 please? | 17:07 |
| bigjools | it's short :) | 17:07 |
| === salgado-lunch is now known as salgado | ||
| jml | bigjools: you should probably link to the bug report in the comment. | 17:12 |
| bigjools | ok | 17:13 |
| jml | other than that, good to go | 17:13 |
| bigjools | cheers | 17:13 |
| bigjools | If I finally put this one to bed I am going to be a very happy man | 17:16 |
| lifeless | jml: could you eyeball LEP?PersistenceLayer? Thanks. | 17:16 |
| jml | lifeless: fo shizzle | 17:17 |
| jml | allenap: btw, do you know of anyone tackling the other failure? the list was silent. | 17:24 |
| jml | I've got a bunch of specs to read. Heading afk to do so & eat. Back later to catch the antipods. | 17:27 |
| allenap | jml: Oh, the db-devel one? No, no idea. I didn't even look at it myself :-/ | 17:32 |
| bigjools | lifeless: FYI I think I figured out the timeouts | 17:40 |
| bigjools | so I'm going to skip that feature-controlled builder fail bug | 17:40 |
| lifeless | bigjools: It might be a good idea to have a realtime knob for number of failures regardless. | 17:41 |
| lifeless | bigjools: but its up to you :) | 17:41 |
| bigjools | lifeless: I don't think that's at all necessary | 17:41 |
| bigjools | IMNSHO :) | 17:41 |
| allenap | jml: If you mean danilo's, then I also don't know. | 17:41 |
| lifeless | bigjools: the next time you land a branch changing or disabling that figure.... think of me :) | 17:42 |
| bigjools | well if this branch doesn't work then I'll do it | 17:42 |
| lifeless | 6 months, 9, I'm sure you'll remember ;) | 17:42 |
| bigjools | lifeless: how could I not always think of you | 17:42 |
| lifeless | awww :) | 17:42 |
| bigjools | so, time to go. heavy eyes from staying up late to watch the cricket | 17:43 |
| bigjools | night al | 17:43 |
| bigjools | l | 17:43 |
| lifeless | gnight | 17:44 |
| lifeless | allenap: ping | 17:45 |
| === beuno-lunch is now known as beuno | ||
| lifeless | flacoste: hi | 18:24 |
| salgado | lifeless, do we have only the 'devel' and '1.0' versions of the webservice or are there others? do you know where's that configured? | 18:27 |
| lifeless | salgado: we have beta, 1.0, devel | 18:27 |
| lifeless | in the | 18:27 |
| lifeless | exported() clal | 18:27 |
| lifeless | call | 18:27 |
| salgado | lifeless, I was asking about the config which has the list of versions | 18:28 |
| lifeless | beta was the first devel, then when we did 1.0 we deleted stuff we didn't like in beta, and devel is like the next beta. | 18:28 |
| lifeless | salgado: oh, the master list? | 18:28 |
| lifeless | uhm | 18:28 |
| salgado | lib/canonical/launchpad/rest/configuration.py | 18:28 |
| salgado | I think | 18:28 |
| lifeless | looks like | 18:28 |
| salgado | yeah, that's itactive_versions = ["beta", "1.0", "devel"] | 18:29 |
| salgado | lifeless, so, what is beta? should the blueprints API be available there? | 18:29 |
| lifeless | no | 18:30 |
| lifeless | see version_descriptions | 18:30 |
| lifeless | in that file | 18:30 |
| salgado | oh, I see | 18:30 |
| lifeless | new stuff should generally just go into devel. | 18:30 |
| lifeless | if we're -totally- confident in its stability, putting it into 1.0 is fine, putting it into beta is pretty pointless given its substantial skew vs 1.0 | 18:31 |
| flacoste | hi lifeless | 18:32 |
| lifeless | flacoste: shall we catchup/handoff ? | 18:32 |
| flacoste | lifeless: sure | 18:33 |
| flacoste | lifeless: i can do it later also | 18:33 |
| flacoste | lifeless: really up to you | 18:33 |
| lifeless | now is good | 18:35 |
| flacoste | lifeless: skype? | 18:36 |
| jml | allenap: no worries | 19:06 |
| lifeless | flacoste: https://bugs.launchpad.net/launchpad-foundations/+bug/651766 | 19:17 |
| _mup_ | Bug #651766: please record concurrent query count on servers <oops-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/651766> | 19:17 |
| jml | :( | 19:19 |
| jml | looks like db_lp is still broken | 19:21 |
| jml | and that something similar is now also affecting lp | 19:21 |
| jml | lifeless: ping | 19:22 |
| lifeless | otp | 19:22 |
| jml | ok. | 19:23 |
| lifeless | won't be long | 19:23 |
| thumper | morning | 20:12 |
| thumper | jml: I have a quick question for you | 20:12 |
| jml | thumper: sure. I'm otp atm. | 20:12 |
| thumper | jml: I remember in the years past you had looked at extracting the codehosting server into a separate project, did that happen? | 20:13 |
| jml | thumper: not really. I made txsshserver, but it's kind of dead. lp.services.sshserver is much closer to the spirit of that. | 20:14 |
| jml | thumper: my goal was always to extract the generic ssh stuff we did, rather than a separate codehosting service | 20:14 |
| thumper | ah, ok | 20:14 |
| === salgado is now known as salgado-afk | ||
| jml | thumper: did you want to have a catch up call? | 20:28 |
| allenap | lifeless: pong | 20:28 |
| thumper | jml: sure, I'm just going through emails | 20:28 |
| thumper | now? | 20:28 |
| thumper | mumble? | 20:28 |
| jml | thumper: mumble's great. one sec. | 20:28 |
| jml | thumper: join me in the strategerie | 20:29 |
| lifeless | allenap: I humbly suggest that the bug you qa-ok'd which timed out on staging and has additional repeated queries, isn't qa-ok :) | 20:29 |
| allenap | lifeless: Okay, fair enough :) There's nothing built on it so I'll revert it. | 20:34 |
| lifeless | allenap: if the additional queries *do not* happen on users outside the saved-search user group | 20:34 |
| lifeless | allenap: then I think it is qa-ok | 20:34 |
| lifeless | allenap: but I couldn't tell if that was the case, thus pinging you | 20:34 |
| flacoste | wow, one of the top landing page on launchpad is https://launchpad.net/~jd-team/+archive/jdownloader | 20:35 |
| flacoste | even above /ubuntu ! | 20:35 |
| allenap | lifeless: There are no saved searches yet, and it's not possible to create them, so this will happen to everyone. I'll revert it. | 20:36 |
| lifeless | allenap: thanks. | 20:36 |
| lifeless | allenap: you need to mark the bug qa-bad and add a tag bad-commit-12345 (the revno in stable thats bad) | 20:36 |
| lifeless | allenap: when you revert, you need [rollback=12345] in your commit message (or use the --rollback option to lp-land) | 20:36 |
| allenap | lifeless: Do I need to run the revert via ec2, or just land it? | 20:37 |
| lifeless | I generally just land | 20:37 |
| lifeless | if its a straight revert | 20:38 |
| lifeless | if its days old or something ec2 can be a good sanity check ;) | 20:38 |
| allenap | lifeless: In this case I think it'll be safe. I'll run some sanity checks locally. | 20:38 |
| ccxCZ | I got weird behavior on api <project>?ws.op=getBranches; There is branch that's fully merged and it sometimes appear on the list and sometimes not which results in useless messages sent by my irc bot. | 20:39 |
| flacoste | ccxCZ: for how long has it been fully merged? | 20:41 |
| ccxCZ | ~40 minutes now | 20:50 |
| flacoste | ccxCZ: hmm, that's weird | 20:53 |
| ccxCZ | maybe it's gone now, let me check | 20:54 |
| ccxCZ | but it lasted for 20 minutes at least | 20:54 |
| ccxCZ | should the branch appear there or not? | 20:55 |
| ccxCZ | seems it settled now, but fluctuations like this are seriously annoying | 20:58 |
| === matsubara is now known as matsubara-afk | ||
| lifeless | is your script logged in ? | 21:08 |
| ccxCZ | no, I just do plain http request on the uri | 21:10 |
| lifeless | then you're getting cached responses | 21:11 |
| lifeless | from the squid cluster that anonymous requests go to. | 21:11 |
| lifeless | If you want accurate data, you need to sign in and use the auth cookie | 21:11 |
| wallyworld | abentley: http://paste.ubuntu.com/536445/ | 21:12 |
| lifeless | the reason its fluctuating is that we have multiple squids and one had an older version of the answer, the other a newer version | 21:12 |
| ccxCZ | i see | 21:12 |
| ccxCZ | is there way to stay at one proxy without having an account? | 21:13 |
| lifeless | no | 21:13 |
| lifeless | primarily because its a load balancing cluster; it would defeat the point :) | 21:14 |
| jml | poolie: ping | 21:15 |
| ccxCZ | and is there a way to tell apart older data from newer for example by some http header? | 21:18 |
| lifeless | allenap: also | 21:20 |
| lifeless | allenap: you might want to revert your subunit change | 21:20 |
| ccxCZ | Date header seems usable, how often do responses stay in squid? | 21:21 |
| jml | lifeless: why would he want to do that? | 21:21 |
| lifeless | because subunit's parser wants bytes | 21:21 |
| jml | no it doesn't | 21:21 |
| jml | it *ought* to want bytes | 21:21 |
| lifeless | it does want bytes | 21:22 |
| lifeless | it embeds binary data literally in-line in its output | 21:22 |
| lifeless | you'll get unicodedecode errors trying to read a subunit stream as utf8 | 21:22 |
| lifeless | if there is nonutf8 data in any of the attachments. | 21:22 |
| jml | TypeError: _StringException expects unicode, got "lost connection during failure report of test 'lp.services.job.tests.test_runner.TestTwistedJobRunner.test_timeout'" | 21:22 |
| lifeless | yes, there is a problem there. | 21:23 |
| lifeless | passing a unicode file handle in is not a solution. | 21:23 |
| jml | or at least, not a very good one | 21:24 |
| lifeless | a solution would work. | 21:24 |
| jml | you think the failures we're seeing on the bot now are related to allenap's fix? | 21:25 |
| lifeless | no | 21:26 |
| lifeless | I think that allenaps fix will break if/when any binary data attachments that are not utf8 get into the stream | 21:26 |
| allenap | lifeless: Okay, I'll revert that one too :) Once we're out of testfix anyway. | 21:27 |
| lifeless | jml: this is the current subunit code: | 21:27 |
| lifeless | def _lostConnectionInTest(self, state_string): | 21:27 |
| lifeless | error_string = u"lost connection during %stest '%s'" % ( | 21:27 |
| lifeless | state_string, self.current_test_description) | 21:27 |
| lifeless | error_string *is* unicode. | 21:28 |
| lifeless | upgrading the subunit used is a solution. | 21:28 |
| jml | ahh, *that* will be why I didn't see the bug when I looked a week ago | 21:29 |
| jml | because I was looking at a version that already had the fix | 21:29 |
| lifeless | yes | 21:30 |
| allenap | lifeless: Via the Launchpad PPA | 21:30 |
| allenap | ? | 21:30 |
| lifeless | allenap: however we do it, we should do it. | 21:30 |
| lifeless | (I don't know ;P) | 21:30 |
| allenap | Okay. I'll file a bug for that. | 21:30 |
| lifeless | thanks ! | 21:30 |
| lifeless | we probably also want one that subunit *accepted* a unicode stream at all | 21:33 |
| lifeless | allenap: I'm sorry that you went to the effort to fix it and had this happen :( | 21:34 |
| flacoste | allenap, lifeless: if a newer subunit isn't availabe in Ubuntu, someone needs to upload it to the ppa | 21:37 |
| flacoste | and then upgrade the launchpad-dependencies to depends on that newer version | 21:38 |
| flacoste | and then file a RT to have it upgraded in the data centre (PQM +buildbot images) | 21:38 |
| flacoste | upgrading the ec2 images is also probably a good idea | 21:38 |
| allenap | lifeless: That's alright, it was a pretty small change, and it put it where you could comment on it. | 21:38 |
| mwhudson | "Xen guests sometimes ignore the first network packet", wow i didn't expect the builder problems to be at that level | 21:39 |
| cody-somerville | mwhudson, where did you read that | 21:40 |
| cody-somerville | mwhudson, ? | 21:40 |
| lifeless | more interesting to me is why we're seeing interrupted streams; I suspect something is printing to stdout | 21:41 |
| lifeless | *or* we're mixing stderr into stdout. | 21:41 |
| lifeless | jml: ^ | 21:41 |
| wgrant | mwhudson: That's not it. | 21:41 |
| * jml blinks | 21:41 | |
| wgrant | mwhudson: Non-virt builders are also affected. | 21:41 |
| jml | lifeless: can you phrase that as a question? | 21:42 |
| mwhudson | cody-somerville: some soyuz bug | 21:42 |
| mwhudson | wgrant: ah | 21:42 |
| cody-somerville | LP #586359 | 21:42 |
| _mup_ | Bug #586359: Virtual builders are sometimes very slow to accept connections <Launchpad Auto Build System:Triaged> <Soyuz:In Progress by julian-edwards> <https://launchpad.net/bugs/586359> | 21:42 |
| jml | wgrant: bigjools said otherwise when I asked him about it | 21:42 |
| wgrant | jml: Grep logs for palmer, notice that palmer is non-virt, profit. | 21:42 |
| wgrant | Oh. | 21:43 |
| wgrant | It might explain the "Connection timed out" thing, but not the big problem ("User timeout caused connection failure") | 21:43 |
| jml | right. | 21:43 |
| lifeless | jml: does the controlling process get stdout and stderr from the child on separate fds and keep them separate everywhere that they might be fed to subunit ? | 21:43 |
| jml | lifeless: on the buildbot? Not only do I not know, I also don't know how to find out. | 21:44 |
| * jml checks ec2test.remote though | 21:44 | |
| jml | lifeless: they aren't kept separate in devscripts.ec2test.remote | 21:45 |
| lifeless | they need to be | 21:46 |
| lifeless | or this can happen: | 21:46 |
| lifeless | failure: start_of_testWarning: something on stderr | 21:47 |
| cody-somerville | I don't think that script is sufficient to say that Xen guests sometimes ignore the first network packet. OEM Services uses Xen guests for our image build system and we have not run into anything like this - and we would if the premise was correct. | 21:47 |
| lifeless | as input to subunit | 21:47 |
| jml | lifeless: sure, that makes sense. | 21:48 |
| lifeless | jml: when that happens, we will see 'lost connection' errors. | 21:49 |
| jml | the code is well factored and has great test coverage, so it should be easy enough for someone to fix | 21:49 |
| jml | lifeless: what's buildbot using, I wonder. | 21:49 |
| lifeless | the buildbot subunit support I added, and is correct. | 21:49 |
| lifeless | we may be doing something differnet | 21:49 |
| jml | uhhh | 21:50 |
| lifeless | (buildbot can watch subunit streams directly) | 21:50 |
| jml | yeah, I just don't see any subunit in the output | 21:50 |
| jml | hang on, this is ZTIS | 21:50 |
| poolie | jml, hi | 21:51 |
| jml | poolie: got time for a call? | 21:52 |
| jml | lifeless: nothing in ZTIS makes me think it has the same bug, but I'm not looking very closely. | 22:21 |
| jml | I have to go & sleep now | 22:21 |
| jml | (not in the fire) | 22:21 |
| jml | g'night | 22:22 |
| cr3 | lifeless: regarding our conversation about eager loading result sets yesterday, is it preferable to return a result set with a limit, result_set.config(limit=limit), or a slice, result_set[:limit]? | 22:31 |
| maxb | Where has the "Nominate for release" link disappeared to, in malone?! | 22:31 |
| cr3 | lifeless: I'm leaning towards the slice because, depending on the size of the limit, I'm not sure whether storm might make more than one roundtrip when iterating over the collection | 22:33 |
| lifeless | cr3: those things are equivalent | 22:33 |
| lifeless | maxb: its restricted to drivers | 22:33 |
| lifeless | maxb: which was the original intent | 22:34 |
| wgrant | No. | 22:36 |
| cr3 | lifeless: in that case, I might lean towards using config then so that I can support both defined and undefined limits (None) as keyword argument, assuming config(limit=None) behave the way I think it does | 22:36 |
| wgrant | "Target to release" is restricted to drivers (and uploaders, in Ubuntu) | 22:36 |
| lifeless | cr3: erm | 22:36 |
| wgrant | "Nominate for release" is restricted to bug supervisors. | 22:36 |
| lifeless | cr3: folk can change it after by slicing further | 22:36 |
| lifeless | cr3: e.g. resultset = .. | 22:36 |
| lifeless | resultset = resultset[1:2] | 22:36 |
| lifeless | resultset = resultset[:4] | 22:37 |
| lifeless | wgrant: i stand tweaked | 22:37 |
| wgrant | It would be nice if Launchpad didn't impose its will over every project. | 22:39 |
| cr3 | lifeless: good point, the offset and limit aren't enforced until actually iterating over the result set, so I guess I'm confused about the appropriate way to expose this through the webservice | 22:39 |
| cr3 | wgrant: all your projects are belong to us? | 22:39 |
| lifeless | cr3: the webservice understands slices | 22:39 |
| lifeless | wgrant: I support having more knobs | 22:39 |
| lifeless | wgrant: this change was done for Ubuntu as it happens | 22:39 |
| wgrant | lifeless: !!! | 22:39 |
| wgrant | lifeless: I know. | 22:39 |
| wgrant | But Launchpad seems to have an Ubuntu-size-fits-all policy :/ | 22:40 |
| lifeless | wgrant: I think its more nuanced than that | 22:40 |
| lifeless | wgrant: we get an awful lot more feedback from Ubuntu users than others though. | 22:40 |
| wgrant | lifeless: I'd argue that that's because you have few large projects using your service, partly because it's slow, but also partly because it's so inflexible. | 22:41 |
| lifeless | wgrant: we have a balance to strike between configurability and homogeneity | 22:41 |
| maxb | lifeless: *sigh*. This means that non-bug-supervisors cannot correctly follow the documented Ubuntu SRU proposal process any more | 22:42 |
| lifeless | wgrant: its important to mark that skills folk learn for working on bugs in Launchpad projects be broadly applicable | 22:44 |
| lifeless | wgrant: I don't know that that is really achievable, because humans use tools in their own fashion, always. | 22:44 |
| lifeless | wgrant: but unless or until jml tackle that point, we're bound to try. | 22:44 |
| lifeless | maxb: that sounds like Ubuntu got what they wanted and then didn't follow up and adapt their own docs ;) | 22:45 |
| lifeless | maxb: uploaders can follow the SRU process | 22:45 |
| lifeless | maxb: the reason non-uploader non-supervisors cannot do it is because of abuse by affected users making the system far too noisy. | 22:46 |
| === henninge changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.12 | PQM is open | firefighting: - | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | ||
| ccxCZ | seems your http server/squid does not handle If-Modified-Since header properly | 22:56 |
| lifeless | for anonymous requests its overriden | 22:56 |
| lifeless | you cannot force a backend request through it | 22:56 |
| ccxCZ | squid should still respond with 304 | 22:57 |
| lifeless | what is it responding with ? | 23:00 |
| ccxCZ | always 200 w/ full body | 23:01 |
| ccxCZ | http://paste.pocoo.org/show/296079/ | 23:02 |
| lifeless | thats legitimate | 23:03 |
| lifeless | ccxCZ: please remove 'edge.' from your url | 23:04 |
| lifeless | ccxCZ: can you show the request as well | 23:04 |
| ccxCZ | http://paste.pocoo.org/show/296082/ | 23:06 |
| lifeless | thanks - we're getting rid of edge ;) | 23:06 |
| ccxCZ | now my client always get 401, but wget is fine. some Useragent magic in there? | 23:08 |
| lifeless | I don't think so | 23:09 |
| lifeless | but I'd need to see your request to know | 23:09 |
| wgrant | You need to send a User-Agent. | 23:09 |
| wgrant | Doesn't matter what. | 23:09 |
| ccxCZ | actually sending some user agent helped | 23:10 |
| ccxCZ | one more thing, number of returned branches seems to limited to some arbitrary value (75 on api.launchpad, 50 on edge), is there way to remove this limit? | 23:31 |
| wgrant | ccxCZ: API collections are batched. | 23:32 |
| wgrant | So you need to request ~75 at a time. | 23:33 |
| wgrant | I forget the exact syntax. | 23:33 |
| lifeless | there's a new api coming | 23:34 |
| lifeless | which will help | 23:34 |
| ccxCZ | also what form is modified_since argument in? unix timestamp? | 23:35 |
| ccxCZ | honestly there are lot of omissions in the 1.0 api doc | 23:37 |
| lifeless | the docs are very very lacking | 23:38 |
| wgrant | The primary interface to the API is launchpadlib, which handles that sort of thing for you. | 23:38 |
| lifeless | there is a bug about this | 23:38 |
| wgrant | But I believe it's ISO8601 | 23:38 |
| wgrant | And yes, the docs are pretty bad. | 23:38 |
| ccxCZ | launchpadlib won't work with twisted | 23:39 |
| lifeless | txrestful does that I believe | 23:39 |
| ccxCZ | I know, but it seemed overly complex to me and far from complete | 23:40 |
| ccxCZ | since I only need to request one uri, using library like this seemed like overkill | 23:41 |
| lifeless | I agree | 23:41 |
| ccxCZ | the thing I wrote is irc bot that monitor project's branches and posts updates to a channel. I was advised I should post to launchpad-dev about it. | 23:48 |
| lifeless | cool | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
