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