/srv/irclogs.ubuntu.com/2018/06/19/#snappy.txt

zygagood morning05:37
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
mborzeckimorning06:34
mborzeckistarting a bit later today, had to take my wife's car to the shop06:34
mupPR 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:37
=== chihchun_afk is now known as chihchun
mvohey mborzecki - good morning06:43
mborzeckimvo: hey06:44
mborzeckiany fires today?06:44
mupPR core18#32 opened: writable-paths: add needed paths for cloud-init <Created by mvo5> <https://github.com/snapcore/core18/pull/32>06:44
mvomborzecki: 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 why06:46
mvomborzecki: but no fires afaict06:46
mborzeckimvo: hmm that's interesting, anything in particular that fails int he tests? or does it not boot at all?06:47
mvomborzecki: 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 network06:47
mborzeckimvo: do the new images use netplan or sth?06:48
mvomborzecki: yeah, it is, it *should* be the same config as the core1606:48
mborzeckimvo: interface naming then?06:48
mvomborzecki: my current straw is that cloud-init is not working yet on core18 and maybe it is doing some magic here06:48
mvomborzecki: its a pretty generic config, one sec, let me find it06:49
mvomborzecki: https://github.com/snapcore/core18/blob/master/static/etc/netplan/00-snapd-config.yaml06:49
mborzeckimvo: looks pretty straightforward06:50
mvomborzecki: yeah, I need to learn if I can get a OOB shell with gce somehow06:50
mborzeckimvo: there is a dhcp client in the image?06:50
mvomborzecki: systemd-networkd06:50
mvomborzecki: I don't think there another06:51
mborzeckimvo: ok, that should be fine, networkd does it's own dhcp06:51
mvomborzecki: yeah06:52
mborzeckimvo: hm you could try and ship your own config file for networkd in case netplan doesn't do it's thing06:52
mvomborzecki: thats an interessting idea06:53
mborzeckiheh, got another update to shellcheck, now it complains about not quoting variables when sourcing files, iirc this wasn't strictly needed06:59
mvomborzecki: heh06:59
mvomborzecki: nice find on your latest shellcheck PR in the framebuffer test06:59
mborzeckimvo: yeah, looking into it right now07:00
mvomborzecki: shell is just not the best language, really good we run the checker now07:00
=== chihchun is now known as chihchun_afk
mvomborzecki: I wish there was something like "-o strict" or somesuch that would at least protect against all the basic mistakes. anyway07:00
mborzeckimvo: shperl07:01
mvomborzecki: heh07:02
=== pstolowski|afk is now known as pstolowski
mvomborzecki: btw, gustavo added some comments to github.com/go-check/check https://github.com/go-check/check/pull/10007:06
mupPR 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:06
mvomborzecki: 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
mborzeckimvo: ah interesting, i can look into this later07:07
mvomborzecki: thank you, I will look at his other points07:08
pstolowskimorning07:08
mvohey pstolowski07:09
=== chihchun_afk is now known as chihchun
mborzeckimvo: 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 positives07:11
mborzeckimvo: 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 tests07:12
mborzeckizyga: how's your SLED work?07:13
zygaStuck07:13
zygaLook at that twitter post07:13
mborzeckizyga: boo :(07:16
mborzeckizyga: slightly surprised those are still behind paywall07:18
zygawell, those are like RHEL07:22
zygabut... I have a license07:22
zygasomething is wrong on the website07:22
mborzeckihttps://forum.snapcraft.io/t/nvidia-cuda-on-ubuntu-core/292/24 heh, nice pattern from nvdiia07:23
mborzeckiioctl(12, _IOC(_IOC_READ|_IOC_WRITE, 0x41, 0x2, 0x18), 0xbeb00fc0) = 0 this does some magic07:24
mborzeckiand works outside of snap07:24
mborzeckibut inside it fails, the driver apparently trues to do another little poke ioctl(12, _IOC(_IOC_READ|_IOC_WRITE, 0x41, 0x3, 0x10), 0xbee73f28) = -1 EINVAL07:24
mborzeckiin either case, the device accessed is open("/dev/nvhost-as-gpu", O_RDWR|O_DSYNC) = 1207:25
mupPR 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:27
zygaI'm looking into opensuse releases07:47
zygasomething is not working well on LEAP07:47
zygaand this is blocking a high-priority snap apparently07:47
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
mborzeckizyga: 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
mborzeckis/group/cgroup/08:15
zygaI believe open would fail, yes08:15
mborzeckihmm, 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() works08:16
mborzeckizyga: 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 even08:17
zygamborzecki: we need to further differentiate leap and tumbleweed08:38
zyga:/08:38
zyga42.3 cannot use any apparmor08:38
zygaleap 15 and tumbleweed can08:38
mborzeckizyga: what's missing there?08:38
zygaapparmor userspace is at 2.1008:39
zygathat's far too old08:39
zygait cannot even parse our snap-confine profile08:39
mborzeckiwell, we don't have much choice then08:40
zygaI will check leap 15 to be sure08:41
zygaand then patch this in the distro08:41
zygaand then send the patches to master08:41
mborzeckihm the framebuffer test was probably not executing on ubuntu-* because there's no /dev/fb* node09:06
mborzeckithen on others, it was just an echo due to missing "09:07
zygayeah09:07
mborzeckiand looks like write to a frame buffer is hitting a region outside of available memory, hence 'file too large' error09:07
zygaI'm building 2.33 opensuse packages here https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd09:17
zygaI will be patching that as I get builds and test them on my machines09:17
zygabut now I need to go and pick up a package from downtown, I will commit my apparmor work and continue on the way there09:18
zygahmm09:37
zygatests fail on opensuse09:37
zygafailed test in the state somewhere https://www.irccloud.com/pastebin/Aeu5glwF/09:37
mborzeckifun fact, ubuntu-{16.04,18.04,-core-16} do not have /dev/fb so the apparmor rules are not really tested anywhere09:37
Son_Goku:D09:39
Son_Gokufun fact, fun facts aren't usually fun09:39
mborzeckibarrels of fun ;)09:39
ChipacaSon_Goku: fun fact: ketchup was once medicine09:40
Son_GokuChipaca, really?09:40
Chipacawell, sold as such09:41
Son_Gokuthat's actually an interesting fact, if that's true09:41
Chipaca(but then so was cocaine)09:41
Son_Gokuwell, _that_ I knew09:41
mborzeckiChipaca: so was mercury09:41
Chipacaalso fun fact: tin (can) openers were invented 48 years after food was being canned09:42
Chipacain the interim people just stockpiled the stuff*09:42
Chipaca* may not be true09:42
pedronisChipaca: 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 results09:42
pedronis(the last thing using details.go)09:43
Chipacapedronis: it's probably covered indirectly, but probably no unit tests09:43
mborzeckianother fun fact, our 16.04 image has minix module loaded even before the test using that module starts09:44
Son_Gokuwut09:44
pedronisChipaca: 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 confused09:44
Son_Gokumvo, do you know when 2.33.1 is going to be tagged?09:44
Chipacapedronis: 1 sec09:44
mborzeckialong with xfs, ntfs, hfs, qnx4 and so on :?09:45
Son_Gokuqnx4?!09:45
Chipacamborzecki: something is trying really hard to mount a filesystem09:45
Chipacamaybe the gce initrd?09:45
mborzeckiChipaca: no clue09:46
mborzeckiwell, fwiw the rmmod-or-not part of the test did not work before shellchecks and it would always rmmod it09:46
Chipacapedronis: it seems you're correct, there are individual tests for specific aspects of details, but nothing whole hog09:48
pedronisChipaca: I suppose I should add something, maybe its own PR tough09:48
Chipacakjackal: that's a lot of yous09:48
Chipacapedronis: ok09:49
ChipacaI should go do some work on my back an' stuff09:49
* Chipaca very comfy tho09:49
pedronisChipaca: probably your info branch removed a details one that can reuse09:50
pedronis*that I can reuse in some form09:50
Chipacapedronis: I like your optimism :-)09:50
pedronisheh, I do think we had some tests (but with /details apparently)09:50
* pedronis is hopeful09:51
ChipacaSon_Goku: last fun fact for a while: colgate beef lasagne didn't sell well09:52
* Chipaca ~> physio09:52
Son_GokuI'm going to go with "eww" for that09:52
Chipacaa solid choice09:53
* Chipaca ~> really afk now09:53
mvozyga, sil2100: a quick look at #32 (in core18) would be great10:16
zygaAck10:17
sil2100mvo: on it now10:17
mvosil2100: thank you10:18
sil2100Ah, already saw it in the morning, didn't manage to +1 it then10:20
mupPR 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:21
joczyga: are new interface PRs waiting on 2.33 going out before landing? just checking not waiting for anything from me10:38
* zyga is in the underground10:38
zygaThey are waiting for jdstrand10:39
zygaHe is off this week10:39
zygaI think 33 is branched already so there is nothing blocking master10:40
joczyga: the PR has your and Jamie's +1s but the tests have not yet run successfully, looks like there was provisioning error10:50
zygaI’ll look into it soon10:56
zygaReturning home now10:56
mborzeckizyga: do you remember if firmware loading is done directly in the kernel now or still through a udev helper?10:58
mupPR 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:00
mborzeckizyga: pinged you in the forums, there's an interesting case regarding firmware loading and interaction with mount namespace11:07
zygamborzecki: replied there11:10
zygamborzecki: as for firmware loading, it AFAIK changed from userspace to kernel but I could be wrong and it could be backwards11:11
zygamborzecki: given that it fails I suspect it's userspace and the firmware cannot be found11:11
mborzeckiidk, haven't touched that really since 2.6.x days11:11
zygamborzecki: also on core vs classic?11:11
mborzeckizyga: the topic is about core11:11
zygamborzecki: on core, unless you use bases, you are using the same filesystem as before11:11
zygathere's a mount namespace but it is largely the same11:12
mborzeckizyga: confinement-options:  classic devmode11:12
zygathat's ... weird11:13
zygaclassic devmode is meaningless11:13
zygadoes it work outside of a snap11:13
zyga?11:13
mborzeckizyga: the thing works outside of snap11:13
zygastrace it11:13
mborzeckizyga: and if you start the app outside of snap, then it will work inside too11:13
mborzeckizyga: there's starce logs attached 2-3 messages up11:13
zygaah, let me see then11:14
zygamborzecki: well11:16
zygaconfinement options is what is *supporteD*11:16
zyganot what is used11:17
zygamborzecki: so this could be a strict snap11:17
zygabut I see there's no apparmor at all11:17
mborzeckizyga: ther's no aa11:17
zygaso it's somewhat meaningless11:17
zygasome funky errors at the end of snap_directly_log.txt https://www.irccloud.com/pastebin/qOLUGDob/11:18
zyganote that it closes -111:18
zygaprobably missing error checking11:18
zygamborzecki: is there /dev/nvidiactl inside the cgroup?11:20
zyga(device cgroup)11:20
mborzeckizyga: yes, we add it, we're adding nvidiactl, nvidia-uvm, nvidia-modeset and then some nvidia<num> devices11:21
zyga1811  open("/dev/shm/cuda_injection_path_shm", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory)11:22
zygathis looks related11:22
zygais it there on the outside?11:23
mborzeckizyga: don't know, i don't have access to this host11:23
mborzeckizyga: it's also funny taht if you run the app outside once, it will work inside the snap too11:23
zygauntil reboot, right?11:23
zygaplease ask for a strace -f, after reboot, of the app running _outside_11:24
=== pstolowski is now known as pstolowski|lunch
zygathen for a similar strace but on the inside, also after reboot (where it will fail)11:24
zygaif we have that we can investigate11:24
* zyga is about 10-20 minutes away from home11:25
zygacannot wait to get back really11:25
zygait's so damn hot today11:25
zygamy son's computer broke and I had to get a part that was faulty11:25
zygahe needs it for classes today11:26
mvoniemeyer: 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
zygamvo: ouch, still fighting that?11:26
zygamvo: did you look at diffing /etc between core18 and core?11:26
mvozyga: yeah11:26
mborzeckizyga: 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 work11:26
zygait may be something that was added to current system11:26
mvozyga: I poked around a bit, added some more cloud-init bits11:26
zygamvo: and something in /etc/modules.d or modprobe.d?11:27
zygamborzecki: it would be good to ask some nvidia people how this is supposed to work11:27
zygait's a bit silly that when you want to use the hardware then each app actually goes to load firmware into the hardware11:28
mborzeckizyga: i bet many people in open source had the same thought :)11:28
mborzeckizyga: i think it's the first use11:28
mvozyga: not afaict11:28
zygam11:28
mvozyga: it might be something silly11:28
mborzeckizyga: so you try to do something with the hardware for the first time and the driver goes to load the firmware11:28
mvozyga: but without access to the machine its hard to diagnose :/11:28
zygayeah11:28
* mvo gets lunch instead11:29
zygamvo: netplan has11:31
zygamvo: netplan has two patterns, one matches en* and the other matches eth*11:31
zygamaybe on a newer core you get veth or something silly like this11:31
zygabecuase newer systemd11:31
zygaand then stuff falls apart11:31
zygasuggestion11:31
zygaas a hack change /etc/netplan/00-snapd-config.yaml11:32
zygaand mach on *11:32
zygafingers crossed11:32
* zyga walks home, cannot wait to have A/C next season 11:33
mborzeckizyga: there's 19C in oslo right now, ever considered moving?11:36
Chipacaoslo with 19C must be melting11:37
zygaHahah11:38
zygaWell, I’m not *that* crazy11:38
Chipacazyga: [citation needed]11:38
mborzeckipedronis: shall we land #5314 once it's green?11:44
mupPR #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:44
mupPR 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:46
zygaChipaca: hehe :)11:47
* zyga is home now11:47
zygageez, outside is not fun11:47
pedronismborzecki: you should ask mvo if there is something high prio from him that could conflict11:48
mborzeckimvo: is there?11:48
mborzeckii can help resolving conflicts if needed11:49
mupPR 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
pedronisChipaca: ^ , not beautiful but better than nothing11:49
Chipacawill look in a bit11:50
Chipacacurrently reviewing shellcheck11:50
mborzeckiChipaca: thank you!11:52
zygamvo: any luck with that etherent change?11:58
Chipacamborzecki: don't thank me until the fat lady sings12:04
ChipacaI ask Questions12:04
mborzeckiChipaca: right, i might as well cleanup the \- now that i'm doing the changes anyway12:07
mborzeckiChipaca: looks like it was copy pasted pretty much everywhere :P12:08
Chipacamborzecki: I understand it's easier to think of it as a pure shellchecking change, but yeah12:08
ChipacaI'd have to read the docs on too many things to find out if that \- actually matches what we want it to match12:08
Chipacamborzecki: there's also a bunch of the PWD ones12:09
niemeyermvo: Heya, yeah, can definitely do it12:19
cachiozyga, hey12:20
zygahey12:20
cachiointerfaces content if failing sporadically https://api.travis-ci.org/v3/job/393533314/log.txt12:20
zygachecking12:20
cachiodid you see that one?12:20
zygacachio: yes,12:21
zygait's not related to content really12:21
zygait's related to mount exploiding12: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
zygaSee "systemctl status "var-lib-snapd-snap-test\\x2dsnapd\\x2dcontent\\x2dslot-2.mount"" and "journalctl -xe" for details.12:21
zygaJun 18 09:29:29 arch snapd[12112]: Jun 18 09:29:28 arch kernel: print_req_error: I/O error, dev loop3, sector 012:22
zygathere's a thread about it12:22
cachiozyga, ah, ok, good to know12:22
cachiotx12:22
zygahttps://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/568212:22
pedronismborzecki: sorry, I  just merged something that probably needs a remerge for your PR12:23
mupPR 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:23
pedronisChipaca: I got a +1 from zyga, happy to tweak in a follow up though if you find something that merits changes12:24
Chipacapedronis: LGTM12:34
Chipacapedronis: also thank you for updating the json12:34
pedronisChipaca: which reminds me, we can remove MockDetailsJSON12:34
pedronisbut something of another PR12:34
pedroniss/of/for/12:35
Chipacapedronis: there's a lot of unused stuff, according to 'unused'12:36
Chipacapedronis: I can propose a removal pr in a bit :)12:37
pedronisthx12:37
=== pstolowski|lunch is now known as pstolowski
CyberShadowHello. I submitted two pull requests last August, and got 0 feedback. Could someone please have a look at them?12:40
CyberShadowhttps://github.com/snapcore/snapd-xdg-open/pulls?q=author%3ACyberShadow12:40
zygaCyberShadow: hello12:40
zygaI think that repository is dead now, let me see12:41
zygawe should archive it12:41
zygawe re-wrote that code significantly since12:41
CyberShadowI found the software useful for use outside of snaps. How do you solve that problem now?12:41
zygalet me show you12:42
zygahttps://github.com/snapcore/snapd/tree/master/userd12:43
zygahttps://github.com/snapcore/snapd/blob/master/userd/launcher.go this is what the old code did12:43
mupPR snapd#5345 opened: store: drop unused: channel map types, and details fixture <Created by chipaca> <https://github.com/snapcore/snapd/pull/5345>12:43
Chipacapedronis: ^ +0 -115 :)12:44
zygaCyberShadow: this runs on the outside and sits on the bus12:44
zygaCyberShadow: the one that runs on the inside ...12:44
zygaCyberShadow: is here https://github.com/snapcore/snapd/blob/master/cmd/snapctl/main.go#L5012:45
zygaand more completely here: https://github.com/snapcore/snapd/blob/master/xdgopenproxy/xdgopenproxy.go12:46
mvocachio: is there a way to log into a gce instance when there is no ssh/network ? some magic via serial console etc?12:46
CyberShadowI see, thanks! So you consolidated everything into one daemon rewritten in Go.12:46
zygaCyberShadow: one codebase, there's more than one process12:47
CyberShadowI think I'll maintain my fork of the old snapd-xdg-open then, it's still useful with Firejail/Bubblewrap.12:47
zygaCyberShadow: I will close your PRs now, sorry12:47
CyberShadowRight, that hasn't changed.12:47
CyberShadowNo problem. Consider adding a note that the repository is EOL.12:47
cachiomvo, you should to send all the info to the console, then we can check that12:47
cachiomvo, let me research a bit about other ways to do it12:48
mborzeckizyga: github allows repos to be archived now, no clue though who can mark that one as such12:48
zygamborzecki: yeah, I know12:48
zygamborzecki: I will ask during the standup12:48
ChipacaCyberShadow: if the two bits were still go but separate, would you contribute to them?12:53
ChipacaCyberShadow: or is the hacky aspect of the previous incarnation part of their appeal :)12:53
zygakyrofa: https://forum.snapcraft.io/t/update-all-python-snaps-not-working-with-classic-confinement-even-with-cleanbuild/597112:54
ChipacaCyberShadow: I ask because the new things support stuff the old ones do not, like apps autostart12:55
Chipacaso there might be value in them for you as well12:55
CyberShadowChipaca: Sure, language doesn't matter13:02
CyberShadowSorry, I'm not sure how autostart fits in with the Firejail/Bubblewrap flow...13:02
ChipacaCyberShadow: I don't know either :)13:03
ChipacaCyberShadow: how would an app go around setting up autostart in that world?13:04
CyberShadowIt doesn't, it's something that would break encapsulation :)13:04
CyberShadowThe user would need to do that manually. They would need to create the container manually too, so it's not unexpected.13:05
ChipacaCyberShadow: I'll raise separating it in the standup13:11
ChipacaCyberShadow: is it the inside-the-container thing that you use, or the outside one, or both?13:11
CyberShadowBoth13:12
Chipacak13:12
CyberShadowHere is the user-facing documentation: https://wiki.archlinux.org/index.php/Bubblewrap#Opening_URLs_from_wrapped_applications13:12
CyberShadowJust 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:13
mupPR 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
ChipacaCyberShadow: yep yep13:14
ChipacaCyberShadow: the old one was attractively simple so I get that13:14
=== chihchun is now known as chihchun_afk
Son_GokuCyberShadow, I suggest renaming the application, but yeah, go for it13:31
CyberShadowGood idea :)13:32
Son_GokuCyberShadow, talk to the guys in #atomic about hosting the program under their banner13:32
Son_Gokuthat way it sits adjacent to bubblewrap ;)13:32
CyberShadowTrue, 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-portal13:39
Son_GokuCyberShadow, well, that's why I suggested projectatomic and not flatpak org ;)13:40
CyberShadowAh, right13:40
ChipacaCyberShadow: 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 this13:47
ChipacaCyberShadow: so fork away, with our blessing13:47
CyberShadowThanks!13:47
pedronismvo: I'll be a couple of minutes late14:00
zygaah, the core18 meeting is still in 29 minutes14:01
zygaI thought it was back to back14:01
pedronisah, same, was confused14:02
zygauh14:21
zygaI ran out of disk space14:21
zygasigh14:21
* zyga moves stuff around14:21
* ogra_ hands zyga a paperbasket14:24
* zyga throws lumps of lead and cement inside14:24
ogra_*thump*14:24
zygalook, the bucket is now a pipe14:24
mvoniemeyer: the compute.instances.reset permission for image debug would be great14:30
zygadownloading chrome14:34
mborzeckimvo: will landing #5314 conflict with any stuff that you have open atm?14:39
mupPR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>14:39
mvomborzecki: its fine, I will deal with any conflicts15:06
niemeyermvo: (done, for our record)15:07
mvoniemeyer: thank you (also for the record ;)15:18
zygaI must say that the google meet thing has better video quality15:18
zygaor mvo changed his camera to some high-def one15:18
zygait looked much sharper than before15:18
zygaI will break for dinner now, back in one hour when I also have my disk space free15:21
mvomborzecki, 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?15:58
pstolowskimvo: sure, i can look at it tomorrow16:29
sergiusensniemeyer: hi there, are you joining?16:38
niemeyersergiusens: Yep, sorry16:39
=== pstolowski is now known as pstolowski|afk
zygamvo: is 2.33 in general a go?16:46
zygaor are there any issues warranting a .116:47
mvozyga: no issues but we will most likely do a .1 to fix some autopkgtests in the distro16:57
zygaonly autopkgtests?16:57
mvozyga: but no real issues, all tests related16:57
zygaok16:57
zygagood, I'll make sure we can release to opensuse tomorrw16:58
mvozyga: thank you16:58
zygaand I need to buy a disk or a NAS maybe16:58
mvozyga: if you want we can coordinate with a .116:58
zygasure, that's fine16:58
zygachanging the tarsal is all we need I suspect16:58
zygathough16:58
zygawe can merge my packaging fixes for .1 too16:58
mvocachio: interessting datapoint - I just got a econnreset test failure where we got a 503 from fastly17:13
zygahmm, any gas recommendations17:14
zygaNAS17:14
zygasilly spellchecker17:14
mvopstolowski|afk: thank you, lets talk tomorrow, I will forward you two mails about it17:36
mvozyga: depends on how much you want to hack it :)17:36
cachiomvo, do you have any log?17:37
mvocachio: I have it still open, I can save/pastebin it17:38
cachiomvo, yes please17:38
mvocachio: http://paste.ubuntu.com/p/x58ZnRZW3Y/17:39
cachiomvo, do you have the error itsrf?17:40
mvocachio: this is the full log http://paste.ubuntu.com/p/2PryTk8nZs/17:46
cachiomvo, tx17:46
cachiomvo, I don't see any error17:48
mvocachio: uh, sorry, hold on17:52
mvocachio: http://paste.ubuntu.com/p/GjXcPvxmPF/ this is hopefully the right one this time17:55
mvoyay, core18 spread did a successful run (with a single test) in gce - cleanup of this tomorrow17:56
cachiomvo, nice17:57
cachioit received a 503 and didn't retry17:57
cachioand also failed to kill the snap download process17:58
cachiomvo, well, the ShouldRetryError method is not returning true if it receives a 50318:03
cachioit is retrying on timeout, syscall.econnreset, dial error and unexpectedEOF18:04
cachiopedronis, 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:05
cachiozyga, in this case we should change the ShouldRetryError to support other errors18:06
cachiothis is why in some cases the econnreset is not downloading the snapd18:07
cachiosnap18:07
cachioans it is not retrying neither18:07
cachiomvo, thanks for the logs, it was really usefull18:08
mvocachio: my pleasure18:18
mborzeckizyga: 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 unit18:19
zygaI think I will just buy a HDD for now18:20
zyganas boxes look very expensive18:20
zygaand 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
mvozyga: I got a relatively cheap synology18:20
mborzeckizyga: 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:20
zygathe problem with that box is that it weighs a lot and is not a mobile in any way18:21
zygaand I want something I can take with my laptop next month18:21
zygaanyway, I'll just get a USB HDD18:21
zyganot perfect18:21
zygabut yeah, low cost18:21
cachioI see the error in the code18:28
cachiomvo, why it is not retrying in 50X18:29
cachiomvo, core snap 2.33 in stable channel18:35
noise][cachio: will you be updating the forum post? (https://forum.snapcraft.io/t/snapd-2-33-release-cycle-started/5585)18:37
cachionoise][, yes18:38
cachionoise][, let me complete the smoke test18:38
zyga\o/18:42
mvocachio: yay, thank you18:43
mvocachio: iirc the idea behind not retry on 500 was that sometihng is broken on the server18:43
mvocachio: but if its a real world scenario maybe we need to rethink that18:43
zygamvo: but the CDN is ... big18:43
zygaso maybe retrying is sensible18:43
zygaanother server might just work18:43
mvozyga: yes18:43
cachiozyga, mvo https://paste.ubuntu.com/p/Tx9WgCW9nR/18:44
cachiobased on ShouldRetryHttpResponse we should retry18:45
mvocachio: yes, I remember this code18:45
cachiobut based ton ShouldRetryError we shouldn't18:45
cachioso we never check the response becasuse we don't retry and break based on the errorr18:46
cachiomvo, is it ok?18:46
mvocachio: yeah, we probably just need to update ShouldRetryError18:47
cachiomvo, ok18:48
gouchihi20:13
gouchito test the fix for  https://forum.snapcraft.io/t/nvidia-gl-libs-access-broken-on-ubuntu-18-0420:13
gouchiI need to update snapd or using core snap to edge branch is enough ?20:14
pedroniscachio: that code doesn't expect a 503  to reach ShouldRetryError, we are probably misunderstanding something about the library20:28
mupPR snapcraft#2162 opened: tests: new codespell, narrowed checks and better execution order <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2162>21:10
mupPR snapcraft#2163 opened: tests: add lifecycle ordering tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2163>21:46

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