| davidcalle | kyrofa: not really, just came back online to finish a snapcraftio deployment. Would you have time tomorrow? | 00:02 |
|---|---|---|
| kyrofa | davidcalle, certainly, I'll ping you when I get in | 00:02 |
| davidcalle | kyrofa: sounds good! ty | 00:02 |
| mup | PR 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 |
| alvarolb | hi! anyone knows why my snap package does not pass the click-review? It reports RUNTIME ERROR, although the package install fine with snap | 00:33 |
| kyrofa | alvarolb, you probably want jdstrand | 00:37 |
| alvarolb | thanks kyrofa. | 00:38 |
| kyrofa | He may be out today, you might try tomorrow | 00:39 |
| alvarolb | ok, will try tomorrow :) as I cannot upload my snap package with this error | 00:40 |
| cyphermox | kyrofa: I'll be back on Monday | 00:49 |
| cyphermox | kyrofa: console-conf AFAIK runs unconfined, as part of the OS snap. | 00:49 |
| kyrofa | cyphermox, no worries, we got it sorted, thank you! | 00:50 |
| cyphermox | aka. core snap. | 00:50 |
| alvarolb | I submitted a bug in the meanwhile: https://bugs.launchpad.net/snappy/+bug/1654451 | 00:53 |
| mup | Bug #1654451: ubuntu store snap click-review error <Snappy:New> <https://launchpad.net/bugs/1654451> | 00:53 |
| mup | Bug #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 | ||
| mup | PR 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 | ||
| mup | PR 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 |
| mup | PR 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 | ||
| grapestomper | does anyone know how to change the default console output from ttyS0 to ttyUSB0 | 03:38 |
| grapestomper | snappy series 16 (core 16?) | 03:39 |
| grapestomper | kernel 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 | ||
| mup | PR 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 | ||
| mup | PR snapcraft#1029 opened: rust plugin: add conditional compilation <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1029> | 05:27 |
| mup | PR 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 | ||
| liuxg | grapestomper, 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/Center | 06:17 |
| liuxg | grapestomper, open the file and change it there dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline | 06:18 |
| === Guest89704 is now known as devil_ | ||
| mup | PR 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 | ||
| mup | PR 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 | ||
| mup | Issue snapd#2568 opened: snapd needs a SELinux profile to run on Fedora <Created by zyga> <https://github.com/snapcore/snapd/issue/2568> | 09:08 |
| mup | Issue 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 |
| mup | PR 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 |
| mup | Issue # closed: snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2559, snapd#2568, snapd#2569 | 09:23 |
| mup | PR # closed: snapd#2416, snapd#2433, snapd#2520, snapd#2528, snapd#2542, snapd#2562, snapd#2563, snapd#2564, snapd#2567 | 09:23 |
| mup | Issue # opened: snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2559, snapd#2568, snapd#2569 | 09:54 |
| mup | PR # opened: snapd#2416, snapd#2433, snapd#2520, snapd#2528, snapd#2542, snapd#2563, snapd#2564, snapd#2567 | 09:54 |
| mup | PR 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 | ||
| mup | PR snapcraft#1030 opened: tests: fix broken delta upload unit test <Created by shawn111> <https://github.com/snapcore/snapcraft/pull/1030> | 10:18 |
| mup | PR 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=0x0 | 11:34 |
| ogra_ | Jan 6 11:33:42 pi3 snap[3647]: Bad system call | 11:34 |
| ogra_ | looks like some seccomp love is needed there | 11: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 --devmode | 11:47 | |
| morphis | ogra_: hm, koza told me that it works and this thing is fixed, which core snap revision are you using? | 11:47 |
| morphis | not sure if it requires the latest from candidate and already works with the one from stable | 11:48 |
| ogra_ | ogra@pi3:~$ sudo pulseaudio.parec foo.wav | 11:48 |
| ogra_ | ^C | 11:48 |
| ogra_ | ogra@pi3:~$ ls -l foo.wav | 11:48 |
| ogra_ | -rw-r--r-- 1 root root 520856 Jan 6 11:48 foo.wav | 11:48 |
| ogra_ | ogra@pi3:~$ | 11:48 |
| ogra_ | works with --devmode | 11: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 edge | 11:49 |
| * ogra_ checks --candidate | 11:50 | |
| ogra_ | also needs --devmode to start | 11:51 |
| popey | Is 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 is | 11:52 |
| popey | is there a work item / card / bug? | 11:52 |
| ogra_ | definitely on the long term, list of the security team | 11:52 |
| popey | It's a blocker for an ISV with a postgresql database as a part | 11:52 |
| ogra_ | you gotta ask jdstrand | 11:52 |
| popey | ok | 11:53 |
| === chihchun is now known as chihchun_afk | ||
| sergiusens | popey it was recently (these past few days) discussed on the mailing list under "Process privileges and owners in snaps" | 12:09 |
| popey | sergiusens: thanks | 12:18 |
| === Guest76687 is now known as ahasenack | ||
| Elleo | jdstrand: 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 |
| mup | Issue 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 |
| DanChapman | Hey! 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 |
| DanChapman | Is this a known issue or some setting i might have accidently changed in myapps.d.u.c | 13:11 |
| nessita | DanChapman, what's the name of your snap? | 13:11 |
| nessita | (hi!) | 13:11 |
| DanChapman | nessita, hey! it's dekko | 13:11 |
| nessita | DanChapman, let me dig a little | 13:12 |
| DanChapman | thanks! | 13:12 |
| nessita | cjwatson, 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 min | 13:14 |
| ogra_ | could it be that you just hit that ? | 13:15 |
| nessita | ogra_, good point, thanks for pointing that out | 13:15 |
| DanChapman | ogra_: oh it could be that! I didn't know there was a delay. | 13:21 |
| DanChapman | nessita: i'll test again just to be sure. get back to you shortly :-) | 13:22 |
| cjwatson | will check logs after this call | 13:25 |
| nessita | DanChapman, thanks! | 13:29 |
| cjwatson | nessita,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 None | 13:29 |
| cjwatson | e.g. | 13:29 |
| nessita | cjwatson, thanks for checking! | 13:30 |
| mup | PR 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 None | 13:34 |
| cjwatson | DanChapman: has the most recent ppc64el build in https://launchpad.net/~dpniel/+snap/dekko-edge been released? | 13:34 |
| cjwatson | the log entry above is LP asking the store to do so | 13:35 |
| DanChapman | cjwatson: yes that has been released fine. | 13:37 |
| DanChapman | nessita: seems to be ok. I must not have left it long enough last time. | 13:37 |
| DanChapman | nessita: cjwatson: thanks for your help and sorry for the noise :-) | 13:37 |
| nessita | DanChapman, thanks for confirmin | 13:37 |
| nessita | g | 13:37 |
| ogra_ | :) | 13:37 |
| jdstrand | Elleo: 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 |
| cjwatson | np | 13:41 |
| Elleo | jdstrand: sorry, I meant abstract not anonymous | 13:42 |
| jdstrand | popey: 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 |
| jdstrand | popey (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 |
| jdstrand | Elleo: can you disable kernel rate limiting with: sudo sysctl -w kernel.printk_ratelimit=0 | 13:45 |
| JamieBennett | jdstrand, sounds good, a long requested feature so will be nice to see some solution | 13:45 |
| jdstrand | Elleo: then do 'tail -f /var/log/syslog|grep DEN' and see if there are any denials when trying to use maliit? | 13:46 |
| Elleo | jdstrand: no denials | 13:47 |
| Elleo | jdstrand: without that apparmor rule it was previously getting denials when trying to create the socket, so that's obviously having an effect at least | 13:48 |
| jdstrand | popey (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 implemented | 13:49 |
| jdstrand | Elleo: 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 problem | 13:51 |
| Elleo | jdstrand: it works if the snap is installed with devmode though, so presumably it's something confinement related | 13:51 |
| jdstrand | Elleo: sure, but not necessarily apparmor. before diving into qtdbus internals, you might strace it | 13:52 |
| mup | PR 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 |
| jdstrand | Elleo: 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 |
| jdstrand | Elleo: 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 namespace | 13:56 |
| Elleo | jdstrand: yep, and if I grep for ALLOWED there's a line for the binding: http://pastebin.ubuntu.com/23752229/ | 13:56 |
| Elleo | jdstrand: although, what's the "denied_mask" property? | 13:56 |
| jdstrand | Elleo: 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 confused | 13:58 |
| * jdstrand doubts that is the case) | 13:58 | |
| jdstrand | Elleo: denied_mask is the part of requested_mask that got denied | 13:58 |
| jdstrand | Elleo: all my questions regarding denials are for when running in strict mode. ALLOWED shows you are in devmode | 13:59 |
| ogra_ | xnox, yo ! | 13:59 |
| Elleo | jdstrand: ah right, that'd have been from when I double checked it worked okay in devmode then | 13:59 |
| Elleo | jdstrand: aha, there are seccomp entries: http://pastebin.ubuntu.com/23752238/ | 13:59 |
| jdstrand | $ scmp_sys_resolver 50 | 14:00 |
| jdstrand | listen | 14:00 |
| jdstrand | use 'network-bind' | 14:01 |
| jdstrand | if you are writing an interface for maliit, then add 'listen' to you seccomp filter | 14:01 |
| Elleo | jdstrand: ah okay, thanks :) | 14:01 |
| mup | PR snapcraft#1031 opened: store: fix sso_host for dev sso <Created by shawn111> <https://github.com/snapcore/snapcraft/pull/1031> | 14:06 |
| Elleo | jdstrand: that's fixed it, thanks very much! | 14:09 |
| jdstrand | Elleo: great! :) | 14:10 |
| jdstrand | mvo: 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 though | 14: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 |
| mvo | jdstrand: thank you | 14:31 |
| jdstrand | ogra_: the top comes from the default template. the bottom from a slot snippet | 14:32 |
| ogra_ | ah, k, thanks | 14:32 |
| jdstrand | ogra_: the top is a reminder that we don't (yet) support privilege dropping | 14:32 |
| xnox | ogra_, 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-bind | 14:36 |
| mvo | jdstrand: updated | 14:36 |
| jdstrand | mvo: thanks! | 14:36 |
| mup | Bug #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 |
| xnox | ogra_, yes and we don't what that. | 14:38 |
| xnox | ogra_, 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 |
| xnox | using 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 |
| xnox | ogra_, 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 |
| xnox | yes. | 14:40 |
| ogra_ | well ... we'Re often operating on devicers with very low ram but a lot of diskspace | 14:41 |
| xnox | on 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 |
| xnox | ogra_, 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 indeed | 14:42 |
| ogra_ | yes, i know | 14:42 |
| ogra_ | in that light dynamic swap file creation will help a lot though | 14:42 |
| xnox | you have to use less memory - that's the best win, for size, performance, longivity. | 14:42 |
| xnox | no, it won't. | 14:42 |
| ogra_ | you only wear out flash if you write a lot to the same place | 14:42 |
| ogra_ | due to dynamic creation that cant happen | 14:43 |
| xnox | hahahahahahahaha | 14:43 |
| ogra_ | (compared to a fixed swapfile) | 14:43 |
| xnox | hahahahaha | 14:43 |
| xnox | it's the same. | 14:43 |
| ogra_ | or will happen less at least :) | 14:43 |
| xnox | because 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 |
| xnox | therefore 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 anymore | 14:44 |
| xnox | on average, it's the same wear. | 14:44 |
| xnox | it'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 file | 14:44 |
| xnox | at all. | 14:44 |
| ogra_ | right, but we have user demand for it | 14:44 |
| ogra_ | so we need to provide *something* | 14:45 |
| ogra_ | and dynamic feels safe than permanent | 14:45 |
| xnox | how 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 |
| ogra_ | *safer | 14:45 |
| mup | PR 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 |
| xnox | it's fragile =) | 14:45 |
| ogra_ | true indeed ... but if the blocks are in use new blocks will be used | 14:45 |
| xnox | which can remap to the old physical block. | 14:46 |
| ogra_ | which is more likely if you have small fragmented files | 14:46 |
| xnox | it's really random walk on most of these controllers. | 14:46 |
| xnox | microcontroller has no visilibity to FS files. | 14:46 |
| xnox | and does not care about virtual blocks either. | 14:46 |
| ogra_ | inded | 14:46 |
| xnox | it really picks any =) | 14:46 |
| ogra_ | ok, so much for that theory :P | 14:47 |
| ogra_ | anyway, it will not permanently eat disk space ... thats still one advantage | 14:47 |
| xnox | so on reboot, your static swapfile may write to new physical locations =/ (that is quite scary....) | 14:47 |
| xnox | ogra_, does not work on btrfs or zfs..... | 14:47 |
| xnox | or lvm. | 14:47 |
| ogra_ | which we currenmtly dont care for on core images | 14:48 |
| ogra_ | the OS is currently hardcoded to ext4 | 14:48 |
| xnox | ... | 14:48 |
| ogra_ | indeed it will bite once we support other FSes | 14:48 |
| xnox | think this trough a little. | 14:48 |
| xnox | talk to ubuntu-image developers about this. | 14:48 |
| ogra_ | (which i'm not sure we'll do anytime soon) | 14:49 |
| xnox | we are shipping lvm cloud images soon. | 14:49 |
| ogra_ | snappy based ? | 14:49 |
| ogra_ | that will require a ton of changes in the OS | 14:49 |
| ogra_ | everything everywhere currently expects ext4 | 14:49 |
| xnox | i thought ext2 was the end-game for filesystems too at one point =) | 14:50 |
| xnox | and that armhf will rule them all | 14:50 |
| xnox | etc. | 14:50 |
| ogra_ | well, its a legacy we carry from system-image setups | 14:50 |
| xnox | things will change, because things do change =) | 14:50 |
| ogra_ | it can surely be changed to other filesystems but will need a lot of changes | 14:50 |
| ogra_ | code changes i mean | 14: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 |
| alvarolb | thanks jdstrand for reviewing the bug in click-reviewer-tools | 14:55 |
| grapestomper_1 | does 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 bootloader | 14:58 |
| grapestomper_1 | I used to do this in grub.d but that is not there. what file is it now | 14:58 |
| ogra_ | somewhere in /boot/grub/ | 14:58 |
| ogra_ | iirc | 14:59 |
| * ogra_ rarely touches x86 images | 14:59 | |
| grapestomper_1 | I looked at there but all the files are read-only | 14:59 |
| ogra_ | hmm, i thought the grub.cfg is rw | 14:59 |
| grapestomper_1 | I see a 50-system-image.cfg that is rw | 15:00 |
| grapestomper_1 | I take that back | 15:01 |
| ogra_ | no, there needs to be a grub.cfg | 15:01 |
| grapestomper_1 | -rw-r--r-- 1 root root | 15:01 |
| grapestomper_1 | agreed :) but I dont see one | 15:02 |
| ogra_ | well, the other option is to roll your own gadget snap with changed cmdline | 15:02 |
| ogra_ | to do that you clone https://github.com/snapcore/pc-amd64-gadget | 15:02 |
| ogra_ | and then edit prebuilt/grub.cfg (commandline is at the bottom there) and call snapcraft in the toplevel dir of the branch | 15:03 |
| grapestomper_1 | ok, thanks - I will look into that | 15:03 |
| diddledan | the 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 |
| mup | Bug #1654585 opened: seccomp profile of pulseaudio snap misses syscalls on armhf <Snappy:New for jdstrand> <https://launchpad.net/bugs/1654585> | 15:10 |
| kgunn | niemeyer: hey there, kyrofa thot you might be the right guy to ping | 15:17 |
| kgunn | we're creating a mir-kiosk image | 15:17 |
| kgunn | but trouble is mir-kiosk launches before i can run console-conf | 15:17 |
| kgunn | is 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 successfully | 15:23 |
| ogra_ | but i have no idea how you would be able to see this from a snap | 15:23 |
| ogra_ | (might need some special interface) | 15:24 |
| kgunn | ogra_: it would seem like this might be something that other people would want to know as snap image creation proliferates in the world | 15:28 |
| morphis_ | ogra_: mvo told me to poke you about https://bugs.launchpad.net/snappy/+bug/1654588 | 15:34 |
| mup | Bug #1654588: Make /etc/systemd/logind.conf.d writable <Snappy:New> <https://launchpad.net/bugs/1654588> | 15:34 |
| mup | Bug #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 core | 15:39 |
| mup | Bug #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 |
| mup | PR snapcraft#1032 opened: Use more secure temporary directory for parser runs <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1032> | 15:48 |
| mup | PR 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 |
| jdstrand | lool: hey, fyi, testing docker on trusty/i386 (note bug 1654590 which I'm going to fix): | 16:15 |
| mup | Bug #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 uptime | 16:15 |
| jdstrand | docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime error: exec format error". | 16:15 |
| jdstrand | lool: oh, nm, I'm dumb | 16:16 |
| jdstrand | I think I pulled a 64 bit image | 16:16 |
| lool | eh | 16:16 |
| jdstrand | lool: do you know how to pull a 32 bit image? sudo docker pull ??? | 16:19 |
| lool | jdstrand: they only introduced multiarch images recently; the armhf image is named differently: arm/ubuntu instead of ubuntu | 16:20 |
| lool | jdstrand: docker run 32bit/ubuntu | 16:20 |
| Sweet5hark | can 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 |
| mup | Bug #1649620: stuff downloaded during "pull()" is deleted before "build()" <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1649620> | 16:21 |
| lool | jdstrand: TBH 32-bits images might not be maintained anymore | 16:21 |
| jdstrand | lool: that is what I tried: | 16:21 |
| jdstrand | $ sudo docker pull 32bit/ubuntu | 16:21 |
| jdstrand | Using default tag: latest | 16:21 |
| jdstrand | Pulling repository docker.io/32bit/ubuntu | 16:21 |
| jdstrand | Tag latest not found in repository docker.io/32bit/ubuntu | 16:21 |
| jdstrand | I think I'll just focus on amd64 for docker for my testing | 16:23 |
| lool | jdstrand: Yes, i386 is not officially supported upstream and they dont really support biarch either | 16:24 |
| lool | they need docker support libraries for the 64 bits docker binary inside the 32bits container | 16:24 |
| jdstrand | ah | 16:24 |
| lool | amd64 is a better base | 16:24 |
| lool | or armhf | 16:24 |
| lool | or even arm64 | 16:24 |
| jdstrand | wonder if the i386 snap makes sense then | 16:24 |
| seb128 | Sweet5hark, what is it that you refer as 'pull()' and 'build()'? snapcraft isn't deleting anything if you don't use 'clean' afaiik | 16:28 |
| seb128 | Sweet5hark, you said it's only doing that on launchpad and not on local builds? | 16:30 |
| seb128 | Sweet5hark, 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 |
| niemeyer | kgunn: Heya | 16:46 |
| kgunn | hey o/ | 16:46 |
| niemeyer | kgunn: What's the actual outcome from console-conf that mir-kiosk depends on? | 16:46 |
| kgunn | niemeyer: 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 screen | 16:47 |
| niemeyer | kgunn: Hmm | 16:48 |
| Sweet5hark | seb128: 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 |
| kgunn | niemeyer: i was thinkin', i could just add access to the /var/lib/console-conf/completed | 16:49 |
| kgunn | to the mir interface | 16:49 |
| kgunn | to prevent launching in the instance it's not there... | 16:50 |
| kgunn | thots? | 16:50 |
| seb128 | Sweet5hark, but only on launchpad? | 16:50 |
| niemeyer | kgunn: The idea of snapctl managed felt nice | 16:50 |
| mup | PR 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 |
| niemeyer | kgunn: But both of these feel slightly awkward from the perspective that console-conf is going away for good.. it also feels slightly magic | 16:51 |
| niemeyer | Finish console-conf and BAM, you're off into something else altogether | 16:51 |
| niemeyer | kgunn: If we're exposing console-conf as an actual UI, why isn't the enablement of the kiosk an explicit action? | 16:52 |
| niemeyer | mir-kiosk.takeover | 16:52 |
| niemeyer | kgunn: That'd feel a lot less like a behind-my-back action, if you see what I mean | 16:53 |
| kgunn | niemeyer: yeah, i see what you mean | 16:55 |
| Sweet5hark | seb128: nope, locally too. | 16:55 |
| seb128 | Sweet5hark, sorry, just saw your new comment ... so yeah, snapcraft issue | 16:56 |
| seb128 | sergiusens or kyrofa might have some clue what could be going on there | 16:56 |
| Sweet5hark | seb128: 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 |
| kgunn | niemeyer: 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 |
| kgunn | AlbertA: fyi ^ | 16:57 |
| seb128 | Sweet5hark, you can use the network in build now | 16:58 |
| niemeyer | kgunn: No.. I mean you'd have an actual command that once called would make the kiosk takeover | 16:58 |
| kgunn | niemeyer: k, just thinking it thru....like a real kiosk maker, how they'd install the device..and steps they'd go thru | 16:58 |
| seb128 | Sweet5hark, see email https://lists.ubuntu.com/archives/snapcraft/2016-December/001978.html | 16:59 |
| lazyPower | elopio - (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 |
| niemeyer | kgunn: A polished device experience would hopefully avoid console-conf altogether | 17:00 |
| lazyPower | i 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 launchpad | 17:01 |
| niemeyer | kgunn: So it really depends quite a bit on what we want to have | 17:01 |
| kgunn | AlbertA: so with this idea ^ we just need to make it not be a daemon | 17:01 |
| Sweet5hark | seb128: ah, cool. will give that a try as a workaround. | 17:02 |
| AlbertA | niemeyer: kgunn: would "takeover" be similar to calling a config hook? | 17:18 |
| AlbertA | or would console-conf just call that command? | 17:18 |
| kgunn | AlbertA: iiuc, it would be a separate thing from console-conf | 17:21 |
| AlbertA | and what would replace connsole-conf, some sort of provisioning tool on the host computer? | 17:22 |
| lazyPower | do we have any info on how to interface with systemd via installed snap? My google-fu is failing me | 17:22 |
| mup | PR 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 |
| seb128 | Sweet5hark, I can confirm your bug btw | 17:50 |
| seb128 | Sweet5hark, 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 pull | 17:52 |
| sergiusens | seb128 why would it be created as part of the pull? | 17:52 |
| seb128 | Sweet5hark, you should probably pull somewhere else and move it in the build | 17:53 |
| seb128 | sergiusens, 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#n173 | 17:53 |
| seb128 | sergiusens, that's about https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1649620 | 17:53 |
| mup | Bug #1649620: stuff downloaded during "pull()" is deleted before "build()" <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1649620> | 17:53 |
| mhall119 | jdstrand: 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 |
| sergiusens | elopio add libreoffice to the candidate testing btw ^ | 17:54 |
| sergiusens | kyrofa can you help seb128 out? I can do that on and off next week or the week after for sure | 17:56 |
| kyrofa | sergiusens, sure, let me take a look | 17:56 |
| seb128 | sergiusens, kyrofa, Sweet5hark, it's probably for next week now | 17:56 |
| Sweet5hark | seb128, 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 |
| sergiusens | Sweet5hark if in pull, put stuff in srcdir or in installdir and it will stick | 17:58 |
| Sweet5hark | seb128, 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 |
| jdstrand | mhall119: initial upload, yes. subsequent uploads, no | 17:59 |
| Sweet5hark | sergiusens: 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 |
| kyrofa | Sweet5hark, 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 building | 18:02 |
| kyrofa | Sweet5hark, 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 there | 18:03 |
| mup | PR snapcraft#1033 opened: misc: delete bzr ignore <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1033> | 18:03 |
| kyrofa | Sweet5hark, I still don't quite understand why you're wanting to build stuff in the pull step though | 18:05 |
| kyrofa | The scrollback was a little spread out so I'm not sure I got everything | 18:06 |
| Sweet5hark | kyrofa: I dont want to build during pull | 18:07 |
| kyrofa | Ah, you're just cloning and patching, it seems? | 18:08 |
| kyrofa | Sweet5hark, 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 |
| Sweet5hark | kyrofa: 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 |
| kyrofa | Sweet5hark, 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 |
| kyrofa | Sweet5hark, if you're concerned about space, you can use shutil.copytree with file_utils.link_or_copy as its copy_function | 18:24 |
| kyrofa | That'll hard link | 18:24 |
| Sweet5hark | kyrofa: 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 |
| kyrofa | Sweet5hark, the method I described to you is used by numerous plugins within snapcraft itself | 18:37 |
| Sweet5hark | kyrofa: that doesnt mean at all that Random J Upstreamcoder will do it that way too. | 18:40 |
| kyrofa | Sweet5hark, my point is, if you want a best practice, perhaps that's a good place to look. | 18:41 |
| kyrofa | Sweet5hark, I agree that the local plugin stuff needs to be further documented | 18:41 |
| mup | Bug #1654629 opened: Async REST API operations don't return 'Location' header <Snappy:New> <https://launchpad.net/bugs/1654629> | 18:42 |
| Sweet5hark | kyrofa: 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 |
| Sweet5hark | right ;) | 18:42 |
| jdstrand | roadmr: hi! can you pull r815 of the review tools? this fixes bug #1654451 | 18:50 |
| mup | Bug #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 | ||
| mup | Bug #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 | ||
| diddledan | weird. 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 manually | 19:45 |
| diddledan | building myself I used the command `snapcraft cleanbuild` so I assumed that because that worked then the launchpad autobuilder would produce the same result | 19:47 |
| kyrofa | diddledan, happy to take a look at your yaml | 19:49 |
| diddledan | kyrofa: https://git.launchpad.net/~diddledan/+git/corebird/tree/snapcraft.yaml?id=4fecf0085f66f7024fe7eefafe07ecd540ea318d | 19:49 |
| kyrofa | diddledan, can I see the LP log? | 19:50 |
| diddledan | do 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.gz | 19:51 |
| kyrofa | Yeah snap builds are public, link is good | 19:51 |
| kyrofa | diddledan, that log seems to end in success... ? | 19:51 |
| diddledan | kyrofa: yeah the build is fine. it's the running of the result that fails hard | 19:52 |
| kyrofa | Ah | 19:52 |
| diddledan | but the same yaml run locally through cleanbuild works fine | 19:52 |
| kyrofa | diddledan, the use of architectures in your yaml is a little suspicious. I don't see that often | 19:53 |
| diddledan | i.e. the store version is b0rked despite being supposedly identical to what I've built and tested outside of the store | 19:53 |
| diddledan | I read somewhere about architectures tag, I can try removing it and letting it rebuild | 19:54 |
| kyrofa | diddledan, yeah, remove it and just ask LP to build one snap for each arch | 19:54 |
| kyrofa | diddledan, how does the one built by LP break? | 19:55 |
| diddledan | the 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 |
| kyrofa | Hoo, beautiful | 19:58 |
| diddledan | :-) | 19:59 |
| diddledan | errors are always fun :-p | 19:59 |
| kyrofa | diddledan, I think the architectures thing is saying "this snap will run without modification on the archs I specify" | 19:59 |
| kyrofa | But then the libs that are being pulled in are probably arch-specific | 19:59 |
| kyrofa | So remove that option, and check both i386 and amd64 boxes for which archs to build in LP | 20:00 |
| kyrofa | Then it'll build one snap for each arch | 20:00 |
| diddledan | so 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 |
| kyrofa | The rest of the world meaning the system on which the snap was installed? | 20:01 |
| diddledan | meaning that gtk and such are all excluded because I didn't list it directly | 20:02 |
| kyrofa | diddledan, no they're included as well as a result of the remote gtk part you're using | 20:02 |
| diddledan | hmm | 20:02 |
| kyrofa | It's just that which ones are pulled depend on the arch of the builder | 20:02 |
| kyrofa | But you're yaml is promising that the resulting snap can run on both amd64 and i386 | 20:03 |
| * diddledan scrachy head | 20:04 | |
| diddledan | scratchy* | 20:04 |
| diddledan | my Brian hurts :-p | 20:04 |
| kyrofa | Heh. Try removing it, and see if that helps. Just make sure you ask LP to build for both archs | 20:05 |
| diddledan | yup, I've done so. just waiting on LP now (it hasn't noticed the build needs running yet) | 20:05 |
| kyrofa | diddledan, let me know | 20:09 |
| diddledan | willdo | 20:09 |
| grapestomper_1 | looking for help with packaging a deb file - does anyone have a link or two they can refer me to? | 20:23 |
| roadmr | jdstrand: sure, r815 coming up | 20:29 |
| mup | PR 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 |
| jdstrand | roadmr: thanks! | 20:34 |
| diddledan | kyrofa: positive result - removing the architectures config fixes it | 20:39 |
| kyrofa | diddledan, excellent | 20:42 |
| diddledan | now 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 |
| diddledan | all 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 supported | 20:46 |
| kyrofa | diddledan, I'm afraid I have zero experience with that. Perhaps jdstrand can help | 20:46 |
| kyrofa | diddledan, do you see any denials in syslog or with snappy-debug? | 20:46 |
| diddledan | yes, grepping /var/log/syslog reports apparmor="DENIED" | 20:48 |
| diddledan | oops | 20:48 |
| diddledan | http://paste.ubuntu.com/23754260/ | 20:48 |
| diddledan | ^ reports that | 20:48 |
| diddledan | last 5 lines seem to be the most recent attempt | 20:49 |
| diddledan | let me try snappy debug | 20:49 |
| jdstrand | I 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 |
| jdstrand | you 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 |
| jdstrand | then run: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.corebird-diddledan.corebird | 20:52 |
| jdstrand | then 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 |
| diddledan | should I add those two lines to the bottom or in a specific location of the profile? | 20:53 |
| jdstrand | diddledan:: anywhere is fine. just before the trailing '}' | 20:58 |
| diddledan | ok, I added those lines (fixing the missing comma in the first one :-p) but still failing. it seems corebird isn't using xdg-open then | 20:59 |
| jdstrand | diddledan: whoops, the first has a typo | 20:59 |
| * jdstrand nods | 20:59 | |
| jdstrand | sounds like it, yeah. I think didrocks may know more, but he seems offline | 20:59 |
| jdstrand | maybe send a new email to the list? | 20:59 |
| diddledan | it's odd because I know that I _have_ had it working with the same version of corebird but in a devmode snap | 21:00 |
| jdstrand | hmm | 21:00 |
| mup | PR snapcraft#1009 closed: store: implement push pre-check <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1009> | 21:00 |
| diddledan | I'm thinking maybe the environment in which LP compiles could be slightly different to a cleanbuild lxd container? | 21:00 |
| diddledan | that seems to be the only difference - the snap built by LP rather than locally | 21:01 |
| diddledan | other than devmode/strict | 21:01 |
| diddledan | ok, 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 theory | 21:18 |
| diddledan | yes. the same package installed using --devmode to snap install allows xdg-open to work correctly | 21:19 |
| diddledan | is 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 |
| diddledan | revert --devmode is possible but that requires a previous version to be available on your system | 21:24 |
| diddledan | and refresh --devmode is possible but that requires a later version in the store than you have installed | 21:24 |
| jdstrand | diddledan: I'm not sure how to move back and forth. I can try to reproduce here | 21:29 |
| kyrofa | jdstrand, how much do you know about gnome-keyring? Would an interface for it be easy, you think? | 21:35 |
| jdstrand | kyrofa: I can't think of anything otoh that would be particularly difficult | 21:36 |
| kyrofa | jdstrand, is it just dbus? | 21:37 |
| jdstrand | afaik | 21:37 |
| kyrofa | jdstrand, would you say it would need to be privileged? | 21:41 |
| kyrofa | i.e. manual connection required | 21:41 |
| jdstrand | kyrofa: for sure | 21:46 |
| jdstrand | on Ubuntu, the keyring is unlocked on login and any application in the session get obtain the passwords | 21:46 |
| kyrofa | jdstrand, yeah makes sense | 21:47 |
| jdstrand | for it to be auto-connectable, gnome-keyring would have to be modified to only allow access to certain keys from certain security labels | 21:47 |
| jdstrand | and/or have apparmor integration, then we could think about policy | 21:48 |
| kyrofa | Alright | 21:48 |
| jdstrand | diddledan: this is needed: /usr/local/share/applications/{,*} r, | 22:10 |
| diddledan | jdstrand: yes, confirmed, that line added to the profile fixes it | 22:13 |
| jdstrand | diddledan: https://bugs.launchpad.net/snappy/+bug/1654666 | 22:15 |
| mup | Bug #1654666: snapd-xdg-open doesn't work in strict mode <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1654666> | 22:15 |
| jdstrand | diddledan: I'll get that fixed hopefully for 2.21 | 22:16 |
| diddledan | thank you. I've marked as affecting me, and subscribed to notifications :-) | 22:16 |
| jdstrand | cool | 22:16 |
| mup | Bug #1654666 opened: snapd-xdg-open doesn't work in strict mode <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1654666> | 22:16 |
| jdstrand | I'm heading out now, but feel free to add comments to the bug | 22:17 |
| diddledan | ok | 22:17 |
| diddledan | thanks again | 22:17 |
| jdstrand | np | 22:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!