[00:15] Bug #1619245 changed: console-conf does not allow to create a user for offline devices [00:55] um why am i waiting for cloud-init to time out today [01:02] mhall119: popey still kicking? === chihchun_afk is now known as chihchun [02:56] Hello [06:05] PR snapcraft#865 opened: Add `init-plugin` [06:12] good morning [06:33] didrocks, davidcalle, do you think we could steal a bit of the playpen CI and document it so we can explain upstreams how to set up a build/publication run with CI in a doc somewhere? [06:34] ethercalc just merged my snapcraft.yaml and they seem interested [06:35] dholbach: sure, but it only produces amd64 snaps [06:35] dholbach: I'm going to go to a dark hole (recording some videos) [06:35] but we can discuss afterwards [06:36] didrocks, sure, let's chat later [06:42] PR snapd#2137 opened: tests: run ubuntu-core-upgrade on own machine === pbek_ is now known as pbek [07:59] PR snapd#2136 closed: tests/lib: prepare ubuntu-core with core from beta [08:04] where to find latest all-snap for RPi2 that is not 4gb in size ? [08:38] ogra_, morphis, slangasek: nplan is now in xenial-updates, including all NM and systemd fixes; so you should be able to drop these from the overlay PPA [08:38] (it also includes that NM naming hack) [08:40] does static ip + custom dns work now ? (I remember there was an issue with that) [09:08] pitti, YAY ! === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:38] ogra_: what's the best place to start to build a system image for an IoT device using snappy core? [09:39] dr1337_, what hardware ? [09:39] ogra_: ARMv7a [09:39] ogra_: BSP is kind of working at the moment [09:39] is it supported by a kernel we have ? (linke linux-generic) [09:39] ogra_: I'm using mainline at the moment [09:40] no patches ? [09:40] ogra_: 4.8.1 so I guess I could just merge the patches [09:40] ogra_: no patches [09:40] ok, so kernel side you might be able to just use the arhive kernel. that makes it easier [09:40] *archive [09:41] dr1337_, http://bazaar.launchpad.net/~ogra/+junk/linux-generic-bbb/files this is what i use to build the beaglebone kernel snap from the archive kernel deb [09:41] you mean this? - https://github.com/snapcore/sample-kernels/tree/master [09:42] you might need to switch it to yakkety somehow [09:43] once you have this done you need to create a proper bootloader setup ... we only support uboot and grub atm [09:43] ogra_ isn't xenial supported yet? [09:43] xenial doesnt have 4.8 debs [09:43] ogra_: I have uboot and kernel loading [09:43] right, you will need to make some adjustments to the build time config of uboot [09:44] ogra_: I actually have a rootfs running 16.04.1 core base [09:44] we load our environment from a binary blob file and only support raw kernel and initrd loading .... these three things need to be enabled in your uboot binary [09:45] then you need to create the binary blob from your default uboot env and add the snappy specific script and variables [09:46] once you have all this working, you wrap it together with image partitioning info into a gadget snap [09:46] ogra_ what's the binary blob file for? [09:46] could you point me in the direction of some documentation? [09:47] it is similar to uEnv.txt ... but since it has a fixed size you can not corrupt it easily when the filesystem underneath gets issues ... [09:47] not yet, i have to write some :) [09:48] ogra_ is that similar to a boot.scr file? [09:48] during the boot process both, uboot itself as well as the booted OS can write to the config ... if you use a uEnv.txt file on top of a fat system things can get shuffled around and at some point your file gets corrupt [09:49] no, it is an actually binary blob, imagine a raw partition for the config ... now take the content and put it into a img file ... that is more how it works [09:50] http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/ [09:50] that are our gadget snap source trees [09:51] http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/beagleblack/README explains how the binary blob gets created [09:51] and here is an example of the uboot config changes we use http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi3/uboot.patch [09:56] pitti: in netplan world how can I disable wireless power management, any pointers ? [09:56] om26er: that's outside of netplan or even NM; I suggest starting with powertop [09:57] that has toggles for everything, and also shows you which sysfs attribute to toggle [09:57] ogra_: thanks mate [09:57] (for scripting it) [09:57] dr1337_, i'll most likely do a series of blog posts soon and work with the doc team on a proper porting guide [09:57] just need to find some time :) [09:58] ogra_ would love to find out more - we have plans on putting ubuntu core on our "hub" for production [09:58] ... if I can get that running on a Pi [09:59] essentially it's a resurrected ninja sphere ;) [09:59] awesome ... ! [09:59] ogra_: a bit painful though - working with more exotic hardware this time [10:00] well, that shouldnt get in your way for doing a basic port [10:00] and since there is a beaglebone setup deriving from it shouldnt be to hard for your setup [10:01] ogra_ well I did spend a whole day banging my head against the table why i couldn't get a UART TTY working with a core rootfs [10:01] turns out it was missing udev [10:01] you mean a base rootfs ? [10:01] which is kind of understandable if you're running core fore cloud VMs [10:01] yeah [10:01] (core definitely has udev ;) ) [10:03] ogra_ not this guy - http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04-core-arm64.tar.gz [10:04] actually i meant this one - http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04-core-armhf.tar.gz [10:06] dr1337_, well, the core in there is wrong :) [10:06] (in the name i mean) [10:07] ogra_: erm....wtf? [10:07] http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04.1-base-armhf.tar.gz [10:07] the "core" named image is just for backwards compatibility ... technically the core name is now reserved for snappy [10:08] and the old "core" was completely renamed to "base" [10:08] ogra_: omg...if only i had known [10:08] and base is a way smaller packageset [10:09] (it is pretty much exactly what you get with "debootstrap --minbase") [10:10] ogra_ yeah makes sense now [10:17] pitti: I was able to disable wifi power management from classic environment on all-snap. (iwconfig, the friend :) [10:18] ogra_: it adds lxd group but lxd still does not start, AFAIK, lxd needs to be a system group [10:19] zyga: 'home' interface does not connect automatically when I install my snap, is that a bug ? [10:20] my snapcraft.yaml looks like this http://bazaar.launchpad.net/~om26er/+junk/crossbar-snap-pkg/revision/1 [10:20] network and network-bind connect automatically however. === om26er is now known as om26er1 === om26er1 is now known as om26er [10:34] om26er, so make it one [10:35] (the -r option to groupadd makes it one) [10:39] ogra_: how can I delete the previously added lxd group ? [10:40] om26er, hmm, i guess that only works manually [10:41] ogra_: know the filename/location ? [10:41] (remove it from /var/lib/extrausers/group and /var/lib/extrausers/gshadow) === hikiko is now known as hikiko|ln [11:44] Hello [11:45] Hi John. [11:47] Is anyone creating snaps, here? [11:53] PR snapcraft#863 closed: history/status alignment fixes [11:56] PR snapcraft#864 closed: Update documentation links to developer.ubuntu.com that now redirect … === hikiko|ln is now known as hikiko [13:04] sergiusens, ping [13:08] liuxg just ask the question ;-) [13:09] sergiusens, last time, I reported a bug regarding installing a local debian package. https://bugs.launchpad.net/snapcraft/+bug/1604669, it was fixed. My question is that how I can make use of it. is there any example for it? thanks [13:09] Bug #1604669: Support Installing a local deb package in the snapcraft [13:09] liuxg just do source: [13:10] sergiusens, what plugin should I use? [13:10] liuxg sources and plugins are orthogonal [13:11] liuxg but I guess if you just want to unpack, use dump [13:12] sergiusens, yes, I just want to install a local debian only. OK. I will have a try. thanks. so "orthogonal" should also work, right? [13:15] liuxg USE dump [13:15] sergiusens, many thanks [13:44] ogra_: hi, I've been trying to find out which part of the build process (using ubuntu-image and my own provided core snap I rebuilt with a PPA to inject a new cloud-init with some snappy changes for system-user assertion); injects the /etc/cloud/cloud-init.disabled into the system-data partition ... I didn't see anything in the core snap, nor in the pc.gadget or ubuntu-image tool ... [13:45] rharper, it is actually snap prepare-image i think ... it will create the file if it finds no cloud-init stuff inside the gadget ... then ubuntu-image just blindly copies /etc inot the img [13:46] so to have it not created you need to ship your cloud-init configuration in the gadget snap ... now ... i dont exactly know how the format has to be ... you have to ask someone from the snapd team .... mvo perhaps [13:46] ogra_: ok, is prepare image part of ubuntu-build ? a quick grep through mvo's git repo of ubuntu-build didn't hit any lines with cloud-init.disabled [13:47] prepare-image is a snap command ... "snap prepare-image" [13:47] ah [13:47] ubuntu-image just calls it [13:47] there's a whole lot of indirection here =) [13:47] yeah [13:47] * rharper goes to read snapd prepare-image code [13:47] rharper, https://github.com/snapcore/snapd/pull/2101 [13:47] PR snapd#2101: image: support gadget specific cloud.conf file [13:47] ogra_: thanks [13:47] that looks relevant [13:48] for deeper insight ask niemeyer or mvo [13:49] (i.e. i have no clue whats the expected format inside that file, where it lands on the filesystem etc etc) [13:49] right [13:50] * rharper goes to make his own gadget snap [13:50] snappidisnap [13:51] * ogra_ sticks his head back into wifiSD card code [13:52] PR snapd#2138 opened: many: removed frameworks target, and some leftover frameworks helpers… [14:12] pitti: hey, about #1580740, i see two problems. one is the fake xdg-open script can't be found by the script (which i think is a problem with the snap itself), the other is that nothing is pulling in snapd-xdg-open on the iso [14:12] Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link

[14:16] attente, i thought the first one was a snap-confine issue [14:19] ogra_: i think the problem is that we don't have the fake xdg-open script anywhere that the snap can find it [14:19] it should be in /usr/lical/bin inside of the ubuntu-core snap [14:19] *local [14:19] it's in the ubuntu-core snap no? [14:20] that dir is not in the path though [14:20] ogra_: seb128: i did a strace, but it doesn't find it at all [14:20] (or in future-speak ... in the core snap :) [14:20] attente, is the binary there on disk? [14:20] dunno if ubuntu-core got updated to have it [14:20] ogra@styx:~$ ls /snap/ubuntu-core/current/usr/local/bin/ [14:20] apt apt-cache apt-get no-apt xdg-open [14:20] it was outdated for a while, I had to change channel to get it [14:20] but that was like in august [14:21] it might be because that dir is not in PATH [14:21] so the telegram snap needs to add it to the path then? [14:21] it should be ... but to be sure you can indeed add it to PATH in your wrapper [14:21] dunno [14:22] but j_dstrand said it was weird to have in /usr/local anyway [14:22] attente what is the path? [14:22] we should probably just move it to /usr/bin [14:22] the path I need to add that is [14:22] seb128, tricky ... since the original lives there [14:22] yeah, that would be best seb128 [14:22] sergiusens: /snap/ubuntu-core/current/usr/local/bin [14:22] ogra_, but the original is not in the ubuntu-core snap [14:22] so on pd based systems you would have a clash [14:23] ogra_ welcome dpkg divert ;-) [14:23] i.e. it would require quite some dpkg-divert hackery if you want to use similar build scripts for both snaps [14:23] the other problem still exists too. nothing pulls in snapd-xdg-open on the iso and it isn't seeded [14:23] which is awful [14:23] attente, sergiusens, is that snap trying to call xdg-open directly? we have a .desktop that makes the mimetype association so gio functions should work [14:24] attente, right, snapd should probably recommends it? [14:24] but that's up to mvo I guess [14:24] attente, i think it was supposed to be merged into either snaapd or snap-confine [14:24] seb128 honestly have no idea; but I have seen direct calls in some other code [14:24] seb128: strace seems to show it looking for the xdg-open binary [14:24] k [14:24] the sepearate package was an interim afaik [14:24] well try the PATH thing [14:24] yeah [14:25] ogra@styx:~$ hello-world.env |grep ^PATH [14:25] PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/games [14:25] ogra@styx:~$ [14:25] yeah, not in PATH by default ... but i think the desktop launchers add it [14:25] is that snap using the desktop launcher? [14:26] (we could just stuff it into /usr/games instead of /usr/local :P ) === kallisti6 is now known as kallisti5 [15:05] created an updated pc gadget to include some cloud-init config, build the gadget snap, updated my model to use the new gadget, signed the model and now building, I get a prepare-image failure, http://paste.ubuntu.com/23313239/ [15:05] anyone ever debug a "ERROR:ubuntu-image:Crash in state machine" with prepare-image ? [15:14] rharper, well, it says it cant find your gadget snap [15:16] how can I donwload source of package (snapcraft.yaml, etc.) for a package that can be installed with snap install $SNAP? [15:18] PR snapd#2137 closed: tests: run ubuntu-core-upgrade on isolated machine [15:20] iliv, you ahve to ask the packager for it [15:20] *have [15:24] ogra_, okay, thanks! [15:32] ogra_: hrm, I thought the syntax for a local gadget snap was the name of the snap (without the .snap) extension? [15:33] in the assertion, yeah [15:33] right [15:35] ogra_: here's the model assertion I have http://paste.ubuntu.com/23313336/ [15:36] rharper, everything after the underscore is a version string ... drop it [15:36] you only want the name (pc) [15:37] ok, but the .snap file I pass via --extra-snaps is OK to include that string? or just rename it all ? [15:37] i think it doesnt matter [15:38] got it working now; thanks ! [15:38] :) [15:54] Hi! One of the projects that I am snapping reads /var/lib/dbus/machine-id, in strict mode it gives me permission denied, what's the remedy ? [15:55] om26er: presumably an interface to dbus / that file [16:01] PR snapd#2135 closed: cmd/snap: simplify auto-import mountinfo parsing === chihchun is now known as chihchun_afk [16:03] Bug #1632453 opened: snapd won't start on dragonboard [16:18] nacc: right, so it seems instead of permission denied, the issue is that it cannot find that file within its path. So as you say an interface might help here (not sure though what the solution would be). [16:18] http://paste.ubuntu.com/23313607/ [16:18] om26er: right, in the snap itself, i doubt that file exists [16:18] om26er: /var/lib/dbus may not exist either, possibly [16:19] om26er: you may want to look at adding a 'shell' application to drop to a shell in your snap's environment to debug [16:19] om26er: and then you could see if adding appropriate pacakge dependencies would fix it (i doubt it, as that's a runtime file) [16:19] om26er: by default, i don't think your snap has any dbus connection [16:20] narc om26er snap run --shell [16:20] sergiusens: ah cool, thanks! [16:20] narc ^ [16:20] sergiusens: i thought it might exist, but couldn't recall :) [16:20] darn. Double fail [16:20] heh [16:21] Autocorrect kills me with irc handles [16:22] nacc: sergiusens right, so whats the solution :) [16:23] om26er simple one is to make it not depend on /var/lib/dbus [16:23] om26er: i'm guessing either remove that dep, or add an interface that provides it to snaps [16:24] sergiusens: hmm, that's an upstream project that I don't control. [16:24] to be precise: https://github.com/crossbario/crossbar [16:25] om26er: it falls back though? [16:26] om26er: in the code, if it can't read machine-id, it falls back to socket.gethostname() [16:26] * sergiusens wonders why everyone is so afraid of forking [16:26] it is the BETTER patching afer all [16:27] "On Linux, it is universally available, given that " [16:27] sergiusens: snaps do violate some public blog posts :) [16:27] http://0pointer.de/blog/projects/ids.html [16:28] fwiw, that's the link in crossbar's source as to why they picked that file [16:28] nacc: not sure if it fallbacks, it rather just skips, so the config file ultimately does not have machine_id. I have seen multiple times that causing some kind of error from crossbar [16:28] adding the machine id manually fixes that, so its a bug [16:28] om26er: oh it might be that socket.gethostname() returns nothing? depends on where it's run, i guess [16:29] om26er: a bug in what? i'd say it's a bug in your snap :) [16:29] nacc I bet you can use /proc/self/sessionid [16:29] sergiusens: ack [16:29] it seems to be just an arbitrary string to uniquely identify the machine [16:29] nacc: yes, thats that I mean :) [16:30] om26er: so i'd fork and try with something that is available to snaps (just point to your github tree instead of upstream) -- probably can even do a PR to update upstream eventually? Or add an actual interface (if you want), but the latter is probably slower [16:31] nacc: any thing that requires changes upstream is a deal breaker IMO. So would try the slower path but I think there have been conversations on @snapcraft about accessing files from other system directories, so I'll keep a close eye on that. [16:32] om26er: why? you can fork trivially in github and build against your fork? [16:32] om26er I disagree about changing upstream [16:32] with that mind set nothing new would ever happen [16:34] nacc: I am working with upstream to get their package officially uploaded. this whole app-my_name scheme is what I am trying to avoid. [16:35] om26er: right, but it's not reasonable to say you can snap your application without any modifications [16:35] afaict [16:35] there are assumptions being made, such as this one assumign d-bus is present in the snap [16:35] *accessible perhaps [16:39] sergiusens: historically its been proved that not all upstreams feel excited to change their code to work with a specific project, so the status-quo does exist. Something that cannot be denied. [16:39] nacc: assumption based on suggestions from people working on systemd and pulseaudio and probably dbus. [16:40] om26er: yes, still an assumption [16:57] om26er the discussion for me is over as you are not even trying [16:57] sure [17:55] niemeyer, dude ! [18:05] * ogra_ goes offline [20:10] hi, is anyone familiar with an issue where running /snap/bin/ubuntu-image fails when calling snap prepare-image with a complaint about opening the model assertion with no such file or directory, but when I run snap prepare-image directly with the same arguments it works? === tedg_ is now known as tedg === mariogrip_ is now known as mariogrip === lazyPowe_ is now known as lazyPower [23:21] Bug #1632886 opened: [Feature Request] Per App Firewall Settings