davidcallekyrofa: not really, just came back online to finish a snapcraftio deployment. Would you have time tomorrow?00:02
kyrofadavidcalle, certainly, I'll ping you when I get in00:02
davidcallekyrofa: sounds good! ty00:02
mupPR snapcraft#920 closed: pluginhandler: ensure staged files are included in the prime step <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/920>00:08
alvarolbhi! anyone knows why my snap package does not pass the click-review? It reports RUNTIME ERROR, although the package install fine with snap00:33
kyrofaalvarolb, you probably want jdstrand00:37
alvarolbthanks kyrofa.00:38
kyrofaHe may be out today, you might try tomorrow00:39
alvarolbok, will try tomorrow :) as I cannot upload my snap package with this error00:40
cyphermoxkyrofa: I'll be back on Monday00:49
cyphermoxkyrofa: console-conf AFAIK runs unconfined, as part of the OS snap.00:49
kyrofacyphermox, no worries, we got it sorted, thank you!00:50
cyphermoxaka. core snap.00:50
alvarolbI submitted a bug in the meanwhile: https://bugs.launchpad.net/snappy/+bug/165445100:53
mupBug #1654451: ubuntu store snap click-review error <Snappy:New> <https://launchpad.net/bugs/1654451>00:53
mupBug #1654451 opened: ubuntu store snap click-review error <Snappy:New> <https://launchpad.net/bugs/1654451>00:54
=== tasdomas` is now known as tasdomas
=== slangase` is now known as slangasek
=== macnibblet is now known as mac_nibblet
mupPR snapcraft#1027 opened: tests: fix broken unit test in master <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1027>01:14
=== devil is now known as Guest89704
=== mac_nibblet is now known as Guest41430
mupPR snapcraft#1027 closed: tests: fix broken unit test in master <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1027>02:02
mupPR snapcraft#1004 closed: tests: add aliases integration test <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1004>02:05
=== chihchun is now known as chihchun_afk
=== madprops_ is now known as madprops
grapestomperdoes anyone know how to change the default console output from ttyS0 to ttyUSB003:38
grapestompersnappy series 16 (core 16?)03:39
grapestomperkernel console output (I want to see the boot process)03:39
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
mupPR snapcraft#1028 opened: [Highly experimental] Run the integration suite in parallel <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1028>04:30
=== JanC_ is now known as JanC
mupPR snapcraft#1029 opened: rust plugin: add conditional compilation <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1029>05:27
mupPR snapcraft#952 closed: rust plugin: add features for conditional compilation <Created by cholcombe973> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/952>05:30
=== JanC is now known as Guest22782
=== JanC_ is now known as JanC
liuxggrapestomper, you may refer to the picture http://img.blog.csdn.net/20160912142114476?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center06:17
liuxggrapestomper, open the file and change it there dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline06:18
=== Guest89704 is now known as devil_
mupPR snapd#2566 closed: tests: disable some ppc64el on yakkety and zesty too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2566>07:40
=== mup_ is now known as mup
mupPR snapd#2128 closed: many: finalize trusty support <Created by vosst> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2128>08:31
=== ahasenack is now known as Guest99073
=== ahayzen_ is now known as Guest32468
mupIssue snapd#2568 opened: snapd needs a SELinux profile to run on Fedora <Created by zyga> <https://github.com/snapcore/snapd/issue/2568>09:08
mupIssue snapd#2569 opened: snap-confine cannot perform namespace capture even with CAP_SYS_ADMIN <Created by zyga> <https://github.com/snapcore/snapd/issue/2569>09:11
mupPR snapd#2548 closed: snap: show `snap --help` output when just running `snap` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2548>09:15
mupIssue # closed: snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2559, snapd#2568, snapd#256909:23
mupPR # closed: snapd#2416, snapd#2433, snapd#2520, snapd#2528, snapd#2542, snapd#2562, snapd#2563, snapd#2564, snapd#256709:23
mupIssue # opened: snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2559, snapd#2568, snapd#256909:54
mupPR # opened: snapd#2416, snapd#2433, snapd#2520, snapd#2528, snapd#2542, snapd#2563, snapd#2564, snapd#256709:54
mupPR snapd#2570 opened: snap: add support: line in `snap info <Created by mvo5> <https://github.com/snapcore/snapd/pull/2570>09:55
=== DanChapman_ is now known as DanChapman
mupPR snapcraft#1030 opened: tests: fix broken delta upload unit test <Created by shawn111> <https://github.com/snapcore/snapcraft/pull/1030>10:18
mupPR snapd#2571 opened: tests: generate higher local version than any "ubuntuN" version from the archive <Created by mvo5> <https://github.com/snapcore/snapd/pull/2571>10:27
=== jamespag` is now known as jamespage
=== mup_ is now known as mup
=== Mikaela[m] is now known as Ciblia
=== Guest99073 is now known as ahasenack
=== ahasenack is now known as Guest76687
=== perrito667 is now known as perrito666
ogra_morphis, yo ... trying your pulse snap on pi3 ...11:34
ogra_Jan  6 11:33:42 pi3 kernel: [100001.213596] audit: type=1326 audit(1483702422.800:99): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=3658 comm="pulseaudio" exe="/snap/pulseaudio/12/usr/bin/pulseaudio" sig=31 arch=40000028 syscall=206 compat=0 ip=0x76df5456 code=0x011:34
ogra_Jan  6 11:33:42 pi3 snap[3647]: Bad system call11:34
ogra_looks like some seccomp love is needed there11:35
ogra_morphis, 206 is setgroups32, that doesnt exist on 64bit arches, that might be the reason why it works on amd64 but not on armhf (and likely also not on i386)11:43
* ogra_ tries --devmode11:47
morphisogra_: hm, koza told me that it works and this thing is fixed, which core snap revision are you using?11:47
morphisnot sure if it requires the latest from candidate and already works with the one from stable11:48
ogra_ogra@pi3:~$ sudo pulseaudio.parec foo.wav11:48
ogra_ogra@pi3:~$ ls -l foo.wav11:48
ogra_-rw-r--r-- 1 root root 520856 Jan  6 11:48 foo.wav11:48
ogra_works with --devmode11:48
ogra_(no idea what it recorded there, i have no mic :P )11:48
ogra_my pi doesnt find one in stable btw ...11:49
ogra_i'm using edge11:49
* ogra_ checks --candidate11:50
ogra_also needs --devmode to start11:51
popeyIs there a plan to allow daemons to run as non-root in snaps, or allow snaps to create users?11:51
ogra_yes... but i dont know how far out that is11:52
popeyis there a work item / card / bug?11:52
ogra_definitely on the long term, list of the security team11:52
popeyIt's a blocker for an ISV with a postgresql database as a part11:52
ogra_you gotta ask jdstrand11:52
=== chihchun is now known as chihchun_afk
sergiusenspopey it was recently (these past few days) discussed on the mailing list under "Process privileges and owners in snaps"12:09
popeysergiusens: thanks12:18
=== Guest76687 is now known as ahasenack
Elleojdstrand: I'm getting some odd behaviour with anonymous sockets under snappy, I've currently got a simple app armor rule of: unix (bind, send, receive) addr="@/tmp/maliit-server/dbus-*" but when maliit attempts to create a QtDbus server using that socket it gets stuck in a pthread_wait (which doesn't happen if its in devmode); any ideas what my be causing that before I dive into qtdbus's internals to see what's happening?12:57
mupIssue snapd#2572 opened: .fstab files generated by snapd for the content interface do not follow the snap.<snap name> scheme <Created by morphis> <https://github.com/snapcore/snapd/issue/2572>13:03
DanChapmanHey! I'm having what now seems to be an issue with automatic releasing of my snap on the edge channel. I have an lp builder publishing to the store but i'm having to manually release each revision after the store review using `snapcraft release`.13:10
DanChapmanIs this a known issue or some setting i might have accidently changed in myapps.d.u.c13:11
nessitaDanChapman, what's the name of your snap?13:11
DanChapmannessita, hey! it's dekko13:11
nessitaDanChapman, let me dig a little13:12
nessitacjwatson, hi there, would you help me confirm if the issue Dan explained above is on LP or the store end? will LP builder try to release the revno? if they fail is there a log?13:13
ogra_DanChapman, note that there is usually a delay between it passing the tests and the auto-publisher ... like ... 20-30 min13:14
ogra_could it be that you just hit that ?13:15
nessitaogra_, good point, thanks for pointing that out13:15
DanChapmanogra_: oh it could be that! I didn't know there was a delay.13:21
DanChapmannessita: i'll test again just to be sure. get back to you shortly :-)13:22
cjwatsonwill check logs after this call13:25
nessitaDanChapman, thanks!13:29
cjwatsonnessita,DanChapman: LP is consistently getting a 200 response from /dev/api/snap-release/ according to our logs, so not our problem :-)13:29
cjwatson[2017-01-03 12:04:13,678: DEBUG/Worker-3] "POST /dev/api/snap-release/ HTTP/1.1" 200 None13:29
nessitacjwatson, thanks for checking!13:30
mupPR snapcraft#990 closed: tests: fix snaps tests in armhf <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/990>13:30
cjwatson(waiting for it to get round to the most recent build so that I can give you a more recent timestamp to use for SCA log checking)13:31
cjwatson[2017-01-06 13:34:15,294: DEBUG/Worker-3] "POST /dev/api/snap-release/ HTTP/1.1" 200 None13:34
cjwatsonDanChapman: has the most recent ppc64el build in https://launchpad.net/~dpniel/+snap/dekko-edge been released?13:34
cjwatsonthe log entry above is LP asking the store to do so13:35
DanChapmancjwatson: yes that has been released fine.13:37
DanChapmannessita: seems to be ok. I must not have left it long enough last time.13:37
DanChapmannessita: cjwatson: thanks for your help and sorry for the noise :-)13:37
nessitaDanChapman, thanks for confirmin13:37
jdstrandElleo: addr="@/tmp/maliit-server/dbus-*" is part of a rule for an abstract socket, but you said you are having trouble with anonymous sockets. can you clarify?13:39
Elleojdstrand: sorry, I meant abstract not anonymous13:42
jdstrandpopey: there are open bugs for that. also (cc ogra, ratliff and JamieBennett), the security team is currently not tasked with implementing opt-in users though I have ideas on the design that I've discussed with people. what I plan to do very soon (if it doesn't get bumped again, next week) to allow daemons to drop to 'daemon'13:43
jdstrandpopey (cc ogra, ratliff and JamieBennett): that would allow things like postgresql to drop to a non-root user that already exists (specifically, 'daemon')13:45
jdstrandElleo: can you disable kernel rate limiting with: sudo sysctl -w kernel.printk_ratelimit=013:45
JamieBennettjdstrand, sounds good, a long requested feature so will be nice to see some solution13:45
jdstrandElleo: then do 'tail -f /var/log/syslog|grep DEN' and see if there are any denials when trying to use maliit?13:46
Elleojdstrand: no denials13:47
Elleojdstrand: without that apparmor rule it was previously getting denials when trying to create the socket, so that's obviously having an effect at least13:48
jdstrandpopey (cc ogra_, ratliff and JamieBennett): see https://lists.ubuntu.com/archives/snapcraft/2017-January/002286.html for my thoughts on how opt-in users could be implemented13:49
jdstrandElleo: if there are no denials it shouldn't be apparmor. what is likely happening is that there are multiple problems. the first was the socket creation, then you allow that and moved to the next problem13:51
Elleojdstrand: it works if the snap is installed with devmode though, so presumably it's something confinement related13:51
jdstrandElleo: sure, but not necessarily apparmor. before diving into qtdbus internals, you might strace it13:52
mupPR snapd#2571 closed: tests: generate higher local version than any "ubuntuN" version from the archive <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2571>13:53
jdstrandElleo: and to be super sure-- you are observing /var/log/syslog, not kern.log, not dmesg and not using a tool like snappy-debug and still not seeing denials?13:53
jdstrandElleo: the other parts of confinement are seccomp (do you see any seccomp denials in syslog? look for 'type=1326' or use snappy-debug), device cgroups (not used by most interfaces, but what interfaces are you plugging?) or mount namespace13:56
Elleojdstrand: yep, and if I grep for ALLOWED there's a line for the binding: http://pastebin.ubuntu.com/23752229/13:56
Elleojdstrand: although, what's the "denied_mask" property?13:56
jdstrandElleo: the mount namespace shouldn't affect an abstract socket, but depending on your testing, it could affect something file related if you are trying to access something in the snap from outside the snap and inside the snap gets confused13:58
* jdstrand doubts that is the case)13:58
jdstrandElleo: denied_mask is the part of requested_mask that got denied13:58
jdstrandElleo: all my questions regarding denials are for when running in strict mode. ALLOWED shows you are in devmode13:59
ogra_xnox, yo !13:59
Elleojdstrand: ah right, that'd have been from when I double checked it worked okay in devmode then13:59
Elleojdstrand: aha, there are seccomp entries: http://pastebin.ubuntu.com/23752238/13:59
jdstrand$ scmp_sys_resolver 5014:00
jdstranduse 'network-bind'14:01
jdstrandif you are writing an interface for maliit, then add 'listen' to you seccomp filter14:01
Elleojdstrand: ah okay, thanks :)14:01
mupPR snapcraft#1031 opened: store: fix sso_host for dev sso <Created by shawn111> <https://github.com/snapcore/snapcraft/pull/1031>14:06
Elleojdstrand: that's fixed it, thanks very much!14:09
jdstrandElleo: great! :)14:10
jdstrandmvo: hi! if you are going to plan a new upload for trusty snapd, you might adjust the Build-Depends from 'libseccomp-dev (>= 2.1.1-1ubuntu1~trusty1)' to 'libseccomp-dev (>= 2.1.1-1ubuntu1~trusty3)'. 'trusty3' is the one that fixed amd64. certainly don't respin just for that though14:22
ogra_jdstrand, hmm, looking at /var/lib/snapd/seccomp/profiles/snap.pulseaudio.pulseaudio i see setgroups and setgroups32 commented out at the top but then setgroups at the bottom uncommented ... why the duplication ?14:29
mvojdstrand: thank you14:31
jdstrandogra_: the top comes from the default template. the bottom from a slot snippet14:32
ogra_ah, k, thanks14:32
jdstrandogra_: the top is a reminder that we don't (yet) support privilege dropping14:32
xnoxogra_, que?14:33
ogra_xnox, on your quest to look at swapfiles, did you happen to look at the "swapspace" package ?14:33
ogra_(dynamically creates swap files on demand and deletes them afterwards)14:34
ogra_jdstrand, heh, so adding setgroups32 just leads me to the next blocker ... "send" (289 on armhf)14:34
ogra_hmm, i see pulse connected to the network interface, but not to network-bind14:36
mvojdstrand: updated14:36
jdstrandmvo: thanks!14:36
mupBug #1654451 changed: ubuntu store snap click-review error <Canonical Click Reviewers tools:In Progress by jdstrand> <Software Center Agent:Invalid> <https://launchpad.net/bugs/1654451>14:37
xnoxogra_, yes and we don't what that.14:38
xnoxogra_, yes and we don't want that.14:38
ogra_xnox, whats the reason ?14:38
ogra_(we're considering such a feature for snappy images, thats why i ask)14:38
xnox(when system is under memory preassure you don't want to randomly start eating into disk space, and consuming memory to allocate swap. We only need swap as a contingency and want it allocated up front. Also things like btrfs rebalance east a lot of memory and you can't really create swap whilst that is in progress)14:39
xnoxusing memory to create swap; when swap is actually needed; is the worst time to do it =)14:40
ogra_so you will be going with a fixed snap file set up by the installer ?14:40
xnoxogra_, please don't do that. Ideally snap gadgets whould e.g. declare none or an appropriate sized swall swapfile /relevant/ for that device workload and that's it.14:40
ogra_well ... we'Re often operating on devicers with very low ram but a lot of diskspace14:41
xnoxon classic one can resize and/or remove it. on all-snaps systems i would not think that it needs to be amendable (outside e.g. gadget snap upgrading and changing the swapfile size)14:41
xnoxogra_, if it's flash storage rather than SSD storage you will kill the device with swap =) there is only so many write cycles on flash storage.14:42
ogra_but we dont want swap to be used at all if avoidable to avoid any slowness indeed14:42
ogra_yes, i know14:42
ogra_in that light dynamic swap file creation will help a lot though14:42
xnoxyou have to use less memory - that's the best win, for size, performance, longivity.14:42
xnoxno, it won't.14:42
ogra_you only wear out flash if you write a lot to the same place14:42
ogra_due to dynamic creation that cant happen14:43
ogra_(compared to a fixed swapfile)14:43
xnoxit's the same.14:43
ogra_or will happen less at least :)14:43
xnoxbecause silly micro-controllers abstract filesystem and round-robin the physical locations to what filesystem and kernel sees, on cheap storage.14:43
ogra_not the same ... if you need i.e. 1GB swap swapspace will create 100 swap files each 100MB ...14:44
xnoxtherefore with dynamic you get either the same wear as static, or possibly more wear =)14:44
ogra_and dynamically delete them again if you dont need the space anymore14:44
xnoxon average, it's the same wear.14:44
xnoxit's best not to use swap to avoid pointless wear =)14:44
ogra_so the filesystem usage will be different from having a permanent gigantic 1GB file14:44
xnoxat all.14:44
ogra_right, but we have user demand for it14:44
ogra_so we need to provide *something*14:45
ogra_and dynamic feels safe than permanent14:45
xnoxhow so again? the device blocks you see, are virtual to you, and you never know what physical block they correspond to. because cheap flash microcontrollers....14:45
mupPR snapcraft#1028 closed: [Highly experimental] Run the integration suite in parallel <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1028>14:45
xnoxit's fragile =)14:45
ogra_true indeed ... but if the blocks are in use new blocks will be used14:45
xnoxwhich can remap to the old physical block.14:46
ogra_which is more likely if you have small fragmented files14:46
xnoxit's really random walk on most of these controllers.14:46
xnoxmicrocontroller has no visilibity to FS files.14:46
xnoxand does not care about virtual blocks either.14:46
xnoxit really picks any =)14:46
ogra_ok, so much for that theory :P14:47
ogra_anyway, it will not permanently eat disk space ... thats still one advantage14:47
xnoxso on reboot, your static swapfile may write to new physical locations =/ (that is quite scary....)14:47
xnoxogra_, does not work on btrfs or zfs.....14:47
xnoxor lvm.14:47
ogra_which we currenmtly dont care for on core images14:48
ogra_the OS is currently hardcoded to ext414:48
ogra_indeed it will bite once we support other FSes14:48
xnoxthink this trough a little.14:48
xnoxtalk to ubuntu-image developers about this.14:48
ogra_(which i'm not sure we'll do anytime soon)14:49
xnoxwe are shipping lvm cloud images soon.14:49
ogra_snappy based ?14:49
ogra_that will require a ton of changes in the OS14:49
ogra_everything everywhere currently expects ext414:49
xnoxi thought ext2 was the end-game for filesystems too at one point =)14:50
xnoxand that armhf will rule them all14:50
ogra_well, its a legacy we carry from system-image setups14:50
xnoxthings will change, because things do change =)14:50
ogra_it can surely be changed to other filesystems but will need a lot of changes14:50
ogra_code changes i mean14:51
ogra_so if anyone wants these cloud images any time soon, they should better look at the boot pĆ¼rocess or talk to someone who knows about it :)14:53
ogra_jdstrand, so adding send additionally to setgroups32 makes it work ... i'll file a bug for you ... funnily the send syscall is enabled in all the pulse oprofiles, just not for the daemon itself :)14:54
alvarolbthanks jdstrand for reviewing the bug in click-reviewer-tools14:55
grapestomper_1does anyone know how the change the default kernel output from ttyS0 to tty??? (ex. ttyUSB0)?14:56
ogra_grapestomper_1, edit the console= arg of your bootloader14:58
grapestomper_1I used to do this in grub.d but that is not there. what file is it now14:58
ogra_somewhere in /boot/grub/14:58
* ogra_ rarely touches x86 images14:59
grapestomper_1I looked at there but all the files are read-only14:59
ogra_hmm, i thought the grub.cfg is rw14:59
grapestomper_1I see a 50-system-image.cfg that is rw15:00
grapestomper_1I take that back15:01
ogra_no, there needs to be a grub.cfg15:01
grapestomper_1-rw-r--r-- 1 root root15:01
grapestomper_1agreed :)  but I dont see one15:02
ogra_well, the other option is to roll your own gadget snap with changed cmdline15:02
ogra_to do that you clone https://github.com/snapcore/pc-amd64-gadget15:02
ogra_and then edit prebuilt/grub.cfg (commandline is at the bottom there) and call snapcraft in the toplevel dir of the branch15:03
grapestomper_1ok, thanks - I will look into that15:03
diddledanthe new dbus slot mechanism in snapd 2.20 works. I've tried uploading corebird-diddledan to the store using the working config but the store has complained that "not allowed by 'deny-connection/slot-attributes' in base declaration declaration-snap-v2_slots_deny-connection (dbus-corebird, dbus)"15:06
mupBug #1654585 opened: seccomp profile of pulseaudio snap misses syscalls on armhf <Snappy:New for jdstrand> <https://launchpad.net/bugs/1654585>15:10
kgunnniemeyer: hey there, kyrofa thot you might be the right guy to ping15:17
kgunnwe're creating a mir-kiosk image15:17
kgunnbut trouble is mir-kiosk launches before i can run console-conf15:17
kgunnis there a way i could check in my launcher file to not launch in the case where console-conf hasn't run?15:18
ogra_kgunn, console-conf writes /var/lib/console-conf/completed when it was run successfully15:23
ogra_but i have no idea how you would be able to see this from a snap15:23
ogra_(might need some special interface)15:24
kgunnogra_: it would seem like this might be something that other people would want to know as snap image creation proliferates in the world15:28
morphis_ogra_: mvo told me to poke you about https://bugs.launchpad.net/snappy/+bug/165458815:34
mupBug #1654588: Make /etc/systemd/logind.conf.d writable <Snappy:New> <https://launchpad.net/bugs/1654588>15:34
mupBug #1654588 opened: Make /etc/systemd/logind.conf.d writable <Snappy:New> <https://launchpad.net/bugs/1654588>15:35
ogra_claimed :)15:35
ogra_morphis_, uploaded to the PPA ... will be in the next core15:39
mupBug #1654590 opened: docker interface should account for /run/shm/ in addition to /dev/shm <Snappy:In Progress by jdstrand> <https://launchpad.net/bugs/1654590>15:41
morphis_ogra_: you're my hero :-)15:46
mupPR snapcraft#1032 opened: Use more secure temporary directory for parser runs <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1032>15:48
mupPR snapd#2573 opened: snap: add information about tracking channel (not just actual channel) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2573>16:04
jdstrandlool: hey, fyi, testing docker on trusty/i386 (note bug 1654590 which I'm going to fix):16:15
mupBug #1654590: docker interface should account for /run/shm/ in addition to /dev/shm <Snappy:In Progress by jdstrand> <https://launchpad.net/bugs/1654590>16:15
jdstrand$ sudo docker run ubuntu:trusty uptime16:15
jdstranddocker: Error response from daemon: rpc error: code = 2 desc = "oci runtime error: exec format error".16:15
jdstrandlool: oh, nm, I'm dumb16:16
jdstrandI think I pulled a 64 bit image16:16
jdstrandlool: do you know how to pull a 32 bit image? sudo docker pull ???16:19
looljdstrand: they only introduced multiarch images recently; the armhf image is named differently: arm/ubuntu instead of ubuntu16:20
looljdstrand: docker run 32bit/ubuntu16:20
Sweet5harkcan someone advise on https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1649620? where to put stuff in "pull()" so that its not deleted and can be used during "build()" -- best without creating extra copies?16:21
mupBug #1649620: stuff downloaded during "pull()" is deleted before "build()" <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1649620>16:21
looljdstrand: TBH 32-bits images might not be maintained anymore16:21
jdstrandlool: that is what I tried:16:21
jdstrand$ sudo docker pull 32bit/ubuntu16:21
jdstrandUsing default tag: latest16:21
jdstrandPulling repository docker.io/32bit/ubuntu16:21
jdstrandTag latest not found in repository docker.io/32bit/ubuntu16:21
jdstrandI think I'll just focus on amd64 for docker for my testing16:23
looljdstrand: Yes, i386 is not officially supported upstream and they dont really support biarch either16:24
loolthey need docker support libraries for the 64 bits docker binary inside the 32bits container16:24
loolamd64 is a better base16:24
loolor armhf16:24
loolor even arm6416:24
jdstrandwonder if the i386 snap makes sense then16:24
seb128Sweet5hark, what is it that you refer as 'pull()' and 'build()'? snapcraft isn't deleting anything if you don't use 'clean' afaiik16:28
seb128Sweet5hark, you said it's only doing that on launchpad and not on local builds?16:30
seb128Sweet5hark, oh, I see, you override things with a plugin ... your build() is calling "make clean", you are sure that's not what clean things for you?16:34
niemeyerkgunn: Heya16:46
kgunnhey o/16:46
niemeyerkgunn: What's the actual outcome from console-conf that mir-kiosk depends on?16:46
kgunnniemeyer: so from my usage perspective, i dl and flash a mir-kiosk image onto dragonboard....boots, but i can't set  up wifi via console conf b/c mir-kiosk steals the screen16:47
niemeyerkgunn: Hmm16:48
Sweet5harkseb128: nope. the make clean should never delete the source. FWIW, I put the call to "./autogen.sh" _before_ the make clean just to be sure and it fails to find ./autogen.sh. so between "pull()" and "build()" something clears the parts dir ...16:49
kgunnniemeyer: i was thinkin', i could just add access to the /var/lib/console-conf/completed16:49
kgunnto the mir interface16:49
kgunnto prevent launching in the instance it's not there...16:50
seb128Sweet5hark, but only on launchpad?16:50
niemeyerkgunn: The idea of snapctl managed felt nice16:50
mupPR snapd#2565 closed: store: setting of fields for details endpoint <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2565>16:50
niemeyerkgunn: But both of these feel slightly awkward from the perspective that console-conf is going away for good.. it also feels slightly magic16:51
niemeyerFinish console-conf and BAM, you're off into something else altogether16:51
niemeyerkgunn: If we're exposing console-conf as an actual UI, why isn't the enablement of the kiosk an explicit action?16:52
niemeyerkgunn: That'd feel a lot less like a behind-my-back action, if you see what I mean16:53
kgunnniemeyer: yeah, i see what you mean16:55
Sweet5harkseb128: nope, locally too.16:55
seb128Sweet5hark, sorry, just saw your new comment ... so yeah, snapcraft issue16:56
seb128sergiusens or kyrofa might have some clue what could be going on there16:56
Sweet5harkseb128: locally, I can work around that by just doing everything in build(). But that doesnt work on lp, as in "build()" you cannot use the network there.16:56
kgunnniemeyer: to make sure i understand what you mean tho, are you saying that mir-kiosk.takeover would be somehow built into the tail end of console-conf?16:57
kgunnAlbertA: fyi ^16:57
seb128Sweet5hark, you can use the network in build now16:58
niemeyerkgunn: No.. I mean you'd have an actual command that once called would make the kiosk takeover16:58
kgunnniemeyer: k, just thinking it thru....like a real kiosk maker, how they'd install the device..and steps they'd go thru16:58
seb128Sweet5hark, see email https://lists.ubuntu.com/archives/snapcraft/2016-December/001978.html16:59
lazyPowerelopio - (tz differences withstanding) I think i made some progress here - https://gist.github.com/9ce253608b1be84fafd27ed0e63afa32  i've got the bins placed and i'm looking into the plugins/slots i need to enable strict mode.17:00
niemeyerkgunn: A polished device experience would hopefully avoid console-conf altogether17:00
lazyPoweri gave up on trying to fix their symlink issue and went for using their pressed bin delivery for now, so there's no hope of this ever building in launchpad17:01
niemeyerkgunn: So it really depends quite a bit on what we want to have17:01
kgunnAlbertA: so with this idea ^ we just need to make it not be a daemon17:01
Sweet5harkseb128: ah, cool. will give that a try as a workaround.17:02
AlbertAniemeyer: kgunn: would "takeover" be similar to calling a config hook?17:18
AlbertAor would console-conf just call that command?17:18
kgunnAlbertA: iiuc, it would be a separate thing from console-conf17:21
AlbertAand what would replace connsole-conf, some sort of provisioning tool on the host computer?17:22
lazyPowerdo we have any info on how to interface with systemd via installed snap? My google-fu is failing me17:22
mupPR snapd#2561 closed: many: obtain installed snaps developer/publisher username through assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2561>17:39
seb128Sweet5hark, I can confirm your bug btw17:50
seb128Sweet5hark, kyrofa, sergiusens, looking like to that the "Preparing to build ..." step is creating the build dir without considering or whether it was already created in the pull17:52
sergiusensseb128 why would it be created as part of the pull?17:52
seb128Sweet5hark, you should probably pull somewhere else and move it in the build17:53
seb128sergiusens, that's what Sweet5hark does in https://git.launchpad.net/~bjoern-michaelsen/df-libreoffice/+git/libreoffice-snap-playground/tree/parts/plugins/x_libreoffice.py?h=xenial#n17317:53
seb128sergiusens, that's about https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/164962017:53
mupBug #1649620: stuff downloaded during "pull()" is deleted before "build()" <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1649620>17:53
mhall119jdstrand: is granting snap declarations for dbus names going to be something you have to manually do for each app that uses the interface?17:54
sergiusenselopio add libreoffice to the candidate testing btw ^17:54
sergiusenskyrofa can you help seb128 out? I can do that on and off next week or the week after for sure17:56
kyrofasergiusens, sure, let me take a look17:56
seb128sergiusens, kyrofa, Sweet5hark, it's probably for next week now17:56
Sweet5harkseb128, sergiusens: yeah, I just just put stuff "somewhere" in pull() and pick it up again in in build(), but there is no way to know if that stays workable.17:56
sergiusensSweet5hark if in pull, put stuff in srcdir or in installdir and it will stick17:58
Sweet5harkseb128, sergiusens: e.g. could try to use tmpdir for that, but that might run out of space our stop being accessible on lp etc. -- so some clear advise on how to do that is appreciated.17:58
jdstrandmhall119: initial upload, yes. subsequent uploads, no17:59
Sweet5harksergiusens: so downloading stuff to ./libreoffice-build in my case? would work for me, but really, why are we mixing source and work directories left and right btw? (download sources to the rather read-only ./libreoffice-build, having ./parts/plugins in the otherwise transient ./parts)18:01
kyrofaSweet5hark, there are a few somewhat special directories within parts/<part>. src is where stuff is pulled, build is where things are built, and install is where things are installed once the part has completed building18:02
kyrofaSweet5hark, I don't recommend messing with any of those directories. However, other directories within parts/<part> are fair game. For example, I have a PHP plugin that pulls its own extensions to a new directory in there18:03
mupPR snapcraft#1033 opened: misc: delete bzr ignore <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1033>18:03
kyrofaSweet5hark, I still don't quite understand why you're wanting to build stuff in the pull step though18:05
kyrofaThe scrollback was a little spread out so I'm not sure I got everything18:06
Sweet5harkkyrofa: I dont want to build during pull18:07
kyrofaAh, you're just cloning and patching, it seems?18:08
kyrofaSweet5hark, you can clone into src if you're not concerned about clobbering your other pulled stuff, or yeah, create your own working area in parts/<part>18:10
Sweet5harkkyrofa: all I want from you guys is an explicit statement like: "if you put file during pull() to $FOO dir, you can be sure to still have them there during build()". For LO another possible problem is that if you pull to one dir and then need to copy to a build dir, that might make some builders out of discspace (if you do a full build later)18:14
Sweet5hark(aka I want a recommended best practice from you that you promise not to break)18:15
kyrofaSweet5hark, if you create a new directory under parts/<part> that is not part of snapcraft's internal structure, you will have them for all subsequent lifecycle steps. Including clean, actually (which is why plugins have clean_pull, clean_build, etc. functions)18:15
kyrofaSweet5hark, if you're concerned about space, you can use shutil.copytree with file_utils.link_or_copy as its copy_function18:24
kyrofaThat'll hard link18:24
Sweet5harkkyrofa: I mostly concerned about there being no best practice for described by snapcraft and its docs for this. If snap/snapcraft is supposed to be a platform, it needs to keep working with whatever people throw at it. If you dont have a bst practice for this, there will soon be 200 different creative ways to do this in the wild and you will be https://xkcd.com/1172/ 'ed very hard.18:36
kyrofaSweet5hark, the method I described to you is used by numerous plugins within snapcraft itself18:37
Sweet5harkkyrofa: that doesnt mean at all that Random J Upstreamcoder will do it that way too.18:40
kyrofaSweet5hark, my point is, if you want a best practice, perhaps that's a good place to look.18:41
kyrofaSweet5hark, I agree that the local plugin stuff needs to be further documented18:41
mupBug #1654629 opened: Async REST API operations don't return 'Location' header <Snappy:New> <https://launchpad.net/bugs/1654629>18:42
Sweet5harkkyrofa: Sure, just add it to the docs too, so Random J. (whom we very much want to provide snaps too) has a chance to find it too ;)18:42
Sweet5harkright ;)18:42
jdstrandroadmr: hi! can you pull r815 of the review tools? this fixes bug #165445118:50
mupBug #1654451: ubuntu store snap click-review error <Canonical Click Reviewers tools:Fix Committed by jdstrand> <Software Center Agent:Invalid> <https://launchpad.net/bugs/1654451>18:50
=== Guest32468 is now known as ahayzen
=== ahayzen is now known as Guest53710
=== chihchunl is now known as chihchun
mupBug #1654642 opened: classic snap files logs with apparmor ALLOWED messages <Snappy:New> <https://launchpad.net/bugs/1654642>19:27
=== Guest53710 is now known as ahayzen_
=== ahayzen_ is now known as ahayzen
diddledanweird. I've released a corebird snap built by launchpad's autobuilder and it is very broken. Yet the same snapcraft yaml file builds, installs, and runs perfectly fine when I do it manually19:45
diddledanbuilding myself I used the command `snapcraft cleanbuild` so I assumed that because that worked then the launchpad autobuilder would produce the same result19:47
kyrofadiddledan, happy to take a look at your yaml19:49
diddledankyrofa: https://git.launchpad.net/~diddledan/+git/corebird/tree/snapcraft.yaml?id=4fecf0085f66f7024fe7eefafe07ecd540ea318d19:49
kyrofadiddledan, can I see the LP log?19:50
diddledando I need to copy that to pastebin or does the direct link work without being me? https://launchpadlibrarian.net/301454571/buildlog_snap_ubuntu_xenial_amd64_corebird-diddledan_BUILDING.txt.gz19:51
kyrofaYeah snap builds are public, link is good19:51
kyrofadiddledan, that log seems to end in success... ?19:51
diddledankyrofa: yeah the build is fine. it's the running of the result that fails hard19:52
diddledanbut the same yaml run locally through cleanbuild works fine19:52
kyrofadiddledan, the use of architectures in your yaml is a little suspicious. I don't see that often19:53
diddledani.e. the store version is b0rked despite being supposedly identical to what I've built and tested outside of the store19:53
diddledanI read somewhere about architectures tag, I can try removing it and letting it rebuild19:54
kyrofadiddledan, yeah, remove it and just ask LP to build one snap for each arch19:54
kyrofadiddledan, how does the one built by LP break?19:55
diddledanthe one I've currently got in 'stable' complains that it can't load the en_GB locale because zlib1g shared object isn't present. in response to that I tried adding zlib1g as a stage package and put that in 'candidate' which is where I got the 'omgz0r the world is ending' spew: http://pastebin.ubuntu.com/23753963/19:57
kyrofaHoo, beautiful19:58
diddledanerrors are always fun :-p19:59
kyrofadiddledan, I think the architectures thing is saying "this snap will run without modification on the archs I specify"19:59
kyrofaBut then the libs that are being pulled in are probably arch-specific19:59
kyrofaSo remove that option, and check both i386 and amd64 boxes for which archs to build in LP20:00
kyrofaThen it'll build one snap for each arch20:00
diddledanso I was basically saying "do a compile, package exactly only the packages I listed in stage-packages, and shut the rest of the world out. hard."?20:01
kyrofaThe rest of the world meaning the system on which the snap was installed?20:01
diddledanmeaning that gtk and such are all excluded because I didn't list it directly20:02
kyrofadiddledan, no they're included as well as a result of the remote gtk part you're using20:02
kyrofaIt's just that which ones are pulled depend on the arch of the builder20:02
kyrofaBut you're yaml is promising that the resulting snap can run on both amd64 and i38620:03
* diddledan scrachy head20:04
diddledanmy Brian hurts :-p20:04
kyrofaHeh. Try removing it, and see if that helps. Just make sure you ask LP to build for both archs20:05
diddledanyup, I've done so. just waiting on LP now (it hasn't noticed the build needs running yet)20:05
kyrofadiddledan, let me know20:09
grapestomper_1looking for help with packaging a deb file - does anyone have a link or two they can refer me to?20:23
roadmrjdstrand: sure, r815 coming up20:29
mupPR snapd#2574 opened: interfaces/docker-support: allow /run/shm/aufs.xeno for 14.04 (LP: #1654590) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2574>20:32
jdstrandroadmr: thanks!20:34
diddledankyrofa: positive result - removing the architectures config fixes it20:39
kyrofadiddledan, excellent20:42
diddledannow everything is working except loading URLs (I have installed snapd-xdg-open in my host and in devmode that works so maybe there's a problem with strict confinement?) error: http://pastebin.ubuntu.com/23754246/20:44
diddledanall http(s) urls are behaving the same way - failing to open with the log message similar to: (corebird:9849): Gtk-WARNING **: Unable to show 'http://gizmodo.com/kodak-swears-its-not-giving-up-on-that-digital-super-8-1790907907?utm_medium=sharefromsite&utm_source=Gizmodo_twitter': Operation not supported20:46
kyrofadiddledan, I'm afraid I have zero experience with that. Perhaps jdstrand can help20:46
kyrofadiddledan, do you see any denials in syslog or with snappy-debug?20:46
diddledanyes, grepping /var/log/syslog reports apparmor="DENIED"20:48
diddledan^ reports that20:48
diddledanlast 5 lines seem to be the most recent attempt20:49
diddledanlet me try snappy debug20:49
jdstrandI don't have much experience with snapd-xdg-open except to say that it will open things on the applications behalf and wouldn't be affected by the snap's security policy. the denials indicate that your snap *may* not be using snapd-xdg-open (it's possible a library is trying to look in there, in which case those denials would be harmless)20:51
jdstrandyou can add the following to /var/lib/snapd/apparmor/profiles/snap.corebird-diddledan.corebird:20:51
jdstrand/usr/share/applications/{.*} r,20:52
jdstrand/var/lib/snapd/desktop/applications/{,.*} r,20:52
jdstrandthen run: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.corebird-diddledan.corebird20:52
jdstrandthen restart your snap and see if it works or if you get other denials (that may indicate if your app is trying to find a suitable handler or passing to snapd-xdg-open)20:53
diddledanshould I add those two lines to the bottom or in a specific location of the profile?20:53
jdstranddiddledan:: anywhere is fine. just before the trailing '}'20:58
diddledanok, I added those lines (fixing the missing comma in the first one :-p) but still failing. it seems corebird isn't using xdg-open then20:59
jdstranddiddledan: whoops, the first has a typo20:59
* jdstrand nods20:59
jdstrandsounds like it, yeah. I think didrocks may know more, but he seems offline20:59
jdstrandmaybe send a new email to the list?20:59
diddledanit's odd because I know that I _have_ had it working with the same version of corebird but in a devmode snap21:00
mupPR snapcraft#1009 closed: store: implement push pre-check <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1009>21:00
diddledanI'm thinking maybe the environment in which LP compiles could be slightly different to a cleanbuild lxd container?21:00
diddledanthat seems to be the only difference - the snap built by LP rather than locally21:01
diddledanother than devmode/strict21:01
diddledanok, it's not a cleanbuild vs LP issue. that leaves the only difference being strict vs devmode - retrying a build using devmode to test the theory21:18
diddledanyes. the same package installed using --devmode to snap install allows xdg-open to work correctly21:19
diddledanis there a way to change from strict to devmode on an already installed and up-to-date store version without removing and reinstalling?21:23
diddledanrevert --devmode is possible but that requires a previous version to be available on your system21:24
diddledanand refresh --devmode is possible but that requires a later version in the store than you have installed21:24
jdstranddiddledan: I'm not sure how to move back and forth. I can try to reproduce here21:29
kyrofajdstrand, how much do you know about gnome-keyring? Would an interface for it be easy, you think?21:35
jdstrandkyrofa: I can't think of anything otoh that would be particularly difficult21:36
kyrofajdstrand, is it just dbus?21:37
kyrofajdstrand, would you say it would need to be privileged?21:41
kyrofai.e. manual connection required21:41
jdstrandkyrofa: for sure21:46
jdstrandon Ubuntu, the keyring is unlocked on login and any application in the session get obtain the passwords21:46
kyrofajdstrand, yeah makes sense21:47
jdstrandfor it to be auto-connectable, gnome-keyring would have to be modified to only allow access to certain keys from certain security labels21:47
jdstrandand/or have apparmor integration, then we could think about policy21:48
jdstranddiddledan: this is needed: /usr/local/share/applications/{,*} r,22:10
diddledanjdstrand: yes, confirmed, that line added to the profile fixes it22:13
jdstranddiddledan: https://bugs.launchpad.net/snappy/+bug/165466622:15
mupBug #1654666: snapd-xdg-open doesn't work in strict mode <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1654666>22:15
jdstranddiddledan: I'll get that fixed hopefully for 2.2122:16
diddledanthank you. I've marked as affecting me, and subscribed to notifications :-)22:16
mupBug #1654666 opened: snapd-xdg-open doesn't work in strict mode <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1654666>22:16
jdstrandI'm heading out now, but feel free to add comments to the bug22:17
diddledanthanks again22:17

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