[05:37] <zyga> good morning
[06:34] <mborzecki> morning
[06:34] <mborzecki> starting a bit later today, had to take my wife's car to the shop
[06:37] <mup> PR core18#31 opened: hooks: move 003-writable-paths.chroot to static/etc/system-image <Created by mvo5> <https://github.com/snapcore/core18/pull/31>
[06:43] <mvo> hey mborzecki - good morning
[06:44] <mborzecki> mvo: hey
[06:44] <mborzecki> any fires today?
[06:44] <mup> PR core18#32 opened: writable-paths: add needed paths for cloud-init <Created by mvo5> <https://github.com/snapcore/core18/pull/32>
[06:46] <mvo> mborzecki: no fires, I'm a little bit frustrated with core18 in gce, spread tests does not work there yet but they work fine in qemu and I'm scratching my head why
[06:46] <mvo> mborzecki: but no fires afaict
[06:47] <mborzecki> mvo: hmm that's interesting, anything in particular that fails int he tests? or does it not boot at all?
[06:47] <mvo> mborzecki: it boots and cachio pasted me the console output which looks fine (for some reason I don't have enough access in the gce console to see it myself). so I think it does not get network
[06:48] <mborzecki> mvo: do the new images use netplan or sth?
[06:48] <mvo> mborzecki: yeah, it is, it *should* be the same config as the core16
[06:48] <mborzecki> mvo: interface naming then?
[06:48] <mvo> mborzecki: my current straw is that cloud-init is not working yet on core18 and maybe it is doing some magic here
[06:49] <mvo> mborzecki: its a pretty generic config, one sec, let me find it
[06:49] <mvo> mborzecki: https://github.com/snapcore/core18/blob/master/static/etc/netplan/00-snapd-config.yaml
[06:50] <mborzecki> mvo: looks pretty straightforward
[06:50] <mvo> mborzecki: yeah, I need to learn if I can get a OOB shell with gce somehow
[06:50] <mborzecki> mvo: there is a dhcp client in the image?
[06:50] <mvo> mborzecki: systemd-networkd
[06:51] <mvo> mborzecki: I don't think there another
[06:51] <mborzecki> mvo: ok, that should be fine, networkd does it's own dhcp
[06:52] <mvo> mborzecki: yeah
[06:52] <mborzecki> mvo: hm you could try and ship your own config file for networkd in case netplan doesn't do it's thing
[06:53] <mvo> mborzecki: thats an interessting idea
[06:59] <mborzecki> heh, got another update to shellcheck, now it complains about not quoting variables when sourcing files, iirc this wasn't strictly needed
[06:59] <mvo> mborzecki: heh
[06:59] <mvo> mborzecki: nice find on your latest shellcheck PR in the framebuffer test
[07:00] <mborzecki> mvo: yeah, looking into it right now
[07:00] <mvo> mborzecki: shell is just not the best language, really good we run the checker now
[07:00] <mvo> mborzecki: I wish there was something like "-o strict" or somesuch that would at least protect against all the basic mistakes. anyway
[07:01] <mborzecki> mvo: shperl
[07:02] <mvo> mborzecki: heh
[07:06] <mvo> mborzecki: btw, gustavo added some comments to github.com/go-check/check https://github.com/go-check/check/pull/100
[07:06] <mup> PR go-check/check#100: many: return kr/pretty:Diff when Equals/DeepEquals check fails <Created by mvo5> <https://github.com/go-check/check/pull/100>
[07:07] <mvo> mborzecki: the first question about "if result { clear error message" is from your diff, this is a test failing, right? I wonder if we should test this more explicitly, wdyt?
[07:07] <mborzecki> mvo: ah interesting, i can look into this later
[07:08] <mvo> mborzecki: thank you, I will look at his other points
[07:08] <pstolowski> morning
[07:09] <mvo> hey pstolowski
[07:11] <mborzecki> mvo: ok, i think i remember now, there may not be an explicit test for this, but the clearing was added there to prevent the Not() checker from raising false positives
[07:12] <mborzecki> mvo: a vague recollection, that if you did say, Not(DeepEqual()) and the Not checker left the error message intact it would still come up as an error in the tests
[07:13] <mborzecki> zyga: how's your SLED work?
[07:13] <zyga> Stuck
[07:13] <zyga> Look at that twitter post
[07:16] <mborzecki> zyga: boo :(
[07:18] <mborzecki> zyga: slightly surprised those are still behind paywall
[07:22] <zyga> well, those are like RHEL
[07:22] <zyga> but... I have a license
[07:22] <zyga> something is wrong on the website
[07:23] <mborzecki> https://forum.snapcraft.io/t/nvidia-cuda-on-ubuntu-core/292/24 heh, nice pattern from nvdiia
[07:24] <mborzecki> ioctl(12, _IOC(_IOC_READ|_IOC_WRITE, 0x41, 0x2, 0x18), 0xbeb00fc0) = 0 this does some magic
[07:24] <mborzecki> and works outside of snap
[07:24] <mborzecki> but inside it fails, the driver apparently trues to do another little poke ioctl(12, _IOC(_IOC_READ|_IOC_WRITE, 0x41, 0x3, 0x10), 0xbee73f28) = -1 EINVAL
[07:25] <mborzecki> in either case, the device accessed is open("/dev/nvhost-as-gpu", O_RDWR|O_DSYNC) = 12
[07:27] <mup> PR core18#31 closed: hooks: move 003-writable-paths.chroot to static/etc/system-image <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/31>
[07:47] <zyga> I'm looking into opensuse releases
[07:47] <zyga> something is not working well on LEAP
[07:47] <zyga> and this is blocking a high-priority snap apparently
[08:15] <mborzecki> zyga: when a device is not in device group, then will open() fail? or would other operations, eg. ioctl() fail but open() will succeed?
[08:15] <mborzecki> s/group/cgroup/
[08:15] <zyga> I believe open would fail, yes
[08:16] <mborzecki> hmm, i'm thinking about that nvidia on ubuntu core on TK1 problem, the snap is accessing some special devices there, eg. /dev/nvhost-as-gpu and ioctl() fails, but open() works
[08:17] <mborzecki> zyga: we don't seem to add any of those devices, but it's likely that the board is runnign some old(ish) kernel, maybe without device cgroup even
[08:38] <zyga> mborzecki: we need to further differentiate leap and tumbleweed
[08:38] <zyga> :/
[08:38] <zyga> 42.3 cannot use any apparmor
[08:38] <zyga> leap 15 and tumbleweed can
[08:38] <mborzecki> zyga: what's missing there?
[08:39] <zyga> apparmor userspace is at 2.10
[08:39] <zyga> that's far too old
[08:39] <zyga> it cannot even parse our snap-confine profile
[08:40] <mborzecki> well, we don't have much choice then
[08:41] <zyga> I will check leap 15 to be sure
[08:41] <zyga> and then patch this in the distro
[08:41] <zyga> and then send the patches to master
[09:06] <mborzecki> hm the framebuffer test was probably not executing on ubuntu-* because there's no /dev/fb* node
[09:07] <mborzecki> then on others, it was just an echo due to missing "
[09:07] <zyga> yeah
[09:07] <mborzecki> and looks like write to a frame buffer is hitting a region outside of available memory, hence 'file too large' error
[09:17] <zyga> I'm building 2.33 opensuse packages here https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd
[09:17] <zyga> I will be patching that as I get builds and test them on my machines
[09:18] <zyga> but now I need to go and pick up a package from downtown, I will commit my apparmor work and continue on the way there
[09:37] <zyga> hmm
[09:37] <zyga> tests fail on opensuse
[09:37] <zyga> failed test in the state somewhere https://www.irccloud.com/pastebin/Aeu5glwF/
[09:37] <mborzecki> fun fact, ubuntu-{16.04,18.04,-core-16} do not have /dev/fb so the apparmor rules are not really tested anywhere
[09:39] <Son_Goku> :D
[09:39] <Son_Goku> fun fact, fun facts aren't usually fun
[09:39] <mborzecki> barrels of fun ;)
[09:40] <Chipaca> Son_Goku: fun fact: ketchup was once medicine
[09:40] <Son_Goku> Chipaca, really?
[09:41] <Chipaca> well, sold as such
[09:41] <Son_Goku> that's actually an interesting fact, if that's true
[09:41] <Chipaca> (but then so was cocaine)
[09:41] <Son_Goku> well, _that_ I knew
[09:41] <mborzecki> Chipaca: so was mercury
[09:42] <Chipaca> also fun fact: tin (can) openers were invented 48 years after food was being canned
[09:42] <Chipaca> in the interim people just stockpiled the stuff*
[09:42] <Chipaca> * may not be true
[09:42] <pedronis> Chipaca: hi, I'm working on exposing publisher,  am I confused? we don't seem to have a test that checks the details of unmarshaling  of search results
[09:43] <pedronis> (the last thing using details.go)
[09:43] <Chipaca> pedronis: it's probably covered indirectly, but probably no unit tests
[09:44] <mborzecki> another fun fact, our 16.04 image has minix module loaded even before the test using that module starts
[09:44] <Son_Goku> wut
[09:44] <pedronis> Chipaca: I mean store_test.go (I know we don't have details_test.go), I don't see the indirect bit either but maybe I'm confused
[09:44] <Son_Goku> mvo, do you know when 2.33.1 is going to be tagged?
[09:44] <Chipaca> pedronis: 1 sec
[09:45] <mborzecki> along with xfs, ntfs, hfs, qnx4 and so on :?
[09:45] <Son_Goku> qnx4?!
[09:45] <Chipaca> mborzecki: something is trying really hard to mount a filesystem
[09:45] <Chipaca> maybe the gce initrd?
[09:46] <mborzecki> Chipaca: no clue
[09:46] <mborzecki> well, fwiw the rmmod-or-not part of the test did not work before shellchecks and it would always rmmod it
[09:48] <Chipaca> pedronis: it seems you're correct, there are individual tests for specific aspects of details, but nothing whole hog
[09:48] <pedronis> Chipaca: I suppose I should add something, maybe its own PR tough
[09:48] <Chipaca> kjackal: that's a lot of yous
[09:49] <Chipaca> pedronis: ok
[09:49] <Chipaca> I should go do some work on my back an' stuff
[09:49]  * Chipaca very comfy tho
[09:50] <pedronis> Chipaca: probably your info branch removed a details one that can reuse
[09:50] <pedronis> *that I can reuse in some form
[09:50] <Chipaca> pedronis: I like your optimism :-)
[09:50] <pedronis> heh, I do think we had some tests (but with /details apparently)
[09:51]  * pedronis is hopeful
[09:52] <Chipaca> Son_Goku: last fun fact for a while: colgate beef lasagne didn't sell well
[09:52]  * Chipaca ~> physio
[09:52] <Son_Goku> I'm going to go with "eww" for that
[09:53] <Chipaca> a solid choice
[09:53]  * Chipaca ~> really afk now
[10:16] <mvo> zyga, sil2100: a quick look at #32 (in core18) would be great
[10:17] <zyga> Ack
[10:17] <sil2100> mvo: on it now
[10:18] <mvo> sil2100: thank you
[10:20] <sil2100> Ah, already saw it in the morning, didn't manage to +1 it then
[10:21] <mup> PR core18#32 closed: writable-paths: add needed paths for cloud-init <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/32>
[10:21]  * mvo hugs sil2100 
[10:38] <joc> zyga: are new interface PRs waiting on 2.33 going out before landing? just checking not waiting for anything from me
[10:38]  * zyga is in the underground
[10:39] <zyga> They are waiting for jdstrand
[10:39] <zyga> He is off this week
[10:40] <zyga> I think 33 is branched already so there is nothing blocking master
[10:50] <joc> zyga: the PR has your and Jamie's +1s but the tests have not yet run successfully, looks like there was provisioning error
[10:56] <zyga> I’ll look into it soon
[10:56] <zyga> Returning home now
[10:58] <mborzecki> zyga: do you remember if firmware loading is done directly in the kernel now or still through a udev helper?
[11:00] <mup> PR snapcraft#2160 closed: many: refactor snapcraft.yaml loading out of load_config <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2160>
[11:07] <mborzecki> zyga: pinged you in the forums, there's an interesting case regarding firmware loading and interaction with mount namespace
[11:10] <zyga> mborzecki: replied there
[11:11] <zyga> mborzecki: as for firmware loading, it AFAIK changed from userspace to kernel but I could be wrong and it could be backwards
[11:11] <zyga> mborzecki: given that it fails I suspect it's userspace and the firmware cannot be found
[11:11] <mborzecki> idk, haven't touched that really since 2.6.x days
[11:11] <zyga> mborzecki: also on core vs classic?
[11:11] <mborzecki> zyga: the topic is about core
[11:11] <zyga> mborzecki: on core, unless you use bases, you are using the same filesystem as before
[11:12] <zyga> there's a mount namespace but it is largely the same
[11:12] <mborzecki> zyga: confinement-options:  classic devmode
[11:13] <zyga> that's ... weird
[11:13] <zyga> classic devmode is meaningless
[11:13] <zyga> does it work outside of a snap
[11:13] <zyga> ?
[11:13] <mborzecki> zyga: the thing works outside of snap
[11:13] <zyga> strace it
[11:13] <mborzecki> zyga: and if you start the app outside of snap, then it will work inside too
[11:13] <mborzecki> zyga: there's starce logs attached 2-3 messages up
[11:14] <zyga> ah, let me see then
[11:16] <zyga> mborzecki: well
[11:16] <zyga> confinement options is what is *supporteD*
[11:17] <zyga> not what is used
[11:17] <zyga> mborzecki: so this could be a strict snap
[11:17] <zyga> but I see there's no apparmor at all
[11:17] <mborzecki> zyga: ther's no aa
[11:17] <zyga> so it's somewhat meaningless
[11:18] <zyga> some funky errors at the end of snap_directly_log.txt https://www.irccloud.com/pastebin/qOLUGDob/
[11:18] <zyga> note that it closes -1
[11:18] <zyga> probably missing error checking
[11:20] <zyga> mborzecki: is there /dev/nvidiactl inside the cgroup?
[11:20] <zyga> (device cgroup)
[11:21] <mborzecki> zyga: yes, we add it, we're adding nvidiactl, nvidia-uvm, nvidia-modeset and then some nvidia<num> devices
[11:22] <zyga> 1811  open("/dev/shm/cuda_injection_path_shm", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[11:22] <zyga> this looks related
[11:23] <zyga> is it there on the outside?
[11:23] <mborzecki> zyga: don't know, i don't have access to this host
[11:23] <mborzecki> zyga: it's also funny taht if you run the app outside once, it will work inside the snap too
[11:23] <zyga> until reboot, right?
[11:24] <zyga> please ask for a strace -f, after reboot, of the app running _outside_
[11:24] <zyga> then for a similar strace but on the inside, also after reboot (where it will fail)
[11:24] <zyga> if we have that we can investigate
[11:25]  * zyga is about 10-20 minutes away from home
[11:25] <zyga> cannot wait to get back really
[11:25] <zyga> it's so damn hot today
[11:25] <zyga> my son's computer broke and I had to get a part that was faulty
[11:26] <zyga> he needs it for classes today
[11:26] <mvo> niemeyer: hey, good morning. could you give me permission so that I can see "jun191112-575930" in GCE? I would love to see the terminal and ideally login if possible (there is a problem with getting the network working right now on core18 so an oob login would be great to figure out what is going on)
[11:26] <zyga> mvo: ouch, still fighting that?
[11:26] <zyga> mvo: did you look at diffing /etc between core18 and core?
[11:26] <mvo> zyga: yeah
[11:26] <mborzecki> zyga: btw. notice that there's a log in dmesg that getting firmware failed, given that it's kepler, iirc those already required a blob to work
[11:26] <zyga> it may be something that was added to current system
[11:26] <mvo> zyga: I poked around a bit, added some more cloud-init bits
[11:27] <zyga> mvo: and something in /etc/modules.d or modprobe.d?
[11:27] <zyga> mborzecki: it would be good to ask some nvidia people how this is supposed to work
[11:28] <zyga> it's a bit silly that when you want to use the hardware then each app actually goes to load firmware into the hardware
[11:28] <mborzecki> zyga: i bet many people in open source had the same thought :)
[11:28] <mborzecki> zyga: i think it's the first use
[11:28] <mvo> zyga: not afaict
[11:28] <zyga> m
[11:28] <mvo> zyga: it might be something silly
[11:28] <mborzecki> zyga: so you try to do something with the hardware for the first time and the driver goes to load the firmware
[11:28] <mvo> zyga: but without access to the machine its hard to diagnose :/
[11:28] <zyga> yeah
[11:29]  * mvo gets lunch instead
[11:31] <zyga> mvo: netplan has
[11:31] <zyga> mvo: netplan has two patterns, one matches en* and the other matches eth*
[11:31] <zyga> maybe on a newer core you get veth or something silly like this
[11:31] <zyga> becuase newer systemd
[11:31] <zyga> and then stuff falls apart
[11:31] <zyga> suggestion
[11:32] <zyga> as a hack change /etc/netplan/00-snapd-config.yaml
[11:32] <zyga> and mach on *
[11:32] <zyga> fingers crossed
[11:33]  * zyga walks home, cannot wait to have A/C next season 
[11:36] <mborzecki> zyga: there's 19C in oslo right now, ever considered moving?
[11:37] <Chipaca> oslo with 19C must be melting
[11:38] <zyga> Hahah
[11:38] <zyga> Well, I’m not *that* crazy
[11:38] <Chipaca> zyga: [citation needed]
[11:44] <mborzecki> pedronis: shall we land #5314 once it's green?
[11:44] <mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
[11:46] <mup> PR snapd#5334 closed: tests: show executed tests on current system when a test fails <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5334>
[11:47] <zyga> Chipaca: hehe :)
[11:47]  * zyga is home now
[11:47] <zyga> geez, outside is not fun
[11:48] <pedronis> mborzecki: you should ask mvo if there is something high prio from him that could conflict
[11:48] <mborzecki> mvo: is there?
[11:49] <mborzecki> i can help resolving conflicts if needed
[11:49] <mup> PR snapd#5344 opened: store: have a basic test about the unmarshalling of /search results <Created by pedronis> <https://github.com/snapcore/snapd/pull/5344>
[11:49] <pedronis> Chipaca: ^ , not beautiful but better than nothing
[11:50] <Chipaca> will look in a bit
[11:50] <Chipaca> currently reviewing shellcheck
[11:52] <mborzecki> Chipaca: thank you!
[11:58] <zyga> mvo: any luck with that etherent change?
[12:04] <Chipaca> mborzecki: don't thank me until the fat lady sings
[12:04] <Chipaca> I ask Questions
[12:07] <mborzecki> Chipaca: right, i might as well cleanup the \- now that i'm doing the changes anyway
[12:08] <mborzecki> Chipaca: looks like it was copy pasted pretty much everywhere :P
[12:08] <Chipaca> mborzecki: I understand it's easier to think of it as a pure shellchecking change, but yeah
[12:08] <Chipaca> I'd have to read the docs on too many things to find out if that \- actually matches what we want it to match
[12:09] <Chipaca> mborzecki: there's also a bunch of the PWD ones
[12:19] <niemeyer> mvo: Heya, yeah, can definitely do it
[12:20] <cachio> zyga, hey
[12:20] <zyga> hey
[12:20] <cachio> interfaces content if failing sporadically https://api.travis-ci.org/v3/job/393533314/log.txt
[12:20] <zyga> checking
[12:20] <cachio> did you see that one?
[12:21] <zyga> cachio: yes,
[12:21] <zyga> it's not related to content really
[12:21] <zyga> it's related to mount exploiding
[12:21] <zyga> - Mount snap "test-snapd-content-slot" (2) ([start var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount failed.
[12:21] <zyga> See "systemctl status "var-lib-snapd-snap-test\\x2dsnapd\\x2dcontent\\x2dslot-2.mount"" and "journalctl -xe" for details.
[12:22] <zyga> Jun 18 09:29:29 arch snapd[12112]: Jun 18 09:29:28 arch kernel: print_req_error: I/O error, dev loop3, sector 0
[12:22] <zyga> there's a thread about it
[12:22] <cachio> zyga, ah, ok, good to know
[12:22] <cachio> tx
[12:22] <zyga> https://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/5682
[12:23] <pedronis> mborzecki: sorry, I  just merged something that probably needs a remerge for your PR
[12:23] <mup> PR snapd#5344 closed: store: have a basic test about the unmarshalling of /search results <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5344>
[12:24] <pedronis> Chipaca: I got a +1 from zyga, happy to tweak in a follow up though if you find something that merits changes
[12:34] <Chipaca> pedronis: LGTM
[12:34] <Chipaca> pedronis: also thank you for updating the json
[12:34] <pedronis> Chipaca: which reminds me, we can remove MockDetailsJSON
[12:34] <pedronis> but something of another PR
[12:35] <pedronis> s/of/for/
[12:36] <Chipaca> pedronis: there's a lot of unused stuff, according to 'unused'
[12:37] <Chipaca> pedronis: I can propose a removal pr in a bit :)
[12:37] <pedronis> thx
[12:40] <CyberShadow> Hello. I submitted two pull requests last August, and got 0 feedback. Could someone please have a look at them?
[12:40] <CyberShadow> https://github.com/snapcore/snapd-xdg-open/pulls?q=author%3ACyberShadow
[12:40] <zyga> CyberShadow: hello
[12:41] <zyga> I think that repository is dead now, let me see
[12:41] <zyga> we should archive it
[12:41] <zyga> we re-wrote that code significantly since
[12:41] <CyberShadow> I found the software useful for use outside of snaps. How do you solve that problem now?
[12:42] <zyga> let me show you
[12:43] <zyga> https://github.com/snapcore/snapd/tree/master/userd
[12:43] <zyga> https://github.com/snapcore/snapd/blob/master/userd/launcher.go this is what the old code did
[12:43] <mup> PR snapd#5345 opened: store: drop unused: channel map types, and details fixture <Created by chipaca> <https://github.com/snapcore/snapd/pull/5345>
[12:44] <Chipaca> pedronis: ^ +0 -115 :)
[12:44] <zyga> CyberShadow: this runs on the outside and sits on the bus
[12:44] <zyga> CyberShadow: the one that runs on the inside ...
[12:45] <zyga> CyberShadow: is here https://github.com/snapcore/snapd/blob/master/cmd/snapctl/main.go#L50
[12:46] <zyga> and more completely here: https://github.com/snapcore/snapd/blob/master/xdgopenproxy/xdgopenproxy.go
[12:46] <mvo> cachio: is there a way to log into a gce instance when there is no ssh/network ? some magic via serial console etc?
[12:46] <CyberShadow> I see, thanks! So you consolidated everything into one daemon rewritten in Go.
[12:47] <zyga> CyberShadow: one codebase, there's more than one process
[12:47] <CyberShadow> I think I'll maintain my fork of the old snapd-xdg-open then, it's still useful with Firejail/Bubblewrap.
[12:47] <zyga> CyberShadow: I will close your PRs now, sorry
[12:47] <CyberShadow> Right, that hasn't changed.
[12:47] <CyberShadow> No problem. Consider adding a note that the repository is EOL.
[12:47] <cachio> mvo, you should to send all the info to the console, then we can check that
[12:48] <cachio> mvo, let me research a bit about other ways to do it
[12:48] <mborzecki> zyga: github allows repos to be archived now, no clue though who can mark that one as such
[12:48] <zyga> mborzecki: yeah, I know
[12:48] <zyga> mborzecki: I will ask during the standup
[12:53] <Chipaca> CyberShadow: if the two bits were still go but separate, would you contribute to them?
[12:53] <Chipaca> CyberShadow: or is the hacky aspect of the previous incarnation part of their appeal :)
[12:54] <zyga> kyrofa: https://forum.snapcraft.io/t/update-all-python-snaps-not-working-with-classic-confinement-even-with-cleanbuild/5971
[12:55] <Chipaca> CyberShadow: I ask because the new things support stuff the old ones do not, like apps autostart
[12:55] <Chipaca> so there might be value in them for you as well
[13:02] <CyberShadow> Chipaca: Sure, language doesn't matter
[13:02] <CyberShadow> Sorry, I'm not sure how autostart fits in with the Firejail/Bubblewrap flow...
[13:03] <Chipaca> CyberShadow: I don't know either :)
[13:04] <Chipaca> CyberShadow: how would an app go around setting up autostart in that world?
[13:04] <CyberShadow> It doesn't, it's something that would break encapsulation :)
[13:05] <CyberShadow> The user would need to do that manually. They would need to create the container manually too, so it's not unexpected.
[13:11] <Chipaca> CyberShadow: I'll raise separating it in the standup
[13:11] <Chipaca> CyberShadow: is it the inside-the-container thing that you use, or the outside one, or both?
[13:12] <CyberShadow> Both
[13:12] <Chipaca> k
[13:12] <CyberShadow> Here is the user-facing documentation: https://wiki.archlinux.org/index.php/Bubblewrap#Opening_URLs_from_wrapped_applications
[13:13] <CyberShadow> Just to clarify, I think everyone involved would be quite happy with maintaining a fork, so don't feel obligated to support this use case :)
[13:14] <mup> PR snapd#5345 closed: store: drop unused: channel map types, and details fixture <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5345>
[13:14] <Chipaca> CyberShadow: yep yep
[13:14] <Chipaca> CyberShadow: the old one was attractively simple so I get that
[13:31] <Son_Goku> CyberShadow, I suggest renaming the application, but yeah, go for it
[13:32] <CyberShadow> Good idea :)
[13:32] <Son_Goku> CyberShadow, talk to the guys in #atomic about hosting the program under their banner
[13:32] <Son_Goku> that way it sits adjacent to bubblewrap ;)
[13:39] <CyberShadow> True, though it looks like they have their own higher-level snapd equivalent to use with Flatpak (which uses Bubblewrap): https://github.com/flatpak/xdg-desktop-portal
[13:40] <Son_Goku> CyberShadow, well, that's why I suggested projectatomic and not flatpak org ;)
[13:40] <CyberShadow> Ah, right
[13:47] <Chipaca> CyberShadow: the conclusion in the standup is that most of the new features are very snap-specific in their approach, and maybe it's not that useful outside of this
[13:47] <Chipaca> CyberShadow: so fork away, with our blessing
[13:47] <CyberShadow> Thanks!
[14:00] <pedronis> mvo: I'll be a couple of minutes late
[14:01] <zyga> ah, the core18 meeting is still in 29 minutes
[14:01] <zyga> I thought it was back to back
[14:02] <pedronis> ah, same, was confused
[14:21] <zyga> uh
[14:21] <zyga> I ran out of disk space
[14:21] <zyga> sigh
[14:21]  * zyga moves stuff around
[14:24]  * ogra_ hands zyga a paperbasket
[14:24]  * zyga throws lumps of lead and cement inside
[14:24] <ogra_> *thump*
[14:24] <zyga> look, the bucket is now a pipe
[14:30] <mvo> niemeyer: the compute.instances.reset permission for image debug would be great
[14:34] <zyga> downloading chrome
[14:39] <mborzecki> mvo: will landing #5314 conflict with any stuff that you have open atm?
[14:39] <mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
[15:06] <mvo> mborzecki: its fine, I will deal with any conflicts
[15:07] <niemeyer> mvo: (done, for our record)
[15:18] <mvo> niemeyer: thank you (also for the record ;)
[15:18] <zyga> I must say that the google meet thing has better video quality
[15:18] <zyga> or mvo changed his camera to some high-def one
[15:18] <zyga> it looked much sharper than before
[15:21] <zyga> I will break for dinner now, back in one hour when I also have my disk space free
[15:58] <mvo> mborzecki, pstolowski: hey, I got a question about the new snapd.seeded service and I think I need help looking at this. the issue is https://pastebin.canonical.com/p/thJBrCX4wr/ i.e. it looks like this starts too early for some reason. do you think one of you have some minutes (tomorrow is fine too) to look into it?
[16:29] <pstolowski> mvo: sure, i can look at it tomorrow
[16:38] <sergiusens> niemeyer: hi there, are you joining?
[16:39] <niemeyer> sergiusens: Yep, sorry
[16:46] <zyga> mvo: is 2.33 in general a go?
[16:47] <zyga> or are there any issues warranting a .1
[16:57] <mvo> zyga: no issues but we will most likely do a .1 to fix some autopkgtests in the distro
[16:57] <zyga> only autopkgtests?
[16:57] <mvo> zyga: but no real issues, all tests related
[16:57] <zyga> ok
[16:58] <zyga> good, I'll make sure we can release to opensuse tomorrw
[16:58] <mvo> zyga: thank you
[16:58] <zyga> and I need to buy a disk or a NAS maybe
[16:58] <mvo> zyga: if you want we can coordinate with a .1
[16:58] <zyga> sure, that's fine
[16:58] <zyga> changing the tarsal is all we need I suspect
[16:58] <zyga> though
[16:58] <zyga> we can merge my packaging fixes for .1 too
[17:13] <mvo> cachio: interessting datapoint - I just got a econnreset test failure where we got a 503 from fastly
[17:14] <zyga> hmm, any gas recommendations
[17:14] <zyga> NAS
[17:14] <zyga> silly spellchecker
[17:36] <mvo> pstolowski|afk: thank you, lets talk tomorrow, I will forward you two mails about it
[17:36] <mvo> zyga: depends on how much you want to hack it :)
[17:37] <cachio> mvo, do you have any log?
[17:38] <mvo> cachio: I have it still open, I can save/pastebin it
[17:38] <cachio> mvo, yes please
[17:39] <mvo> cachio: http://paste.ubuntu.com/p/x58ZnRZW3Y/
[17:40] <cachio> mvo, do you have the error itsrf?
[17:46] <mvo> cachio: this is the full log http://paste.ubuntu.com/p/2PryTk8nZs/
[17:46] <cachio> mvo, tx
[17:48] <cachio> mvo, I don't see any error
[17:52] <mvo> cachio: uh, sorry, hold on
[17:55] <mvo> cachio: http://paste.ubuntu.com/p/GjXcPvxmPF/ this is hopefully the right one this time
[17:56] <mvo> yay, core18 spread did a successful run (with a single test) in gce - cleanup of this tomorrow
[17:57] <cachio> mvo, nice
[17:57] <cachio> it received a 503 and didn't retry
[17:58] <cachio> and also failed to kill the snap download process
[18:03] <cachio> mvo, well, the ShouldRetryError method is not returning true if it receives a 503
[18:04] <cachio> it is retrying on timeout, syscall.econnreset, dial error and unexpectedEOF
[18:05] <cachio> pedronis, is it ok? should er retry the download when we get a 503 from the cdn?
[18:05]  * zyga thinks the idea is "if the user would retry, so should we'
[18:06] <cachio> zyga, in this case we should change the ShouldRetryError to support other errors
[18:07] <cachio> this is why in some cases the econnreset is not downloading the snapd
[18:07] <cachio> snap
[18:07] <cachio> ans it is not retrying neither
[18:08] <cachio> mvo, thanks for the logs, it was really usefull
[18:18] <mvo> cachio: my pleasure
[18:19] <mborzecki> zyga: qnap or netgear maybe? i personally have netgear, had to rma it once because the eth port got burned, i've sent them ethtool output, and sent me another unit
[18:20] <zyga> I think I will just buy a HDD for now
[18:20] <zyga> nas boxes look very expensive
[18:20] <zyga> and I would like to actually use the one I've built some time ago (it's not something I can use today because it has old / crappy drives)
[18:20] <mvo> zyga: I got a relatively cheap synology
[18:20] <mborzecki> zyga: yeah you buy a box, then the disks, it adds up :)
[18:20] <zyga> (I built an ivy bridge i3 box with 5 HDD cages on backplane)
[18:21] <zyga> the problem with that box is that it weighs a lot and is not a mobile in any way
[18:21] <zyga> and I want something I can take with my laptop next month
[18:21] <zyga> anyway, I'll just get a USB HDD
[18:21] <zyga> not perfect
[18:21] <zyga> but yeah, low cost
[18:28] <cachio> I see the error in the code
[18:29] <cachio> mvo, why it is not retrying in 50X
[18:35] <cachio> mvo, core snap 2.33 in stable channel
[18:37] <noise][> cachio: will you be updating the forum post? (https://forum.snapcraft.io/t/snapd-2-33-release-cycle-started/5585)
[18:38] <cachio> noise][, yes
[18:38] <cachio> noise][, let me complete the smoke test
[18:42] <zyga> \o/
[18:43] <mvo> cachio: yay, thank you
[18:43] <mvo> cachio: iirc the idea behind not retry on 500 was that sometihng is broken on the server
[18:43] <mvo> cachio: but if its a real world scenario maybe we need to rethink that
[18:43] <zyga> mvo: but the CDN is ... big
[18:43] <zyga> so maybe retrying is sensible
[18:43] <zyga> another server might just work
[18:43] <mvo> zyga: yes
[18:44] <cachio> zyga, mvo https://paste.ubuntu.com/p/Tx9WgCW9nR/
[18:45] <cachio> based on ShouldRetryHttpResponse we should retry
[18:45] <mvo> cachio: yes, I remember this code
[18:45] <cachio> but based ton ShouldRetryError we shouldn't
[18:46] <cachio> so we never check the response becasuse we don't retry and break based on the errorr
[18:46] <cachio> mvo, is it ok?
[18:47] <mvo> cachio: yeah, we probably just need to update ShouldRetryError
[18:48] <cachio> mvo, ok
[20:13] <gouchi> hi
[20:13] <gouchi> to test the fix for  https://forum.snapcraft.io/t/nvidia-gl-libs-access-broken-on-ubuntu-18-04
[20:14] <gouchi> I need to update snapd or using core snap to edge branch is enough ?
[20:28] <pedronis> cachio: that code doesn't expect a 503  to reach ShouldRetryError, we are probably misunderstanding something about the library
[21:10] <mup> PR snapcraft#2162 opened: tests: new codespell, narrowed checks and better execution order <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2162>
[21:46] <mup> PR snapcraft#2163 opened: tests: add lifecycle ordering tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2163>