[00:03] Chipaca: did you get anywhere with dhcp fun? [00:04] mwhudson, it's probably well past his EOD === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [02:04] cwayne: I think my issue was my wifi card [02:04] using a wire seems to be getting more success [02:12] built [02:12] but it is not intergating with Unity AppMenu [02:12] I did install with --devmode [02:22] nevermind you updated it [02:24] where is the vcs for ubuntu-core-config? [04:19] jdstrand: any info on LP: #1590679 [04:19] Bug #1590679: Apps can't own session bus names (unity7 interface)

[07:04] hey hey [07:06] good morning dholbach! [07:06] salut didrocks === hikiko is now known as hikiko|bbl [07:41] hi [07:53] kyrofa: This is QT5, yeah. I tried using the desktop/qt5 part, but I get a Python encoding error (for which a bug is already filed). [08:24] oh, mvo is back [08:24] mvo, hey :-) [08:31] good morning europe [08:33] hey seb128 [08:33] hey mwhudson, good morning! [08:33] hey mwhudson [08:33] mvo, howa re you? [08:34] seb128: thanks, good, how are you? a gazillon of mail and tasks :) [08:34] mvo, can you have a look to https://code.launchpad.net/~seb128/livecd-rootfs/snap-hooks-tweaks/+merge/301881 ? I think the duplicated < mvo, I'm good thanks :-) [08:35] seb128: nice catch, thank you! [08:35] mvo, yw! [08:36] mvo, do you have any idea when we are going to get an ubuntu-core update in the stable channel? the current version still doesn't have the xdg-open script [08:37] seb128: it is planed for this week, we are waiting for 2.11 in xenial-updates before we do the update but that is in propsoed now, so it can go to updates today or tomorrow and then we create a image with that [08:37] eh [08:37] a core snap :) [08:37] mvo, also I think your update-desktop-database fix doesn't work, did you test it? [08:38] oh, I didn't notice we had 2.11 landed in proposed [08:38] going to install and test [08:39] seb128: it does not work in what way? [08:39] but reading the commit I think it's not working, calling update-desktop-database without argument seems to not update /var/lib/snap/... [08:39] I think you need to call it with that dir as arg [08:39] at least if I do sudo update-desktop-database I don't get the cache generated [08:39] seb128: oh, hrm, ok. happy to fix that [08:40] I can do a PR if you want [08:40] let me install 2.11 and test [08:40] do I need to reboot to load the new version? [08:40] or can I systemctl restart somethin? [08:41] seb128: it should get restart ed automatically iirc [08:41] k, let's see [08:41] mvo, danke [08:41] seb128: its really only doing that, update-desktop-database, if it needs more, a PR is most welcome === chihchun_afk is now known as chihchun [09:09] Chipaca, ogra_: fwiw i installed a hacked snappy into an image and confirmed that nothing matches /sys/class/net/eth* when snap firstboot runs for me [09:10] lool: hey i just sent you a mail, i'll be around for the next 30 mins or so if by any chance you want to chat about it [09:10] mwhudson: seen it [09:10] mwhudson: did you want to chat about it? :) [09:10] lool: well only if your answer is something other than "everything you say sounds fantastic" :-) [09:11] mwhudson: from what I've read so far it is ;-) [09:13] lool: excellent === JanC is now known as Guest88920 === JanC_ is now known as JanC [09:45] lool: all good then? [09:45] oh heh you replied [09:47] mwhudson, well, like i said yesterday, i think that bit related to module loading [09:47] ogra_: probably [09:47] ogra_: i should file a bug and let someone who knows what they are doing tackle it i guess... [09:48] /sys is definitely there since the initrd ... but the subdir comes from the driver [09:49] mwhudson, do you see the module loaded at all on a failed boot ? [09:49] PR snapd#1620 opened: give a directory argument to update-desktop-database because the script [09:49] (i think kvm uses e1000) [09:49] mvo, ^ [09:49] ogra_: well "dhclient eth0" works fine once booted, so yes? [09:49] hmm [09:50] and i guess the dir exists too at the time you run dhclient [09:50] seb128: thanks, I have a look [09:50] ogra_: yeah [09:52] mvo, is replacing the /usr/lib/snapd/snapd binary enough for testing (and restarting the service)? [09:52] seb128: yes [09:53] Bug #1609322 opened: snap firstboot can run before /sys/class/net/ is populated [09:54] mvo, so hold on, seems not work at runtime, looking a bit more [09:56] ok [10:02] mwhudson, how did you find that /sys/class/net/eth* isnt there ? i assume you have some ls sprinkled over some start scripts ? if so, could you do the same with lsmod instead ? [10:02] so we see when the modules get loaded [10:02] ogra_: i added code to snapd/firstboot/firstboot.go [10:03] ogra_: i can try games with lsmod too (tomorrow) [10:03] cool ... (in case i get to it before you i'll note it on the bug) [10:07] mvo, is there a trick like compiled binaries or a cache or something? I don't understand my snapd log has a string which isn't in the binary even after being restarted [10:08] mvo, snapd[8273]: desktop.go:177: DEBUG: update-desktop-database successful [10:08] but [10:08] $ strings /usr/lib/snapd/snapd | grep successful [10:08] update-desktop-database successful on %s [10:10] I added the parameter for debugging but my code doesn't seem to be used?! === hikiko|bbl is now known as hikiko === chihchun is now known as chihchun_afk [10:19] mvo, can you share the kernel packages with me in the store ? [10:20] also u-d-f doesnt like the dragoboard gadget it seems [10:20] ogra@anubis:~/datengrab/images/snappy$ sudo ./ubuntu-device-flash core 16 --channel=edge --os=ubuntu-core --kernel=dragonboard-kernel --gadget=dragonboard -o test-dragon.img [10:20] cannot use "dragonboard", must be one of: ["canonical-i386" "pc" "canonical-pc" "canonical-pi2" "canonical-dragon" "beagleblack"] === chihchun_afk is now known as chihchun [10:23] hi, are zyga on vacation this week? [10:25] seb128: oh, it may restart itself from the core snap, SNAP_REEXEC=0 is the trick, easiest for testing is probably to follow the README.md (there is a subsection on testing) [10:25] ogra_: please check the latest u-d-f from the all-snaps/16 subdir [10:25] ogra_: what kernel packages are missing, happy to share them with you [10:26] ogra_: also, how can I get a serial console for the pi2? I get to starting kernel and then nothing, iirc you menitoned some dtb issues? [10:26] ogra_: this blocks me right now because I can not debug the early boot on my pi2 with the latest pi2 test image [10:27] ogra_: see also telegram, there are some fixes (and questions). sideload should work again [10:28] mvo, even after a reboot still the same, I don't understand what's going on... [10:28] I did string on the different binary on disk and they have the updated string [10:28] how can the debug output have the old one? [10:28] mvo, i dont have any access to the new -kernel ones only to the old canonical- ones [10:29] mvo, i can dig up a uboot.bin that has serial for you ... gimme a bit [10:30] seb128: its re-execing to ubuntu-core [10:30] seb128: its a "feature" but I can see that its confusing [10:31] ogra_: great, thank you [10:31] mvo, meaning? [10:31] ogra_: I add you to all the kernels now [10:31] mvo, what file/version do I need to update and how? [10:31] mvo, and if you want my attention on telegram, please ping directly, i dont get any access to super-groups from the ubuntu phone client (which is the only thing permananently on telegram i have) [10:31] seb128: there is a snapd in /snap/ubuntu-core/current/usr/lib/snapd/snapd which will be used if its there (and has a higher version) [10:31] oh [10:31] seb128: the easiest way to test your change is to follow the readme in the github repo [10:31] lol [10:31] mvo, thanks [10:31] seb128: it should be short and sweet (the testing section) [10:32] mvo, also, there is still a base package (from a failed and overzealous renaming attempt) in the store that needs unpublishing [10:32] seemes we have at least one bug where people installed it :P [10:32] ogra_: uff, I renamed it to base-delete-me [10:33] thanks :) [10:33] ogra_: hm, so you don't see anything in the group at all? meeh, good to know [10:33] we really need an easy way for package owners to wipe their packages in the store ... my packagelist is so full of unpublished crap now [10:34] ogra_: +100 [10:35] (and owning 60 click packages in the store really doesnt help to keep the overview ... everything is on one page) [10:35] mvo, k, going to teach me to read the README upfront next time ;-) [10:35] mvo, thanks! [10:35] mvo, change works btw, good to land ;-) [10:37] seb128: !!! thank you [10:37] yw! [10:50] PR snapd#1621 opened: store: fix buy method after some refactoring broke it [10:52] PR snapd#1553 closed: cmd: support defaulting to the user's preferred payment method [10:54] My snap is running in devmode but not confiened anyway to check whats stopping it? [10:55] Cavan: it will still log many messages if it tries to do too much. Check "dmesg" output. [10:56] Cavan: Then install in confined mode, and try to run it. When it crashes, you find out why. If there's a seccomp abortion, "scmp_sys_resolver NNN" on the signal number you see in the log. [10:56] Cavan: It's basically, "run it and see how it crashes." [11:00] quengho, do I literally type "dmesg" after trying to run the snap to trace the crash? Or in the directory? [11:17] mwhudson, I didn't do anything with dhcp (not looking into this atm) [11:17] mwhudson, did updating the before/after work in the end? [11:22] PR snapd#1622 opened: client, cmd/snap: use the new multi-refresh endpoint [11:30] I have a VPS I am using to build "in the cloud" and when I spin it up I only have a root account, no user. For speed, I just snapcraft as root. I know under normal circumstances "building as root" is ill advised, is that still the case with snapcraft, given confinement? [11:30] i.e. can I be lazy and build as root and be okay? [11:32] popey, the danger is that you mess up the host, from a snap POV it shouldnt matter if you run as root or not [11:32] i dont care about the host, i provisioned it just to build the snap [11:32] i thought so :) [11:32] and will destroy it afterwards :) [11:33] i.e. if you do a snapcraft build on LP it always runs as root [11:34] oh, well that's interesting data point :) === chihchun is now known as chihchun_afk [12:37] is launchpad timing out (when commenting on a bug) for anybody else, or does it hate me in particular? [12:38] PR snapd#1596 closed: osutil: support both "nobody" and "nogroup" for grpnam tests [12:39] PR snapd#1590 closed: interfaces: add process-control interface (LP: #1598225) [12:40] PR snapd#1589 closed: interfaces: miscelleneous policy updates for default, log-observe, mount-observe, opengl, pulseaudio, system-observe and unity7 [12:42] PR snapd#1562 closed: many: cleanup/update rest.md; improve auth errors [12:43] PR snapd#1586 closed: wrappers: set BAMF_DESKTOP_FILE_HINT for unity [12:43] PR snapd#1602 closed: interfaces: add kernel-module interface for module insertion [12:44] PR snapd#1620 closed: give a directory argument to update-desktop-database because the script [12:46] PR snapd#1570 closed: snapstate: remove artifacts from a snap try dir that vanished [12:50] PR snapd#1565 closed: interfaces: also allow rfkill in network_control [12:51] PR snapd#1566 closed: interfaces/builtin: read perms for network devices in network-observe === chihchun_afk is now known as chihchun [13:33] is snappy giving access to the dbus session bus by default? [13:33] or is there an interface needed for that? (which one?) [13:39] seb128, I think parts of it, depending on interfaces used (e.g. unity7) [13:40] kyrofa, that user on the list gets a "Failed to open connection to "session" message bus: Failed to connect to socket /tmp/dbus-OQWDAcdbVG: Permission denied " [13:40] I wonder if that's just a missing interface, he doesn't use any [13:40] but also unsure which one to recommend [13:40] unity7 is not very restrictive and not needed there [13:41] seb128, indeed. Hold on, the mailing lists changed again so my filters are garbage. I'm redoing them now then I can see what you're talking about [13:43] seb128, ah, the xdg one? [13:44] yes [13:44] seb128, xgd-open is used for links, right? Click a link within the snap, want firefox to open? [13:45] correct [13:45] but the dbus question is orthogonal [13:45] he did a minimal part to test [13:45] kyrofa, but yeah, basically the command he uses does "dbus-send --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"$1" " [13:45] Indeed, just making sure I'm clear on what's happening here [13:46] and he got an access denied to the session bus [13:46] Yeah I don't think there are any interfaces which grant generic access to the session bus [13:47] k, I replied suggesting that he tries unity7 [13:47] thanks [13:49] Yeah that should definitely cover it. However, does the SRU of xdg-open solve this issue for him? He'd still need that interface, no? [13:49] seb128, also, while I understand he was just testing it out, would xdg-open ever be utilized from a non-gui application? [13:50] yes [13:50] it's a shell script and is used in random places [13:50] including small sysadmin scripts and command lines tools [13:50] Can you give me an example? I wonder if we need a simpler interface that includes it [13:52] kyrofa, http://sources.debian.net/src/mc/3:4.8.17-1/misc/ext.d/image.sh/?hl=9#L9 [13:52] kyrofa, from a random search on codesearch.debian.net [13:52] Huh, interesting [13:53] debian reportbug is in the list [13:54] kyrofa, http://sources.debian.net/src/lptools/0.2.0-2/bin/lp-review-notifier/?hl=160#L160 [13:54] mvo, what do you think about that? Should we be recommending cli applications that utilize xdg-open to use the unity7 interface, or would it be better to have a more fine-grained interface? [13:55] (I ask you since you were the last person I talked to about xdg-open, but jdstrand may be better) [13:56] could make sense to have an "url-handler" interface [13:56] xdg-open does mailto: also [13:56] I am trying to snap python project and I need to get config.yml from the source repo to parts//install (python setup tools don't put it there). How can it be done? I can add filesets in "stage" and "snap" but not "build" phases [13:58] jacekn: organise? [13:58] Spads: explain? [13:59] jacekn: it's a stanza that lets you shuffle file locations around, but it may be the wrong part of the process for this [14:00] http://snapcraft.io/docs/build-snaps/parts [14:00] there's filesets and organize(sic) [14:01] Spads: I'l have a look but it's not that simple. The file is in the source dir but setuptools don't copy it to parts//install [14:01] right [14:01] and really this is a problem I've had a few times [14:01] where the install step wasn't fully automated [14:02] Spads, if the build system doesn't install it really the only way to do it is to have another part that uses the copy plugin and the same source and places the config where it needs to go [14:02] and I could set up a second part to go through the whole build process a second time [14:02] which seems pointless [14:02] when really what we usually need is "build system X, plus a copy" [14:05] Spads, something like this: http://pastebin.ubuntu.com/22031026/ [14:05] kyrofa: ok that will work for me I think. It's suboptimal but will do the job [14:06] kyrofa: jdstrand is probably better [14:06] yeah [14:06] * jacekn thinks "ship that sample config file with my build" will be pretty common use case [14:06] The other common use case I'm still trying to work out is the "copy this example config file to $SNAP_USER_DATA before first run" [14:06] jacekn, indeed, which is why build systems typically take care of that [14:07] kyrofa: how safe is xdg-open? I mean, if everything is expected to be able to use it and it is safe, could just add it to the default template [14:07] jacekn: so one of the things about snappy is that the real goal is to get upstreams to adopt it, so if we can add that file to the build system and get the snapcraft.yaml merged in, that's better [14:07] jdstrand, seb128 or attente can probably answer that better than me [14:08] Spads: kyrofa: ok thanks, I'll use the workaround and try to improve upstream [14:09] jdstrand, but it causes browsers or mailers to open... so off the cuff I'd say that doesn't sound like a great thing for everything to have blanket access to [14:10] kyrofa, seb128: there is also the question of if xdg-open is in all snaps images [14:10] Indeed, good question [14:10] PR snapd#1621 closed: store: fix buy method after some refactoring broke it [14:10] jdstrand, kyrofa, we need to MIR it so I guess it's going to go through a security review, but it's basically an hundred line of C and small service getting on the bus and calling g_app_info_launch_default_for_uri() on the uri you gave to it [14:10] kyrofa: well, that is the safety question. the one on touch was safe and we had it in the default policy [14:11] jdstrand, kyrofa, the script in the ubuntu-core image is just calling "dbus-send --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"$1"" [14:11] then the small service is on the system side [14:12] which get the message and call the glib function to open the uri provided in the default handler [14:12] if it makes sense for all snaps and iot, I would suggest adding it to the default template. if it does not, I think I would suggest adding a new interface: 'url-handle' (not 'handler') [14:13] if someone submits a PR, then the interfaces team can discuss [14:13] k [14:13] unsure if it makes sense for iot [14:14] but it's used by sysadmin in scripts and in command line tools [14:14] if it can be used in a cli environment, then it might make sense. if not, I would say no [14:15] it can, it only calls to your default handler [14:15] that could be links [14:16] PR snapd#1612 closed: interfaces: add /proc/version_signature to appamor template [14:16] PR snapd#1617 closed: many: move to purely hash based key lookup and to new key/signature format (v1) [14:16] I suggest submitting a PR with it in the default template then (that will be easier to implement), then if the fuller interfaces team wants it in a separate interface, then moving it out is easy [14:19] PR snapd#1611 closed: tests: add locale-control write spread test [14:27] PR snapd#1607 closed: changed snapd to snap [14:29] PR snapd#1608 closed: tests: add snapd-control interface spread test [14:30] PR snapd#1601 closed: partition: clear snap_try_{kernel,core} on success [14:30] PR snapcraft#708 opened: Add support for use of pip constraints === chihchun is now known as chihchun_afk [14:44] jdstrand, thanks, going to do that [14:46] PR snapd#1623 opened: interfaces: udev: avoid doubled rules and put all in a per snap file [14:46] zyga: ^^ [14:46] zyga: took the time and implemented that now [14:47] joc_: ^^ [15:02] jdstrand: hey for https://github.com/snapcore/snapd/pull/1618, adding this to the hardware-observe seems fine [15:02] PR snapd#1618: interfaces: add lscpu to apparmor template [15:03] jdstrand: for https://github.com/snapcore/snapd/pull/1612 is there an existing interface i should add that to? [15:03] PR snapd#1612: interfaces: add /proc/version_signature to appamor template [15:06] arges: ./interfaces/apparmor/template.go has a typo using @{PROC}/@{pid}/version_signature and @{PROC}/@{pid}/version. clearly, no one has complained about the currect path in the default template, so how about remove from there and add to system-observe? [15:07] I commented in the 1612 PR [15:07] jdstrand: i was wondering about that extra @{pid} in the path! [15:07] I half suspect it was a java app that was looking in the wrong place [15:08] jdstrand: ack I can do that, and I'll just submit them as three separate patches into one pull-request [15:08] arges: sounds great [15:08] arges: feel free to ping me [15:08] mvo, if you have some review slots still, https://code.launchpad.net/~seb128/livecd-rootfs/snap-xdg-defaults/+merge/301917 ... that's creating a .desktop/mimetype registration so clicking on http/mailto/help urls in gnome software know what handle to use [15:19] Hi. I was wondering, are there any plans to make snapd also available to older Ubuntu versions. Like 14.04 LTS or is this technically not possible? [15:20] PR snapd#1624 opened: Use `cp -aLv` instead of `cp -a` (no symlinks on vfat) [15:22] imexil, not as long as there is a systemd requirement [15:23] PR snapd#1610 closed: store: soft-refresh discharge macaroon from store when required [15:23] ogra_: OK === Guest69044 is now known as ahoneybun [15:37] seb128: oh, nice! thank you [15:38] mvo, yw! [15:48] PR snapcraft#618 closed: parser - Support .snapcraft.yaml files [15:49] any snappy folks around? [15:51] PR snapcraft#662 closed: Update the Standards-Versions and the Vcs* tags in the debian/control file [15:53] PR snapd#1625 opened: asserts: make account-key's `until` optional to represent a never-expiring key [16:00] PR snapcraft#688 closed: Strip common path prefixes from linkname as well as name when extracting a tarfile [16:03] \o/ [16:14] PR snapd#1624 closed: boot: use `cp -aLv` instead of `cp -a` (no symlinks on vfat) === JanC is now known as Guest94529 === JanC_ is now known as JanC [16:40] I can run my snap in devmode, but when confined im getting "[28234.099513] audit: type=1400 audit(1470242246.729:353): apparmor="DENIED" operation="exec" profile="snap.zeppelin.zeppelin" name="/usr/bin/nohup" pid=21467 comm="zeppelin-daemon" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0" through 'dmesg' [16:40] Cavan: does it need unity7? [16:40] some programs hit dbus walls just trying to tell the unity dock they're there and have an icon etc [16:40] I found adding the unity7 plug helped there [16:40] oh it's a daemon [16:41] as you were! [16:42] Spads, aha thanks anyway! [16:45] PR snapcraft#669 closed: Add detection for an existing `.snapcraft.yaml` file before running `snapcraft init` [16:47] At the sprint last week, oneshots were mentioned as being supported; snapcraft rejects "daemon: oneshot". Is there something else I should be doing? [16:47] Cavan: that came up yesterday. please file a bug at https://bugs.launchpad.net/snappy/+filebug and add the 'snapd-interface' tag and we'll allow calling nohup [16:51] Odd_Bloke in is in master, no as a deb yet [16:51] *not [16:51] sergiusens: OK, cool, so long as I'm not remembering things that aren't true. :p [16:52] jdstrand, is there anything I can do in the meantime to make it work? [16:52] Odd_Bloke in case you want to git clone and just run from master https://github.com/snapcore/snapcraft/blob/master/HACKING.md#project-layout [16:53] just use the snapcraft in that bin [16:53] and yes, it was added for lxd [16:53] now adding timers and socket activation [16:53] Cool! [16:53] I'll probably have a few more (non-lxd) things incoming at some point.# [17:02] We build Ubuntu cloud images using a chroot. This chroot (obviously) does not have snapd running in it, which means that running 'chroot foo snap install ...' produces a "dial unix /run/snapd.socket: connect: no such file or directory" error. How can we go about installing snaps within a chroot? [17:03] slangasek: Have you done any relevant thinking around this for doing things in livecd-rootfs/buildds? [17:04] jdstrand, is there anything I can do in the meantime to make it work? (Sorry if I already sent this I disconnected) [17:06] Odd_Bloke preinstall snaps instead of fetching/caching them? [17:06]