/srv/irclogs.ubuntu.com/2016/11/30/#snappy.txt

robert_ancellIs there a method for system services to own (system) D-Bus names or is this the same problem as for sessions? i.e. bug 159067900:45
mupBug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>00:45
mupPR snapcraft#927 closed: Add a test script to build external snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/927>02:13
mupBug #1645961 opened: Snapd generates a wrong udev rule for i2c devices <Snappy:New> <https://launchpad.net/bugs/1645961>03:12
=== chihchun_afk is now known as chihchun
mupBug #1627175 changed: RPi3 with only HDMI attached never shows subiquity <Snappy:Fix Released by ogra> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1627175>06:40
mupBug #1626121 changed: strict mode snaps crash with Segmentation fault on 16.10 <Snappy Launcher:Invalid> <Snapcraft:New> <Snappy:Fix Released by jdstrand> <snap-confine (Ubuntu):Invalid> <snapd (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1626121>06:43
mupBug #1624676 changed: ERROR cannot remove snap file "kicad-dev-snap", will retry in 3 mins: umount: /snap/kicad-dev-snap/x6: mountpoint not found <Snappy:Fix Released> <https://launchpad.net/bugs/1624676>07:10
mupBug #1623897 changed: console-conf should show if wired interfaces are connected <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1623897>07:16
mupBug #1624329 changed: snapd firstboot setup fails constantly when rebooting before console-conf has finished <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1624329>07:16
mupBug #1628193 changed: please set TMPDIR=/tmp when launching snaps <Snappy:Fix Released> <snap-confine (Ubuntu):Fix Released> <https://launchpad.net/bugs/1628193>07:25
mupBug #1628289 changed: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Fix Released> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>07:25
mupBug #1628357 changed: A deamon fails with: No home directory found <Snappy:Fix Released> <https://launchpad.net/bugs/1628357>07:28
mupBug #1628559 changed: Can't install more than 1 package in one command <Snappy:Fix Released> <https://launchpad.net/bugs/1628559>07:28
mupBug #1628640 changed: Add 'snap info' command showing publisher, channel map <Snappy:Fix Released by chipaca> <Software Center Agent:Triaged by facundo> <https://launchpad.net/bugs/1628640>07:28
foxmaskbonjello07:29
mupBug #1630036 changed: auto import of assertions fails for devices present at boot <Snappy:Fix Released> <https://launchpad.net/bugs/1630036>07:31
mupBug #1630520 changed: snap login error message incorrect <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1630520>07:38
mupBug #1630586 changed: Pi3 kernel crash and is unreliable <patch> <Snappy:Fix Released> <linux-raspi2 (Ubuntu):Fix Released by p-pisati> <https://launchpad.net/bugs/1630586>07:38
mupBug #1630652 changed: snap revert and refresh forwards and backwards causes breakage <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1630652>07:38
mupBug #1631159 changed: No way to simply list available snaps via snapd <Canonical System Image:New> <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1631159>07:41
mupBug #1632305 changed: console-conf cannot be used twice <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1632305>07:44
dholbachhey hey07:52
mupBug #1632336 changed: after first boot /var/lib/snapd/seed/snaps is empty <Snappy:Fix Released> <https://launchpad.net/bugs/1632336>07:53
mupBug #1632337 changed: dragonboard beta3 image reboots during snap create-user <Snappy:Fix Released> <https://launchpad.net/bugs/1632337>07:53
mupBug #1634089 changed: Cannot activate Chinese input method for Qt app <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1634089>07:59
seb128hey dholbach!08:01
dholbachsalut seb12808:02
mupBug # changed: 1634730, 1634775, 1634822, 163488008:02
seb128that bot should tell what the bugs are, giving random numbers as changed is not that useful08:03
didrocksbingo!08:04
didrocksseb128: no no, it can be useful :)08:04
mupPR snapd#2379 opened: snap: remove unused experimental command <Created by mvo5> <https://github.com/snapcore/snapd/pull/2379>08:04
mupBug #1634909 changed: Disabling pc||pc-kernel||core should give a warning message <Snappy:Fix Released> <https://launchpad.net/bugs/1634909>08:05
mupPR snapd#2380 opened: debian: add missing ca-certificates dependency <Created by mvo5> <https://github.com/snapcore/snapd/pull/2380>08:08
abeatowoodrowshen, hi, I  saw you created an alsa-utils package, where could I find the sources?08:08
woodrowshenabeato: oh, https://github.com/woodrow-shen/snapcraft-alsa-utils/blob/master/snapcraft.yaml08:10
abeatowoodrowshen, awesome, thanks08:10
woodrowshenabeato: i didn't use interface yet08:10
abeatowoodrowshen, so this for installing with --devmode?08:11
woodrowshenabeato: yes08:11
abeatooh, I see08:11
longsleepSo 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:14
stubAre snappy updates being backported to Trusty? I'm interested in some 2.18 fixes in Trusty and Xenial.08:20
mupPR snapd#2381 opened: image: drop support for UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL <Created by mvo5> <https://github.com/snapcore/snapd/pull/2381>08:25
mupBug # changed: 1636023, 1636383, 1636419, 163642108:29
mupBug #1636764 changed: Snapd is not correctly initialized with UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 and model assertion is invalid <Snappy:Won't Fix> <https://launchpad.net/bugs/1636764>08:35
mupBug #1636864 changed: ubuntu-image 0.10+real1 requires sudo <Snappy:Fix Released> <https://launchpad.net/bugs/1636864>08:38
mupBug #1636894 changed: [raspberry pi3]pi3 snap is removable  <Snappy:Fix Released> <https://launchpad.net/bugs/1636894>08:38
mupBug #1637981 changed: failed snap refresh removes security profiles <Snappy:Fix Released> <https://launchpad.net/bugs/1637981>08:41
mupBug #1638656 changed: snapd testsuite fails when run inside an lxd container <Snappy:Fix Released> <https://launchpad.net/bugs/1638656>08:44
mupBug #1638798 changed: mir server process goes defunct when a mir client attaches under confinement <Snappy:Fix Released> <https://launchpad.net/bugs/1638798>08:44
mupBug #1639234 changed: docs/rest has not url for install (refresh, revert, remove) example <Snappy:Fix Released> <https://launchpad.net/bugs/1639234>08:47
mupBug #1639614 changed: Sandbox denials with snap using thumbnailer <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1639614>08:50
kalikiana_stub: I expect trusty will get backports, considering new interfaces that's pretty much required anyway to run all (new) snaps in the long term08:54
kalikiana_I'm not sure, though, if that's documented somewhere08:54
kalikiana_Or in what cadence08:54
mupPR snapd#2382 opened: snap: Improve `snap --help` output as designed by Mark <Created by mvo5> <https://github.com/snapcore/snapd/pull/2382>08:58
abeatowoodrowshen, 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:13
mupPR snapd#2383 opened: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <https://github.com/snapcore/snapd/pull/2383>09:16
mupPR snapd#2215 closed: tests: spread system user autoimport <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2215>09:19
woodrowshenabeato: oh, yes, it seems to have /usr/share/alsa/alsa.conf09:25
woodrowshenabeato: from libasound2-data09:25
woodrowshenabeato: for early stage, i hacked os snap to workaround it ...09:26
abeatowoodrowshen, you copied the alsa.conf file around, isn't it?09:26
woodrowshenabeato: right09:27
abeatonoted, thanks09:27
mupPR snapd#2384 opened: snap: add snap size, description and provided apps to `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2384>09:27
woodrowshenabeato: np09:27
sil2100Hey! When running snap prepare-image (through ubuntu-image) I get a sha3-384 mismatch when downloading core09:48
sil2100Yesterday it worked fine, although then I was getting a similar mismatch when downloading pc-kernel IIRC09:48
sil2100Is this a known problem?09:49
sil2100error: sha3-384 mismatch downloading core: got 4ebcade07da9a4d1dfc822efdb300997fd17f5fdd3e91fd0036bb1479fba2ff586cd672b04933d396b2734c57f949c30 but expected 536b4e3795ae66f1962567ce6f129eb979d08054aed874c40772c39b30222dd535e8739769af0e81e794b2136e05adbe09:49
mupPR snapd#2385 opened: daemon, strutil: move daemon.quotedNames to strutil.Quoted <Created by chipaca> <https://github.com/snapcore/snapd/pull/2385>09:49
sil2100I'm using snapd 2.17.109:53
zygasil2100: no, can you please report it!09:55
sil2100On it!09:55
mvosil2100: anything in syslog that indicates that there was some retry or something?09:56
mupPR snapd#2346 closed: Misc libvirt fixes <Created by javacruft> <Closed by javacruft> <https://github.com/snapcore/snapd/pull/2346>10:00
mupPR snapd#2276 closed: Add openvswitch-support interface <Created by javacruft> <Closed by javacruft> <https://github.com/snapcore/snapd/pull/2276>10:01
sil2100mvo: nothing, but actually after trying now hm, both core and pc-kernel went fine through10:02
ogra_sil2100, do you use the canonical VPN ? (due to the recent router attacks mine died a few times since monday without notice)10:02
sil2100I remember trying to run the same command at least 4 times yesterday and getting mismatches for pc-kernel10:02
sil2100While now it just succeeded after a re-run10:02
sil2100Strange10:02
sil2100Anyway, seems like a false alarm, sorry for the noise10:04
ogra_hmm, i'm getting a lot of 504 errors on launchpad10:06
ogra_seems you are not alone10:06
ogra_err, from the store, sorry ...10:07
mupPR snapd#2386 opened: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <https://github.com/snapcore/snapd/pull/2386>10:07
zygaogra_: hey ogra, how are you10:08
zygaogra_: I did some of the things we talked about, please have a look at github.com/snapcore now10:08
zygaogra_: I've done the lauchpad project for pi2 so far (snap-pi2), I'll make the rest next10:08
ogra_zyga, trying to find out why core failed to upload tonights builds :P10:08
zygaogra_: pi2 is set so that each commit that lands on master gets pushed to the store10:08
zygaogra_: I'll patch all the gadgets to have a skeleton snapcraft.yaml with dump plugin10:09
ogra_zyga, hmm, i thought you would create a master project for that under snapcore10:09
ogra_like snapcore/gadgets/$arch10:09
ogra_alternatively probably putting "gadget-" in the branch name might make sense10:10
ogra_they kind of vanish in the amount of stuff thats already there10:11
ogra_(and i guess that will become more)10:11
ogra_also, while we're moving we should probably also drop "generic-" from the x86 arches10:12
ogra_in the store they are called pc or pc-i38610:12
zygaogra_: on github there are no projects, jsut repositories10:15
zygaogra_: in the store both pc gadgets are just called "pc"10:16
zygaogra_: once we build more from source we can unify them and drop one10:16
zygaogra_: but now we cannot since we need two snapcraft.yaml's that are different10:16
zygaogra_: in the end we'll get only four gadgets, pc, pi2, pi3 and dragonboard10:16
zygaogra_: but now the pc one has two repos because that's how we need to do it10:16
=== ubott2 is now known as ubottu
ogra_zyga, i'm not talking about merging them but making them better discoverable in the amount of projects there10:21
ogra_s/projects/branches/10:21
ogra_and about dropping the "generic"10:21
ogra_"<ogra_> alternatively probably putting "gadget-" in the branch name might make sense"10:22
ogra_i find them hard to discover already and there are not many branches under snapcore yet ... in a year that will have doubled10:22
zygaogra_: 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
zygaogra_: note: those are repos, not branches10:23
ogra_ok10:23
ogra_"things"10:23
ogra_:P10:23
zygaogra_: we don't want to add all the gadgets there, just the ones that we support10:23
ogra_yes10:23
zygaogra_: and snap-confine will go away so we'll have less things there10:23
zygaogra_: note that you won't see branches, this is essential, you won't see 12s of forks and branches from other people10:24
ogra_yes, i have used github before :)10:24
=== zbenjamin_ is now known as zbenjamin
zygaogra_: sorry, I was just trying to explain how this might look like10:26
ogra_yeah, no worries :)10:26
zygaogra_: ok, now for the publishing pipeline10:26
mupPR snapd#2385 closed: daemon, strutil: move daemon.quotedNames to strutil.Quoted <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2385>10:26
zygatyhicks, 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
mupPR snap-confine#189: Use apparmor-support module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/189>10:27
ogra_mvo, danm !10:36
ogra_*damn even10:36
mvoogra_: hu?10:36
ogra_mvo, i'll have to revert your change to bug 163987810:36
mupBug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v <Snappy:Fix Committed by ogra> <https://launchpad.net/bugs/1639878>10:36
mvoogra_: why?10:36
ogra_i'm in the middle if re-working pre-arch modules10:37
ogra_*per10:37
ogra_because our initrd gets to big10:37
ogra_we really dont want the virt stuff on arm10:37
mvoogra_: I don't see this module on arm10:37
ogra_on which arm do you look ?   :)10:38
ogra_(the generic kernel has it)10:38
mvoogra_: pi2, the only one I have10:38
ogra_right, there we dont build it10:38
ogra_anyway, i'm already working on a fix and should have it ready later today10:39
ogra_(there are a bunch of others like virtio that need to go)10:39
mvoogra_: *shurg* its 28kb (the hv_storsvc) and 96kb (the hv_vmbus). but yeah, go ahead if thats too big10:39
ogra_its not about to big but about loading them forcefully ... check lsmod on your rpi10:40
ogra_they eat ram10:40
mvoogra_: we are loading them forcefully? that sounds not ideal, why is that?10:41
ogra_(we use MODULE=list in the initrd)10:41
ogra_to keep the number small, thats the only way, all others load a lot of default stuff we dont need and thats megabytes10:41
mvoogra_: 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
mvoogra_: I don't disagree to fix all that, don't get me wrong10:42
mvoogra_: 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
ogra_mvo, indeed10:43
ogra_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
ogra_we dont ship the package anymore and the path is an anachronism10:44
mupPR snapd#2342 closed: client: use typed snap.ConfinementType <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2342>10:44
mvoogra_: that makes sense, yes, its slight ugly as it is right now10:45
ogra_yup10:45
mupPR snapd#2387 opened: asserts: introduce top-commands header in snap-declaration <Created by pedronis> <https://github.com/snapcore/snapd/pull/2387>10:45
ogra_not really high prio but it makes me itch every time i have to touch it10:46
mvo+110:47
zygaogra_, mvo: https://github.com/snapcore/pi2/pull/111:00
mupPR pi2#1: Improve the README file <Created by zyga> <https://github.com/snapcore/pi2/pull/1>11:00
=== sil2100_ is now known as sil2100
ogra_zyga, perhaps we should have a "BUILDING" file for the old content11:01
ogra_(which could also point to sources etc and have some more info on where the binaries come from(11:02
zygaogra_: for the mkvenvimage line?11:04
ogra_yeah, it is highly important for oporters to know about it11:04
zygaogra_: can you propose that please? I'm sure you'd be more accurate than I am11:04
ogra_*porters11:04
zygaogra_: let's land this branch and iterate11:05
ogra_though ...11:05
zygaogra_: I'll make the snapcraft.yaml with dump plugin now11:05
ogra_we could switch to the make plugin and simply automate it i guess11:05
zygaogra_: :D11:05
zygaogra_: I'll do the naive dump plugin11:05
zygaogra_: and let you improve, ok?11:05
ogra_yeah, start with that11:05
zygaok!11:05
ogra_:D11:05
mupPR snapd#2373 closed: debian: remove unneeded conflict against the "snappy" package <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2373>11:15
gerry_hi all, I am using the jdk plugin but I need the headers how do I do this?11:22
mupPR snapd#2379 closed: snap: remove unused experimental command <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2379>11:22
zygaogra_, mvo, slangasek: https://github.com/snapcore/pi2/pull/211:23
mupPR pi2#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pi2/pull/2>11:23
zygasergiusens: ^^11:23
zygasergiusens: I found a bug in snapcraft, I think, building that with snapcraft twice results in an odd error message about meta/gadget.yam11:24
ogra_zyga, why didnt you keep the boot-assets" name11:24
zygaogra_: I did, it's a subdirectory there11:24
ogra_oh, sorry11:24
=== sil2100_ is now known as sil2100
zygaogra_: I didn't try booting with that11:24
zygaogra_: but the prime/ directory looks identical to the old tree, except for meta/gui/icon.png11:25
ogra_well, as long as the bits land in boot-assets later all is fine11:27
sergiusenszyga we deal with bugs through bug reports if you are so sure of it ;-)11:28
zygaogra_: can you review it please then11:30
zygasergiusens: let me file it quickly :)11:30
zygasergiusens: https://bugs.launchpad.net/snapcraft/+bug/164608111:32
mupBug #1646081: Gadget snap cannot be built twice <Snapcraft:New> <https://launchpad.net/bugs/1646081>11:32
zygasergiusens: does that look sensible?11:34
zygasergiusens: I found this on the following pull request: https://github.com/snapcore/pi2/pull/211:34
mupPR pi2#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pi2/pull/2>11:34
=== chihchun is now known as chihchun_afk
zygasergiusens: and btw, since you are here, where should the icon be? am I doing the right thing with setup/gui/icon.png?11:34
zygaogra_: I'm waiting for your comment there, if you +1 it we can land it :)11:36
zygaogra_: thanks! merged11:37
zygaogra_: so now about that makefile part11:37
zygaogra_: do you think we should also copy the licenses?11:37
ogra_dont we do that ? yes, we should11:38
ogra_like they are upstream11:38
sergiusenszyga yes, but you can use the dedeprecated `icon` entry to get rid of `setup`11:40
zygaogra_: ok, let me fix that11:40
zygasergiusens: how can I read about filesets or organize help?11:41
zygasergiusens: 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 work11:41
zygaah11:42
zygasorry, there's a typo in the tree itself :)11:42
zygaogra_, sergiusens: https://github.com/snapcore/pi2/pull/311:44
mupPR pi2#3: Copy licenses to the snap <Created by zyga> <https://github.com/snapcore/pi2/pull/3>11:44
zygaogra_: shall I correct the LICENSE vs LICENCE typo?11:44
ogra_zyga, well, thats also from upstream :)11:45
popeyis it possible to just point to a deb url in a snapcraft yaml?11:45
ogra_however you feel like ;)11:45
popeyto pull in a pre-built deb and unpack it?11:45
zygaogra_: ok, I'll leave it as-is then11:45
ogra_popey, https://github.com/ogra1/laidout is one way11:47
ogra_(see the Makefile)11:47
popeyta11:48
popeyoh11:48
popeythat's icky, can we not just source: foo.deb ?11:48
ogra_well, it is old ... perhaps we can now :)11:48
popeyok11:48
popey:)11:48
ogra_thats a sergiusens question11:48
mupBug #1646085 opened: snapd-interface access to /usr/bin/infocmp denied <Snappy:New> <https://launchpad.net/bugs/1646085>11:49
popeywhat I really want is access to a 3rd party archive in a cleanbuild11:49
gerry_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:49
zygaogra_: https://github.com/snapcore/pi2/pull/411:52
mupPR pi2#4: Add URL to launchpad build history <Created by zyga> <https://github.com/snapcore/pi2/pull/4>11:52
zygagerry_: 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 have11:52
zygagerry_: 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:53
gerry_zyga: thank you for your help the app works when I run it without sudo it crashes when I use sudo with an exception11:58
zygado you need to run it with sudo?11:58
zygaogra_: I just requested a manual build11:59
zygaogra_: if all goes well it will end up in edge :)11:59
zygaogra_: and if not we can work with mvo on store side permission11:59
gerry_yes because when I upload it to the ubuntu store it does not get loaded into software11:59
zygagerry_: what do you mean by "it does not get loaded into software"11:59
ogra_zyga, i could add you if i could reach the store ... seems it isnt liking me today ... getting 504s11:59
zygaogra_: yeah, the store has hicckups today12:00
zygahic-hic-hic-hic12:00
zygaor more rather12:00
zygahic-hic-504-hic12:00
ogra_heh, it seems to be one very looong hick .... and no "up" at all for me12:00
zygasergiusens: hey, can you suggest how we can use the dump plugin for this: ?12:01
zygasergiusens: https://github.com/snapcore/pi2/blob/master/snapcraft.yaml#L1512:01
gerry_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
zygagerry_: ah, I think this is a separate bug12:01
zygagerry_: how does using sudo helps?12:01
gerry_zyga: I was told it had to work with sudo to be accepted12:02
zygagerry_: who told you that?12:02
gerry_somebody on here didrocks12:02
zygadidrocks: can you tell me more about this please?12:03
zygaogra_, mvo: can you guys please add me to the pi2 gadget snap in the store, if you can?12:06
ogra_if i could :P12:06
ogra_i cant even get the front page of myapps.d.u.c12:07
ogra_504 Gateway Time-out12:07
ogra_The server didn't respond in time.12:07
ogra_...12:07
ogra_oh, a new message !12:08
ogra_We're currently experiencing some difficulties12:08
ogra_Sorry, it looks like we're experiencing a problem with this service. We'll be investigating shortly.12:08
ogra_... so that i dont get bored :P12:08
zygathanks for checking12:09
didrockshum? I didn't say to use sudo AFAIK12:10
didrocksgerry_: not sure where this is coming from, are you mixing with the permissions issues you had? ^12:10
didrockszyga: ^12:10
didrocksscrolling back -> gnome software12:11
didrocksyeah, I did tell you that for now, you will only see snaps in gnome software if you use sudo AFAIK12:11
didrockssudo to start gnome software12:11
didrocksnothing to do with your snaps12:11
didrocks(there is a permission mismatch in snapd/gnome-software)12:11
zygagerry_: please don't worry about this, it will get fixed in gnome-software12:12
didrocksyeah, but gerry_ wanted to see his snap right now, hence this solution12:12
zygagerry_: you should be able to just find the launcher of your app from dash/gnome-shell12:12
zygagerry_: and it should run when started from that location12:12
gerry_zyga: yes I can run it locally but my ultimate aim was to have it included in gnome-software12:13
zygaogra_: https://github.com/snapcore/pi3/pull/112:15
mupPR pi3#1: Improve the README file <Created by zyga> <https://github.com/snapcore/pi3/pull/1>12:15
ogra_oh, hello store !12:19
zygaogra_: https://github.com/snapcore/pi3/pull/2 :)12:20
mupPR pi3#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pi3/pull/2>12:20
ogra_zyga, you should have three invite mails from the store...12:22
gerry_zyga, didrocks: sorry I am a little confused now have I still to continue looking for an answer to my sudo problem?12:23
zygaogra_: thank you12:23
zygagerry_: no, unless you expect your users to use sudo on a daily basis12:23
zygaogra_: you should have invites to the repos12:24
ogra_two for now, yeah12:24
gerry_zyga: so now I just need to find out why it has not been included in gnome-software? thank you very much and sorry I am such a pain12:25
didrocksgerry_: it does show up in snap find, correct?12:25
didrocksyour snap12:25
zygagerry_: does it show up in the dash when you search for it?12:26
zygagerry_: is the desktop file in /var/lib/snapd/desktop/applications/ what you'd expect?12:26
zygagerry_: if so, you are good12:26
zygaogra_: ok, got it, I'll triggere another build of pi2 so that it can get published12:27
zygaogra_: let's do dragon next, it doesn't have the PC problem12:28
gerry_I am using gnome desktop where it shows up as a menu selection and it shows up in gnome-software as an installed app12:28
ogra_oh, dragon ...12:28
ogra_forgot that one ... invite sent12:29
gerry_just when I search for it under "all" it is not there12:29
zygaogra_: https://github.com/snapcore/dragonboard/pull/112:32
mupPR dragonboard#1: Improve the README <Created by zyga> <https://github.com/snapcore/dragonboard/pull/1>12:32
zygaogra_: got the invite, thanks12:32
zygaogra_: so I see revision 30 in the store but it's not published automatically12:36
zygalooks like a launchpad bug?12:36
zygahttps://myapps.developer.ubuntu.com/dev/click-apps/2436/rev/30/12:36
zygacjwatson: should a snap built according to this recipe auto-publish to edge? https://code.launchpad.net/%7Ezyga/+snap/pi212:37
ogra_zyga, yes12:37
ogra_note that it takes a while for the last step in the store12:38
ogra_(thats a cronned publisher i think)12:38
ogra_and there it published ;)12:39
zygawoooooot!12:40
zygagreat12:40
renato__zyga, hey I am getting this error: http://paste.ubuntu.com/23554713/, while trying to test my new interface. What I am missing?12:41
zygaogra_: https://github.com/snapcore/dragonboard/pull/212:41
mupPR dragonboard#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/dragonboard/pull/2>12:41
zygarenato__: looking12:41
zygarenato__: you probably how to edit the base declaration assertion12:44
zygarenato__: look at ...12:44
zygaah, sorry afk12:45
renato__let me check12:47
renato__zyga, http://paste.ubuntu.com/23557921/12:49
sergiusensdidrocks mind helping me with `snapcraft define preload`?12:49
gerry_hi guys sorry I have another question had a look in ubuntu one and my app has the entry Tue 22 Nov. 2016 Approved. Automated review found no issue how long until it gets in gnome-software ?12:50
zygagerry_: it's automatic it if is published into the stable channel12:59
mupPR snapd#2388 opened: make snap install/refresh/etc abort if the service does not stay active, unless --devmode is given <Created by chipaca> <https://github.com/snapcore/snapd/pull/2388>13:00
gerry_zyga: thank you nothing yet just found the little "release" button though13:00
zygaogra_: pi3 build in progress, dragon is next but I'm waiting for the initial launchpad mirror13:13
ogra_cool13:14
zzarrhello! I'm trying to install snapd on a machine running 16.04.1, but get this error http://pastebin.com/QxCLfWE4 how do I solve it?13:15
zzarrare there a problem with the repository?13:15
zzarrI could install other packages13:15
zygazzarr: there's a conflict there, you need to remove the snap package13:16
zzarrthanks zyga, I will do13:18
zzarrit worked, once more, thanks zyga13:18
zzarrif I install the nexctcloud snap, would that break my apache setup?13:20
zygaogra_: dragonboard build triggered13:21
ogra_great13:21
zygaogra_: now for pc13:22
zygaI wonder if I can cheat13:22
ogra_yay13:22
zygamerge both generic- repos into one13:22
zygaand use snapcraft.yaml to build it13:22
zygaso that there's one project that gives two working gadget snaps for both arches13:22
zygahmmm - perhaps that's the way13:22
ogra_yeah13:28
zygaogra_: pi2, pi3 and dragonboard are now auto-published :)13:30
ogra_yay13:30
zygasergiusens: question about gadget.yaml13:35
zygasergiusens: looking at amd64 and i386 gadget snaps I see differences in their gadget.yaml files13:36
zygasergiusens: do you think we can build both snaps from one tree somehow?13:36
zygasergiusens: or is this futile13:36
zygazyga@xenial-server:~/snappy-hub$ diff -u generic-amd64/meta/gadget.yaml generic-i386/meta/gadget.yaml  | pastebinit13:36
zygahttp://paste.ubuntu.com/23558061/13:36
zygaogra_, slangasek ^^13:38
ogra_zyga, the diff looks right13:38
ogra_i386 doesnt have secure boot13:39
ogra_not sure how you would get that into a single snapcraft.yaml though13:39
zygayeah, that's what I'm thinking about13:39
ogra_or rather gadget.yaml13:39
=== verterok` is now known as verterok
zygaif there's no way we can just accept two repos/snapcraft.yamls for now13:39
gerry_hi finally got my app uploaded to gnome-software thank for the zyga and didrocks13:42
gerry_*help13:42
zygagerry_: that's great! glad to see your snap in the store13:43
gerry_I have another problem now when I want to remove it via the gnome-software it keeps asking me for my ubuntu one  email and password ?13:44
zygagerry_: I think you have to login at least once to do that13:44
gerry_zyga: oh ok thanks trying that now :)13:45
gerry_zyga: I try to enter my email and password and it just says one of them is false even though I have checked it out in my browser and it logs in ok on that?13:59
mhall119does /w 7914:06
gerry_found a way started gnome-software as sudo14:06
gerry_I have another question why in gnome-software is my app have non-free written on it?14:16
gerry_*does14:16
kalikianagerry_: non-free means nobody vetted the source code - so for a snap that's by design the case, nobody can know how it was built, as opposed to packages from the Ubuntu archive14:23
kalikianaI'll agree, though it looks ugly, it's just a technical stupidity14:23
gerry_Kalikianna: thanks for you help just one more question it does not seem to use screenshots either?14:24
mupBug #1632390 changed: "snap find" return unrelative snap <Snappy:Opinion> <https://launchpad.net/bugs/1632390>14:32
kalikianagerry_: It doesn't seem to be implemented yet. Not sure if there's a bug yet14:32
mhall119sergiusens: does snapcraft support ./setup/hooks/ yet? Or do you still have to put them into ./prime/meta/hook/ before the final snap step?14:32
mhall119niemeyer: zyga: related to that, has the change to run the configure hook on install & upgrade landed in the snapd archive packages?14:34
didrockssergiusens: sorry, didn't see your ping, sure, what about it?14:36
zygamhall119: I think we're still waiting for some stuff to get the next SRU out, mvo knows details14:37
=== cmars` is now known as cmars
jdstrandmorphis, joc_ (cc niemeyer): hey, I was refamiliarizing myself with how serial-port, gpio, i2c and hidraw work in practice (due to responding to bug #1645445) and realized that https://github.com/snapcore/snapd/wiki/Interfaces was a bit lacking14:41
mupBug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <Snappy:Incomplete> <https://launchpad.net/bugs/1645445>14:41
jdstrandmorphis, joc_ (cc niemeyer): so I fixed that: https://github.com/snapcore/snapd/wiki/Interfaces/_compare/0c2b18b9a98ce1a5e45d4392c05023a505072c2e...e514578237da8a4d00b38a0f6db6c1053448f76414:41
jdstrandmorphis, joc_ (cc niemeyer): please let me know if I should change something14:41
jdstrandmvo: regarding 1645445, I responded. need feedback from the dev and then I can talk to Gustavo on how to advise on the next steps14:43
zygajdstrand: o/14:43
jdstrandzyga: hey14:43
zygajdstrand: I created a Content-Interface wiki page14:43
zygajdstrand: I'd like to move all the interesting interfaces to sub-pages with details and link to them from the Interfaces page14:43
mvojdstrand: thank you14:43
zygajdstrand: thanks for your XDG_RUNTIME_DIR review, I will adjust the code as suggested14:44
zygajdstrand: I proposed https://github.com/snapcore/snap-confine/pull/189 as a follow-up to what tyler reviewed yesterday14:44
mupPR snap-confine#189: Use apparmor-support module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/189>14:44
jdstrandzyga: re Interfaces page, sounds good to me14:45
jdstrandzyga: re 189, yep saw that. re xdg, thanks!14:45
abeatosergiusens, maybe you know, how can add a user to a group in ubuntu core? --extrausers seems to be not magical enough14:46
zygajdstrand: there was one interesting bug in i2c that was found recently14:47
zygajdstrand: we used = instead of == in the udev rule14:47
jdstrandeek14:47
zygajdstrand: I didn't do a pass over all of those but it feels like it slipped through review and is not CId yet14:47
zygajdstrand: one interesting development today: look at github.com/snapcore14:47
zygajdstrand: look for pi2, pi3 and dragonboard :)14:47
zygajdstrand: I plan to hack on the wiki extensively tomorrow-ish14:48
* ogra_ wonders why the snapcraft@ suddenly is hit by so much spam stuff 14:49
ogra_is that only me ?14:49
abeatonot only you, not14:49
zygaogra_: we've noticed, taking action14:50
ogra_thx14:50
zygamy inbox was beeping like a timer ;)14:50
jdstrandzyga: oh, that is handy. cool :)14:50
zygajdstrand: PC is the last to go because of two arches sharing snap name but I'll get it supported if I can14:50
jdstrandogra_: you may have an answer for abeato ^14:51
zygajdstrand: also a place to report bugs (on the LP mirror projects)14:51
* ogra_ reads backlog14:51
jdstrandinterestingly, I *just* made a comment about group membership in bug #164544514:51
mupBug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <Snappy:Incomplete> <https://launchpad.net/bugs/1645445>14:51
abeatoogra_, about adding a user to a group :)14:51
ogra_abeato, hmm, addgroup with --extrausers doesnt work ?14:51
ogra_err14:51
ogra_adduser14:51
ogra_adduser --extrausers ogra newgroup14:52
ogra_something like that14:52
abeatoogra_, http://paste.ubuntu.com/23558361/14:52
ogra_(newgroup being the name of the group)14:52
ogra_hmm, that should work14:52
ogra_abeato, oh14:53
ogra_you are trying to add the user to a group that lives in /etc/group14:53
ogra_so that cant work14:53
abeatoogra_, :(14:54
abeatoogra_, should not that be possible? is this a bug?14:54
ogra_we'd have to move that group to /var/lib/extrausers ... though the audio group is deprecated since half a decade now14:54
jdstrandogra_: dialout came up in 164544514:55
abeatoogra_, /dev/snd/ stuff has that group14:55
ogra_jdstrand, well, we cant really make these system groups dnyamic ... that will break the filesystems badly14:55
mupPR snapd#2364 closed: overlord: increase test timeout and improve failure message <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2364>14:55
jdstrandogra_: we need a solution for device permissions and users. maybe it is simply that we have snap.dialout and snap.audio and snapd's udev rules does that instead14:56
ogra_abeato, yes, but you should only access it through a sound daemon14:56
jdstrandogra_: I think groups are still useful on all snaps, but it needs design14:57
ogra_jdstrand, that might work ... the prob is that the GIDs are immovable due to readonly/readwrite merges14:57
rvrSpam on snapcraft mailing list :(14:58
jdstrandogra_: I was thinking snapd.dialout is an extrausers group. that suffers from the merge problem?14:58
ogra_which is why the system groups are all sitting in /etc/group14:58
ogra_jdstrand, the issue is the GID ... would an additional rgoup help at all ?14:58
ogra_the device node would still be owned by audio ... and potential homedirs of a daemon too ...14:59
jdstrandwell, that is tricky. we don't want to change all dialout to snap.dialout cause that might break core14:59
ogra_if you now change GIDs the filesystem ownership breaks14:59
jdstrandyeah14:59
jdstrandhrm14:59
ogra_you would have to update the GID ownership on every boot ...14:59
zygaogra_: https://github.com/snapcore/generic-amd64/pull/1/files14:59
mupPR generic-amd64#1: Add initial README.md file <Created by zyga> <https://github.com/snapcore/generic-amd64/pull/1>14:59
ogra_walking the whole fs14:59
zygaogra_: I will do two github repos but one launchpad project with two git mirrors there14:59
zygaogra_: and they will both build to the "pc" snap15:00
ogra_zyga, sounds good ... i'd still prefer pc and pc-i386 as names though :)15:00
zygaogra_: yeah, maybe once we implement generic rename support we can do that15:00
zygaogra_: do you want to rename the repos?15:00
zygaogra_: this is free now15:00
ogra_generic is a 15.04 name we forcefully dropped everywhere (except in that branch because nobody cared)15:00
zygaok15:00
zygaI'll do that15:00
zygapc-$ARCH15:00
niemeyerjdstrand: Thanks for the wiki improvements15:01
ogra_thanks:)15:01
abeatoownership stuff can get tricky, what I am doing is playing with a confined aplayer, in the end I have to do: "sudo alsa-utils.aplay /root/enter.wav" when I have alsa and home interfaces connected... you have to do sudo *and have a file in /root/ folder* to play something15:02
jdstrandogra_: it seems extrausers and the system group issue is that what we have isn't smart enough. it seems like an artificial limitation of the implementation that an extrauser can't be added to a system group. perhaps snappy needs an updated nss module that can handle that15:02
abeatoaddinng my user to the audio group would help a bit15:02
ogra_jdstrand, well, i wont hold you back :P15:02
ogra_abeato, device ownerships should be handled by udev ACLs nowadays15:03
ogra_(since years actually)15:03
jdstrandhrm15:03
zygaogra_: https://github.com/snapcore/pc-amd64 and https://github.com/snapcore/pc-i38615:03
jdstrandit needs design15:03
jdstrandbut seems possible15:03
jdstrandit also needs someone assigned to it15:03
ogra_jdstrand, and you think we cant do it via ACLs like we do oon the desktop since ages ?15:03
abeatoogra_, ok, I will try with an ACL, is that possible in ubuntu core?15:04
ogra_iirc we dropped the audio group membership for default users in 10.04 or 12.04 in favour of ACLs15:04
zygaogra_: how does it work with ACLs?15:04
ogra_abeato, perhaps not without changes to core ... but i think if possible we should use them15:05
zygaogra_: and wich users should get access? (if the ACLs relate to users, I don't know)15:05
ogra_zyga, now i'd say thats a pitti question ... but i guess we need to start getting along alone ... (he implemented that IIRC)15:05
zygaogra_: is that documented anywhere?15:05
ogra_zyga, logind manages the access15:05
zygaogra_: (and let's land https://github.com/snapcore/pc-amd64/pull/1/files unless you want to tweak wording)15:06
mupPR pc-amd64#1: Add initial README.md file <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/1>15:06
ogra_abeato, "getfacl /dev/snd/controlC0 | grep -Eo "user:.+:" | cut -d: -f2" ...15:08
ogra_that should return your username if you have acl access to the sound device ... independent from the audio group15:08
zygaogra_: so for services (root) this is irrelevant but fro users that log in we could useit15:08
jdstrandogra_: maybe. I see only one setfacl in /lib/udev/rules.d15:08
ogra_the above command clearly retuns ogra on all my desktop installs15:09
ogra_so we should make sure this works on core as well15:09
zygaogra_: does logind manage ssh logins and console logins?15:09
ogra_and at the same time:15:10
ogra_ogra@styx:~$ groups|grep audio15:10
ogra_ogra@styx:~$15:10
abeatoogra_, same for me, it shows my user, but no getfacl in core, certainly15:10
ogra_ok, file a bug ... lets first get the tools in and then see if we can make them work ;)15:10
abeatoogra_, alright, in snappy I guess?15:10
ogra_yeah15:10
jdstrandogra_: this seems like a plausible way to handle it. yes, abeato, please file a bug15:11
abeatocool15:11
ogra_if you can ... assign to me15:11
abeatosure :)15:11
jdstrandI'm curious about the mechanism used to setfacl15:11
ogra_i think there is some buuiltin setfacl in udev somehow15:12
ogra_but pitti only explained it once to me and that was several years ago15:12
ogra_(i have forgotten most of it and need to dig into it again)15:13
mupPR snapd#2388 closed: make snap install/refresh/etc abort if the service does not stay active, unless --devmode is given <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2388>15:13
ogra_aha15:14
ogra_jdstrand, https://wiki.ubuntu.com/Audio/TheAudioGroup15:14
ogra_a little sparse but it at least explains the high level to endusers15:14
pittiogra_: right, /lib/udev/rules.d/70-uaccess.rules tags such devices as "uaccess" and 73-seat-late.rules calsl the "uaccess" builtin15:14
jdstrandogra_: it looks like it should be systemd these days instead of consolekit, but yeah15:15
ogra_yeah, that was it ... uaccess15:15
mupPR snapd#2382 closed: snap: Improve `snap --help` output as designed by Mark <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2382>15:15
mupPR snapd#2383 closed: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2383>15:15
ogra_i guess fort thing is to seed acl on core :)15:16
ogra_nice .... not really a dependency chain ... thats easy15:16
ogra_s/fort/first/15:17
zygaogra_: https://github.com/snapcore/pc-amd64/pull/215:17
mupPR pc-amd64#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/2>15:17
zygaogra_: it feels like licenses are missing15:17
ogra_zyga, what licenses ?15:17
zygaogra_: and it would bew nice to have some gardening of the wording in snapcraft.yaml15:18
jdstrandogra_: huh. with all the uaccess rules already there and systemd already in place, I'm curious if that is all you have to do...15:18
zygawell, for those binaries we are shipping now :)15:18
ogra_jdstrand, probably ... lets see :)15:18
ogra_zyga, well, they are built from ubuntu archive source for these arches15:18
jdstrandogra_: that would literally be the best outcome imaginable :)15:18
ogra_yeah :)15:18
ogra_zyga, the licenses in the pi and dragonboard gadgets are only for the binary blobs we can not control and come as-is from upstream ...15:19
ogra_we ship a copy of the GPL in core ... so thats all fine for the gadgets that come completely from source15:20
abeatoogra_, https://bugs.launchpad.net/snappy/+bug/1646144 . I cannot assign, so feel free to auto-assign ;)15:21
mupBug #1646144: ACLs to devices need to be supported in core  <Snappy:New> <https://launchpad.net/bugs/1646144>15:21
ogra_merci !15:21
abeatonp15:22
mupBug #1646144 opened: ACLs to devices need to be supported in core  <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1646144>15:23
mupPR snapcraft#936 opened: nodejs: install during pull to support npm run <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/936>15:25
mupPR snapd#2375 closed: store: retry tweaks and logging <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2375>15:29
zygacjwatson: hey, can you please suggest some lp-shell operation that would un-set the default repo from https://code.launchpad.net/snap-pc15:29
zygacjwatson: so that it shows github-mirror-{i386,amd64} explicitly15:30
zygaogra_: https://github.com/snapcore/pc-amd64/pull/3 and https://github.com/snapcore/pc-i386/pull/115:35
mupPR pc-amd64#3: Correct repo URL <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/3>15:35
mupPR pc-i386#1: Add initial README.md <Created by zyga> <https://github.com/snapcore/pc-i386/pull/1>15:35
zygathanks!15:36
ogra_np15:36
zygaogra_: https://github.com/snapcore/pc-i386/pull/215:38
mupPR pc-i386#2: Add simple snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pc-i386/pull/2>15:38
ogra_not naive this time ? :)15:39
zygacjwatson: no worries, I figured it out :)15:39
zygaogra_: haha, I saw your comment :D15:39
ogra_:)15:39
zygaogra_: so all the base four are done15:40
ogra_yay15:40
zygaogra_: once the mirror is refreshed I'll add snapcraft recipes15:40
ogra_cool15:40
zygaogra_: and I should give slangasek admin rights over this15:40
ogra_yeah15:40
ogra_he has all the store submission rights already15:40
zygaogra_: right, I want to give him github and launchpad project ownership15:41
ogra_the question is ... as what user does the LP build run ?15:41
ogra_you might need to re-own the snaps to snappy-dev (and just add steve to that team)15:41
ogra_else the store submissions will be as zygoon15:41
jdstrandogra_: https://bugs.launchpad.net/snappy/+bug/1646144/comments/215:41
mupBug #1646144: ACLs to devices need to be supported in core  <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1646144>15:41
jdstrandogra_: I have an idea :)15:42
jdstrandogra_: I need to step away for a bit, but this chat of ours today I think may get us somewhere good :)15:42
ogra_:D15:42
ogra_the idea sounds good !15:43
zygajdstrand: I'm curious too :)15:43
mupPR snapcraft#923 closed: pluginhandler: source management moved to the core <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/923>15:43
ogra_zyga, see the bug comment15:43
zygaogra_: I think those are as me15:43
zygaogra_: but I updated my boards, let me check15:44
ogra_essentially, we use ACLs but for additional groups in extrausers15:44
zygaogra_: show up as canonical: http://pastebin.ubuntu.com/23558568/15:44
ogra_i,e, snap-dialout ...15:44
ogra_zyga, thats irrelevant ... i mean the sotre15:44
ogra_**store15:45
zygaogra_: store says the published is canonical15:45
ogra_who is the uploader15:45
zygaogra_: you cannot see that via snap info I suspect ( Chipaca << )15:46
ogra_(the sotre will always say canonical is the publisher ... thats the output side ... i'm concerned about the input side here)15:46
zygaogra_: but my point is that it may not matter if it works15:46
Chipacawhat can't you see?15:46
ogra_no, you can see it in the sotre page15:46
zygaah, from the store page15:46
zygaChipaca: uploader vs publisher on a snap15:46
Chipacayeah, that doesn't reach the client yet15:47
ogra_zyga, it matters as soon as you resign, your account gets closed and alll builds under that account immediately stop15:47
* zyga nod15:47
ogra_sadly i get 504 errors again :/15:47
zyganods even15:47
ogra_so i cant really check15:47
zygayeah, same here15:47
zygaogra_: if that's "Submitted by" then it is indeed me15:48
ogra_right ... i wonder if we can get that team owned15:48
ogra_afaik it is the user who triggered the LP build15:49
zygaI suppose so, it probably depends on the recipe15:49
zygaright15:49
ogra_so if your tree is owned by snappy-dev on LP everyone from the tam can be the owner15:49
ogra_*team15:49
=== JanC is now known as Guest103
=== JanC_ is now known as JanC
ogra_that at least gives the opportunity to have some other account take over instead of having everything killed once an account is closed on LP15:50
zygaogra_: we could have a project group for all the canonical snaps on launchpad15:53
zygaogra_: as a way to find them more easily15:53
zygaslangasek: around?15:59
slangasekzyga: hi15:59
ogra_zyga, well, thats snappy-dev for all others today16:00
zygaslangasek: hey, I wanted to give you and update on where we are for the transition we talked about yesterday16:00
* slangasek nods16:00
zygaslangasek: all the official gadgets are on https://github.com/snapcore/ already16:00
zygaslangasek: we will probably tweak repository names later but they are all there and have the relevant history16:00
slangasekand do I have admin / commit privs on them?16:01
zygaslangasek: they have all been updated with nicer radmes and snapcraft.yamls that work16:01
zygaslangasek: not yet, I need your github handle for that16:01
slangasekzyga: vorlonofportland16:01
zygaslangasek: all but pc are also built all the way to the store already (just waiting for the mirror to enable the last two)16:01
slangasekzyga: did you end up using the pc snapcraft.yaml that sergiusens did?16:01
zygaslangasek: not yet but I plan to next16:01
zygaslangasek: all of the current ones are just dump plugins16:02
slangasekok16:02
ogra_it think tehy are currently all just "dump"16:02
slangasekwfm16:02
ogra_yeah, we'll sort that over time16:02
zygaslangasek: there are also four new launchpad projects, snap-{pi2,pi3,dragonboard,pc}16:02
zygaslangasek: those host mirrors and do the package builds16:02
slangasekonly pc, not pc-i386 vs. pc-amd64?16:02
ogra_nope16:02
zygaslangasek: I need to give you admin access over those so that you can tweak the rest (ownership etc)16:02
ogra_pc can handle both arches16:02
ogra_store side16:03
ogra_LP is where they get merged16:03
zygaslangasek: only one because pc can handle both (on launchpad), it does have two repositories16:03
slangasekbut the gadget contents are different16:03
zygaslangasek: but that can change over time16:03
ogra_yeah, the github trees are too16:03
zygaslangasek: the idea was that those map to snap names exactly with "snap-$SNAP_NAME"16:03
zygaslangasek: github repos for pc were renamed from generic-* to pc-*16:03
zygaslangasek: ogra reviewed all the pull requests sofar16:03
longsleepzyga: its nice to have all the example/reference gadget stuff in one place - i will update my stuff on https://github.com/longsleep/build-pine64-image/tree/snappy/snappy accordingly.16:03
zygaslangasek: and that's about it16:04
zygalongsleep: woot! thank you!16:04
ogra_nobody tested them though ... :)16:04
ogra_or did you zyga ?16:04
zygaogra_: I switched my boards to them but I dind't build images, the content is the same as before thoughj (looking at prime/)16:04
slangasekok, so because the actual snap is named 'pc' this works - yes, understood16:04
ogra_well, then we're fine16:04
zygaslangasek: there are some low hanging fruit that I'll do a pass on also before finishing with this16:05
zygaslangasek: I want to improve snapcraft.yaml's wrt consistency and wording16:05
zyga(summary and description)16:05
slangasekok16:05
zygaslangasek: so that's it :)16:05
longsleepzyga: the only thing which prevents me from releasing snappy stuff for pine64 is the issue that i cannot register my key with snapcraft and that the kernel fails with some aparmor thing which we debugged yesterday. Do you have an ETA when to expect a release of that branch of yours? Or would it be better to search for a fix on the current core release?16:05
slangasekzyga: who will review those snapcraft.yaml changes ? since you don't own these snaps :)16:06
zygalongsleep: ETA 2-3 days to the image PPA from which it gets to edge instantly16:06
ogra_slangasek, well, i handled them in the past, i will go on doing that16:06
zygaslangasek: you and gora16:06
zygaogra16:06
zygaslangasek: those are regular pull requests16:06
zygaslangasek: I plan to add CI for snapcraft but maybe not tonight, I have a few other things to look at16:06
longsleepzyga: ah ok thats good, so i might be able to build a edge image on the weekend or next week16:06
zygaslangasek: let me add you as admin to the repos now16:07
zygaoh, bugget16:08
zygabugger :P16:08
zygalaunchpad cannot build two recipes from one account to the same snap name16:09
zyga"There is already a snap package owned by Zygmunt Krynicki with this name.16:09
zygacjwatson: ^^16:09
zygahttps://code.launchpad.net/~zyga/+snap/pc16:09
longsleepzyga: https://github.com/snapcore/sample-kernels/commits/stable-3.10.y should work yes? So if i would compare whatever was merged into that tree my kernel should work with snappy too?16:09
zygalongsleep: I don't know for sure, perhaps you should ask in #ubuntu-kernel16:10
zygaslangasek, ogra_: have a look at https://code.launchpad.net/~zyga/+snap/pc16:10
longsleepzyga: ok cool thanks16:10
zygais the name under "registered store package name" the only relevant thing16:10
zygaand I can rename this to pc-i386?16:10
* zyga tries16:11
ogra_i think thats the only relevant thing, yeah ... but you cant change it if you want to have it be the same thing in the sotre16:11
ogra_(same thing as amd64)16:11
zygaogra_: compare https://code.launchpad.net/~zyga/+snap/pc-amd64 and https://code.launchpad.net/~zyga/+snap/pc-i386 please16:12
zygaIMHO looks good but ... we'll know when this is done16:12
ogra_ah, yeah, that looks correct16:12
ogra_the name in snapcraft,yaml is also pc for both ?16:13
zygayes16:13
mupPR snapd#2381 closed: image: drop support for UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2381>16:13
zygayou reviwed that :)16:13
ogra_then we should be good16:13
mupPR snapd#2371 closed: daemon, store: let snap info find things in any channel <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2371>16:14
zyganiemeyer: can you please add vorlonofportland to the ubuntu-foundations team on https://github.com/orgs/snapcore/teams/ubuntu-foundations as the team maintainer16:14
zygaslangasek: this will then give you control over https://github.com/orgs/snapcore/teams/ubuntu-foundations/repositories16:15
zygaslangasek: let's talk about launchpad projects, who should own them?16:15
* ogra_ would keep them at snappy-dev and add people as needed to the snappy-dev team 16:16
* zyga nods16:16
ogra_that worked in the past and all other automatic snaps use it16:16
ogra_(core and kernels at least)16:17
ogra_(though the kernel bit might move with the kernel team taking over)16:17
zygaogra_: pc-* builds completed16:20
ogra_yep, i saw16:20
ogra_failed the store review though16:20
zygaogra_: yeah, I'm seeing the same thing16:20
ogra_Could not find compiled binaries for architecture 'i386' lint-snap-v2_architecture_specified_needed (i386)16:21
zygaogra_: interesting: Could not find compiled binaries for architecture 'i386'16:21
zygatyhicks: do you know where to report issues on store review tools?16:21
ogra_well, it worked before ... something is wrong16:22
ogra_bah16:22
ogra_sigh16:22
zygastore review tools may have gotten stronger, dunno16:22
zygacan you look at the snap to triple check it is sane?16:22
ogra_the new store policy will now stop all uploads for pc16:22
ogra_so amd64 wont even go inot testing so we could compare16:22
zygaI see16:22
zygathat's unfortunate, indeed16:22
ogra_yeah, thats a silly policy16:22
zygaogra_: do you want me to push the bbb gadget snap anywhere? I did transition it as well16:23
ogra_push to a bzr branch16:23
zygaogra_: sorry, that was all in git after the repo split :/16:24
zygaogra_: one thing in bzr that we have to do is to remove those old versions from snappy-hub16:24
tyhickszyga: https://bugs.launchpad.net/click-reviewers-tools/+filebug16:24
zygatyhicks: thank you!16:24
tyhicksnp!16:24
ogra_the i386 content looks fine to me16:24
ogra_i see pc-boot.img and pc-core.img as well as grub.cfg16:25
ogra_as it should be16:25
ogra_i dont understand why the check tools would compplain here16:26
zygaogra_: reported as https://bugs.launchpad.net/click-reviewers-tools/+bug/164617616:27
mupBug #1646176: pc gadget snap blocked because it doesn't have i386 executables <Canonical Click Reviewers tools:New> <https://launchpad.net/bugs/1646176>16:27
zygaogra_: I suspect they look for elf files16:27
ogra_zyga, well, it looks identical to the former pc i396 gadget16:27
ogra_**i38616:27
zygaogra_: as I said earlier I suspect the review tools have chanced since it was last uploaded but that's just a theory16:27
ogra_so why would this one fail while the other one went through16:27
ogra_i dont think they changed much in the last three/four weeks16:28
zygaslangasek: I didn't see your response for who should own launchpad objects16:28
zygaok, I need a break, it's gotten very cold up here, time to get some warm tea made16:29
zygaogra_: let me know if I can convince you of a nice shiny git repository16:29
ogra_do it ... :P16:30
zygaogra_: I'd love to help as I want to support beagle boards for my ow needs16:30
zygaogra_: ! :)16:30
zygaogra_: where should we put the repo?16:30
zygaogra_: is there a bbb community that we could use to host this?16:30
zygaogra_: (nice to play in an exisiting playground :)16:30
ogra_i dont think so ... or i dont know about one on github at least16:30
zygaogra_: ok, I'll get that tea and look around16:31
zygaogra_: it would be nice if we could support variou TI boards this way, as long as they have a nice kernel and support ARMv716:31
zygaogra_: I bet you have more than I do :)"16:31
ogra_but i dont think it is bad if either you or me own it16:31
zygaogra_: we could create a small organization and keep those projects there, it's a nice way to attract attention as it's not under anyone's name16:31
zygaogra_: e.g. "beagleboard.org" or something16:31
ogra_we already can support multiple TI boards ... the generic kernel has a bunch of dtb's16:31
ogra_but each would need its own gadget anyway16:32
zygabut I bet there's some organization on github already, we just need to find it16:32
zygaogra_: yes but that's an org, repos are under an owner (org or person)16:32
ogra_and the bbb community wont use our kernel anyway16:32
ogra_we're missing all the rcn-ee patches16:32
ogra_so that gadget isnt really for them16:32
zygaogra_: so could be github.com/beagleboard.org/{beagle,beagleboardblack,...}16:32
zygaogra_: one step at a time :)16:33
ogra_well16:33
ogra_the bbb gadget as is is far from being done16:33
ogra_it is supposed to use raw imgs, not a vfat for uboot ...16:34
zygaogra_: sure, but it doesn't need to be perfect, it's important to find people that are willing to improve it and let them do it16:34
ogra_i had to cripple it due to an ubuntu-image bg16:34
ogra_**bug16:34
ogra_until it is ready for consumption i'd really prefer to not submit it anywhere16:34
zygaogra_: what is the bug?16:34
ogra_a limitation in the sdgisk handling16:35
ogra_it is fixed now16:35
ogra_(you had to assign a partition per raw blob ... that moved the partition numbering and broke uboot... )16:35
kalikianaIs there any way to shadow /usr/bin/ locally from the point of view of a snap? I'm wondering if I can deal with a hard-coded /usr/bin/ without modifying the source16:35
ogra_it needs love (essentially a re-write of the gadget.yaml) that i didnt get to yet16:36
slangasekzyga: I disagree, the launchpad projects should be clearly owned by the foundations team not just snappy-dev16:36
zygakalikiana: yes but it's not supported yet, we plan to support that16:36
zygaslangasek: fine, just give me the team name :)16:36
ogra_slangasek, is there a LP team for foundations used to own branches etc ?16:36
slangasekzyga: canonical-foundations16:36
zygakalikiana: I think it will come to my todo list in Jan next year16:36
zygaslangasek: thank you :)16:36
ogra_(i only know cnaonical-foundations but thought thats organisational)16:36
zygakalikiana: in a release Feb perhaps16:37
slangasek(there is a community ubuntu-foundations team but I'd rather just keep canonical-foundations for now)16:37
kalikianazyga: Okay, I suppose hacking the source it is then. Waiting two months is not an option, but thanks anyway :-D16:37
zygakalikiana: contributions are welcome, if you want to help we could get it in earlier16:37
zygakalikiana: I can work with you and guide you through the code16:37
zygakalikiana: we have machinery for that16:37
zygaslangasek: can you go to https://launchpad.net/snap-pi2 and edit all the other objects to be owned by that team16:38
zygaslangasek: I can no longer do it16:38
zygaslangasek: please also edit git mirror owner16:39
kalikianazyga: I'd be interested in having a look. I don't know at what end that would be tackled at all, though - I have written some snapd code but no clue about other related bits16:39
zygaslangasek: or add me to that team for a moment16:39
zygaslangasek: I think that might be faster16:39
zygakalikiana: you can hack a prototyle locally16:39
slangasekzyga: on a call, I will look at this shortly16:39
zygaslangasek: thank you16:39
zygakalikiana: you can edit the mount profile that looks like an fstab, it is in /var/lib/snapd/mount/profiles AFAIR16:40
zygakalikiana: (it might be gone if you don't have one for a snap but it's easy to create16:40
zygakalikiana: the contents are exactly like an /etc/fstab16:40
zygakalikiana: if you describe a bind mount operation there you can bind mount, e,g. /snap/yoursnapname/revision/bin to /bin16:41
zygakalikiana: you will have to patch snap confine (perhaps) to allow this via an apparmor profile but you can do that live on a running system without rebuilding anything16:41
zygakalikiana: by editing /etc/apparmor.d/usr.lib.snapd.snap-confine16:41
zygakalikiana: (I can show you how)16:41
zygakalikiana: and re-compiling the profile with apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine16:42
zygakalikiana: if that all works the rest is to make that nicer and exposed through snapcraft.yaml16:42
zygakalikiana: from there to snapd16:42
zygakalikiana: and to that file16:42
zygakalikiana: should be very easy to do a quick check if this works for you16:42
zygakalikiana: and if it does I can help you make the contirbutions to snapd and eventually to snapcraft16:43
kalikianaHmmm that sounds simpler than I might've expected16:43
zygakalikiana: the fstab file is named snap.$SNAP_NAME.$APP_NAME AFAIR16:43
zygakalikiana: you can run your program with SNAP_CONFINE_DEBUG=yes in the environment16:43
zygakalikiana: it is pretty useful to see what's going on16:44
zygakalikiana: one important note!16:44
zygakalikiana: you need to run sudo /usr/lib/snapd/snap-discard-ns $SNAP_NAME16:44
zygakalikiana: after every change to the mount profile and invocation of snap-confine16:44
zygakalikiana: we don't have live modification of the mount namespace yet, that's something high on my todo list but it's not done yet16:44
zygakalikiana: try it and ask if you get stuck on anything16:45
zyga:-)16:45
zygakalikiana: and you can look at a snap using the content interface (connected) to see how this file usually looks like and how it is named16:45
zygaslangasek: I'm EODing, please add me to canonical-foundations so that I can complete the move16:53
zygaslangasek: ttyl :)16:53
slangasekzyga: ... no, but I will move over anything you want moved over :)16:53
zygaslangasek: can you move the git repos as well?16:54
slangasekyes, sure16:54
zygaslangasek: unless you have lp superpowerers you may not be able to16:54
zygaslangasek: if you can just go for it :)16:54
slangasekzyga: "git clone" "git push"16:54
zygaslangasek: no.. don't do that16:54
zygaslangasek: those are git mirrors16:54
slangasekheh ok16:54
zygaslangasek: also snap build recipes from those16:54
zygaslangasek: perhaps you can just ask lp admins to change those16:54
slangasekzyga: or should I not just recreate them?16:55
zygaslangasek: in the end you will also have to change all the README.md files as the owner is encoded in the URL16:55
zygaslangasek: well, that'd just duplicate all the work I did, I think it's faster to change the owner16:55
ogra_recreate sounds sanest16:55
zygaogra_: why? this is all checked already16:55
ogra_but that would need super powers16:55
zygaslangasek: wait16:55
zygaslangasek: I can move this to canonical (group)16:56
zygaslangasek: you can move it then to the foundations team16:56
zygaslangasek: ok?16:56
ogra_heh16:56
slangasekzyga: which bit are you moving?16:56
ogra_canonical proxy16:56
zygahttps://code.launchpad.net/~zyga/snap-pi2/+git/github-mirror/+edit16:56
slangasekok16:56
zygaslangasek: try now16:56
zygaoh boy, the snap owenr edit has broken UI :)16:57
ogra_https://code.launchpad.net/~canonical/snap-pi2/+git/github-mirror/+edit seems to offer swithing owners though16:58
zygaslangasek: also https://launchpad.net/~canonical/+snap/pi216:58
zygarepo chown'ed16:59
zyganice!17:00
ogra_yay17:00
zyganow just the package17:00
slangasekzyga: done and done17:00
zygaslangasek: great, I'll move pi3 and the rest next17:00
zygaslangasek: https://code.launchpad.net/snap-pi3 all yours now17:02
zygaslangasek: snap-pc ready for you17:05
zygaslangasek, ogra_: https://github.com/snapcore/pi2/pull/5 https://github.com/snapcore/pi3/pull/3 https://github.com/snapcore/dragonboard/pull/3 https://github.com/snapcore/pc-i386/pull/3 https://github.com/snapcore/pc-amd64/pull/417:15
mupPR pi2#5: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pi2/pull/5>17:15
mupPR pi3#3: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pi3/pull/3>17:15
mupPR dragonboard#3: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/dragonboard/pull/3>17:15
mupPR pc-i386#3: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pc-i386/pull/3>17:15
mupPR pc-amd64#4: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/4>17:15
ogra_all approved17:16
zygaogra_: merge them17:16
zygaogra_: you should have the green button :)17:16
ogra_done17:18
zygaogra_: thanks!17:18
zyga:)17:18
ogra_awful clickery17:18
zygaslangasek: snap-pc doesn't have the nice summary as other snaps do17:19
zygaslangasek: sorry, I didn't notice this earlier when creating the project17:19
zygacompare https://launchpad.net/snap-dragonboard and https://launchpad.net/snap-pc17:20
* zyga EODs17:23
* ogra_ too17:23
zygaogra_: thanks for your help, that was well worth it IMHO :)17:23
zygaogra_: let's talk tomorrow about bbb17:23
zygaogra_: enjoy your evening :)17:24
ogra_i will !17:24
ogra_you too !17:24
mupPR snapd#2299 closed: overlord, daemon, progress: enable building snapd without CGO <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2299>17:26
slangasekzyga: branches and snap recipes transferred, thanks!17:31
zygaslangasek: I think you missed https://code.launchpad.net/~canonical/+snap/dragonboard17:34
slangasekzyga: race condition ;) done now17:34
zygaslangasek: confirmed! all the links from github work as well17:35
zyganice :)17:35
zygathank you for the help17:35
zygaslangasek: you may want to look at https://bugs.launchpad.net/click-reviewers-tools/+bug/1646176 though17:36
mupBug #1646176: pc gadget snap blocked because it doesn't have i386 executables <Canonical Click Reviewers tools:New> <https://launchpad.net/bugs/1646176>17:36
zygaslangasek: it cripples i386 / amd64 gadgets today17:36
mupPR snapd#2389 opened: daemon: close the dup()ed file descriptor to not leak it <Created by chipaca> <https://github.com/snapcore/snapd/pull/2389>17:36
slangasekzyga: by "cripples" you just mean that it prevents auto-publishing to edge, correct?17:37
zygaslangasek: yes17:37
zygaslangasek: they are stale17:37
* slangasek nods17:38
slangasekthough if any of your PRs changed the binary contents of the gadget... :)17:38
zygaslangasek: I'm running those gadgets on my boards / pc's but I didn't try to re-flash17:39
zygaslangasek: I think you should work with QA to propmote some edge revisions to beta to get them tested17:39
zygaslangasek: or candidate before the next release17:39
zygaslangasek: I'll propose some improvements to snapcraft.yaml's because they are ugly-ish and were done in a hurry17:39
zygaslangasek: but those are now normal reviews :)17:39
zygaslangasek: when gustavo adds you to the team on github you will have admin power over all those repos17:40
slangasekzyga: also, I saw your autobuild recipes use xenial. Any reason not to track devel?17:41
zygaslangasek: no opinion on that, right now it doens't matter (IMHO) but perhaps I'm wrong17:41
slangasekI don't think we want to build edge only from binaries that have cleared SRU queue17:41
zygaslangasek: also those are for 16 series which is xenial-ish so ... there17:41
zygaslangasek: but feel free to change those if you think it should be something else17:42
slangasekit's edge; we should take edge bootloader contents17:42
slangasek(switching now)17:42
zygaslangasek: one detail, can you updatet https://launchpad.net/snap-pc to have nicer summary17:42
zygaslangasek: e.g. " The gadget snap for Personal Computers using Intel or AMD processors"17:42
* zyga nod17:43
* zyga nods17:43
zyga(and s is stuck)17:43
ogra_time for a new keyboard ;)17:43
zyganah, I'll just spray some air into it, it's not that old17:44
zygassss17:44
slangasekzyga: I'm unclear what you're wanting changed on https://launchpad.net/snap-pc, I already see a description much like the one for https://launchpad.net/snap-dragonboard17:44
zygaslangasek: the big bold "snap-pc"17:44
slangasekah17:44
zygaslangasek: compare to https://launchpad.net/snap-pi217:44
slangasekdone17:44
zygaslangasek: so that it feels uniform among snap-{pi2,pi3,dragonboard,pc}17:45
zygathanks!17:45
* zyga really EODs now :-)17:45
attentesergiusens: hi, for some reason i keep getting "fatal: unable to access 'https://git.gnome.org/browse/jhbuild/': Failed to connect to git.gnome.org port 443: Connection timed out" from the integration test on github c-i17:46
sergiusenselopio can you check on attente's problem?17:48
mupPR snapd#2390 opened: tests: do not use external snaps <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2390>17:57
zygaslangasek: I've added -gadget suffix to all the repos on github per niemeyer's request, can you please edit the correspodning github/launchpad links. I believe there are some redirects but it is more confusing if we have to rely on those18:10
=== robru_ is now known as robru
slangasekzyga: ack, will do shortly18:25
slangasekzyga: I can't find an option to change the git branch that's the target for mirroring18:42
cwaynezyga: hey, sorry to bother you -- any eta on 'snaps calling other snaps' fix?18:42
mupPR snapcraft#933 closed: _filedir takes an extension, not a glob <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/933>19:19
pedroniscwayne: we don't have a design, either way last I heard it needs to be expressed as some kind of interface (it's setting up a dependency in practice so it needs to be mediated that way to fit)19:23
zygacwayne: progressing, still not done, still pending for .4520:09
zygaslangasek: you mean source, right?20:11
zygaslangasek: I think that's fine, github does the aliases internally20:11
slangasekzyga: ok, then what was it you wanted updated?20:11
zygaslangasek: URLs in in README.md's and on launchpad itself in project description20:13
slangasekah20:13
mhall119jdstrand: has https://issues.apache.org/jira/browse/COUCHDB-3226 been fixed in the mount-observe interface now?20:13
robert_ancelljdstrand, regarding your PR for D-Bus addresses. The first interface I am thinking of is the LigthDM D-Bus service. It seems to me this doesn't make sense as a built-in interface in snapd.20:22
ssweenyI currently use systemd mount dependencies to keep my media server software from starting until the external drive with the media on it is mounted. Is there a way to do that in a snap or do I have to write a startup script that waits on the mount to happen?21:10
jdstrandmhall119: it is in trunk. It should be in 2.1821:14
jdstrandrobert_ancell: hmm, it seems to me like it *would* be an interface21:15
robert_ancelljdstrand, but it only applies to that one snap, and if I changed it in the future it would require modifying snapd...21:16
mhall119jdstrand: I thought 2.18 was released, is it waiting to be SRU'd into 16.04?21:17
mupPR snapcraft#936 closed: nodejs plugin: install during pull to support npm run <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/936>21:19
jdstrandrobert_ancell: that could be said of the network-manager interface as well. that is the nature of interfaces. Interfaces are contracts between consumers and providers. if lightdm is going to be shipped as a snap and going to provide a service, it needs an interface22:03
jdstrandrobert_ancell: the interface can be forward thinking and written in a way to minimize future changes22:04
robert_ancelljdstrand, it just seems like this is not going to scale for the hudreds of other interfaces that need to exist22:05
jdstrandrobert_ancell: again, interfaces are contracts between snaps that may not be coordinating. if lightdm changes in an incompatible way with other snaps, then that needs to be coordinated via snappy such that a new lightdm doesn't break a consuming snap22:07
jdstrandrobert_ancell: if lightdm isn't changing in incompatible ways like that then there is no maintenance issue because snapd shouldn't have to change22:07
jdstrandrobert_ancell: some day the dbus interface might grow to a point that you wouldn't need a separate interface beyond it. however, system services, bus policy, policykit, etc, it isn't there yet22:09
mupPR snapd#2389 closed: daemon: close the dup()ed file descriptor to not leak it <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2389>22:17
mupPR snapcraft#934 closed: deltas: migrate from xdelta to xdelta3 <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/934>22:40
mupPR snapcraft#935 closed: cmake plugin: utilize MakePlugin build logic within CMakePlugin <Created by larryprice> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/935>22:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!