=== fginther` is now known as fginther
=== vicamo_ is now known as vicamo
=== bpierre_ is now known as bpierre
dholbachgood morning07:50
mvo_hey dholbach, gooooood monring08:03
dholbachhey hey :)08:03
fgimenezgood morning08:14
zygahey :)08:14
mvo_hey fgimenez, good morning08:15
mvo_and hey zyga08:15
mvo_fgimenez: any luck with my integration test :) ?08:15
fgimenezhi mvo_ :) the job didn't get triggered, i'll try to dig into it right now08:16
mvo_fgimenez: ok, let me know if I can help in any way, happy to re-trigger it08:18
fgimenezmvo_, great thanks, i'll reconfigure it to listen to the repo on which i've been doing the development, where things work well, and try to figure out what are the differences, i've just checked the logs from the last payloads received from github and all seems to be ok08:20
fgimenezmvo_, the jobs are properly triggered from https://github.com/fgimenez/snappy-github-plugin, both on pull request and comments on them, see
fgimenezmvo_, the first error in the log is because there's no bot user configured (the status in the PR won't be updated), but the job is triggered properly08:32
fgimenezmvo_, it's the same jenkins instance that failed with ubuntu-core/snappy, just modified the job to point to fgimenez/snappy-github-plugin, maybe some config is different in the github side08:33
fgimenezmvo_, this is how the webhook config looks like in the test repo http://postimg.org/image/486b11ewj/08:43
mvo_fgimenez: aha, mine was set to json instead of urlencoded08:44
mvofgimenez: I changed to urlencoded and triggered the event again, anything interessting in the logs?08:46
fgimenezmvo_, mmm nope still http://paste.ubuntu.com/13310045/08:47
fgimenezmvo if you are redelivery maybe the payload is the same as before, i think that the urlencoded is the correct format, we can wait for a new PR08:49
fgimenezmvo, btw, the jenkins instance project is at https://github.com/ubuntu-core/snappy-jenkins, the readme has info about how it is configured08:52
mvofgimenez: ok, I pushed a new branch08:53
mvofgimenez: anything in the logs or same message?08:55
fgimenezmvo, still the same... what are the headers of the last event?08:55
fgimenezmvo, when it works they look like http://paste.ubuntu.com/13310136/08:56
mvofgimenez: its funny, the heade says content-type: application/x-www-form-urlencoded08:56
mvofgimenez: but the payload looks like its still json for some reason08:56
mvo2015-11-17 09:53:2608:56
mvo looks valid08:56
mvofgimenez: hm, recreated it, still no luck. I get a 200 response though09:01
fgimenezmvo, yes, with urlencoded content-type the payload can have any string, json also, it's like if you paste that json in a textarea and submit the form, if the server is aware of it then it can be decoded09:01
fgimenezmvo, ok, i'll try to reproduce it with the test repo, first i'll get the full logs from jenkins to see whats really going on09:02
fgimenezmvo, could you please paste the header and payload of the latest event? i've seen here https://github.com/janinko/ghprb/blob/master/src/main/java/org/jenkinsci/plugins/ghprb/GhprbRootAction.java#L137 that the message from jenkins comes from an unrecognized event09:11
mvofgimenez: I send you a /msg with the details09:13
arazyga, I like very much how you are explaining every step of the way to implement capabilities in the mailing list09:22
ara*kudos*, even09:22
zygaara: hey09:22
zygaara: :D09:22
zygaara: thank you, :-)09:22
mvofgimenez: thanks so much for your help, now that I configured it right it works like a charm09:24
fgimenezmvo, np :) thank you09:25
JamesTaitGood morning all; happy Tuesday, and happy Home-Made Bread Day! 😃10:08
mvofgimenez: how long do the tests usually run?10:13
mvofgimenez: the github-snappy-integration-tests-cloud jobs I mean10:14
fgimenezmvo, yes, it depends on the cloud load and the network response for updates, an usual run can take about 25min, sometimes longer (up to 1h) or shorter (16 min or so)10:15
mvofgimenez: thanks10:16
soffoklHey, I trying to disable snappy-autopilot.timer, but after reboot it active again. Is there any way to disable it permanently?10:16
soffokl(amd64)ubuntu@localhost:~$ sudo systemctl disable snappy-autopilot.timer10:16
soffoklRemoved symlink /etc/systemd/system/multi-user.target.wants/snappy-autopilot.timer.10:16
soffokl(amd64)ubuntu@localhost:~$ sudo reboot10:16
soffokl$ ssh
soffokl(amd64)ubuntu@localhost:~$ sudo systemctl list-timers snappy-autopilot.timer10:16
soffoklNEXT                         LEFT       LAST PASSED UNIT                   ACTIVATES10:16
soffoklTue 2015-11-17 11:00:00 UTC  50min left n/a  n/a    snappy-autopilot.timer snappy-autopilot.service10:16
fgimenezmvo, there are a couple of things we can do in the test runner to make it quicker, we can save about 3min for every run in the initial steps, i'll try to prepare a branch shortly10:18
fgimenezmvo, and we can of course run the suite in parallel, this could give us great time savings10:18
=== chihchun_afk is now known as chihchun
mvofgimenez: yay, test finished, one error that may well be a real issue! is there a way for me to see what base image version was used for the test? I wonder if it has the latest apparmor10:32
fgimenezmvo, sure, at the beginning of the log, look for "Launching instance for Snappy image ubuntu-core/custom/..." the version number is right before "-disk1.img"10:34
mvofgimenez: thanks again10:34
fgimenezmvo, np, btw the tests are running now against the latest available rolling/edge amd64 image, with elopio's work we can trigger them to against bbb in spi, and we could define other jobs for executing in amd64 15.04, for example10:37
fgimenezmvo, when we will have the snappy-cloud-image in place we will be able to upload new images to the cloud as soon as they are published in system-image, now this process is still manual, let me know if you need a more recent rolling/edge image10:38
longsleepsergiusens: Hey, i think i just found a bug in u-d-f, it seams that it applies tarballs from the system-image server in random order / tarballs are extracted into basemount in the order that they finished downloading11:55
Chipacasergiusens: ^?12:16
sergiusenslongsleep, hmm, you may be right; I'd need to look12:16
* sergiusens was having breakfast12:16
* Chipaca approves12:16
longsleepsergiusens: i can add a bug with pointers to the code if you like12:17
sergiusenslongsleep, that would be good, thanks12:17
longsleepsergiusens: done, see bug 151700912:24
ubottubug 1517009 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash applies system image tarballs in random order" [Undecided,New] https://launchpad.net/bugs/151700912:24
=== nessita_ is now known as nessita
mvoelopio: when you have a chance, could you update the ubuntu-core xenial base image for the docker integration tests13:07
=== barry` is now known as barry
elopiomvo: I can, but I'm not sure I'm understanding what you want.14:17
mvoelopio: sorry, I probably did not express myself well. so … I enabled the webhook to trigger the integration tests on each pull request, fgimenez hold my hand for that :) now I'm very exicted that they run. my understanding is that the base image used needs manual updates(?) and we need the latest xenial image with the latest apparmor for one of the branches14:19
mvoelopio: the feature/native-security-policy-regen branch14:19
mvoelopio: does that make more sense now?14:19
elopiomvo: more or less :) they always run against the latest daily rolling edge, atm #235. So there's nothing to update to.14:20
mvoelopio: oh, I have 247 here right now?14:21
elopiomvo: do you mean that you need something that will be in the daily not yet generated?14:21
elopiomvo: ah, #235 is the bbb I'm testing now.14:22
mvoelopio: aha, ok. if its always using the latest image I need to ponder why the one test is failing. I was assuming apparmor on the image is out-of-date, it needs the version from ~2-3 days ago14:22
elopiomvo: do you have a link to the results?14:23
fgimenezmvo, elopio i think that the latest image uploaded is 229, we still are not able to upload automatically the latest ones, elopio, you can upload it with snappy-cloud-image, having the canonistack instances for the shared user loaded14:25
elopiofgimenez: ahh.14:26
fgimenezelopio, i can do it this time and document it somewhere (the snappy-cloud-image readme sounds like a good place :), it will be soon automated14:26
elopioyes, please.14:26
elopiosorry mvo for confusing it more.14:27
sergiusenslool, do you have a minute to discuss plugins, build `drivers` and build tools?14:28
loolsergiusens: I'm in hangouts for next 90 mn, but then free14:29
mvoelopio, fgimenez: no worries and thanks for your hard work on this, its a wonderful feature and its great to see it progressing so nicely14:29
sergiusenslool, great, its about the divide between openjdk, oracle jdk, former bea jdk, ibm's jdk with the combination of make, ant, maven, etc14:35
fgimenezmvo, elopio ok, 247 is ready, the tests will use it from now on14:45
fgimenezelopio, with snappy-cloud-image installed from ppa:fgimenez/snappy-cloud-image, just executing snappy-cloud-image -release rolling -channel edge (with the shared user credentials loaded) is enough14:47
fgimenezelopio, it's takes less time to upload the image if you execute that from a cloud instance14:48
mvofgimenez: \o/ I triggered a re-test14:52
mvofgimenez: this is real magic, I'm really exicted14:53
fgimenezmvo, great! :)14:54
zygatedg: thank you for the questions15:28
mvojust fyi (jdstrand will also send a mail about it). the native-security-policygen-regen branch landed that means we no longer use aa-clickhook to generate the security profiles. this *might* introduce bugs but its a really nice cleanup step16:19
elopioplars: the bbb tests stopped working without any changes to the scripts. Could it be timing out?16:26
plarselopio: when did they last work?16:27
elopioplars: tuesday.16:27
elopiothen I fixed some bugs on the tests, and no results_payload anymore.16:27
plarselopio: did you get any output from them? I don't see a whole except that it successfully booted into the test image, ran some tests, and got a 255 rc16:28
plarselopio: ah, hang on, maybe more to it... let me dig a little16:28
elopiowhat's a 255 rc?16:28
elopiono output received. results_payload empty.16:29
plarselopio: it looks like it couldn't connect to the test image after all16:34
plarselopio: the bbb seems fine, the default image running on emmc works16:34
elopioplars: should I do something in my script to notice this?16:35
plarselopio: I'm not sure that you can - I think it should fail before it even gets to your script. Is it possible the image is just busted? Have you tried this locally on a bbb?16:38
elopioplars: yes, daily.16:38
elopioit works.16:38
plarselopio: you say it last worked on tuesday, the 10th?16:41
elopioplars: yes.16:41
lentzi90Is there some simple way of getting the IP addres of a beaglebone running snappy ubuntu? I can't find my micro HDMI adapter... and I can't access the router to check it that way.16:44
beunolentzi90, it might be on the network as webdm.local16:44
beunotry pinging that16:44
lentzi90ok thanks!16:45
jdstrand_kyrofa: fyi, see mov's comment on the security regen branch landing16:46
kyrofamvo excellent news! Thanks for the heads up jdstrand_16:47
=== chihchun is now known as chihchun_afk
plarselopio: so a couple of things...16:59
plarselopio: 1. I'm trying a test job on both bbb's we have, to see if one of them is bad or something16:59
plarselopio: 2. the way I'm trying to detect whether we're in the emmc image, or the test image that we just flashed, or if we didn't manage to get to any image at all isn't great.  Pretty much anything I can do to detect if it's in the snappy image we flashed is bound to be fragile, and what that means for right now, on bbb, we are not properly detecting that it17:01
plarscan't reach the bbb after flashing17:01
plarselopio: what *should* happen is that the provisioning step should fail, and it wouldn't even try to run your test, so there would definitely be no test results in that case, but I think SPI would mark the test failed17:02
plarselopio: I'll get a fix in for the case where it doesn't detect boot failure to the test image properly, but I'm more concerned with why it's not seeing the test image. I'll let you know what I find out17:06
elopioplars: thank you.17:06
plarselopio: I need to look at the x86 hosts also, I couldn't get any of them working last I tried, and I'm concerned that maybe some change to the image broke them. Any thoughts on that? I heard there were going to be some changes but haven't had a chance to check them out yet17:08
elopioplars: no. I'm basically ignoring the x86 hosts because we can't reboot them.17:08
elopiothat's the useful part of this suite.17:08
plarselopio: yeah, I have a story in our backlog to explore other options for automating x86... I think we may have to break down and just netboot them17:10
plarselopio: I was hoping to use some feature of grub that supposedly lets you read a file over http, and use that to give a hint which mode to boot into, but I can't seem to get networking up on grub unless I pxeboot the system17:11
plarselopio: so it may make more sense to just have it netboot an initrd image, and do everything from there. I think ogra_ was working on something like that for rpi2, and perhaps it would make sense to just do the same for x8617:12
mvoelopio: I triggered a new xenial image with the new security policy generation code, if you want to play around a bit later and poke at it17:12
plarselopio: hmm, the first bbb has booted and seems to be running my test. I can connect to it and snappy seems to be running, so I think it *can* work17:13
elopioplars: I'll launch a new one.17:13
plarselopio: what are the options you are passing to udf on it?17:13
elopiomvo: great, thank you!17:13
mvoelopio, fgimenez: there is also a new initramfs-tools-ubuntu-core with all-snap support it should be fully backward compatible but if you see boot issues in the tests alter me please17:13
elopioplars: core rolling --channel edge --oem beagleblack --developer-mode17:14
plarselopio: both of mine ran just fine17:15
elopiomvo: is it good enough to check for boot problems with systemctl --failed --all }17:15
plarselopio: that's the same as mine, just in a different order17:18
fgimenezmvo, elopio is it included in the latest image?17:20
elopioplars: same thing, no payload
plarselopio: ok, so it looks like the flash went just fine, and I can even reach the image. If you are sure about that image id though, there should definitely be something there18:07
plarselopio: the test failed, but spi should still fill in something18:07
plarselopio: that id looks completely empty to me - as if it doesn't even exist18:08
plarselopio: is that what you're seeing?18:08
plarselopio: give me a bit to grab some lunch and I'll take a closer look18:08
elopioplars: do you mean "87fd5a8b-c9be-4a92-86ac-c3b6f0496f8d" ?18:09
plarselopio: yes18:09
* elopio afk too.18:09
mvoelopio: I think nothing should break18:09
elopioplars: no, for that id I see 'test_status': 'FAILED', but 'result_payload': {}18:10
plarselopio: weird, I see nothing, but maybe that's because of my credentials?18:11
plarselopio: well, the reason you see nothing in the payload then would be because your script didn't put anything there18:11
elopioplars: can be. Take a look at that jenkins output, it pings until the results appear, after like 44 minutes.18:11
plarsthe failed status would probably come from spi itself18:11
plarsI'll try to reproduce the steps by hand and see if I can spot something18:12
elopioplars: right, what I'm wondering is why it was putting stuff last tuesday, but then after no changes it's now empty. My first suspicion was a timeout.18:12
plarslet me grab food first though18:12
plarselopio: ok, I found the problem18:48
plarsresults=cat: restuls/output/artifacts/results.subunit: No such file or directory18:48
plarselopio: also, would you mind cleaning up the tmpdirs you create? since they are not in the SPI generated path, they won't get automatically cleaned up18:49
plarselopio: an easy way you can do it (which would also facilitate easier debugging) is to do a static path, and just rm it before starting18:49
plarselopio: ex: rm -rf /tmp/elopio && mkdir /tmp/elopio18:49
elopioplars: I do this: results=$(cat restuls/output/artifacts/results.subunit 2>&1)19:16
elopioso if the file doesn't exist, it will assign the error to results.19:16
elopioit should end in the json anyway.19:17
elopioI added a trap and corrected the typo. Lets see what happens now.19:20
plarselopio: hmm, I think you'll hit problems when writing the json, because ${results} doesn't have anything19:21
plarselopio: anyway, I spotted another problem, you're json is missing a comma, so I think it's going to choke on that also19:21
plarselopio: on the summary line19:21
elopiogagh, I hate json.19:23
elopiocomma added.19:23
elopioI have no idea how it worked on tuesday then. must have changed it by mistake.19:23
elopioplars: so, for dumb people like me, the output of this script is vital19:24
elopioI can't trust myself to write a script that collect all its own errors.19:25
plarselopio: there was no output from your script that helped me either, I only got that far by running it by hand and adding set -x19:25
elopioplars: that's the output I want, the one from -x.19:26
plarselopio: I am capturing what the script exposes as best I can in logstash, but that's not always reliable, and spi doesn't seem to gather anything on its own19:26
elopioI removed it because I could not access it.19:26
plarselopio: sadly, that system where I run logstash/kibana is not something you can get to through the vpn right now, I've already got a ticket in with IS to resolve that, so we'll see how it goes.19:28
plarselopio: if they can get us hooked up to do that, then I'll be able to get you pretty easy access to the logs coming out of it, but it wouldn't have been helpful here I think19:29
elopioplars: that would be nice so I stop bothering you.19:30
=== chihchun_afk is now known as chihchun
ksuttleHey there. Where can I report bugs for apt-get?19:54
ksuttlehttps://bugs.launchpad.net/ubuntu ?19:57
geniiksuttle: ubuntu-bug apt20:03
=== chihchun is now known as chihchun_afk
jdstrand_niemeyer1: hey, you still around?20:40
=== jdstrand_ is now known as jdstrand
jdstrandniemeyer1: wondering if you could fast track https://github.com/ubuntu-core/snappy/pull/11220:41
jdstrandniemeyer1: it is just a doc change. I was writing the announcement of the policy generation branch and noticed that the docs weren't quite right20:42
niemeyer1jdstrand: Will check it out20:42
plarsHas there been any change to how you write an image to the hard disk if you want to boot from there? (x86)21:53
plarsI used to be able to dd it, but that doesn't seem to work now21:53
plarselopio: do you know? ^21:53
elopioplars: not that I know.22:39

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!