[00:02] <mup> PR snapd#1952 closed: configstate,hookstate: add snapctl set <Critical> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1952>
[00:07] <mup> PR snapd#1983 opened: ctlcmd: add snapctl get <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1983>
[02:04] <mup> Bug #1564076 changed: Can't launch snaps <gnome-software> <sdoc> <verification-done> <gnome-software (Ubuntu):Fix Committed by robert-ancell> <snapd (Ubuntu):Fix Released> <gnome-software (Ubuntu Xenial):New> <snapd (Ubuntu Xenial):Fix Released> <gnome-software (Ubuntu Yakkety):Fix Committed by
[02:04] <mup> robert-ancell> <snapd (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1564076>
[02:53] <mwhudson> er do tests pass with tip for people right now?
[02:55] <mwhudson> go test github.com/snapcore/snapd/interfaces/builtin fails for me
[03:15] <mup> PR snapd#1984 opened: daemon: add logging to help diagnose create-user slowness <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1984>
[05:10] <Mirv> thanks mhall119 jdstrand nessita! that's what I thought, but it'd be nice to get an up-to-date playground example then like I doubt geany/geany-plugins is working at the moment. I guess that the plug and slot need to be named identically instead of specifying the content field.
[06:09] <mup> PR snapd#1985 opened: progress: use New64 and fix output newline <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1985>
[06:18] <mup> PR snapd#1973 closed: tests: ensure HOME is also set correctly <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1973>
[06:19] <mup> PR snapd#1986 opened: tests: ensure HOME is also set correctly <Created by mvo5> <https://github.com/snapcore/snapd/pull/1986>
[06:39] <dholbach> hey hey
[06:54] <didrocks> good morning dholbach
[06:54] <dholbach> salut didrocks
[07:01] <zyga> o/
[08:18]  * ogra_ -> dentist
[08:44] <mup> PR snapd#1986 closed: tests: ensure HOME is also set correctly <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1986>
[09:15] <mup> PR snapd#1984 closed: daemon: add logging to help diagnose create-user slowness <Created by mwhudson> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1984>
[09:16] <Chipaca> mwhudson, o/
[09:25] <mup> Bug #1626930 opened: Missing mount-observe slot in Core <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1626930>
[09:28] <mup> Bug #1626930 changed: Missing mount-observe slot in Core <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1626930>
[10:18] <oparoz> Hello guys. Is it or is it not possible to override seccomp by whitelisting syscalls? The documentation and tests in the snapcraft repo seem all wrong
[10:30] <oparoz> Was looking in the repo of the fork... So it seems everything is gone. Too bad
[10:49] <jacekn> hello. Im building snap and snapcraft prints warning: "grade" property not specified: defaulting to "stable". Where can I find documentation for this option? There is nothing here: http://snapcraft.io/docs/build-snaps/syntax
[10:51] <mup> PR snapd#1987 opened: daemon,overlord/assertstate: support streams of assertions with snap ack <Created by pedronis> <https://github.com/snapcore/snapd/pull/1987>
[10:57] <ogra_> mvo, bah, crap, did you note what keyboard-configuration all pulled in alongside ? (initscripts, debconf, lsb-base ... ) we really need to cut that down again
[11:05] <morphis_> pitti: can you have a look at https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 ?
[11:15] <pitti> morphis_: replied
[11:16] <morphis_> pitti: the service name is sadly nothing I can influence
[11:16] <morphis_> that is what snapd builds for it
[11:16] <morphis_> also to avoid intersections with other snaps
[11:16] <pitti> morphis_: right, hence adding Alias=
[11:16] <morphis_> pitti: sure but that is still something snapd need to get from somewhere
[11:17] <pitti> WDYM "get"?
[11:17] <morphis_> pitti: snapd creates the service unit on the fly
[11:17] <pitti> you just put it in the unit, and when it gets enabled, systemctl creates the alias symlink
[11:17] <morphis_> we don't ship it as part of the snap so we can't modify it
[11:17] <pitti> err
[11:18] <morphis_> so we would have to add another key in meta/snap.yaml which then gets parsed by snapd and added in the .service unit
[11:18] <pitti> if we are going to snap up core plumbing parts like NM, bluez, cups or whatnot, I suppose that's necessary indeed
[11:18] <morphis_> pitti: something to argue with niemeyer about
[11:18] <pitti> cluttering a lot of packages with snapd service aliases is a really bad design
[11:18] <morphis_> pitti: I am currently just searching for a way to replace networkd in our images with network-manager which comes from the snap
[11:47] <mup> Bug #1626986 opened: snapd should allows snaps to define systemd unit Alias names <Snappy:New> <https://launchpad.net/bugs/1626986>
[12:00] <jdstrand> jacekn: I guess the documentation is out of date. grade can be one of stable or devel. aiui, if you set it to 'devel' it ensures it won't accidentally end up in the stable channel
[12:01] <jacekn> jdstrand: and can stable end up in devel?
[12:01] <jdstrand> jacekn: I think so
[12:02] <jdstrand> sergiusens: can you comment? ^
[12:05] <jacekn> jdstrand: sergiusens: I have some opinions here. For snapscraft.yaml building external code I have to maintain multiple branches with different "version" and "source-tag". This new options means yet another line that needs to be different between those branches
[12:06] <jacekn> jdstrand: sergiusens: so really IMO warning is an overkill, I'd prefer not to have that option at all
[12:06] <jdstrand> jacekn (cc sergiusens): we didn't design the feature. perhaps that would be a good question for the mailing list?
[12:07] <jacekn> jdstrand: ack and good point!
[12:07] <jdstrand> that way you'll get definitive answers on how things work and why
[12:07] <jdstrand> and I know they are always looking for real world feedback
[12:09] <qengho> lpotter: Your Pi (2? 3?) didn't display HDMI at boot? My pi3 did not either. I worry OG's "hdmi_safe" proposal isn't fixing the right thing. Want to help debug it?
[12:12] <ogra_> qengho, you mean you dont see anything after the first boot (i.e. after 5min) apart from the raspberries even with hdmi:safe set ?
[12:12] <ogra_> *hdmi_safe
[12:13] <ogra_> qengho, also, which image do you use and how big is your SD ... (the daily image is a lot smaller and will talke longer to resize on a big SD)
[12:17] <qengho> ogra_: correct, nothing displayed after 5 or 45, though I'm about to test scientifically and give you real data by end of day. I used the "release" images on a 32GB, fast microSD.
[12:17] <ogra_> well, that should resize in 2-3min max
[12:17] <ogra_> (likely faster)
[12:18] <ogra_> i really cant reproduce it here ... i always get the "please press enter" under the raspberries
[12:18] <qengho> ogra_: And I will want your help. I think the cmdline can have any number of console= lines. You could have serial AND tty0. I think.
[12:18] <qengho> But I can't test the serial one.
[12:18] <ogra_> no, then you dont get the actual boot data on serial
[12:19] <ogra_> the first console= arg is used for early boot ... the second one is switched to after the kernel ... i.e. initrd and following
[12:20] <ogra_> might be first and last (instead of first and second) if you have more than two ...
[12:21] <ogra_> during development it is essential that users can give us the full boot log when something hangs ... i'm happy to change defaults for final release but not while we require debug data
[12:24] <qengho> ogra_: In any case, perhaps that configuration tool can display on /dev/ttySwhatever AND /dev/tty0 .
[12:24] <ogra_> it does !
[12:24] <qengho> Oh. Hrm.
[12:24] <qengho> Then something is wrong.
[12:24] <ogra_> here at least ...
[12:24] <mup> PR snapd#1974 closed: snapd: kmod backend <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/1974>
[12:25] <qengho> ogra_: Okay, I'll test and let you know.
[12:25] <ogra_> systemd always starts one agetty on each console by default ... console-conf intercepts agetty and displays the "please press enter" message one them
[12:26] <ogra_> *on
[12:26] <ogra_> qengho, i also dont undersatnd why people want to use HDMI at all. given we do not allow any login except ssh anymore
[12:27] <ogra_> so defaulting to HDMI doesnt really make much sense
[12:28] <qengho> ogra_: You connect another computer and *its* display to the computer, instead of just a display? That's dumb. That's why.
[12:28] <ogra_> (having avahi and a network based conole-conf by default would make massively more sense)
[12:28] <qengho> Yes, so much. I need some zeroconf.
[12:29] <ogra_> well ... except that the image will then explode in size ... we're already way to big for embedded
[12:30] <qengho> ogra_: OTOH, if you have an old DEC VT220 you're plugging in directly, then I apologize.
[12:30] <ogra_> i just use the serial cable that was shipped with the board when i bought the "embedded developer" set
[12:30] <ogra_> :P
[12:32] <qengho> You sound scornful of it like you're saying "micro-" computer, and wisful of the days when a REAL computer took up several cubic meters. Computers get smaller. This is normal now. This is a real computer.
[12:32] <ogra_> qengho, you dont really expect people to attach a monitor to their NAS, AP, router, IoT controller, do you ?
[12:33] <ogra_> i'm not saying computer at all
[12:33] <qengho> ogra_: When it comes with a video card and more than one USB port, I think you have to stop pretending it's only a lawnmower device.
[12:33] <ogra_> we are targeting IoT here ... at most you will run a single purpose kiosk app in such a device
[12:34] <ogra_> when you use HDMI at all
[12:34] <ogra_> qengho, it isnt a desktop ... you wont actually use it as one ... beyond probably showing off to people that you can use it as such
[12:35] <ogra_> i definitely dont know anyone who actually uses a pi as their default desktop system, sorry
[12:36] <ogra_> i agree it makes sense to have HDMI for something like a kido system or any other single purpose kiosk setup thhough, no doubt here
[12:36] <ogra_> *kodi
[12:37] <ogra_> but after all our current target is IoT and embedded ... once we have a desktop session snap you will run on such a device you will also have a grephical firstboot tool to set it up ... and that wont run on the console at all
[12:38] <morphis_> ogra_: ping
[12:38] <ogra_> no need to ping me if i talked a line above ;)
[12:38] <ogra_> just ask :)
[12:39] <morphis_> ogra_: but you have the choice to pong when you're free :-)
[12:39]  * ogra_ pongs 
[12:39] <ogra_> heh
[12:39] <morphis_> hehe
[12:39] <qengho> ogra_: there are many many millions of RPis sold, and very few are that "embedded kit" version. Throw away your serial cable and become one of the 99.99% of owners for a few days.
[12:39] <morphis_> ogra_: we put upgrade for netplan currently in the ppa to include them in the next core snap, right?
[12:40] <tachyons_> https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/indicators.py#L33 , This approach of finding content length using content length header is making probelm when using http compression
[12:40] <tachyons_> Eg github gist
[12:40] <tachyons_> Lazy to file a bug in launchpad :D
[12:40] <ogra_> qengho, yeah, its a sad fact that people picked a dead wood settopbox chip for that hype instead of something proper ...
[12:41] <ogra_> morphis_, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[12:41] <ogra_> needs to end up there
[12:42] <ogra_> morphis_, at least until pitti lands everything that netplan needs in xenial-updates proper :)
[12:43] <ogra_> (which i hope is the case for GA, we need to be able to build stable without the PPA)
[12:43] <pitti> ogra_: when is GA?
[12:43] <ogra_> pitti, uh, not sure ... several weeks ... jamiebennett knows exact dates
[12:43] <pitti> ogra_: I didn't yet backport it as we don't use netplan extensively yet, and thus it's still in the "find/add missing features" phase
[12:44] <tachyons_> sergiusens:  cc
[12:44] <pitti> ogra_: but we could certainly start to SRU the NetworkManager patches at least
[12:44] <jamiebennett> pitti: GA = 2016-11-03
[12:44] <pitti> thanks
[12:44] <ogra_> now thats exact :)
[12:44] <pitti> morning or afternoon? ☺
[12:44] <ogra_> *g*
[12:44] <jamiebennett> 23:59
[12:45] <jamiebennett> we need all the time we can ;)
[12:45] <pitti> PST
[12:46] <morphis_> ogra_: ok
[12:47] <morphis_> pitti: ok, once I give you the go for that patch we talked about can to bring the new netplan package into the snappy-dev ppa?
[12:47] <pitti> morphis_: it's your PPA, go wild :)
[12:47] <morphis_> pitti: not really mine :-)
[12:48] <pitti> it's not a long-term solution, but good enough for a beta/demo for sure
[12:48] <morphis_> pitti: its for sure not a demo, it goes into production
[12:51] <morphis_> pitti: but we can figure out a better solution and migrate to that at a later point
[12:51] <pitti> *nod*
[12:51] <pitti> and the PPA seems fine for those
[12:53] <pitti> morphis_: maybe the snap yaml doesn't even need to be explicit about these aliases -- I mean, you slurp in packages (or upstream builds) that already *have* the systemd and dbus .service files, so it could just scan those and automatically provide aliases (if explicit declarations are unwanted)
[12:54] <pstolowski> jdstrand, hey, thanks for the review of timedate control interface!
[12:55] <morphis_> pitti: yeah another option, something we need to discuss with niemeyer
[12:55] <ogra_> pitti, that would get tricky ... i have a bunch of snaps that use daemons, none of them can actually use their default init scripts or systemd units ... usually you need to re-define config paths and the like
[12:56] <pitti> but in general, I don't understand why you wouldn't just take upstream .service files as they are, and instead rewrite them
[12:56] <ogra_> so i doubt we could make that a generic thing
[12:56] <zyga> jdstrand: hey
[12:56] <pitti> well, then at least provide them under their original name
[12:56] <ogra_> because i need a wrapper that creates an initial config, in a non standard place for example
[12:56] <morphis_> ogra_: it would be just an alias we need to add to the files you say we're NetworkManager.service too
[12:56] <pitti> they aren't co-installable with the corresponding debs anyway
[12:57] <ogra_> pitti, hahaha ...
[12:57] <ogra_> (we have nothing that prevents this)
[12:57] <pitti> but it would just mean that dependencies, resource limitations, privilege reductions, aliases, etc. need to be duplicated in the yaml
[12:57] <mup> PR snapd#1988 opened: Allow system bus access for screen-inhibit-control <Created by afrantzis> <https://github.com/snapcore/snapd/pull/1988>
[12:58] <pitti> but anyway, that's a SEP :)
[13:05] <jdstrand> zyga: hey-- so, how does leaving in hello-world cause ubuntu-core to get unmounted (ns discard latest commit). Or did I misread your comment?
[13:05] <jdstrand> pstolowski: you're welcome :)
[13:06] <zyga> jdstrand: it's not
[13:06] <zyga> jdstrand: I just started realizing what is the problem
[13:06] <zyga> jdstrand: I'm going to just get an ack from chipaca and release stuff
[13:06] <jdstrand> zyga: heh, ok, cause I was starting to get worried :)
[13:06] <zyga> jdstrand: it seems snapd is doing something crazy wrt cleanup now
[13:06] <zyga> jdstrand: ubuntu-core is unmounted mid tests when some cleanup task fires
[13:07] <jdstrand> zyga: ack. that is worrisome for other reasons, but glad that the ns discard wasn't causing it :)
[13:07] <zyga> jdstrand: I need a few more changes in snapd (to redesign the branch a little, move the task to other manager) and I got +1 to merge it
[13:07] <jdstrand> great :)
[13:09] <sergiusens> tachyons_ we have a bug for that
[13:10] <sergiusens> jdstrand I just answered an askubuntu question about grade around 30' ago
[13:11] <jdstrand> zyga: I see you merged that-- should you uncomment the hello-world bit too?
[13:11] <jdstrand> sergiusens: cool
[13:11] <zyga> jdstrand: I evicted that commit
[13:11]  * sergiusens goes back to writing unit tests
[13:11] <zyga> jdstrand: it's not commented out anymore
[13:12]  * sergiusens looks at joc_ and wonders how he got away with it ;-)
[13:12] <jdstrand> zyga: ok cool. I didn't see that commit, only the one saying you were merging. thanks
[13:14] <zyga> jdstrand: I rebased that commit away (the one that was commenting those bits out)
[13:27] <mup> PR snapd#1987 closed: daemon,overlord/assertstate: support streams of assertions with snap ack <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1987>
[13:35] <tachyons_> sergiusens:  link ?
[13:38] <sergiusens> tachyons_ https://bugs.launchpad.net/snapcraft/+milestone/2.19
[13:38] <om26er> Hello! Whats the update on diff based snap updates ?
[13:45] <mup> PR snapd#1989 opened: tests: build once and install test snap from cache <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1989>
[14:07] <om26er> Whats the password for all-snap image ? After I added my launchpad email, I am not able to login.
[14:07] <sergiusens> SamYaple hey, I tried to this http://paste.ubuntu.com/23220251/ on an unpatched snapcraft and was able to do this http://paste.ubuntu.com/23220246/ (I am not sure how to expose the current .pth bug)
[14:07] <sergiusens> om26er only ssh
[14:07] <sergiusens> ssh in and set a passwd if you must
[14:08] <ogra_> "sudo passwd $USER" after you sshed in ...
[14:08] <sergiusens> ogra_ obviously :-P
[14:08] <om26er> sergiusens, hmm, I think I can't remember my IP
[14:09] <sergiusens> om26er cannot help you there
[14:09] <ogra_> sergiusens, well, yu could just try "passwd" which wont work ...
[14:09] <om26er> IP for the virt manager machine
[14:09] <sergiusens> nmap might
[14:09] <ogra_> so not *that* obvious
[14:09] <sergiusens> ogra_ because current passwd is unset/unkown
[14:09] <ogra_> yeah
[14:09] <sergiusens> and sudo does the trick
[14:09] <ogra_> right
[14:12] <om26er> ogra_, sergiusens I am in. Had to re create the VM to know my IP :)
[14:29] <zyga> jdstrand: there's a chance that the test failures we saw are caused by https://github.com/snapcore/snap-confine/blob/master/spread-tests/regression/lp-1599608/task.yaml
[14:30] <zyga> exactly how I cannot explain yet
[14:47] <morphis_> ogra_, pitti: so who should upload https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 as a patch to netplan to the snappy ppa?
[14:52] <ogra_> mvo, slangasek, hmm, the small image size made resize2fs take significantly longer :/
[14:52] <ogra_> i wonder why ...
[14:53] <ogra_> (the 128GB card i currently use used to resize in 1-2 min before ... now its 10min and counting with a daily image)
[14:58] <mup> PR snapcraft#823 closed: plainbox-provider plugin: rewrite python shebangs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/823>
[15:01]  * ogra_ goes and tries the beta image instead 
[15:01] <SamYaple> sergiusens: http://paste.ubuntu.com/23220481/
[15:03] <sergiusens> SamYaple ah, so it is python2 that has the issue, got it
[15:03] <ogra_> bah
[15:03] <ogra_> resizes instantly
[15:03] <ogra_> that wasnt even 20sec
[15:05] <ogra_> i guesss that means that creating images at minimal size complicates resizing
[15:05] <ogra_> :(
[15:06] <SamYaple> sergiusens: for dogpile.cache, yes python2 is the issue
[15:06] <slangasek> ogra_: er... impressive?
[15:06] <SamYaple> sergiusens: but its on a per project bases. this same thing can happen on python3
[15:06] <ogra_> slangasek, why ?
[15:06] <SamYaple> *basis
[15:07] <slangasek> ogra_: 10 minutes to resize?  It shouldn't matter that it's on 128GB.  But I'm assuming you don't want us to revert the change to make the image small ;)
[15:07] <ogra_> slangasek, i assume with the minimal size the blocksize is not exactly a multiple of 512 or some such
[15:07] <ogra_> slangasek, well, i gave up after 15min ... not sure how long it would actualyl have taken
[15:07] <ogra_> but using the 3.8GB big beta image resizes absolutely instantly
[15:08] <ogra_> slangasek, oooh, and since i'm testing on the dragonboard ... i'm now glaring since 2min at "Contacting server..."
[15:08] <ogra_> o this slowness seem to not be arch specific at all
[15:08] <ogra_> *so
[15:08] <ogra_> *eems
[15:08] <ogra_> bah !
[15:10] <ogra_> (right after i typed that the screen changed, but even on the dragonboard it is slow at the user setup tep)
[15:11] <ogra_> hmm, but why is the resize so slow, there are no errors in the resize log
[15:11] <ogra_> (apart ffrom the one when i ripped out the card it seems resize2fs was chugging along happily)
[15:19] <mup> PR snapcraft#822 closed: Don't filter .pth files in python plugin <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/822>
[15:20]  * ogra_ rolls an image with extra added empty space 
[15:25] <elopio> cwayne: you did atom, right? Can you help me with an electron snap?
[15:29] <cwayne> elopio: yep, sure
[15:29] <elopio> cwayne: I'm getting Error: spawn electron ENOENT
[15:30] <elopio> have you seen that? I'm trying adding electron to node-packages, but I have no idea what I'm doing.
[15:30] <cwayne> elopio: hm, not seen that, i had to usee a custom plugin to just call scripts that atom had, so there wasnt really much dealing with electron itself
[15:31] <elopio> the docs don't help much, but I clearly have nothing called electron in my prime directory. Let's see how it goes.
[15:31] <ogra_> slangasek, i must admit in the light of resize times that go into the 20min area (even with an image i made look like one of the former ones) i'm tending to say we should perhaps build them in 1GB size steps instead of "as small as possible" ... this is definitely not suitable
[15:32] <oparoz> Can the snap web install beta apps?
[15:32] <oparoz> ...which are using devmode
[15:33] <ogra_> mvo, where is the ubuntu-image patch you used to create the 3.8GB betas (you obviously didnt use the latest from trunk but also not the default 4GB one)
[15:34] <ogra_> (and i cant see any change related to this in your github tree either)
[15:34] <slangasek> ogra_: or, if you think this is part of it, we can tune our mkfs.ext4 options to adjust block size / cluster size / bytes per inode / inode size
[15:35] <slangasek> ogra_: maybe you want to experiment with those and see which flags might make a difference to the speed?
[15:36] <mvo> ogra_: its not pushed, but its just 4Gb->3.9Gb, i can push the diff if you need it
[15:36] <ogra_> slangasek, well, something makes the old images do instant resize ... and even the ones that mvo built as betas which dont use your latest change
[15:37] <ogra_> mvo, that would be great ... i want the dailies to not take hours while people like qengho wait for something on HDMI ;)
[15:37] <ogra_> i guess *that* is the actual problem
[15:37] <ogra_> (regarding the console= discussion)
[15:37] <slangasek> ogra_: yes, so since you have a case where you can reproduce slow resize (is this on the BBB?), can you tweak the ext4 filesystem when you build it and see what does or doesn't improve the speed?
[15:38] <ogra_> slangasek, thats the dragonboard ... but i bet we'll have iot on all images
[15:38] <slangasek> ogra_: I don't have a 128GB SD card to reproduce this with
[15:38] <ogra_> (i test the bbb with a 4GB card ... the resize is neglectable there)
[15:38] <ogra_> slangasek, well, a 256GB one will do as well :P
[15:38] <slangasek> ogra_: also, 'tune2fs -l' output on the filesystem after the resize is done, please
[15:39] <ogra_> ok, will do
[15:53] <mup> PR snapd#1990 opened: many: allow use of the system user assertion with create-user <Created by mvo5> <https://github.com/snapcore/snapd/pull/1990>
[15:56] <abeato> ogra_, why might I see this error when doing "snap prepare-image"? :
[15:56] <abeato> error: cannot fetch and check prerequisites for the model assertion: assertion not found
[15:57] <ogra_> how does your assertion look like ?
[15:57] <abeato> ogra_, http://paste.ubuntu.com/23220732/
[15:58] <ogra_> hmm, looks fine
[15:58] <ogra_> and you specified the path to it correctly in the ubuntu-image command line ?
[15:59] <abeato> ogra_, yes, this it the command that fails:
[15:59] <abeato> $ sudo snap prepare-image --channel=beta --extra-snaps=network-manager_1.2.2-5_armhf.snap --extra-snaps=modem-manager pi3.model /tmp/tmpqfqroa0f/unpack
[15:59] <abeato> pi3.model is in the folder
[16:00] <ogra_> what is /tmp/tmpqfqroa0f/unpack supposed to be
[16:00] <abeato> ogra_, the actual command that is executed is:
[16:00]  * ogra_ has actually never used snap prepare-image directly ... 
[16:00] <abeato> $ sudo /snap/bin/ubuntu-image --channel beta --extra-snaps network-manager_1.2.2-5_armhf.snap --extra-snaps modem-manager -o pi3.img pi3.model
[16:01] <abeato> ogra_, but in the end what fails is the prepare-image step
[16:01] <ogra_> hmm
[16:02] <ogra_> does it work if you call it completely without --extra-snaps ?
[16:02] <abeato> no, not in that case either
[16:03] <ogra_> did you try with edge yet instead of beta ?
[16:03]  * ogra_ wonders if self signed assertions somehow block building from non-edge
[16:03] <abeato> ogra_, let me try
[16:06] <elopio> alright, now I don't get any errors. But also I don't get any window :(
[16:06] <elopio> any electron expert around?
[16:07] <abeato> ogra_, I have
[16:07] <sergiusens> elopio check if one of the threads is crashing (font-config for example), glib/gtk makes many assumtions and doens't fail cleanly
[16:07] <abeato> ubuntu-core          16.04.1    423  canonical  -
[16:07] <abeato> doing
[16:07] <abeato> $ sudo snap install --channel=edge ubuntu-core
[16:07] <abeato> error: cannot install "ubuntu-core": snap "ubuntu-core" already installed
[16:08] <abeato> is that fine?
[16:08] <ogra_> abeato, i thik 423 is the last stable
[16:08] <elopio> sergiusens: ok, how do I check that?
[16:08] <elopio> I have nothing about fonts or gtk, but I can copy them from atom
[16:09] <abeato> ogra_, how do I install a new one? "sudo snap install --channel=edge ubuntu-core"does not work
[16:09] <sergiusens> elopio strace in a snap shell
[16:09] <ogra_> abeato, hmm, whats the error, it should
[16:09] <elopio> ok! I've never done that, let me find the instructions.
[16:10] <abeato> error: cannot install "ubuntu-core": snap "ubuntu-core" already installed
[16:10] <abeato> ogra ^^
[16:10] <ogra_> abeato, though edge is quite brave, i'd go with beta
[16:10] <ogra_> weird
[16:10] <ogra_> thsi is how i got mine onto edge back then
[16:11] <abeato> hm...
[16:11] <ogra_> but that should have no influence on ubuntu-image
[16:12] <abeato> ogra_, ah... I must use "refresh" instead of "install" when installed, even when trying to use a different channel :)
[16:13] <ogra_> ah
[16:13] <abeato> 660 rev
[16:13] <ogra_> yeah, beta is fine :)
[16:14] <ogra_> geez ... this resizing thing is insane ... still going ...
[16:14] <ogra_> i wonder why i havent hit it earlier
[16:18] <elopio> sergiusens: am I doing this right? https://paste.ubuntu.com/23220881/
[16:18] <elopio> it just  seems to do nothing.
[16:19] <mup> PR snapd#1991 opened: overlord,store: clean up serial-proof plumbing code <Created by pedronis> <https://github.com/snapcore/snapd/pull/1991>
[16:23] <mup> PR snapd#1992 opened: overlord/state: introduce cleanup support <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1992>
[16:27] <ogra_> YAY !!!
[16:27] <ogra_> so this was 50min for the resize
[16:28] <ogra_> finally it moved
[16:28] <mup> PR snapd#1993 opened: snap: move/clarify Info.Broken <Created by pedronis> <https://github.com/snapcore/snapd/pull/1993>
[16:32] <ogra_> slangasek, http://paste.ubuntu.com/23220928/
[16:32] <ogra_> slangasek, also, confirmed that resizing is slow on pi3 with the small images
[16:33] <slangasek> ogra_: thanks.  interesting, you have there a block and fragment size that's smaller than what I saw locally in a pi2 image... which way did you create this with ubuntu-image? the snap, the yakkety deb?
[16:33] <slangasek> (or is this the official image?)
[16:34] <ogra_> slangasek, trunk calling ./ubuntu-image
[16:34] <slangasek> ogra_: against what release?
[16:34] <slangasek> are you using xenial or yakkety e2fsprogs?
[16:34] <ogra_> on a xenial host with tghe PPA ext2fsprogs version installed
[16:34] <slangasek> ok
[16:35] <sergiusens> elopio track the forks and make it output to separate files, much easier
[16:36] <ogra_> i havent checked an actual image yet, i'll do some builds with workdir so i can inspect the img files on the weekend ... currently my machine is busy actually re-building the dailies
[16:36] <elopio> sounds easy, let's see if stackoverflow knows how to do it.
[16:39] <ogra_> slangasek, oh, and here is the resize log http://paste.ubuntu.com/23220950/
[16:39] <slangasek> ogra_: ok.  your block size, fragment size, blocks per group, fragments per group are all smaller than what I have in the last pi2 image I created here, *with* the size minimization; so that's definitely something different, I'll see if I can reproduce this
[16:41] <mup> PR snapcraft#824 opened: Add `snapcraft create-key` <Created by cjwatson> <Conflict> <https://github.com/snapcore/snapcraft/pull/824>
[16:41] <slangasek> ogra_: you said "the PPA" for e2fsprogs... which ppa? I don't see e2fsprogs in snappy-dev/image or snappy-dev/tools
[16:41] <ogra_> slangasek, and the resize code http://paste.ubuntu.com/23220956/ ... perhaps i'm doing something unsuitable here
[16:42] <ogra_> slangasek, your ubuntu-image ppa :)
[16:42] <slangasek> ogra_: I think the problem is in your initial fs creation, which doesn't match the one we had here and that yes, will have poorer performance (not just during resize, but overall)
[16:42] <slangasek> ogra_: ok, I didn't assume you were using our ppa ;)
[16:42] <elopio> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1583259 can we have that in the next milestone?
[16:42] <mup> Bug #1583259: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <verification-done> <Canonical Click Reviewers tools:Fix Released by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Triaged by sergiusens> <Snappy:New> <click-reviewers-tools (Ubuntu):Fix Released>
[16:42] <mup> <click-reviewers-tools (Ubuntu Xenial):Fix Released> <click-reviewers-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1583259>
[16:43] <ogra_> well, i didnt want to blindly install the yakkety package here :)
[16:43]  * zyga has unexpected guests for the past two hours, sorry for being laggy
[16:43] <ogra_> zyga, how dare you to have a social life !
[16:44] <slangasek> ogra_: that should definitely give me enough to try to reproduce the problem here, thanks.  One last thing, could you kpartx -a the original image and tune2fs -l that as well, just to confirm that the weird block sizes are in the source image?
[16:44] <slangasek> ogra_: and are you using the official pi2 model assertion for this or another one?
[16:44] <ogra_> slangasek, yeah, waiting for my machine to be done with the image build, then i'll do the kaprtx
[16:45] <ogra_> slangasek, official but you are looking at dragonboard data there
[16:45] <ogra_> not pi2
[16:45] <ogra_> thje only non-official assertion i use is the bbb one
[16:46] <zyga> ogra_: well, social life friends just flew in from spain, on their way elsewhere, with night overlap through warsaw :)
[16:46] <zyga> ogra_: when stuff is on fire like it feels now I don't like having a social life TBH
[16:47] <ogra_> zyga, well, you are around til 10pm on normal days and start at 8 ... and hang around here on weekends ...  if friends come you should simply end your day
[16:47] <zyga> ogra_: .... are you saying I should re-consider having a social life for a change
[16:47] <ogra_> at times :)
[16:48] <zyga> ogra_: I'd like to, at least, finish the week knowing that I know how the fire started
[16:48] <zyga> ogra_: otherwise I will just think about it all the time anyway
[16:48] <ogra_> well, go and do the fire inspection then :)
[16:49] <zyga> ay :)
[16:50] <oparoz_> Does snap web work? Is there documentation for it? Can it install beta snaps? Does it support devmode?
[16:51] <ogra_> slangasek, http://paste.ubuntu.com/23220991/ for the kpartx bit
[16:51] <zyga> oparoz_: I know some people have been working on it again lately
[16:51] <zyga> oparoz_: perhaps jamiebennett knows better
[16:52] <oparoz_> Thanks zyga. I'm trying to figure out how to push new apps to users of the Nextcloud Box. I'm guessing the only way right now is to tell them to use SSH?
[16:53] <zyga> oparoz_: push as in remotely install?
[16:53] <zyga> oparoz_: I didn't try lately, does snapweb do anything useful after being installed?
[16:53] <oparoz_> zyga, Well, more as in making it available somewhere so that they can push a button and install it
[16:54] <oparoz_> zyga, I saw this screenshot and want my snaps to be on there: https://insights.ubuntu.com/2016/09/22/rocket-chat-a-new-snap-is-landing-on-your-nextcloud-box-and-beyond/
[16:56] <mup> PR snapcraft#825 opened: Release changelog for 2.18.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/825>
[16:56] <zyga> oparoz_: I think that's just the store, if your app is in the store and has the right meta-data it will show up like that in snapweb
[16:56] <zyga> oparoz_: I know there's been a lot of work put into snapweb, I don't know if it is released as stable though
[16:57] <oparoz_> zyga, thanks. I just don't understand how users will get to see that page with their installed snaps. I never had to register to be able to install snaps
[17:07] <kyrofa> zyga, oparoz__ I think snapweb is only in edge right now. elopio or lool might know more
[17:08] <oparoz__> So basically, the screenshot in that article is something which cannot be used by Box' at this stage
[17:08] <oparoz__> kyrofa, or can you get this view by SSHing and manually connecting the Box to the store?
[17:09] <oparoz__> And then install Snaps on the box via the store's "Add more snaps"
[17:09] <kyrofa> oparoz__, yeah, SSH in and try this: `sudo snap install --edge snapweb`
[17:10] <oparoz__> OK, done.
[17:10] <kyrofa> oparoz__, I don't remember what port it's on... I want to say 4200
[17:10] <oparoz__> :D
[17:11] <kyrofa> netstat will help
[17:11] <oparoz__> you were correct :)
[17:12] <oparoz__> kyrofa, unfortunately, it only lists stable snaps, so not very useful :(
[17:12] <oparoz__> I mean to ask users to help test snaps
[17:13] <kyrofa> oparoz__, yeah, stable snaps are the only ones that are easily discoverable in the store
[17:13] <kyrofa> oparoz__, like what?
[17:13] <oparoz__> transmission
[17:14] <oparoz__> But I guess it also filters by arch... and I haven't created the armh yet
[17:15] <oparoz__> But snap web will be very cool once stable
[17:16] <kyrofa> Yeah it'd be ideal to be able to say "show me unstable snaps" or something
[17:16] <oparoz__> kyrofa, yeah, or just pick the minimum level of stability
[17:17] <oparoz__> I'm OK with stable and beta per example
[17:17] <kyrofa> Yeah, checkboxes for "show me these channels" even
[17:17] <oparoz__> Especially since we can't put devmode snaps in stable
[17:34] <mup> PR snapd#1977 closed: interfaces/builtin: add network-setup-observe interface <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1977>
[17:44] <attente> kyrofa, elopio, hi
[17:44] <elopio> hello attente o/
[17:44] <attente> :)
[17:45] <attente> i'm having issues with getting the integration test for the jhbuild plugin working under travis-ci
[17:45] <mup> PR snapd#1991 closed: overlord,store: clean up serial-proof plumbing code <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1991>
[17:46] <attente> mostly because the tests are run as a root user in a docker instance
[17:46] <mup> PR snapd#1980 closed: tests: more debug around the create-key test <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1980>
[17:46] <attente> but i also saw that the cleanbuild integration test that also uses lxc is specifically disabled
[17:47] <attente> so i'm wondering if that's ok to do for the jhbuild plugin test as well
[17:49] <attente> basically i'm in a world of hurt trying to get it working under root when it's only meant to be run unprivileged
[17:54] <kyrofa> attente, hey there!
[17:54] <kyrofa> attente, I don't know the specific answer to your question, but note that the launchpad builders all run as root as well. Ideally plugins would work under root
[17:54] <sergiusens> attente I've been meaning to ask, how does your jhbuild plugin going to work when we switch to containers by default to build most things?
[17:55] <elopio> attente: I thought it used lxc.
[17:55] <sergiusens> elopio he's thinking lxc inside docker
[17:56] <attente> sergiusens: yeah... i didn't realize that was the plan. you're switching to lxc containers? there's some support for nesting i believe?
[17:56] <sergiusens> attente yes there is
[17:57] <sergiusens> attente I am just waiting for the network setup dilemma in lxd to be solved
[18:06] <elopio> sergiusens: https://paste.ubuntu.com/23221212/ Here's my strace. I see many errors, but I'm not sure what I'm looking for.
[18:06] <elopio> It seems bad that many things in electron/dist are not found.
[18:07] <mup> PR snapd#1983 closed: ctlcmd: add snapctl get <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1983>
[18:27] <jdstrand> zyga: fyi, https://bugs.launchpad.net/snap-confine/+bug/1626019/comments/2
[18:27] <mup> Bug #1626019: Docker snap cannot start containers in Classic (but does in Core) <Snappy Launcher:New> <https://launchpad.net/bugs/1626019>
[18:29] <mup> PR snapcraft#826 opened: Do not depend on Content-Length when Content-Encoding is gzip <Created by tachyons> <https://github.com/snapcore/snapcraft/pull/826>
[18:34] <lool> kyrofa: snapweb >> beta + edge actually (beta images, beta snapweb) - but I think it could happily be promoted
[18:34] <kyrofa> lool, awesome!
[18:35] <kyrofa> lool, would be great to have it in stable
[18:36] <lool> kyrofa: yeah; I wish it wasn't too late to ping mvo about it, but I'm totally +1 on it; we could promote it monday
[18:36] <lool> kyrofa: I'll be at Linaro Connect next week (Vegas), if you get the chance to discuss this with him, that'd be lovely
[18:36] <lool> I can do it, but I wanted to touch base with mvo before doing so
[18:36] <kyrofa> lool, making a note now, you got it
[18:36] <lool> s/can do it/can do the actual promotion/
[18:36] <lool> <3
[18:37] <kyrofa> lool, I'll tell him you +1d it but wanted to double check with him first
[18:37] <lool> yeah
[18:37] <lool> thanks a ton
[18:37] <kyrofa> Sure thing. Good luck at linaro!
[18:38] <mup> PR snapcraft#825 closed: Release changelog for 2.18.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/825>
[19:10] <lpotter>  qengho, ogra_ wait what? we dont allow normal console login on rpi?!?
[19:12] <qengho> lpotter: We do! We do. Or, rather, we should. We want to.
[19:14] <lpotter> I see the rpi as a convergent device, instead of mobile/desktop, its convergent embedded/desktop :)
[19:14] <qengho> lpotter: If it doesn't give a config prompt on the display that is built-in, it is a bug.
[19:14] <qengho> lpotter: I'm trying to figure out details of it now.
[19:15] <jdstrand> lool: fyi, https://github.com/jdstrand/docker-snap/tree/snappy-interfaces (updated snapcraft.yaml for new interfaces) and https://github.com/jdstrand/docker-snap/tree/workaround-lp1626019 (make docker work on classic)
[19:15] <lpotter> qengho: whats the login password?
[19:16] <jdstrand> lool: the 2nd has everything from the first. You'll still want to upload in devmode I think until snapd with docker/docker-support lands in xenial-updates, but hopefully this helps
[19:17] <qengho> lpotter: there is no password.
[19:17] <qengho> lpotter: did you configure?
[19:19] <qengho> lpotter: Your username is probably your launchpad id. l-p
[19:19] <lpotter> I might need to reflash. never got to see the configure screen at first boot. shut it down, changed cmdline.txt
[19:20] <lpotter> ahh,ok. so it sets up the user, and no user ubuntu now?
[19:20] <nacc> lpotter: yeah, i think that's correct
[19:21] <jdstrand> zyga: fyi, see the trello card and bug #1626019. I thought there was some talk with you and st graber on cleaning up mountinfo so that it only head relevant entries-- if that happened I suspect docker would work without the workaround. that said, with the workaround I think the urgency is not world-burning any more
[19:21] <mup> Bug #1626019: Docker snap cannot start containers in Classic (but does in Core) <Snappy Launcher:Triaged> <https://launchpad.net/bugs/1626019>
[19:21] <jdstrand> ratliff, tyhicks: ^
[19:23] <slangasek> ogra_: in case you didn't see the mail, https://github.com/CanonicalLtd/ubuntu-image/pull/65 awaits your testing
[19:23] <mup> PR CanonicalLtd/ubuntu-image#65: Avoid wrong block sizes for an fs we'll resize on first boot anyway <Created by vorlonofportland> <Merged by warsaw> <https://github.com/CanonicalLtd/ubuntu-image/pull/65>
[19:26] <tachyons_> "CompressionError: unknown compression type 'xz' " I am getting this error when I am trying to install snapcraft
[19:26] <tachyons_> I installed lzma package , But no luck
[19:27] <nacc> tachyons_: installing snapcraft where?
[19:27] <tachyons_> nacc: my laptop
[19:27] <tachyons_> ubuntu 16.04 , 64 bit
[19:27] <nacc> tachyons_: sorry, the release is what i meant, i assume `apt install snapcraft` ?
[19:28] <tachyons_> nacc:  sorry , while installing from github
[19:28] <nacc> tachyons_: ah
[19:29]  * nacc doesn't know about that, unfortunately
[19:29] <nacc> but you wouldn't need lzma but xz-utils, iirc
[19:30] <slangasek> tachyons_, nacc: /usr/lib/python3.5/lzma.py is part of libpython3.5-stdlib, stock in 16.04; sounds like a corrupted python install?
[19:32] <nacc> yeah, seems weird either way
[19:33] <tachyons_> nacc: I installed xz-util too
[19:33] <nacc> tachyons_: hrm, strange! as slangasek said, it should 'just work', sorry -- you'd have to dig into what is reporting that error
[19:34] <tachyons_> I have libpython3-stdlib installed , should install 3.5-stdlib too ?
[19:35] <nacc> tachyons_: libpython3-stdlib depends on libpython3.5-stdlib
[19:35] <tachyons_> https://paste.gnome.org/p3gijqva3
[19:35] <nacc> ah
[19:35] <nacc> locally compile python?
[19:35] <nacc> *compiled
[19:35] <tachyons_> seems like error is from python2.7 , Is it an issue with pip ?
[19:35] <tachyons_> nacc: No !
[19:36] <nacc> tachyons_: you might need 'python-lzma'
[19:36] <nacc> for 2.7 support
[19:37] <tachyons_> nacc: Already instaled , no luck
[19:38] <slangasek> python2.7> none of this should be using python2
[19:38] <tachyons_> I am a ruby guy  and don't have much idea about python ecosystem :-)
[19:38] <slangasek> don't know how you got things into a state that python2.7 is involved
[19:39] <nacc> slangasek: that was goign to be my next q
[19:39] <nacc> tachyons_: snapcraft is python3 based afaict
[19:39] <nacc> https://github.com/snapcore/snapcraft/blob/master/HACKING.md seems to refer to only python3 deps
[19:39] <tachyons_> slangasek:  Error message showing python 2.7 , that is why I asked about that
[19:40] <tachyons_> I copied steps from Hacking.md
[19:40] <kyrofa> tachyons_, you might consider simply installing snapcraft, which will pull in the right deps, then just run from source
[19:41] <slangasek> yes, that is the shortest path to get you going with snapcraft on 16.04
[19:41] <slangasek> however, I am worried that these python2 errors imply you have damaged your 16.04 system
[19:41] <nacc> tachyons_: why is your pip local to your user?
[19:42] <tachyons_> kyrofa:  I already have working snapcraft installed from repo , But I need snapcraft sourcecode for some hacks
[19:43] <kyrofa> tachyons_, right, I understand. I'm just saying snapcraft from source and snapcraft in the archive typically have the same deps
[19:43] <kyrofa> tachyons_, you could use build-dep if you have source archives enabled, too
[19:44] <tachyons_> One doubt , command is pip3 is python3 and pip is for python2, right ?
[19:44] <qengho> ogra_: have you ever booted your RPi3 with release image without your serial attached?
[19:46] <slangasek> tachyons_: you seem to be right about that, indeed - so HACKING.md ought to be updated
[19:48] <kyrofa> tachyons_, yeah, you can probably safely ignore the HACKING.md. Just make sure the right deps are installed and run path/to/src/bin/snapcraft directly
[19:48] <kyrofa> No need to install it in a venv, etc
[19:49] <tachyons_> replaced pip with pip3 , Now it is working
[19:49] <tachyons_> Thanks
[19:50] <mup> Bug #1627175 opened: RPi3 with only HDMI attached never shows subiquity <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1627175>
[19:50] <qengho> lpotter: Check this bug to see if it matches your experiences. ^
[19:51]  * qengho afk a while.
[20:17] <mup> PR snapd#1993 closed: snap: move/clarify Info.Broken <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1993>
[20:44] <dduffey> lool, slangasek how do you turn off autopilot ... I am using  custom kernel (for a demo) and the autopilot it causing it to loose the network
[20:44] <dduffey> I used to do "snappy config", but I don't see a "snap config"
[20:45] <lool> dduffey: you cant
[20:45] <lool> dduffey: config was not readded yet for series 16
[20:55] <mup> PR snapd#1992 closed: overlord/state: introduce cleanup support <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1992>
[20:58] <mup> PR snapd#1989 closed: tests: build once and install test snap from cache <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1989>
[21:49] <zyga> jdstrand: I'll check that card next week; what I remebmer about this is that we now properly detach the old root but because old root is still visible we cannot really umount or detach anything else
[21:51] <zyga> jdstrand: offtopic, this branch was there to test if the unexpected unmount of the core snap is caused by the test that was fiddling with cgroups: https://github.com/snapcore/snap-confine/pull/152
[21:51] <mup> PR snap-confine#152: Disable failing test <Created by zyga> <https://github.com/snapcore/snap-confine/pull/152>
[21:51] <zyga> jdstrand: but as you can see, it failed
[21:51] <zyga> jdstrand: I'll run another pass in qemu locally (I'll switch to linode next) to try to capture syslog and snap changes when this happens
[21:51] <zyga> jdstrand: but it also means that I don't reall know what is causing this to fail
[21:58] <zyga> dduffey: you can disable the snapd.refresh.timer perhaps
[21:58] <zyga> dduffey: (systemd level timer)
[23:11] <evgenijmalanov> What i can inistall .snap files ( Ubuntu Touch device
[23:12] <evgenijmalanov> .. What i can inistall .snap files ( for Ubuntu Touch device) on desktop
[23:20] <qengho> evgenijmalanov: I don't understand what you want.
[23:28] <mup> PR snapcraft#827 opened: Support setting build targets in the maven plugin. Make the maven plu… <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/827>
[23:57] <oparoz> Does "refresh" pick up changes in the beta channel?