[05:49] <pitti> Good morning
[07:55] <jibel> Good morning
[09:37] <slickymaster> morning all
[11:00] <davmor2> Morning all
[11:03] <slickymaster> morning davmor2
[12:44] <rbasak> pitti, jibel: do you have any thoughts on adding armhf dep8 testing to -proposed migration gating, please? I presume you need hardware, of course, but if I could provide a suitable chassis, then are there any other implications to doing this?
[12:44] <pitti> rbasak: we actuall had that running for a while, but tore it down again because it was too unreliable
[12:45] <pitti> at least at that time there was no suitable virtualization technology, and RAM/storage was too small even for LXC
[12:45] <pitti> rbasak: with a Calxeda box that should probably work; do we have one available now?
[12:45] <rbasak> pitti: we may do. I'm trying to figure that out. What hardware were you running on before?
[12:46] <pitti> rbasak: Panda boards
[12:46] <rbasak> I see.
[12:46] <pitti> rbasak: I take it we'd start with adt-virt-lxc?
[12:46] <pitti> (as there's no qemu)
[12:46] <rbasak> I'm not sure. That's up for discussion, I guess.
[12:46] <pitti> rbasak: I think tests without "Restrictions: needs-root" should probably mostly get along with lxc
[12:46] <pitti> things like udisks, upstart, or gvfs won't
[12:47] <rbasak> We do have rudimentary qemu now I believe, but that would require an A15 box, and I'm not sure about availability of those.
[12:47] <pitti> but I think the majority of our tests don't need root, so having at least those covered by ARM would be great
[12:47] <rbasak> An alternative would be to do bare metal, and reinstall every time. Depending on how many nodes are available that may not be too bad.
[12:47] <pitti> rbasak: well, it's better to start small anyway; so if we have a box big enough to run lxc on, that'd already be something
[12:47] <pitti> rbasak: no, we tried that, and it was maintenance hell
[12:47] <pitti> that's what we did with the panda
[12:48] <pitti> s
[12:48] <rbasak> I have had automated install running well and reliably on highbanks in the lab for years
[12:48] <pitti> those would be nice for running the needs-root tests, of course
[12:49] <rbasak> This hardware needs to go into a dedicated lab, right? So it can't share resources with anywhere else?
[12:49] <pitti> rbasak: I don't know much about the lab organization, I'm afraid
[12:49] <rbasak> Who do I need to ask about that?
[12:49] <pitti> rbasak: my gut feeling is that having reliable network access to them is sufficient
[12:50] <pitti> rbasak: retoaded and jibel are good people to talk about that, I think
[12:50] <pitti> rbasak: that'd be great indeed
[12:50] <rbasak> If remote, then do the nodes still need to be permanently allocated to Jenkins?
[12:50] <rbasak> Or is there any opportunity for a more dynamic mechanism?
[12:50] <pitti> rbasak: also, I haven't yet tried running tests in the ubuntu emulator; that might also be worth a try at least for the no-root ones
[12:51] <pitti> rbasak: I think you can add/remove executors to jenkins fairly dynamically; but again, that's jibel's area
[12:51] <rbasak> I think I can get you a suitable chassis or access to one. It's not certain yet, though, but I'd like to progress further with figuring out how this would work.
[12:51] <pitti> rbasak: nice! thanks for that
[12:52] <rbasak> I'll wait for jibel to see this I guess. Thanks!
[12:55] <jibel> rbasak, autopkgtest have been running on pandaboards in LXC with external drives for a while. But they were constantly dying under load and required most of the time required manual intervention. Maintenance cost was clearly too high compared to the benefit.
[12:55] <jibel> if there is something more reliable why not
[12:55] <pitti> ah, they already used lxc
[12:56] <jibel> rbasak, the other point is that we'll want to not gate everything on ARM testing because that'd would slow down the whole publication
[12:57] <jibel> and we'd need to be able to select which package to run on which architecture
[12:57] <rbasak> jibel: that makes sense. Is it possible to have a list of packages that we care about, and just test those?
[12:58] <pitti> I think at first we want to run all (non-root) tests but don't gate on them
[12:58] <jibel> rbasak, it is possible, but requires changes in the interface with britney
[12:58] <pitti> to see how many tests need adjusting and how stable the system is
[12:59] <jibel> pitti, that's easy because it is how it was running before I disabled it
[12:59] <rbasak> jibel: OK, so what should we do next? If I get you a chassis, would that be useful, or would it need to sit unused while we sort out the infrastructure changes?
[13:00] <rbasak> jibel: also, does the chassis need to go to a particular lab, or is remote access OK?
[13:00] <retoaded> pitti, we do have a Calxeda available within the lab and have 4 nodes on it allocated for jibel
[13:01] <retoaded> pitti, with a possibility of allocating a few more if needed
[13:01] <pitti> retoaded: nice! I guess they are beefy enough to host one or two GB (temporarily)?
[13:01] <retoaded> pitti, should be
[13:03] <retoaded> pitti you can log into cyclops-node02 if you want to check one of the nodes out
[13:04] <pitti> retoaded: Host cyclops-node02.ubuntu-ci not found: 3(NXDOMAIN)
[13:04] <pitti> retoaded: I guess I need some other gateway?
[13:05] <pitti> retoaded: sorry, forgot to start VPN after reboot
[13:05] <retoaded> pitti, shouldn't. let me check it; may not have added the shotname cname value to DNS
[13:05] <pitti> retoaded: asks me for password
[13:05] <retoaded> pitti, ahhh, that could explain it too
[13:05] <pitti> retoaded: (as pitti)
[13:05] <retoaded> pitti, see PM
[13:06] <pitti> thanks
[13:06] <retoaded> np
[13:06] <pitti> /dev/sda2        46G  1.6G   42G   4% /
[13:06] <pitti> holy crap, 42 GB? that's an ARM machine! :-)
[13:06] <pitti> /dev/sda3       409G   71M  388G   1% /data
[13:07] <pitti> retoaded: can I install lxc and autopkgtest on that, etc.?
[13:08] <retoaded> pitti, yep. that is one of the systems allocated to jibel so do what you want :-)
[13:08] <pitti> retoaded: so even dist-upgrade to saucy, or even trusty? (not sure how much maintenance their base systems get from you)
[13:08] <pitti> retoaded: sweet, thanks
[13:08] <retoaded> pitti, I haven't done anything with them since the base install
[13:09] <retoaded> pitti, you have node02 to node05 allocated atm
[13:09] <pitti> rbasak, jibel: I'll set up cyclops-node02 for saucy, create a trusty LXC container on it and run a few autopkgtests to get a feeling
[13:10] <pitti> retoaded: ah, packages seem a bit broken, running apt-get -f install; is "reboot" safe?
[13:11] <pitti> (/boot is full, cleaning up a few old kernels)
[13:18] <pitti> retoaded: ok, reboot worked fine, and kernels cleaned up
[13:18] <retoaded> pitti, ack
[13:32] <jibel> retoaded, ah, I completely forgot this system, thanks for reminding me :)
[13:33] <pitti> jibel: I'll fix and upgrade node03 in the meantime
[13:33] <jibel> retoaded, are we free to do what we want with these nodes and there is some kind of CI procedure to follow?
[13:43] <WebbyIT> Hey balloons :-)
[13:48] <pitti> jibel, retoaded: meh, I'm afraid I already killed cyclops02 -- it seems it doesn't like the saucy kernel?
[13:48] <pitti> sorry about that
[13:49] <jibel> pitti, ah, it wasn't long :)
[13:49] <jibel> rbasak, that's how it goes with testing on ARM ;)
[13:49] <pitti> I'll try and keep the raring kernel on cyclops03
[13:50] <retoaded> jibel, yes, you are completely free to do what you need with those 4 nodes
[13:50] <rbasak> What you want is a one-command "restore this machine" tool, that works out-of-band so doesn't care about the state of the machine.
[13:51] <rbasak> IMHO, this should be the case for any deployment anywhere. I wrote this for pandaboards and later extended to the highbanks. Then breaking a node no longer matters :)
[13:51] <pitti> $ fix-machine --boot-raring-kernel cyclops-node02
[13:52] <rbasak> Pretty much, yeah. My command took URLs or paths to d-i kernel, initrd, kernel parameters, etc, ran expect on the serial console, and exited with a zero status on success.
[14:23] <balloons> hey WebbyIT
[14:25] <WebbyIT> balloons, I hope you are fine :-) What's about https://code.launchpad.net/~sergiusens/ubuntu-calculator-app/cmake/+merge/202176?
[14:28] <balloons> WebbyIT, using cmake is going to allow you to test easier using a new tool sergio wrote
[14:28] <balloons> he used calculator as the test
[14:28] <WebbyIT> balloons, interesting! So, I leave to you the honour to review it ;-)
[14:29] <balloons> WebbyIT, :-) I'll leave some details about how it works
[14:29] <WebbyIT> yeah, awesome, thanks!
[14:40] <pitti> rbasak: hey, maybe you know: I dist-upgraded that arm node from raring to saucy, but I want it to boot with the raring kernel
[14:41] <pitti> rbasak: i. e. I'd move the /boot/vmlinuz and initrd.img symlinks to the old kernel
[14:41] <pitti> rbasak: do I need to run anything else to activate that, or will the boot loader just work? (that's /boot/boot.scr apparently, and just says "vmlinuz")
[14:43] <pitti> I might need to run flash-kernel for that?
[14:43] <pitti> retoaded: ^ or maybe you know
[14:44] <pitti> retoaded: so cyclops-node02 is fully upgraded to saucy (3.11.0-15 kernel) and didn't come back after reboot; node04 is just a plain upgrade to current raring (-35 kernel), and came back; node03 is upgraded to saucy, but didn't reboot yet; I'd like to reboot with the raring kernel to avoid the same fate as node02
[14:44] <retoaded> pitti, hmmm .....
[14:45] <pitti> retoaded: ah, I'll ask ogra about that, he'll know
[14:45] <retoaded> pitti, ack. in the mean time I'll look at node02
[14:46] <rbasak> pitti: I don't recall, off the top of my head. Running "sudo flash-kernel" won't hurt.
[14:46] <rbasak> pitti: can you pastebin boot.scr and `ls /boot`?
[14:48] <pitti> rbasak: /etc/kernel/postrm.d/zz-flash-kernel calls that with an ABI
[14:48] <pitti> rbasak: I haven't changed anythign yet, doing now
[14:50] <retoaded> pitti, node02 did come back up but assigned the wrong interface in the default route
[14:50] <retoaded> it's fixed now
[14:51] <pitti> retoaded: ah, good to know
[14:51] <pitti> retoaded: what did you change, so that I can do the same change to node03 before I reboot?
[14:53] <retoaded> pitti, I set eth1 to manual in /etc/network/interfaces
[14:53] <pitti> indeed, I wonder what the second one is
[14:53] <rbasak> pitti: IIRC, on highbank, flash-kernel does very little, since U-Boot can read /boot/vmlinuz directly. I think the boot.scr just points to it and sets parameters and that's all. But it's been a while.
[14:53] <pitti> rbasak: right; now that I know that both kernels work and it's due to /e/network/interfaces, I can verify that safely :)
[14:55] <pitti> 10.98.3.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
[14:55] <pitti> 10.98.3.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
[14:55] <pitti> retoaded: ^ indeed, that's from the (not yet rebooted) node03; that looks wrong
[14:56] <retoaded> that is does
[15:09] <pitti> retoaded: nice trick with ipmitool; node05 isn't reachable via network (and I haven't touched that at all yet); I salvaged that as well
[15:09] <retoaded> pitti, sweet
[15:09] <pitti> so same old by now, fix overflowing /boot, fix apt, upgrade to saucy
[15:26] <pitti> rbasak: ah, too bad -- adt-virt-lxc only works with a cloud image (we really need to fix that), and lxc-create -t ubuntu-cloud barfs with "confused by argument: armhf"
[15:26] <pitti> I take it we don't have armhf cloud images?
[15:26] <pitti> hm, actually we do on http://cloud-images.ubuntu.com/trusty/current/
[15:35] <rbasak> pitti: is that an lxc bug? I think lxc-create should work with armhf on -t ubuntu-cloud.
[15:35] <pitti> rbasak: figured it out; I took trusty's cloud-image-utils, worked now
[15:35] <pitti> saucy's is too old for armhf
[15:35] <rbasak> Ah, OK.
[15:39] <pitti> rbasak: adt-virt-lxc still doesn't seem to like them, though :(
[15:40] <pitti> RuntimeError: Failed to find host root directory for container 'adt-virt-lxc-qcayey'.
[15:40] <pitti> "sudo lxc-start-ephemeral -o trusty-cloud" works perfectly, though
[15:42] <pitti>         host_guest_root = '/var/lib/lxc/%s/%s' % (lxc_name, subdir)
[15:42] <pitti> ooh
[15:42] <pitti> that's not true, I have containers in /data/lxc/
[15:42] <pitti> we need to teach that to read the LXC config
[15:43] <pitti> hah!
[15:44] <rbasak> That whole area of the code is a hack.
[15:45] <rbasak> The moment we can have lxc-wait support, it can all go away
[15:45] <rbasak> bug 1266808
[15:45] <pitti> *nod*
[15:47] <pitti> meh, cloud images' apt sources use archive.u.c. instead of ports
[15:52] <slickymaster> hey DanChapman
[16:02] <DanChapman> hey slickymaster :-)
[16:04] <pitti> retoaded, jibel: so cyclops-node0[2345] are now running up-to-date saucy and reboot reliably; cyclops-node0[23] have lxc installed and "trusty" and "trusty-cloud" (cloud-image) containers
[16:04] <pitti> $ sudo adt-run -B libpng_1.2.49-5ubuntu1.dsc --- adt-virt-lxc --ephemeral trusty-cloud
[16:04] <pitti> jibel, rbasak ^ succeeds at last \o/
[16:04] <pitti> I had to fix and upgrade the trusty cloud image
[16:04] <slickymaster> DanChapman: thanks for that, mate. I really appreciate it
[16:04] <retoaded> pitti \o/
[16:04] <jibel> pitti, wow
[16:04]  * jibel is impressed
[16:05] <pitti> I'll set up apt-cacher-ng on node2/3 to speed up things
[16:05] <DanChapman> slickymaster, No worries when is the membership meeting? I will try to turn up aswell :-)
[16:06] <jibel> pitti, they should have access to apt proxy on tachash
[16:06] <pitti> jibel: ah, is that squid or apt-cacher-ng or something else?
[16:06] <jibel> it is running on port 8000
[16:07] <jibel> pitti, squid
[16:07] <slickymaster> DanChapman: the meeting will be held on February 6th, 2014 at 22:00:00 UTC in #ubuntu-meeting on irc.freenode.net
[16:08] <slickymaster> DanChapman: if you're willing, which I thank you, I'll ping you coming the day
[16:08] <pitti> jibel: works fine, thanks; I'll configure it on all four nodes
[16:08] <jibel> pitti, that's what upgrade tests are using and it works quite well
[16:13] <pitti> jibel: done
[16:15]  * pitti tries the postgresql-plsh autopkgtest, that's more elaborate
[16:19] <pitti> works
[16:20] <pitti> jibel: that looks quite promising indeed!
[16:20] <pitti> jibel: want me to set up the other two nodes while I'm at it?
[16:21] <jibel> pitti, if you have time for it,  go ahead
[16:45] <pitti> jibel: I suggest we don't create fresh trusty-cloud containers daily, but instead dist-upgrade that instance
[16:45] <pitti> jibel: today's armhf cloud instance is horribly outdated (dist-upgrade takes like 20 mins), and it needs some adjustment after creation
[16:55] <pitti> jibel: ok, all four nodes are now ready to run autopkgtests; I tested libpng on all four
[16:55] <pitti> jibel: in case you wonder, containers are in /data/lxc/, /etc/lxc/lxc.conf configures that
[16:55] <pitti> jibel: as /data/ has tons of space
[16:56] <pitti> rbasak: ^ FYI
[16:56] <rbasak> utlemming: ^^ - I guess we need to sort these out?
[16:57] <pitti> utlemming: ah, are you building the armhf cloud images? their apt sources use archive.u.c. instead of ports.u.c., and are very outdated (trusty)
[16:58] <pitti> well, either it's the cloud images themselves, or the lxc-create ubuntu-cloud template (not sure what creates the apt sources)
[16:58] <pitti> sorry, need to run to Taekwondo now, have a nice evening everyone!
[16:58] <utlemming> pitti: er, they use ports now, not archive. IF not then there is an issue
[16:59] <utlemming> pitti: or an issue with cloud-init
[17:12] <slickymaster> bbl ->
[19:18] <elfy> balloons: ok - how about "Proceed with the test in your native language. Note that the testcase will remain in English and you will need to translate instructions to suit"
[19:19] <balloons> hmm.. a bit wordy.. Perhaps we place in italics?
[19:19] <balloons> wordy as in long, but if we shorten it's likely to be confusing.. it's well said, just the explaination is long :-)
[19:19] <elfy> Proceed in your native language. Instructions will remain in English
[19:19] <elfy> Proceed in your native language if you wish. Instructions will remain in English
[19:21] <elfy> balloons: 2 more to choose from then ^^ :p
[19:21] <balloons> i like the shortest I guess :-)
[19:21] <elfy> :p
[19:21] <elfy> ok - so who to italicise it ?
[19:22] <elfy> how ...
[19:26] <balloons> mm strong bolds it
[19:26] <balloons> I think <i> still works
[19:27] <elfy> ok
[19:28] <elfy> I'll plan to get them done by the time your about tomorrow then

[19:29] <knome> for emphasize
[19:30] <elfy> ta
[19:31] <balloons> ^^ knome's got it
[19:31] <elfy> :)
[19:31] <balloons> I know <b> and <i> are SO old school
[19:31] <balloons> ty much elfy
[19:31] <elfy> you know more than me balloons - it's all voodoo as you are aware :p
[19:32] <knome> well <b> and <i> should still work i guess, but they refer to specific *style* rather than the *purpose*
[19:33] <elfy> woooosh
 and <em> are meaningful for screen-readers too, because they know to read something in a *strong* or *emphasized* way, rather than read something... "bold" or "italic" ?
[19:33] <elfy> stuck in the wall above my head that is :p
[19:33] <knome> hooray for more semantic web!
[19:47] <Letozaf_> balloons, hello
[19:48] <balloons> Letozaf_, hello
[19:49] <Letozaf_> balloons, I've fixed some autopilot calendar app tests that failed for localization problems, but I think I have found a bug on other tests
[19:49] <balloons> Letozaf_, I'm working on calendar still today as well.. What did you find?
[19:49] <balloons> I'm confused why it's failing on dashboard atm
[19:49] <Letozaf_> balloons, for instance if I run calendar_app.tests.test_weekview.TestWeekView.test_current_week_is_selected test
[19:50] <Letozaf_> balloons, it fails because calendar app gets sunday as fist day of weed but in Italy it's supposed to be monday
[19:52] <balloons> Letozaf_, ahh.. ok, that is supposed to be accounted for in the test
[19:52] <balloons> see _get_first_day_of_week
[19:52] <balloons> what day of the week does it say is the first day
[19:52] <Letozaf_> balloons, I get "Locale has Sunday as first day of week"
[19:52] <Letozaf_> balloons, but it should be monday
[19:53] <Letozaf_> balloons, the value of daystart property is wrong
[19:54] <balloons> ahh, well.. weird. Does the calendar show Sunday as first or Monday as first?
[19:54] <elfy> good job I'm not doing that - my week starts on a Thursday :(
[19:54] <Letozaf_> balloons, if I open calendar app with autopilot launch the first day of weed is Monday, but let me try agian just to be sure
[19:55] <Letozaf_> elfy, :D
[19:55] <balloons> elfy, :-P Nice!
[19:55] <balloons> Letozaf_, yes confirm it. It should be reading it correctly from the app. The app itself should be reading the locale
[19:56] <Letozaf_> balloons, that's why I'm a bit confused as the app launched with autopilot launch is right, the first day of week is monday
[19:56] <balloons> ok.. heh.
[19:56] <balloons> that's good, so the app is getting it correct :-)
[19:56] <Letozaf_> balloons, but firstDay = self.week_view.firstDay.datetime is wrong
[19:57] <Letozaf_> balloons, it should be 20 jan instead it's 19
[19:57] <Letozaf_> balloons, so the test fails with MismatchError: 19 != 20
[19:57] <balloons> right.. the dayStart comes from the qml file, have a look
[19:58] <balloons> property var firstDay: dayStart.weekStart(Qt.locale().firstDayOfWeek);
[19:58] <balloons> oops..
[19:58] <balloons> property var dayStart: new Date()
[19:58] <balloons> we need the firstDay property
[19:58] <balloons> ohh, lol.. I thought it was wrong for a second.. looks ojk
[19:59]  * Letozaf_ is looking at qml file
[20:00] <balloons> WeekView.qml
[20:00] <Letozaf_> balloons, yes thanks
[20:00] <balloons> brb
[20:05] <balloons> kk
[20:06] <Letozaf_> balloons, I'm not so good in QML so I'm googling a bit :P
[20:07] <balloons> hehe
[20:07] <balloons> Letozaf_, I don't think the answer is in the qml.. the firstDay is set according to the locale
[20:07] <balloons> we should make sure it's telling us Monday in the test.. if so, then the test isn't working properly
[20:08] <Letozaf_> balloons,  I saw that in the test the value of firstDay is 19 instead of 20, but have to find out why now
[20:09] <balloons> add a couple debug prints, see what values we get from the qml, etc
[20:10] <Letozaf_> balloons, yes I did it but maybe I will try again to see if I can find the reason why the test fails
[20:11] <Letozaf_> balloons, now I'm quite sure I'm doing it right :P
[20:25] <balloons> chihchun_afk, i greet you nonetheless. hola mi amigo
[20:30] <balloons> Letozaf_, so what have you learned?
[20:30] <Letozaf_> balloons, the fistDay property contains 19 jan (I used print to get it's value) : self.week_view.firstDay.datetime it must come from qml -  I am trying to figure out how to transform the value 1390172400 in the property (got this with autopilot vis) in a formatted date
[20:30] <balloons> 1390172400 sounds like a unix timstamp
[20:30] <Letozaf_> balloons, I was googling for that
[20:31] <balloons> Sun, 19 Jan 2014 23:00:00 GMT
[20:31] <Letozaf_> balloons, lol Sun, 19 Jan 2014 23:00:00 GMT was about to write it
[20:32] <balloons> :-) So basically everything looks correct then. The locale is telling us the week starts on Monday, but it doesn't
[20:32] <Letozaf_> balloons, I'm a bit confused as calendar app has the week displayed coreclty
[20:32] <Letozaf_> balloons, it starts on mon and ends on sun
[20:33] <balloons> ok, so let's peer into the qml the
[20:33] <Letozaf_> balloons, but the value of the property is wrong... :?
[20:33] <balloons> Letozaf_, well I mean it's not what we need
[20:33] <balloons> the qml might make further changes to it, so it's starting on Monday like it should
[20:34] <Letozaf_> balloons, oh! yes maybe
[20:34] <balloons> lol.. not that I see
[20:34]  * balloons was grasping at straws
[20:34] <balloons> ^^ there's an odd saying for you
[20:34] <Letozaf_> balloons, :D yes
[20:34] <Letozaf_> balloons, love odd sayings
[20:35] <balloons> I was hoping the qml would have an answer, but it doesn't
[20:35] <balloons> so the locale returns Sunday as the first day, but it shows up properly as monday
[20:35] <Letozaf_> balloons, yes
[20:39] <balloons> I can't figure out why autopilot isn't working for me on my desktop.. ugh
[20:39] <Letozaf_> balloons, weekStart property is not the same as dayStart the first has 1389567600 the latter 1390172400
[20:39] <Letozaf_> balloons, weekStart is in PathViewBase
[20:40] <Letozaf_> balloons, Sun, 12 Jan 2014 23:00:00 GMT  ?
[20:41] <Letozaf_> balloons, another sunday instead of monday
[20:41] <balloons> :-)
[20:45] <balloons> Letozaf_, I'm playing here: lhttps://code.launchpad.net/~nskaggs/ubuntu-calendar-app/debug-ap-tests/+merge/202691
[20:47]  * Letozaf_ is looking at it
[20:50] <Letozaf_> balloons, the other day autopilot also did not work for me... after some updates it started working again :O
[20:51] <balloons> it's only calendar.. I borked something somewhere.. there's a bad import but it doesn't make sense
[20:54] <Letozaf_> balloons, :(
[20:56] <balloons> oO narrowed it down :-
[20:57] <Letozaf_> balloons, I've found something weired too
[20:58] <Letozaf_> balloons, in the TimeLineHeader there's a label LUN (monday) but the date is Sun, 12 Jan 2014 23:00:00 GMT
[20:58] <Letozaf_> balloons, so label and date differ
[21:00] <Letozaf_> balloons, same on the other HeaderDateComponent, label LUN and date Sun, 19 Jan 2014 23:00:00 GMT
[21:02] <balloons> whoa, weird
[21:03] <Letozaf_> balloons, I am quite convinced something's wrong in the qml file, but cannot find where :(
[21:04] <balloons> Letozaf_,  if you believe it to be a bug, then let's file one
[21:04] <Letozaf_> balloons, ok I will
[21:10] <elfy> balloons: if you're using trusty and have a minute to spare on a game - try horizontally resizing sudoku if it's installed
[21:10] <elfy> then try it on a small screen :p
[21:11] <balloons> seems fine
[21:11] <elfy> mmm - might be Xubuntu issue then - can't resize it <--> at all
[21:11] <balloons> ugh.. yea, I can resize everything just fine here
[21:12] <balloons> my trusty is updated to today
[21:12] <elfy> mmm - that was worth mentioning then
[21:12] <elfy> mine too
[21:22] <Letozaf_> balloons, I reported bug 1271726
[21:22] <balloons> Letozaf_, I think I might have an insight into why this is
[21:23] <Letozaf_> balloons, the labels display 20 and MON but the date is Sun 19 Jan
[21:23] <balloons> Letozaf_, they are adding and subtracting days, but you see the datetime has a time value in it
[21:23] <balloons> might be the issue.. I wonder if a screenshot would be helpful?
[21:23] <balloons> it's a bit confusing I'd guess to explain
[21:23] <Letozaf_> balloons, sure I will attach one now
[21:24] <Letozaf_> balloons, yes quite difficult to explain
[21:38] <Letozaf_> balloons, ok added three screenshots hope  the "problem" is clearer now
[21:39] <balloons> Letozaf_, ohh that's perfect
[21:39] <Letozaf_> balloons, :D
[21:39] <balloons> Pretty clear to see the issue from the screenshots
[21:43] <balloons> Letozaf_, very good find. And it's confusing, heh
[21:43] <balloons> might help explain some of these weird errors I'm seeing
[21:43] <Letozaf_> balloons, yes it's confusing
[21:44] <Letozaf_> balloons, hope this helps also for your weired errors :)
[21:44] <balloons> well.. now as to good ole reminders app.. I'm guessing it's about time for you to say ciao
[21:45] <balloons> Letozaf_, here's an example veebers did of mocking: https://code.launchpad.net/~veebers/stock-ticker-mobile-app/mock-server-for-testing/+merge/194971
[21:45] <balloons> I might steal that for trying with reminders
[21:45] <Letozaf_> balloons, cool thanks I will take a look at it
[21:46] <Letozaf_> balloons, yes sounds like it will be useful for reminders-app too
[21:47] <veebers> balloons: that reminds me, have we had any luck communicating with the stock-ticker-app dev?
[21:47] <Letozaf_> balloons, going to bed now :P be back tomorrow
[21:47] <balloons> Letozaf_, buonasera
[21:48] <Letozaf_> balloons, buonanotte :)
[21:48] <balloons> veebers, :-) not since before xmas.. It's not a primary core app, so there's less focus on it
[21:49] <veebers> balloons: ok. It sucks that there is that MR still sitting there for it, but I don't really have time to do anything about it _right_ now. I'll try and chase it up in the near future
[21:49] <balloons> veebers, I'll ping again. Still, the work you've done on it I think will be useful into solving the issues we have with reminders and weather
[21:49] <veebers> balloons: also, hi how are you :-)
[21:49] <veebers> is this regarding a mock server?
[21:49] <balloons> so if you do have time, I'd suggest putting it into mocking the server for weather or reminders :-p
[21:49] <balloons> veebers, yes
[21:50] <balloons> weather is moving to TWC api, and there's a branch with some work done for it
[21:50] <balloons> but in general, we don't have a good solution for mocking yet
[21:50] <balloons> I've been holding your MR as an example to look at when I needed to start
[21:50] <veebers> balloons: right, I took the example of the server mock from another app (can't remember the name right now) but there has been talk about making a generic mockable server that we can re-use
[21:50] <balloons> that day is more or less here
[21:51] <veebers> balloons: ah ok. I'm pretty sure it's something we intend to discuss during the sprint. But that's not today :-)
[21:51] <balloons> veebers, elopio and I ran into the same issue with needing to setup an online account as part of a test
[21:51] <balloons> so it's another piece in the mocking puzzle
[21:52] <balloons> yes, it might take the sprint.. but likely I'll have some examples good or bad before then heh
[21:55] <veebers> balloons: ah, sweet
[22:05] <elopio> veebers, balloons: about sharing a base fake http server, the scope devs told me that the code we would share is so small that it's better to copy it. Most things are specific to the real server we are mocking.
[22:05] <elopio> here's the one I like the most so far:
[22:05] <elopio> http://bazaar.launchpad.net/~ubuntuone-hackers/unity-scope-click/trunk/files/head:/src/tests/autopilot/unityclickscope/
[22:05] <elopio> comes with a nice fixture to start it during set up :D
[22:05] <veebers> elopio: sounds awesome
[22:06] <veebers> perhaps we need to promote it as an example other people can work off
[22:08] <elopio> veebers, balloons: maybe the three of us can come up with a perfect server example, and balloons can blog about it.
[22:09] <elopio> whatever balloons says in his blog is holy word.
[22:09] <balloons> elopio, veebers we also have an app developer week with presentations :-)
[22:09] <balloons> elopio, lol.. yes I need to post about a few of these toys
[22:10] <elopio> balloons: hey, when's the developer week?
[22:11] <elopio> I would like to talk about a domain specific language for user acceptance tests.
[22:11] <balloons> elopio, oO
[22:12] <balloons> zzz.. I JUST now realized the week is the same time as our sprint in oakland
[22:42] <LucaBiolcati> Hello!!
[22:56] <balloons> LucaBiolcati, hello
[22:56] <LucaBiolcati> https://wiki.ubuntu.com/QATeam/WhoWeAre#preview
[22:57] <LucaBiolcati> balloons, where is the error?
[22:58] <balloons> LucaBiolcati, oO.. I'll have a look
[22:59] <balloons> LucaBiolcati, all fixed
[23:00] <balloons> LucaBiolcati, you were missing the last column