| pitti | Good morning | 03:27 |
|---|---|---|
| pitti | thomi: hey, how are you? | 03:27 |
| thomi | hi pitti, fine thanks | 03:27 |
| pitti | thomi: is there an AP method for dumping type/properties of a widget and all of its children to stdout? If not, I'd like to write that | 03:29 |
| pitti | thomi: I keep writing something like that for pretty much each new AP test that I'm writing | 03:29 |
| pitti | thomi: as especially with QML, the widget tree in -vis looks 'orrible, and it's a pain to find the label or anything actually visible in the 25th sublayer behind nested QItems, panels, and other uninteresting stuff | 03:30 |
| veebers | pitti: in the past I've used this rough script to achieve 'vis' on the device: lp:~veebers/+junk/introspector but I agree that something nicer would be, well, nicer | 03:31 |
| veebers | pitti: I also use an interactive shell to do something similar, i.e. set a breakpoint in a skeleton test and interact and iterate the details I need | 03:31 |
| thomi | pitti: there's nothing like that now. It would be nice if whatever you write also improved the vis tool at the same time :) | 03:32 |
| pitti | I'm using something like http://paste.ubuntu.com/6254780/ ATM | 03:32 |
| pitti | it should get nice formatting (proper nesting) and the like, but anythign greppable | 03:32 |
| pitti | thomi: hm, not sure how a text dump would improve vis, but I'm open for ideas :) (unless you mean adding a button to vis to do just that for the whole tree -- but that might take loong) | 03:33 |
| thomi | pitti: OK, was just a thought. I'll be interested to see what you come up with :) | 03:34 |
| pitti | ack :) | 03:34 |
| pitti | seems like a perfect little hack for train time this afternoon (or next week, as I have some other autopkgtest etc. work planned, too) | 03:35 |
| pitti | thomi, veebers: filed bug 1241323 for this with some rationale and details | 03:40 |
| ubot5 | bug 1241323 in Autopilot "Add method for dumping widget and its children to stdout" [Wishlist,New] https://launchpad.net/bugs/1241323 | 03:40 |
| pitti | fginther, jibel: ah, http://10.97.0.26:8080/job/autopilot-testrunner-otto-saucy/1259/console shows why our otto CI runner is busted: "ls: cannot access /sys/fs/cgroup/systemd/user/: No such file or directory" | 03:41 |
| jibel | Good morning pitti | 04:58 |
| jibel | pitti, that's what I suspected when you talked about logind. I use a special mount hook to do this and enable nested containers | 05:04 |
| jibel | pitti, but the machine should be upgraded to saucy as the main point of otto is to do HW testing and the host and guest must share the same kernel to do so | 05:05 |
| elopio | ping pitti: you know about mocking stuff. What would you think of a project that lets us record the messages between a client and a server, and then lets us replay the server response as a mock on a test? | 05:16 |
| pitti | jibel: oh, so we weren't actually fully testing saucy on these machines | 05:34 |
| pitti | jibel: I suspect the hosts is a rather small server install, so upgrading them shouldn't be too complicated? | 05:34 |
| pitti | elopio: I think I've seen something like that already; indeed sounds useful, especially for your area (U1) | 05:34 |
| jibel | pitti, we are on the autolanding machines but apparently not on the CI ones. I don't know how they've been setup, I havent bee involved at all | 05:35 |
| jibel | pitti, upgrading is trivial | 05:35 |
| jibel | pitti, for the daily release, the machines are updated every day, when first T images are built, I'll upgrade them to T | 05:36 |
| pitti | elopio: something like http://code.google.com/p/wireplay/ or http://tcpreplay.synfin.net/ | 05:36 |
| elopio | pitti: this is the only one I've seen, but sounds a little hard to get all the files right: https://pypi.python.org/pypi/mock-server/ | 05:36 |
| pitti | elopio: oh, you mean for specific protocols | 05:37 |
| pitti | elopio: python already has http, xmlrpc, and whatnot servers, and setting up a fake ftp/smb/ssh etc. server is also easy (all without root) | 05:37 |
| elopio | pitti: wireplay looks nice! | 05:37 |
| elopio | pitti: well, I'm just collecting ideas. Something that lets us mock a REST API easily would be nice. | 05:38 |
| elopio | but just replaying TCP might even be easier. | 05:38 |
| elopio | thanks for the links. | 05:38 |
| pitti | elopio: well, in general higher-level tools are more flexible, but it looks like mock-server doesn't have record&replay, just "manual" mock set up | 05:39 |
| pitti | OTOH record&replay isn't very flexible in variating for different corner cases | 05:39 |
| elopio | pitti: yes, I suppose I should start trying them. What I would like is that all our servers provide a mock implementation to test the integration of whatever clients want to communicate with it. | 05:40 |
| pitti | $ run-adt-test -s network-manager | 05:40 |
| pitti | ubuntu-distro-info: Distribution data outdated. | 05:40 |
| pitti | jibel: ^ I guess that hits our jenkins machines, too? | 05:40 |
| pitti | elopio: that sounds nice indeed, as long as you constantly test your mocks with the real client tools (to make sure they don't get out of date) | 05:41 |
| pitti | jibel: WDYT of http://paste.ubuntu.com/6255194/ ? | 05:43 |
| elopio | pitti: yes. We also need test clients that query all the API methods. We can run them against the mock and the real server :) | 05:43 |
| elopio | some of the projects already have that level of testing. | 05:44 |
| pitti | jibel: actually, scratch that; should use -s | 05:44 |
| jibel | pitti, ah thanks! this bug must be everywhere :/ | 05:44 |
| pitti | jibel: http://paste.ubuntu.com/6255197/ | 05:44 |
| jibel | pitti, I'd redirect stderr of the call with -d to /dev/null | 05:46 |
| jibel | unless we want to show it for information | 05:46 |
| pitti | jibel: I was hesitant to do that as it might actually fail for a different reason, but no strong opinion | 05:46 |
| pitti | jibel: committed for now, feel free to adjust if you prefer supressing the error (but I'm not a big fan of that) | 05:47 |
| jibel | pitti, I find it always confusing to show an error message and falling bakc implicitly to another value without notifying the user | 05:48 |
| jibel | that's a matter of taste I guess :) | 05:48 |
| jibel | pitti, +1 | 05:48 |
| pitti | jibel: do you have a script to bzr pull on all four slaves, or do you usually do that manually? | 05:49 |
| pitti | I just did the latter in the past few times | 05:49 |
| jibel | pitti, hm, I have one for other systems but not for auto-package-testing. I'll update the one I use for daily-releas | 05:51 |
| pitti | jibel: ah, ok; I can write one and stuff it into jenkins/ ? | 05:51 |
| jibel | pitti, don't bother, I've one ready, I just need to change the paths and hosts | 05:52 |
| pitti | ah, good | 05:52 |
| jibel | ah, it would have been too easy if all the servers were configured identically | 05:57 |
| pitti | rbasak: wrt. your lxc branch, looks quite nice! I'm writing tests for it now | 07:29 |
| pitti | rbasak: the main thing I don't like about it is the --ephemeral option | 07:29 |
| pitti | rbasak: I mean, is there ever a reason *not* to use it? | 07:29 |
| pitti | rbasak: if you forget it, doesn't that basically mean "mess up my container"? | 07:30 |
| pitti | rbasak: oh I see, otherwise it uses lxc-clone first | 07:31 |
| pitti | rbasak: so what's the practical difference between those? | 07:31 |
| pitti | ralsina: nevermind, saw it in the manpage | 07:41 |
| pitti | sorry, rbasak ^ | 07:41 |
| pitti | jibel: FYI, I landed the lxc runner in debian git now | 07:50 |
| rbasak | pitti: yeah some tests give me a ton of tar errors while files are transferred with --ephemeral. I think they can see a race in overlayfs. | 07:54 |
| rbasak | Thanks for landing it! | 07:54 |
| pitti | now, if lxc-start-ephemeral only would do what it says on the tin and actually *use* a tmpfs | 07:55 |
| jibel | pitti, \o/ | 07:55 |
| jibel | rbasak, what kind of tar errors? | 07:56 |
| rbasak | It might do it without -k, I'm not sure | 07:56 |
| pitti | rbasak: it doesn't, not even with -s tmpfs | 07:56 |
| pitti | I don't want this to touch my hard drive | 07:56 |
| rbasak | jibel: tar thinks that files/directories (can't remember which) have changed from underneath it while it unpacks, and compains then ends with an error exit | 07:56 |
| rbasak | pitti: with --eatmydata at least your hard drive won't slow it down :) | 07:57 |
| pitti | stgraber: any idea about this? "sudo lxc-start-ephemeral -o adt" is supposed to use tmpfs, but it doesn't even with -s tmpfs | 07:57 |
| rbasak | IIRC the php5 test did this (tar errors). Let me try it now. | 07:57 |
| pitti | stgraber: I don't see any new tmpfs mount anywhere, or it using /tmp/ for the overlay instead of /var/lib/lxc, and the container rootfs isn't a mountpoint | 07:57 |
| phillw | pitti: when ever you're ready; give me a poke and I'll try it out on a virgin server; you'll need a domain name, though :) | 08:02 |
| pitti | phillw: sorry, try what? | 08:02 |
| rbasak | df -h | 08:05 |
| jibel | pitti, isn't it using a delta/ directory somewhere in var/lib/lxc/<container> for the overlay? | 08:11 |
| pitti | jibel: maybe, but all these are empty, too | 08:11 |
| jibel | I read a blog post from hally a while ago about it | 08:11 |
| pitti | in fact, I'm not sure where exactly it stores teh delta | 08:11 |
| jibel | hallyn | 08:11 |
| jibel | pitti, with ephemeral pre-mount mounts delta0 as tmpfs in the ephemeral container then uses is overlay for rootfs from the original container | 08:24 |
| jibel | *uses as | 08:24 |
| pitti | jibel: ah, so this is somehow not visible from the host | 08:26 |
| jibel | pitti, yes, and everything is mounted with -n | 08:27 |
| pitti | yes, but those should still appear in /proc/mounts usually, so I guess it's the cgroup magic which only makes them visible in the container | 08:31 |
| jibel | that's the point I don't get. pre-mount is executed on the host, so everything mounted in pre-mount should be visible in /proc/mounts | 08:33 |
| slickymaster | morning all | 08:50 |
| jibel | rbasak, I cannot reproduce any tar issue with ephemeral. I'm on saucy with latest autopkgtest from git and ran | 09:08 |
| jibel | AUTOPKGTEST_BASE=$(pwd) runner/adt-run -d ../autopkgtest_2.3.7.dsc --- virt-subproc/adt-virt-lxc --ephemeral saucy-amd64 | 09:08 |
| jibel | rbasak, would you have a specific example? | 09:08 |
| rbasak | jibel: I'm trying now. It did reproduce reliably on php5 for me - trying a build now. | 09:08 |
| rbasak | jibel: I think it needs a fairly big pile of data before it falls over | 09:09 |
| jibel | rbasak, okay, I'll try with the kernel :) | 09:09 |
| jibel | I tried with php but it fails with a "no test in this package" error :/ | 09:14 |
| rbasak | Oh | 09:14 |
| jibel | which is a lie are there are obviously tests in the package | 09:15 |
| rbasak | Hmm | 09:15 |
| rbasak | Let's see what my test gives me. It's still buildling | 09:15 |
| rbasak | bulding | 09:15 |
| rbasak | building | 09:15 |
| * rbasak learns to type | 09:15 | |
| jibel | ah no, it is dsc0t-mod_php that exit with code 8 not adt-run | 09:16 |
| === vrruiz_ is now known as rvr | ||
| rbasak | jibel: reproduced: http://paste.ubuntu.com/6256204/ | 10:02 |
| rbasak | "adt-run --gain-root=sudo php5_5.5.3+dfsg-1ubuntu2.dsc --- adt-virt-lxc --ephemeral saucy 2>&1|tee ..." is all that is needed | 10:02 |
| rbasak | I'm on an OpenStack instance that may be a little contended for I/O | 10:02 |
| rbasak | It seems to happen when a large built tree is fed in by adt-run using tar | 10:03 |
| rbasak | The "tar x" on the "guest" side races overlayfs. If overlayfs is slow, then tar sees an intermediate step and bombs out. | 10:03 |
| rbasak | I think it only happens when the tar is large since otherwise the system can just hold it in cache and overlayfs is fast enough. It's when it has to hit the disk that it goes slow enough for the tar process to win the race. | 10:04 |
| rbasak | That's my theory, anyway. | 10:04 |
| rbasak | I'm interested to know whether these steps cause it to reproduce as easily in other environments. In my environment, it always fails. | 10:05 |
| jibel | rbasak, thanks for the details, I'll try to reproduce in the lab. | 10:07 |
| davmor2 | Morning all | 10:09 |
| jibel | pitti, I reported http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726714 + a patch | 10:20 |
| ubot5 | Debian bug 726714 in autopkgtest "adt-run fails when fakeroot not installed in testbed and build is needed" [Normal,Open] | 10:20 |
| pitti | jibel: merci, je vais le regarder | 10:21 |
| sonu | Noticed there are no manual test cases for Release upgrade using: | 10:49 |
| sonu | 1. sudo update-manager -d | 10:49 |
| sonu | 2. sudo apt-get dist-upgrade | 10:49 |
| sonu | Should we add these? | 10:50 |
| sonu | if so, to the existing test case "1468_Install (upgrade)" or create a new one? | 10:50 |
| elfy | sonu: have you seen testcase 1310 ? and dist-upgrade isn't for upgrading to a new release afaik | 10:56 |
| sonu | Elfy, sorry, my mistake overlooked 1310 | 10:57 |
| elfy | :) | 10:57 |
| sonu | I am noting few usability problems after upgrading from 13.04 to 13.10 | 10:58 |
| sonu | Like the windows are not being moved to work-spaces down with : Shift+Ctrl+Alt+ (Down Arrow) | 10:59 |
| sonu | while side arrows are working fine to move to work spaces | 11:00 |
| sonu | Shift+Ctrl+Alt+ (Up Arrow) does not work as well | 11:00 |
| elfy | probably better off in a support channel for that | 11:02 |
| sonu | noticed these had been changed automatically in keyboard shortcuts | 11:02 |
| sonu | the ctrl is changed with the window | 11:02 |
| sonu | ok, but I thought the standard keyboard shortcuts should not change on upgrade | 11:03 |
| elfy | as I said - try a support channel - I assume Ubuntu so #ubuntu | 11:03 |
| === _salem is now known as salem_ | ||
| === fader_ is now known as fader | ||
| Fawzib | hello, im trying to install 13.10 (server) but is freezing (or keyboard stops working) at the 'Select a language' screen. Using USB keyboard | 13:15 |
| stgraber | pitti: I'd have to recheck the code but it's likely that everything happens in a seperate mount namespace making those mounts invisible from the host | 14:34 |
| === salem_ is now known as _salem | ||
| DanChapman | afternoon everyone | 14:50 |
| elfy | hi DanChapman | 14:50 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === Effenberg0x0 is now known as EffenbergAway | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!