/srv/irclogs.ubuntu.com/2019/07/29/#snappy.txt

mborzeckimorning05:20
pstolowskimornings!07:06
mborzeckipstolowski: hey, welcome back, well rested?07:18
pstolowskimborzecki: yep! i had great time, thanks07:19
mborzeckipstolowski: nice ;)07:19
pstolowskimborzecki: how was it here?07:20
mborzeckipstolowski: few of us left this week, mvo on vac, pedronis & zyga attending a sprint07:20
mborzeckipstolowski: rather quiet07:20
mupPR snapd#7183 opened: [RFC] many: drop snap.ReadGadgetInfo wrapper <Gadget update> <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7183>07:52
mborzeckiunit tests hanging on travis again, hmm08:07
Chipacahah! finding bugs during a refactor is fun09:04
mborzeckiChipaca: bugs == fun09:08
mborzeckiChipaca: unless they bite, then run09:08
mupPR snapd#7184 opened: daemon: do not modify test data in user suite <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7184>09:08
mborzeckiChipaca: can you take a look ^^ ?09:09
Chipacamborzecki: in a mo'09:14
mborzeckiChipaca: sure, thanks!09:14
mupPR snapd#7185 opened: boot, etc.: refactor boot to have a lookup with different imps <Created by chipaca> <https://github.com/snapcore/snapd/pull/7185>09:14
mborzeckibrb09:32
zygaGood morning09:48
mborzeckizyga: hey09:49
mborzeckizyga: how was the trip?09:49
zygahey09:52
zygamy flight had 3 hour delay because they had to fly in a replacement09:53
zygabut otherwise it was totally uneventful and pleasant09:53
pstolowskihey zyga!09:54
zygahey pawel09:54
zygaguys, a small heads up09:55
zygadespite the sprint I will try to land bug fixes09:55
zygaI think core and ubuntu are green now09:55
zygafedora still has some interactions with lxd that I need to address09:55
zygamy goal is to make https://github.com/snapcore/snapd/pull/7168 landable09:55
mupPR #7168: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168>09:55
zygasorry about the noisy PRs, I'll try to garden them throughout the day09:56
zygaif you need anything from me urgently please use telegram09:56
pstolowskiack09:56
zygaif you don't have me on telegram ping me on IRC, i'll try to check from time to time09:56
Chipacapstolowski: hey! wb :-)10:10
pstolowskiChipaca: o/10:10
pstolowskiChipaca: thanks for helping land some of my PRs while i was off10:10
Chipacapstolowski: sorry we couldn't manage to land them all :)10:11
pstolowskiChipaca: nah, it was better than expected!10:12
pstolowskiChipaca: afaiu the PR about snapd type & snapcraft needs passthrough for now, was this something you discussced & agreed on?10:13
Chipacapstolowski: i think using passthrough was deemed acceptable for now10:14
Chipacapstolowski: but i'm not 100% positive on that10:14
pstolowskik. i'll give it one more try on spread and see if i can find anything before trying passthrough10:15
mupPR snapd#7186 opened: gadget: ensure filesystem labels are unique <Gadget update> <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7186>10:35
ChipacaI like that Fedora Workstation automatically creates a mugshot for your user, based on your initials10:35
ChipacaI particularly like it because, as per my usual approach, the user's name is Fedora User10:36
mborzeckisimple one ^^ pstolowski maybe?10:36
Chipacaso password prompts are like 'FU gimme your password'10:36
Chipacai like distros with attitude10:36
mborzeckihahaha10:37
mborzeckianyone noticed unit tests getting stuck recently?10:39
Chipacanot me10:43
Chipacamborzecki: where?10:43
mborzeckiChipaca: go test ./... as run on travis seems to get stuck randomly, i can't reproduce it locally though10:44
pstolowskimborzecki: yeah i think i've just experienced it on my PR10:54
mborzeckipstolowski: yay10:58
mborzeckipstolowski: did you get a bracktrace by any chance?10:59
pstolowskimborzecki: nope, it was on travis10:59
mborzeckipstolowski: there were some changes recently around socket listen in deamon, i'm suspecting that might be the cause10:59
zygamborzecki: can you try go test with race detector?11:23
mborzeckizyga: nothing comes up11:34
mborzeckizyga: more problems with lxd & unified cgroups https://forum.snapcraft.io/t/lxd-3-15-fails-with-unified-cgroup-hierarchy/12462/1011:39
zygamborzecki: hey11:42
zygalooking11:42
* Chipaca lunches11:47
mborzeckipstolowski: pinged you in https://github.com/snapcore/snapd/pull/718711:55
mupPR #7187: data/selinux: allow snap-confine to read entries on nsfs <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7187>11:55
mborzeckizyga: is this something you saw in your tests too? ^^11:55
mupPR snapd#7187 opened: data/selinux: allow snap-confine to read entries on nsfs <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7187>11:55
=== morphis0 is now known as morphis
zygamborzecki: re12:03
zygamborzecki: I don't believe so but I didn't focus on fedora yet, it's the next pass12:03
zygamborzecki: I didn't get a clean run on fedora yet12:03
mborzeckizyga: ok12:04
zygaI'm working on fixing the fedora leaks now12:18
micahhi, it seems my 'core' is in the state 'broken', how do I fix that?12:26
Chipacazyga: I don't do it this way: https://www.telegraph.co.uk/politics/2019/07/28/dominic-cummings-one-strike-ban-cabinet-leaks-leaked-daily-telegraph/12:26
Chipacamicah: what kernel are you running?12:27
micahseems I needed to remove core and install core12:27
micahChipaca: 4.14.11912:28
Chipacamicah: hm, that should be working fine (5.2 has some issues)12:28
Chipacamicah: how did this happen?12:29
micahChipaca: i dont know how... but it seems when I restart, its broken again12:38
Chipacamicah: can you do: snap info cpre | pastebinit12:39
Chipacaer12:39
Chipacamicah: can you do: snap info core | pastebinit12:39
Chipacamicah: or even better,12:40
Chipacamicah: can you do: snap info --verbose core | pastebinit12:40
micahChipaca: https://pastebin.com/b4dWfzT912:42
ogra"snap version2 too12:42
ograerr12:43
ogra"snap version"12:43
ogra(little weakness of the shift key)12:43
ogra4.14.119 sounds like some random mainline kernel ...12:43
mborzeckiogra: hmm, sounds like an LTS kernel tbh12:44
micahhttps://pastebin.com/2mRCq9K712:45
Chipacamicah: systemctl --all --failed | grep snap  ?12:46
ogramborzecki, well ... 4.14.119-2.pvops.qubes.x86_6412:46
mborzeckiogra: 4.14.119 with qubes patches on top likely12:46
ogramborzecki, definitely not an ubuntu kernel (though this seems to be debian ... but also not a debian archive kernel for sure)12:47
ogramborzecki, sure, but you cant know what config options are set, if the apparmor patches are complete etc12:47
ograit is simply not "some distro standard kernel"12:48
mborzeckiogra: or whether it defaults to selinux like the mainline builds did/do :)12:48
ograyep :)12:49
Chipacaogra: i'm not going to abort any support as soon as the kernel isn't on a known-good list12:49
ograChipaca, i didnt ask that anyne stops supporting ... it is just an important fact to know about during support12:49
ogra*anyone12:49
Chipacamicah: please pastebin the output of that?12:49
micahChipaca: seems systemctl --all --failed | grep snap doesn't give me anything12:52
Chipacamicah: so what's at /snap/core/current ? (try with ls -l)12:52
micahlrwxrwxrwx 1 root root 4 Jul 29 08:27 /snap/core/current -> 727012:52
Chipacamicah: and in 7270?12:53
* Chipaca goes for tea12:53
micahand 7270 is empty12:53
Chipacamicah: does 'systemctl --all | grep snap' give you anything?12:56
micahChipaca: it does12:58
Chipacamicah: can i see?12:59
Chipacapstolowski: cachio: standup?13:01
micahChipaca: https://pastebin.com/pNsjmY9u13:01
Chipacadegville: standup?13:02
Chipacamicah: systemctl status snap-core-7270.mount ?13:10
micahchipaca: https://pastebin.com/hySYpyXv13:10
Chipacamicah: systemctl start snap-core-7270.mount ?13:12
micahChipaca: that seems to start it13:13
micahand 7270 now has things in it13:14
Chipacamicah: ok, systemctl restart snapd.service, to get things back in shape13:17
Chipacamicah: something went wrong somewhere with systemd for that to be broken, but if you don't know what Β―\_(ツ)_/Β―13:18
mborzeckigrr go 1.13 runtime now pokes /sys/kernel/mm/transparent_hugepage/hpage_pmd_size during startup, making selinux complain each time you run snap* command13:18
Chipacastgraber: do you have a link to the 5.3 mount api breakage?13:19
micahChipaca: yeah, definately... too bad I dont know what13:23
Chipacamicah: would be good to know if it's still ok on reboot13:29
micahChipaca: i'll try in a second13:33
Chipacamicah: no rush, we'll be here tomorrow13:34
Chipaca:)13:34
mborzeckihttps://github.com/snapcore/snapd/pull/7187 unit tests hanging on travis again :/13:43
mupPR #7187: data/selinux: allow snap-confine to read entries on nsfs <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7187>13:43
Saviqcachio: hey, would you consider having a `ubuntu-devel` image for spread?13:45
SaviqOur at least build a 1910 one?13:46
Saviq*Or13:46
cachioSaviq, sure13:46
cachioSaviq, but also you can used the one published by canonical13:47
stgraberChipaca: https://lkml.org/lkml/2019/7/26/38813:48
Saviqcachio: could you review our list please https://github.com/MirServer/mir/blob/master/spread.yaml#L14 ?13:49
* Saviq tries to remember why we don't use the official images in the first place…13:50
cachioSaviq, just run: gcloud compute images list --project ubuntu-os-cloud-devel13:51
cachiothis will give you all the devel imags13:51
Chipacastgraber: thanks13:52
cachioyou just can use any of these by doing image: ubuntu-os-cloud-devel/<image-name>13:52
Saviqcachio: thanks, I'll try, I never got gcloud working properly here…13:53
cachioSaviq, https://paste.ubuntu.com/p/z9ckvYwScZ/13:53
cachiotihs is the list of images13:53
Saviqcachio: thanks :)13:53
cachiotake a look and if there is not any image that works for you I can create 1 with the lates changes from devel13:54
cachioSaviq, your spread.yaml seems to be ok13:54
cachiothe ubutnu images that you use are the official ones13:54
mupPR snapd#7188 opened: data/selinux: allow read on sysfs <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7188>13:58
mborzeckipstolowski: heh ^^ another one13:58
micahChipaca: on reboot, same problem14:21
Chipacamicah: ok, look at 'journalctl --system', and look for anything red14:22
micahChipaca: i see nothing red there that is related (some firmware/acpi things)14:23
zygahey, any news?14:26
Chipacamicah: what's systemctl status snap-core-7270.mount ?14:27
Chipacazyga: about what?14:28
zygain general14:28
zygaguys, the go unit tests are flaky14:28
zygacan we see if a branch from last week would be green14:28
zygaI have a feeling it is something we merged mid week14:28
zygais anyone on this?14:28
mborzeckizyga: attempted to reproduce this, but only got this https://github.com/snapcore/snapd/pull/7184 obviously the problem doesn't happen locally (at least for me)14:29
mupPR #7184: daemon: do not modify test data in user suite <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7184>14:29
zygamborzecki: can you try with GOMAXPROCS=214:30
zygaor something "low"14:30
micahChipaca: i put the output of the journalctl --system and the systemctl status into this paste: https://pastebin.com/MknBeW9T14:34
zygamborzecki: the tests that use lxd should reboot to clean up14:38
zygathat's the bottom line from the lxd team14:38
mborzeckizyga: sgtm14:38
zyganot sure how to do it yet14:38
mborzeckizyga: only a handfull of those14:39
zygaI know we have REBOOT and REBOOT_COUNT, need to play with that14:39
mborzeckizyga: i can look into that, there's a REBOOT in a couple of tests I added already14:39
zygamborzecki: thank you14:39
zygaI'll work on other tests14:39
zygathough honestly, right now unit tests being red is more problematic14:40
Chipacazyga: mborzecki: do you have an example run of the tests hanging?14:41
zygano, only in travis14:41
zygamost recent PRs are red14:41
Chipacazyga: that's what i mean14:41
zyga(because of this)14:41
mborzeckiChipaca: https://travis-ci.org/snapcore/snapd/builds/564940409?utm_source=github_status&utm_medium=notification14:41
Chipacazyga: not necessarily because of this14:42
Chipacamborzecki: thanks14:42
ograChipaca, micah, wow, so qubes seems to essentially be a livecd kind of setup (everything readonly, parts of the system are rw bind mounts) ... perhaps some dirs needed by snapd are simply missing (or not there when snapd starts due to races etc)14:42
ogra(it is also interesting that your kernel was built on fedora while your rootfs is debian based apparently ... but thats just a fun fact)14:43
mupPR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>14:45
mupPR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>14:45
micahogra: Chipaca it appears qubes does this to make it work: https://github.com/QubesOS/qubes-app-linux-snapd-helper14:45
mupPR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>14:46
mupPR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>14:46
ograwow https://github.com/QubesOS/qubes-app-linux-snapd-helper/blob/master/qubes-snapd-mount14:46
ograso it re-creates all snap mount units14:47
ogra... on the fly ...14:47
micahshould it have a pre-dependency on something?14:50
micahbecause it seems like in some boots, it works, and some it does not14:50
Chipacamicah: looks like snapd.service should have an after: whatever it is that creates the mounts14:50
ograyeah, my guess would be that snapd is already running while this mount unit recreation still runs14:51
ograit is also rather dangerous what they are doing there, typically snapd creates these mount units ... if anything chenags on the snapd side, the qube script wont pick it up14:52
ogra*changes14:52
ograif they need to chnage the pre-snap mount units, they should better take the original ones as input14:53
ogra*per-snap14:53
ograJul 29 10:32:03 browser systemd[1]: snap-core-7270.mount: Succeeded.14:54
ograJul 29 10:32:03 browser systemd[1]: Unmounted Mount unit for core, revision 7270.14:54
ograJul 29 10:32:03 browser systemd[1]: Started Rebuild the non-persistent snappy systemd mounts.14:54
ograJul 29 10:32:03 browser systemd[1]: Starting Snappy daemon...14:54
ograJul 29 10:32:03 browser systemd[1]: Unmounting Mount unit for firefox, revision 243...14:54
ograJul 29 10:32:03 browser systemd[1]: rw-bind\x2ddirs-snap-firefox-243.mount: Succeeded.14:54
ograthey are definitely stepping on each others toes14:55
ijohnsonhey Chipaca, degville: I'm finalizing a refactoring of the instructions for running spread in HACKING.md, should I make all the text under 80 chars there?14:55
ijohnsonThe file isn't consistent, not sure if we have a style we try to maintain for markdown14:55
Chipacaijohnson: as long as it looks ok in github i don't mind14:57
* Chipaca is not a purist14:57
ijohnsoncool! sounds good14:57
ogramake it 78.5 chars .. the you can still have a terminal scrollbar14:57
ogra:P14:57
ogra*then14:57
Chipacazyga: cpufreq'ed my laptop down to 800MHz and turned off all my cores except 114:58
Chipacazyga: trying to repro the travis thing14:58
zygathank you14:58
ijohnsonogra: how many times have you read markdown from a github repo in a terminal in the past month?14:59
Chipacai haven't had a work machine this slow since the first one i built myself14:59
zyga:D14:59
ograijohnson, every time i used w3m ...14:59
Chipaca200MHz pentium mmx :')14:59
* ijohnson searches what w3m is14:59
micahogra: yeah, that does look like its stepping on itself there... i'm not familiar enough with what is going on here to know what I should do to make this not happen14:59
ograijohnson, (like ... never :P ... and i wa indeed joking)14:59
ijohnsonah got it14:59
degvilleijohnson / Chipaca: It's not my jurisdiction, I'm sure, but editing md in vim is definitely easier for me when it's <80 wide.15:00
ijohnsonhmm, let me see how it looks in GitHub when it's at 80 lines15:01
ijohnsonwe do want to make docs easy for degville to edit :-)15:01
degvilleit should be fine.15:01
degvillethe width shouldn't affect the output.15:01
ijohnsonthose sound like famous last words15:02
degvilleahahaha!15:02
Chipacadegville: in preformatted text it does15:02
Chipacathat is, in ```s15:02
degville^ except that of course :)15:02
ogramicah, well, it would be interesting to know what they try to achieve by duplicating the snap mount units in the first place15:05
ograit also seems their rw-bind script tries to mount the snap dirs rw alongside ... which is pointless given everything is a squashfs anyway15:06
ijohnsonok, what looks better in GitHub: https://github.com/anonymouse64/snapd/blob/feature/HACKING-md-updates/HACKING.md15:08
ijohnsonor https://github.com/anonymouse64/snapd/blob/feature/HACKING-md-updates-unlimited-chars/HACKING.md15:08
ograperhaps systemd is simply clever enough to recognize that this is producing a mess and simply unmounts them all15:08
Chipacaijohnson: ooh, that needs to say 1.9 now15:08
ijohnsonI actually don't see a difference15:09
ijohnsonChipaca: ah you're right15:09
ijohnsonhonestly, the formatting looks the same whether it's 80 chars or not, so I think degville will get to keep easily editing in vim15:09
ijohnsonChipaca: do you know what release of snapd started requiring go 1.9?15:10
Chipacaijohnson: not offhand15:10
Chipacalet me check the logs15:10
ograhuh ? why would vim have anything to do with 80chars ?15:10
mborzeckiChipaca: i got it once with GOMAXPROCS=2 and -count=20, but didn't have GOTRACEBACK set :/15:11
Chipacaijohnson: 2.3815:12
ijohnsonthanks Chipaca15:13
ijohnsonogra: see degville's comment15:13
Chipacaijohnson: that was 'git log' to find #6294, and then 'git tag --contains 618450bb0fb3064a9f310456047993017828556d'15:13
mupPR #6294: packaging/ubuntu: build with golang 1.10 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6294>15:13
ijohnsonhow did you know which PR to look for though?15:14
ograijohnson, we should do some compny wide crowdfunding to pay a proper post-VGA monitor for degville then :)15:14
Chipacaijohnson: I looked for 1\.915:14
ijohnsonah15:14
Chipaca:)15:14
degvilleogra: it's only because I have been used to editing tw=79 for a long time. Probably the only cache size my brain can handle.15:15
ograhaha15:15
micahogra: i'm trying to come up with a clear, concise summary of the problem so I can report it to qubes15:20
micahogra: think this is accurate: "Qubes automounts conflict with Snap mounts, causing snaps not to work and appear broken."15:21
ogramicah, yeah, kind of ... i think whet they should do is to simply "ln -sf /var/lib/snapd/snap /" and just leave the mount units alone15:22
ogra*what15:23
ograănd they shoudl do that linking before any of the mount units or snapd even attempt to start)15:23
micahi see15:24
ijohnsonbtw I think we should update the spread snap to look for the user's real $HOME dir instead of $HOME/snap/spread/current15:24
ograit seems that they do all this re-creation dance just because they do not know if /snap exists or not15:25
Chipacaijohnson: ?15:26
ograthere are other options ... they could pretend they are fedora, then /var/lib/snapd/snap would be the default and snapd would be taking care that the mount units do the right thing ...15:26
ijohnsonwell the HACKING.md says to get spread, you should install the snap, but it also says that you should put images inside $HOME/.spread/qemu15:26
ijohnsonso the instructions don't work if you follow them exactly15:27
ograor they could provide a patch to snapd upstream to put their OS into a list that makes snapd DTRT15:27
ijohnsonyou either need to move qemu images into $SNAP_HOME (or whatever env points there I forget), or you need to export HOME before running spread15:27
ograthough it seems their OS actually pretends to be debian even though it is a derivative of some kind15:28
ograso it might be hard to detect for snapd that you run QubesOS15:28
mborzeckiChipaca: in case you're playing with the unit tests getting stuck, https://github.com/golang/go/issues/2718915:31
Chipacamborzecki: yay15:35
mborzeckiChipaca: heh https://paste.ubuntu.com/p/QGhSdgQWSC/ that's a bit unexpected too15:36
Chipacai'm going to leave this running and go for a run myself15:37
zyganiemeyer: https://forum.snapcraft.io/t/rfc-plug-slot-rules-plug-names-slot-names-constraints/1243915:38
niemeyerTHanks15:38
mborzeckiChipaca: another interesting find https://paste.ubuntu.com/p/yFNJcPBjfg/15:42
Chipacamborzecki: /o\15:43
* Chipaca really goes afk now15:43
mupPR snapd#7189 opened: HACKING.md: update spread section, other updates <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7189>15:43
micahogra: well basically its a debian VM, running under xen15:43
micahogra: could I construct a systemd unit file that just does this symlink and is run before the the mount units or snap units and try and see if that works?15:46
* cachio lunch16:09
mborzeckiChipaca: was about to leave when noticed the tests got stuck: https://paste.ubuntu.com/p/yhGfmdRvj7/16:12
mborzeckileaving for real now :)16:12
mborzeckizyga: ^^16:12
=== pstolowski is now known as pstolowski|afk
micahogra: The rw-bind script just makes sure that the snaps are saved in the appvm storage rather than being lost on shutdown on the appvm16:20
mupPR snapcraft#2646 opened: cli: only say sorry for in-snapcraft issues <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2646>16:23
ogramicah, well, try it (the symlink creation) .. i'd also disable the rewrite unit then16:29
zygaRe17:15
diddledanI'm just installing Windows Insider build 18945 to see what the state of affairs is for snaps now that squashfs is in the shipped kernel17:54
zygadiddledan: I'm running that17:57
diddledan\o/17:57
zygadiddledan: it's not enough but I read that some people managed to run systemd inside a hand-made container17:58
zygadiddledan: and then run snapd inside that17:58
diddledanyeah you need to trick systemd to believe it's pid117:59
mupPR snapcraft#2646 closed: cli: only say sorry for in-snapcraft issues <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2646>18:29
mupPR snapd#7190 opened: tests: set GOTRACEBACK=1 when running tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7190>18:52
diddledansnap version: https://www.irccloud.com/pastebin/VHgAuLOx/19:03
zygadiddledan: neat19:03
zygadiddledan: can you tell me more about how you got that?19:03
diddledanstart systemd with: $ sudo daemonize /usr/bin/unshare -fp --mount-proc /lib/systemd/systemd --system-unit=basic.target19:04
diddledanfind the process id of the unshare process and run $ sudo nsenter -t $SYSTEMD_PID -m -p /bin/login -f dllewellyn19:05
diddledanthen just `snap version`19:05
zyga mmm19:05
zygacan you snap install xkcdwebserver and see it from windows?19:05
diddledanseems to timeout accessing via either localhost or the wsl instance's ip19:08
zygadiddledan: is the service up?19:10
diddledanyup19:10
zygadiddledan: it's a composite test that checks if many things together actually worked19:10
zygacurious, ok19:11
zygathanks!19:11
zygais it on 80 or some other port?19:11
diddledansystemctl status snap.xkcd-webserver.xkcd-webserver.service:  https://www.irccloud.com/pastebin/jhhaJwvU/19:11
diddledanport 8019:11
diddledanthere also seems to be a mono service running but that's from the base image rather than via a snap19:12
diddledantcp        0      0 0.0.0.0:8084            0.0.0.0:*               LISTEN      1289/mono19:12
diddledanthat _does_ respond19:12
diddledangoogler snap (cli for google searches) works19:15
diddledantheloungeirc responds from windows on port 900019:16
zygadiddledan: neat19:16
diddledansomething specific to xkcd is failing tho19:16
zygamaybe port 80 is just "busy" with windows stuff?19:16
diddledanpossibly19:16
mupPR snapd#7191 opened: tests: remove installed snap on restore <Created by zyga> <https://github.com/snapcore/snapd/pull/7191>19:18
diddledanaah, stopping and restarting the service with `snap stop` and `snap start` appears to have disloged the blockage (I was looking to see what the port did on windows side when it was stopped)19:19
diddledanhttps://usercontent.irccloud-cdn.com/file/aB6fZBpA/image.png19:19
diddledanthat's coming from the snap in wsl2!19:19
ijohnsondiddledan: awesome work!19:23
* ijohnson relocates to coffee shop19:23
diddledanwhat's the debugging command to get the confinement status of a system again?19:23
diddledani.e. to output what confinements the snapd is seeing as available for use19:23
diddledanthe one that shows the apparmor flags and stuff19:24
diddledanaha. found it19:26
diddledanhttps://www.irccloud.com/pastebin/w0UFjDgb/19:26
diddledandoesn't support strict confinement yet then19:26
diddledan$ snap debug confinement                                                                                     partial19:27
diddledanhttps://www.irccloud.com/pastebin/EAFDkrva/19:28
zygadiddledan: yeah, that's expected, apparmor is absent19:37
diddledanahem https://usercontent.irccloud-cdn.com/file/bjIkhr6T/image.png20:14
diddledanfrom `snap install pick-colour-picker` :-)20:14
diddledanit doesn't seem to want to respond to clicks tho20:15
zygadiddledan: color pickers probably require X features that are not really emulated correctly on windows20:19
zygadiddledan: very impressive though :)20:19
diddledancalculator works tho: https://usercontent.irccloud-cdn.com/file/XLgwJBtA/image.png20:24
zygadiddledan: how long did it take to start?20:25
diddledannot long20:25
diddledanI didn't really time it20:25
diddledantrying to open it again made putty crash on a malformed ssh packet20:25
diddledansomething funky is happening that kills ssh20:27
diddledanthe same error occurs trying to open gimp (from snap)20:27
diddledanI wonder if that's because I'm going through 127.0.0.120:27
diddledanwhich means Windows is proxying the ssh20:28
diddledanyeah the localhost proxy that MS implemented is breaking SSH20:29
zygadiddledan: you need putty for X redirection?20:30
diddledanit's the easiest way to do it, yeah20:30
zygadiddledan: can you "just" expose X over localhost and not over a unix socket?20:31
zygathough not sure if that's supported for real20:31
zygabut fun experiments regardless20:31
diddledanno, the localhost proxy that allows Windows apps to access Linux sockets is one-directional - i.e. linux bound sockets are propagated to windows, but windows bound sockets aren't exposed to linux20:32
diddledanyou can probably do it over the network though, because it's "just a VM"20:33
zygaah, I see why ssh helps20:33
zygait sets up the pipe20:33
diddledanto achieve that you'd need to expose your X11 server in windows to the network20:33
diddledanyeah, ssh just makes it simpler20:33
mupPR snapd#7188 closed: data/selinux: allow read on sysfs <Simple πŸ˜ƒ> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7188>20:37
mupPR snapcraft#2647 opened: build providers: catch LXD socket error <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2647>20:47
diddledanzyga: of course, no self-respecting Linux user would be without their WINE: https://usercontent.irccloud-cdn.com/file/Musm2Py9/image.png20:54
zygahaha, so that's a wine app on windows?20:54
diddledanit's a snap of wine running notepad++ which is a windows-only app running on wsl2 on windows :-p20:55
diddledanI figured I hadn't seen enough of the movie Inception :-p20:55
zygadiddledan: you should record this :)20:56
zygadiddledan: it's neat20:56
diddledanit's freaking bananas!20:57
diddledanI tried a couple OpenGL games but the X11 server I'm using only supports OpenGL 1.4 and they all require OpenGL 2.0+20:58
=== lborda is now known as lborda_afk
diddledanwat: editing windows and linux files from within a windows app running in linux: https://usercontent.irccloud-cdn.com/file/agBv7vhv/image.png21:03
diddledanI'm confused21:03
mupPR snapd#7192 opened: tests: Initial change to retry on external files download <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7192>21:14

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