[00:45] Is there a method for system services to own (system) D-Bus names or is this the same problem as for sessions? i.e. bug 1590679 [00:45] Bug #1590679: Apps can't own session bus names (unity7 interface)

[02:13] PR snapcraft#927 closed: Add a test script to build external snaps [03:12] Bug #1645961 opened: Snapd generates a wrong udev rule for i2c devices === chihchun_afk is now known as chihchun [06:40] Bug #1627175 changed: RPi3 with only HDMI attached never shows subiquity [06:43] Bug #1626121 changed: strict mode snaps crash with Segmentation fault on 16.10

[07:10] Bug #1624676 changed: ERROR cannot remove snap file "kicad-dev-snap", will retry in 3 mins: umount: /snap/kicad-dev-snap/x6: mountpoint not found [07:16] Bug #1623897 changed: console-conf should show if wired interfaces are connected [07:16] Bug #1624329 changed: snapd firstboot setup fails constantly when rebooting before console-conf has finished [07:25] Bug #1628193 changed: please set TMPDIR=/tmp when launching snaps

[07:25] Bug #1628289 changed: snapd should depend on squashfuse (for use in containers)

[07:28] Bug #1628357 changed: A deamon fails with: No home directory found [07:28] Bug #1628559 changed: Can't install more than 1 package in one command [07:28] Bug #1628640 changed: Add 'snap info' command showing publisher, channel map [07:29] bonjello [07:31] Bug #1630036 changed: auto import of assertions fails for devices present at boot [07:38] Bug #1630520 changed: snap login error message incorrect [07:38] Bug #1630586 changed: Pi3 kernel crash and is unreliable

[07:38] Bug #1630652 changed: snap revert and refresh forwards and backwards causes breakage [07:41] Bug #1631159 changed: No way to simply list available snaps via snapd [07:44] Bug #1632305 changed: console-conf cannot be used twice [07:52] hey hey [07:53] Bug #1632336 changed: after first boot /var/lib/snapd/seed/snaps is empty [07:53] Bug #1632337 changed: dragonboard beta3 image reboots during snap create-user [07:59] Bug #1634089 changed: Cannot activate Chinese input method for Qt app [08:01] hey dholbach! [08:02] salut seb128 [08:02] Bug # changed: 1634730, 1634775, 1634822, 1634880 [08:03] that bot should tell what the bugs are, giving random numbers as changed is not that useful [08:04] bingo! [08:04] seb128: no no, it can be useful :) [08:04] PR snapd#2379 opened: snap: remove unused experimental command [08:05] Bug #1634909 changed: Disabling pc||pc-kernel||core should give a warning message [08:08] PR snapd#2380 opened: debian: add missing ca-certificates dependency [08:08] woodrowshen, hi, I saw you created an alsa-utils package, where could I find the sources? [08:10] abeato: oh, https://github.com/woodrow-shen/snapcraft-alsa-utils/blob/master/snapcraft.yaml [08:10] woodrowshen, awesome, thanks [08:10] abeato: i didn't use interface yet [08:11] woodrowshen, so this for installing with --devmode? [08:11] abeato: yes [08:11] oh, I see [08:14] So anyone can point me to someone who might be able to help me fix the "Key registration failed: The account-key-request assertion is not valid." - i am not able to register-key any key with snapcraft and my account :/ [08:20] Are snappy updates being backported to Trusty? I'm interested in some 2.18 fixes in Trusty and Xenial. [08:25] PR snapd#2381 opened: image: drop support for UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL [08:29] Bug # changed: 1636023, 1636383, 1636419, 1636421 [08:35] Bug #1636764 changed: Snapd is not correctly initialized with UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 and model assertion is invalid [08:38] Bug #1636864 changed: ubuntu-image 0.10+real1 requires sudo [08:38] Bug #1636894 changed: [raspberry pi3]pi3 snap is removable [08:41] Bug #1637981 changed: failed snap refresh removes security profiles [08:44] Bug #1638656 changed: snapd testsuite fails when run inside an lxd container [08:44] Bug #1638798 changed: mir server process goes defunct when a mir client attaches under confinement [08:47] Bug #1639234 changed: docs/rest has not url for install (refresh, revert, remove) example [08:50] Bug #1639614 changed: Sandbox denials with snap using thumbnailer [08:54] stub: I expect trusty will get backports, considering new interfaces that's pretty much required anyway to run all (new) snaps in the long term [08:54] I'm not sure, though, if that's documented somewhere [08:54] Or in what cadence [08:58] PR snapd#2382 opened: snap: Improve `snap --help` output as designed by Mark [09:13] woodrowshen, how did you test the alsa snap? I'm trying with a kvm machine using "-soundhw hda", and I get these errors when using aplay: http://paste.ubuntu.com/23557271/ [09:16] PR snapd#2383 opened: interfaces/builtin: fix incorrect udev rule in i2c [09:19] PR snapd#2215 closed: tests: spread system user autoimport [09:25] abeato: oh, yes, it seems to have /usr/share/alsa/alsa.conf [09:25] abeato: from libasound2-data [09:26] abeato: for early stage, i hacked os snap to workaround it ... [09:26] woodrowshen, you copied the alsa.conf file around, isn't it? [09:27] abeato: right [09:27] noted, thanks [09:27] PR snapd#2384 opened: snap: add snap size, description and provided apps to `snap info` [09:27] abeato: np [09:48] Hey! When running snap prepare-image (through ubuntu-image) I get a sha3-384 mismatch when downloading core [09:48] Yesterday it worked fine, although then I was getting a similar mismatch when downloading pc-kernel IIRC [09:49] Is this a known problem? [09:49] error: sha3-384 mismatch downloading core: got 4ebcade07da9a4d1dfc822efdb300997fd17f5fdd3e91fd0036bb1479fba2ff586cd672b04933d396b2734c57f949c30 but expected 536b4e3795ae66f1962567ce6f129eb979d08054aed874c40772c39b30222dd535e8739769af0e81e794b2136e05adbe [09:49] PR snapd#2385 opened: daemon, strutil: move daemon.quotedNames to strutil.Quoted [09:53] I'm using snapd 2.17.1 [09:55] sil2100: no, can you please report it! [09:55] On it! [09:56] sil2100: anything in syslog that indicates that there was some retry or something? [10:00] PR snapd#2346 closed: Misc libvirt fixes [10:01] PR snapd#2276 closed: Add openvswitch-support interface [10:02] mvo: nothing, but actually after trying now hm, both core and pc-kernel went fine through [10:02] sil2100, do you use the canonical VPN ? (due to the recent router attacks mine died a few times since monday without notice) [10:02] I remember trying to run the same command at least 4 times yesterday and getting mismatches for pc-kernel [10:02] While now it just succeeded after a re-run [10:02] Strange [10:04] Anyway, seems like a false alarm, sorry for the noise [10:06] hmm, i'm getting a lot of 504 errors on launchpad [10:06] seems you are not alone [10:07] err, from the store, sorry ... [10:07] PR snapd#2386 opened: interfaces/builtin: fix incorrect udev rule in i2c [10:08] ogra_: hey ogra, how are you [10:08] ogra_: I did some of the things we talked about, please have a look at github.com/snapcore now [10:08] ogra_: I've done the lauchpad project for pi2 so far (snap-pi2), I'll make the rest next [10:08] zyga, trying to find out why core failed to upload tonights builds :P [10:08] ogra_: pi2 is set so that each commit that lands on master gets pushed to the store [10:09] ogra_: I'll patch all the gadgets to have a skeleton snapcraft.yaml with dump plugin [10:09] zyga, hmm, i thought you would create a master project for that under snapcore [10:09] like snapcore/gadgets/$arch [10:10] alternatively probably putting "gadget-" in the branch name might make sense [10:11] they kind of vanish in the amount of stuff thats already there [10:11] (and i guess that will become more) [10:12] also, while we're moving we should probably also drop "generic-" from the x86 arches [10:12] in the store they are called pc or pc-i386 [10:15] ogra_: on github there are no projects, jsut repositories [10:16] ogra_: in the store both pc gadgets are just called "pc" [10:16] ogra_: once we build more from source we can unify them and drop one [10:16] ogra_: but now we cannot since we need two snapcraft.yaml's that are different [10:16] ogra_: in the end we'll get only four gadgets, pc, pi2, pi3 and dragonboard [10:16] ogra_: but now the pc one has two repos because that's how we need to do it === ubott2 is now known as ubottu [10:21] zyga, i'm not talking about merging them but making them better discoverable in the amount of projects there [10:21] s/projects/branches/ [10:21] and about dropping the "generic" [10:22] " alternatively probably putting "gadget-" in the branch name might make sense" [10:22] i find them hard to discover already and there are not many branches under snapcore yet ... in a year that will have doubled [10:23] ogra_: I wanted to match the snap name, we can do that gadget- prefix later (once slangasek owns those, it's just a rename button) [10:23] ogra_: note: those are repos, not branches [10:23] ok [10:23] "things" [10:23] :P [10:23] ogra_: we don't want to add all the gadgets there, just the ones that we support [10:23] yes [10:23] ogra_: and snap-confine will go away so we'll have less things there [10:24] ogra_: note that you won't see branches, this is essential, you won't see 12s of forks and branches from other people [10:24] yes, i have used github before :) === zbenjamin_ is now known as zbenjamin [10:26] ogra_: sorry, I was just trying to explain how this might look like [10:26] yeah, no worries :) [10:26] ogra_: ok, now for the publishing pipeline [10:26] PR snapd#2385 closed: daemon, strutil: move daemon.quotedNames to strutil.Quoted [10:27] tyhicks, jdstrand: could you please review https://github.com/snapcore/snap-confine/pull/189/files -- it is the next one in the apparmor support series, (I've merged it after improvements suggestef by tyler) [10:27] PR snap-confine#189: Use apparmor-support module [10:36] mvo, danm ! [10:36] *damn even [10:36] ogra_: hu? [10:36] mvo, i'll have to revert your change to bug 1639878 [10:36] Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v [10:36] ogra_: why? [10:37] i'm in the middle if re-working pre-arch modules [10:37] *per [10:37] because our initrd gets to big [10:37] we really dont want the virt stuff on arm [10:37] ogra_: I don't see this module on arm [10:38] on which arm do you look ? :) [10:38] (the generic kernel has it) [10:38] ogra_: pi2, the only one I have [10:38] right, there we dont build it [10:39] anyway, i'm already working on a fix and should have it ready later today [10:39] (there are a bunch of others like virtio that need to go) [10:39] ogra_: *shurg* its 28kb (the hv_storsvc) and 96kb (the hv_vmbus). but yeah, go ahead if thats too big [10:40] its not about to big but about loading them forcefully ... check lsmod on your rpi [10:40] they eat ram [10:41] ogra_: we are loading them forcefully? that sounds not ideal, why is that? [10:41] (we use MODULE=list in the initrd) [10:41] to keep the number small, thats the only way, all others load a lot of default stuff we dont need and thats megabytes [10:42] ogra_: I get "no such device" when trying to load it here on my machine, so it seems like it will not get loading if not in a hv env? [10:42] ogra_: I don't disagree to fix all that, don't get me wrong [10:43] ogra_: this upload was a drive-by from bug triage and it was less work to fix it than to write the comment about the status etc. and AFAICT it does not harm you in any way, the rework will just superseed it, or am I missing something? [10:43] mvo, indeed [10:44] mvo, on another note ... how about we get rid of /etc/system-image and move writable-paths one level up for one of the next releases ? [10:44] we dont ship the package anymore and the path is an anachronism [10:44] PR snapd#2342 closed: client: use typed snap.ConfinementType [10:45] ogra_: that makes sense, yes, its slight ugly as it is right now [10:45] yup [10:45] PR snapd#2387 opened: asserts: introduce top-commands header in snap-declaration [10:46] not really high prio but it makes me itch every time i have to touch it [10:47] +1 [11:00] ogra_, mvo: https://github.com/snapcore/pi2/pull/1 [11:00] PR pi2#1: Improve the README file === sil2100_ is now known as sil2100 [11:01] zyga, perhaps we should have a "BUILDING" file for the old content [11:02] (which could also point to sources etc and have some more info on where the binaries come from( [11:04] ogra_: for the mkvenvimage line? [11:04] yeah, it is highly important for oporters to know about it [11:04] ogra_: can you propose that please? I'm sure you'd be more accurate than I am [11:04] *porters [11:05] ogra_: let's land this branch and iterate [11:05] though ... [11:05] ogra_: I'll make the snapcraft.yaml with dump plugin now [11:05] we could switch to the make plugin and simply automate it i guess [11:05] ogra_: :D [11:05] ogra_: I'll do the naive dump plugin [11:05] ogra_: and let you improve, ok? [11:05] yeah, start with that [11:05] ok! [11:05] :D [11:15] PR snapd#2373 closed: debian: remove unneeded conflict against the "snappy" package [11:22] hi all, I am using the jdk plugin but I need the headers how do I do this? [11:22] PR snapd#2379 closed: snap: remove unused experimental command [11:23] ogra_, mvo, slangasek: https://github.com/snapcore/pi2/pull/2 [11:23] PR pi2#2: Add naive snapcraft.yaml [11:23] sergiusens: ^^ [11:24] sergiusens: I found a bug in snapcraft, I think, building that with snapcraft twice results in an odd error message about meta/gadget.yam [11:24] zyga, why didnt you keep the boot-assets" name [11:24] ogra_: I did, it's a subdirectory there [11:24] oh, sorry === sil2100_ is now known as sil2100 [11:24] ogra_: I didn't try booting with that [11:25] ogra_: but the prime/ directory looks identical to the old tree, except for meta/gui/icon.png [11:27] well, as long as the bits land in boot-assets later all is fine [11:28] zyga we deal with bugs through bug reports if you are so sure of it ;-) [11:30] ogra_: can you review it please then [11:30] sergiusens: let me file it quickly :) [11:32] sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1646081 [11:32] Bug #1646081: Gadget snap cannot be built twice [11:34] sergiusens: does that look sensible? [11:34] sergiusens: I found this on the following pull request: https://github.com/snapcore/pi2/pull/2 [11:34] PR pi2#2: Add naive snapcraft.yaml === chihchun is now known as chihchun_afk [11:34] sergiusens: and btw, since you are here, where should the icon be? am I doing the right thing with setup/gui/icon.png? [11:36] ogra_: I'm waiting for your comment there, if you +1 it we can land it :) [11:37] ogra_: thanks! merged [11:37] ogra_: so now about that makefile part [11:37] ogra_: do you think we should also copy the licenses? [11:38] dont we do that ? yes, we should [11:38] like they are upstream [11:40] zyga yes, but you can use the dedeprecated `icon` entry to get rid of `setup` [11:40] ogra_: ok, let me fix that [11:41] sergiusens: how can I read about filesets or organize help? [11:41] sergiusens: how can I cope three license files from the root of the project, I tried the copy and dump plugins but my attempts didn't work [11:42] ah [11:42] sorry, there's a typo in the tree itself :) [11:44] ogra_, sergiusens: https://github.com/snapcore/pi2/pull/3 [11:44] PR pi2#3: Copy licenses to the snap [11:44] ogra_: shall I correct the LICENSE vs LICENCE typo? [11:45] zyga, well, thats also from upstream :) [11:45] is it possible to just point to a deb url in a snapcraft yaml? [11:45] however you feel like ;) [11:45] to pull in a pre-built deb and unpack it? [11:45] ogra_: ok, I'll leave it as-is then [11:47] popey, https://github.com/ogra1/laidout is one way [11:47] (see the Makefile) [11:48] ta [11:48] oh [11:48] that's icky, can we not just source: foo.deb ? [11:48] well, it is old ... perhaps we can now :) [11:48] ok [11:48] :) [11:48] thats a sergiusens question [11:49] Bug #1646085 opened: snapd-interface access to /usr/bin/infocmp denied [11:49] what I really want is access to a 3rd party archive in a cleanbuild [11:49] hi when I run snappy-debug and run my app with sudo I get "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" can anybody tell me how to do this? [11:52] ogra_: https://github.com/snapcore/pi2/pull/4 [11:52] PR pi2#4: Add URL to launchpad build history [11:52] gerry_: it probably means that the appliaction tries to touch files that are not owned by root but the process dones't have CAP_DAC_OVERRIDE which typical root processes have [11:53] gerry_: if you use sudo you'd have to make those files root owned (probaly something in ~/snap/$SNAP_NAME but I may be wrong) [11:58] zyga: thank you for your help the app works when I run it without sudo it crashes when I use sudo with an exception [11:58] do you need to run it with sudo? [11:59] ogra_: I just requested a manual build [11:59] ogra_: if all goes well it will end up in edge :) [11:59] ogra_: and if not we can work with mvo on store side permission [11:59] yes because when I upload it to the ubuntu store it does not get loaded into software [11:59] gerry_: what do you mean by "it does not get loaded into software" [11:59] zyga, i could add you if i could reach the store ... seems it isnt liking me today ... getting 504s [12:00] ogra_: yeah, the store has hicckups today [12:00] hic-hic-hic-hic [12:00] or more rather [12:00] hic-hic-504-hic [12:00] heh, it seems to be one very looong hick .... and no "up" at all for me [12:01] sergiusens: hey, can you suggest how we can use the dump plugin for this: ? [12:01] sergiusens: https://github.com/snapcore/pi2/blob/master/snapcraft.yaml#L15 [12:01] zyga : the gnome-software library I can see it when it is listed in the installed apps but does not get listed in the "wild" [12:01]