[00:02] PR snapd#1952 closed: configstate,hookstate: add snapctl set [00:07] PR snapd#1983 opened: ctlcmd: add snapctl get [02:04] Bug #1564076 changed: Can't launch snaps

robert-ancell> === gaughen_ is now known as gaughen [02:53] er do tests pass with tip for people right now? [02:55] go test github.com/snapcore/snapd/interfaces/builtin fails for me [03:15] PR snapd#1984 opened: daemon: add logging to help diagnose create-user slowness [05:10] 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. === hikiko is now known as hikiko|off [06:09] PR snapd#1985 opened: progress: use New64 and fix output newline [06:18] PR snapd#1973 closed: tests: ensure HOME is also set correctly [06:19] PR snapd#1986 opened: tests: ensure HOME is also set correctly [06:39] hey hey [06:54] good morning dholbach [06:54] salut didrocks [07:01] o/ [08:18] * ogra_ -> dentist === chihchun_afk is now known as chihchun [08:44] PR snapd#1986 closed: tests: ensure HOME is also set correctly === jamespag` is now known as jamespage [09:15] PR snapd#1984 closed: daemon: add logging to help diagnose create-user slowness [09:16] mwhudson, o/ === rmescandon_ is now known as rmescandon === vigo is now known as vigo-afk [09:25] Bug #1626930 opened: Missing mount-observe slot in Core [09:28] Bug #1626930 changed: Missing mount-observe slot in Core [10:18] 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] Was looking in the repo of the fork... So it seems everything is gone. Too bad [10:49] 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] PR snapd#1987 opened: daemon,overlord/assertstate: support streams of assertions with snap ack [10:57] 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] pitti: can you have a look at https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 ? [11:15] morphis_: replied [11:16] pitti: the service name is sadly nothing I can influence [11:16] that is what snapd builds for it [11:16] also to avoid intersections with other snaps [11:16] morphis_: right, hence adding Alias= [11:16] pitti: sure but that is still something snapd need to get from somewhere [11:17] WDYM "get"? [11:17] pitti: snapd creates the service unit on the fly [11:17] you just put it in the unit, and when it gets enabled, systemctl creates the alias symlink [11:17] we don't ship it as part of the snap so we can't modify it [11:17] err [11:18] 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] if we are going to snap up core plumbing parts like NM, bluez, cups or whatnot, I suppose that's necessary indeed [11:18] pitti: something to argue with niemeyer about [11:18] cluttering a lot of packages with snapd service aliases is a really bad design [11:18] pitti: I am currently just searching for a way to replace networkd in our images with network-manager which comes from the snap === chihchun is now known as chihchun_afk [11:47] Bug #1626986 opened: snapd should allows snaps to define systemd unit Alias names [12:00] 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] jdstrand: and can stable end up in devel? [12:01] jacekn: I think so [12:02] sergiusens: can you comment? ^ [12:05] 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] jdstrand: sergiusens: so really IMO warning is an overkill, I'd prefer not to have that option at all [12:06] jacekn (cc sergiusens): we didn't design the feature. perhaps that would be a good question for the mailing list? [12:07] jdstrand: ack and good point! [12:07] that way you'll get definitive answers on how things work and why [12:07] and I know they are always looking for real world feedback [12:09] 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] 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] *hdmi_safe [12:13] 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] 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] well, that should resize in 2-3min max [12:17] (likely faster) [12:18] i really cant reproduce it here ... i always get the "please press enter" under the raspberries [12:18] 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] But I can't test the serial one. [12:18] no, then you dont get the actual boot data on serial [12:19] 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] might be first and last (instead of first and second) if you have more than two ... [12:21] 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] ogra_: In any case, perhaps that configuration tool can display on /dev/ttySwhatever AND /dev/tty0 . [12:24] it does ! [12:24] Oh. Hrm. [12:24] Then something is wrong. [12:24] here at least ... [12:24] PR snapd#1974 closed: snapd: kmod backend [12:25] ogra_: Okay, I'll test and let you know. [12:25] 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] *on [12:26] 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] so defaulting to HDMI doesnt really make much sense [12:28] ogra_: You connect another computer and *its* display to the computer, instead of just a display? That's dumb. That's why. [12:28] (having avahi and a network based conole-conf by default would make massively more sense) [12:28] Yes, so much. I need some zeroconf. [12:29] well ... except that the image will then explode in size ... we're already way to big for embedded [12:30] ogra_: OTOH, if you have an old DEC VT220 you're plugging in directly, then I apologize. [12:30] i just use the serial cable that was shipped with the board when i bought the "embedded developer" set [12:30] :P [12:32] 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] qengho, you dont really expect people to attach a monitor to their NAS, AP, router, IoT controller, do you ? [12:33] i'm not saying computer at all [12:33] 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] we are targeting IoT here ... at most you will run a single purpose kiosk app in such a device [12:34] when you use HDMI at all [12:34] 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] i definitely dont know anyone who actually uses a pi as their default desktop system, sorry [12:36] 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] *kodi [12:37] 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 === tachyons is now known as tachyons_ [12:38] ogra_: ping [12:38] no need to ping me if i talked a line above ;) [12:38] just ask :) [12:39] ogra_: but you have the choice to pong when you're free :-) [12:39] * ogra_ pongs [12:39] heh [12:39] hehe [12:39] 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] ogra_: we put upgrade for netplan currently in the ppa to include them in the next core snap, right? [12:40] 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] Eg github gist [12:40] Lazy to file a bug in launchpad :D [12:40] qengho, yeah, its a sad fact that people picked a dead wood settopbox chip for that hype instead of something proper ... [12:41] morphis_, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial [12:41] needs to end up there [12:42] morphis_, at least until pitti lands everything that netplan needs in xenial-updates proper :) [12:43] (which i hope is the case for GA, we need to be able to build stable without the PPA) [12:43] ogra_: when is GA? [12:43] pitti, uh, not sure ... several weeks ... jamiebennett knows exact dates [12:43] 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] sergiusens: cc [12:44] ogra_: but we could certainly start to SRU the NetworkManager patches at least [12:44] pitti: GA = 2016-11-03 [12:44] thanks [12:44] now thats exact :) [12:44] morning or afternoon? ☺ [12:44] *g* [12:44] 23:59 [12:45] we need all the time we can ;) [12:45] PST [12:46] ogra_: ok [12:47] 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] morphis_: it's your PPA, go wild :) [12:47] pitti: not really mine :-) [12:48] it's not a long-term solution, but good enough for a beta/demo for sure [12:48] pitti: its for sure not a demo, it goes into production [12:51] pitti: but we can figure out a better solution and migrate to that at a later point [12:51] *nod* [12:51] and the PPA seems fine for those [12:53] 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] jdstrand, hey, thanks for the review of timedate control interface! === vigo-afk is now known as vigo [12:55] pitti: yeah another option, something we need to discuss with niemeyer [12:55] 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] 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] so i doubt we could make that a generic thing [12:56] jdstrand: hey [12:56] well, then at least provide them under their original name [12:56] because i need a wrapper that creates an initial config, in a non standard place for example [12:56] ogra_: it would be just an alias we need to add to the files you say we're NetworkManager.service too [12:56] they aren't co-installable with the corresponding debs anyway [12:57] pitti, hahaha ... [12:57] (we have nothing that prevents this) [12:57] but it would just mean that dependencies, resource limitations, privilege reductions, aliases, etc. need to be duplicated in the yaml [12:57] PR snapd#1988 opened: Allow system bus access for screen-inhibit-control [12:58] but anyway, that's a SEP :) [13:05] 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] pstolowski: you're welcome :) [13:06] jdstrand: it's not [13:06] jdstrand: I just started realizing what is the problem [13:06] jdstrand: I'm going to just get an ack from chipaca and release stuff [13:06] zyga: heh, ok, cause I was starting to get worried :) [13:06] jdstrand: it seems snapd is doing something crazy wrt cleanup now [13:06] jdstrand: ubuntu-core is unmounted mid tests when some cleanup task fires [13:07] zyga: ack. that is worrisome for other reasons, but glad that the ns discard wasn't causing it :) [13:07] 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] great :) [13:09] tachyons_ we have a bug for that [13:10] jdstrand I just answered an askubuntu question about grade around 30' ago [13:11] zyga: I see you merged that-- should you uncomment the hello-world bit too? [13:11] sergiusens: cool [13:11] jdstrand: I evicted that commit [13:11] * sergiusens goes back to writing unit tests [13:11] jdstrand: it's not commented out anymore [13:12] * sergiusens looks at joc_ and wonders how he got away with it ;-) [13:12] zyga: ok cool. I didn't see that commit, only the one saying you were merging. thanks [13:14] jdstrand: I rebased that commit away (the one that was commenting those bits out) [13:27] PR snapd#1987 closed: daemon,overlord/assertstate: support streams of assertions with snap ack [13:35] sergiusens: link ? [13:38] tachyons_ https://bugs.launchpad.net/snapcraft/+milestone/2.19 [13:38] Hello! Whats the update on diff based snap updates ? [13:45] PR snapd#1989 opened: tests: build once and install test snap from cache [14:07] Whats the password for all-snap image ? After I added my launchpad email, I am not able to login. [14:07] 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] om26er only ssh [14:07] ssh in and set a passwd if you must [14:08] "sudo passwd $USER" after you sshed in ... [14:08] ogra_ obviously :-P [14:08] sergiusens, hmm, I think I can't remember my IP [14:09] om26er cannot help you there [14:09] sergiusens, well, yu could just try "passwd" which wont work ... [14:09] IP for the virt manager machine [14:09] nmap might [14:09] so not *that* obvious [14:09] ogra_ because current passwd is unset/unkown [14:09] yeah [14:09] and sudo does the trick [14:09] right [14:12] ogra_, sergiusens I am in. Had to re create the VM to know my IP :) [14:29] 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] exactly how I cannot explain yet [14:47] 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? === JanC is now known as Guest73904 === JanC_ is now known as JanC [14:52] mvo, slangasek, hmm, the small image size made resize2fs take significantly longer :/ [14:52] i wonder why ... [14:53] (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] PR snapcraft#823 closed: plainbox-provider plugin: rewrite python shebangs [15:01] * ogra_ goes and tries the beta image instead [15:01] sergiusens: http://paste.ubuntu.com/23220481/ [15:03] SamYaple ah, so it is python2 that has the issue, got it [15:03] bah [15:03] resizes instantly [15:03] that wasnt even 20sec [15:05] i guesss that means that creating images at minimal size complicates resizing [15:05] :( [15:06] sergiusens: for dogpile.cache, yes python2 is the issue [15:06] ogra_: er... impressive? [15:06] sergiusens: but its on a per project bases. this same thing can happen on python3 [15:06] slangasek, why ? [15:06] *basis [15:07] 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] slangasek, i assume with the minimal size the blocksize is not exactly a multiple of 512 or some such [15:07] slangasek, well, i gave up after 15min ... not sure how long it would actualyl have taken [15:07] but using the 3.8GB big beta image resizes absolutely instantly [15:08] slangasek, oooh, and since i'm testing on the dragonboard ... i'm now glaring since 2min at "Contacting server..." [15:08] o this slowness seem to not be arch specific at all [15:08] *so [15:08] *eems [15:08] bah ! [15:10] (right after i typed that the screen changed, but even on the dragonboard it is slow at the user setup tep) [15:11] hmm, but why is the resize so slow, there are no errors in the resize log [15:11] (apart ffrom the one when i ripped out the card it seems resize2fs was chugging along happily) [15:19] PR snapcraft#822 closed: Don't filter .pth files in python plugin [15:20] * ogra_ rolls an image with extra added empty space [15:25] cwayne: you did atom, right? Can you help me with an electron snap? [15:29] elopio: yep, sure [15:29] cwayne: I'm getting Error: spawn electron ENOENT [15:30] have you seen that? I'm trying adding electron to node-packages, but I have no idea what I'm doing. [15:30] 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] 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] 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] Can the snap web install beta apps? [15:32] ...which are using devmode [15:33] 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] (and i cant see any change related to this in your github tree either) [15:34] 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] ogra_: maybe you want to experiment with those and see which flags might make a difference to the speed? [15:36] ogra_: its not pushed, but its just 4Gb->3.9Gb, i can push the diff if you need it [15:36] 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] mvo, that would be great ... i want the dailies to not take hours while people like qengho wait for something on HDMI ;) [15:37] i guess *that* is the actual problem [15:37] (regarding the console= discussion) [15:37] 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] slangasek, thats the dragonboard ... but i bet we'll have iot on all images [15:38] ogra_: I don't have a 128GB SD card to reproduce this with [15:38] (i test the bbb with a 4GB card ... the resize is neglectable there) [15:38] slangasek, well, a 256GB one will do as well :P [15:38] ogra_: also, 'tune2fs -l' output on the filesystem after the resize is done, please [15:39] ok, will do [15:53] PR snapd#1990 opened: many: allow use of the system user assertion with create-user [15:56] ogra_, why might I see this error when doing "snap prepare-image"? : [15:56] error: cannot fetch and check prerequisites for the model assertion: assertion not found [15:57] how does your assertion look like ? [15:57] ogra_, http://paste.ubuntu.com/23220732/ [15:58] hmm, looks fine [15:58] and you specified the path to it correctly in the ubuntu-image command line ? [15:59] ogra_, yes, this it the command that fails: [15:59] $ 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] pi3.model is in the folder === bschaefer_ is now known as bschaefer [16:00] what is /tmp/tmpqfqroa0f/unpack supposed to be [16:00] ogra_, the actual command that is executed is: [16:00] * ogra_ has actually never used snap prepare-image directly ... [16:00] $ 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] ogra_, but in the end what fails is the prepare-image step [16:01] hmm [16:02] does it work if you call it completely without --extra-snaps ? [16:02] no, not in that case either [16:03] 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] ogra_, let me try [16:06] alright, now I don't get any errors. But also I don't get any window :( [16:06] any electron expert around? [16:07] ogra_, I have [16:07] 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] ubuntu-core 16.04.1 423 canonical - [16:07] doing [16:07] $ sudo snap install --channel=edge ubuntu-core [16:07] error: cannot install "ubuntu-core": snap "ubuntu-core" already installed [16:08] is that fine? [16:08] abeato, i thik 423 is the last stable [16:08] sergiusens: ok, how do I check that? [16:08] I have nothing about fonts or gtk, but I can copy them from atom [16:09] ogra_, how do I install a new one? "sudo snap install --channel=edge ubuntu-core"does not work [16:09] elopio strace in a snap shell [16:09] abeato, hmm, whats the error, it should [16:09] ok! I've never done that, let me find the instructions. [16:10] error: cannot install "ubuntu-core": snap "ubuntu-core" already installed [16:10] ogra ^^ [16:10] abeato, though edge is quite brave, i'd go with beta [16:10] weird [16:10] thsi is how i got mine onto edge back then [16:11] hm... [16:11] but that should have no influence on ubuntu-image [16:12] ogra_, ah... I must use "refresh" instead of "install" when installed, even when trying to use a different channel :) [16:13] ah [16:13] 660 rev [16:13] yeah, beta is fine :) [16:14] geez ... this resizing thing is insane ... still going ... [16:14] i wonder why i havent hit it earlier [16:18] sergiusens: am I doing this right? https://paste.ubuntu.com/23220881/ [16:18] it just seems to do nothing. [16:19] PR snapd#1991 opened: overlord,store: clean up serial-proof plumbing code [16:23] PR snapd#1992 opened: overlord/state: introduce cleanup support [16:27] YAY !!! [16:27] so this was 50min for the resize [16:28] finally it moved [16:28] PR snapd#1993 opened: snap: move/clarify Info.Broken [16:32] slangasek, http://paste.ubuntu.com/23220928/ [16:32] slangasek, also, confirmed that resizing is slow on pi3 with the small images [16:33] 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] (or is this the official image?) [16:34] slangasek, trunk calling ./ubuntu-image [16:34] ogra_: against what release? [16:34] are you using xenial or yakkety e2fsprogs? [16:34] on a xenial host with tghe PPA ext2fsprogs version installed [16:34] ok [16:35] elopio track the forks and make it output to separate files, much easier [16:36] 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] sounds easy, let's see if stackoverflow knows how to do it. [16:39] slangasek, oh, and here is the resize log http://paste.ubuntu.com/23220950/ [16:39] 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] PR snapcraft#824 opened: Add `snapcraft create-key` [16:41] ogra_: you said "the PPA" for e2fsprogs... which ppa? I don't see e2fsprogs in snappy-dev/image or snappy-dev/tools [16:41] slangasek, and the resize code http://paste.ubuntu.com/23220956/ ... perhaps i'm doing something unsuitable here [16:42] slangasek, your ubuntu-image ppa :) [16:42] 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] ogra_: ok, I didn't assume you were using our ppa ;) [16:42] sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1583259 can we have that in the next milestone? [16:42] Bug #1583259: Snappy needs to influence environment variables in applications