[01:35] <olympionex>  I'm having trouble running 'snap try' with snap/snapd vs 2.21 on 16.04.  The confinement is specified as classic and when I run 'snap try --classic' or 'snap try --devmode', I still get the error that it requires consent to use classic confinement
[03:05] <telelaci> quit
[03:05] <telelaci> exit
[03:05] <telelaci> help
[03:05] <telelaci> ?
[03:06] <telelaci> shit
[03:09] <mup> Bug #1659719 opened: ssh can't call a binary from a snap without the full path <Snappy:New> <https://launchpad.net/bugs/1659719>
[03:51] <mup> Bug #1659724 opened: Feature request: give applications unrestricted access to d-bus services provided by the same snap <Snappy:New> <https://launchpad.net/bugs/1659724>
[06:45] <ubuntunoddy> how to convert nodejs app to snap app
[07:01] <mup> PR snapd#2729 closed: tests: use test snap <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2729>
[07:03] <mup> PR snapd#2731 opened: store: always log retry summary when SNAPPY_TESTING is set <Created by mvo5> <https://github.com/snapcore/snapd/pull/2731>
[07:07] <mup> PR snapd#2722 closed: tests: set SNAPPY_USE_STAGING_STORE in su call <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2722>
[07:19] <mup> Bug #1659744 opened: Classic snaps 'not found' if --classic argument is missing <Snappy:New> <https://launchpad.net/bugs/1659744>
[08:05] <mup> PR snapd#2732 opened: snapenv: do not append ":" to the SNAP_LIBRARY_PATH <Created by mvo5> <https://github.com/snapcore/snapd/pull/2732>
[08:47] <mup> PR snapd#2733 opened: tests: make the debugging of c-unit-tests more useful <Created by zyga> <https://github.com/snapcore/snapd/pull/2733>
[08:51] <mup> PR snapcraft#1082 closed: project: new plugin directory location <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1082>
[10:18] <mup> PR snapd#2730 closed: snap: be more helpful in the `snap install <already-installed>` error message <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2730>
[10:45] <mup> PR snapcraft#1083 opened: project: support for gui in snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1083>
[10:45] <mup> PR snapd#2734 opened: debian/tests: drop stale autopkgtest dependencies <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2734>
[11:03] <mup> Bug #1637299 changed: sudo snap login "Password:" prompt unclear what password to type <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1637299>
[11:27] <mup> Bug #1633230 opened: snap ack doesn't indicate which assertions are good or bad <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1633230>
[11:27] <mup> Bug #1633261 opened: snap ack should provide a summary of the assertions status <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1633261>
[11:39] <mup> PR snapcraft#1084 opened: make: add support for cwd path to make() function <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1084>
[12:00] <mup> PR snapcraft#1085 opened: snapcraft: fix or ignore PEP8 static errors <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1085>
[12:09] <mup> PR snapcraft#1086 opened: print snapcraft's version on startup when running with --debug <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1086>
[12:21] <mup> PR snapd#2721 closed: tests: integration test  for system reload <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2721>
[12:23] <popey> I have a build which is failing in launchpad. Seems the 'sudo chroot' bit at the bottom barfs.. https://launchpadlibrarian.net/304085507/buildlog_snap_ubuntu_xenial_amd64_openbazaar_BUILDING.txt.gz
[12:23] <popey> one for cjwatson perhaps ^ ?
[12:24] <cjwatson> package context: unrecognized import path "context" (import path does not begin with hostname)
[12:24] <cjwatson> that's the actual failure
[12:24] <cjwatson> the rest is just consequential errors
[12:24] <cjwatson> popey: ^-
[12:25] <cjwatson> and that's something in your snap
[12:27] <popey> hm
[12:27] <popey> thanks for looking.
[12:43] <mup> Bug #1658909 changed: lsb_release fails in classic (arm64) <Snappy:Confirmed for ogra> <lsb (Ubuntu):Invalid> <lsb-release (Ubuntu):Invalid> <https://launchpad.net/bugs/1658909>
[13:35] <Elleo> I'm getting some very odd behaviour with gsettings under confinement, when the snap starts it reads them fine, but it seems to be unable to change them or to get notified of changes if I modify the gsettings manually (but it will pick up the changes after being restarted), anyone have any ideas what might be happening?
[13:35] <Elleo> (it works fine when in devmode)
[14:15] <mup> PR snapd#2482 closed: store: retry auth-related requests <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2482>
[14:26] <morphis> ogra_: there?
[14:43] <zyga> Elleo: do you get any apparmor denials
[14:43] <zyga> Elleo: apparmor controls all dbus traffic
[14:43] <zyga> Elleo: and notification is a distinct signal from read/write calls
[14:43] <zyga> Elleo: dmesg | grep DENIED
[14:43] <zyga> Elleo: and report that as a bug please
[14:43] <jdstrand> I think it is something else
[14:44] <zyga> jdstrand: hey :)
[14:44] <zyga> jdstrand: what do you think?
[14:44] <jdstrand> I suspect it is the bug where HOME is set to ~/snap/SNAP_NAME/SNAP_REVISION and the global dconf is in ~/.config/dconf. the policy allows it, but dconf is having trouble finding it
[14:45] <mup> PR snapd#2733 closed: tests: make the debugging of c-unit-tests more useful <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2733>
[14:45] <jdstrand> I think a symlink from  ~/snap/SNAP_NAME/SNAP_REVISION/.config/dconf to ~/.config/dconf would workaround it. my memory may be hazy. I think seb128 has the details
[14:46] <jdstrand> zyga: nad hi :)
[14:53] <Elleo> zyga: no denials, monitoring the gsetting it seems it does get written to, but then immediately gets changed back for some reason :/
[14:54] <Elleo> zyga: unless I change it manually via gsettings, in which case it stays fine but doesn't get notified
[14:56] <Elleo> popey: /32
[14:57] <Elleo> popey: that bucklespring is a bit worrying :P
[14:57] <Elleo> popey: isn't it basically exploiting the fact that x11 has zero security and acting like a keylogger?
[14:57] <zyga> jdstrand: thanks for the review on the snap-update-ns draft; I'll fix the things you pointed out and focus on figuring out what is broken in the kernel
[14:58] <ogra_> morphis, i'm back now
[14:58] <zyga> jdstrand: while we don't hit that particular issue here (I suspect because we are not starting from a namespace already) I think that you are right in first having a clear understanding of what is at play
[14:59] <seb__> Hi! Does any one know if it's possible to get the mac current out of the USB ports on a Raspberry pi 2? Used to do it with "usb_max_current=1"
[15:00] <zyga> ogra_: ^
[15:01]  * ogra_ doesnt know ... 
[15:01] <morphis> ogra_: great :-)
[15:01] <ogra_> seb__, where do you put that usually ? config.txt ? cmdline.txt ?
[15:02] <zyga> seb__: let me grep one thing
[15:02] <seb__> config.txt usually. New to snappy core
[15:03] <ogra_> well, confi.txt is there, you can just edit it as needed ... it is mounted under /boot/uboot/
[15:03] <seb__> really?!, ohh damn. Gotte go check that
[15:03] <ogra_> (or directly if you plug the SD into your PC ... in the system-boot partition)
[15:04] <ogra_> just make sure you dont drop anything of the existing options that are set there
[15:04] <ogra_> else something might break
[15:04] <seb__> Understood
[15:09] <popey> Elleo: pfffft, you worry too much :S
[15:10] <popey> Elleo: it uses X11 and pulse, no network...
[15:12] <seb__> It worked! Thank you for your help :D
[15:24] <cjwatson> popey: oh, while I remember, it'd be low-priority, but maybe a bug on launchpad-buildd to ask us to have a clean error message rather than a noisy traceback in this case would be good
[15:24] <cjwatson> you'd probably have noticed the actual error if it hadn't been followed by a pile of barf
[15:39] <roadmr> jdstrand: tools r833 is in prod! yay, I left them ready for deploy yesterday and they seem to have piggybacked on an impromptu deployment that happened just before midnight.
[15:39] <popey> cjwatson: good point
[15:50] <mup> PR snapd#2734 closed: debian/tests: drop stale autopkgtest dependencies <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2734>
[15:54] <rvr> ogra_: Do you do anything special to enable the serial console on the Pi?
[15:55] <ogra_> rvr, whats missing ?
[15:55] <ogra_> rvr, we set enable_uart in config.txt and we have a console= arg in cmdline.txt for serial
[15:56] <rvr> ogra_: I got a USB TTL serial adapter and I don't get anything in the console
[15:56] <zyga> jdstrand: I have a question about the mount/unmount helpers
[15:56] <zyga> jdstrand: about conditionality of logging
[15:56] <ogra_> did you wire it up correctly ?
[15:56] <rvr> ogra_: What's the speed? 115200
[15:56] <zyga> jdstrand: qemu:ubuntu-16.04-64:tests/main/op-remove
[15:56] <ogra_> yeah
[15:56] <rvr> ogra_: I think so, RX->TX, TX->RX
[15:56] <zyga> jdstrand: if you can answer that one quickly I will do the rest of the changes
[15:57] <ogra_> i usually use: screen /dev/ttyUSB0 115200
[15:58] <ogra_> rvr, and only gnd/rx/tx ... not 5V connected, right ?
[15:58] <rvr> ogra_: 5V connected
[15:58] <rvr> ogra_: And HDMI
[15:58] <ogra_> (connecting the red 5V cable can damage the board)
[15:58] <rvr> ogra_: Oh, I see
[15:59] <ogra_> hdmi shouldnt matter ... the two consoles are separate ... you get consoles on both tty's usually
[16:01] <jdstrand> zyga: I'm not sure what you are linking to. can you give a full url?
[16:02] <zyga> jdstrand: sorry, sure
[16:03] <zyga> https://github.com/snapcore/snapd/pull/2658
[16:03] <mup> PR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
[16:03] <zyga> jdstrand: let's just discuss it here
[16:03] <zyga> jdstrand: do you want me to make a debug version of snap-confine
[16:03] <zyga> jdstrand: that can do logging
[16:03] <zyga> jdstrand: and have all the log (and support code) compile to nothing in the regular build?
[16:04] <zyga> jdstrand: and (since we're talking), about the static vs dynamic buffer; originally I implemented this to use a dynamically allocated buffer
[16:04] <zyga> jdstrand: but the snappy team -1 the change as too complex
[16:04] <zyga> jdstrand: so I changed that to a "good enough" static buffer
[16:05] <jdstrand> zyga: I'd prefer that debug* is compiled out on production builds, yes
[16:05] <jdstrand> zyga: I gave another option to the static buffer that would not be complex
[16:05] <zyga> jdstrand: do you have a plan on how we'd be assisting people in debugging issues?
[16:05] <zyga> jdstrand: the N-variant of scpcpy?
[16:06] <zyga> jdstrand: IMHO both approaches are equally non-complex (I don't see malloc as particularly complex in this case, there are exactly two places that call those functions)
[16:07] <jdstrand> zyga: re variant> you call debug_mount_cmd(), it does 'char cmd[BUF_SIZE]' then pass that into your function
[16:07] <stokachu> so with latest snapcraft i saw a commit about merging snap and snapcraft directory
[16:07] <stokachu> can i put everything under /snap directory and all is well?
[16:07] <jdstrand> zyga: it isn't the on the stack bit I cared about, it was 'static'
[16:08] <stokachu> sergiusens, ^
[16:08] <zyga> jdstrand: ah, I see
[16:08] <zyga> jdstrand: that's easy enough
[16:08] <stokachu> also does the store support reading the /snap/setup/gui directory?
[16:09] <zyga> jdstrand: (I still prefer dynamic but I don't think this is an issue)
[16:09] <zyga> jdstrand: though in practice this function will move that buffer from one place to another
[16:09] <zyga> jdstrand: and with the _must approach it won't be any more reusable
[16:09] <zyga> (you either get the buffer size right or you don't)
[16:09] <mup> PR snapd#2726 closed: interfaces/builtin: rework core-support to only allow full access to systemctl <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2726>
[16:10] <pedronis> zyga: for what it worth, when I said static I meant static sized,  so what jdstrand is suggesting
[16:10] <pedronis> I don't know what the other meant
[16:10] <zyga> pedronis: static char[100]; vs char[100] vs char * (and malloc)
[16:11] <pedronis> the 2nd
[16:11] <zyga> pedronis: thanks for clarifying that
[16:12] <pedronis> sorry, C has that kind of static, I know, but might brain almost never think of it, it's rarely a good idea
[16:12] <zyga> static has many meanings, unfortunately
[16:12] <pedronis> yea
[16:12] <pedronis> C++ adds a couple more
[16:13] <zyga> indeed
[16:13] <zyga> keywords are hard to add to a language
[16:13] <zyga> anyway
[16:13] <jdstrand> zyga: as for test plan, I would say they get to compile a snap-confine with debugging. putting it behind an env variable doesn't help with protection for someone attack snap-confine. the attacker will set the env var. if we checked if realuid == euid then honoring the variable is maybe ok
[16:13] <zyga> jdstrand: hmm
[16:14] <zyga> jdstrand: we might compile snap-confine-debug and make it not setuid root
[16:14] <zyga> the people that know how to do it could then use it
[16:14] <jdstrand> I just don't want scores of string handling code in the setuid code
[16:14] <jdstrand> (on production)
[16:15] <jdstrand> granted, snap-confine has an apparmor profile, but it is allowing a good bit that would be fun to attack
[16:15] <jdstrand> (it has to)
[16:15] <zyga> jdstrand: I think string handling is unavoidable, must_snprint is not a panacea for everything, I'd rather just bite the bullet and do it corretly
[16:15] <zyga> jdstrand: but I won't object if you feel that's wrong
[16:16] <jdstrand> zyga: I want both :)
[16:16] <zyga> jdstrand: so what's the next step on this: drop the static char[100] buffers, have the callers pass this in (along with size) and code it 100% defensively?
[16:16] <jdstrand> hence, must_strncat() suggestion
[16:16] <jdstrand> zyga: yes
[16:16] <zyga> jdstrand: well, I had grow_string earlier
[16:16] <zyga> jdstrand: that did realloc
[16:17] <rvr> ogra_: http://paste.ubuntu.com/23875465/
[16:17] <zyga> jdstrand: I guess this is the root of the issue, static vs dynamic memory allocation,
[16:17] <jdstrand> zyga: in general, I liked the intent and most of the branch, it was just these couple bits. getting rid of that boilerplate code will help with coding, clarity and reviews, so thanks
[16:17] <ogra_> rvr, great
[16:17] <rvr> ogra_: It does not boot Ubuntu Core
[16:18] <ogra_> well, because you did hit a key
[16:18] <zyga> jdstrand: right, that was my intent, cut the copy-pasted code and ensure the debug logs are accurate and not hand-crafted
[16:18] <jdstrand> zyga: note that I didn't review the dynamic bits. if they were done right, I wouldn't have cared. some projects actually prefer heap vars over stack
[16:18] <zyga> jdstrand: let me show that, it's still in the history:
[16:19] <jdstrand> zyga: well, it won't matter if the other reviewers are going to nak it :)
[16:19] <jdstrand> I was just pointing out that I don't have a fundamental issue with either heap or stack
[16:19] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/2658/commits/e2ab995067ae382372198c264abacc90872ae7d1
[16:19] <mup> PR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
[16:20] <zyga> jdstrand: ah, I see
[16:20] <zyga> jdstrand: (the error message is corrected in the next commit if you spot the error there)
[16:21] <zyga> jdstrand: and this is the use: https://github.com/snapcore/snapd/pull/2658/commits/c007979aaec28469046ecf3f5c54e0a522e31e39
[16:21] <mup> PR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
[16:26] <axino> hi
[16:26] <axino> is it possible to have a daemon started by a snap run under a non-root user ?
[16:26] <ogra_> not yet
[16:27] <axino> ogra_: ok thanks !
[16:27] <ogra_> (but why would you want that anyway given it is fully snadboxed)
[16:27] <axino> ogra_: I don't know, running stuff as root that doesn't need to be makes me incomfortable
[16:27] <rvr> ogra_: It does nothing when pressing Enter :-/
[16:28] <ogra_> rvr, what should it do ?
[16:28] <rvr> ogra_: Boot Ubuntu Core?
[16:28] <ogra_> (aprt from giving you a newline)
[16:28] <rvr> ogra_: I'm stuck in that screen from the paste
[16:28] <ogra_> well, you obviously stopped the autoboot (whihc only happens if you hit a key in the serial console)
[16:29] <rvr> hmm
[16:29] <ogra_> so uboot now gives you a command shell
[16:29] <ogra_> just reset the board
[16:29] <ogra_> (either by typing reset and hitting enter on the shell prompt or my re-plugging power)
[16:29] <rvr> Just replugged
[16:29] <ogra_> good
[16:29] <rvr> ogra_: Does screen flashes you?
[16:30] <ogra_> nope
[16:30] <rvr> Hmm
[16:30] <ogra_> are you on a mac ?
[16:30] <ogra_> there was a bug about screen misbehaving on macs
[16:30] <ogra_> though that was under macos
[16:30] <rvr> I'm in a Mac, but in Linux
[16:30] <ogra_> right, thats what i remembered
[16:31] <rvr> minicom doesn't flash
[16:31] <ogra_> well, screen doesnt flash for me on either my laptop or my desktop PC
[16:31] <rvr> Weird
[16:32] <rvr> ogra_: But I can't see booting either
[16:32] <rvr> ogra_: Do you use a Pi 3 or Pi 2?
[16:32] <ogra_> https://bugs.launchpad.net/bugs/1659523
[16:32] <mup> Bug #1659523: console-conf doesn't work well if using screen on Mac <Snappy:New> <https://launchpad.net/bugs/1659523>
[16:32] <ogra_> i wonder if it is actually some HW thing
[16:33] <ogra_> given he also claims that minicom works just fine
[16:33] <ogra_> rvr, both ... and a BBB and a dragonboard
[16:33] <ogra_> nothing flashes for me
[16:33] <ogra_> and they all boot just fine
[16:34] <rvr> Hmm... it boots fine with HDMI and without the serial console
[16:34] <ogra_> well, seems something send key presses
[16:34] <ogra_> thats the only way to make the boot stop where you showed it
[16:34] <ogra_> *sends
[16:35] <mup> PR snapd#2735 opened: interfaces/builtin: add missing syscalls to core-support needed for systemctl <Created by morphis> <https://github.com/snapcore/snapd/pull/2735>
[16:39] <ogra_> rvr, with minicom you can also see it properly boot ?
[16:39] <ogra_> ... like ... serial output and all
[16:39] <rvr> ogra_: I unplugged the TX wire and boots ok
[16:40] <ogra_> right, but you wont be able to type anthing into it now
[16:40] <rvr> At least it says that it is booting the kernel
[16:41] <rvr> ogra_: Nope, it wasn't booting with either screen or minicom
[16:42] <ogra_> sounds like some HW issue then ... if even minicom sends keystrokes
[16:48] <rvr> ogra_: Booting fine with a reflashed card and without TX :P
[16:49] <ogra_> well, but that doesnt help using your serial console :)
[16:49] <ogra_> are you sure your tx is actually plugged into the right place ?
[16:49] <rvr> I'm happy to see it at least booting :D
[16:49] <ogra_> heh
[16:50] <ogra_> as long as you dont want to interact with it :)
[17:02] <rvr> ogra_: Re-wired carefully, and with screen I can type now
[17:02] <rvr> ogra_: Thanks :)
[17:02] <ogra_> yay
[17:02] <ogra_> enjoy :)
[17:02] <rvr> I can finally use the screen for the desktop!
[17:04] <rvr> Everytime I had to check the images, I couldn't use my screen :(
[17:11] <axino> ogra_: the thing is, it appears that when run as root, my app can't read stuff in $SNAP_USER_COMMON
[17:11] <kyrofa> axino, that's because your "user" is now root
[17:12] <kyrofa> axino, which means $SNAP_USER_COMMON is now in /root/snap/<snapname>/<snapversion>
[17:12] <axino> kyrofa: correct
[17:12] <axino> kyrofa: the snap can't read there
[17:12] <kyrofa> axino, can you duplicate that with `sudo snap run --shell <appname>`?
[17:13] <axino> ($SNAP_USER_COMMON is /root/snap/<snapname>/common, to be precise)
[17:13] <kyrofa> axino, right, sorry, I gave SNAP_DATA
[17:14] <axino> kyrofa: yes
[17:15] <kyrofa> axino, that sounds like a bug
[17:16] <mup> PR snapd#2736 opened: Initial unity8 interface <Created by mikix> <https://github.com/snapcore/snapd/pull/2736>
[17:17] <mup> PR snapd#2737 opened: tests: add more debug if ubuntu-core-upgrade fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/2737>
[17:18] <stokachu> i realize i brought this up the other day but if i have a snap that is already defined as a classic it would be much cleaner to then ahve the user not have to pass --classic during a snap install
[17:19] <stokachu> ive had a couple people ask me why they have to pass that option in
[17:24] <kyrofa> stokachu, that would be akin to a devmode snap being automatically installed as devmode
[17:24] <kyrofa> stokachu, they users need to understand that this is not a snap confined normally
[17:25] <stokachu> kyrofa, yea that makes sense, i guess from my perspective sudo snap install --classic conjure-up is a lot to type
[17:25] <kyrofa> stokachu, I hear you
[17:25] <stokachu> didnt know if it was worth taking to the mailing list for discussion
[17:26] <kyrofa> stokachu, oh please feel free, but I suspect that's the response you'll get
[17:26] <stokachu> i totally understand why we do it
[17:27] <stokachu> i guess cosmetically is it better to pass in --classic or show a prompt that this snap is a classic snap do you want to continue
[17:27] <stokachu> and --classic would just act as a -y in apt world
[17:29] <stokachu> ill just throw it out there and see what comes of it
[17:31] <axino> kyrofa: I got it
[17:31] <kyrofa> stokachu, I actually quite like that idea myself
[17:31] <kyrofa> stokachu, send that email
[17:31] <axino> kyrofa: I rsynced the files from my user to /root/snap/foo, so root wasn't the owner, which apparmor doesn't like
[17:31] <stokachu> ok cool :) ill write it up now
[17:32] <kyrofa> axino, ahh, yep that'll do it
[17:34] <kyrofa> Hey jdstrand, I'm writing a utility in the Nextcloud snap to install one's own key/cert for HTTPS, but I've hit a bit of an issue. The utility itself needs to run as root, since it's doing stuff in SNAP_DATA. My first cut used the home interface, so as long as the certs are in $HOME the utility can pick them up (as command-line args). Of course, though, running as sudo, the utility can't access the user's $HOME
[17:35] <kyrofa> What is the best way to write this utility?
[17:35] <kyrofa> Saying "First put your certs in /root/ somewhere" isn't super friendly
[17:36] <kyrofa> I'm trying to think of some way to pipe them in without having a terrible interface
[17:38] <ogra_> axino, didnt you say you package a daemon ? why would that have any user dirs at all ... just use SNAP_DATA or SNAP_COMMON
[17:39] <mup> PR snapd#2738 opened: spread: remove state tar on project restore <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2738>
[17:39] <ogra_> (i dont think /root/snap/<snap> is a great idea either ... SNAP_DATA will properly put stuff into /var without being bound to any user)
[17:39] <axino> ogra_: I don't know, I considered a config file to be user data, not system data
[17:39] <ogra_> well, that would make /etc obsolete on most linux installs ;)
[17:39] <kyrofa> axino, is it user-specific? Can users have their own?
[17:40] <kyrofa> axino, if not, then it's a system-wide config living in some random user's home dir
[17:40] <axino> kyrofa: yes, you could say that
[17:40] <stokachu> kyrofa, ok sent lets see what happens!
[17:40] <kyrofa> axino, how would a user make a system-wide service use their own config without effecting the service for other users?
[17:41] <axino> kyrofa: well it's a daemon, it's snapd which makes it system-wide automatically !
[17:41] <kyrofa> Haha, fair enough
[17:41] <axino> kyrofa: presumably, several users could run it with different config - even thought that's not how I'm going to use it
[17:42] <ogra_> i'd make it use SNAP_DATA as default and have a wrapper that takes a look if there is a config in SNAP_USER_DATA ... if the latter is true, read it and override it
[17:43] <ogra_> like it would be on a normal system
[17:43] <ogra_> i.e. if you have have a bip (irc proxy) snap that uses a default config but can be run by a user too ...
[17:43] <axino> ha yes
[17:44] <axino> that could work
[17:50] <axino> ogra_: the issue is, if it's configured as a daemon, then there's no binary for users to run
[17:51] <kyrofa> axino, you could declare one, if the binary is happy running multiple times
[17:51] <ogra_> you could define one ... but yeah. if it is a daemon you have a systemd started instance alongside alll the time
[17:51] <axino> indeed I coul
[17:51] <axino> could*
[17:56] <Chipaca> kyrofa, o/
[17:56] <Chipaca> kyrofa, i just saw the integration tests failures :-)
[17:56] <kyrofa> Hey Chipaca! Haha
[17:56] <Chipaca> kyrofa, do those tests need to run with debug?
[17:57] <Chipaca> i mean
[17:57] <kyrofa> Chipaca, some of them do, but not all (and in fact, some don't)
[17:57] <Chipaca> i can fix the tests by expecting (and skipping) the version line, or by debug=False
[17:57] <Chipaca> but i don't know enough to know which is which tbh :-/
[17:57] <kyrofa> Chipaca, I think the biggest reason we use debug=True there is because upon failure, the suite adds the entire dump to the output log so we can see what happened
[17:58] <Chipaca> kyrofa, any guideline?
[17:58] <kyrofa> Chipaca, hold on, let me take a quick look
[17:58] <Chipaca> ah, true
[17:58] <Chipaca> might as well just fix them to expect the version line then
[17:58] <ogra_> just leave them as is and call them alternate facts
[17:59] <Chipaca> kyrofa, also in the integration tests, i saw it uses version 'devel', making the version line mention 'vdevel'. Maybe i should drop the v?
[17:59] <kyrofa> Chipaca, yeah but... a one-line change causing this many failures means our suite is fragile
[17:59] <kyrofa> Chipaca, you'll get devel when running from source
[18:00] <kyrofa> Chipaca, perhaps removing the v would look better, yeah
[18:00] <Chipaca> also it was *two* lines, not one :-p
[18:00] <kyrofa> :P
[18:03] <kyrofa> Chipaca, yeah our tests are just super fragile. I think we need to change the assertEquals to a assertThat([...], Contains())
[18:04] <kyrofa> Chipaca, but that's not a tiny amount of work. We can take it if you like
[18:05] <Chipaca> kyrofa, I can take a stab at it for the ones affected by this change
[18:05] <kyrofa> Chipaca, alright. Note that there are 29 of them, sure appreciate that
[18:06] <kyrofa> Chipaca, but yeah, please do use the testtools matchers where you can
[18:13] <mup> PR snapcraft#1087 opened: Don't wait for lxd networking in cleanbuild test <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/1087>
[18:16] <jdstrand> kyrofa: if the utility needs to run as root, you don't want to have it using non-root certificates. use sudo -H and then HOME is /root
[18:18] <kyrofa> jdstrand, well, I sort of do. Otherwise I require users to place certs in /root first, which seems a hoop to jump through just to say "take my certs"
[18:19] <kyrofa> jdstrand, I might as well not use the home plug at all and say "put them in /root/snap/nextcloud/current/
[18:19] <kyrofa> "
[18:19] <KristijanZic> Hi! Is there some web api for snaps like there is for clicks like https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex  ? I had some free time and have developed some ubuntu webstore in Angular just need to connect it to something if there is an api.
[18:20] <kyrofa> jdstrand, but yeah, that was all I had too. Maybe I'll rewrite it to have them paste cert contents in instead
[18:22] <jdstrand> kyrofa: if the tool needs to run as root, then the certs need to be put in a place owned by root, otherwise root would be trusting certs from unprivileged users. They have to put the certs somewhere anyway, right? can just use 'sudo cp ...' instead of 'cp ...'
[18:23] <kyrofa> jdstrand, the utility I was writing is what put the certs somewhere
[18:23] <kyrofa> (it copies them off to where they need to go)
[18:24] <Chipaca> kyrofa, the tests that use pexpect are going to need to check for the version string explicitly
[18:25] <kyrofa> Chipaca, ah, are there a lot of those? The ones I looked at were just assertEqualing the output. But I guess pexpect is used in the suite setup itself huh
[18:25]  * Chipaca apologises for the context switch
[18:26] <Chipaca> kyrofa, not to worry, i'll sort it
[18:27] <kyrofa> jdstrand, I'm not meaning to argue by the way, I understand the reasoning behind this, I just wanted to make sure I wasn't missing anything
[18:29] <kyrofa> KristijanZic, yes there is. Chipaca where is the snapd REST API documented these days?
[18:29] <kyrofa> Oh wait-- Chipaca nevermind
[18:29] <Chipaca> well, I wouldn't call that a web api
[18:29] <kyrofa> KristijanZic, you don't want that, you want the store-side stuff
[18:29] <Chipaca> KristijanZic, note that wiki page is outdated (it says as much up there)
[18:29] <Chipaca> KristijanZic, in the updated document there's a snaps section
[18:30] <KristijanZic> kyrofa: I just want to list snaps if possible that are in the current Ubuntu snap store.
[18:30] <jdstrand> kyrofa: sure. so, HOME we really have to have 'owner' match (we can't say 'owner or root' in apparmor atm) in order to enforce multiuser
[18:30] <Chipaca> KristijanZic, OTOH maybe you want to talk to snapd, not the store
[18:30] <jdstrand> kyrofa: but, there is this rule: /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix,
[18:31] <jdstrand> kyrofa: that doesn't have owner match. of course, you have to put them there and if you are going to put them there you may as well use sudo cp to the place you want it
[18:31] <KristijanZic> Chipaca, where are the docs for that? Is that the way uappexplorer does it?
[18:31] <ogra_> KristijanZic, https://github.com/bhdouglass/uappexplorer that has options for listing snaps
[18:31] <Chipaca> KristijanZic, sorry, which 'that'?
[18:31] <ogra_> heh
[18:32] <kyrofa> jdstrand, indeed. It just means more documentation, heh
[18:32] <jdstrand> kyrofa: I'm still not sure why 'sudo cp' needs to be wrapped in a tool...
[18:32] <Chipaca> KristijanZic, uappexplorer talks to CPI
[18:32] <kyrofa> jdstrand, because I want where they go to be under my control
[18:32] <KristijanZic> Chipaca, snapd api?
[18:32] <kyrofa> jdstrand, otherwise I need to document it, keep it up to date, and migrate accordingly
[18:32] <Chipaca> KristijanZic, https://github.com/snapcore/snapd/wiki/REST-API
[18:32] <ogra_> but that needs a local snapd instance
[18:33] <ogra_> if you dont want that CPI is the better option i guess
[18:33] <jdstrand> kyrofa: you could say 'sudo cp foo $SNAP_DATA ; sudo yoursnap.register foo'
[18:33] <KristijanZic> ogra, any docs for cpi?
[18:33] <Chipaca> KristijanZic, that wiki page you pasted is the old CPI docs
[18:34] <Chipaca> KristijanZic, it links to the new ones
[18:34] <ogra_> KristijanZic, i'd just use the uappexplorer source as base for your queries ... and the wiki.ubuntu.com pages
[18:34] <Chipaca> ogra_, dude, it's fully documented in its own section in the new docs
[18:35] <ogra_> code talks !
[18:35] <ogra_> :P
[18:35] <KristijanZic> Chipaca, ok, thanks. ogra, sure
[18:37] <Chipaca> KristijanZic, https://search.apps.ubuntu.com/docs/#snap-specific-endpoints-errors
[18:38] <Chipaca> took me a bit because in the middle of fixing the tests before, didn't want to look at the browser :-)
[18:39] <KristijanZic> Oh, great! Thank you :D
[18:44] <Chipaca> kyrofa, I was wrong. Everything went better than expected.
[18:44] <Chipaca> I think it's a sign I should EOF right here.
[18:44] <kyrofa> Chipaca, ah! Excellent, I agree. I'm jealous you're so far ahead of me
[18:45] <Chipaca> kyrofa, no you're not -- not unless you really wanted to start work nine hours ago
[18:45] <kyrofa> Yeah... you got me :P
[18:52] <stokachu> kyleN, bugs.launchpad.net/snappy is the place for bugs these days? i know github issues got moved
[18:52] <stokachu> sorry kyrofa
[18:53] <kyrofa> stokachu, good question, hold on
[18:54] <stokachu> gustavo told me but it was in passing
[18:54] <kyrofa> stokachu, you probably want to log against snapd
[18:54] <kyrofa> stokachu, https://launchpad.net/snapd
[18:54] <stokachu> ok cool thanks ill do that now
[18:58] <mup> Bug #1659924 opened: Snap failures in 16.04 <Snappy:New> <https://launchpad.net/bugs/1659924>
[19:00] <kyrofa> stokachu, guess we're not the only ones, good thread ;)
[19:00] <stokachu> kyrofa, yea it worked out pretty great, thanks for the push
[19:04] <stokachu> though sergio mentioned about snapd 2.22 without the use of sudo, does that mean we aren't requiring people to snap login anymore?
[19:06] <kyrofa> stokachu, honestly I'm not quite sure what he meant by that
[19:42] <Chipaca> kyrofa, i haven't actually gone, and there's a failing test i'm fixing :-/
[19:42] <kyrofa> Chipaca, :(
[19:50] <Chipaca> kyrofa, fixed, pushed, and happy about it
[19:51] <mup> PR snapd#2735 closed: interfaces/builtin: add missing syscalls to core-support needed for systemctl <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2735>
[20:22] <mup> PR snapcraft#1083 closed: project: support for gui in snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1083>
[20:25] <mup> PR snapcraft#1081 closed: local source: preserve symlinks to directories <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1081>
[20:25] <mup> PR snapcraft#1087 closed: Don't wait for lxd networking in cleanbuild test <Created by OddBloke> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1087>
[20:42] <jdstrand> davidcalle: hey. I just noticed that https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ has the old version of the whitepaper. is that the most current link?
[20:43] <mup> PR snapcraft#1088 opened: Release changelog for 2.26 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1088>
[21:07] <mup> PR snapd#2739 opened: tests: remove (some) garbage files found by restore cleanup analysis <Created by zyga> <https://github.com/snapcore/snapd/pull/2739>
[21:09] <kirkland> who approves/denies requests to own reserved package names?
[21:09] <kirkland> (I submitted a couple)
[21:28] <sergiusens> marcoceppi_, hey, sorry for asking again, bt I lost your quick instructions, mind sending them my way again?
[21:30] <marcoceppi_> sergiusens: hey, no problem https://github.com/juju-solutions/charm-pkg
[21:30] <kyrofa> kirkland, talk to nessita and/or noise][
[21:31]  * kirkland waves at nessita and noise][
[21:32] <noise][> kirkland: hey, what's up?
[21:32] <noise][> name regs...
[21:32] <kirkland> noise][: howdy, I have a few snap package name registrations I'm pushing through
[21:32] <noise][> just got the notif, 1m
[21:32] <kirkland> noise][: yeah, i have a few more coming
[21:33] <kirkland> noise][: actually just do those two, and we're good for today ;-)
[21:33] <sergiusens> marcoceppi_, then charm <what>; charm <what-now> ? :-)
[21:33] <noise][> ok
[21:33] <marcoceppi_> sergiusens: oh, `charm version; charm create foo; cd foo; charm build`
[21:33] <noise][> kirkland: done
[21:34] <DedSec> hey, iam running into this strange issue on ubuntu server 16.04 when i try to run snap install of any app, snap tries to download the ubuntu core file and then gives the following error once the core file has finished downloading. error: cannot perform the following tasks:
[21:34] <DedSec> - Mount snap "core" (888) ([start snap-core-888.mount] failed with exit status 1: Job for snap-core-888.mount failed. See "systemctl status snap-core-888.mount" and "journalctl -xe" for details.
[21:34] <DedSec> )
[22:16] <mup> PR snapd#2685 closed: interfaces/builtin: add account-control interface <Created by teknoraver> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2685>
[22:17] <mup> PR snapd#2703 closed: many: make ubuntu-core-launcher mostly go away <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2703>
[22:22] <kirkland> noise][: thanks, uploaded;  who does the review?
[22:55] <mup> PR snapd#2740 opened: releasing snapd version 2.22 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2740>
[23:00] <noise][> kirkland: reviews of the uploads are security team