/srv/irclogs.ubuntu.com/2017/01/27/#snappy.txt

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 confinement01:35
telelaciquit03:05
telelaciexit03:05
telelacihelp03:05
telelaci?03:05
telelacishit03:06
mupBug #1659719 opened: ssh can't call a binary from a snap without the full path <Snappy:New> <https://launchpad.net/bugs/1659719>03:09
mupBug #1659724 opened: Feature request: give applications unrestricted access to d-bus services provided by the same snap <Snappy:New> <https://launchpad.net/bugs/1659724>03:51
ubuntunoddyhow to convert nodejs app to snap app06:45
mupPR snapd#2729 closed: tests: use test snap <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2729>07:01
mupPR snapd#2731 opened: store: always log retry summary when SNAPPY_TESTING is set <Created by mvo5> <https://github.com/snapcore/snapd/pull/2731>07:03
mupPR 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:07
mupBug #1659744 opened: Classic snaps 'not found' if --classic argument is missing <Snappy:New> <https://launchpad.net/bugs/1659744>07:19
mupPR snapd#2732 opened: snapenv: do not append ":" to the SNAP_LIBRARY_PATH <Created by mvo5> <https://github.com/snapcore/snapd/pull/2732>08:05
mupPR snapd#2733 opened: tests: make the debugging of c-unit-tests more useful <Created by zyga> <https://github.com/snapcore/snapd/pull/2733>08:47
mupPR snapcraft#1082 closed: project: new plugin directory location <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1082>08:51
mupPR 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:18
mupPR snapcraft#1083 opened: project: support for gui in snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1083>10:45
mupPR snapd#2734 opened: debian/tests: drop stale autopkgtest dependencies <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2734>10:45
mupBug #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:03
mupBug #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
mupBug #1633261 opened: snap ack should provide a summary of the assertions status <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1633261>11:27
mupPR snapcraft#1084 opened: make: add support for cwd path to make() function <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1084>11:39
mupPR snapcraft#1085 opened: snapcraft: fix or ignore PEP8 static errors <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1085>12:00
=== hikiko is now known as hikiko|ln
mupPR snapcraft#1086 opened: print snapcraft's version on startup when running with --debug <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1086>12:09
mupPR snapd#2721 closed: tests: integration test  for system reload <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2721>12:21
popeyI 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.gz12:23
popeyone for cjwatson perhaps ^ ?12:23
cjwatsonpackage context: unrecognized import path "context" (import path does not begin with hostname)12:24
cjwatsonthat's the actual failure12:24
cjwatsonthe rest is just consequential errors12:24
cjwatsonpopey: ^-12:24
cjwatsonand that's something in your snap12:25
popeyhm12:27
popeythanks for looking.12:27
mupBug #1658909 changed: lsb_release fails in classic (arm64) <Snappy:Confirmed for ogra> <lsb (Ubuntu):Invalid> <lsb-release (Ubuntu):Invalid> <https://launchpad.net/bugs/1658909>12:43
=== hikiko|ln is now known as hikiko
ElleoI'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)13:35
mupPR snapd#2482 closed: store: retry auth-related requests <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2482>14:15
morphisogra_: there?14:26
zygaElleo: do you get any apparmor denials14:43
zygaElleo: apparmor controls all dbus traffic14:43
zygaElleo: and notification is a distinct signal from read/write calls14:43
zygaElleo: dmesg | grep DENIED14:43
zygaElleo: and report that as a bug please14:43
jdstrandI think it is something else14:43
zygajdstrand: hey :)14:44
zygajdstrand: what do you think?14:44
jdstrandI 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 it14:44
mupPR 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
jdstrandI 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 details14:45
jdstrandzyga: nad hi :)14:46
Elleozyga: no denials, monitoring the gsetting it seems it does get written to, but then immediately gets changed back for some reason :/14:53
Elleozyga: unless I change it manually via gsettings, in which case it stays fine but doesn't get notified14:54
Elleopopey: /3214:56
Elleopopey: that bucklespring is a bit worrying :P14:57
Elleopopey: isn't it basically exploiting the fact that x11 has zero security and acting like a keylogger?14:57
zygajdstrand: 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 kernel14:57
ogra_morphis, i'm back now14:58
zygajdstrand: 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 play14:58
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"14:59
zygaogra_: ^15:00
* ogra_ doesnt know ... 15:01
morphisogra_: great :-)15:01
ogra_seb__, where do you put that usually ? config.txt ? cmdline.txt ?15:01
zygaseb__: let me grep one thing15:02
seb__config.txt usually. New to snappy core15:02
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 that15:03
ogra_(or directly if you plug the SD into your PC ... in the system-boot partition)15:03
ogra_just make sure you dont drop anything of the existing options that are set there15:04
ogra_else something might break15:04
seb__Understood15:04
popeyElleo: pfffft, you worry too much :S15:09
popeyElleo: it uses X11 and pulse, no network...15:10
seb__It worked! Thank you for your help :D15:12
=== JanC_ is now known as JanC
cjwatsonpopey: 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 good15:24
cjwatsonyou'd probably have noticed the actual error if it hadn't been followed by a pile of barf15:24
roadmrjdstrand: 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
popeycjwatson: good point15:39
mupPR snapd#2734 closed: debian/tests: drop stale autopkgtest dependencies <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2734>15:50
rvrogra_: Do you do anything special to enable the serial console on the Pi?15:54
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 serial15:55
rvrogra_: I got a USB TTL serial adapter and I don't get anything in the console15:56
zygajdstrand: I have a question about the mount/unmount helpers15:56
zygajdstrand: about conditionality of logging15:56
ogra_did you wire it up correctly ?15:56
rvrogra_: What's the speed? 11520015:56
zygajdstrand: qemu:ubuntu-16.04-64:tests/main/op-remove15:56
ogra_yeah15:56
rvrogra_: I think so, RX->TX, TX->RX15:56
zygajdstrand: if you can answer that one quickly I will do the rest of the changes15:56
ogra_i usually use: screen /dev/ttyUSB0 11520015:57
ogra_rvr, and only gnd/rx/tx ... not 5V connected, right ?15:58
rvrogra_: 5V connected15:58
rvrogra_: And HDMI15:58
ogra_(connecting the red 5V cable can damage the board)15:58
rvrogra_: Oh, I see15:58
ogra_hdmi shouldnt matter ... the two consoles are separate ... you get consoles on both tty's usually15:59
jdstrandzyga: I'm not sure what you are linking to. can you give a full url?16:01
zygajdstrand: sorry, sure16:02
zygahttps://github.com/snapcore/snapd/pull/265816:03
mupPR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>16:03
zygajdstrand: let's just discuss it here16:03
zygajdstrand: do you want me to make a debug version of snap-confine16:03
zygajdstrand: that can do logging16:03
zygajdstrand: and have all the log (and support code) compile to nothing in the regular build?16:03
zygajdstrand: and (since we're talking), about the static vs dynamic buffer; originally I implemented this to use a dynamically allocated buffer16:04
zygajdstrand: but the snappy team -1 the change as too complex16:04
zygajdstrand: so I changed that to a "good enough" static buffer16:04
jdstrandzyga: I'd prefer that debug* is compiled out on production builds, yes16:05
jdstrandzyga: I gave another option to the static buffer that would not be complex16:05
zygajdstrand: do you have a plan on how we'd be assisting people in debugging issues?16:05
zygajdstrand: the N-variant of scpcpy?16:05
zygajdstrand: 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:06
jdstrandzyga: re variant> you call debug_mount_cmd(), it does 'char cmd[BUF_SIZE]' then pass that into your function16:07
stokachuso with latest snapcraft i saw a commit about merging snap and snapcraft directory16:07
stokachucan i put everything under /snap directory and all is well?16:07
jdstrandzyga: it isn't the on the stack bit I cared about, it was 'static'16:07
stokachusergiusens, ^16:08
zygajdstrand: ah, I see16:08
zygajdstrand: that's easy enough16:08
stokachualso does the store support reading the /snap/setup/gui directory?16:08
zygajdstrand: (I still prefer dynamic but I don't think this is an issue)16:09
zygajdstrand: though in practice this function will move that buffer from one place to another16:09
zygajdstrand: and with the _must approach it won't be any more reusable16:09
zyga(you either get the buffer size right or you don't)16:09
mupPR 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:09
pedroniszyga: for what it worth, when I said static I meant static sized,  so what jdstrand is suggesting16:10
pedronisI don't know what the other meant16:10
zygapedronis: static char[100]; vs char[100] vs char * (and malloc)16:10
pedronisthe 2nd16:11
zygapedronis: thanks for clarifying that16:11
pedronissorry, C has that kind of static, I know, but might brain almost never think of it, it's rarely a good idea16:12
zygastatic has many meanings, unfortunately16:12
pedronisyea16:12
pedronisC++ adds a couple more16:12
zygaindeed16:13
zygakeywords are hard to add to a language16:13
zygaanyway16:13
jdstrandzyga: 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 ok16:13
zygajdstrand: hmm16:13
zygajdstrand: we might compile snap-confine-debug and make it not setuid root16:14
zygathe people that know how to do it could then use it16:14
jdstrandI just don't want scores of string handling code in the setuid code16:14
jdstrand(on production)16:14
jdstrandgranted, snap-confine has an apparmor profile, but it is allowing a good bit that would be fun to attack16:15
jdstrand(it has to)16:15
zygajdstrand: I think string handling is unavoidable, must_snprint is not a panacea for everything, I'd rather just bite the bullet and do it corretly16:15
zygajdstrand: but I won't object if you feel that's wrong16:15
jdstrandzyga: I want both :)16:16
zygajdstrand: 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
jdstrandhence, must_strncat() suggestion16:16
jdstrandzyga: yes16:16
zygajdstrand: well, I had grow_string earlier16:16
zygajdstrand: that did realloc16:16
rvrogra_: http://paste.ubuntu.com/23875465/16:17
zygajdstrand: I guess this is the root of the issue, static vs dynamic memory allocation,16:17
jdstrandzyga: 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 thanks16:17
ogra_rvr, great16:17
rvrogra_: It does not boot Ubuntu Core16:17
ogra_well, because you did hit a key16:18
zygajdstrand: right, that was my intent, cut the copy-pasted code and ensure the debug logs are accurate and not hand-crafted16:18
jdstrandzyga: 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 stack16:18
zygajdstrand: let me show that, it's still in the history:16:18
jdstrandzyga: well, it won't matter if the other reviewers are going to nak it :)16:19
jdstrandI was just pointing out that I don't have a fundamental issue with either heap or stack16:19
zygajdstrand: https://github.com/snapcore/snapd/pull/2658/commits/e2ab995067ae382372198c264abacc90872ae7d116:19
mupPR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>16:19
zygajdstrand: ah, I see16:20
zygajdstrand: (the error message is corrected in the next commit if you spot the error there)16:20
zygajdstrand: and this is the use: https://github.com/snapcore/snapd/pull/2658/commits/c007979aaec28469046ecf3f5c54e0a522e31e3916:21
mupPR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>16:21
axinohi16:26
axinois it possible to have a daemon started by a snap run under a non-root user ?16:26
ogra_not yet16:26
axinoogra_: ok thanks !16:27
ogra_(but why would you want that anyway given it is fully snadboxed)16:27
axinoogra_: I don't know, running stuff as root that doesn't need to be makes me incomfortable16:27
rvrogra_: It does nothing when pressing Enter :-/16:27
ogra_rvr, what should it do ?16:28
rvrogra_: Boot Ubuntu Core?16:28
ogra_(aprt from giving you a newline)16:28
rvrogra_: I'm stuck in that screen from the paste16:28
ogra_well, you obviously stopped the autoboot (whihc only happens if you hit a key in the serial console)16:28
rvrhmm16:29
ogra_so uboot now gives you a command shell16:29
ogra_just reset the board16:29
ogra_(either by typing reset and hitting enter on the shell prompt or my re-plugging power)16:29
rvrJust replugged16:29
ogra_good16:29
rvrogra_: Does screen flashes you?16:29
ogra_nope16:30
rvrHmm16:30
ogra_are you on a mac ?16:30
ogra_there was a bug about screen misbehaving on macs16:30
ogra_though that was under macos16:30
rvrI'm in a Mac, but in Linux16:30
ogra_right, thats what i remembered16:30
rvrminicom doesn't flash16:31
ogra_well, screen doesnt flash for me on either my laptop or my desktop PC16:31
rvrWeird16:31
rvrogra_: But I can't see booting either16:32
rvrogra_: Do you use a Pi 3 or Pi 2?16:32
ogra_https://bugs.launchpad.net/bugs/165952316:32
mupBug #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 thing16:32
ogra_given he also claims that minicom works just fine16:33
ogra_rvr, both ... and a BBB and a dragonboard16:33
ogra_nothing flashes for me16:33
ogra_and they all boot just fine16:33
rvrHmm... it boots fine with HDMI and without the serial console16:34
ogra_well, seems something send key presses16:34
ogra_thats the only way to make the boot stop where you showed it16:34
ogra_*sends16:34
mupPR 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:35
ogra_rvr, with minicom you can also see it properly boot ?16:39
ogra_... like ... serial output and all16:39
rvrogra_: I unplugged the TX wire and boots ok16:39
ogra_right, but you wont be able to type anthing into it now16:40
rvrAt least it says that it is booting the kernel16:40
rvrogra_: Nope, it wasn't booting with either screen or minicom16:41
ogra_sounds like some HW issue then ... if even minicom sends keystrokes16:42
rvrogra_: Booting fine with a reflashed card and without TX :P16:48
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
rvrI'm happy to see it at least booting :D16:49
ogra_heh16:49
ogra_as long as you dont want to interact with it :)16:50
rvrogra_: Re-wired carefully, and with screen I can type now17:02
rvrogra_: Thanks :)17:02
ogra_yay17:02
ogra_enjoy :)17:02
rvrI can finally use the screen for the desktop!17:02
rvrEverytime I had to check the images, I couldn't use my screen :(17:04
axinoogra_: the thing is, it appears that when run as root, my app can't read stuff in $SNAP_USER_COMMON17:11
kyrofaaxino, that's because your "user" is now root17:11
kyrofaaxino, which means $SNAP_USER_COMMON is now in /root/snap/<snapname>/<snapversion>17:12
axinokyrofa: correct17:12
axinokyrofa: the snap can't read there17:12
kyrofaaxino, can you duplicate that with `sudo snap run --shell <appname>`?17:12
axino($SNAP_USER_COMMON is /root/snap/<snapname>/common, to be precise)17:13
kyrofaaxino, right, sorry, I gave SNAP_DATA17:13
axinokyrofa: yes17:14
kyrofaaxino, that sounds like a bug17:15
mupPR snapd#2736 opened: Initial unity8 interface <Created by mikix> <https://github.com/snapcore/snapd/pull/2736>17:16
mupPR snapd#2737 opened: tests: add more debug if ubuntu-core-upgrade fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/2737>17:17
stokachui 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 install17:18
stokachuive had a couple people ask me why they have to pass that option in17:19
kyrofastokachu, that would be akin to a devmode snap being automatically installed as devmode17:24
kyrofastokachu, they users need to understand that this is not a snap confined normally17:24
stokachukyrofa, yea that makes sense, i guess from my perspective sudo snap install --classic conjure-up is a lot to type17:25
kyrofastokachu, I hear you17:25
stokachudidnt know if it was worth taking to the mailing list for discussion17:25
kyrofastokachu, oh please feel free, but I suspect that's the response you'll get17:26
stokachui totally understand why we do it17:26
stokachui guess cosmetically is it better to pass in --classic or show a prompt that this snap is a classic snap do you want to continue17:27
stokachuand --classic would just act as a -y in apt world17:27
stokachuill just throw it out there and see what comes of it17:29
axinokyrofa: I got it17:31
kyrofastokachu, I actually quite like that idea myself17:31
kyrofastokachu, send that email17:31
axinokyrofa: I rsynced the files from my user to /root/snap/foo, so root wasn't the owner, which apparmor doesn't like17:31
stokachuok cool :) ill write it up now17:31
kyrofaaxino, ahh, yep that'll do it17:32
kyrofaHey 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 $HOME17:34
kyrofaWhat is the best way to write this utility?17:35
kyrofaSaying "First put your certs in /root/ somewhere" isn't super friendly17:35
kyrofaI'm trying to think of some way to pipe them in without having a terrible interface17:36
ogra_axino, didnt you say you package a daemon ? why would that have any user dirs at all ... just use SNAP_DATA or SNAP_COMMON17:38
mupPR 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
axinoogra_: I don't know, I considered a config file to be user data, not system data17:39
ogra_well, that would make /etc obsolete on most linux installs ;)17:39
kyrofaaxino, is it user-specific? Can users have their own?17:39
kyrofaaxino, if not, then it's a system-wide config living in some random user's home dir17:40
axinokyrofa: yes, you could say that17:40
stokachukyrofa, ok sent lets see what happens!17:40
kyrofaaxino, how would a user make a system-wide service use their own config without effecting the service for other users?17:40
axinokyrofa: well it's a daemon, it's snapd which makes it system-wide automatically !17:41
kyrofaHaha, fair enough17:41
axinokyrofa: presumably, several users could run it with different config - even thought that's not how I'm going to use it17:41
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 it17:42
ogra_like it would be on a normal system17: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
axinoha yes17:43
axinothat could work17:44
axinoogra_: the issue is, if it's configured as a daemon, then there's no binary for users to run17:50
kyrofaaxino, you could declare one, if the binary is happy running multiple times17:51
ogra_you could define one ... but yeah. if it is a daemon you have a systemd started instance alongside alll the time17:51
axinoindeed I coul17:51
axinocould*17:51
Chipacakyrofa, o/17:56
Chipacakyrofa, i just saw the integration tests failures :-)17:56
kyrofaHey Chipaca! Haha17:56
Chipacakyrofa, do those tests need to run with debug?17:56
Chipacai mean17:57
kyrofaChipaca, some of them do, but not all (and in fact, some don't)17:57
Chipacai can fix the tests by expecting (and skipping) the version line, or by debug=False17:57
Chipacabut i don't know enough to know which is which tbh :-/17:57
kyrofaChipaca, 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 happened17:57
Chipacakyrofa, any guideline?17:58
kyrofaChipaca, hold on, let me take a quick look17:58
Chipacaah, true17:58
Chipacamight as well just fix them to expect the version line then17:58
ogra_just leave them as is and call them alternate facts17:58
Chipacakyrofa, 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
kyrofaChipaca, yeah but... a one-line change causing this many failures means our suite is fragile17:59
kyrofaChipaca, you'll get devel when running from source17:59
kyrofaChipaca, perhaps removing the v would look better, yeah18:00
Chipacaalso it was *two* lines, not one :-p18:00
kyrofa:P18:00
kyrofaChipaca, yeah our tests are just super fragile. I think we need to change the assertEquals to a assertThat([...], Contains())18:03
kyrofaChipaca, but that's not a tiny amount of work. We can take it if you like18:04
Chipacakyrofa, I can take a stab at it for the ones affected by this change18:05
kyrofaChipaca, alright. Note that there are 29 of them, sure appreciate that18:05
kyrofaChipaca, but yeah, please do use the testtools matchers where you can18:06
mupPR snapcraft#1087 opened: Don't wait for lxd networking in cleanbuild test <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/1087>18:13
jdstrandkyrofa: 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 /root18:16
kyrofajdstrand, 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:18
kyrofajdstrand, 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
KristijanZicHi! 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:19
kyrofajdstrand, but yeah, that was all I had too. Maybe I'll rewrite it to have them paste cert contents in instead18:20
jdstrandkyrofa: 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:22
kyrofajdstrand, the utility I was writing is what put the certs somewhere18:23
kyrofa(it copies them off to where they need to go)18:23
Chipacakyrofa, the tests that use pexpect are going to need to check for the version string explicitly18:24
kyrofaChipaca, 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 huh18:25
* Chipaca apologises for the context switch18:25
Chipacakyrofa, not to worry, i'll sort it18:26
kyrofajdstrand, 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 anything18:27
kyrofaKristijanZic, yes there is. Chipaca where is the snapd REST API documented these days?18:29
kyrofaOh wait-- Chipaca nevermind18:29
Chipacawell, I wouldn't call that a web api18:29
kyrofaKristijanZic, you don't want that, you want the store-side stuff18:29
ChipacaKristijanZic, note that wiki page is outdated (it says as much up there)18:29
ChipacaKristijanZic, in the updated document there's a snaps section18:29
KristijanZickyrofa: I just want to list snaps if possible that are in the current Ubuntu snap store.18:30
jdstrandkyrofa: sure. so, HOME we really have to have 'owner' match (we can't say 'owner or root' in apparmor atm) in order to enforce multiuser18:30
ChipacaKristijanZic, OTOH maybe you want to talk to snapd, not the store18:30
jdstrandkyrofa: but, there is this rule: /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix,18:30
jdstrandkyrofa: 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 it18:31
KristijanZicChipaca, 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 snaps18:31
ChipacaKristijanZic, sorry, which 'that'?18:31
ogra_heh18:31
kyrofajdstrand, indeed. It just means more documentation, heh18:32
jdstrandkyrofa: I'm still not sure why 'sudo cp' needs to be wrapped in a tool...18:32
ChipacaKristijanZic, uappexplorer talks to CPI18:32
kyrofajdstrand, because I want where they go to be under my control18:32
KristijanZicChipaca, snapd api?18:32
kyrofajdstrand, otherwise I need to document it, keep it up to date, and migrate accordingly18:32
ChipacaKristijanZic, https://github.com/snapcore/snapd/wiki/REST-API18:32
ogra_but that needs a local snapd instance18:32
ogra_if you dont want that CPI is the better option i guess18:33
jdstrandkyrofa: you could say 'sudo cp foo $SNAP_DATA ; sudo yoursnap.register foo'18:33
KristijanZicogra, any docs for cpi?18:33
ChipacaKristijanZic, that wiki page you pasted is the old CPI docs18:33
ChipacaKristijanZic, it links to the new ones18:34
ogra_KristijanZic, i'd just use the uappexplorer source as base for your queries ... and the wiki.ubuntu.com pages18:34
Chipacaogra_, dude, it's fully documented in its own section in the new docs18:34
ogra_code talks !18:35
ogra_:P18:35
KristijanZicChipaca, ok, thanks. ogra, sure18:35
ChipacaKristijanZic, https://search.apps.ubuntu.com/docs/#snap-specific-endpoints-errors18:37
Chipacatook me a bit because in the middle of fixing the tests before, didn't want to look at the browser :-)18:38
KristijanZicOh, great! Thank you :D18:39
Chipacakyrofa, I was wrong. Everything went better than expected.18:44
ChipacaI think it's a sign I should EOF right here.18:44
kyrofaChipaca, ah! Excellent, I agree. I'm jealous you're so far ahead of me18:44
Chipacakyrofa, no you're not -- not unless you really wanted to start work nine hours ago18:45
kyrofaYeah... you got me :P18:45
stokachukyleN, bugs.launchpad.net/snappy is the place for bugs these days? i know github issues got moved18:52
stokachusorry kyrofa18:52
kyrofastokachu, good question, hold on18:53
stokachugustavo told me but it was in passing18:54
kyrofastokachu, you probably want to log against snapd18:54
kyrofastokachu, https://launchpad.net/snapd18:54
stokachuok cool thanks ill do that now18:54
mupBug #1659924 opened: Snap failures in 16.04 <Snappy:New> <https://launchpad.net/bugs/1659924>18:58
kyrofastokachu, guess we're not the only ones, good thread ;)19:00
stokachukyrofa, yea it worked out pretty great, thanks for the push19:00
stokachuthough sergio mentioned about snapd 2.22 without the use of sudo, does that mean we aren't requiring people to snap login anymore?19:04
kyrofastokachu, honestly I'm not quite sure what he meant by that19:06
Chipacakyrofa, i haven't actually gone, and there's a failing test i'm fixing :-/19:42
kyrofaChipaca, :(19:42
Chipacakyrofa, fixed, pushed, and happy about it19:50
mupPR 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>19:51
mupPR snapcraft#1083 closed: project: support for gui in snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1083>20:22
mupPR snapcraft#1081 closed: local source: preserve symlinks to directories <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1081>20:25
mupPR 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:25
jdstranddavidcalle: 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:42
mupPR snapcraft#1088 opened: Release changelog for 2.26 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1088>20:43
mupPR snapd#2739 opened: tests: remove (some) garbage files found by restore cleanup analysis <Created by zyga> <https://github.com/snapcore/snapd/pull/2739>21:07
kirklandwho approves/denies requests to own reserved package names?21:09
kirkland(I submitted a couple)21:09
sergiusensmarcoceppi_, hey, sorry for asking again, bt I lost your quick instructions, mind sending them my way again?21:28
marcoceppi_sergiusens: hey, no problem https://github.com/juju-solutions/charm-pkg21:30
kyrofakirkland, talk to nessita and/or noise][21:30
* kirkland waves at nessita and noise][21:31
noise][kirkland: hey, what's up?21:32
noise][name regs...21:32
kirklandnoise][: howdy, I have a few snap package name registrations I'm pushing through21:32
noise][just got the notif, 1m21:32
kirklandnoise][: yeah, i have a few more coming21:32
kirklandnoise][: actually just do those two, and we're good for today ;-)21:33
sergiusensmarcoceppi_, then charm <what>; charm <what-now> ? :-)21:33
noise][ok21:33
marcoceppi_sergiusens: oh, `charm version; charm create foo; cd foo; charm build`21:33
noise][kirkland: done21:33
DedSechey, 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)21:34
mupPR snapd#2685 closed: interfaces/builtin: add account-control interface <Created by teknoraver> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2685>22:16
mupPR 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:17
kirklandnoise][: thanks, uploaded;  who does the review?22:22
mupPR snapd#2740 opened: releasing snapd version 2.22 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2740>22:55
noise][kirkland: reviews of the uploads are security team23:00

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