[00:10] PR snapcraft#863 opened: history/status alignment fixes [01:39] help [01:45] Anyone has a guide in running .net core in snappy ubuntu core? i'm following the guide in microsoft website, i can't install because it was using apt-get install. [01:51] it's not snapped yet [01:54] @Son_Goku so it's possible to run a .net core in snappy ubuntu core i just need to snap it first, correct? [01:54] rl-ubuntu: No such command! [01:54] yep [01:56] awesome, will try that. thanks [04:17] Bug #1612260 changed: My package is published but not showing up in the store [07:05] PR snapd#2125 opened: tests: fixed code blocks on external backend readme [07:13] good morning [07:32] didrocks, hey, I’ve rebuilt my webbrowser-app snap and I was expecting that because of https://github.com/ubuntu/snapcraft-desktop-helpers/commit/46bea1d261e005eecfe532a5a23d9dd080898432 locales-all would be pulled in as a stage package, but it appears it’s not. any idea why? [07:37] PR snapd#2126 opened: tests: add spread test for `snap auto-import` [07:42] oSoMoN: hey! oh, interesting, let me check if I can find the online definition of the importer [07:42] oSoMoN: you did snapcraft update, correct? [07:42] I do see locales-all here [07:52] didrocks, I didn’t run snapcraft update, but when checking the source of the desktop-qt5 part, it has my commit [07:53] re-running now, after running snapcraft update === mbriza|gone is now known as mbriza [07:56] oSoMoN: you did snapcraft clean as well? [07:56] because I'm unsure it dirty check properly [07:57] I ran bzr clean-tree --unknown --ignored in my branch, so there should be no leftover [07:57] yep! [08:05] PR snapd#2127 opened: tests: add test for auto-mount assertion import [08:11] PR snapd#2125 closed: tests: fixed code blocks on external backend readme [08:14] didrocks, now it worked, locales-all got included in my snap [08:14] looks like running snapcraft update made the differenc [08:14] nice! :) [08:14] difference [08:14] yep [08:14] you need to refresh the definition [08:14] it's like apt update if you prefer [08:14] thanks for the tip! [08:16] it's a bit error prone that it needs to be done manually this way :-/ [08:18] agreed, (I'm pretty sure that was already raised) [08:18] at least, it should tell "we have new definitions for you, please run…" [08:18] IIRC, the concern was "too many connections to the server" [08:19] I can see that connecting every time you use snapcraft wouldn't work either [08:19] but maybe refreshing once a day [08:19] then those who need to trigger an update can manually do it === jamespag` is now known as jamespage === StoneTable is now known as aisrael [08:47] PR snapcraft#864 opened: Update documentation links to developer.ubuntu.com that now redirect … === King_InuYasha is now known as Son_Goku [09:06] PR snapd#2128 opened: debian: remove usage of dh-systemd [09:23] PR snapd#2129 opened: interface attributes: prepare plug slot hooks (phase 1) [09:45] ogra_, once again talking about doing fancy stuff in core in #systemd and the "run systemd in initrd" comes up [09:51] Chipaca, well, have fun implementing it and making it work with the existing bits :P [09:51] Chipaca, effectively that will just make the initrd explode in size [09:51] ogra_, my response was *very* polite [09:51] with not much benefit [09:52] :) [09:52] ogra_, on the other hand, did we ever have a serious conversation around making initrd be the actual root? [09:56] Chipaca, we did in the phonedations team a few times. but not in context to snappy ... if we'd actually use initamfs-tools to create that rootfs (to only contain *exactly* what is necessary) that would surely result in an awesome but maintenance intense system [09:59] ogra_ what was it like working on the ninja sphere? [10:00] dr1337, like working with a beaglebone on streoids ;) [10:01] *steroids [10:01] How did canonical get involved in it? [10:01] PR snapd#2130 opened: store: retry store ops (phase 1) [10:09] dr1337, no idea ... probably a conference or some such. i only got the board and was asked to do an initial test image after the involvement was there already === hikiko is now known as hikiko|ln [10:17] re: launchpad snap builders, which version of Ubuntu do they use ? [10:17] xenial i think [10:17] I am building a snap, it works fine in a lxc container running xenial but fails to build in lp [10:17] how does it fail (got a build log link ?) [10:17] ogra_: https://launchpadlibrarian.net/289187171/buildlog_snap_ubuntu_xenial_amd64_crossbar_BUILDING.txt.gz [10:18] om26er, i'd guess for a firewall issue [10:19] ogra_: seems other things are downloading file from pypi [10:19] atleast from what I can see [10:19] om26er: it says : Download error on https://pypi.python.org/simple/: [Errno -2] Name or service not known [10:19] i see a lot "Ignoring indexes:" above the error [10:20] so this is probably the first point where it actually tries to download any indexes [10:20] hmm [10:20] ogra_: lp bug? [10:21] dunno, but surely something to ask cjwatson about :) [10:21] he has the deeper insight here :) [10:23] cjwatson: ^ my snap build fails in lp, it works fine in a clean lxd container I am running locally. [10:23] om26er: you have to do your network access in the pull phase, not build [10:24] the snapcraft.yaml looks like this: https://github.com/om26er/crossbar/blob/master/snapcraft.yaml [10:24] om26er: I know you're trying to, but it's clearly not complete [10:24] om26er: possibly due to setup_requires or similar that pip download isn't managing to follow [10:24] om26er: you can probably just manually add cffi to the download step [10:25] ogra_: ^ can you decrypt that on to how that may reflect in my snapcraft.yaml (still trying to get used to snapcraft :) [10:27] no, sorry, i'm not a big python guy beyond what comes from the archive (i have no biggger knowledge of pip) [10:28] om26er: "python-packages: cffi" probably [10:28] at least worth a go as a starting point [10:28] om26er: well strictly "python-packages: cffi>=1.1.0" [10:30] om26er: though you might possibly be better with "requirements: requirements.txt" instead [10:30] that would get the pinned requirements recommended by upstream in this case [10:32] ok let me try that. [10:55] cjwatson: seems that didn't help :/ same results https://launchpadlibrarian.net/289191346/buildlog_snap_ubuntu_xenial_amd64_crossbar_BUILDING.txt.gz [10:56] .yaml looks like this now https://github.com/om26er/crossbar/blob/master/snapcraft.yaml [10:57] note: I used requirements-in.txt file in the tree as requirements.txt has some hash verification so its fails like http://paste.ubuntu.com/23307635/ [11:00] a successful build (local lxd) looks like this http://paste.ubuntu.com/23307708/ === hikiko|ln is now known as hikiko [11:01] om26er: Yuck. Possibly wheel should be in the download phase due to this. [11:02] om26er: Adding "python-packages: cffi>=1.1.0" should work around it, then. [11:02] cjwatson: with removal of the requirements like ? or can that co-exist ? [11:02] om26er: It can coexist. [11:03] om26er: But I think there's a reasonable argument that this is a snapcraft bug: given that wheel may need to hit the network, it should be done in the pull phase. [11:06] om26er: i.e. something like http://paste.ubuntu.com/23307726/ (totally untested) [11:07] cjwatson: hmm wonder if there is a way to test that in lp :) [11:09] cjwatson, hmm, all my kernel snap rebuilds failed with a 403 error [11:10] that is: https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/6639 https://code.launchpad.net/~snappy-dev/+snap/dragonboard-kernel/+build/6641 https://code.launchpad.net/~snappy-dev/+snap/pc-kernel/+build/6638 and https://code.launchpad.net/~snappy-dev/+snap/pc-kernel/+build/6637 [11:18] cjwatson: btw that did work :) [11:19] So we need to fix that so that others don't hit that. [11:19] *in snapcraft [11:26] ogra_, if I have a ubuntu core device and it is bound to my launchpad account, may I know how I can make it work with another colleauge's launchpad on his computer? [11:27] ogra_, the idea is that he can login into the device witth his account instead of my account, which uses the ssh key in my computer. [11:29] i think the command that console-conf uses in teh backend is "snap create-user" [11:29] (not 100% sure though) === sjn__ is now known as sjn [11:30] ogra_, what is the correct syntax for using the command "snap create-user"? do I just need to supply the launchpad id? [11:30] ogra_: I don't have enough logging at the moment to be able to tell you exactly why that was. The possible causes are that the uploader hasn't signed the latest developer agreement in the store, that the uploader hasn't set a developer namespace in the store, or that the authorisation token isn't authorised for the correct package name. (You can rule out the last of those by going through ... [11:30] ... e.g. https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+authorize) [11:30] liuxg, i dont actually know ... doesnt snap help tell something about it ? (but i guess jst your mail address should suffice) [11:31] "snap create-user --help" says you give it an email address. [11:31] [create-user command arguments] [11:31] : An email of a user on login.ubuntu.com [11:31] cjwatson, well, thats weird, the uploader is indeed me :) [11:31] uh, oh [11:32] and i just notice that all the core builds failed to upload too ... [11:32] ogra_: I'm just telling you the possible causes. It will be one of those. I don't know which. [11:32] cjwatson, can we have mail notification for that ? i havent gotten a single mail [11:32] ogra_: bug please [11:32] will do [11:33] ogra_: there's supposed to be a mail notification, so must have missed a case [11:33] yeah, i get mails for other failures [11:34] right, BadUploadResponse doesn't have an associated notification [11:35] ogra_, thanks. I have not tried it yet. Maybe I will try it when I am with my colleague. I do not have his account info now. [11:37] ogra_: anyway apparently the 403s are a known SCA bug in production, being looked at now [11:37] sigh, this is insane ... i'll be clicking authorize stuff for the next hour or so, *all* aumoated snaps failed [11:37] ogra_: +authorize won't help [11:37] in this case [11:37] ouch [11:38] ogra_: once the SCA bug is fixed you should be able to retry the store upload from LP though [11:38] ok [11:39] yeah, even after authorize/re-upload i get 403's everywhere, confirmd [11:44] cjwatson, bug 1632299 [11:44] Bug #1632299: BadUploadResponse store reply in snap uploads should trigger email notification [11:44] what is "Initialize device" and why is it spamming my "snap changes" every 9 mins or so... http://termbin.com/rzoi ? [11:45] thanks [11:46] popey, by reading that paste i would say it is an Error :P [11:49] heh [11:50] ogra_: worthy of a bug report somewhere do you think? [11:50] yeah [11:50] ok, thanks for looking [11:50] i guess mvo or pedronis could help you further with that one [11:52] ok, bug filed. [11:53] Bug #1632305 opened: console-conf cannot be used twice [11:53] Bug #1632306 opened: 'snap changes' spammed with "Initialize device" [11:55] liuxg, hah ... looks like Bug #1632305 above has a trick you can use to create your second user ;) [11:55] Bug #1632305: console-conf cannot be used twice [11:55] ogra_, where is the trick? sorry, I missed it. [11:56] re-run "sudo console-conf" ;) [11:56] seems to work if you use a new user and just dont change the network settings [11:56] (according to that bug) [11:57] ogra_, do you mean run it after ssh into the device? [11:57] yes, as the bug says [11:57] popey: it means it's failing to register itself? is this with a canonical image? does it have network? [11:57] ogra_, OK. thanks. I will have a try. [11:59] ogra_, so, "sudo console-conf" is now working or not. according to the bug report, it does not work yet [11:59] it faisl if you re-use the same user [11:59] (thats the bug) [11:59] but thats not what you want [12:00] ogra_, oh, so, I can set it to another user. after that, I can switch back to my own, right? if this works, it should be fine for me. [12:00] right [12:01] ogra_, thanks. it is cool. by the way, does "snap create-user" do the same thing? it seems to be the correct command [12:02] console-conf calls it, ye [12:02] s [12:02] (as i said in the beginning) [12:02] popey: thanks for your bug on the init device issue, could you please attach the output of "change change 833" (or similra, one of the failing ones) [12:02] ogra_, ok. so, both ways work. thanks a lot [12:02] re-using console-conf is just cheap way [12:02] popey, btw, is that the device that switched back to stable unconditionally ? [12:03] ogra_, right. :) [12:03] popey, if so, that could indeed be related [12:03] (teh fw_setenv command i gave you is just a hack) [12:10] mvo: done [12:11] ogra_: uhm, not sure if it's that one, I have 3 [12:12] popey: did you reset you state at some point or something ? [12:12] not intentionally [12:13] see also bug 1631791 [12:13] Bug #1631791: Pi 2 on ubuntu-core 424 no longer able to do anything [12:13] ooh, i have another one doing the initialize device thing [12:14] that error mode is weird [12:16] also, bug 1632124 is on a pi 3 which is also doing the initialize device thing [12:16] Bug #1632124: snapd pegging cpu at 100% === cmars` is now known as cmars [12:38] popey: asked a couple more questions in the bug itself [12:39] pedronis: on it, painfully slow to get snap changes as the cpu is pegged by snapd [12:40] pedronis: ok, commented [12:42] popey: it's creating key after key and not finding them [12:42] apparently [12:44] * ogra_ notes that popey's image is still using ubuntu-core ... [12:44] (newer images use the "core" package instead) [12:45] interesting [12:45] Good morning all. Quick question -- should there be any delay from publish to availibilty in the store? I don't remember ever seeing a delay, but I'm hearing publication can take 12 hours or more sometimes [12:45] well, not that much, you would have to flash a newer image to get there ... but perhaps there is a bug in the code that handles both names ... [12:46] thats relatively new code [12:46] mmm, on a clean rpi2 clasic image as of today, doing snap install hello-world shouldn't install core instead of ubuntu-core? [12:46] I just did this and ubuntu-core was downloaded [12:46] oh, it doesn't migrate from ubuntu-core to core? I need to re-flash again? [12:46] popey, yes ... [12:47] ara: hey [12:47] :( [12:47] ara, i think thats only happening with the next snapd revision ... [12:47] (defaulting to install core) [12:48] mmm, classic on rpi2 fails to install ubuntu-core as well: https://pastebin.canonical.com/167549/ [12:49] hey zyga, how's korea? [12:49] popey: I'm quite baffled by what is going on on your pi2, seems like we write something and a second after we are not reading it [12:49] ara, wow, gross [12:49] it shouldnt try to handle any boot stuff on classic ever [12:50] ogra_, this is a clean server classic image, no dist-upgrade yet [12:50] probably that code isnt pi-safe :) [12:51] ogra_, do you want me to file a bug for this? if so, where? what logs? [12:51] ara, hmm, you should definitely dist-upgrade first to get the latest snapd [12:51] let me update snapd and see if that solves it [12:52] snapd, snap-confine and ubuntu-core-launcher [12:52] (orr just dist-upgrade) [12:52] * ara wonders if we should produce 16.04.1.1 images with the latest packages, as so much changed [12:52] snap-confine was not even installed yet on those images [12:53] well, 16.04.2 will have everything [12:53] right, but snapd will pull it in on dist-upgrade [12:53] iirc it was added as dependency [12:53] yes, it does [12:56] ara: hey, pretty and exotic [13:15] Bug #1631801 changed: snapd removes Exec lines from .desktop file on installation [13:16] So I need to write values to /sys/class/gpio/ is there a way to keep my snap confined and be able to do so ? [13:18] zyga: ^ [13:21] om26er: using the GPIO interface on a correctly set up core image (only gadget can expose those) [13:22] zyga: apart from those to be exposed, my main question is can I write to lets say /sys/class/gpio21/direction or /sys/class/gpio21/value ? Since that's what would make it be able to do it anything. Now I assume it will always require sudo ? [13:24] on another question what would it take to ensure they are exposed on a RaspberryPi ? Does the RPi gadget snap need to do that ? [13:25] or even is there a "gadget" snap for the Pi ? [13:25] om26er: yes, regular permissions will still be in the way [13:25] om26er: you'd have to write a service that can run as root to use them [13:28] zyga: curious where does this PR stand in all this https://github.com/snapcore/snapd/pull/2065 ? [13:28] PR snapd#2065: interfaces/builtin: use udev to export GPIOs to userspace [13:29] om26er: on hold [13:29] I was busy with roscon lately === josepht` is now known as josepht [13:34] Is there any problem with the store? [13:34] Currently it seems I can expose the GPIO by adding udev rule, not sure though If I can read/write values to from a confined snap, will test soon. [13:34] snap install classic doesn't work [13:34] vrruiz@localhost:~$ snap install hello-world [13:34] error: cannot install "hello-world": snap not found [13:35] WFM [13:35] rvr: Weird. What architecture? [13:35] qengho: arm64 [13:35] Ah hah. [13:35] I bet no one made an arm64 package for hello-world. [13:36] But that can be fixed in no time. ... [13:36] qengho: Ok, but I could run spread tests just one hour ago [13:36] and now it's giving me error with snap install classic [13:36] rvr: I don't know what that means. [13:36] qengho hello world is arch all I think [13:37] hello however isn't [13:37] too many hellos [13:37] ogra@localhost:~$ sudo snap install hello-world [13:37] hello-world (stable) 6.3 from 'canonical' installed [13:37] ogra@localhost:~$ [13:37] * ogra_ is just testing dragonboard arm64 here [13:37] not classic though [13:37] (do we actually have classic images yet ?) [13:38] speaking of classic, I don't see a yakkety classic RPi image anywhere. [13:39] ogra_: I guess so, because it was working this morning [13:39] om26er, ask foundations :) [13:39] or the server team [13:39] or whoever cares for classic these days [13:39] its boring, still uses linux 4.4 :p as linux-raspi2 was never updated in yakkety [13:39] ogra_ maybe there needs to be clarification on what classic, the enable-classic or a classic install on the rootfs [13:40] oh, crap, i mis-read rvr's line above [13:40] oh wait, 4.8 for RPi is now uploaded. [13:40] ogra@localhost:~$ sudo snap install classic --devmode --edge [13:40] classic (edge) 16.04 from 'canonical' installed [13:40] ogra@localhost:~$ [13:40] works fine here [13:40] rvr, ^^^ [13:41] + snap install --devmode --edge classic [13:41] error: cannot install "classic": snap not found [13:41] Hmm [13:42] your order is different [13:42] try turning it off and on again [13:42] ;) [13:42] lol [13:43] This is weird [13:43] vrruiz@localhost:~$ sudo snap install classic --devmode --edge [13:43] error: cannot install "classic": snap not found [13:53] Bug #1632336 opened: after first boot /var/lib/snapd/seed/snaps is empty [13:53] Bug #1632337 opened: dragonboard beta3 image reboots during snap create-user [14:00] popey, on the pi2/3 that get that weird device thing loop, what does "snap --version" say? [14:00] popey, i mean in bug 1632306 [14:00] Bug #1632306: 'snap changes' spammed with "Initialize device" [14:00] popey: what revision is your core snap on currently? we are looking at the device registraiton bug reight now [14:00] popey@localhost:~$ snap --version [14:00] snap 2.16+ppa37-1 [14:00] snapd 2.16+ppa37-1 [14:00] series 16 [14:00] on pi 2 [14:01] Chipaca: ^ [14:01] popey: revision from snap list please, that will also help us [14:01] popey, ta === jgrimm-out is now known as jgrimm [14:01] Chipaca: ppa37 sounds like beta3 [14:01] mvo, that's already in the bug :-) [14:01] popey: *cough* sorry! [14:01] Chipaca: autsch [14:01] yeah, i would, but running "snap list" takes aaaaaages [14:01] np [14:02] mvo, ubuntu-core 16.04.1 845 canonical - [14:02] ubuntu-core 16.04.1 845 canonical - [14:02] popey: aha, takes ages because snapd is so busy churning :/ [14:02] confirmed [14:02] it's variable, sometimes it is, sometimes not [14:03] my pi3 is churning, for sure. still not responsed to --version [14:03] popey@localhost:~$ snap --version [14:03] snap 2.16+ppa39-1 [14:03] snapd 2.16+ppa39-1 [14:03] series 16 [14:04] ^ from pi 3 [14:26] hello, where is right place to define snapweb should be included or not in a customized image? [14:29] hi I am just playing with snaps for the first time I have used the first example yaml to style what I want to do with my .jar. Unsuprisingly it does not work I was just looking if there is an easy reason? the yaml is at http://pastebin.com/69B0spML [14:43] PR snapd#2131 opened: tests add spread test for prepare-device customizing device init/registration [14:48] PR snapd#2132 opened: interfaces/builtin: enable out of process providers for locationd [14:58] ogra_, you around? [14:58] or maybe it's barry [14:58] ogra_, about resizing the image to its smallest, what filesystem is it? [14:58] ext4 [15:00] PR snapd#2133 opened: osutil: add missing unit tests for IsMounted [15:01] ogra_, any reason not to make it 4G and then resize2fs -M (and then truncate)? [15:02] Chipaca, yes, 4G takes 10.15min to dd, uses your diskspace pointlessly etc etc [15:02] *10-15 [15:02] ogra_, dd to where? [15:02] Chipaca, we already have a bug about this and agreement to implement it properly to only have the images as big as their content requires [15:02] Chipaca, to a device [15:03] Chipaca, that bug is why i'm so surprised that barry implemented "+50%" [15:03] hello ogra_, where is right place to define snapweb should be included or not in a customized image? [15:03] which is just nonsense [15:03] ogra_, but I mean resize2fs -M before dd'ing [15:04] Chipaca, you need the right partition size ... so you still have an image size that is to big and having the user run resize2fs as a step of a standard install is awful [15:04] we have this properly automated on first boot [15:04] there is really no need to add other fancy hackery here [15:04] we just need ubuntu-image to do the thing that was agreed [15:05] thomi: use 'architectures: [all]' [15:05] * jdstrand notes he is off today and just passing through [15:05] shuduo, in your ubuntu-image call when you build the image [15:06] shuduo, there might be some way in the gadget but i dont know how that exactly works [15:06] s/might/should/ [15:06] (never used it) [15:07] tyhicks: hey [15:07] tyhicks: can you review snap-confine change for me please [15:08] zyga: hey - I can only handle something small/quick right now [15:09] tyhicks: hmm, this is neither but it is very important [15:09] tyhicks: alternatively just pick it up tomorrow and review/finish it (if it requires any changes) [15:09] tyhicks: this is about /media sharing for GA [15:10] ogra_: hey [15:11] ogra_: I'm booting beta3 amd64 on vmware and ... I get "cannot find 'writable' partition", being dropped to initrd shell, can you help me debug this? [15:11] zyga: is there an open PR? [15:11] tyhicks: yes, two, let me give you the links [15:12] https://github.com/snapcore/snap-confine/pull/169 [15:12]