[01:35] 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] quit [03:05] exit [03:05] help [03:05] ? [03:06] shit [03:09] Bug #1659719 opened: ssh can't call a binary from a snap without the full path [03:51] Bug #1659724 opened: Feature request: give applications unrestricted access to d-bus services provided by the same snap [06:45] how to convert nodejs app to snap app [07:01] PR snapd#2729 closed: tests: use test snap [07:03] PR snapd#2731 opened: store: always log retry summary when SNAPPY_TESTING is set [07:07] PR snapd#2722 closed: tests: set SNAPPY_USE_STAGING_STORE in su call [07:19] Bug #1659744 opened: Classic snaps 'not found' if --classic argument is missing [08:05] PR snapd#2732 opened: snapenv: do not append ":" to the SNAP_LIBRARY_PATH [08:47] PR snapd#2733 opened: tests: make the debugging of c-unit-tests more useful [08:51] PR snapcraft#1082 closed: project: new plugin directory location [10:18] PR snapd#2730 closed: snap: be more helpful in the `snap install ` error message [10:45] PR snapcraft#1083 opened: project: support for gui in snap [10:45] PR snapd#2734 opened: debian/tests: drop stale autopkgtest dependencies [11:03] Bug #1637299 changed: sudo snap login "Password:" prompt unclear what password to type [11:27] Bug #1633230 opened: snap ack doesn't indicate which assertions are good or bad [11:27] Bug #1633261 opened: snap ack should provide a summary of the assertions status [11:39] PR snapcraft#1084 opened: make: add support for cwd path to make() function [12:00] PR snapcraft#1085 opened: snapcraft: fix or ignore PEP8 static errors === hikiko is now known as hikiko|ln [12:09] PR snapcraft#1086 opened: print snapcraft's version on startup when running with --debug [12:21] PR snapd#2721 closed: tests: integration test for system reload [12:23] 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] one for cjwatson perhaps ^ ? [12:24] package context: unrecognized import path "context" (import path does not begin with hostname) [12:24] that's the actual failure [12:24] the rest is just consequential errors [12:24] popey: ^- [12:25] and that's something in your snap [12:27] hm [12:27] thanks for looking. [12:43] Bug #1658909 changed: lsb_release fails in classic (arm64)

=== hikiko|ln is now known as hikiko [13:35] 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] (it works fine when in devmode) [14:15] PR snapd#2482 closed: store: retry auth-related requests [14:26] ogra_: there? [14:43] Elleo: do you get any apparmor denials [14:43] Elleo: apparmor controls all dbus traffic [14:43] Elleo: and notification is a distinct signal from read/write calls [14:43] Elleo: dmesg | grep DENIED [14:43] Elleo: and report that as a bug please [14:43] I think it is something else [14:44] jdstrand: hey :) [14:44] jdstrand: what do you think? [14:44] 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] PR snapd#2733 closed: tests: make the debugging of c-unit-tests more useful [14:45] 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] zyga: nad hi :) [14:53] zyga: no denials, monitoring the gsetting it seems it does get written to, but then immediately gets changed back for some reason :/ [14:54] zyga: unless I change it manually via gsettings, in which case it stays fine but doesn't get notified [14:56] popey: /32 [14:57] popey: that bucklespring is a bit worrying :P [14:57] popey: isn't it basically exploiting the fact that x11 has zero security and acting like a keylogger? [14:57] 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] morphis, i'm back now [14:58] 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] 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] ogra_: ^ [15:01] * ogra_ doesnt know ... [15:01] ogra_: great :-) [15:01] seb__, where do you put that usually ? config.txt ? cmdline.txt ? [15:02] seb__: let me grep one thing [15:02] config.txt usually. New to snappy core [15:03] well, confi.txt is there, you can just edit it as needed ... it is mounted under /boot/uboot/ [15:03] really?!, ohh damn. Gotte go check that [15:03] (or directly if you plug the SD into your PC ... in the system-boot partition) [15:04] just make sure you dont drop anything of the existing options that are set there [15:04] else something might break [15:04] Understood [15:09] Elleo: pfffft, you worry too much :S [15:10] Elleo: it uses X11 and pulse, no network... [15:12] It worked! Thank you for your help :D === JanC_ is now known as JanC [15:24] 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] you'd probably have noticed the actual error if it hadn't been followed by a pile of barf [15:39] 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] cjwatson: good point [15:50] PR snapd#2734 closed: debian/tests: drop stale autopkgtest dependencies [15:54] ogra_: Do you do anything special to enable the serial console on the Pi? [15:55] rvr, whats missing ? [15:55] rvr, we set enable_uart in config.txt and we have a console= arg in cmdline.txt for serial [15:56] ogra_: I got a USB TTL serial adapter and I don't get anything in the console [15:56] jdstrand: I have a question about the mount/unmount helpers [15:56] jdstrand: about conditionality of logging [15:56] did you wire it up correctly ? [15:56] ogra_: What's the speed? 115200 [15:56] jdstrand: qemu:ubuntu-16.04-64:tests/main/op-remove [15:56] yeah [15:56] ogra_: I think so, RX->TX, TX->RX [15:56] jdstrand: if you can answer that one quickly I will do the rest of the changes [15:57] i usually use: screen /dev/ttyUSB0 115200 [15:58] rvr, and only gnd/rx/tx ... not 5V connected, right ? [15:58] ogra_: 5V connected [15:58] ogra_: And HDMI [15:58] (connecting the red 5V cable can damage the board) [15:58] ogra_: Oh, I see [15:59] hdmi shouldnt matter ... the two consoles are separate ... you get consoles on both tty's usually [16:01] zyga: I'm not sure what you are linking to. can you give a full url? [16:02] jdstrand: sorry, sure [16:03] https://github.com/snapcore/snapd/pull/2658 [16:03] PR snapd#2658: cmd: add mount / unmount helpers [16:03] jdstrand: let's just discuss it here [16:03] jdstrand: do you want me to make a debug version of snap-confine [16:03] jdstrand: that can do logging [16:03] jdstrand: and have all the log (and support code) compile to nothing in the regular build? [16:04] jdstrand: and (since we're talking), about the static vs dynamic buffer; originally I implemented this to use a dynamically allocated buffer [16:04] jdstrand: but the snappy team -1 the change as too complex [16:04] jdstrand: so I changed that to a "good enough" static buffer [16:05] zyga: I'd prefer that debug* is compiled out on production builds, yes [16:05] zyga: I gave another option to the static buffer that would not be complex [16:05] jdstrand: do you have a plan on how we'd be assisting people in debugging issues? [16:05] jdstrand: the N-variant of scpcpy? [16:06] 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] zyga: re variant> you call debug_mount_cmd(), it does 'char cmd[BUF_SIZE]' then pass that into your function [16:07] so with latest snapcraft i saw a commit about merging snap and snapcraft directory [16:07] can i put everything under /snap directory and all is well? [16:07] zyga: it isn't the on the stack bit I cared about, it was 'static' [16:08] sergiusens, ^ [16:08] jdstrand: ah, I see [16:08] jdstrand: that's easy enough [16:08] also does the store support reading the /snap/setup/gui directory? [16:09] jdstrand: (I still prefer dynamic but I don't think this is an issue) [16:09] jdstrand: though in practice this function will move that buffer from one place to another [16:09] jdstrand: and with the _must approach it won't be any more reusable [16:09] (you either get the buffer size right or you don't) [16:09] PR snapd#2726 closed: interfaces/builtin: rework core-support to only allow full access to systemctl [16:10] zyga: for what it worth, when I said static I meant static sized, so what jdstrand is suggesting [16:10] I don't know what the other meant [16:10] pedronis: static char[100]; vs char[100] vs char * (and malloc) [16:11] the 2nd [16:11] pedronis: thanks for clarifying that [16:12] 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] static has many meanings, unfortunately [16:12] yea [16:12] C++ adds a couple more [16:13] indeed [16:13] keywords are hard to add to a language [16:13] anyway [16:13] 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] jdstrand: hmm [16:14] jdstrand: we might compile snap-confine-debug and make it not setuid root [16:14] the people that know how to do it could then use it [16:14] I just don't want scores of string handling code in the setuid code [16:14] (on production) [16:15] granted, snap-confine has an apparmor profile, but it is allowing a good bit that would be fun to attack [16:15] (it has to) [16:15] 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] jdstrand: but I won't object if you feel that's wrong [16:16] zyga: I want both :) [16:16] 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] hence, must_strncat() suggestion [16:16] zyga: yes [16:16] jdstrand: well, I had grow_string earlier [16:16] jdstrand: that did realloc [16:17] ogra_: http://paste.ubuntu.com/23875465/ [16:17] jdstrand: I guess this is the root of the issue, static vs dynamic memory allocation, [16:17] 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] rvr, great [16:17] ogra_: It does not boot Ubuntu Core [16:18] well, because you did hit a key [16:18] jdstrand: right, that was my intent, cut the copy-pasted code and ensure the debug logs are accurate and not hand-crafted [16:18] 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] jdstrand: let me show that, it's still in the history: [16:19] zyga: well, it won't matter if the other reviewers are going to nak it :) [16:19] I was just pointing out that I don't have a fundamental issue with either heap or stack [16:19] jdstrand: https://github.com/snapcore/snapd/pull/2658/commits/e2ab995067ae382372198c264abacc90872ae7d1 [16:19] PR snapd#2658: cmd: add mount / unmount helpers [16:20] jdstrand: ah, I see [16:20] jdstrand: (the error message is corrected in the next commit if you spot the error there) [16:21] jdstrand: and this is the use: https://github.com/snapcore/snapd/pull/2658/commits/c007979aaec28469046ecf3f5c54e0a522e31e39 [16:21] PR snapd#2658: cmd: add mount / unmount helpers [16:26] hi [16:26] is it possible to have a daemon started by a snap run under a non-root user ? [16:26] not yet [16:27] ogra_: ok thanks ! [16:27] (but why would you want that anyway given it is fully snadboxed) [16:27] ogra_: I don't know, running stuff as root that doesn't need to be makes me incomfortable [16:27] ogra_: It does nothing when pressing Enter :-/ [16:28] rvr, what should it do ? [16:28] ogra_: Boot Ubuntu Core? [16:28] (aprt from giving you a newline) [16:28] ogra_: I'm stuck in that screen from the paste [16:28] well, you obviously stopped the autoboot (whihc only happens if you hit a key in the serial console) [16:29] hmm [16:29] so uboot now gives you a command shell [16:29] just reset the board [16:29] (either by typing reset and hitting enter on the shell prompt or my re-plugging power) [16:29] Just replugged [16:29] good [16:29] ogra_: Does screen flashes you? [16:30] nope [16:30] Hmm [16:30] are you on a mac ? [16:30] there was a bug about screen misbehaving on macs [16:30] though that was under macos [16:30] I'm in a Mac, but in Linux [16:30] right, thats what i remembered [16:31] minicom doesn't flash [16:31] well, screen doesnt flash for me on either my laptop or my desktop PC [16:31] Weird [16:32] ogra_: But I can't see booting either [16:32] ogra_: Do you use a Pi 3 or Pi 2? [16:32] https://bugs.launchpad.net/bugs/1659523 [16:32] Bug #1659523: console-conf doesn't work well if using screen on Mac [16:32] i wonder if it is actually some HW thing [16:33] given he also claims that minicom works just fine [16:33] rvr, both ... and a BBB and a dragonboard [16:33] nothing flashes for me [16:33] and they all boot just fine [16:34] Hmm... it boots fine with HDMI and without the serial console [16:34] well, seems something send key presses [16:34] thats the only way to make the boot stop where you showed it [16:34] *sends [16:35] PR snapd#2735 opened: interfaces/builtin: add missing syscalls to core-support needed for systemctl [16:39] rvr, with minicom you can also see it properly boot ? [16:39] ... like ... serial output and all [16:39] ogra_: I unplugged the TX wire and boots ok [16:40] right, but you wont be able to type anthing into it now [16:40] At least it says that it is booting the kernel [16:41] ogra_: Nope, it wasn't booting with either screen or minicom [16:42] sounds like some HW issue then ... if even minicom sends keystrokes [16:48] ogra_: Booting fine with a reflashed card and without TX :P [16:49] well, but that doesnt help using your serial console :) [16:49] are you sure your tx is actually plugged into the right place ? [16:49] I'm happy to see it at least booting :D [16:49] heh [16:50] as long as you dont want to interact with it :) [17:02] ogra_: Re-wired carefully, and with screen I can type now [17:02] ogra_: Thanks :) [17:02] yay [17:02] enjoy :) [17:02] I can finally use the screen for the desktop! [17:04] Everytime I had to check the images, I couldn't use my screen :( [17:11] ogra_: the thing is, it appears that when run as root, my app can't read stuff in $SNAP_USER_COMMON [17:11] axino, that's because your "user" is now root [17:12] axino, which means $SNAP_USER_COMMON is now in /root/snap// [17:12] kyrofa: correct [17:12] kyrofa: the snap can't read there [17:12] axino, can you duplicate that with `sudo snap run --shell `? [17:13] ($SNAP_USER_COMMON is /root/snap//common, to be precise) [17:13] axino, right, sorry, I gave SNAP_DATA [17:14] kyrofa: yes [17:15] axino, that sounds like a bug [17:16] PR snapd#2736 opened: Initial unity8 interface [17:17] PR snapd#2737 opened: tests: add more debug if ubuntu-core-upgrade fails [17:18] 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] ive had a couple people ask me why they have to pass that option in [17:24] stokachu, that would be akin to a devmode snap being automatically installed as devmode [17:24] stokachu, they users need to understand that this is not a snap confined normally [17:25] kyrofa, yea that makes sense, i guess from my perspective sudo snap install --classic conjure-up is a lot to type [17:25] stokachu, I hear you [17:25] didnt know if it was worth taking to the mailing list for discussion [17:26] stokachu, oh please feel free, but I suspect that's the response you'll get [17:26] i totally understand why we do it [17:27] 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] and --classic would just act as a -y in apt world [17:29] ill just throw it out there and see what comes of it [17:31] kyrofa: I got it [17:31] stokachu, I actually quite like that idea myself [17:31] stokachu, send that email [17:31] 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] ok cool :) ill write it up now [17:32] axino, ahh, yep that'll do it [17:34] 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] What is the best way to write this utility? [17:35] Saying "First put your certs in /root/ somewhere" isn't super friendly [17:36] I'm trying to think of some way to pipe them in without having a terrible interface [17:38] 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] PR snapd#2738 opened: spread: remove state tar on project restore [17:39] (i dont think /root/snap/ is a great idea either ... SNAP_DATA will properly put stuff into /var without being bound to any user) [17:39] ogra_: I don't know, I considered a config file to be user data, not system data [17:39] well, that would make /etc obsolete on most linux installs ;) [17:39] axino, is it user-specific? Can users have their own? [17:40] axino, if not, then it's a system-wide config living in some random user's home dir [17:40] kyrofa: yes, you could say that [17:40] kyrofa, ok sent lets see what happens! [17:40] axino, how would a user make a system-wide service use their own config without effecting the service for other users? [17:41] kyrofa: well it's a daemon, it's snapd which makes it system-wide automatically ! [17:41] Haha, fair enough [17:41] kyrofa: presumably, several users could run it with different config - even thought that's not how I'm going to use it [17:42] 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] like it would be on a normal system [17:43] 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] ha yes [17:44] that could work [17:50] ogra_: the issue is, if it's configured as a daemon, then there's no binary for users to run [17:51] axino, you could declare one, if the binary is happy running multiple times [17:51] you could define one ... but yeah. if it is a daemon you have a systemd started instance alongside alll the time [17:51] indeed I coul [17:51] could* [17:56] kyrofa, o/ [17:56] kyrofa, i just saw the integration tests failures :-) [17:56] Hey Chipaca! Haha [17:56] kyrofa, do those tests need to run with debug? [17:57] i mean [17:57] Chipaca, some of them do, but not all (and in fact, some don't) [17:57] i can fix the tests by expecting (and skipping) the version line, or by debug=False [17:57] but i don't know enough to know which is which tbh :-/ [17:57] 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] kyrofa, any guideline? [17:58] Chipaca, hold on, let me take a quick look [17:58] ah, true [17:58] might as well just fix them to expect the version line then [17:58] just leave them as is and call them alternate facts [17:59] 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] Chipaca, yeah but... a one-line change causing this many failures means our suite is fragile [17:59] Chipaca, you'll get devel when running from source [18:00] Chipaca, perhaps removing the v would look better, yeah [18:00] also it was *two* lines, not one :-p [18:00] :P [18:03] Chipaca, yeah our tests are just super fragile. I think we need to change the assertEquals to a assertThat([...], Contains()) [18:04] Chipaca, but that's not a tiny amount of work. We can take it if you like [18:05] kyrofa, I can take a stab at it for the ones affected by this change [18:05] Chipaca, alright. Note that there are 29 of them, sure appreciate that [18:06]