[07:35] <dholbach> good morning
[08:04] <fgimenez> good morning
[08:17] <tetor1> good evening (from Tokyo)
[08:23] <mvo> hey good morning fgimenez and tetor1
[08:23] <mvo> tetor1: well, good evening for you of course :) still morning here in europe
[08:23] <fgimenez> hi mvo :)
[08:24] <mvo> I'm looking for ideas how to do git branches similar to bzr pipelines or LPs prerequiste branches model so that I can work on a set of changes but broken into smaller branches
[08:25] <mvo> fgimenez or Chipaca, any ideas?
[08:41] <fgimenez> mvo, afaik you could branch from a base branch, which would be the equivalent of the prerequisirte, but i think that nothing prevents you from merging the dependent branch before its dependency (which would merge the complete diff)
[08:43] <fgimenez> mvo, imo the model is different here, the work should be split in small chunks and rebased frequently to master, or the long lived branch taken as base
[08:44] <Chipaca> mvo: you create a long-lived staging branch, do your work against that, then merge that into trunk? isn't that the git way?
[08:45] <Chipaca> mvo: what fgimenez said
[08:45] <Chipaca> mvo: but i'm not a git expert at all
[08:45] <mvo> Chipaca, fgimenez: thanks, I will try that
[08:47] <zyga> good morinng
[08:57] <clobrano> good morning all
[09:09] <Guest42341> noooooooooooooooooooo!
[09:13] <Chipaca> what on earth is up with that guy
[09:13] <Chipaca> s/guy/person
[09:15] <clobrano> wrong chat, I suppose :D
[09:18] <clobrano> is there any string I can get from shell that differentiate Snappy from other Linux distro?
[09:34] <Chipaca> clobrano: not afaik. I think /etc/ubuntu-build is there on both snappy and click for example
[09:35] <Chipaca> clobrano: wrt wrong chat, no: Guest42341 comes in every day, shouts something, and goes away
[09:36] <clobrano> Chipaca: about Guest42341 I did'n know :D
[09:36] <Chipaca> clobrano: and now that i've said two things with the same length I've got to try to say more
[09:36] <clobrano> Chipaca: ok for the string, I'll ask the user to select the OS ;)
[09:45] <longsleep> Chipaca: Hey, i am still having issues with seccomp and Nginx on snappy. Would you eventually have some time to help me figuring out why exactly i see no audit logs for seccomp and Nginx just works when i add @unrestricted to its profle, but does not with snappy common + networking + network-service?
[09:46] <Chipaca> longsleep: sure, bring it on. At least until somebody more knowledgeable on seccomp/apparmor shows up :)
[09:46] <longsleep> Chipaca: ok awesome - first thing i do not understand is if i should get seccomp reject messages in syslog
[09:46] <longsleep> (or how they would look)
[09:46] <Chipaca> longsleep: if seccomp is what's blocking things, yes you should
[09:47] <longsleep> Chipaca: yeah i thought so too, but i do not have a single seccomp message in my log
[09:47] <Chipaca> longsleep: and sc-logresolve should find those for you
[09:47] <longsleep> Chipaca: yeah - that command shows nothing unfortunatly
[09:48] <Chipaca> longsleep: and no DENIED either?
[09:48] <longsleep> Chipaca: i only see DENIED when running with @unrestricted in the seccomp profile (apparmor DENIED)
[09:49] <longsleep> Chipaca: like this http://paste.ubuntu.com/12988041/
[09:49] <Chipaca> interesting!
[09:49] <longsleep> but this is with @unrestricted - if i run restricted it just crashes when forking without any message to the logs
[09:50] <Chipaca> longsleep: and “sudo snappy service logs” doesn't give you anything either?
[09:50] <longsleep> Chipaca: nothing related to audit
[09:51] <longsleep> Chipaca: i also have a hard time to figure out where it is crashing. The syscalls it is using are all in the seccomp profile.
[09:51] <longsleep> Chipaca: so i am trying to figure out why @unrestricted makes it work
[09:51] <Chipaca> longsleep: have you strace'd it with and without?
[09:52] <Chipaca> longsleep: (the strace needs to go outside of confinement -- if it's a service, in the .service file)
[09:52] <longsleep> Chipaca: How can i strace it when a child process is crashing but the main process works fine?
[09:52] <longsleep> Nginx uses a master process, which works fine, that spawns worker processes - and those crash when
[09:53] <longsleep> started
[09:53] <longsleep> or created - not sure
[09:53] <Chipaca> longsleep: strace -f follows forks
[09:53] <longsleep> ok let me try that
[09:53] <Chipaca> longsleep: strace -ff splits each fork's trace into a different file
[09:53] <Chipaca> longsleep: you'll have to copy strace in
[09:53] <longsleep> Chipaca: that might help in figureing out why it crashes
[09:53] <longsleep> Chipaca: sure - hold on a sec
[09:54] <longsleep> What i still do not get is why i do not get seccomp logs though
[09:54] <Chipaca> longsleep: yeh. You should be seeing logs, so that's a question for jdstrand i think
[09:54] <longsleep> I mean i run kernel 3.10 - maybe i am missing something there but i have checked and did not find anything
[09:57] <Chipaca> oh, that's fairly old isn't it?
[09:57] <Chipaca> $ uname -r
[09:57] <Chipaca> 4.2.0-16-generic
[09:57] <Chipaca> yeesh
[09:58] <longsleep> Chipaca: yeah - ODROID is sadly stuck at 3.10
[09:58] <Chipaca> longsleep: anyway, strace should shed light on it one way or another
[09:58] <longsleep> ok i got strace now
[10:01] <longsleep> Chipaca: ok the crash case seems simple: http://paste.ubuntu.com/12988105/
[10:02] <Chipaca> longsleep: that's seccomp alright
[10:02] <Chipaca> longsleep: you need to know what comes *next* though :)
[10:02] <longsleep> yeah on it
[10:02] <Chipaca> :)
[10:02] <longsleep> setgid32(0)
[10:02] <longsleep> thats next
[10:03] <longsleep> ah i see and that is commented in the profile
[10:03] <longsleep> # snappy doesn't currently support per-app UID/GIDs so don't allow this family
[10:03] <longsleep> # of syscalls. To properly support these, we need to have syscall arg filtering
[10:03] <longsleep> # (LP: #1446748) and per-app UID/GIDs.
[10:04] <longsleep> Chipaca: that was helpful - thanks!
[10:04] <JamesTait> Good morning all; happy Wednesday, and happy International Animation Day! 😃
[10:04] <longsleep> Chipaca: so what do i need to do, to get some seccomp profile which allows this?
[10:05] <Chipaca> longsleep: can't you tell nginx not to switch users?
[10:05] <longsleep> Chipaca: no :/
[10:06] <longsleep> Chipaca: it always switches to whatever configured or nobody when run as root
[10:06] <longsleep> Chipaca: only way it will not switch is when not run as root
[10:06] <Chipaca> longsleep: we need to poke jdstrand then
[10:07] <Chipaca> longsleep: maybe allowing just switching to nobody is possible
[10:08] <longsleep> Chipaca: yeah that would be a good idea probably, but as long as bug #1446748 that might be hard
[10:10] <longsleep> Ah i just found why i missed finding the syscall in the first place
[10:10] <longsleep> Linux 2.4 added setgid32() supporting 32-bit IDs. The glibc setgid() wrapper function transparently deals with the varia‐ tion across kernel versions
[10:10] <longsleep> "transparent wrapper function" ...
[10:11] <Chipaca> glib is full of those
[10:12] <longsleep> Chipaca: so i can fix this by patching Nginx - leaves the issue why i cannot see seccomp denies in the logs
[10:19] <longsleep> Chipaca: another approach would be if snappy would somehow run a service as non root
[10:19] <longsleep> Chipaca: the check in nginx is simple: if (geteuid() == 0) {
[10:32] <Chipaca> mvo: wrt https://travis-ci.org/ubuntu-core/snappy/builds/87841510, comment out or skip the last line in that test
[10:35] <mvo> Chipaca: thanks, I will do that now, I was not sure what its doing
[10:35] <Chipaca> mvo: trying to test that which go deems unknowable
[10:35] <mvo> Chipaca: yeah, I figured it from your conversation from last night :)
[10:42] <Chipaca> mvo: all the branches are blocked by that, so maybe i should make a separate branch just for this
[10:42] <Chipaca> mvo: what say you
[10:42] <mvo> Chipaca: yeah, I was thinking the same
[10:42] <Chipaca> ok, coming up
[10:48] <mvo> Chipaca: how does https://github.com/ubuntu-core/snappy/compare/ubuntu-core:master...mvo5:bugfix/fix-daemon-vet-issue?expand=1 look?
[10:48] <Chipaca> mvo: that's relying on the same undefined behaviour
[10:49] <Chipaca> fighting with git now, it doesn't want to push stuff
[10:49] <Chipaca> but i've got a branch for it
[10:49] <mvo> Chipaca: I have no strong opinion but it seems like we can add a comment and once the undefined behavior actually bites us we remove the test
[10:50] <mvo> Chipaca: it seems right now undefined means "may change in future compiler versions"
[10:51] <mvo> Chipaca: but if removing is the better option, I don't mind
[10:51] <Chipaca> gah
[10:52] <Chipaca> how do i set a branch's "upstream"?
[10:52] <morphis> ogra_, mvo: you know if /etc/network/interfaces.d/eth0 is present in all Ubuntu Core snappy images by default?
[10:52] <mvo> Chipaca: not sure I understand the question? hangout?
[10:53] <mvo> morphis: it wil generated on first boot
[10:53] <ogra_> morphis, it gets created on firstboot by snappy config
[10:53] <morphis> so lets say, when I have a image with the network-manager snap included I just need to change the snappy configuration of the image at build time?
[10:54] <ogra_> if you have an oem snap that defines that the nm-snap gets included you can also set default config options in its yaml file for snappy config
[10:54] <morphis> ok
[10:55] <ogra_> i dont think we have a way to not create the file at all though ( Chipaca would know if thats possible)
[10:58] <Chipaca> other than not having an ethernet device, no there isn't
[10:58] <Chipaca> morphis: what's breaking?
[10:58] <morphis> Chipaca: nothing
[10:59] <ogra_> nobody said anything is broken :)
[10:59] <morphis> Chipaca: however as we have network-manager now we want network-manager to control eth0 rather than ifupdown
[10:59] <morphis> I could just teach networkmanager to still use eth0 even if its configured through eth0
[11:00] <Chipaca> i'd rather we taught snappy a new config option
[11:00] <ogra_> Chipaca, well, nm is in a snap ... you dont want that option in ubuntu-core i guess
[11:01] <ogra_> /etc/NetworkManager/NetworkManager.conf has the "managed=" option for that ...
[11:01] <ogra_> so you want to have a config option in the nm snap that sets it and have your oem snap set this to true
[11:02] <ogra_> (that way an admin/integrator can still disable it and keep the wired config in ubuntu-core if wanted)
[11:04] <morphis> ogra_: I see
[11:05] <ogra_> mvo, so i managed to get the rolling edge images to build again after all of LP was switched to xenial ...
[11:06] <ogra_> mvo, can we go over https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=wily and see what needs to be forward copied for xenial (and what goes to the archive instead)
[11:07] <ogra_> since ubuntu-snappy 1.6 was never uploaded to wily i assume we want to forward port it ? apparmor and ubuntu-core-config seem fine to come from the archive ... i'm not sure about the go* packages in that list
[11:08] <ogra_> s/forward port/forward copy/
[11:09] <ogra_> (btw, 209 is our first xenial image in rolling/edge, if anyone wants to test that)
[11:13] <Chipaca> mvo: https://github.com/ubuntu-core/snappy/pull/21 and thanks again
[11:14] <mvo> Chipaca: could you please remove the "fmt" import in there too and just "git commit --amend" and "git push -f"?
[11:14] <Chipaca> mvo: you mean, actually run tests?
[11:14] <mvo> Chipaca: well, thats not needed :P
[11:14] <mvo> Chipaca: travis is doing that for you and tells you it's failing
[11:14] <Chipaca> sorry, got carried away with this argh-why-is-push-not-working and forgot i was actually in the middle of it
[11:15] <mvo> Chipaca: no problem at all
[11:25] <Chipaca> mvo: https://github.com/ubuntu-core/snappy/pull/21 is green
[11:29] <dholbach> tedg, will snapcraft move to github too?
[11:35] <Chipaca> mvo: any idea why git is angry-red-highlighting the second-plus lines in the pot diff in https://github.com/ubuntu-core/snappy/pull/14/files ?
[12:05] <ogra_> dholbach, ??
[12:05] <dholbach> ogra: mh?
[12:05] <ogra_> (community sync)
[12:05] <ogra_> (another meeting that nicely moved 2h)
[12:06] <dholbach> oops.... sorry
[12:06] <dholbach> I'll be right there
[12:15] <mvo> ogra_: thanks, I think we pretty much want it all in the archive
[12:16] <mvo> Chipaca: I don't know why its angry red, sorry
[12:16] <Chipaca> mvo: and do you know how to ask travis to do its thing again?
[12:17] <Chipaca> there's supposed to be a "rebuild" button, but i can't even find the build tab :)
[12:17] <mvo> Chipaca: I'm dong that now, there is a retry button
[12:18]  * ogra_ notes down "mvo is dong now"
[12:19] <Chipaca> ogra_: "dong that"*
[12:19] <mvo> *cough*
[12:19] <mvo> doing
[12:19] <mvo> DOING
[12:19] <mvo> *sigh*
[12:19] <Chipaca> mvo: too late, your profile has been updated
[12:20]  * ogra_ grins evil 
[12:42] <longsleep> Chipaca: Patch to make Nginx run on snappy: http://paste.ubuntu.com/12989119/
[12:51] <Facu> morning!
[12:51] <Facu> question: how can I know (manually, like browsing a web page) which version of a snap is published? thanks!
[12:55] <Chipaca> Facu: are you the owner of the snap?
[12:56] <Facu> Chipaca, nop
[12:56] <Chipaca> Facu: GET -H "Accept: application/hal+json"  -H 'X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1' -H 'X-Ubuntu-Architecture: armhf' -H 'X-Ubuntu-Release: 15.04-core' -H "X-Ubuntu-Device-Channel: stable" https://search.apps.ubuntu.com/api/v1/package/webdm
[12:56] <Chipaca> Facu: for example
[12:57] <Facu> Chipaca, ah, no web page?
[12:57] <Facu> Chipaca, thanks!
[12:57] <Chipaca> Facu: i'm not sure web pages know about channels yet
[12:57] <ogra_> Facu, https://uappexplorer.com/apps?type=snappy
[12:57] <ogra_> (thats a community page for phone apps, but it also lists snaps)
[12:57] <Chipaca> yeah, was just about to point at https://uappexplorer.com/app/webdm.canonical
[12:58] <Chipaca> Facu: version is in the "info" tab
[12:58] <Chipaca> but, no channels
[12:58] <Facu> awesome!
[13:00] <Facu> Chipaca, ogra_, thank you very much
[13:00] <Chipaca> Facu: that'll be (another) beer
[13:01] <Facu> Chipaca, we don't drink enough beers together :/
[13:01] <Chipaca> Facu: i agree
[13:03] <zyga> sergiusens: hey
[13:17] <sergiusens> zyga, ho
[13:20] <zyga> sergiusens: hey, I have a question
[13:21] <zyga> sergiusens: building a snap I ran across an error I'm not familiar with
[13:21] <zyga> sergiusens: Failed doing pull for foo: [Errno 1] Operation not permitted: '/home/zyga/foo/parts/foo/install/sbin/mount.ntfs'
[13:22] <zyga> sergiusens: does that sound familiar?
[13:22] <zyga> sergiusens: this is snapcraft trunk
[13:23] <tedg> sergiusens: dholbach was asking whether snapcraft will move to github. Thoughts?
[13:36] <sergiusens> tedg, heh; soonish, lets get 0.4 out the door first
[13:36] <sergiusens> zyga, that's from a stage package, right? Are you in a container?
[13:36] <sergiusens> zyga, if you are in a container, check if it is suid; that might be it
[13:41] <zyga> sergiusens: not in a container
[13:41] <zyga> sergiusens: vanilla wily
[13:43] <sergiusens> zyga, what snapcraft are you using and I guess this is from a deb, right?
[13:43] <sergiusens> not all debs just work
[13:44] <sergiusens> zyga, btw, I was pinging you yesterda as guacamole and trusty and maybe first moving our current cli to it and then do the new one
[13:45] <zyga> sergiusens: I'm using snapcraft trunk
[13:45] <zyga> sergiusens: mmm, yeah that's doable
[13:46] <zyga> sergiusens: I'm commited to snappy topics as soon as today ends :)
[13:46] <zyga> sergiusens: as for ntfs, not sure, it's nothing new
[13:46] <zyga> sergiusens: I can run snapcraft again and it "works" but I suspect it just didn't notice the problem and marked the prior stage as done
[13:46] <zyga> sergiusens: stage packages have
[13:46] <zyga>         stage-packages:
[13:46] <zyga>             - libglib2.0-dev
[13:46] <zyga>             - libnl-genl-3-dev
[13:46] <zyga>             - libssl-dev
[13:48] <zyga> sergiusens: I'll try some more, thanks
[13:48] <zyga> sergiusens: a lot of stuff has changed over the past month :)
[13:57] <sergiusens> zyga, yeah, bot not deb handling ;-)
[13:57] <sergiusens> *but
[14:03] <zyga> sergiusens: where did handle source options something go?
[14:03] <zyga> sergiusens: aka def pull()
[14:03] <sergiusens> zyga, into the base plugin
[14:03] <sergiusens> zyga, you complained about it, remember ;-)
[14:04] <sergiusens> zyga, and the implementation is now in sources.py
[14:06] <zyga> sergiusens: yeah, I just realized why it didn't work
[14:06] <zyga> sergiusens: it now relies on schema
[14:06] <zyga> sergiusens: and I had a custom one, no worries now
[14:06] <zyga> sergiusens: thanks!
[14:10] <sergiusens> zyga, right 'snapcraft help plugins --devel'
[14:10] <zyga> oh
[14:10] <zyga> nice
[14:13] <zyga> sergiusens: I have a problem, I need an extra ppa and so I have this hacky patch, http://bazaar.launchpad.net/~zyga/snapcraft/plainbox/revision/256
[14:13] <dholbach> sergiusens, nice work on 'snapcraft help'!
[14:14] <dholbach> I just found a small issue with it: http://pastebin.ubuntu.com/12989697/ - shall I file a bug?
[14:14] <sergiusens> zyga, look at the ros plugin
[14:14] <zyga> sergiusens: this howerver, now (but not before), started to cause issues with apt
[14:14] <zyga> sergiusens: thanks!
[14:14] <sergiusens> zyga, it is undocumented, there's and extra sources attrib
[14:14] <zyga> nice
[14:16] <fgimenez> ogra_, when booting rolling/edge 210: Press Enter for maintenance (or press Control-D to continue):
[14:16] <ogra_> tgm4883, do you see an nls codepage error somewhere in the boot lo ?
[14:16] <ogra_> *log
[14:16] <ogra_> err
[14:16] <ogra_> fgimenez, ^^^
[14:17] <ogra_> we usually et that when it cant mount /boot due to missing vfat  modules
[14:17] <sergiusens> dholbach, yeah
[14:19] <dholbach> thanks sergiusens
[14:19] <dholbach> https://bugs.launchpad.net/snapcraft/+bug/1510954
[14:20] <fgimenez> ogra_, nope http://paste.ubuntu.com/12989745/
[14:22] <ogra_> fgimenez, hmm, it doesnt seem to get to mount /boot at all
[14:26] <ogra_> looks like systemd to me
[14:27] <ogra_> sigh, so i guess i need to try myself to debug this
[14:28] <ogra_> that seems to go deeper
[14:33] <fgimenez> ogra_, booting from a udf generated image it throws me to emergency mode
[14:33] <ogra_> well, the same one as in the paste, right  ?
[14:34] <fgimenez> ogra_, yep, it shows more text anyway, journalctl -xb shows errors about mounting /etc/watchdog.conf, don't know if it might be related
[14:34] <ogra_> are you sure thats 210 ?
[14:35] <ogra_> the watchdog stuff should be fine in that one
[14:36] <fgimenez> ogra_, yep, sudo ubuntu-device-flash core rolling -o kvm-rolling-edge.img --channel edge --developer-mode
[14:36] <ogra_> hmm, k, i'll check that
[14:39] <ogra_> i dont see it starting udev in your paste
[14:45] <fgimenez> ogra_ the paste comes from autopkgtest, don't know if it's complete, for example booting the image with kvm shows the emergency mode welcoming text that is not present in autopkgtest's output
[14:54] <zyga> sergiusens: http://bazaar.launchpad.net/~zyga/snapcraft/plainbox/revision/256
[14:54] <zyga> sergiusens: do you think it would be appropriate to just not inspect symlinks at all?
[15:01] <sergiusens> zyga, we've been asked for the opposite as dangling symlinks in a snap are not allowed
[15:12] <Chipaca> writing 4G at 20MB/s gets old
[15:14] <ogra_> use --faster
[15:19] <Chipaca> i'm getting dropped into emergency thing
[15:19] <Chipaca> on bbb rolling/edge
[15:19] <ogra_> Chipaca, see above
[15:19] <zyga> sergiusens: ah
[15:19] <ogra_> xenial isnt ready yet it seems
[15:19] <Chipaca> ogra_: ouh
[15:20] <ogra_> i'll get to debugging it soon ...
[15:20] <Chipaca> ogra_: do you know offhand what's the latest edge that boots?
[15:20] <ogra_> the last wily image was 208 ...
[15:20] <Chipaca> good enough :)
[15:20] <Chipaca> thanks
[15:20] <ogra_> 209 was completely broken, 210 is the first actual xenial image
[15:22] <Chipaca> ogra_: i got to see "welcome to ubuntu 16.04", so that's nice :)
[15:22] <ogra_> ah, it moves on properly when you hit ctrl-d ?
[15:22] <Chipaca> no, it prints that before emerg mode
[15:22] <ogra_> ah
[15:23] <Chipaca> in other news, if you don't plug in the sd card, dd is super fast! 843MB/s!!
[15:23] <ogra_> lol
[15:23] <ogra_> and you get a new device node in /dev for free as well !
[15:24] <sergiusens> dholbach, https://code.launchpad.net/~sergiusens/snapcraft/1510954/+merge/276013
[15:25] <ogra_> ogra@styx:~/Devel/images$ sudo ubuntu-device-flash core --channel edge -o xenial-rolling.img ----developer-mode rolling
[15:25] <ogra_> Determining oem configuration
[15:25] <ogra_> generic-amd64 failed to install: snappy package not found
[15:25] <ogra_> hmpf
[15:25] <ogra_> oh
[15:26] <ogra_> perhaps i tried to hard to use developer mode :P
[15:26] <sergiusens> ogra_, how many - do you need? don't waste them
[15:26] <dholbach> https://code.launchpad.net/~dholbach/snapcraft/integrate-snappy-tutorials-build-snaps/+merge/276012
[15:27] <elopio> ogra_: rolling edge #210 amd64 doesn't boot
[15:27] <ogra_> elopio, yes
[15:27] <ogra_> see above
[15:27] <ogra_> i'm u-d-f'ing ...
[15:27] <ogra_> to debug
[15:28] <elopio> sorry, I'm late :)
[15:28] <ogra_> :)
[15:28] <zyga> sergiusens: I think that's a valid thing to do, maybe the exception could be something that we have in the image already
[15:29] <zyga> sergiusens: I don't even know why ntfs is pulled in, I worry that if we are too strict about it, we'll break a random snap out there that doesn't rely on the symlink, just on some package that pulls it in
[15:29] <sergiusens> zyga, right, the problem is 'being in the image already' can only be guaranteed for libc6 and that is the only thing we leave dangling today
[15:30] <sergiusens> zyga, right; ubuntu debs in stage packages are going to need a lot of refinements as we go
[15:30] <jdstrand> seb128: hey, do you have an ubuntu-personal system available? if so, can you paste the output of 'snappy list' on that system?
[15:31] <seb128> jdstrand, hey, no sorry, the image have been discontinued before wily
[15:31] <Chipaca> ogra_: 208 also lands me in emergency mode
[15:31] <ogra_> Chipaca, uuuh, any error ?
[15:31] <sergiusens> or Chipaca a quick one https://code.launchpad.net/~sergiusens/snapcraft/1510954/+merge/276013
[15:31] <jdstrand> seb128: as in, ubuntu-personal images are no longer being generated or you just happen to not have one?
[15:31] <seb128> jdstrand, they are not longer generated
[15:31] <jdstrand> I see
[15:32] <jdstrand> thanks
[15:32] <seb128> yw
[15:32] <Chipaca> ogra_: some not relevant i think ,but:
[15:32] <Chipaca> ogra_: etc-watchdog.conf.mount: Mount on symlink /etc/watchdog.conf not allowed.
[15:33] <ogra_> Chipaca, yeah, thats known
[15:33] <Chipaca> ogra_: that's about it
[15:34] <ogra_> the fix went in but there were no wily images anymore
[15:34] <ogra_> not sure that can block the boot
[15:34] <Chipaca> will try going back one further
[15:34] <Chipaca> see what happens
[15:35] <longsleep> are there any known issues in u-d-f on trusty? I just got a report that it does not work and fails with error while executing external command kpartx -ds spreedbox-15.04-stable-dev.img: device-mapper: remove ioctl on loop0p4 failed: Device or resource busy
[15:35] <longsleep> loop deleted : /dev/loop0
[15:35] <longsleep> anyone seen this before?
[15:35] <longsleep> (it works the very first time after boot)
[15:36] <Chipaca> longsleep: that's an error that comes up often with u-d-f, that we don't have a good way to fix
[15:36] <Chipaca> longsleep: at least we haven't found it yet
[15:36] <Chipaca> longsleep: but you can clean up and try again
[15:36] <longsleep> Chipaca: oh - it never happend for me
[15:36] <zyga> sergiusens: I agree with both
[15:37] <longsleep> Chipaca: how to clean up? losetup -d and kpartx -d did not help
[15:37] <Chipaca> 1 sec
[15:37] <Chipaca> longsleep: sudo dmsetup clear loop0p4 && sudo losetup -d /dev/loop0 && sudo kpartx -ds /dev/loop0
[15:38] <longsleep> Chipaca: cool
[15:38] <Chipaca> longsleep: after that "sudo losetup -l" should be empty
[15:38] <longsleep> Chipaca: He will try it in a moment
[15:38] <sergiusens> Chipaca, the root cause is generally a failure to unmount do to a missing .Close()
[15:39] <Chipaca> sergiusens: shaaaaame
[15:40] <Chipaca> ogra_: just in case, am i missing anything? ubuntu-device-flash --revision 207 core rolling --oem=beagleblack --channel edge -o bbb_rolling_edge.img --developer-mode
[15:40] <longsleep> Chipaca: i can confirm that your commands do the trick and resolve the issue - thanks. Though for him it is always required.
[15:40] <sergiusens> Chipaca, right; the snappy tests need to check for left over FDs if easy to do :-)
[15:41] <ogra_> Chipaca, should work, yes
[15:41] <Chipaca> longsleep: it *never* succeeds for him?
[15:42] <longsleep> Chipaca: it never seems to clean up after it ran before, though u-d-f does not finish because it does not find a snap defined in the oem yaml
[15:42] <longsleep> Chipaca: maybe that is related and it does not properly cleanup in this case
[15:43] <ogra_> ok, i found the issue ...
[15:43] <Chipaca> ogra_: \o/ ?
[15:43] <ogra_> seems ubuntu-core-config is broken in xenial
[15:43] <Chipaca> ogra_: /o\
[15:43] <ogra_> i'm sure i dropped watchdog.conf and /etc/default/watchdog before from it
[15:43] <ogra_> but they are in writable-paths so systemd tries to double mount
[15:44] <ogra_> yup, removing them both makes it boot fine
[15:47] <ogra_> ok, fix uploaded
[15:47] <ogra_> next image should boot
[15:51] <elopio> zyga: your landing bot might be a little too verbose :)
[15:53] <Chipaca> ogra_: 207 *also* lands me in emergency mode
[15:53] <Chipaca> ogra_: wat
[15:53] <zyga> elopio: https://bugs.launchpad.net/launchpad/+bug/1510993
[15:54] <zyga> elopio: perhaps that's the reason
[15:54] <ogra_> Chipaca, sure, the fix landed in wily when the buildds were already switched to xenial i fear you have to go far further back to have a booting image
[15:54] <ogra_> like ... before watchdoog was added
[15:55]  * Chipaca goes back to 200
[15:56] <Chipaca> as per bug 1503329 187 booted, so that's the farthest back i'll have to go
[15:56] <elopio> zyga: I mean that the two messages after the +1 seem unnecessary. The approval generally says thanks. And launchpad will send a message when the merge is done.
[15:57] <zyga> elopio: ah, I see
[15:57] <zyga> elopio: yeah, you are right
[15:57] <zyga> elopio: I can remove that
[15:57] <zyga> elopio: btw, what are you using it for?
[15:57] <elopio> zyga: tarmac by default just talks if something goes wrong.
[15:58] <elopio> zyga: I'm not using anything in there. Somebody subscribed me to those branches, so I woke up to tons of your bot messages.
[15:58] <elopio> well, not tons.
[15:58] <elopio> many.
[16:11] <Chipaca> ogra_: could you kick off an image build, at least for armhf?
[16:13] <Chipaca> bootcharts on the bbb or wiiiiiiiiiide :)
[16:22] <Chipaca> ogra_: with modprobe + modules in oem, we can make the bbb bring up the option module with the right bits!
[16:32] <ogra_> Chipaca, i'll kick an image as soon as https://launchpad.net/ubuntu/+source/ubuntu-core-config/0.6.31 is ready
[16:32] <ogra_> proposed migration is sloow atm
[16:32] <Chipaca> :) ok
[16:33] <Chipaca> ogra_: anyway, i'm not blocked by that
[16:33] <Chipaca> have plenty to figure out here :)
[16:35] <ogra_> Chipaca, remount / rw ... remove all lines mentioning watchdog from /etc/system-image/writable-paths and be fine ...
[16:35] <ogra_> (from the emergency shell)
[16:36] <ogra_> next boot will just work
[16:38] <Chipaca> i'll try that
[16:38] <snappy_> which version of snappy do i need for service logs to work?
[16:38] <Chipaca> system-ifup.service is not present in 208, which is strange
[16:40] <ogra_> Chipaca, does that come from snappy ?
[16:40] <ogra_> (the ubuntu-snappy package )
[16:40] <Chipaca> snappy_: 5
[16:40] <Chipaca> ogra_: not afaik
[16:40] <ogra_> hmm
[16:40] <Chipaca> ogra_: i mean 200, not 208, there
[16:41] <Chipaca> ogra_: am updating to 208 now
[16:41] <ogra_> ah
[16:41] <Chipaca> ogra_: probably part of the systemd changes
[16:41] <Chipaca> ogra_: but if so, possibly bad news for this fix on stable
[16:41] <Chipaca> we'll see
[16:42] <ogra_> yep
[16:47]  * ogra_ twiddles thumbs ... 
[16:47] <ogra_> come on publisher
[16:48] <ogra_> sergiusens, why did you unmilestone all the milestone 0.4 bugs ?
[16:49] <ogra_> are they getting dropped ?
[16:49] <sergiusens> ogra_, only 2 or three; they won't make it in today
[16:49] <ogra_> ah, k
[16:49] <snappy_> Chipaca: I have Snappy 15.04 edge... but sudo service log returns "log: unauthorized service"
[16:49] <longsleep> snappy builds seems to generate invalid package.yaml for oem packages if the oem package contains a preinstalled section. It replaces preinstalled with builtin and adds 4 bogus extra bytes at the end.
[16:50] <ogra_> snappy_, it is "sudo snappy service log <service name>"
[16:50] <Chipaca> snappy_: i'm going to need you to copy-paste that into a pastebin please
[16:50] <Chipaca> ogra_: urm, no :)
[16:50] <ogra_> no ?
[16:51] <Chipaca> ogra_: sudo snappy service logs [ package [ service ]]
[16:51] <snappy_> Chipaca: ubuntu-core version is 229
[16:51] <ogra_> ah logs, not log
[16:51] <ogra_> "sudo snappy service logs webdm" works here
[16:51] <Chipaca> ogra_: yep. webdm is the package :)
[16:51] <ogra_> :)
[16:52] <Chipaca> snappy_: pastebin, please
[16:55] <snappy_> Chipaca: I cant copy and paste text
[16:56] <Chipaca> snappy_: why?
[16:56] <snappy_> Chipaca: I can post an image
[16:56] <snappy_> oh nvm
[16:56] <Chipaca> image works, but is often more work, and if you're not able to ssh in you're going to have a hard time :)
[16:58] <snappy_> Chipaca: pastebin.com/NLrbkWXN
[16:58] <Chipaca> snappy_: unrecognised, not unauthorized
[16:58] <ogra_> snappy_, it is "sudo snappy service ..."
[16:59] <Chipaca> and what ogra_  said
[16:59] <ogra_> you are missing a snappy in your command ...
[16:59] <snappy_> oic
[16:59] <ogra_> service is a snappy command, not a standalone thing ...
[16:59] <snappy_> thx
[17:05] <longsleep> Added bug #1511050 - someone should look at this asap as it currently seems to be impossible to build a oem snap with preinstalled snaps.
[17:08] <Chipaca> pitti: are you around?
[17:10] <ogra_> Chipaca, images for armhf and amd64 building (FYI)
[17:12] <Chipaca> ogra_: ta
[17:12] <Chipaca> i'm wondering where system-ifup.slice went :-(
[17:14] <ogra_> where on disk should that be ?
[17:14] <ogra_> /etc/systemd ?
[17:14] <Chipaca> ogra_: no, it's magic afaict :)
[17:14] <ogra_> ah
[17:15] <Chipaca> ogra_: hence me bleating for pitti
[17:15] <ogra_> yeah
[17:19] <Chipaca> elopio: about quoting in python
[17:19] <Chipaca> elopio: consistency is good, but not at the expense of legibility
[17:20] <elopio> Chipaca: I agree. Where are we losing legibility?
[17:20] <Chipaca> elopio: if you want to create a string that has single quotes in it
[17:20] <Chipaca> elopio: you should use double quotes for the string
[17:20] <Chipaca> elopio: not escape all the single quotes
[17:21] <Chipaca> I mean, sure, having in a same line three strings with different quotes *for no good reason* is bad
[17:22] <elopio> yes, that's what I try to do and I've seen sergiusens doing that.
[17:22] <Chipaca> but  foo("'hello'", '"yes"', '''"what's this?''') is better than the mishmash of backslashes
[17:22] <Chipaca> (a contrived example, but i'm right now reviewing code that suffers from a lesser case of this problem)
[17:23] <sergiusens> Chipaca, I've fixed that fwiw
[17:24] <Chipaca> sergiusens: cool
[17:24] <sergiusens> Chipaca, also, we don't have consolidation in the messages/strings wrt use of ' or ".
[17:24] <sergiusens> I was consolidating with "
[17:25] <Chipaca> ¯\_(ツ)_/¯
[17:48]  * ogra_ u-d-f's 211 ...
[17:56]  * ogra_ curses
[17:57] <ogra_> seems rmadison lied to me
[17:57] <ogra_> so 212 it will be then
[17:57]  * ogra_ triggers a new build
[17:58] <elopio> ogra_: this issue is similar to the one last week? No way to test it without generating the image?
[17:58] <ogra_> elopio, it is the watchdog files
[17:59] <ogra_> elopio, i fixed it for wily but before there was an image built with my fix the image builders were switched to default to xenial
[17:59] <ogra_> and since then we had no images at all
[17:59] <ogra_> now i uploaded the same fix to xenial ...
[18:00] <elopio> I got it until this point ^.
[18:00] <ogra_> but rmadison lied to me and told me the package was promoted to the archive while it wasnt yet ... so i need another rebuild
[18:01] <ogra_> the 212 rolling image that is just building will boot fine i guess
[18:01] <ogra_> (now the fix is in the archive)
[18:03] <balloons> elopio, are you still a-ok with having that snappy testing session? If so, I'll schedule it for you now
[18:04] <elopio> balloons: like automation or manual testing?
[18:08] <elopio> balloons: ah, just go for it, we'll talk about both automated and manual tests. Please make it early in the morning so Federico can join us. I will try to convince him to take care of the automated part :)
[18:12] <tedg> elopio: sergiusens: So this is getting insane. What do I do to reduce the length of a URL that is longer than 79 characters?
[18:13] <tedg> I already deduplicated one string using format to remove common occurances of "certificate" but this one has too much unique data.
[18:13] <elopio> tedg: you can url = ("...."
[18:13] <elopio> "...."
[18:13] <elopio> "....")
[18:14] <tedg> Uhg, okay.
[18:14] <elopio> the strings in each line will contact. Split the URL whererver it makes sense, like after /
[18:14] <ogra_> intuitive :P
[18:14] <elopio> *concat
[18:15] <elopio> ogra_: well, you can put + between the lines too to make it more explicit. I find it nice, but I'm biased :)
[18:16] <ogra_> i'm a shell addict ... i'd prefer backslashes :)
[18:16] <tedg> If only we could have a computer program that could wrap long lines on its own. We could call it a "text editor". Ah, to dream of the future.
[18:16] <ogra_> tedg, hmm
[18:16] <ogra_> not a bad idea though
[18:16] <ogra_> we should write one ...
[18:16] <ogra_> ... and call it vimacs !
[18:17] <tedg> Multiple modes that require for control key combinations to switch between. It'd be intuitive!
[18:17] <elopio> ogra_: I think this works too: url = "..." \
[18:17] <elopio> "..." \
[18:17] <elopio> "..."
[18:17] <ogra_> oh, neat
[18:17] <elopio> you see? there's python for everybody!
[18:17] <tedg> Yeah, actually I've found you can get around the checks on which things can break lines by using \
[18:17] <ogra_> python.sh !
[18:18] <tedg> The linter seems to not catch things in that case.
[18:18] <elopio> tedg: yes, but pythonistas don't like \ that much.
[18:18] <tedg> It's okay. I don't like them either :-P
[18:18] <elopio> I must admit that I'm enjoying the golang long lines.
[18:18] <elopio> but don't tell anybody.
[18:19] <balloons> elopio, will do. I will put in on the schedule, but we can easily drop it if it doesn't work out. Thanks for being willing to try.
[18:19] <ogra_> until you have to edit them via a serial terminal for the first time :P
[18:19] <elopio> balloons: I have lots of things to talk about, most of them in progress so even better to find people who want to help. It will work.
[18:25] <tedg> elopio: Welcome to the dark side, we have cookies!
[18:38] <balloons> hey tedg btw.. I would be remiss if I didn't offer you a lovely trip to some warmer weather in a month. Orlando is lovely that time of year, and mhall119 will be there. What more could you ask for?
[18:39] <balloons> tedg, I'm obviously talking about fossetcon. Mike was looking for someone who could speak about snappy and show off snapcraft. is it an option for you?
[18:39] <balloons> so you know, elopio volunteered you :-)
[18:40] <tedg> balloons: Uhm, could be. Depends if elopio will turn off the DEP8 tests :-)
[18:40] <balloons> nicely done!
[18:40] <tedg> balloons: Link?
[18:40] <balloons> http://fossetcon.org/. It's November 19-21
[18:40] <balloons> ubucon would just be the 19th
[18:44] <tedg> Generally yes, I think I could probably do that.
[18:44] <tedg> Have to redo my snapcraft talk anyway, kinda failed at TXLF
[18:46] <ogra_> the snappy/snapcraft talk at ubucon.de was actually crowded
[18:47] <Guest42341> how do i end up on this channel???
[18:47] <tedg> ogra_: I tried for a demo in mine, and someone broke the docker snap an hour before...
[18:47] <ogra_> yeah
[18:48] <ogra_> i remember
[18:48] <tedg> Live demos are always a bad idea... I need to learn that for reals sometime.
[18:49] <balloons> ahh yes. So much can go wrong when you try things live
[18:51] <elopio> tedg: hey, I didn't turn the dep8 tests on!
[18:52] <elopio> I was happy and surprised when other people started adding the checks :)
[19:17] <ogra_> the latest rolling/edge image should now work
[19:18] <elopio> ogra_: 212 boots, but the ens3 interface is down.
[19:18] <ogra_> well
[19:18] <elopio> ogra_: the config test passes.
[19:19] <ogra_> i see ens3 in my kvm here
[19:21] <ogra_> anyway, thats for tomorrow ...
[19:21] <ogra_> mail sent and i'm EOD ....
[19:22] <elopio> ogra_: good night. And thanks.
[20:32] <sergiusens> tedg, any luck with the plugin or those bug fixes?
[20:33] <tedg> sergiusens: Plugin almost done. Talking with "upstream" now.
[20:34] <tedg> I've got some complexity to fix though :-(
[20:46] <tedg> Haha, oops. I made it more complex.
[20:57] <sergiusens> tedg, don't hang yourself :-P
[21:07] <tedg> Oh, you got rid of all the booleans!
[21:07] <tedg> Nice, need to update.
[21:15] <sergiusens> tedg, oh, the if self.run and blah blah. Of course, now we type less :-)
[21:16] <tedg> Well, it reduces the complexity as well.
[21:26] <sergiusens> tedg, right, but man, that change landed ages ago ;-)
[21:29] <pitti> Chipaca: what is system-ifup.slice? you mean ifup@.service?
[21:43] <snappy_> hi
[22:02] <snappy_> Chipaca: u online?
[22:15] <Chipaca> snappy_: no
[22:16] <Chipaca> pitti: I don't know what it is, exactly! was hoping you'd tell me :)
[22:16] <Chipaca> snappy_: what's up?
[22:23] <Chipaca> pitti: it shows up in an amd64 kvm, but not in a bbb, fwiw
[22:24] <snappy_> hi
[22:24] <Chipaca> snappy_: how's things?
[22:25] <snappy_> Chipaca: good thx
[22:25] <snappy_> Chipaca: getting a failed to connect to Mir on ubuntu 15.04 edge.
[22:25] <Chipaca> snappy_: core?
[22:25] <snappy_> Chipaca: when trying to run freerdp snap
[22:25] <snappy_> Chipaca: snappy ubuntu core*
[22:25] <snappy_> Chipaca: edge
[22:26] <Chipaca> snappy_: ok, questions for you
[22:26] <Chipaca> snappy_: is mir starting successfully? that is: do you get a black screen with a pointer?
[22:26] <snappy_> Chipaca: no.  doesnt run
[22:26] <snappy_> Chipaca: on edge
[22:27] <Chipaca> snappy_: right. The only way I got it to work was by running it under virt-manager, and making sure the display was "spice"
[22:28] <snappy_> oic
[22:28] <snappy_> hmm
[22:28] <snappy_> thx ill try that
[22:34] <Chipaca> pitti: and ifup@.service doesn't "run"; i can't after: or before: it
[23:30] <sergiusens> elopio, are you testing/exploring on trusty, vivid or wily?
[23:30] <elopio> sergiusens: vivid and wily.
[23:31] <sergiusens> elopio, have you built the ros example?
[23:31] <elopio> sergiusens: I left it running, let me check...
[23:31] <elopio> Failed doing build for tomcat: Error -3 while decompressing data: invalid block type
[23:31] <elopio> let me re-run it to confirm.
[23:31] <sergiusens> elopio, hm that might be networking playing tricks
[23:32] <sergiusens> elopio, what about ros?
[23:32] <sergiusens> elopio, I ask about ros because I want to know where the 'listener' and 'talker' end up in that build
[23:33] <elopio> sergiusens: ros succeeded, that was executed just before that tomcat error.
[23:33] <sergiusens> elopio, do you have the snap to test the 'binaries' or access to the ./snap dir?
[23:33] <sergiusens> does snap/opt/ros/indigo/beginner_tutorials/lib/beginner_tutorials/listener exist?
[23:34] <elopio> sergiusens: running again because I don't know where plainbox leaves the files.
[23:34] <sergiusens> elopio, oh, plainbox just wipes them :-P
[23:37] <elopio> sergiusens: listener exists in that path.
[23:37] <elopio> also talker
[23:38] <sergiusens> elopio, https://code.launchpad.net/~sergiusens/snapcraft/path_ros/+merge/276070
[23:40] <elopio> sergiusens: +1
[23:46] <elopio> sergiusens: should we retry when the downloads fail?
[23:46] <sergiusens> elopio, maybe, but did it fail or was it incorrect?
[23:47] <elopio> I retried and it worked. My network is sucking even more this days.
[23:48] <elopio> sergiusens: on the run I had running on the other machine I got:
[23:48] <elopio> Failed doing pull for local: [Errno 1] Operation not permitted: '/home/elopio/.cache/plainbox/sessions/pbox-_anzho6q.session/CHECKBOX_DATA/parts/local/install/sbin/mount.ntfs'
[23:49] <sergiusens> elopio, for which example?
[23:49] <elopio> sergiusens: trying to figure that out to retry. the wall of text in the test doesn't make it easy.
[23:50] <sergiusens> elopio, yeah, I agree; I wanted those examples to be individual tests not one big blob :-)
[23:51] <elopio> with testools and subunit details.
[23:52] <elopio> it's the one after gopaste, and mentions ant, so I'm guessing java-hello-world. Retrying...
[23:53] <sergiusens> elopio, strange that built fine for me
[23:53] <sergiusens> inside an lxd container even
[23:55] <elopio> sergiusens: built alright in the wily machine. This is vivid. Pull only downloads things, right? It's a weird error.
[23:55] <sergiusens> elopio, it also does the ubuntu unpack magic
[23:56] <sergiusens> elopio, I bet vivid is the one in the container?
[23:56] <sergiusens> elopio, or chroot or clean environment
[23:57] <elopio> sergiusens: no containers here. vivid is the laptop, wily is the desktop