zyga | good morning | 05:37 |
---|---|---|
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
mborzecki | morning | 06:34 |
mborzecki | starting a bit later today, had to take my wife's car to the shop | 06:34 |
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:37 |
=== chihchun_afk is now known as chihchun | ||
mvo | hey mborzecki - good morning | 06:43 |
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:44 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
mvo | mborzecki: I don't think there another | 06:51 |
mborzecki | mvo: ok, that should be fine, networkd does it's own dhcp | 06:51 |
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:52 |
mvo | mborzecki: thats an interessting idea | 06:53 |
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 | 06:59 |
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 |
=== chihchun is now known as chihchun_afk | ||
mvo | mborzecki: I wish there was something like "-o strict" or somesuch that would at least protect against all the basic mistakes. anyway | 07:00 |
mborzecki | mvo: shperl | 07:01 |
mvo | mborzecki: heh | 07:02 |
=== pstolowski|afk is now known as pstolowski | ||
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:06 |
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:07 |
mvo | mborzecki: thank you, I will look at his other points | 07:08 |
pstolowski | morning | 07:08 |
mvo | hey pstolowski | 07:09 |
=== chihchun_afk is now known as chihchun | ||
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:11 |
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:12 |
mborzecki | zyga: how's your SLED work? | 07:13 |
zyga | Stuck | 07:13 |
zyga | Look at that twitter post | 07:13 |
mborzecki | zyga: boo :( | 07:16 |
mborzecki | zyga: slightly surprised those are still behind paywall | 07:18 |
zyga | well, those are like RHEL | 07:22 |
zyga | but... I have a license | 07:22 |
zyga | something is wrong on the website | 07:22 |
mborzecki | https://forum.snapcraft.io/t/nvidia-cuda-on-ubuntu-core/292/24 heh, nice pattern from nvdiia | 07:23 |
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:24 |
mborzecki | in either case, the device accessed is open("/dev/nvhost-as-gpu", O_RDWR|O_DSYNC) = 12 | 07:25 |
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:27 |
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 | 07:47 |
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
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:15 |
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:16 |
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:17 |
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:38 |
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:39 |
mborzecki | well, we don't have much choice then | 08:40 |
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 | 08:41 |
mborzecki | hm the framebuffer test was probably not executing on ubuntu-* because there's no /dev/fb* node | 09:06 |
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:07 |
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:17 |
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:18 |
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:37 |
Son_Goku | :D | 09:39 |
Son_Goku | fun fact, fun facts aren't usually fun | 09:39 |
mborzecki | barrels of fun ;) | 09:39 |
Chipaca | Son_Goku: fun fact: ketchup was once medicine | 09:40 |
Son_Goku | Chipaca, really? | 09:40 |
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:41 |
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:42 |
pedronis | (the last thing using details.go) | 09:43 |
Chipaca | pedronis: it's probably covered indirectly, but probably no unit tests | 09:43 |
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:44 |
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:45 |
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:46 |
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:48 |
Chipaca | pedronis: ok | 09:49 |
Chipaca | I should go do some work on my back an' stuff | 09:49 |
* Chipaca very comfy tho | 09:49 | |
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:50 |
* pedronis is hopeful | 09:51 | |
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:52 |
Chipaca | a solid choice | 09:53 |
* Chipaca ~> really afk now | 09:53 | |
mvo | zyga, sil2100: a quick look at #32 (in core18) would be great | 10:16 |
zyga | Ack | 10:17 |
sil2100 | mvo: on it now | 10:17 |
mvo | sil2100: thank you | 10:18 |
sil2100 | Ah, already saw it in the morning, didn't manage to +1 it then | 10:20 |
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:21 | |
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:38 | |
zyga | They are waiting for jdstrand | 10:39 |
zyga | He is off this week | 10:39 |
zyga | I think 33 is branched already so there is nothing blocking master | 10:40 |
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:50 |
zyga | I’ll look into it soon | 10:56 |
zyga | Returning home now | 10:56 |
mborzecki | zyga: do you remember if firmware loading is done directly in the kernel now or still through a udev helper? | 10:58 |
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:00 |
mborzecki | zyga: pinged you in the forums, there's an interesting case regarding firmware loading and interaction with mount namespace | 11:07 |
zyga | mborzecki: replied there | 11:10 |
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:11 |
zyga | there's a mount namespace but it is largely the same | 11:12 |
mborzecki | zyga: confinement-options: classic devmode | 11:12 |
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:13 |
zyga | ah, let me see then | 11:14 |
zyga | mborzecki: well | 11:16 |
zyga | confinement options is what is *supporteD* | 11:16 |
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:17 |
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:18 |
zyga | mborzecki: is there /dev/nvidiactl inside the cgroup? | 11:20 |
zyga | (device cgroup) | 11:20 |
mborzecki | zyga: yes, we add it, we're adding nvidiactl, nvidia-uvm, nvidia-modeset and then some nvidia<num> devices | 11:21 |
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:22 |
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:23 |
zyga | please ask for a strace -f, after reboot, of the app running _outside_ | 11:24 |
=== pstolowski is now known as pstolowski|lunch | ||
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:24 |
* 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:25 |
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:26 |
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:27 |
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:28 |
* mvo gets lunch instead | 11:29 | |
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:31 |
zyga | as a hack change /etc/netplan/00-snapd-config.yaml | 11:32 |
zyga | and mach on * | 11:32 |
zyga | fingers crossed | 11:32 |
* zyga walks home, cannot wait to have A/C next season | 11:33 | |
mborzecki | zyga: there's 19C in oslo right now, ever considered moving? | 11:36 |
Chipaca | oslo with 19C must be melting | 11:37 |
zyga | Hahah | 11:38 |
zyga | Well, I’m not *that* crazy | 11:38 |
Chipaca | zyga: [citation needed] | 11:38 |
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:44 |
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:46 |
zyga | Chipaca: hehe :) | 11:47 |
* zyga is home now | 11:47 | |
zyga | geez, outside is not fun | 11:47 |
pedronis | mborzecki: you should ask mvo if there is something high prio from him that could conflict | 11:48 |
mborzecki | mvo: is there? | 11:48 |
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:49 |
Chipaca | will look in a bit | 11:50 |
Chipaca | currently reviewing shellcheck | 11:50 |
mborzecki | Chipaca: thank you! | 11:52 |
zyga | mvo: any luck with that etherent change? | 11:58 |
Chipaca | mborzecki: don't thank me until the fat lady sings | 12:04 |
Chipaca | I ask Questions | 12:04 |
mborzecki | Chipaca: right, i might as well cleanup the \- now that i'm doing the changes anyway | 12:07 |
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:08 |
Chipaca | mborzecki: there's also a bunch of the PWD ones | 12:09 |
niemeyer | mvo: Heya, yeah, can definitely do it | 12:19 |
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:20 |
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:21 |
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:22 |
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:23 |
pedronis | Chipaca: I got a +1 from zyga, happy to tweak in a follow up though if you find something that merits changes | 12:24 |
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:34 |
pedronis | s/of/for/ | 12:35 |
Chipaca | pedronis: there's a lot of unused stuff, according to 'unused' | 12:36 |
Chipaca | pedronis: I can propose a removal pr in a bit :) | 12:37 |
pedronis | thx | 12:37 |
=== pstolowski|lunch is now known as pstolowski | ||
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:40 |
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:41 |
zyga | let me show you | 12:42 |
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:43 |
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:44 |
zyga | CyberShadow: is here https://github.com/snapcore/snapd/blob/master/cmd/snapctl/main.go#L50 | 12:45 |
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:46 |
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:47 |
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:48 |
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:53 |
zyga | kyrofa: https://forum.snapcraft.io/t/update-all-python-snaps-not-working-with-classic-confinement-even-with-cleanbuild/5971 | 12:54 |
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 | 12:55 |
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:02 |
Chipaca | CyberShadow: I don't know either :) | 13:03 |
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:04 |
CyberShadow | The user would need to do that manually. They would need to create the container manually too, so it's not unexpected. | 13:05 |
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:11 |
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:12 |
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:13 |
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:14 |
=== chihchun is now known as chihchun_afk | ||
Son_Goku | CyberShadow, I suggest renaming the application, but yeah, go for it | 13:31 |
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:32 |
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:39 |
Son_Goku | CyberShadow, well, that's why I suggested projectatomic and not flatpak org ;) | 13:40 |
CyberShadow | Ah, right | 13:40 |
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! | 13:47 |
pedronis | mvo: I'll be a couple of minutes late | 14:00 |
zyga | ah, the core18 meeting is still in 29 minutes | 14:01 |
zyga | I thought it was back to back | 14:01 |
pedronis | ah, same, was confused | 14:02 |
zyga | uh | 14:21 |
zyga | I ran out of disk space | 14:21 |
zyga | sigh | 14:21 |
* zyga moves stuff around | 14:21 | |
* 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:24 |
mvo | niemeyer: the compute.instances.reset permission for image debug would be great | 14:30 |
zyga | downloading chrome | 14:34 |
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> | 14:39 |
mvo | mborzecki: its fine, I will deal with any conflicts | 15:06 |
niemeyer | mvo: (done, for our record) | 15:07 |
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:18 |
zyga | I will break for dinner now, back in one hour when I also have my disk space free | 15:21 |
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? | 15:58 |
pstolowski | mvo: sure, i can look at it tomorrow | 16:29 |
sergiusens | niemeyer: hi there, are you joining? | 16:38 |
niemeyer | sergiusens: Yep, sorry | 16:39 |
=== pstolowski is now known as pstolowski|afk | ||
zyga | mvo: is 2.33 in general a go? | 16:46 |
zyga | or are there any issues warranting a .1 | 16:47 |
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:57 |
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 | 16:58 |
mvo | cachio: interessting datapoint - I just got a econnreset test failure where we got a 503 from fastly | 17:13 |
zyga | hmm, any gas recommendations | 17:14 |
zyga | NAS | 17:14 |
zyga | silly spellchecker | 17:14 |
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:36 |
cachio | mvo, do you have any log? | 17:37 |
mvo | cachio: I have it still open, I can save/pastebin it | 17:38 |
cachio | mvo, yes please | 17:38 |
mvo | cachio: http://paste.ubuntu.com/p/x58ZnRZW3Y/ | 17:39 |
cachio | mvo, do you have the error itsrf? | 17:40 |
mvo | cachio: this is the full log http://paste.ubuntu.com/p/2PryTk8nZs/ | 17:46 |
cachio | mvo, tx | 17:46 |
cachio | mvo, I don't see any error | 17:48 |
mvo | cachio: uh, sorry, hold on | 17:52 |
mvo | cachio: http://paste.ubuntu.com/p/GjXcPvxmPF/ this is hopefully the right one this time | 17:55 |
mvo | yay, core18 spread did a successful run (with a single test) in gce - cleanup of this tomorrow | 17:56 |
cachio | mvo, nice | 17:57 |
cachio | it received a 503 and didn't retry | 17:57 |
cachio | and also failed to kill the snap download process | 17:58 |
cachio | mvo, well, the ShouldRetryError method is not returning true if it receives a 503 | 18:03 |
cachio | it is retrying on timeout, syscall.econnreset, dial error and unexpectedEOF | 18:04 |
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:05 | |
cachio | zyga, in this case we should change the ShouldRetryError to support other errors | 18:06 |
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:07 |
cachio | mvo, thanks for the logs, it was really usefull | 18:08 |
mvo | cachio: my pleasure | 18:18 |
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:19 |
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:20 |
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:21 |
cachio | I see the error in the code | 18:28 |
cachio | mvo, why it is not retrying in 50X | 18:29 |
cachio | mvo, core snap 2.33 in stable channel | 18:35 |
noise][ | cachio: will you be updating the forum post? (https://forum.snapcraft.io/t/snapd-2-33-release-cycle-started/5585) | 18:37 |
cachio | noise][, yes | 18:38 |
cachio | noise][, let me complete the smoke test | 18:38 |
zyga | \o/ | 18:42 |
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:43 |
cachio | zyga, mvo https://paste.ubuntu.com/p/Tx9WgCW9nR/ | 18:44 |
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:45 |
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:46 |
mvo | cachio: yeah, we probably just need to update ShouldRetryError | 18:47 |
cachio | mvo, ok | 18:48 |
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:13 |
gouchi | I need to update snapd or using core snap to edge branch is enough ? | 20:14 |
pedronis | cachio: that code doesn't expect a 503 to reach ShouldRetryError, we are probably misunderstanding something about the library | 20:28 |
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:10 |
mup | PR 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!