[02:24] <mup> PR snapd#6033 opened: tests: update parallel-install-store test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6033>
[03:12] <mup> PR snapd#6034 opened: many: save media info when installing, show it when listing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
[05:13] <mborzecki> morning
[06:08] <mup> PR snapd#6035 opened: tests/main/parallel-install-store: the store has caught up, do not expect failures <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6035>
[06:08] <mborzecki> super simple ^^
[06:12] <mborzecki> and it unblock spread runs on master
[06:38] <zyga> Re
[06:40] <zyga> mborzecki: we might need a backport
[06:49] <mborzecki> zyga: don't know if we can push a single cherry-pick, i'm opening a PR to 2.36
[06:49] <mup> PR snapd#6036 opened: tests/main/parallel-install-store: the store has caught up (2.36) <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6036>
[06:51] <dot-tobias> *waves good morning*
[06:52] <zyga> hey dot-tobias
[07:02] <pstolowski> mornings
[07:02] <zyga> o/
[07:04] <mup> PR snapd#6035 closed: tests/main/parallel-install-store: the store has caught up, do not expect failures <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6035>
[07:04] <mborzecki> pstolowski: hey
[07:05] <mup> PR snapd#6033 closed: tests: update parallel-install-store test <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6033>
[07:05] <zyga> can I get formal reviews on 5987 please
[07:06] <zyga> as well as on 6010 if you can
[07:14] <mborzecki> hm down to 34 PRs, nice
[07:14] <zyga> could be 32 if someone merges my PRs ;-)
[07:14] <zyga> (*shameless*)
[07:15] <mborzecki> thought i left +1 on 5987 already
[07:17] <pstolowski> zyga: looking
[07:18] <zyga> thank you for reviews in any case :)
[07:22] <pstolowski> zyga: not sure about snap-confine-debug change in makefile.am (i'm not clear about background of this); it looks like noinst_PROGRAMS += snap-confine/snap-confine-debug is left intact there, intended?
[07:22] <zyga> yes, that's so that 'make all' builds it
[07:22] <pstolowski> ok
[07:22] <zyga> make hack just now installs that debug copy with extra stuff for local work
[07:22] <zyga> we still have the non-debug version as before
[07:26] <pstolowski> +1
[07:37]  * pstolowski runs an errand
[07:41] <zyga> more rain today
[07:47] <mup> PR snapd#5987 closed: cmd: refactor IPC and lifecycle of the helper process <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5987>
[07:55] <mborzecki> multipass is a classic snap?
[08:02] <zyga> I think it needs kvm
[08:02] <zyga> So ... likely?
[08:03] <mborzecki> aand power outage :/
[08:06] <zyga> Uh, does that happen often?
[08:08] <mborzecki> zyga: quite often during thunderstorms and super windy weather, i was actually surprised that it happened only now given that's been very windy for 3 days now
[08:11] <mborzecki> electricity company will happily take your money but they're not equally keen to replce airlines with underground power cables or fix their distribution transformers
[08:20] <ackk> mborzecki, yes it's --classic
[08:24] <mborzecki> multipassd not starting https://paste.ubuntu.com/p/3Zd3zcTrgK/
[08:25] <mborzecki> ackk: should i use beta rather than edge?
[08:25] <ackk> mborzecki, I've been using edge and it used to work (at least, it did yesterday)
[08:26] <ogra> zyga, qemu-virgil is using kvm too and doesnt need to be classic ... i think that not caused by kvm
[08:26] <ogra> *that's
[08:26] <mborzecki> ackk: just for the record, is should work on non-ubuntu systems too, right?
[08:27] <ackk> mborzecki, AFAIK classic only works on ubuntu
[08:27] <ackk> ogra, ^ ?
[08:27] <mborzecki> ackk: i mean multipass (whcih is a classic snap)
[08:27] <Chipaca> zyga: morning
[08:27] <ackk> mborzecki, right, I mean I don't think it will because classic snaps only work on ubuntu (AFAIK)
[08:29] <ogra> ackk, afaik you only need to create the /var/lib/snapd/snap to /snap link to make them work on non-ubuntu
[08:31] <ackk> ogra, but don't classic snaps assume the ubuntu distro layout underneath?
[08:31] <ackk> I mean, they probably work on some non-ubuntu distros but ISTR they don't on some
[08:31] <ogra> depends how they are built :)
[08:32] <ackk> mborzecki, which distro are you using?
[08:32] <ogra> this is totally up to the creator ... you can point all library paths to inside the snap
[08:32] <mborzecki> ackk: afaiu they should not, oherwise it defats the purpose of having them as snaps
[08:32] <ogra> then a classic snap isnt different to i.e. an upstream binary tarball you extract to /opt
[08:33] <Chipaca> (morning all)
[08:33] <ackk> ogra, sure, I mean they might rely on certain binaries to be available on the system. for instance I had a snap published as classic because the app calls "sudo" and that doesn't work in non-classic
[08:34] <ogra> well, you could also just fix the app to not do that ;) or design your snap differently (a daemon process managing the elevated bits that a frontend wrapper talks to)
[08:35] <ogra> that would even allow you strict confinement ;)
[08:35] <ackk> ogra, yeah I'm talking about snapping existing apps
[08:35] <ogra> right, internal sudo calls are a special case where classic is valid
[08:39] <ackk> ogra, I wonder if there would be a way for core to provide a fake sudo that just forwards the command, so if your app has the right slots it can still do stuff, without using classic
[08:40] <ogra> there could perhaps be an interface, yes ... but i bet thats pretty non-trivial to get right in a safe manner, you need to access the passwd db, suoders etc
[08:40] <Chipaca> where were the environment variables that snapcraft exposes during a build documented?
[08:41] <Chipaca> I remember somebody asking about this and having to go to github to find it
[08:41] <Chipaca> (a docs github)
[08:41] <Chipaca> degville: you maybe? ^
[08:41] <zyga> o/
[08:42] <zyga> Took small break for making breakfast for my daughter
[08:42] <ackk> Chipaca, btw, it seems many links in the table on https://docs.snapcraft.io/snapcraft-yaml-reference are broken (they don't do anything)
[08:43] <Chipaca> ackk: yep, reported that one
[08:43] <ackk> cool, thanks
[08:43] <Chipaca> I mean, somebody did
[08:43] <Chipaca> not me
[08:45] <degville> Chipaca: is this the one: https://github.com/canonical-docs/snappy-docs/blob/master/reference/env.md
[08:46] <Chipaca> degville: similar but the SNAPCRAFT_ ones
[08:46] <degville> ah, ok. I'll look.
[08:48] <degville> Chipaca: https://forum.snapcraft.io/t/environment-variables-that-snapcraft-exposes/7569 ?
[09:07] <chesty> hi, on my laptop my default route goes over a vpn and I have a net namespace if I want an application to not use the vpn, ie `sudo ip netns exec novpn gosu me firefox ` or whatever. this doesn't work for snap, how do I make a snap use an alternate routing table?
[09:10] <zyga> chesty: when you say it doesn't work, what are the symptoms?
[09:11] <chesty> sudo ip netns exec novpn sudo -u michaelc skypeexecv failed: Permission denied
[09:11] <zyga> do you see any apparmor denials? dmesg | grep DENIED
[09:12] <chesty> yes, [336140.107862] audit: type=1400 audit(1540372346.301:4293): apparmor="DENIED" operation="exec" profile="/snap/core/5789/usr/lib/snapd/snap-confine" name="/snap/core/5789/usr/lib/snapd/snap-exec" pid=27632 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=1098200003 ouid=0
[09:13] <chesty> oh, I might need the classic flag?
[09:13] <chesty> nope, the classic flag didn't help, I did need it to install skype
[09:13] <zyga> no, this is against snap-confine, not a particular snap
[09:13] <zyga> hmmm
[09:14] <zyga> this is unexpected
[09:14] <zyga> can you please pastebin /etc/apparmor.d/snap.core.5789.usr.lib.snapd.snap-confine
[09:16] <chesty> the only snap related file in /etc/apparmor.d is /etc/apparmor.d/usr.lib.snapd.snap-confine.real
[09:18] <zyga> chesty: what does snap version say?
[09:19] <chesty> 2.36~pre2+git971.73ec9b5~ubuntu16.04.1
[09:19] <zyga> can you please go to /var/lib/snapd/apparmor/ and look for snap-confine.core.NNN
[09:19] <chesty> I believe I install an edge a few weeks ago to fix a bug
[09:19] <zyga> and pastebin the profile for the revision 5789 please
[09:20] <ackk> ogra, I meant, sudo could just let the app make the call and let normal confinement enforce permissions, can't it?
[09:21] <ogra> no, if you exec inside the snap environment also sudo is confined and wont see the host system unless there is an interface
[09:22] <ackk> ogra, yeah but I meant replace sudo with a fake sudo
[09:22] <ackk> ogra, so that "sudo foo" would just run "foo"
[09:22] <ogra> well, you still want to elevate your privs somehow
[09:23] <ogra> or the app wants rather
[09:27] <chesty> https://pastebin.com/VJRpkgd6
[09:35] <mborzecki> yay, building a snap via snapcraft in a vm launched by multipass, all on arch
[09:48] <mborzecki> docs.snapcraft.io doesn't really mention snapcraft + multipass
[09:51] <pstolowski> nice!
[09:58] <mborzecki> and it built successfuly!
[09:59] <pstolowski> even nicer!
[10:05] <Chipaca> degville: that was it, thanks!
[10:06] <degville> np. We should make it easier to find.
[10:06] <Chipaca> yar
[10:07] <dot-tobias> should I be able to scp something to an ubuntu-core-vm (qemu), or is this not possible? SCP works fine with “real” Core installations, but somehow neither SSH key nor the manually set password for my account on the core vm is accepted. Auth.log in the vm just shows connection attempts. Am I completely off here, or missing something?
[10:07] <Chipaca> dot-tobias: how do you run the vm?
[10:08] <zyga> it works but perhaps the way you run the VM is tricky and your network is not properly set up\
[10:08] <Chipaca> dot-tobias: I use: kvm -m 4G -redir :8022::22 -snapshot -serial stdio ~/Downloads/core18-amd64-18-beta20180823.img
[10:08] <Chipaca> dot-tobias: I have a "kvm.sanppy" entry in my ~/.ssh/config
[10:08] <Chipaca> dot-tobias: and i just "ssh kvm.snappy" and it works
[10:09] <Chipaca> dot-tobias: (that particular invocation is an example only, happened to be the first  one in my history :) )
[10:09] <dot-tobias> Chipaca: Using the ubuntu-core-vm as described here: https://developer.ubuntu.com/core/examples/snaps-on-mir
[10:10] <Chipaca> dot-tobias: ah, never tried that, let me give it a whirl
[10:11] <dot-tobias> (my previous message was missing a “snap” after “ubuntu-core-vm 😊 )
[10:11] <dot-tobias> Chipaca: Thanks
[10:12] <Chipaca> I need to complain at gerboland (assuming these docs are from them) about using --devmode like this :-(
[10:12] <ogra> dot-tobias, alternatively you can use qemu-virgil ... (launch instructions are in snap info) ...
[10:12] <popey> ogra: why does core not have curl or wget?
[10:13] <ogra> popey, dunno ... just snap install mget ?
[10:13] <popey> ugh
[10:13] <ackk> Chipaca, that's also how maas uses it I guess :)
[10:13] <popey> I dont wanna install stuff on a clean system
[10:13] <popey> just wanna use curl to find out the public IP
[10:13] <tomwardill> I've bounced off that before too
[10:14] <mup> PR snapd#6037 opened: tests/unit/gccgo: drop gccgo unit tests (2.36) <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6037>
[10:14] <ogra> well, i dont remember anymore why we didnt ship wget ... security reasons most likely
[10:14] <mborzecki> super simple ^^
[10:15] <popey> hah, we ship netcat
[10:15] <Chipaca> popey: python3 -c 'from requests import get;print(get("https://api.ipify.org").text)'
[10:15] <popey> that'll do, thanks :)
[10:18] <zyga> mborzecki: is there a way to install python3 on amazon linux?
[10:18] <Chipaca> dot-tobias: so, using ubuntu-core-vm, you get the initial configure screen, yes?
[10:19] <mborzecki> zyga: maybe epel
[10:19] <Chipaca> zyga: snap install pypy
[10:19] <mborzecki> zyga: although iirc epel-7 should be already added to the repos
[10:19] <Chipaca> zyga: i mean pypy3
[10:19] <zyga> Chipaca: it would need to be classic
[10:19] <Chipaca> zyga: pypy3 is classic
[10:19] <zyga> I may find a way out of this
[10:20] <mborzecki> zyga: same problem will be on centos
[10:20] <dot-tobias> Chipaca: qemu just shows a black screen, but knowing the setup by heart i just pressed enter until it was configured 😊 Installing mir-kiosk works.
[10:20] <Chipaca> grr
[10:20] <Chipaca> dot-tobias: do you have an nvidia card?
[10:20] <dot-tobias> Chipaca: Yes
[10:20] <Chipaca> grr³
[10:20] <mborzecki> nvidia..
[10:20] <Chipaca> i have an nvidia card too, today
[10:20] <Chipaca> and also get a black screen
[10:20] <zyga> today"
[10:21] <zyga> heisencard
[10:21] <zyga> sometimes nvidia
[10:21] <zyga> sometimes amd
[10:21] <zyga> ;-)
[10:21] <zyga> I need to bring the heater in here, I' m freezing
[10:21] <mborzecki> nvidia on even days, today's 24th :)
[10:21] <Chipaca> I edited the script to change sdl,gl=on to sdl,gl=off, and now it works (but is slow, because sdl seems slow)
[10:21] <dot-tobias> Gotta head off for a while, colleagues complaining that we're missing lunch 😄 → re later
[10:21] <Chipaca> mborzecki: zyga: it's a 'prime' laptop, so today it's in have-nvidia-i'm-plugged-in mode
[10:22] <mborzecki> Chipaca: heh, i understand what you're going through :)
[10:23] <Chipaca> mborzecki: it's not a mid-life crisis until _I_ say it is!
[10:23] <chesty> hey zyga, did you see my pastebin above by chance?
[10:23] <Chipaca> mborzecki: wait what were we talking about
[10:31] <ogra> Chipaca, qemu-virgil ... justsayin ;)
[10:31] <ogra> (tested regular with nvidia)
[10:32] <Chipaca> ogra: i was trying to help dot-tobias, which took me to https://developer.ubuntu.com/core/examples/snaps-on-mir which tells people to do things in a way I tell people telling people to do things not to do
[10:32] <ogra> heh
[10:33] <zyga> chesty: yes, I saw it, I was investigating and then got interrupted, sorry
[10:33]  * Chipaca hopes ogra's parser can un-nest that, but has hopes because German
[10:33] <ogra> totally !
[10:33] <chesty> zyga, no no, i appreciate your help. I just didn't ping you so thought you might not have seen it
[10:33] <zyga> chesty: so... there are no permissions to run snap-exec directly in that profile but that's exactly as the profile was all the time
[10:34] <zyga> chesty: I don't understand why that detail happens yet
[10:34] <zyga> can you report a bug about it so that it doesn't get lost please
[10:34] <Chipaca> ogra: dunno about this virgil thing, I don't want to end up with qemu tied to a boat with wax up its … ears
[10:34] <Chipaca> ogra: also that developer is super sketchy
[10:35] <ogra> yeah, only does hacks all the time
[10:35] <ogra> (i heard)
[10:36] <chesty> zyga, absolutely, is that on github?
[10:36] <zyga> chesty: on launchpad.net/snapd please
[10:37] <Chipaca> chesty: https://bugs.launchpad.net/snapd/+filebug
[10:38] <Chipaca> zyga: ^ :-)
[10:38] <zyga> thanks Chipaca :)
[10:38] <Chipaca> zyga: https://bugs.launchpad.net/snapd/+filebug?field.title=all+ur+base
[10:38] <ogra> we used to have that in the channel topic :)
[10:38] <zyga> rbelongtostore
[10:39] <Chipaca> xceptfedorabase
[10:40] <zyga> no no, it's in the store too
[10:40] <zyga> mkosi will soon support building base snaps
[10:40] <Chipaca> datbelongtosongoku
[10:41] <chesty> zyga https://bugs.launchpad.net/snapd/+bug/1799677
[10:41] <zyga> thank you chesty
[10:41] <mup> Bug #1799677: apparmor issue when running snap with ip netns exec <snapd:New> <https://launchpad.net/bugs/1799677>
[10:42] <zyga> chesty: I'll return to the bug after some feature work I need to finish soon
[10:42] <mborzecki> heh, travis jobs on release/2.36 branch are not so much fun
[10:42] <chesty> zyga and thank you for you help. there's no rush. cheers
[10:43] <mborzecki> iirc someone was complaining about https://bugs.launchpad.net/snapd/+bug/1799677 in the comments under one of the reddit topics about flatpak
[10:43] <mup> Bug #1799677: apparmor issue when running snap with ip netns exec <snapd:Triaged by zyga> <https://launchpad.net/bugs/1799677>
[10:45] <mup> PR snapd#6037 closed: tests/unit/gccgo: drop gccgo unit tests (2.36) <Simple 😃> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6037>
[10:47] <mborzecki> any ideas about https://github.com/snapcore/snapd/pull/6025 ?
[10:47] <mup> PR #6025: Add go.mod files <Created by ryanjyoder> <https://github.com/snapcore/snapd/pull/6025>
[10:54] <Chipaca> ogra: qemu-virgil has the same gl issues
[10:54] <Chipaca> ogra: mind you i might need to restart to get gl working (or it might be broken) (quantum gl)
[11:02] <zyga> mborzecki: can you have a look at https://github.com/snapcore/snapd/pull/6010 again please
[11:02] <mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
[11:02] <zyga> mborzecki: there are two topics in that go.mod pr: just the go.mod feature (which I'm not familiar with) and the bigger topic of what is our public API
[11:19]  * pstolowski lunch
[11:20] <Chipaca> mborzecki: zyga: https://github.com/snapcore/snapd/pull/6025#issuecomment-432616398
[11:20] <mup> PR #6025: Add go.mod files <Created by ryanjyoder> <https://github.com/snapcore/snapd/pull/6025>
[11:21] <mborzecki> Chipaca: thanks for leaving a note there
[11:22] <Chipaca> i don't want op to think we're ignoring them :)
[11:24] <mborzecki> Chipaca: otoh, the code is on github, nothing stopping them from using it as a public lib no matter what we say
[11:24] <Chipaca> mborzecki: oh, i don't mind that :-)
[11:25] <mborzecki> as long as we don't promise anything :)
[11:25] <Chipaca> mborzecki: it's the complaining when we break it, or more precisely the having to run around like a headless chicken three hours after eod because we released something that broke them and it's suddenly our problem somehow
[11:26] <mborzecki> zyga: left a comment, i think you missed some python[23] in mount.sh
[11:27] <zyga> ohh
[11:27] <zyga> drat
[11:27] <zyga> I tested manually
[11:27] <zyga> thanks!
[11:28] <zyga> pushed
[11:32] <mborzecki> 2018-10-24 10:54:23 Cannot allocate google:ubuntu-18.10-64: cannot find any Google image matching "ubuntu-os-cloud-devel/daily-ubuntu-1810-cosmic-v20181002" on project "ubuntu-os-cloud-devel"
[11:32] <mborzecki> eh, need one more patch for 2.36
[11:37] <dot-tobias> Chipaca: (re Ubuntu Core in KVM) FWIW, using the latest 18 Core image from today and your kvm invocation, console-conf shows just fine on the same nvidia card as before. I suspect the ubuntu-core-vm snap --beta does not have the latest 😊
[11:38] <Chipaca> dot-tobias: does any gl snap work for you right now?
[11:38] <dot-tobias> Chipaca: Sec, testing mir-kiosk …
[11:38] <Chipaca> dot-tobias: is mir-kiosk a gl-using snap?
[11:41] <ogra> yes
[11:41] <ogra> ist a hard requirement
[11:41] <ogra> *it's
[11:41] <dot-tobias> Chipaca: That question is beyond my knowledge, but I assume it does … (but ogra confirms)
[11:42] <dot-tobias> As for the test, mir-kiosk does not work. journalctl entry: Exception while creating graphics platform // st::exceptioin::what: Failed to find platform for current system
[11:42] <Chipaca> yep, and i confirmed by downloading the snap and looking :-)
[11:43] <Chipaca> dot-tobias: ohmygiraffe is the canonical opengl test, i hear
[11:43] <Chipaca> … and that one works, here
[11:43] <Chipaca> ogra: so boo, your snap is broken :-D
[11:44]  * Chipaca really has no idea about this side of the stack
[11:44] <Chipaca> also i suck at ohmygiraffe
[11:44] <Chipaca> i'm lion fodder
[11:44] <ogra> Chipaca, which snap ?
[11:45] <Chipaca> ogra: qemu-illiad
[11:45] <Chipaca> or was it qemu-virgil
[11:45] <ogra> works fine here
[11:45] <ogra> on nvidia and intel
[11:45] <ogra> (as long as you follow the steps in snap info)
[11:45] <ogra> and it was -virgil :)
[11:46] <Chipaca> actually, now it's started working
[11:46] <Chipaca> WAT
[11:46] <Chipaca> ah no, -vga std
[11:46] <Chipaca> heh
[11:46] <ogra> yeah, you dont want std
[11:46] <Chipaca> oh it works with virtglwotsit as well
[11:46] <Chipaca> ohmygiraffe fixed my gl, or … dunno
[11:46] <Chipaca> maybe i just needd lunch
[11:46] <Chipaca> needed*
[11:46] <Chipaca> ¯\_(ツ)_/¯
[11:47] <ogra> to just test if GL works and if it starts you can simply start it without any options
[11:47] <ogra> should get you the accelerated gtk UI ... with a menu bar at the top
[11:48] <Chipaca> too late, now i'm running budgie on it
[11:48] <ogra> heh
[11:53]  * dot-tobias *tries to follow this conversation and installs qemu-virgil snap*
[11:56] <ogra> dot-tobias, afterwards do a "snap info qemu-virgil"
[11:56] <ogra> it has the quickstart instructions
[11:58] <Chipaca> ogra: you should look into getting that autoconnected
[11:59] <dot-tobias> ogra: Done that, getting permission denied with “could not access KVM kernel module”. Did connect the interface with sudo (if that makes any difference)
[12:00] <Chipaca> dot-tobias: are you in the kvm group?
[12:01] <ogra> Chipaca, yeah never got to doing the paperwork for autoconnect yet
[12:02] <ogra> dot-tobias, if you arent in the kvm group but know the kvm module is loaded you can also just use qemu-virgil with sudo
[12:04] <dot-tobias> Chipaca: No I was not (did I mention that my knowledge of all this is virtually non-existent?), but after adding it with usermod it still does not work.
[12:04] <Chipaca> dot-tobias: for the usermod to take you need to re-login (or use sg)
[12:05] <Chipaca> a blood sacrifice is also needed
[12:05] <Chipaca> but it doesn't need to be yours
[12:05] <ogra> well ... or sudo
[12:05] <dot-tobias> Chipaca: Learning new things every day … thought usermod is instant, that did the trick. Thanks!
[12:06] <dot-tobias> using sudo for qemu-virgil gave me a perm denied on the image file in my user's home directory ¯\_(ツ)_/¯
[12:06] <Chipaca> yep :-)
[12:06] <ogra> lol
[12:06] <ogra> ok
[12:06] <Chipaca> ogra: you should be able to detect some of this and warn
[12:06] <Chipaca> ogra: otherwise maybe including it in descr
[12:07] <dot-tobias> qemu-virgil starting now, but the qemu window states "no bootable device" when using the exact command from qemu-virgil snap info
[12:07] <ogra> can you paste the line here ?
[12:07] <ogra> (the one you used in your terminal)
[12:07] <ogra> note there is a line wrap in the info output
[12:08] <ogra> Chipaca, good point
[12:08] <Chipaca> dot-tobias: 'exact command' including the 'some.img' at the end?
[12:08] <dot-tobias> ogra: nevermind, I had renamed the image file in the meantime … :facepalm:
[12:08] <Chipaca> heheh
[12:08] <Chipaca> :-)
[12:09] <ogra> heh
[12:09] <dot-tobias> Chipaca: nope, I was smart enough to supplement some.img with the actual name, but forgot that I changed it between the first and last attempt to start qemu-virgil (because I downloaded another daily build)
[12:10] <ogra> wow, this is gross ...
[12:11] <mup> PR snapd#5954 closed: [wayland] explicitly permit file locking for wayland lock <Created by gerboland> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5954>
[12:11] <ogra> i'm creating a hardcoded link in $SNAPCRAFT_PART_INSTALL to point to /var/snap/<snapname>/current/foo in ony of my snaps ...
[12:12] <ogra> if i have that snap installed, snapcraft actually reads the content from that dir on disk instead of respecint that it is a symlink inside my build
[12:12] <ogra> s/ony/one
[12:13] <ogra> so it doesnt just put the link into the snap but copies the dir from /var
[12:14] <ogra> removing the snap before building gets me a properly dangling symlink
[12:14] <ogra> (as intended)
[12:15] <Chipaca> ogra: sounds buggeh
[12:15] <dot-tobias> ogra, Chipaca: Welp, scp'ing to the qemu-virgil-hosted Core image (20181023) does not work either (which was the initial problem with just running ubuntu-core-vm from its snap) 😞 and the manual kvm invocation by Chipaca seems to have issues with gl apps, which prevents me from actually testing my kiosk app 😄
[12:15]  * dot-tobias stuck between a rock and a hard place
[12:15] <ogra> how do you scp ?
[12:15] <Chipaca> dot-tobias: which was the image you were getting?
[12:15] <Chipaca> dot-tobias: link plz, so i can try to repro
[12:16] <dot-tobias> http://cdimage.ubuntu.com/ubuntu-core/18/20181023/ubuntu-core-18-amd64.img.xz
[12:16] <dot-tobias> Chipaca ^
[12:16] <Chipaca> getting
[12:16] <Chipaca> ah, the core-18 snap, ok
[12:16] <Chipaca> getting
[12:16] <ogra> scp -P 10022 file-to-copy user@localhost:~/
[12:16] <ogra> thats how you should do it
[12:18] <dot-tobias> ogra: Yes, the connection itself is fine, and I can SSH in without problems – but using scp it does not accept my SSH key, then asks for the password instead. I even tried to set the password inside the vm with passwd <user> but giving the super-slowly-typed password to scp still aborts after 3 tries.
[12:18] <Chipaca> or “scp file-to-copy kvm.snappy:” if you have the right .ssh/config entry =)
[12:18] <Chipaca> core got, booting
[12:19] <zyga> error: failed to commit transaction (conflicting files)
[12:20] <dot-tobias> ogra, Chipaca: scp -p 10022 my.snap $SSO_USER@localhost:~/ → prompts for $SSO_USER's password, debugging with -vvv shows that my SSH key just gets ignored. Forcing it with -i ~/.ssh/my_key has no effect
[12:20] <Chipaca> dot-tobias: -p, or -P?
[12:20] <dot-tobias> Chipaca: -p
[12:20] <ogra> large p please
[12:20] <ogra> small p preserves modification times of the file you copy
[12:20] <Chipaca> you're trying to ssh into yourself =)
[12:21] <ogra> large P means port
[12:21] <dot-tobias> I'm gonna go sit in the dumb corner for a while now … Assumed that -p would be the same as for ssh.
[12:21] <ogra> yeah, it is super confusing and annoying that they differ
[12:21] <Chipaca> dot-tobias: https://pastebin.ubuntu.com/p/SfwM3ngYx7/
[12:22] <Chipaca> dot-tobias: adjust as necessary, and append to ~/.ssh/config, and then forget all the sillyness of -p/-P etc
[12:22] <dot-tobias> Chipaca: Thanks 😊
[12:23] <Chipaca> I suspect I could prune the "phablet" entry from my .ssh/config
[12:23] <Chipaca> also bazaar.ubunet
[12:23] <dot-tobias> Well, I guess I should not try again with the ubuntu-core-vm route because I might very well discover that I wasted > 15min on this when I could have just re-read the scp manpages. Huge thank you to ogra and Chipaca
[12:31] <mborzecki> Chipaca: can I get a second +1 on https://github.com/snapcore/snapd/pull/6036 ?
[12:31] <mup> PR #6036: tests: the store has caught up, drop gccgo test, update cosmic image (2.36) <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6036>
[12:33] <ogra> Chipaca, btw, i dont get why ubuntu-core-vm actually needs devmode at all ... it is essentially similar to qemu-virgl (just uses an older qemu and has a lot of wrapper scripts around the qemu call)
[12:33] <Chipaca> ogra: I'm in communication with the author about this
[12:34] <Chipaca> mborzecki: you can try
[12:34]  * mborzecki tries
[12:34] <Chipaca> mborzecki: go go go
[12:35] <mborzecki> Chipaca: thx
[12:35] <mup> PR snapd#6036 closed: tests: the store has caught up, drop gccgo test, update cosmic image (2.36) <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6036>
[12:44] <zyga> I need a 2nd review on https://github.com/snapcore/snapd/pull/6010 to move forward
[12:44] <mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
[13:21] <pstolowski> cachio__: for a 2nd serial port with nested vm test it's important that it also has a different serial number, i hope qemu does that
[13:31] <zyga> Chipaca: reviewed https://github.com/snapcore/snapd/pull/5955/reviews
[13:31] <mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots 📸󠁟> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
[13:32] <zyga> I would love a review of https://github.com/snapcore/snapd/pull/6010 in return
[13:32] <mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
[13:38] <zyga> k, I need to go to the vet again
[13:38] <Chipaca> zyga: thank you for the review!
[13:38] <Chipaca> i'll get on those suggestions in a bit
[13:41] <mborzecki> Chipaca: don't remember, if you do `snap restore` without --users then data for all users is restore or none?
[13:41] <Chipaca> mborzecki: all
[13:42] <Chipaca> that's one of the rough edges imo
[13:42] <mborzecki> Chipaca: and if i want no users?
[13:42] <Chipaca> mborzecki: er... shoot 'em?
[13:42] <mborzecki> Chipaca: that's what i meant in https://github.com/snapcore/snapd/pull/5955/files#r224709843 i think it'd be nice to add something to long help of restore (and maybe save too)
[13:42] <Chipaca> mborzecki: there's also no way to toggle restoring config
[13:43] <mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots 📸󠁟> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
[13:43] <Chipaca> mborzecki: I'd rather not document it, and instead find a way of doing it :-)
[13:43] <mborzecki> Chipaca: soemthing like 'When no users are provided, restoring a snapshot restores data for all users (whose data is in snapshot?)'
[13:45] <Chipaca> we could have --no-system, --no-users, and --no-config
[13:45] <Chipaca> --no-nothing
[13:45] <mborzecki> hm many switches
[13:45] <mborzecki> --users '' ?
[13:47] <wgrant> mborzecki: Morning. Not sure if you saw on the forum, but we have parallel installs available on the prod store now.
[13:47] <mborzecki> wgrant: yup, saw that, thanks for the notice, from the little testing I did it seems to be working fine
[13:47] <wgrant> mborzecki: Excellent. Do let me know if you see anything odd.
[13:47] <mborzecki> wgrant: ok
[13:49] <mborzecki> Chipaca: silly thought, does `snap saved` show whose user data is in the snapshot?
[13:49] <Chipaca> mborzecki: I'll update the help with that fwiw
[13:50] <Chipaca> mborzecki: it does not. I'd wondered about including that (maybe in a --verbose or --long).
[13:51] <Chipaca> but didn't acquire consensus, and it's been hard enough getting reviews for the bits that _did_ have consensus...
[13:51] <mborzecki> Chipaca: i think we have --verbose elsewhere too (snap info?), but that's soemthing for a follow up presumably
[13:51] <Chipaca> mborzecki: all of these flaggy things are :-)
[13:52] <Chipaca> mborzecki: there's --verbose but for something that's already vertical; showing users would force a switch to vertical here
[13:52] <Chipaca> so maybe --long is better
[13:52] <Chipaca> dunno
[13:52] <mborzecki> another PR anyway :)
[13:52] <mborzecki> we want this one to land after all
[14:15] <zyga> re
[14:45] <mup> PR snapd#6032 closed: overlord/snapstate, snap, wrappers: start services in the right order during install <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6032>
[14:55]  * cachio lunch
[16:32] <cjwatson> koala_man: I don't suppose you have the skillset to track down https://github.com/haskell/HTTP/issues/68 ?
[16:32] <cjwatson> koala_man: That seems to be the root cause of this weird proxy bug with shellcheck
[16:48] <koala_man> cjwatson: I might, but it would probably require source changes to HTTP, cabal or both. How would those fixes make it back into the xenial build image?
[16:56] <cjwatson> koala_man: It's possible we'll have to work around it; I'm not sure yet
[16:57] <cjwatson> koala_man: But it appears to be violating RFC MUSTs, so ...
[16:57] <koala_man> cjwatson: xenial uses cabal-install version 1.22.6.0-2 while this bug appears to be a non-issue in >1.23.0.0 (after https://github.com/haskell/cabal/commit/b780cc77dd) due to not using the HTTP library anymore
[16:57] <cjwatson> Oh, interesting
[16:57] <koala_man> and that was over three years ago
[16:58] <cjwatson> (I'm less interested in workarounds now I've captured straces that show xenial's cabal-install version blatantly Doing HTTP Wrong)
[16:59] <cjwatson> Same symptoms as in that bug, basically: gets 301 with Connection: close, tries to write the redirected request to the same FD, gets EPIPE, gets very sad
[16:59] <Chipaca> backport of the 1.24 from bionic in a ppa? or has the haskell stack changed too much?
[16:59] <cjwatson> Backporting Haskell stacks tends to be LOL
[17:00]  * Chipaca chooses to read that as a labour of love
[17:00] <cjwatson> When I used to do this from time to time in Ubuntu it took literally days just to do all the rebuilds
[17:00] <cjwatson> Can't imagine doing it as an SRU
[17:00] <cjwatson> cabal-install *might* be standalone enough ...
[17:00] <koala_man> haha, yes, the ecosystem certainly has its challenges
[17:03] <Chipaca> cjwatson: I can't even get the build deps for the one in xenial
[17:04] <Chipaca>  builddeps:haskell-cabal-install : Depends: libghc-zlib-dev (< 0.6) but 0.6.1.1-1 is to be installed
[17:04] <cjwatson> Yeah, that was bumped to < 0.7 in bionic; I guess haskell-cabal-install wasn't rebuilt in the last round because it's a standalone application so nobody noticed
[17:05] <cjwatson> bionic's version needs libghc-hackage-security-dev and libghc-tar-dev (>= 0.5.0.3) though, neither of which are in xenial
[17:05] <cjwatson> Conceivably easier to backport that one commit
[17:05] <Chipaca> maybe there's a haskellers ppa out there
[17:05] <cjwatson> Well, plus zlib dep fix
[17:06] <cjwatson> We really need the version in xenial to be able to actually do HTTP properly
[17:06] <cjwatson> I don't really want to punt everyone to a PPA
[17:07] <Chipaca> .... maybe there's a snap of it
[17:07] <Chipaca> :-D
[17:07]  * Chipaca runs away and hides
[17:07] <koala_man> :D
[17:12] <koala_man> shellcheck can also be built with haskell-stack. I can see if the xenial version is recent enough, and whether it does HTTP better
[17:14] <cjwatson> I'm just grabbing github:haskell/cabal to see if I can work out what to backport and if it's possible without getting into too many complication
[17:14] <cjwatson> s
[17:15] <cjwatson> I smell dinner though
[17:20] <mup> PR snapd#5972 closed: tests: initial setup for testing current branch on nested vm and hotplug management <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5972>
[17:24] <ogra> hmm
[17:25] <ogra> so i just uninstalled htop, reinstalled it with --classic ... noticed that it can see al processes without any interfaces connected ... then uninstalled it again, reinstalled it without --classic and it can *still* manage all processes despite no interfaces being shown connected
[17:26] <ogra> does using --classic for a snap premanently trash confinement now ?
[17:29] <ijohnson> ogra: try using `/usr/lib/snapd/snap-discard-ns htop` and running htop again, it may be reusing the classic namespace setup for the snap, but I'm not sure as I don't know what exactly is setup for a classic snap (if anything)
[17:30] <ogra> well, i'd expect "unconfined"
[17:31] <ogra> well, nothing changed
[17:31] <ogra> i have a confined htop that can see (and kill !!) all processes
[17:31] <ijohnson> right but I don't know if there's a mount namespace setup for classic snaps, as if there is it could be re-used when you run it again. I've run into similar issues with namespaces not getting discarded after a snap was removed
[17:31] <ogra> well, i discarded it with the above commend
[17:31] <ogra> no change
[17:32] <ijohnson> yeah no other ideas from me then
[17:33] <ogra> this smells very very broken :/
[17:33] <ijohnson> yeah I didn't actually realize that you could install a strict snap with classic confinement, I thought that was disallowed
[17:33] <ogra> i even get multiple pages of DENIED messages in dmesg -w
[17:34] <ogra> when starting htop
[17:34] <ogra> yet it can see the whole processlist and kill all processes owned by me
[17:34] <ogra> operates completely unconfined
[17:35] <ijohnson> should probably report as a bug on LP (perhaps as a security bug?)
[17:35] <ogra> Chipaca, if i used --classic with a confined snap, do i have to do some magical secret handshake to get it back to being confined ?
[17:36] <ogra> (even uninstalling/reinstalling, discarding the namespace and whatnot doesnt seem to get me confinement back)
[17:36] <Chipaca> ogra: remove and reinstall should do the trick
[17:36] <ogra> well, probably i'm dong something wrong
[17:36] <Chipaca> ogra: if it doesn't, you've found a bug
[17:36] <ogra> then i did
[17:36] <ogra> sigh
[17:36] <Chipaca> ogra: stop breaking snapd :-p
[17:36] <ogra> now maxiberta can read my disk !!!
[17:37] <Chipaca> ogra: I hear he's bribe-able
[17:37] <ogra> yeah, but the next sprint we cross paths is far ... so beer bribe doesnt work
[17:37] <Chipaca> ogra: you'd be shocked to know how cheap it would be to get it delivered
[17:39] <ogra> delivered, yeah ... but then ... customs ...
[17:39] <Chipaca> ogra: i meant something like https://www.pedidosya.com.ar/restaurantes/buenos-aires/don-cervecero-menu
[17:39] <Chipaca> ogra: (those are argentine pesos)
[17:40] <Chipaca> ~10eur for 10 473cc cans delivered
[17:40] <Chipaca> maybe :-)
[17:40] <Chipaca> anyhoo, what was i doing
[17:40] <Chipaca> oh yeah swearing at spread
[17:47] <ogra> https://bugs.launchpad.net/snapd/+bug/1799760
[17:47] <mup> Bug #1799760: using --classic for a confined snap doesnt get me confinement back even after reinstalling the snap <snapd:New> <https://launchpad.net/bugs/1799760>
[17:48] <mup> PR snapd#6038 opened: release: 2.36 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6038>
[17:52] <Chipaca> zyga: ^^ bug from ogra you might like
[17:54] <ogra> i wont reboot that system ... so whatever else needs to be captured, the machine will stay in that state
[18:52]  * zyga looks
[19:03]  * cachio afk
[20:09] <mup> PR snapcraft#2379 closed: meta: add assumes if using "full" app adapter <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2379>
[20:48] <mup> PR snapcraft#2385 opened: cli: consolidate re-execution <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2385>
[22:52] <mup> PR snapd#6039 opened: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[23:03] <cjwatson> koala_man: I managed to set up a simpler reproduction environment: for me, configuring squid with "client_persistent_connections off", and then running "http_proxy=... strace -f -o cabal.trace -s 4096 cabal fetch pandoc" in a clean sandbox with an empty cabal download cache provokes it often enough to be somewhat debuggable
[23:03] <cjwatson> (the strace is needed to slow it down slightly - I think this is a race between when it tries to write the redirected request to the connection and when it's closed by the other end
[23:03] <cjwatson> )
[23:04] <cjwatson> koala_man: with that I've found that while bionic's cabal-install breaks in the same way (without curl), Debian unstable's (also without curl) seems to work - and it's not just winning the race, because I can see it getting EPIPE/SIGPIPE from write() and then recovering where the earlier version didn't
[23:04] <cjwatson> so that might be something I can bisect
[23:09] <mup> PR snapd#6040 opened: data/apt: close stderr when calling snap in the apt install hook <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6040>
[23:23] <koala_man> cjwatson: this is to patch into HTTP and then rebuild cabal-install against it, thereby minimizing potential side effects?
[23:48] <mup> PR snapcraft#2384 closed: project: do not install base if already installed <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2384>