=== chihchun_afk is now known as chihchun [06:58] Good morning [07:00] mornign jibel [07:02] Hey elfy [07:09] bonjour jibel [07:11] jibel: want me to create utopic VMs as per a-p-t's doc/opening_a_new_release.md ? [07:11] goodday to you pitti [07:11] hey elfy [07:12] * elfy wants to know when the unicorn's package tracker's going to be there [07:30] pitti, I'll do it. Don't you want to use the latest autopkgtest and get rid of a-p-t this cycle? [07:30] pitti, bonjour :) [07:44] jibel: this cycle yes [07:44] jibel: I'm also happy to use adt-virt-qemu now so that we get a structure similar to the ppc64el/armhf jobs [07:45] jibel: but I suppose we want something running now to avoid blocking utopic, and I'd like to work on some systemd bits today for the sprint on the weekend [07:45] jibel: I don't think it's too much work to change the jobs for adt-virt-qemu, though; want me to have a look? [07:46] jibel: this is mostly changing jenkins_config.xml.tmpl to not run run-adt-test but adt-run, right? [07:46] pitti, right [07:46] and install an autopkgtest checkout etc. on wazn and friends [07:46] exactly [07:46] jibel: ok, I'll give this a go [07:49] jibel: btw, if we switch all the jenkins config to utopic, how do we keep the trusty jobs running? [07:49] jibel: I suppose we keep a-d-t around for the existing jobs? [07:49] pitti, yes we must keep it around for trusty and for dkms as well [07:50] ack [07:50] pitti, but there is no gating for package in trusty [07:50] s [07:50] jibel: ok, so don't do the VM creation for now, I'll create them using adt-buildvm-ubuntu-cloud and dist-upgrade those [07:50] pitti, k [08:06] jibel: do we still need auto-package-testing.20140219 ? [08:06] pitti, no, it's to please my paranoia of doing something wrong [08:07] jibel: ... but it's all in bzr? [08:07] I know :) [08:07] but ... [08:07] * pitti introduces jibel to the magic of revision control :) [08:07] jibel: I was wondering if there are any jobs which run with that old version [08:08] no, nothing really [08:08] ok, thanks [08:08] ah, can't delete, owned by usit [08:26] pitti, I think you can sudo to usit? [08:26] pitti, on albali that is? [08:26] jibel: I'm working on wazn ATM [08:26] ah [08:27] there shouldn't be any usit on wazn for a-p-t [08:27] jibel: had to fix autopkgtest to get along with saucy's qemu; VM build works nicely now [08:27] pitti, wazn should be upgraded to trusty BTW [08:28] oh, good [08:28] the others, too? running non-LTSes on servers is a bit hazardous [08:30] jibel: hm, don't we configure an apt proxy in the a-p-t VMs in the DC? that's the APTPROXY config option, but this isn't in ~/.adtrc [08:32] pitti, I don't remember if there was an issue accessing ftpmaster. Can you set it up and we'll disable the proxy if it causes problems [08:33] pitti, other servers are running Precise [08:34] jibel: oh, right; we don't use a proxy, but we configure a mirror [08:34] APTURI=http://ftpmaster.internal/ubuntu/ [08:36] jibel: so until we have cloud images, we don't set up a "build VMs" job, but just manually upgrade it every other day or so, right? [08:36] pitti, yes, that's what I did last cycle [08:36] ack [08:38] pitti, I removeed the directory owned by usit [08:38] thanks [08:38] jibel: I put the VMs into cache/disks/ FYI [08:40] autopkgtest/tools/adt-buildvm-ubuntu-cloud -m http://ftpmaster.internal/ubuntu/ -v -a i386 -o cache/disks/ [08:41] for the record, that's what I use to build the VM; then log in with "kvm -m 1024 -drive file=adt-trusty-amd64-cloud.img,if=virtio -nographic", sed trusty to utopic in apt, dist-upgrade, poweroff, and rename the .img file to *utopic* [08:46] pitti, want me to do it on other servers or you're scripting it too? [08:47] jibel: I'm doing aldebaran next [08:47] jibel: I seem to have lost my login to alderamin :( [08:47] jibel: can we scp the images between these hosts somehow? [08:48] pitti, I heard that alreramin died yesterday [08:48] ssh responds, but asks me for password [08:49] so if you can't log in either, let's ignore it for now [08:49] ah right, offline in jenkins too [08:50] pitti, we cannot scp between hosts [08:51] ok, I'll just download and reupload them through my workstation then [08:51] adt-run: & apt0t-build: - - - - - - - - - - stderr - - - - - - - - - - [08:51] sh: 1: /autopkgtest/tmp/apt0-build/libpng-1.2.50/debian/tests/build: Numerical result out of range [08:51] WTF? [08:51] that's autopkgtest/run-from-checkout libpng --- qemu cache/disks/adt-utopic-amd64-cloud.img [08:52] pitti, on wazn? [08:52] yes [08:52] I'll have a closer look [09:00] hm, ftpmaster link is quite a bit on the slow side this morning [09:07] meh, 5 minutes to download 20 MB [09:13] pitti, I've the confirmation that alderamin is dead [09:13] pitti, disks have been replaced and recovery is in progress [09:13] thanks [09:16] pitti, I'm wondering if we should call everything devel instead of utopic so we don't have to do it again next cycle [09:17] jibel: hmm, my gut feeling is that it's better to call them after the release, so that we can continue to use them for SRUs; and the VMs have to be manually upgraded either way? [09:21] right, copying the devel VMs to stable would be the same anyway [09:22] and then we'd have to fork off the stable ones [10:14] pitti, I've setup tachash and the views in jenkins to receive the jobs, should I create the jobs that create container for ppc64el and armhf? [10:15] jibel: oh, that sounds good; they use debootstrap for LXC, so that should Just Work [10:15] doing now [10:16] jibel: still creating VMs on albali and aldebaran, with an excruciating 30 kB/s.. [10:16] and debugging that weird qemu error on wazn [10:17] jibel: so in theory something like http://paste.ubuntu.com/7321272/ ought to work; but the VM path is different on albali (/var/cache/adt/disks/ instead of $HOME/cache/disks/) [10:18] heh E: No such script: /usr/share/debootstrap/scripts/utopic [10:18] jibel: not sure how this works wiht the current jobs, but we might just create a symlink $HOME/cache -> /var/cache/adt / [10:18] there is a link missing [10:18] jibel: new debootstrap is in utopic [10:19] so if I ssh into that VM and run the same script, it works just fine, so it's presumably not qemu but something weird in adt-virt-qemu [10:20] pitti, do you want to upgrade ppc64el and armhf to utopic? otherwise I'll just create a symlink in /usr/share/debootstrap/scripts/ [10:20] jibel: hm, upgrading the kernel and debootstrap sounds fine, but otherwise just create the symlink [10:25] jibel: I created the cache/ symlink now on albali, so that the paths are the same on all nodes [10:25] thanks [10:34] jibel: oh, so that weird error only happens on the 9p shared dir [10:34] ubuntu@autopkgtest:/autopkgtest/tmp/apt0-build/libpng-1.2.50$ debian/tests/build [10:34] -bash: debian/tests/build: /bin/sh: bad interpreter: Numerical result out of range [10:34] calling sh debian/tests/build works fine [10:34] WTH [10:35] pitti, and it works fine with latest trusty images of course? [10:35] jibel: I never saw it on trusty host, yes [10:35] jibel: so this will presumably just go away when we upgrade wazn to trusty [10:35] but I do some more experiments [10:35] and there is no difference with utopic yet [10:35] we might just disable the shared downtmp for qemu when running on a too old kernel [10:36] as we call apt-get source in the testbed, we won't need to scp the source package from the host into the testbed either way, so it's not such a big performance loss [10:36] (and still much better than with a-p-t) [10:37] jibel: I'll try that on precise, if these apts ever finish :) [10:38] that reminds me of a nice optimization that we should do -- disable all translations in apt, including the English ones [10:42] jibel: ah, even worse on albali/aldebaran, qemu-img doesn't yet understand -q; /me works around [10:46] jibel: eek -- aldebaran has kvm processes from Apr 04 and two kvm processes from 2013 [sic!] [10:46] * pitti takes the zap-o-matic [10:47] pitti, utah? [10:47] ah, can't, they run as root :( [10:47] jibel: yes [10:47] pitti, I think you can kill those that belongs to utah but not the rest [10:47] jibel: so there are 10 kvm processes running which should all go [10:48] jibel: no, I can't, they all run as root [10:48] (why on earth do they do that??) [10:48] I don't have sudo on the box [10:48] I don't know who uses buildbot [10:48] no wonder why it's so slow [10:52] jibel: ah, I see the utopic-adt-setup-lxc failure; do you want me to push utopic's debootstrap to all boxes? [10:52] or are you already at it? [10:52] pitti, I created a symlink, so we can wait until the boxes are properly upgraded to utopi [10:52] c [10:52] ah, you are already re-running it [10:53] yes I did [10:53] $ ./cmd ppc64.hosts sudo lxc-ls --fancy [10:53] yay, all of them have adt-utopic :) [10:53] and it succeeded on wolfes [10:54] oh, someone made cyclops-node24 reappear (it was dead a few days ago), I need to do some admin/cleanup on that [10:54] * pitti does [10:57] http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-setup-lxc/2/ [10:57] jibel: such a nice view :) [10:58] jibel: so except for the debootstrap link this pretty much Just Worked, or did you have to fiddle with anything else? [11:00] pitti, it Just Worked [11:00] well, I had to renew all the keys in known_hosts :) [11:03] jibel: ah, because they got reinstalled [11:05] pitti, when VMs are ready I'll push a test request from snakefruit [11:05] jibel: I fixed the qemu-img issue; I'm now working on not using the 9p shared dir for qemu < 1.7, so that this works on precise and saucy [11:06] jibel: can you push a test request for ppc64el and armhf only? [11:06] jibel: oh, and we need to commit something like http://paste.ubuntu.com/7321272/, right ? [11:06] pitti, no they are children jobs of intel tests [11:07] pitti, sounds good [11:10] ah crap, it's not actually that easy to disable the 9p dir [11:12] jibel: do you know when wazn gets upgraded to trusty? [11:12] pitti, no, waiting for larry [11:12] apart from us nobody uses it, so it could be any time [12:02] jibel: I deployed a workaround; this command now succeeds on wazn, aldebaran, and albali: autopkgtest/run-from-checkout libpng --- qemu cache/disks/adt-utopic-amd64-cloud.img [12:02] I also tried with i386 [12:02] pitti, there are 5 packages wiating in the queue [12:03] oh [12:03] jibel: so want me to commit the jenkins_config.xml.tmpl? [12:03] pitti, yes and deploy it [12:04] pitti, http://paste.ubuntu.com/7321864/ [12:04] to disable languages [12:04] right, I was going to add something like that [12:06] jibel: committed and rolled out to wazn, albali, aldebaran; I figure you need to roll it out to tachash for the job config change to get active? [12:07] pitti, done [12:08] hm, all rather large packages [12:08] jibel: can we try with libpng first? [12:08] jibel: oh, and how do we update these 5 jobs to use the new template? delete them, or fix manually? [12:09] pitti, they'll be fixed on next run [12:09] actaully I'll resubmit them [12:12] pitti, libpng is running [12:12] whne it's done I'll resubmit the other if it is successflu [12:12] ful [12:13] \o/ [12:14] jibel: hm, I just noticed the hanging saucy-adt-setup-testbed #206 on aldebaran [12:14] jibel: should we still be running this? [12:14] matsubara uses it for maas [12:14] No test report files were found. Configuration error? [12:16] oh, is $WORKSPACE something which needs to be set in the script? [12:16] ah, there are some bits we might want from a-p-t [12:17] ./jenkins/jenkins_config_ppc64el.xml.tmpl doesn't define that either, though [12:17] no $WORKSPACE is set by jenkins but the was an xml file generated that jenins uses to interpret the result [12:17] we can just disable that [12:19] jibel: so $WORKSPACE should have been something like $HOME/workspace/utopic-adt-libpng/ARCH/amd64/label/adt ? [12:19] yes [12:20] jibel: that has a /results dir with a log (but missing stdout/stderr and others) [12:20] green http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-libpng/2/ARCH=i386,label=adt/ [12:21] pitti, but when a job starts it's emptied. And I restarted them [12:21] ah [12:21] workspace/utopic-adt-libpng/ARCH/i386/label/adt/results/ on wazn looks great [12:22] yippie! [12:22] pitti, the problem was that jenkins expected an XML result file that we don't generate anymore [12:22] so I disabled it in the configuration [12:23] jibel: so what's needed to refresh the config of the already created jobs? [12:23] http://paste.ubuntu.com/7321973/ [12:23] ah [12:24] jibel: your slave-admin/ppc64.hosts change looks a bit odd -- the user name is already in slave-admin/ssh_config; why do you need that? [12:24] pitti, I didn't commit that change. wolfes rejected me without that [12:25] jibel: oh, perhaps you have a wolfe-* config in your real ~/.ssh/config ? [12:25] no [12:25] pitti, so I'll resubmit other jobs and they should reconfigure themselves [12:26] jibel: sweet, many thanks [12:26] jibel: with ftpmaster being so slow, they'll take a whil [12:26] e [12:26] and with aldebaran having umpteen ancient qemus which eat all memory [12:29] pitti, if you have access to ubuntu-archive could you remove the files called trusty in /home/ubuntu-archive/proposed-migration/autopkgtest/data/adt/utopic-proposed/amd64/work/ [12:29] on snakefruit [12:30] jibel: done [12:30] thanks [12:36] pitti, jobs are running but crash crashed with index not found :/ [12:36] on ddebs [12:37] on amd64, yes [12:37] on i386 it's differently interesting: http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-crash/2/ARCH=i386,label=adt/console [12:37] and qemu didn't start for ceph [12:37] jibel: I'll look into ddebs; I set it up this morning, but appparently some stuff went wrong [12:39] ah, dh_listpackages is from debhelper; it seems we had that in our previous VMs always? [12:40] pulled as a dependency? [12:40] ah yes, we did [12:40] so, I need to eliminate that from adt-run (I don't want to depend on debhelper) [12:43] it was installed as a dependency of autopkgetest [12:47] jibel: oh dear, now we are going to get new spam for all the (known) failing armhf/ppc64el packages === _salem is now known as salem_ [12:51] jibel: indexes for utopic-{security,updates} built [12:53] pitti, I'll disable notifications until it's stable, what do you think? [12:54] jibel: sounds good [13:07] pitti, the overlay is in /tmp not in memory? [13:07] jibel: oh right, forgot to specify that [13:08] -o OVERLAY_DIR, --overlay-dir OVERLAY_DIR [13:08] Temporary overlay directory (default: in /tmp) [13:09] jibel: so we need to call --- qemu -o /run/shm/ [image] [13:09] pitti, okay, I'll change that [13:10] jibel: committed [13:10] thanks :) [13:10] jibel: well, that was easy -- you have the bigger trouble with rolling this out :( [13:10] sorry, forgot about that [13:10] pulled [13:10] I've had /tmp on tmpfs for ages [13:10] I keep forgetting that it isn't a default [13:11] that'll speed up things noticeably, especially on wazn [13:11] s/wazn/albali === bfiller_afk is now known as bfiller [13:18] pitti, can you try to login to alderamin, it's back [13:18] jibel: yes, works [13:19] pname|#gid] [-p prompt] [-u user name|#uid] file ... [13:19] erk [13:19] $ sudo -u auto-package-testing -i [13:19] that fails, though; does that work for you? [13:20] pitti, it doesn't. Larry's on it [13:21] ping balloons [13:23] pitti, it should work now [13:25] yes, works [13:25] jibel: I'll set up the bits [13:26] Could not access KVM kernel module: Permission denied [13:27] retoaded: ^ on alderamin for auto-package-testing [13:27] retoaded: i. e. adduser auto-package-testing kvm ? [13:27] pitti, fixing that too [13:28] $ sudo -u auto-package-testing -i [13:28] groups: cannot find name for group ID 1030 [13:28] retoaded: thanks; this ^ also looks suspicious? [13:28] retoaded: right, group auto-package-testing with id 1030 is missing (there are existing files with that, so would be nice to restore that GID) [13:30] pitti, incorrect GID pulled in, should be fixed now for both a-p-t and u-t [13:30] retoaded: cheers! [13:32] retoaded: on aldebaran we have some 10 QEMU processes which are very old (some from 2013!), would you mind killing pgrep -u root kvm ? [13:32] pitti, checking but I know 6 should actually be in use [13:34] retoaded: oh, you mean the ones from 2013 are permanent ones, not ephemeral ones for testing? [13:34] pitti, the 6 running since 2013 are permanent VMs [13:34] yes [13:34] ah [13:34] those will, at some point, get moved into the cloud [13:45] jibel: ah, I restarted crash, but it seems that job config hasn't updated for --overlay-dir yet [13:47] pitti, it is not enough to restart it from jenkins because it is the job the submit jobs to jenkins which reconfigures jenkins. [13:48] I requeued it [13:48] to requeue a job, you copy a state file in tachash:/var/local/adt/utopic/in [13:52] jibel: I'm out for about an hour for some running [13:53] pitti, okay, I'll go running later this evening. Is there anything you want me to continue on alderamin? [13:53] jibel: VMs are building, when I'm back I'll do the upgrade and the "old qemu" workaround [13:53] actually, I can do the latter already [13:54] (done) [14:23] jibel: hm, did you already move the VMs to adt-utopic-* on alderamin? they are already there, apparently from this morning [14:23] jibel: or was that dir perhaps copied from some other host? [14:24] pitti, I finish the preparation of the VMs and currently running libpng [14:24] finished [14:24] jibel: ah, good; because I still see the adt-trusty* ones; I suppose I can kill these then [14:25] pitti, yeah it took 30min just to update the VM and was waiting for it to be done before removing the original [14:25] pitti, your running was fast :) [14:26] pitti, so libpng passed, we can restart the slave I guess [14:26] jibel: yes, didn't shower yet :) [14:26] jibel: great! [14:26] pitti, that's why it sometimes nice to work in an office next to each other :P [14:26] not to work [14:27] jibel: so we have the "cannot allocate port 10022" bug, and the timeout on copying (e. g. on bintuils) [14:27] I'll look into those [14:27] jibel: heh, yes; I was about to start the apt-get update before showering :) [14:28] retoaded, can you restart alderamin-adt ? [14:29] retoaded, the job is called auto-package-testing-jenkins-slave [14:32] jibel, sure [14:39] pong elopio [14:46] jibel: FTR, I manually added the -o /run/shm/ to all existing jobs now, so we can retry in jenkins [15:54] pitti, with the new autopkgtest and the modification of the jobs there is a bit missing and we are not exporting the results to update britney [15:55] previously the job ran: $BINDIR/adt-export-result -D $ADTLOG_PATH $PKGNAME $RES at the end of the run in the testbed to generate a result file with the package it's dependencies and the resutl [15:55] its [15:56] jibel: was that done by run-adt-test? [15:56] pitti, no by the script that called adt-run inside the testbed: bin/testbed/run-adt [15:57] ah, that does more than just copying the results out of the testbed to the host? [15:57] right, that result file [15:59] yes it generates something like: trusty amd64 apport 2.14.1-0ubuntu3 PASS python3-problem-report 2.14.1-0ubuntu3 lsb-base 4.1+Debian11ubuntu6 gdb-minimal 7.7-0ubuntu ... [16:00] jibel: so we need to generate that from the summary, *-packages, and testpkg-version [16:01] jibel: it needs all the dependencies for comparing with what britney requested? [16:01] pitti, yes [16:02] pitti, we could fetch all the *-packages and merge them [16:02] jibel: that's more than just the direct rdepends, if that doesn't hurt? [16:02] I guess in the medium term britney should just look at these files directly [16:03] pitti, in this direction it won't hurt because the request will contain less deps so we'll be able to match them all [16:03] wow, surprising wave of green in http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/ [16:06] pitti, okay, I can easily grab and merge the files with jenkins api. I'll do that. [16:07] jibel: does it all need to be one line? we could do some seddery in the job to concat the files and prepend the $ARCH $PACKAGE $RELEASE etc. variables? [16:11] pitti, that's fine I'll do that at the end of the job so I don't have to modify the rest of the machinery [16:17] pitti, $RELEASE $ARCH $PACKAGE $(cat *-packages| tr -s '[\n\t]' ' ' ) [16:18] jibel: aren't you missing $(cat testpkg-version) ? [16:18] after $PACKAGE [16:18] pitti, I do [16:19] I'm driving my daughter to the dentist and will do that when I'm back [16:19] jibel: nice, thanks; I'll be gone by then [16:19] jibel: so, good night and many thanks for today [16:20] I think I fixed the ValueError: invalid literal for int() with base 10: '' now [16:20] * pitti deployz === bfiller is now known as bfiller_afk === roadmr is now known as roadmr_afk [17:35] sorry for the contentless ping. [17:35] balloons: now I can build and provision the click for reminders [17:35] but I can't open the app on the phone. [17:36] probably, I'm still doing something different than you. [17:36] elopio, why not? And I think I can fix the build issues with reminders.. dpm fixed it for fm, testing it now [17:36] by fix, I mean push something to trunk that works with qtcreator and click-buddy :-) [17:36] balloons: but I only want to run the test for now, can you send me your click file, please? [17:36] elopio, sure [17:36] balloons: the upstart log says it has no premissions to execute reminders. [17:37] I think my click doesn't have the binary. [17:37] elopio, actually.. hmm. I can rebuild it, but my box froze and it was in my temporary chroot [17:39] diabolic reminders app [17:39] I wonder if I can pull the click from my device somehow [17:40] balloons: at this point, I'm just doing click-buddy --arch armhf --dir . --provision from your branch. [17:40] how are you building the click? [17:41] elopio, in my own chroot [17:42] using click-buddy --dir . --provision [17:42] I tried that at some point. I'll do it again. [17:42] balloons: in your chroot for 13.10 or 14.04? [17:42] 14.04 [17:44] lucky me has to install ubuntu-sdk in the chroot again.. this will be a long time === roadmr_afk is now known as roadmr [17:46] i'll let it run if you still need it in a bit, I'll share :-) [17:55] balloons: yes, same result with 14.04, it doesn't open. [17:55] elopio, I would assume sudo click chroot -a armhf -f ubuntu-sdk-14.04 create would work, but it's not what I use [17:56] still setting up the sdk.. I'll build as soon as it's done.. Maybe another 20 mins total [17:56] balloons: that's how I created the chroot. [18:04] it's not the same error though. [18:04] doing it with the 1404 chroot I get Unable to exec 'reminders' in '/opt/click.ubuntu.com/.click/users/phablet/com.ubuntu.reminders': No such file or directory [18:05] elopio, hmm.. naming issue? this is simply trying to run the app, not run the tests? [18:05] balloons: yes, opening the app from the dash. [18:10] yay, base tarball updated :-) [18:18] ok, finally we're building reminders [18:23] evening balloons elopio [18:23] hello elfy [18:23] chroot is the topic at hand elfy :-) and click packages.. fun stuff [18:24] * elfy has feet up with tea in hand :) [18:25] click packages mmm - I hope they work ok [18:25] with flavours as well :p [18:27] balloons: do you know if the artwork for the 14.04 CDs is available for download? [18:27] elopio, artwork as in what? And yes it is.. That stuff is all in packages [18:28] balloons: this artwork http://shop.canonical.com/images/UBN00216-1.jpg [18:28] the CD cases or boxes. [18:30] la_juyis: oh, btw, I'll be here in case you need a hand with the rss. [18:31] elopio, ahh.. that I don't know [18:31] elopio, :) I'm with that [18:39] elopio, have to run for a bit, but I have a click for you [18:39] \o/ [18:39] no idea if it will work or not [18:39] should be the same as last time [18:40] I'll give it a try. [18:41] elopio, http://ge.tt/5ncArPd1/v/0. It should be done in a second [18:47] it opens! [18:47] finally, thanks balloons. === bfiller_afk is now known as bfiller [19:00] balloons: my branch is just missing an eventually *>* === roadmr_ is now known as roadmr [19:06] elopio, balloons hi [19:09] :D === elopio_ is now known as elopio === salem_ is now known as _salem [21:35] elopio, so your branch all set now? [22:11] balloons: it is. [22:11] what do you think about it? [22:11] elopio, link? [22:12] * balloons overwhelmed with links in browswer [22:15] balloons: https://code.launchpad.net/~elopio/reminders-app/test_go_to_accounts2/+merge/214163 [22:22] elopio, you've tweaked some things.. I wasn't sure what to think of the structural changes [22:23] I guess that feedback is more for reminders as it is in trunk [22:23] this mp just builds on it.. [22:24] balloons: ok, but it's still easy to change any module. They are small, shoot your complaints. [22:25] fixtures are interesting [22:26] elopio, I was mostly referring to having the RemindersApp class.. I remember that being interesting and different [22:27] I don't think I would push to change anything just yet, I'm just curious how things will evolve. I'd like to keep going with it [22:27] balloons: ok, feel free to suggest changes at any moment. We can experiment a lot with reminders. [22:28] elopio, I'll do a quick review and approve your mp, assuming it works :-) [22:28] balloons: I wanted you to take a look basicaly to ask for a good place to put the URLDispatcher fake service and fixture. [22:28] url dispatcher has no autopilot package. [22:28] but we will use this helpers on many places. [22:29] yes, fm has it.. and some others [22:29] *these [22:29] so basically the whole of fake_services.py? [22:32] balloons: yes. [22:33] I thought of ubuntuuitoolkit, but the toolkit has no dependency on URL dispatcher [22:33] so it sounds weird. We might be throwing evereything to the toolkit just because we have no better place. [22:33] dispatcher is outside the sdk? [22:34] right.. well, I mean I consider the helper to be a ubuntu-sdk helper.. [22:35]