mupBug #1603838 opened: Interface for reading files in /usr <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1603838>00:38
mupBug #1594324 opened: pulseaudio interface needs access to pulse libraries <Snappy:Confirmed for zyga> <https://launchpad.net/bugs/1594324>01:08
skiboySo I feel uncertain about how apps/snap packages will improve the Linux desktop.  Could someone share their reasoning on why apps will improve the user experience?02:15
skiboyLet's take the example of a security update.  Let's say that OpenSSL has a critical vulnerability, and 5 different apps are all bundled with it.  Wouldn't this mean that all 5 apps need to be updated?02:19
skiboyEspecially in third-world countries, where every byte of data matters, wouldn't this be detrimental?02:21
skiboyDo apps actually help the user? Are they worth the bloat? Are they just an easy way out for application developers?02:22
Son_Gokuskiboy, in many ways, it's essentially an easy way out02:54
Son_Gokuone of the things that the snap/flatpak/appimage/etc model does is return the full burden of security to the upstream author02:55
Son_Gokuthe blame lays squarely on them02:55
skiboyAnd I can see the hassle in packaging something for so many different distros...  But I feel it will be to the detriment of the end user...02:56
Son_Gokupackaging for Linux doesn't have to be so hard, and indeed there are several people working on this problem all the time02:56
Son_Gokubut at the end of the day, most people like to cling to enough differences that unifying the underlying architecture that allows for software delivery is not likely to happen02:57
Son_Gokueveryone is guilty of this, even myself02:57
Son_Gokuin many ways, the development of flatpaks, snaps, appimages, etc. is a signal that we've all thrown in the towel02:57
Son_Gokuafter nearly 20 years of trying to push for the better model, most of the folks who are commercially invested in Linux are trying to switch to the Windows model of software distribution02:59
skiboyhow frustrating02:59
=== chihchun_afk is now known as chihchun
Son_Gokunearly a decade ago, the Linux Standards Base attempted to solve this problem, but some distros never fully agreed to implement the specifications03:00
Son_Gokuthe Debian family was a rather big opponent back in the day03:01
skiboybut snap packages aren't replacing apt-get, right?  I can still easily update my system with one command?03:01
Son_Gokueventually, it will03:07
Son_Gokuat least, in Ubuntu03:07
Son_Gokuthe Ubuntu Snappy Core is the prototype of the future of Ubuntu03:07
mupPR snapd#1662 opened: client, cmd, daemon, osutil: support --yaml and --sudoer flags for create-user <Created by mwhudson> <Conflict> <https://github.com/snapcore/snapd/pull/1662>04:48
mupPR snapd#1663 opened: disallow create-user on classic systems <Created by jaymell> <https://github.com/snapcore/snapd/pull/1663>05:53
=== PatrizioQON is now known as pbek
mupPR snapcraft#719 opened: support dest-subdir on dump plugin <Created by ycheng> <https://github.com/snapcore/snapcraft/pull/719>06:50
liuxgdidrocks, I just tried to search for "mysql" and I find a few of them. I want to know how mysql and tomcat are installed in the snap. I think it could be good to have them preassembed somewhhere..07:01
didrocksliuxg: it seems you just volounteered :)07:03
liuxgdidrocks, frankly, I have not tried that yet. I do not know the process for it.07:04
didrocksliuxg: maybe a good opportunity to explore and learn IMHO07:04
=== faenil is now known as faenil_
mupBug #1611639 opened: docs/package-names.md is out of sync with the rest of the project <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1611639>07:23
mupBug #1611641 opened: Running "snap" should produce more helpful output <Snappy:New> <https://launchpad.net/bugs/1611641>07:32
mupPR snapd#1656 closed: snap: do not sort the result of `snap find` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1656>07:39
morphisogra_: not sure, but a sudo /snap/bin/ubuntu-device-flash core 16 --verbose --channel edge --kernel pi2 --gadget pi3 --os ubuntu-core -o test.img gives me an image where the bootloader can't read the initrd08:47
morphisogra_: getting https://paste.ubuntu.com/22893704/08:47
ogra_morphis, well, is there an initrd.img file in / of your boot partition ?09:42
ogra_(that should be in a subdir named like the kernel snap)09:43
morphisogra_: https://paste.ubuntu.com/22896672/09:43
ogra_morphis, yeah, thats what i thought ...09:44
ogra_u-d-f issue09:44
morphismvo: ^^09:44
ogra_(it shoudl copy the initrd and vmlinuz in place and set the snap_kernel var)09:44
mvomorphis: please try "--kernel pi2-kernel"09:50
ogra_i missed that one ...09:50
ogra_it should error out there though09:50
mvomorphis: ideally the code would verify that but I'm not sure its worth the work (given that u-d-f will go away soon)09:50
mvoogra_: yeah, see above09:50
morphisogra_: was using what you gave me yesterday :-)09:55
ogra_mvo, hmm, dont you need --devmode for the snapped u-d-f ? (your mail doesnt mention it)09:55
morphisogra_: you need devmode, yes09:56
* ogra_ cant imagine we have loop device access09:56
* ogra_ answers the mail09:57
ogra_and i'm blind !09:57
* ogra_ blushes09:57
mupPR snapd#1664 opened: integration-tests: add update-rollback stress tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1664>10:03
* zyga -> coffee 10:05
mvoogra_: heh, no worries10:06
morphisogra_, mvo: if I use a local kernel snap do I just have to pass --kernel my.snap or a absolute path?10:17
ogra_both should work (if the snap is in the same dir at least)10:18
timothyzyga: new failures on snapd-git on archlinux10:18
zygatimothy: looking10:21
zygatimothy :thanks, I will report this10:23
zygatimothy: I reported https://bugs.launchpad.net/snappy/+bug/161170610:26
mupBug #1611706: Test suite failures on Arch <Snappy:New> <https://launchpad.net/bugs/1611706>10:26
mupBug #1611706 opened: Test suite failures on Arch <Snappy:New> <https://launchpad.net/bugs/1611706>10:27
zygadholbach: hey10:30
dholbachhey zyga10:30
zygadholbach: I'd like to start publishing content on snapcraft.io10:31
dholbachI don't have access to the page10:31
zygadholbach: how can I do that?10:31
dholbachzyga, https://github.com/ubuntudesign/snapcraft.io10:31
zygadholbach: thank you10:40
morphismvo, ogra_: ok, using a local kernel snap doesn't wor10:41
morphisit don't end up on the boot partition10:42
ogra_morphis, hmm, i thought mvo had added a fix for that yesterday10:42
morphisdoesn't look like10:43
=== davidcalle is now known as davidcalle|afk
joc_zyga: nice blog post, thorough and useful i think10:49
mvomorphis, ogra_: sorry, did not manage that yet, will look after lunch, please keep poking, the world is a busy place for me currently, sorry for that10:50
ogra_no worries10:50
=== hikiko is now known as hikiko|ln
morphismvo: np10:55
mwhudsonogra_: hey hey did you do that thing about making paths writable yet?10:59
ogra_mwhudson, bah, crap ... i forgot it ...10:59
ogra_mwhudson, that was /var/lib/console-conf and /etc/netplan ?11:00
mwhudsonogra_: yes11:01
* mwhudson checks his "things he was going to bug ogra_ about list"11:01
ppisatidoes u-d-f accept local files for the gadget / core snap? i know it does the the kernel snap...11:02
ppisatiand where can i download those files?11:02
mwhudsonyou can extract them from a downloaded image ;-)11:05
* mwhudson unhelpfuls11:05
zygajoc_: thank you :)11:05
ppisatii mainly want to avoid: 1) download time 2) development clashes (e.g. something changes in edge that breaks up my stuff)11:06
ogra_ppisati, it used to, but i'm not sure about the current state, it changed a lot the last days11:10
mvoI look into the kernel sideload bug now11:12
mvoogra_: sideloading amd64 kernel works, is that a problem with pi2 (uboot) only?11:19
ogra_mvo, yeah, i only saw it on amr builds (dragonboard and pi2/3)11:19
mvoaha, ok11:20
ogra_[    6.377542] smsc95xx v1.0.411:23
ogra_[    6.435520] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:c9:2b:0311:23
ogra_[    7.901142] smsc95xx 1-1.1:1.0 enxb827ebc92b03: renamed from eth011:23
ogra_ppisati, any idea why the kernel would ignore net.ifnames=0 ?11:23
ppisatiogra_: it's not the kernel11:25
ppisatiogra_: hold on11:25
mupBug #1593379: systemd 229-4ubuntu6 ignores net.ifnames=0 on USB or /etc/udev/rules.d/80-net-setup-link.rules being a /dev/null symlink <verification-failed> <systemd11:25
mup(Ubuntu):Fix Released by pitti> <systemd (Ubuntu Xenial):In Progress by pitti> <systemd (Debian):Fix Released> <https://launchpad.net/bugs/1593379>11:25
ppisatifixed in yakkety, still open in xenial11:25
* ppisati goes for lunch, back later11:26
ogra_ppisati, ah ... well, that wasnt systemd but the smsc95xx driver printing the above11:30
ogra_would systemd change it back ? (i would expect the kernel to not rename it at all)11:31
=== chihchun is now known as chihchun_afk
=== hikiko|ln is now known as hikiko
mvoppisati, ogra_: can you please try r4 of u-d-f from the store? it should fix the kernel sideload bug12:22
* ogra_ just tested the pi3 image with the new ubuntu-core from the store, looks fine 12:22
ogra_i'll test a sideloaded kernel next12:23
ogra_hmmm .... hmmmmm ...12:26
ogra_morphis, did you try to build an armhf snap for u-d-f too ?12:27
ogra_i wonder if you could build an image on the pi or dragonboard on an all-snap system :)12:27
josephtsergiusens: didrocks brings up a good point in the sub-parts mailing list thread regarding older versions of snapcraft needing the still namespaced part names.  I think we can work around it by having the namespaced part names explicitly in the wiki and updating the origins.12:42
josephti.e. parts: [desktop/gtk2, desktop/gtk3, ...] and another entry with "parts: [desktop-gtk2, desktop-gtk3, ...]12:43
jdstrandnoise][: that's fine. I've got a meeting in a few minutes but suspect that next commit in less than 2 hours12:45
morphisogra_: no :-)12:54
liuxghas anyone ever snapped tomcat into snap?12:57
ogra_yeah, in 15.04 ... not sure if there is a s16 snap12:58
liuxgogra_, would you please show me the project? thanks12:59
ogra_no idea where that lives13:01
liuxgogra_, a customer is using apache, tomcat, mysql, java for a server on ubuntu core. I am trying to find out how we can package the stuff into a snap.13:02
ogra_i only remember someone packaging it13:02
ogra_iirc either asac or lool13:02
liuxgasac, lool, have you every packaged tomcat into a snap? a customer is trying to build a apache server with tomcat. thanks13:03
ogra_(probably asking on gitter in the snappy-playpen channel makes more sense though )13:04
ogra_didrocks, ^^^ didnt mosquitto use tomcat ?13:05
ogra_iirc you worked on that13:05
=== mterry_ is now known as mterry
liuxgogra_, mosquitto does not use tomcat, it uses MQTT to do thaht.13:06
didrocksyeah, only mqtt AFAIK13:10
liuxgdidrocks, ogra_,  if tomcat is not in the official ubuntu archive, we cannot install it directly from the debian packages, right? we have to use the source code to build it, right?13:11
ogra_well, arent there tarballs with binaries ?13:12
ogra_i see tomcat in the archive though13:13
ogra_7 and 813:14
ppisatiogra_: the kernel is printing it because the rename function (dev_change_name()) is invoked through an ioctl()13:16
ppisatiogra_: if you try with the xenial's release systemd package, you won't hit that13:16
didrocksliuxg: you can always at worse download the content of binaries and uncompress while using the copy/dump plugins13:17
ogra_ppisati, ok, i was just curious since that happens before init even runs i think13:17
liuxgdidrocks, the thing is that we need to copy to the right place in the snap. we have to know where the files should go.13:19
loolliuxg: Hi, here's the sample snap I did with Tomcat a long while ago https://github.com/snapcore/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml13:20
loolliuxg: it is not very fancy, but it worked; let me know how it goes13:20
didrocksliuxg: indeed13:21
loolliuxg: I'm travelling this week, so a bit hard to reach13:21
liuxglool, many thanks for your help. I will take a look at it. Have a good trip!13:21
liuxgdidrocks, lool, strange, "dump" is not listed when I use "snapcraft list-plugins". is this a bug?13:23
loolliuxg: It's the first time I hear about it; I think this example was modified when this plugin landed in snapcraft13:23
didrocksliuxg: it will be available with the next version of snapcraft (which is in -proposed right now)13:23
ogra_dump is the new name for the copy plugin i think13:24
liuxgdidrocks, my current snapcraft version is 2.13.1, what will be next release?13:25
liuxgogra_, do you mean that I can use "copy" to replace it?13:25
ogra_or just look at an older version of the branch :)13:26
liuxgogra_, then in the example https://github.com/snapcore/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml#L17, it does not specify the destination, will it work?13:26
liuxgogra_, sorry, this is the line https://github.com/snapcore/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml#L2213:27
liuxgdidrocks,  do you know how I can make use of the latest snapcraft (-proposed)? my snapcraft is from the stable channel so far.13:28
didrocksliuxg: you can just wget the package on launchpad and install it manually13:28
didrockswith dpkg -i13:28
ogra_liuxg, this is the snapcraft.yaml from before the rename (seems it wasnt only copy that got renamed to dump) https://github.com/snapcore/snapcraft/blob/f0a19ebccfa3f0502b792095d4b0edae4e04eb68/demos/tomcat-maven-webapp/snapcraft.yaml13:29
liuxgdidrocks, OK, I will have a try. thanks. previously, I just directly installed it from the source, and I messed up everything.13:30
didrocksyeah, you can go this way, it's safer :)13:30
liuxgogra_, thanks for your help. yeah, it looks different13:31
liuxglool, what is the purpose of the file ".travis.yml" in the project https://github.com/lool/snappy-mvn-demo/blob/master/.travis.yml? thanks13:47
loolliuxg: it's to trigger a travis build when something gets pushed or when a pull request is made13:48
loolliuxg: see travis-ci.org13:48
loolliuxg: I dont think it worked correctly for that project though13:48
liuxglool, I just tried to compile it, it failed. I compiled it using the its previous version http://paste.ubuntu.com/22912200/13:49
liuxglool, the error message is like http://paste.ubuntu.com/22912252/13:50
liuxgdidrocks, where did you find the binaries for the snapcraft on launchpad? I found a site https://launchpad.net/snapcraft/trunk, but I did not get the release file? thanks14:00
didrocksliuxg: https://launchpad.net/ubuntu/+source/snapcraft/2.14/+build/1058918014:00
didrockssee "built files"14:00
liuxgdidrocks, yes, I saw it. thanks14:01
ogra_ogra@anubis:~/datengrab/images/snappy$ sudo snap refresh --channel=beta ubuntu-device-flash14:02
ogra_error: cannot refresh "ubuntu-device-flash": snap "ubuntu-device-flash" has no updates available14:02
ogra_mvo, ^^^ did you publish the new u-d-f ?14:02
ogra_ignore that ... needs --devmode too14:03
ogra_error: cannot perform the following tasks:14:03
ogra_- Setup snap "ubuntu-device-flash" (4) security profiles (cannot setup apparmor for snap "ubuntu-device-flash": cannot load apparmor profile "snap.ubuntu-device-flash.ubuntu-device-flash": cannot load apparmor profile: exit status 1014:03
* didrocks was going to suggest that14:03
ogra_apparmor_parser output:14:03
mvoogra_: wuut14:04
mvoogra_: how can apparmor fail for a devmode snap :(14:04
mvoogra_: if the file is still there, can you pastebinit ? (I guess its not :/14:05
ogra_now ... that didbnt go so well ... calling u-d-f anyway after that error had-locked my machine14:07
* ogra_ removes and re-installs14:08
ogra_that looks better14:08
liuxglool, ogra_, I have upgraded my snapcraft to 2.14, but I still get the same error when I tried to build the tomcat demo example https://github.com/snapcore/snapcraft/tree/master/demos/tomcat-maven-webapp. the error message is like http://paste.ubuntu.com/22913740/, do I miss anything there?14:09
jdstrandmvo: note, the apparmor policy is wholly present with --devmode-- all that is different is the complain flag14:10
zygajdstrand: hey, I posted another interface article on my blog, feedback welcome :-)14:10
zygamvo: hmm?14:10
mvoogra_: that is still pretty terrible, this is snapd 2.11?14:11
mvojdstrand: oh, ok14:11
zygamvo: devmode can still fail, it's just another profile14:11
jdstrandmvo: so if there is an error in the policy then it will fail to parse. also, if this is done on a machine that doesn't have an updated parser for newer rules (like unix), it will fail to parse14:11
mvozyga: see above, ogra_ installed an update of ubuntu-device-flash and the install aborted with an exit 1014:11
ogra_ogra@anubis:~/datengrab/images/snappy$ snap --version14:11
ogra_snap    2.11+0.16.0414:11
ogra_snapd   2.11+0.16.0414:11
ogra_series  1614:11
ogra_ubuntu  16.0414:11
jdstrandis this by chance running on a trusty machine?14:11
ogra_there is no snap on trusty :)14:11
mvojdstrand: well, I did not do anything with the policy14:11
mvojdstrand: this is a quick-n-dirty devmode snap of ubuntu-device-flash14:12
zygamvo: we should see exactly what apparmor_parser said14:12
ogra_it worked fine after snap remove and snap install14:12
zygaogra_: can you pastebin the profile from /var/lib/snapd/apparmor/profiles please14:12
ogra_zyga, i fear thats gone now ... but indeed i can14:12
zygamvo: maybe there's a bug in some of the intefaces that causes this to fail14:12
ogra_(i mean the broken one is gone)14:12
zygaogra_: this looks like a efault template14:13
mvoogra_: anything in snap changes or snap change XX (nr) that might give a clue?14:13
mvozyga: it is14:14
zygaogra_: if that fails then all the snaps will fail the same way14:14
zygaogra_: can you install hello-world snap please?14:14
ogra_mvo, http://paste.ubuntu.com/22914167/14:14
jdstrandartmello_: hey14:15
artmello_jdstrand: hey14:15
ogra_zyga, installed14:16
=== artmello_ is now known as artmello
jdstrandartmello_: are you planning on snapping the thumbnailer service or assuming it will be present on the system?14:16
mvojdstrand: does exit-code 10 has any meaning (context is http://paste.ubuntu.com/22914167/)14:16
artmellojdstrand: snapping it. I have an untested snap of it but I was thinking about fixing the interface first14:17
artmellojdstrand: but I can start using the snap thumbnailer during these tests14:17
jdstrandartmello: ok, so 'classic' is the traditional Ubuntu desktop system and interfaces that access those services need different policy than those that are services as snaps14:18
artmellojdstrand: ok14:18
jdstrandartmello: because you are snapping thumbnailer, you don't have to worry about classic at this time14:18
artmellojdstrand: right14:19
jdstrandartmello: so, yes, do the ConnectedSlotAppArmor stuff I mentioned in privmsg. when testing, you'll want to remove the thumbnailer service deb and install the thumbnailer service snap14:19
jdstrand(so the snap can bind to the dbus interface, etc)14:20
=== davmor2_ is now known as davmor2
jdstrandartmello: but you'll need to adjust the thumbnailer to not do the security label check any more (since it doesn't have to with interface connections)14:20
artmellojdstrand: right, will change thumbnailer as you suggested14:21
jdstrandartmello: (or again, if sharing codesbases for the thumbnailer with click, short-circuit with the snap. check I mentioned)14:21
artmellojdstrand: ok, thx! I undertood it better now. Will apply the changes and see how it goes14:24
zygaogra_: hmmmm so if that doesn't fail then I have no idea14:24
zygaogra_: is the problem reproducible?14:24
ogra_zyga, dunno, i can tell you the next time i upgrade something in --beta with --devmode from the store i guess14:24
kyrofaogra_, mvo can we release the OS snaps into staging as part of our process as well?14:25
sergiusensjosepht we can just pick up another cache file14:25
jdstrandmvo: '10' doesn't mean much to me. that seems to be ECHILD...14:25
ogra_perhaps mvo can upload a no-change snap of u-d-f so i can re-test (though perhaps that should wait til after the meeting, i dont want to have to hit the reset button during meeting :))14:25
ogra_kyrofa, i just released a set today14:26
jdstrandwhat is the snap.yaml of ubuntu-device-flash?14:26
kyrofaogra_, ah, into staging as well?14:26
mvokyrofa: staging? you mean candidate?14:26
kyrofamvo, no, the staging server14:26
kyrofamvo, staging store, whatever it's called14:26
mvokyrofa: oh, sorry. hm, yes we can :)14:26
ogra_kyrofa, i'm waiting for jdstrand's review tools fix to land to see how the auto-landing goes ... but i think we still need to manually hit the publish button14:26
kyrofamvo, if you setup a clean machine and point it to staging, there's no OS snap to pull down so you can't install anything :)14:26
kyrofamvo, easy workaround, but if that's something we can automate it'd be useful14:27
mvokyrofa: I shared it with you, you can now just download it directly from the real store and upload to staging as you need14:28
kyrofamvo, ah, super useful thank you!14:28
mvokyrofa: +1 for automation, we are still working on that, its still very manual right now (manual approve, manual publish, lots of button clicks :/14:28
ogra_kyrofa, i guess thats also a cjwatson question if LP can offer uploads to staging14:29
ogra_(if there is a way i'll happily add a parallel ubuntu-core build, thats trivial)14:29
ogra_reading pi2-kernel_x1.snap/kernel.img14:31
ogra_** Unable to read file pi2-kernel_x1.snap/kernel.img **14:31
ogra_reading pi2-kernel_x1.snap/initrd.img14:31
ogra_** Unable to read file pi2-kernel_x1.snap/initrd.img **14:31
ogra_Bad Linux ARM zImage magic!14:31
kyrofaogra_, oh, good point14:31
ogra_mvo, ^^^14:31
cjwatsonogra_: only from LP staging14:32
ogra_ah, well, then i should be able to set something up (i have to check if i still have staging access)14:32
cjwatsonstaging access isn't a special thing14:33
cjwatsonbut it does require a separate staging SSO account14:33
cjwatsonand staging LP isn't up all the time14:33
mvoogra_: can you run "file pi2-kernel_x1.snap/kernel.img" (and the same for initrd.img?14:33
ogra_ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/14:33
mvoogra_: and what commandline did you use? I will try to reproduce14:33
ogra_same issue as before14:33
mvoogra_: hm, hm14:34
ogra_and no kernel/initrd in system-boot at all14:34
ogra_ogra@anubis:~/datengrab/images/snappy$ sudo /snap/bin/ubuntu-device-flash core 16 --channel edge --gadget pi3 --kernel pi2-kernel_4.4.0-1019-raspi2_armhf.snap --os ubuntu-core -o test-pi3.img14:36
ogra_that was what i used for building ... the kernel was manually downloaded from the store14:36
mupPR snapcraft#719 closed: support dest-subdir on dump plugin <Created by ycheng> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/719>14:38
=== matiasb1 is now known as matiasb
stokachuis network-control the only plug i need so that my snap can create a network bridge?14:51
ogra_well, you probably also want to use thenetwork .. so the "network" plug would also be handy in that case14:51
stokachuok, problem is when i set those 2 and attempt to run my snap it just errors with "Bad system call"14:52
stokachuthis is running in strict mode14:53
stokachuthats my log output14:54
jdstrandstokachu: assuming this is amd64, you need network-bind (scmp_sys_resolver 49 shows as bind)14:55
jdstrandstokachu: no if you aren't actually binding to a network port, then the network-control interface should probably include bind14:55
stokachujdstrand: yea im just creating a bridge for my lxd containers to use14:56
jdstrandstokachu: can you file a bug and add the 'snapd-interface' tag with a simple reproducer for needing bind?14:58
stokachujdstrand: sure thing14:59
jdstrandstokachu: and mention the workaround is to use 'network-bind'14:59
jdstrandstokachu: thanks! :)14:59
stokachujdstrand: np, building now and testing to make sure it won't fail14:59
sergiusenselopio do you want to tackle https://bugs.launchpad.net/snapcraft/+bug/1611498 ?15:00
mupBug #1611498: snapcraft fails install using virtualenv instructions <Snapcraft:Triaged> <https://launchpad.net/bugs/1611498>15:00
sergiusensnext week15:01
sergiusensor maybe josepht as you got this going in the first place ^15:01
stokachujdstrand: cool! works15:01
josephtsergiusens: I can take care of that15:02
josephtelopio: ^15:02
liuxgsergiusens, I just tried to build the demo example at https://github.com/snapcore/snapcraft/tree/master/demos/tomcat-maven-webapp, there was an error. I do not know how to correct the problem for it. I have upgraded my snapcraft to 2.14 already. thanks15:02
jdstrandstokachu: nice! :)15:02
draglyis http://search.apps.ubuntu.com down?15:04
ppisatiGetting details for ubuntu-core15:13
ppisatiExpecting value: line 1 column 1 (char 0)15:13
ppisatisnapcraft just returned this while trying to fecth ubuntu-core15:14
OerHeksdragly, there is an update going on, launchpad is down too.15:14
ogra_ppisati, funny error ... and so descriptive :P15:14
draglyOerHeks: Okay. Thanks :)15:14
ppisatiogra_: :(15:14
ppisatii hope is connected to the lp / store/ etc downtime15:14
ogra_ppisati, thats the kernel plugin trying to get the initrd from the store ?15:14
ahasenackis it true you cannot snap an app that starts as root and then drops its privileges?15:15
ppisatiogra_: yep, to download the ubuntu-core snap i think15:15
ahasenackI'm checking https://developer.ubuntu.com/en/snappy/build-apps/debug/#common-problems15:16
ahasenackthe switch from root to unprivileged user (or any other user) is blocked?15:16
ogra_ahasenack, where to would it drop its privs ?15:16
ogra_there are no users15:17
ahasenackis that the reason?15:17
ahasenackor is the set?uid call blocked?/15:17
ogra_asnd there is no ability to create any from a snap15:17
ahasenackit could be a default user from /etc/passwd15:17
ogra_setuid gets stripped out by snapcraft at build time15:17
ahasenackshipped in the base system15:17
ogra_and daemons/services always run as root15:17
ahasenackI meant the syscall, not the setuid bit on a file15:17
ogra_yeah,m i think thats blocked, together with fchown and others15:18
ahasenacknot in the real world, there good services run as unprivileged users. I understand apparmor can confine root, sure15:18
niemeyerahasenack: A couple of aspects to that:15:21
niemeyerahasenack: snapd can easily mediate any interactions around that, including privilege dropping15:22
niemeyerahasenack: So if there are requirements, we can cook the proper interface lifting the exact allowances the application would need for doing its job15:22
niemeyerahasenack: Unfortunately and ironically, "dropping" privileges is often done with system calls that allows *gaining* privileges15:23
sergiusensppisati please log a bug for that :-)15:23
niemeyerahasenack: So although the app intent is good, relinquishing access to certain things, from a system perspective it may not be advantageous to allow even the initial phase of the application to do those actions15:24
niemeyerahasenack: So, YMMV.. I wouldn't strongly prescribe anything at this point.. I know you are very security-mindful, and if you have suggestions or would like to research about how much to give and how much to take, that'd be very welcome15:25
mupBug #1611819 opened: implement a way for daemons to play audio <Snappy:New> <https://launchpad.net/bugs/1611819>15:26
elopiosergiusens: pong.15:26
jdstrandahasenack: we are going to support privilege dropping, we first need snap-confine in xenial-updates, then we'll allow something, perhaps priv dropping to 'daemon'. later we might allow requesting a uid and/or gid and dropping to that (that would be farther out)15:26
niemeyerjdstrand: Nice15:27
jdstrandI feel like I keep talking about snap-confine landing. fingers crossed it will be soon :)15:28
jdstrandthat said, I have several things on my plate to get to before that, so that's ok15:29
jdstrandnoise][: hey, Canonical irc seems down so mentioning here15:36
jdstrandnoise][: r706 is ready to pull. that, among other things, will do what ogra_ asked me to address wrt auto-approve of the ubuntu-core snap15:37
kyrofajdstrand, yep, lost it here too15:37
ogra_jdstrand, that includes the confinement complaint too ?15:39
ogra_(or was that not causing a block)15:39
jdstrandogra_: can you give me the link to the snap that had that?15:40
ogra_if the store lets me in :P15:40
jdstrandogra_: the issue was 'confinement' not being present?15:40
ogra_no, being present in a non "app" snap15:41
joc_jdstrand: hi, i'm trying to confirm if the udev tagging for cgroup access is working for me as discussed yesterday, i'm finding that i get access to everything matched by /dev/** though15:41
mupPR snapcraft#679 closed: add multiple generator script options to autotools <Created by apachelogger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/679>15:41
ogra_jdstrand, the messages are:15:41
ogra_'confinement' should only be specified with 'type: app' lint-snap-v2_confinement_valid15:41
ogra_(NEEDS REVIEW) type 'os' not allowed lint-snap-v2_snap_type_redflag15:41
jdstrandogra_: I fixed the second15:42
ogra_sadly snapcraft forcefully adds "confinement: strict" to all builds regardless of type15:42
joc_jdstrand: do i need to check that i have a particular version of snap-confine running?15:42
ogra_can we have the first one not be a blocker ?15:42
jdstrandogra_: ok, yeah, I didn't fix the first one.15:42
sergiusensogra_ sadly there is no requirement for it to be any different either ;-)15:42
jdstrandnoise][: give me a few minutes for r70715:42
ogra_sergiusens, well, it will make all auto uploads for os or kernel snaps fail atm15:42
jdstrandjoc_: use snap-confine from xenial-proposed15:43
ogra_sergiusens, but yeah, it is completely ignored by snapd at install or image build time15:43
jdstrandconfinement makes no sense with the core snap15:43
sergiusensogra_ a requirement means that all interested members of the party should comply for things to work though ;-)15:43
ogra_jdstrand, agreed, but it also doesnt do any harm since it is ignored everywhere15:43
joc_jdstrand: i'm using an all-snap image to test on device15:43
jdstrandI'm just saying why the test is what it is15:44
ogra_jdstrand, i'd be fine with a warning as long as it doesnt block the upload15:44
jdstrandogra_: I'll fix it. I'm not saying I won't, just saying snapcraft imho shouldn't adding meaningless yaml15:44
ogra_jdstrand, agreed, i blame kyrofa and sergiusens :P15:45
sergiusensjdstrand ogra_ if it makes no sense a bug report is enough15:45
ogra_i think i opened one15:45
* ogra_ goes digging15:45
sergiusensogra_ I blame you for not doing a full end to end analysis ;-)15:45
jdstrandjoc_: I haven't used all snaps systems in ages cause of all the churn. I don't know if it is using snap-confine or not. does /usr/lib/snapd/snap-confine exist?15:45
ogra_sergiusens, bug 160745915:45
mupBug #1607459: type:os should prevent adding "confinement" to the snap.yaml <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1607459>15:46
dholbachall rightie - I call it a day - see you in two weeks! :-)15:46
sergiusenskyrofa ^15:46
ogra_i should change that to "os and kernel"15:46
sergiusenswant to take that confinement thing?15:46
* ogra_ hugs sergiusens 15:46
sergiusensogra_ there you go, bug only said os ;-)15:46
sergiusensogra_ what about gadget?15:46
ogra_yeah, that too i guess15:46
sergiusensthe kernel can have hooks15:46
joc_jdstrand: no it's not in my image15:47
jdstrandit is less clear for kernel and gadget15:47
sergiusensdon't you think running the hooks in devmode might be a good thing?15:47
ogra_i doubt we will have gadget auto-uploads though15:47
sergiusensjdstrand which is why I bring it up :-)15:47
sergiusenshooks change everything15:47
ogra_these things are usually one-time uploads that do not change very frequently once they are stable15:47
jdstrandI don't have an answer for those. my understanding is for both they may have parts that are confined15:47
jdstrandat some point15:47
jdstrandbut I don't know the status today15:47
sergiusensjdstrand also, once we have the core for say fedora, won't confinement make a little sense at least for the os snap in case the confinement part is not fully implemented15:48
sergiusensbut that is all zyga's grand scheme of things thing ^15:48
jdstrandjoc_: can you give me ~20 minutes then I can give you my full attention?15:48
joc_jdstrand: sure15:48
jdstrandbut... ogra_ what needs to happen to make snap-confine in the core snap instead of ubuntu-core-launcher? snap-confine landing in xenial-proposed and because ubuntu-core-launcher is a transitional package it will pull in snap-confine?15:50
ogra_jdstrand, we need to drop u-c-l and add snap-confine to the "seed" (which we dont really have, it is a hardcoded package list in livecd-rootfs)15:51
jdstrandogra_: I'm somewhat concerned if that is the case because snap-confine continues to not make it through SRU and joc_ and his team are going to need this for their testing15:51
ogra_(bacuse you cant change seeds for released LTSes)15:51
jdstrandogra_: will that process pull in from xenial-proposed?15:51
kyrofasergiusens, sure, assign that one to me, I'll put it on my snapcraft backlog15:51
ogra_you mean move it to the archive ?15:51
ogra_thats an archive admin task ...15:52
ogra_totally unrelated ot any seeds or dependencies15:52
ogra_moving it to main once it did move to the archive proper will need a dependency ... but getting out out of proposed has nothing to do with this15:52
jdstrandogra_: no. well, I don't know. joc_ and his team will need snap-confine in the image ideally now so they can test with the real bits that will be in rtm. it is in xenial-proposed. is there a way to make that happen?15:53
sergiusenskyrofa just make sure to bring up the conflicts about type: core, gadget and kernel and if confinement makes sense; also think about core coming from say another distro (think about the built-on tag we discussed in Heildelberg) and think about the fact that some cores might not implement all the confinement primitives (where in that case the core snap would be devmode I guess)15:53
jdstrandogra_: I'm talking about core snap, not classic15:53
jdstrandnot sure if that makes a difference15:53
sergiusenskyrofa more of a research first implement later15:53
ogra_jdstrand, let me check ...15:54
ogra_Get:77 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main armhf snap-confine armhf 1.0.38-0ubuntu0.16.04.4 [19.6 kB]15:54
kyrofasergiusens, indeed, good points15:54
kyrofaI'll mention in standup tomorrow15:54
ogra_seems it is alreayd pulled in but someone forgot to delete an older version from the image PPA15:54
sergiusenskyrofa let me just add that to the bug15:54
ogra_OH, wait15:54
ogra_Get:77 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main armhf snap-confine armhf 1.0.38-0ubuntu0.16.04.4 [19.6 kB]15:54
ogra_yeah, it comes from porposed ... the ppa just confused me15:55
jdstrandjoc_: ^ perhaps you can work with ogra_ on obtaining the correct core snap?15:55
ogra_joc_, jdstrand so it is in the last edge ubuntu-core15:55
jdstrandogra_: great, thanks! :)15:55
sergiusensogra_ don't log ubuntu bugs!15:55
sergiusensogra_ those get ignored by us15:55
ogra_btw, daily builds and build logs are at https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core15:55
ogra_sergiusens, so ignorant :P15:56
sergiusensthis is why we missed it15:56
ogra_sergiusens, what if people follow the distro guidelines for filing bugs then ?15:56
ogra_(which tell you to use "ubuntu-bug snapcraft" )15:56
sergiusensogra_ the distro guys should then link them ;-)15:56
joc_jdstrand: ogok thanks, i can try and use the recent ubuntu-device-flash to spin a new image15:56
sergiusensogra_ as any other upstream15:56
ogra_sergiusens, which distro guys would look at them, i dont hink anyone is subscribed to the package15:57
ogra_yxou would need a responsible team that subscribes to them15:57
sergiusensogra_ and that is why so many bugs get unresolved ;-)15:57
ogra_someone needs to take them15:57
draglyzyga: I might be using it wrong, but running snapd-hacker-toolbelt.busybox ls /var/lib/snapd/lib/gl/ gives me "Permission denied". Could that be the issue, or do I have to give the snapd-hacker-toolbelt some permission before it can do ls?15:57
ogra_since ubuntu users are told to zuse ubuntu-bug by all docs we have15:57
zygadragly: connect the opengl interface15:59
sergiusensogra_ in any case, if I look at the bugs on the package I see most of them are logged by distro people. All others consuming snapcraft drt ;-)15:59
zygadragly: by default it is probably off-limits15:59
sergiusensogra_ more reason to move to a snap ASAP as well ;-)15:59
ogra_sergiusens, well, you should talk to foundations i guess to subscribe to the distro bugs then15:59
draglyCan I do that after installing it or do I need to rebuild the snapd-hacker-toolbelt snap?16:00
ogra_sergiusens, will a snapcraft snap work in classic mode on an all snap image ?16:00
ogra_mvo, ^^^ do you know ?16:00
ogra_(thats most likely the biggest reason to use a classic shell on an all-snap image)16:00
sergiusensogra_ nah, I'll let you do it; the package bugs are pretty much the same as someone mentioning bugs in a mailing list, forum or redit16:00
sergiusensogra_ we won't need classic16:01
sergiusensogra_ all we will need is lxd16:01
mvosergiusens: but we can use classic until lxd is ready?16:01
* sergiusens is feeling feisty today16:02
sergiusensmvo yeah, just like before it went away :-)16:02
draglyzyga: Or is editing snaps directly in the /snap folder okay while debugging?16:02
mupPR snapd#1665 opened: many: do not require root for `snap prepare-image` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1665>16:03
ogra_mvo, well, i can still imagine that people using the classic shell want to use binaries from installed snaps in there, we should plan for that16:03
ogra_(it isnt like we dont have everything we need in there already)16:04
ogra_(but i doubt the setup is ready OOTB currently)16:04
mupBug #1611837 opened: all-snaps: Boot breaks on reset in VirtualBox <Snappy:New> <https://launchpad.net/bugs/1611837>16:05
mvosergiusens: pfffff ;)16:06
mvoogra_: the way the kernel.img/initrd.img is extracted will change soon, once that change lands we can no longer use a symlink inside the kernel, it needs to be the actual file, could you please update livecd-rootfs so that the real file is kernel.img/initrd.img and the others are symlinks?16:08
ogra_mvo, well, i'll ripp all that code out of livecd-rootfs ... but yeah, i'll take it into account for the automated kernel snaps16:09
ogra_mvo, do we need the versioned filenames at all then ?16:09
mvoogra_: no, it might just be nice for manual inspections16:10
ogra_(i remember some requirement about matching versions in the kernel yaml spec)16:10
mvoogra_: we may need it soon, but I can can manually tweak the snaps if needed, it just needs to be there16:10
mvoogra_: kernel.yaml got killed16:10
ogra_oh ?16:10
ogra_when ?16:10
ogra_today ?16:10
mvoogra_: during the heidelberg sprint, I think you were in the session ;) but maybe not, I'm not sure, its definitely in the notes16:11
* ogra_ rips caps off his kbd16:12
mvoogra_: but the kernel version and the version string in snap/meta.yaml much match (eh meta/snap.yaml)16:12
mvoogra_: uh, no need to shout16:12
ogra_yeah, sorry16:12
* ogra_ hands out earplugs16:12
kyrofajdstrand, zyga where is the SRU bug for snap-confine?16:12
mvoogra_: aha, ok. well, I don't remember the details but I have it in the kernel/gadget.yaml notes, so less work16:12
* mvo switches network16:12
kyrofaJeez ogra_, take it easy16:12
ogra_mvo, werll, thats a snapcraft thing, none of my code touches snap.yaml anymore ... it is all snapcraft now16:13
jdstrandkyrofa: https://people.canonical.com/~ubuntu-archive/pending-sru.html16:14
jdstrandkyrofa: oddly, it is listed but with no bugs16:14
kyrofajdstrand, indeed, I was just looking to subscribe to it so I knew when it made it through16:14
jdstrandkyrofa: I think that is because 1.0.38-0ubuntu0.16.04.4 fixed something and it needed -v16:14
stokachuso im trying to access a binary that I pull in via stage-packages and getting this error in strict mode:16:15
ogra_mvo, so what exactly needs to match ... snapcraft.yaml's version vs /lib/modules/$name-$version/ ?16:15
stokachuAug 10 11:54:32 deadpool kernel: [898974.105170] audit: type=1400 audit(1470844472.128:48571): apparmor="DENIED" operation="bind" profile="snap.conjure-up.conjure-up" pid=9807 comm="juju" family="unix" sock_type="stream" protocol=0 requested_mask="bind" denied_mask="bind" addr="@/var/lib/juju/mutex-/store-lock"16:15
jdstrandkyrofa: mvo, I see snap-confine in pending-sru has no bugs. as such it will never get attention from the sru team. I think you needed to have the changelog include pervious versions16:15
kyrofastokachu, try adding the network-bind plug16:15
stokachui have network, network-control, network-bind as my plugs16:15
kyrofaOh, /var/lib/juju, yeah16:16
stokachudo i need to do plugs for the juju binary?16:16
jdstrandstokachu: https://bugs.launchpad.net/snappy/+bug/160496716:16
mupBug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>16:16
stokachuah :)16:16
jdstrandI have a PR that is started but it got pushed behind a couple other things16:17
stokachujdstrand: ok, i can run in devmode for now16:17
jdstrandyeah, was just going to suggest that16:17
stokachujdstrand: thanks, ill keep an eye on that bug16:17
jdstrandmvo_: s/changelog/changes/16:17
draglyShould --devmode allow a snap to access the entire system or is it still sandboxed?16:20
mvo_jdstrand: sorry, I got disconnected, what did you say earlier?16:20
kyrofamvo_, you mean this?16:24
kyrofa<jdstrand> kyrofa: mvo, I see snap-confine in pending-sru has no bugs. as such it will never get attention from the sru team. I think you needed to have the changelog include pervious versions16:24
jdstrandthanks kyrofa :)16:24
jdstrandmvo_: that was it ^16:24
jdstrandogra_: with r707: $ PYTHONPATH=./ ./bin/click-review ../click-reviewers-tools-test-packages/ubuntu-core_176.snap16:25
jdstrand../click-reviewers-tools-test-packages/ubuntu-core_176.snap: pass16:25
jdstrandogra_: I requested a pull with the store team a moment ago16:25
mvo_jdstrand: oh, ok. it has a regression anyway so I will have to do a new uplaod soonish16:27
jdstrandmvo_: ok, thanks16:27
ahasenackjdstrand: niemeyer: sorry, I had lunch and irc dropped16:27
ahasenackgood to hear something is coming16:28
mvo_jdstrand: but thanks!16:28
ahasenackand sure, setuid can be used to either drop or gain privileges16:28
jdstrandmvo_: fingers crossed your next upload is the *one* :)16:28
ahasenackI think selinux allows for an "order" of sorts here, i.e., "root" can drop to "squid" in this certain application16:28
ahasenackdon't know if apparmor has the same concept16:28
jdstrandahasenack: we will have something similar16:28
mvo_jdstrand: yeah, snap-confine was more difficult than expected16:29
jdstrandahasenack: it doesn't (yet), but with newer snap-confine, we can do it with seccomp16:29
ahasenackjdstrand: ok, so for today, the only option is to patch the app to not drop privileges?16:29
jdstrandahasenack: yes, or use devmode16:29
jdstrandwell, or use an unrelated interface16:29
ahasenackdevmode defeats the purpose I think, I'm trying to avoid it really hard16:29
ahasenackpatching the app might be hard too, since some go to great lengths to ensure they really dropped the privs16:30
jdstrandahasenack: devmode is meant only as a temporary thing16:30
ahasenackjdstrand: is there a blueprint or bug tracking this privilege dropping work/intent?16:30
jdstrandwe'll allow privilege dropping. at first it will be to a fixed uid, but will expand on that16:31
ahasenackthat would be enough to snap this app already16:31
jdstrandthere is a trello card, let me check on the bug16:31
jdstranda bug16:31
ahasenacksince it allows configuring the user it runs as16:31
ahasenack(as most do)16:31
jdstrandahasenack: bug #1581310 is in the same realm (it is for chown). if you are in trello I can add you to the card16:33
mupBug #1581310: ubuntu-core doesn't allow sed -i (fchown syscall) <snapd-interface> <snapd (Ubuntu):Triaged by jdstrand> <https://launchpad.net/bugs/1581310>16:33
ahasenackjdstrand: does the card get more updates than the bug, or is it enough if I subscribe to the bug?16:34
jdstrandahasenack: subscribing to the bug would be fine. I will be fixing that bug at the same time as setuid16:34
ahasenackcool, thanks16:35
ogra_jdstrand, yay, thanks !16:43
draglyzyga: Built ubuntu-clock-app with snapcraft now, and it works with strict confinement. Seems snapd-confine works as expected. However, the ubuntu-calculator-app does not work after installing with "snap install ubuntu-calculator-app". Trying to build it manually now.16:46
draglyYes, it works after building it manually. Any reason this should differ from installing it from the repository?16:46
mupPR snapd#1661 closed: docs: private flag doesn't exist on /v2/find (it's select) <Created by robert-ancell> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1661>16:48
joc_jdstrand: i built a new image from edge as ogra suggested and confirmed it has at least /usr/lib/snapd/snap-confine present, i'm still not getting the behaviour i expected from the interface though16:54
ogra_joc_, snap list|grep ubuntu-core16:54
ogra_what revision do yu have16:54
joc_ogra_: 17816:55
ogra_ok, thats the recent build16:55
ogra_Get:4 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 snap-confine amd64 1.0.38-0ubuntu0.16.04.4 [20.4 kB]16:56
ogra_and thats the version it installed16:56
EAbdelplease is there any one connnected here ?17:01
jdstrandjoc_: ok. did a file in /etc/udev/rules.d/ get created?17:02
joc_jdstrand: yes17:03
jdstrandjoc_: can you paste the contents?17:03
jdstrandjoc_: can you paste 'udevadm info /dev/the-thing-you-tried-to-tag'?17:07
EAbdelneed some help17:09
EAbdelsomone here to help me ?17:09
joc_jdstrand: http://paste.ubuntu.com/22929677/17:09
jdstrandjoc_: ok, so it should have something like: E: TAGS=:systemd:nap_miniterm-joc_open:17:10
jdstrandjoc_: but it only has TAGS=:systemd:17:11
jdstrand(obviously I meant 'TAGS=:systemd:snap_miniterm-joc_open:')17:11
jdstrandjoc_: because that tag isn't present, snap-confine isn't creating a device cgroup17:12
jdstrandand so the /dev/** line allows everything17:12
elopiosergiusens: josepht: I have a problem here: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/yaml.py#L13617:13
joc_jdstrand: ok, makes sense, to work out why the tag isnt applied then17:13
elopiosergiusens: josepht: why are we getting the remote parts every time? Can we be lazier than that?17:14
mupPR snapd#1666 opened: osutil: change escaping for create-user's sudoers <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1666>17:14
sergiusenselopio in the tests? Because some tests use remote parts and some don't17:14
jdstrandjoc_: so, ID_VENDOR_ID=10c417:15
EAbdelsomone workign with snaps ?17:15
elopiosergiusens: no, every time we load the config we get the remote parts.17:15
sergiusenselopio we clear the xdg home as part of the main test fixture17:15
jdstrandjoc_: but you have ATTRS{idVendor}=="0003"17:15
sergiusenselopio let me think into why that is17:15
elopiowe should load the remote parts only when they are needed.17:15
jdstrandjoc_: did you mix up vendor and product?17:15
sergiusenselopio yes that should be the case17:15
sergiusenselopio which is why I went with the current test solution; this should be fixed once josepht gets the yaml loader stuff refactored17:16
jdstrandjoc_: ID_MODEL_ID=0003. I guess that corresponds with the idProduct. anyway, yeah, it looks like things aren't quite right with the rule17:16
elopiosergiusens: I think I can quickly put a property to solve it. /me tries17:17
joc_jdstrand: oh good spot, i haven't in the plug defintion, sounds like i must have done in the interface code17:17
joc_that generates the snippet17:17
jdstrandjoc_: feel free to adjust the file in /etc/udev/rules.d directly and then do: udevadm control --reload-rules ; udevadm settle ; udevadm trigger ; udevadm settle17:17
jdstrandtechnically the settles shouldn't be required, but I found they were17:18
jdstrandjoc_: after that series of udevadm command you can do the udevadm info /dev/... command and see if it worked17:19
jdstrandjoc_: perhaps you knew all this-- if so, you get bonus help :)17:19
jdstrandjoc_: once happy, yeah, update the interface accordingly17:20
joc_jdstrand: looking better, get an E: TAGS=:systemd:snap_miniterm-joc_open:17:20
jdstrandah good17:20
jdstrandjoc_: when you launch the app, the cgroup should be used17:21
joc_jdstrand: excellent, getting operation not permitted when trying to open other /dev/ttyXXX now17:22
joc_jdstrand: sorry about that, my fault with the code, but the help on the debugging was much appreciated17:23
jdstrandjoc_: this actually makes me want to investigate something, so that is helpful17:24
sergiusensis anyone having issues with write operations on launchpad?17:26
mupPR snapcraft#657 closed: Add constraints to python2 plugin <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/657>17:26
joc_jdstrand: something comes to mind for me too17:29
joc_jdstrand: as this is a usb device i can unplug it17:30
joc_and now there is no device with tag on so no cgroup and i have access to everything in /dev again17:31
jdstrandjoc_: yes, that is precisely what I was talking about investigating17:33
jdstrandjoc_: I've added it to the trello card for my part of this interface. it is a bug in snap-confine that will need to be fixed17:33
jdstrandjoc_: don't worry about snap-confine. I'll fix it17:34
jdstrandjoc_: but I think this shows we should be more defensive with the apparmor rule to limit damage in the event of bugs17:35
jdstrandjoc_: is it possible for you to use /dev/tty* instead of /dev/**?17:35
jdstrandjoc_: or /dev/ttyUSB*? whatever that can be more fine-granined but not all of /dev/**17:36
joc_jdstrand: yes i can do and it would limit the damage of falling back to just the apparmor rule17:36
jdstrandit might not be possible. I suspect with the tty subsystem it is though17:36
jdstrandjoc_: note, I won't block the interface review on that, but I will mention it in the PR17:37
jdstrandjoc_: by 'that' I meant the snap-confine bug17:37
jdstrandjoc_: I also know how to address that bug17:37
joc_jdstrand: ok, i'll make the changes and propose it soon, thanks17:39
jdstrandjoc_: sure thing17:39
mupPR snapcraft#720 opened: Start the fake parts server only in the tests that need it <Created by elopio> <https://github.com/snapcore/snapcraft/pull/720>17:47
jdstrandjoc_: you may be wondering why we have this combination of cgroups and apparmor when it would be arguably easier to just update the apparmor profile17:53
jdstrandjoc_: the reason is that updating the apparmor profile requires a policy recompile which while not terrible on x86 can be up to a second or more on armhf17:54
jdstrandjoc_: so do that on hotplug events is not ideal17:55
jdstrandjoc_: so we have cgroups for now. in the future apparmor will grow xattr support such that we will be able to add a rule to the default template that says 'any file with this xattr that matches this security label is allowed'. then we load the policy once and a udev script updates the xattr of the file instead of messing with cgroups17:56
jdstrandjoc_: and we can remove the apparmor glob rules and all is nice and clean :)17:57
jdstrandhopefully we'll have that for series 18. we'll see17:58
=== evnmar_ is now known as evnmar
mupPR snapd#1651 closed: osutil: more create-user fixes <Reviewed> <Created by mwhudson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1651>18:01
mupPR snapd#1665 closed: many: do not require root for `snap prepare-image` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1665>18:01
jdstrandratliff: you might actually be interested in that last bit with jo c_ ^18:04
jdstrandratliff: fyi only18:05
ratliffthanks, jdstrand, interesting indeed18:07
ali1234why isn't there a snapcraft snap?18:07
sergiusensali1234 because we cannot build from there yet18:09
sergiusenskeyword: yet18:09
ali1234yes but why?18:09
ali1234would it work in devmode?18:10
ogra_it will even work with strict confinement ... just be patient ;)18:11
ogra_GRR ...18:12
ogra_i start hating our arm builders18:12
ogra_("starting in 18min" ... since 2h :P )18:12
ali1234what is the correct way to change the hostname on an all-snap system?18:13
ali1234ogra_: i tried to make classic use an overlay, now it won't boot at all18:19
kyrofaogra_, have you tried the auto-upload from LP from an account with whom the snap was shared yet?18:22
mupPR snapcraft#698 closed: Add option disable-parallel for all plugins <Created by blakerouse> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/698>18:44
stokachudo interfaces get installed automatically?19:05
stokachufo rexample if there is a juju interface that we would plug into19:05
stokachujuju snap would need to be installed19:05
kyrofastokachu, that's likely a question for zyga19:08
=== davmor2 is now known as davmor2_Hols
josephtsergiusens: do you mind adding notes from our discussion to the sub-parts bug? https://bugs.launchpad.net/snapcraft/+bug/160693319:43
mupBug #1606933: parser - Make all parts top-level parts <Snapcraft:In Progress by joetalbott> <https://launchpad.net/bugs/1606933>19:43
josephtsergiusens: I would but the reason for the new file idea escapes me :)19:45
mupPR snapcraft#717 closed: fix checker errors to let runtests.sh pass again <Created by cpaelzer> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/717>19:47
argesjdstrand: hey not sure if https://github.com/snapcore/snapd/pull/1602 is on your queue. The CI test failures seem to be random so i can never tell if its in a bad state or not20:02
mupPR snapd#1602: interfaces: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602>20:02
jdstrandarges: I'll give it a once over for the security policy bits and anything else I happen to see, but a core member of the snappy team will perform the merge20:08
argesjdstrand: thanks.20:09
jdstrandarges: as for the test failures-- yeah, that's annoying. not sure what's happening there lately; things were solid for quite a while...20:09
jdstrandarges: I left two small things to adjust, then LGTM. Please ping me when you commit and I'll say as much in the PR20:14
argesjdstrand: ok20:15
ali1234hmm... the all-snap image stopped working after i rebooted it a couple of times20:18
ali1234now it doesn't get past uboot20:19
tianonseeing the same boot issues after updating all-snaps on an amd64 VM too (although stuck in grub, not uboot)20:28
ali1234i didn't attempt to upgrade it20:28
ali1234although i gather it does so automatically20:28
tianonIIRC it has auto-update turned on by default20:28
ali1234however, i was attempting to reboot because i forgot to plug in the network cable20:29
jdstrandogra_: if you are still around, would you mind sharing your sshfs snap?20:29
ali1234so i dunno how it could have downloaded the update...20:29
tianonI can reproduce 100% consistently with https://people.canonical.com/~mvo/all-snaps/16/all-snaps-amd64.img.xz by doing "sudo snap refresh" followed by a reboot20:29
argesjdstrand: fwiw. pushed an update with your changes. I rebased again so not sure what the results of the CI tests will be20:40
jdstrandarges: I think the snappy team prefers to not have rebases fwiw, but I'll take a look20:50
ali1234how do i make snapcraft use a local git repo?20:58
mupPR snapd#1667 opened: many: implement snaptool command <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1667>20:59
ali1234also what is the best practice when the snapcraft.yaml exists in the same repo as the source code?20:59
ali1234hmm... desktop-launch went crazy21:14
mupPR snapcraft#677 closed: playing with caching <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/677>21:17
kyrofaarges, jdstrand indeed, you can squash up for the initial PRs if you want to start clean, but merges only once the PR is created21:19
camakoali1234, this should work :21:24
camakosource: /path/to/my/repo21:24
camako    source-type: git21:24
camakojdstrand, ping21:27
ali1234but what about when the snapcraft.yaml exists within the project it is compiling?21:27
tianonjdstrand: oh man, I've been updating my PR wrong /o\  I'll keep this in mind for future updates, sorry! :x21:28
camakoali1234, "source: ."21:32
ali1234yeah that specifically fails for me21:32
camakolooking at gitter-im in the playpen may help.. that's what it does.21:33
ali1234it causes desktop-launch to try to create recursive directories, then it crashes when it hits the dir limit21:33
ali1234i'm trying to reproduce it on amd6421:36
ali1234then i'll upload an example to my museum of broken snaps...21:36
jdstrandcamako: hi21:42
camakojdstrand, hi.. I was looking at the mesa gl/gles demos in terms of snappy interface requirements21:42
camakoI noticed that they use 'sendmsg' which gets a denial21:43
camakofurther investigation revealed that it's used to talk to the X server21:43
camakowhich is a legit thing to do21:43
camakobut x11 interface doesn't include sendmsg21:43
camakoonly 'send' I think21:44
camakoand then I thought, other apps (non-gl) would use it too21:44
jdstrandcamako: seems fine to add. either file a bug with snapd-interface or do a PR against snapd21:44
jdstrandcamako: if filing a bug, please add the 'snapd-interface' tag21:45
jdstrandthen we'll get that fixed up21:45
jdstrandI suspect it will want 'sendto' as well21:45
camakojdstrand, will do... out of curiosity, how come no other X11 app has encountered this problem?21:46
jdstrandcamako: not sure. what architecture are you using?21:46
camakoI'm on AMD64 with intel (i965) gpu21:46
jdstrandyeah, that's odd21:46
jdstrandguess your snap made an api call that others don't typically use21:46
jdstrandand that call ended up using sendmsg21:47
camakojdstrand, I traced it to 'glXMakeCurrent'21:47
ali1234most X11 code doesn't use GL, and most GL code doesn't use X11 features directly...21:48
jdstrandthere you go21:48
jdstrandit's interesting how things like this crop up21:49
camakojdstrand, don't we have apparmor protection on ubuntu outside snappy?21:49
jdstrandit's an easy fix so we can get it into the next snapd release without issue21:49
jdstrandcamako: apparmor is used in various places, sure (/me notes we are talking about seccomp here)21:50
camakojdstrand, abstractions/X (which allows 'send') is under apparmor, so I was going with that21:51
jdstrandcamako: that's a different send21:51
camakoso I'm wondering without sendmsg, how is an app like glxgears end up working?21:51
jdstrandcamako: in snappy we have both apparmor mediation and seccomp filtering21:51
camakoah ok21:51
jdstrandseccomp is the first line, then apparmor21:52
camakook I'll file a bug21:52
jdstrandseccomp is way more coarse-grained, but the combination of the two is compelling21:52
jdstrandcause we can say, block module loading at the syscall level even if the apparmor policy would allow it21:53
jdstrand(it doesn't, you'd need sys_module so not the best example, but the point is, we use them in combination for a strong sandbox)21:53
jdstrandthe sandbox is mostly apparmor, but the seccomp filtering comes in handy where apparmor doesn't yet implement an lsm hook21:54
jdstrandkernel keyring is a good example. we can also block known problematic or ancient syscalls to reduce the kernel attack surface21:54
jdstrandanyhoo, yes, file a bug and I'll get it fixed21:55
camakojdstrand, I'll file a bug, but I am keen to understand why things are working on the desktop.21:55
camako  # the unix socket to use to connect to the display21:55
camako  /tmp/.X11-unix/*           w,21:55
camako  unix (connect, receive, send)21:55
camako^^ these lines from the X file21:56
camakocaught my eye21:56
jdstrandcamako: so, on the desktop most X apps shipped as debs aren't confined by apparmor (or seccomp)21:56
camakoI'm assuming for non-snappy desktop apps,  this is used?21:56
camakoah ok then..21:56
camakothanks for the explanation21:57
jdstrandcamako: when you confine an X app with apparmor, then you need a unix rule from the X abstraction. those use apparmor syntax and are not syscalls21:57
camakoI see21:57
jdstrandcamako: when you then setup a seccomp filter for the app, then you see the syscalls it uses21:57
jdstrandso on snappy you get both. on non-snappy, neither or possibly just apparmor21:58
camakoI was running an app that I compiled... would that have been confined by apparmor?21:58
jdstrandcamako: no22:01
ali1234hmm... can't reproduce with a simple helloworld snap22:09
mupBug #1611978 opened: Incomplete x11 interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1611978>22:13
ali1234well that's annoying22:33
=== King_InuYasha is now known as Son_Goku
sergiusensrobert_ancell hey, mind updating https://github.com/snapcore/snapcraft/pull/670 ?23:18
mupPR snapcraft#670: Remove .la files generated by autotools <Created by robert-ancell> <https://github.com/snapcore/snapcraft/pull/670>23:18
robert_ancellsergiusens, ok23:18
ali1234something is very wrong here: http://paste.ubuntu.com/22968449/23:20
sergiusensali1234 we had this same problem, well stokachu did and it was related to having a command in the snap calling an internal to the snap binary with the same name and exec doing its thing of infinitely calling upon itself due the the in snap command having a bad shebang23:47
ali1234t worked fine yesterday :(23:47
ali1234there are only two things in the snap: desktop-helper and my binary (infodump)23:48
ali1234desktop-launcher sorry23:48
ali1234hmm i see... so desktop-launch is running /snap/bin/infodump instead of /snap/infodump/current/bin/infodump23:56
ali1234which causes the recursion23:56
sergiusensali1234 yeah, that would do it23:56
ali1234but why?23:57
sergiusensali1234 is /snap/infodump/current/bin/infodump a binary?23:57
sergiusensis it +x?23:57
sergiusensif it has a shebang, is it correct?23:58
ali1234it *should* be a binary23:58
ali1234hang on i have to build it again to know for sure23:58

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