| === chihchun_afk is now known as chihchun | ||
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| === chihchun is now known as chihchun_afk | ||
| mup | Bug #1652262 changed: subiquitycore exception in controller.run <snappy> <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1652262> | 04:16 |
|---|---|---|
| mup | PR snapcraft#1552 opened: tests: replace the mosquitto demo test with a snapd integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1552> | 04:51 |
| mvo | ppisati: could you please trigger a new kernel build for edge? I pushed a bugfix for ubuntu-core-initramfs-tools recently | 07:25 |
| mvo | ogra_: you showed me a bunch of empty revision dirs under /snap/core some days ago (iirc). could you pastebin that again? I was looking into this this morning but I haven't managed to reproduce it yet (and the code seems to be doing the right thing). so I'm curious to learn more how this is happening | 07:35 |
| mvo | zyga-ubuntu: I wonder if we need to look at the issue that we need to make /snap shared again for lxd. iirc there was this issue that the mounts happen before we run snap-confine for the first time to do the shared mount magic | 07:38 |
| mvo | zyga-ubuntu: you wanted to look if we can do something with namespace, we may need a brute force approach with an early mount unit | 07:38 |
| zyga-ubuntu | mvo: right, I was thinking about it last night; I wanted to mention that it also happens on 14.04 so it's relateively easy and painless to interate on | 07:44 |
| zyga-ubuntu | mvo: I haven't had the time to try though, I'm iterating on the feedback from jamie now | 07:44 |
| mvo | zyga-ubuntu: ok - my approach would be a mount unit similar to the one we have in 14.04 - but that is very heavy handed and may get tricky as we need to run it after /snap is mounted but before anything under /snap/* is squashfs mounted, so the right before= is tricky | 07:48 |
| mvo | zyga-ubuntu: also please check https://github.com/snapcore/core-build/pull/21 and https://github.com/snapcore/core-build/pull/22 if you have a moment, should be painless | 07:49 |
| mup | PR core-build#21: Release 0.7.43+ppa23 <Created by mvo5> <https://github.com/snapcore/core-build/pull/21> | 07:49 |
| mup | PR core-build#22: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22> | 07:49 |
| zyga-ubuntu | mvo: maybe we need After on actual units? | 07:49 |
| zyga-ubuntu | (mount units we create) | 07:49 |
| zyga-ubuntu | mvo: ok | 07:49 |
| mvo | zyga-ubuntu: yeah, that would work I think, we just need to make sure we rewrite existing ones (I don't think we do this currently) | 07:50 |
| zyga-ubuntu | mvo: no, we don't | 07:50 |
| zyga-ubuntu | mvo: I'd strongly enourage us to try SyncDir thing for that | 07:51 |
| davidcalle | sergiusens: hey, so you know, we are still following up on the deployment of the latest dn, I'll ping you when it's resolved | 07:51 |
| mup | PR core-build#21 closed: Release 0.7.43+ppa23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/21> | 07:51 |
| zyga-ubuntu | mvo: as it has the "ensure" property of patching up broken state | 07:51 |
| * mvo nods | 07:52 | |
| zyga-ubuntu | mvo: the tests look ok, I'm wondering if you tried using the VM-based tests that would run this in the real initrd | 07:53 |
| mvo | zyga-ubuntu: I did, but got stuck seting up the right environment for this | 07:54 |
| zyga-ubuntu | mvo: I see, what was the main difficulty? | 07:54 |
| mvo | zyga-ubuntu: also travis is broken since the VM based tests got merged, I'm looking at this right now | 07:54 |
| zyga-ubuntu | mvo: oh? It passed earlier | 07:54 |
| zyga-ubuntu | mvo: (I mean, it did go green before this was merged) | 07:54 |
| mvo | zyga-ubuntu: maybe I did not try hard enough, but I need to simulate the /writable and core snap changes so that sync dir can be tested, setting up changes in the core snap in /etc was were I got stuck | 07:55 |
| zyga-ubuntu | test init process did not signal boot-ok | 07:56 |
| mvo | zyga-ubuntu: please check https://travis-ci.org/snapcore/core-build/builds | 07:56 |
| mvo | zyga-ubuntu: maybe coincidence, I just started looking at this | 07:56 |
| mvo | zyga-ubuntu: aha, did you retrigger it? | 07:57 |
| mvo | zyga-ubuntu: the first actual failure is much later in #41 | 07:57 |
| mup | PR #41: add X-Ubuntu-Wire-Protocol to the headers <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/41> | 07:57 |
| pedronis | core#41 | 07:57 |
| mup | PR core#41: limit the version string to 32chars (this is what the store allows) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/41> | 07:57 |
| zyga-ubuntu | mvo: I re-started older test jobs that got cancelled | 07:57 |
| mvo | zyga-ubuntu: and please don't get me wrong, the iqemu tests are nice, just seems to be not nice for my particular test | 07:57 |
| zyga-ubuntu | mvo: we'll see when it stated failing (hopefully) | 07:57 |
| mvo | zyga-ubuntu: aha, nice | 07:58 |
| mvo | core-build#41 | 07:58 |
| zyga-ubuntu | mvo: no worries, I just wanted to understand what was hard. I agree that it would be easier to do some of those tests with more of the system around (writable disk or SD card) | 07:58 |
| mvo | thanks pedronis, looks like mup does not know about core-build | 07:58 |
| mvo | zyga-ubuntu: I also looked briefly at the gpt regression bug and how to test that but that looks really tricky to unit test :( | 07:59 |
| mvo | zyga-ubuntu: *but* I think we should have a spread test for this, I will ponder a bit how to test it | 07:59 |
| zyga-ubuntu | mvo: yes | 07:59 |
| zyga-ubuntu | mvo: I think both would not hurt :) | 07:59 |
| mvo | +1 | 07:59 |
| mvo | zyga-ubuntu: silly question, but do you know why the tests did not run on core-build? | 08:00 |
| mvo | (or why they were canceled) | 08:01 |
| zyga-ubuntu | mvo: no, no idea | 08:01 |
| zyga-ubuntu | mvo: I just did a test on my machine, clean tree, VM tests passed | 08:02 |
| zyga-ubuntu | mvo: everything does fail with: test init process did not signal boot-ok | 08:02 |
| zyga-ubuntu | mvo: let me push a pr that runs tests in verbose mode | 08:02 |
| zyga-ubuntu | mvo: hmmmm, why there's no travis here: https://github.com/snapcore/core-build/pull/23 ? | 08:05 |
| mup | PR core-build#23: tests: treat --verbose as -v <Created by zyga> <https://github.com/snapcore/core-build/pull/23> | 08:05 |
| mup | PR core-build#23 opened: tests: treat --verbose as -v <Created by zyga> <https://github.com/snapcore/core-build/pull/23> | 08:05 |
| zyga-ubuntu | ah, it just showed up | 08:06 |
| mvo | zyga-ubuntu: interessting | 08:07 |
| ppisati | mvo: i guess, every kernel | 08:08 |
| zyga-ubuntu | mvo: https://travis-ci.org/snapcore/core-build/builds/275784391?utm_source=github_status&utm_medium=notification ??! | 08:09 |
| mvo | zyga-ubuntu: "test init process did not signal boot-ok" - at least it is concistent, ie #27 also failed with the same error | 08:10 |
| mvo | zyga-ubuntu: is it supposed to show more output? maybe its just slow? how much time does it have for this signal? | 08:11 |
| zyga-ubuntu | mvo: I found the issue | 08:11 |
| mvo | ppisati: thank you, please let me know when new edge kernel is available and I will test right away | 08:12 |
| zyga-ubuntu | https://travis-ci.org/snapcore/core-build/builds/275784391#L2178 | 08:12 |
| zyga-ubuntu | mvo: fixing that now | 08:12 |
| zyga-ubuntu | mvo: cpio was in the middle of a pipe so the erorr was silent | 08:13 |
| ppisati | mvo: ack | 08:13 |
| zyga-ubuntu | mvo: I pushed it back to my PR | 08:13 |
| zyga-ubuntu | mvo: it passed now | 08:18 |
| zyga-ubuntu | mvo: so whatever caused cpio to get yanked from the image we chroot into won't affect us anymore | 08:19 |
| zyga-ubuntu | mvo: please merge https://github.com/snapcore/core-build/pull/23 for happiness | 08:19 |
| mup | PR core-build#23: tests: treat --verbose as -v <Created by zyga> <https://github.com/snapcore/core-build/pull/23> | 08:19 |
| phil_m | @zyga-suse, @zyga-ubuntu, @zyga: great accomplishment with Manjaro and Snappy | 08:23 |
| nothal | phil_m: No such command! | 08:23 |
| zyga-suse | phil_m: I'm still working on opengl support but snapd proper works ok | 08:24 |
| phil_m | ok, so what was the problem? | 08:24 |
| phil_m | if some is needed to be changed within the kernel, we can do that also | 08:25 |
| zyga-suse | phil_m: so far none, the patch I cherry picked had different sum than the one from the URL, maybe it was corrupt there? | 08:25 |
| zyga-suse | phil_m: would you be interested in cherry-picking apparmor support into the manjaro kernel like solus did? | 08:25 |
| phil_m | ah ok. | 08:25 |
| zyga-suse | phil_m: this would give you apparmor confinement | 08:25 |
| phil_m | I've to see about appamor | 08:26 |
| zyga-suse | phil_m: the patch against 4.14 should be small now, 4.15 will have everything but I think we missed the window with some patches | 08:27 |
| zyga-suse | phil_m: do you have the apparmor userspace tools packaged? | 08:28 |
| phil_m | well, we had apparmor in our distro but removed it: https://github.com/manjaro/packages-core/issues/49 | 08:29 |
| mvo | zyga-suse: ta | 08:29 |
| zyga-suse | phil_m: I see I have to add one more patch to cmd.go, | 08:29 |
| mup | PR core-build#23 closed: tests: treat --verbose as -v <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/23> | 08:29 |
| phil_m | since you have full write access to our community packages git repo you can also add the needed patches directly if you like. | 08:30 |
| zyga-suse | phil_m: thank you, should I discuss this with other manjaro developers before proposing PRs? | 08:31 |
| phil_m | na, not needed | 08:32 |
| zyga-suse | phil_m: thank you, I'll plan what is the best course of action | 08:32 |
| phil_m | we are open and since you know better about snapd you can push it directly | 08:32 |
| phil_m | however one of our maintainers has to package it. | 08:32 |
| zyga-suse | phil_m: please stick around and let's chat periodically about what else might be needed | 08:32 |
| phil_m | sure, no problem in that. | 08:32 |
| zyga-suse | phil_m: that's great, I'd love to co-maintain the package if that's okay | 08:33 |
| phil_m | sure, why not. we have to see how we can do that properly. | 08:33 |
| zyga-suse | phil_m: and if the main packager could be here or on the forum (or both) for release coordination, that would be perfect | 08:33 |
| phil_m | you can always ping me via email if needed or write in github that a new release needs to be packaged | 08:34 |
| zyga-suse | phil_m: thank you! I'll definitely stay in touch | 08:34 |
| phil_m | it should be packaged then on the same day with a small delay | 08:34 |
| phil_m | since we are not Arch we are more open for new packages if they make sense. | 08:35 |
| zyga-suse | yes, we have a release cycle that has a moment when the package is in testing and once we are happy across the spectrum of systems we mark it as stable | 08:35 |
| zyga-suse | thank you :-) | 08:35 |
| phil_m | we also have some kind of release cylce with each package. we use branches and move them when ready to the next one. | 08:35 |
| zyga-suse | where can I read about that? | 08:36 |
| pedronis | I noticed we never marked this https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 as backlog, fixed now | 08:37 |
| phil_m | more or less in our forum or wiki | 08:37 |
| phil_m | https://wiki.manjaro.org/index.php?title=Repositories_and_Servers | 08:37 |
| phil_m | testing gets updated mostly every second day. | 08:37 |
| phil_m | unstable daily and stable in weekly basis | 08:37 |
| zyga-suse | phil_m: I think this matches snapd release cycle well, we are trying to (still trying though) make a reliable mothly cycle | 08:41 |
| phil_m | https://manjaro.github.io/homepage/public/features/background/ | 08:42 |
| phil_m | this is a simply page explaining how we manage our packages | 08:42 |
| pedronis | mvo: let me when you want to chat about what's left for repairs | 08:43 |
| mvo | pedronis: I'm finishing a small branch, then I should be ready so ~30min or so (depending a bit on how tests look) | 08:48 |
| phil_m | zyga-suse: looking good so far according to your screens ;) | 08:49 |
| pedronis | mvo: ok | 08:49 |
| zyga-suse | yes :) | 08:49 |
| zyga-suse | phil_m: though I need to investigate two things before I call it good | 08:49 |
| phil_m | na, no pressure | 08:50 |
| phil_m | take all the time you need | 08:50 |
| ogra_ | mvo, http://paste.ubuntu.com/25539231/ | 09:03 |
| mvo | ogra_: and all empty except the last ~3 ones, right? | 09:05 |
| mup | PR snapd#3920 opened: snap-confine: improve error message if core/u-core cannot be found <Created by mvo5> <https://github.com/snapcore/snapd/pull/3920> | 09:05 |
| zyga-ubuntu | mvo: nice, thank you | 09:07 |
| mvo | zyga-ubuntu: thanks for the quick review! | 09:07 |
| zyga-ubuntu | darn | 09:08 |
| ackk | mvo, hi, I'm not really sure what failed on https://github.com/snapcore/snapd/pull/3916, is it just flakiness in tests setup? | 09:08 |
| mup | PR #3916: add support for socket activation in apps <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916> | 09:08 |
| zyga-ubuntu | a bird just landed next to my window and I even have a camera standing by for that occasion but it ... flew away before I got the shot | 09:09 |
| mvo | ackk: yeah, the test failure looks not related to your code | 09:18 |
| ackk | mvo, can you restart just that build? or it doesn't matter for the review? | 09:18 |
| mup | PR snapcraft#1553 opened: lxd: instructions for /etc/sub{u,g}id after failed start <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1553> | 09:18 |
| ashwind | Hey, I see that GPIO pins cannot be accessed via a snap. Is this correct? I have a sensehat (https://www.raspberrypi.org/products/sense-hat/) connected a Pi3 via GPIO pins. I would like to obtain readings from those sensors via a python application. If this possible with a python app captured in a snap? | 09:22 |
| zyga-ubuntu | ashwind: hey, is your snap using the right interfaces? is it a service running as root or a command running as your user? | 09:24 |
| ashwind | I haven't fully implemented to snap yet. | 09:25 |
| ashwind | I just saw that gpio pin access is restrcted | 09:25 |
| ashwind | https://snapcraft.io/docs/reference/interfaces | 09:25 |
| zyga-ubuntu | ashwind: using the right interface you can definitely use GPIOs | 09:26 |
| ashwind | oh awesome, please advise | 09:26 |
| zyga-ubuntu | ashwind: the way this works is that a given snap can be given rights to use a restricted interface | 09:26 |
| zyga-ubuntu | ashwind: implement your snap as you would normally | 09:26 |
| ashwind | ok done | 09:27 |
| zyga-ubuntu | ashwind: installation instructions for a given device should show how to connect the right GPIO pins correctly | 09:27 |
| zyga-ubuntu | ashwind: for specific devices this will be available as a gadget feature (the gadget can pre-connect things correctly) | 09:27 |
| zyga-ubuntu | ashwind: auto-connect is not that useful for GPIOs because there are typically plenty of them | 09:27 |
| zyga-ubuntu | (and you get access to specific pins, not to all of them in general) | 09:28 |
| zyga-ubuntu | and because this differs from device to device and auto-connect logic is not smart enough to know which one is the right one | 09:28 |
| ogra_ | mvo, yeah | 09:32 |
| ogra_ | mvo, well, actually *all* empty ... | 09:33 |
| mvo | ogra_: hm? even current? | 09:34 |
| ogra_ | yes | 09:34 |
| ogra_ | ogra@anubis:~/datengrab/pi3$ sudo ls -l /root/snap/core/current | 09:35 |
| ogra_ | lrwxrwxrwx 1 root root 4 Sep 13 22:59 /root/snap/core/current -> 2925 | 09:35 |
| ogra_ | ogra@anubis:~/datengrab/pi3$ sudo ls -l /root/snap/core/current/ | 09:35 |
| ogra_ | insgesamt 0 | 09:35 |
| mvo | ogra_: ok, so there is something else going on, that explains why I can't reproduce it probably | 09:35 |
| ogra_ | thhis system has been usinng snaps since day one, but there is no ubuntu-core dir theer | 09:36 |
| mvo | ogra_: and this is on the running system? | 09:36 |
| ogra_ | thats my desktop macine | 09:36 |
| ogra_ | *machine | 09:36 |
| mvo | ogra_: ohhhh, these are your data dirs | 09:37 |
| ogra_ | (so yes) | 09:37 |
| mvo | ogra_: sorry, I misunderstood | 09:37 |
| ogra_ | right | 09:37 |
| ogra_ | well ... roots data dirs | 09:37 |
| pedronis | didn't we have a complicated discussion about removing those | 09:37 |
| ogra_ | not hamful, just wasting inodes ... but still ugly | 09:37 |
| pedronis | they are not easy to find across distros | 09:38 |
| pedronis | and root indeed in a special case | 09:38 |
| pedronis | I think we look only for /home/* atm | 09:38 |
| ogra_ | you mean /root isnt root in soome distros ? | 09:38 |
| pedronis | no that homedirs are not quite in the same place | 09:38 |
| ogra_ | (why do we even create them ?) | 09:38 |
| ogra_ | are they relevant for anything ? | 09:39 |
| pedronis | probably they get created when we run the configure hook? | 09:39 |
| ashwind | zyga-ubuntu: so i implemented my snap to be of type "app", do i need to change it to "gadget"? I see a pi3-gadget git repo https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml, how does this relate? | 09:39 |
| ogra_ | i dont think core would ever wite to them | 09:39 |
| pedronis | or maybe we are not lazy at all | 09:39 |
| pedronis | don't remember | 09:39 |
| pedronis | mvo: I'm around if you want to chat btw, let me know | 09:41 |
| ogra_ | looking at /root/snap core os the only snap with that behaviur | 09:41 |
| ogra_ | *core is | 09:41 |
| mvo | pedronis: yeah, one minute and I'm ready | 09:41 |
| pedronis | ogra_: I suspect it's a consquence of running the configure hook | 09:42 |
| ogra_ | all other packages remove the dirs on uninstall/refresh | 09:42 |
| pedronis | atm | 09:42 |
| ogra_ | might be that this is what creates them ... but the bug seems to be in te emove code | 09:42 |
| ogra_ | *remove | 09:42 |
| pedronis | as I said the remove code does only /home/*/snap/... | 09:42 |
| pedronis | afaik | 09:43 |
| pedronis | we discussed improving it | 09:43 |
| pedronis | but I think it was postponed | 09:43 |
| pedronis | and root ends up like this | 09:43 |
| ogra_ | yeah, it isnt critical or anything | 09:43 |
| mvo | pedronis: I have a look, looks trivial to include /root as a speical case | 09:43 |
| mvo | even if not perfect | 09:43 |
| ashwind | zyga-ubuntu: hmm let me read up, thanks! | 09:49 |
| phil_m | zyga-suse: I'd to go. Keep me updated via email on the snappy progress on Manjaro. If needed I can package it, when done. | 09:50 |
| zyga-ubuntu | re | 09:57 |
| zyga-ubuntu | ashwind: no, you should keep your snap as "app" | 09:58 |
| zyga-ubuntu | sorry i was on the phone | 09:58 |
| ogra_ | hmm, do we have any dir in /run that a dameon can write to and that i can see as normal user ? | 10:07 |
| zyga-ubuntu | ogra_: $XDG_RUNTIME_DIR perhaps but not sure | 10:08 |
| ogra_ | zyga-ubuntu, well, that seems tio be hidden from the otside world (or being deleted when i exist "snap run --shell" | 10:10 |
| ogra_ | ) | 10:10 |
| ogra_ | but i found a solution ... | 10:11 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| ogra_ | zyga-ubuntu, your initrd tests make everything in core-build explode ... | 10:39 |
| ogra_ | $ $CHROOT_RUN sh -c 'cd build/initramfs/testing; LC_ALL=C.UTF-8 ./aaa-tests.py --verbose' | 10:39 |
| ogra_ | warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] | 10:39 |
| ogra_ | test init process did not signal boot-ok | 10:39 |
| ackk | mvo, so one thing I'm not totally sure about that PR for socket activation is whether it's better to keep the socket-mode as a string or an integer | 10:44 |
| mvo | ogra_, pedronis: fwiw, I am poking a bit at the user data thing for root/ and I think I'm on a good course | 10:44 |
| ogra_ | yay | 10:44 |
| ackk | mvo, declaring it as an int in the snapcraft schema makes it render in the snap as decimal, not octal | 10:45 |
| mvo | ackk: yeah, I would prefer a string for this reason, unless there is yaml magic to make it render in the natural 0xxx notation | 10:45 |
| ackk | mvo, ok, then I can just revert the last commit (I had initially it as a string) | 10:46 |
| mvo | ogra_: I think its even buggy in the forward-data copy case for root :/ anyway, I am looking | 10:46 |
| * zyga-ubuntu -> lunch | 10:46 | |
| mvo | ackk: sounds good, we will also need input from niemeyer on your socket activation PR as it touches the yaml and we need sign off for that :) | 10:46 |
| zyga-ubuntu | ogra_: pull master | 10:46 |
| zyga-ubuntu | ogra_: it was fixed now | 10:47 |
| ackk | mvo, ok | 10:47 |
| ogra_ | zyga-ubuntu, well, i'm looking at master tests ... but if it is fixed now it is fine | 10:48 |
| ogra_ | zyga-ubuntu, mvo how did you guys get travis to do anything again ? it hasnt even started tests for a while | 10:49 |
| zyga-suse | ogra_: it started instantly for me | 10:50 |
| zyga-suse | ogra_: no idea | 10:50 |
| zyga-suse | ogra_: maybe it hasn't been merged, there should be a PR open | 10:50 |
| zyga-suse | ogra_: please look, I'm trying not to starve today | 10:50 |
| ogra_ | well it timed uot waiting fr starting the tests fr like 2 months now | 10:50 |
| ogra_ | unrealated to the tests ... travis never started at all | 10:51 |
| ogra_ | so someone has done something too make travis actually start again | 10:51 |
| zyga-suse | ogra_: I started about a dozen jobs on core-build today | 10:51 |
| ogra_ | zyga-suse, right i did that nce a week for the last few weeks but travis only timed uot before even starting | 10:52 |
| ogra_ | something has changed that suddenly allows it to run tests again ... did we pay extra $$$ ? | 10:52 |
| zyga-suse | nope, perhaps just smaller load | 10:52 |
| ogra_ | well, then better watch snapd now ... if it is load related we migth steal cycles from other snapcore trees | 10:53 |
| ogra_ | :) | 10:53 |
| ogra_ | (this is not what i understand as reliable CI :P ) | 10:54 |
| zyga-suse | free, reliable, nice, | 10:55 |
| zyga-suse | pick two | 10:55 |
| ogra_ | haha | 10:55 |
| mup | PR snapd#3866 closed: many: implement fetching sections and package names periodically <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3866> | 11:08 |
| * Chipaca dances | 11:08 | |
| Chipaca | also, glad to have been into london yesterday and not today | 11:08 |
| * Chipaca dances a bit more | 11:08 | |
| * zyga-ubuntu hugs Chipaca | 11:14 | |
| zyga-ubuntu | barbaric times we live in | 11:14 |
| * zyga-ubuntu resumes coding | 11:25 | |
| ackk | mvo, updated that PR, fwiw | 11:47 |
| pedronis | mvo: added a couple comments, some we already discused to the snap-repair list/show PR | 11:54 |
| ogra_ | zyga-ubuntu, mvo, can we agree that "release" PRs in core-build simply get merged (i saw you guys did an actual review, i think this is pointless given it is only a changelog entry, the actual changes have been reviewed before anyway) | 12:03 |
| ogra_ | (and if the changelog is broken the loacla dpkg-buildpackage would error anyway and you couldnt upload) | 12:03 |
| ogra_ | *local | 12:03 |
| ogra_ | i.e. https://github.com/snapcore/core-build/pull/21 | 12:04 |
| mup | PR core-build#21: Release 0.7.43+ppa23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/21> | 12:04 |
| ogra_ | (reviews just waste time here IMHO) | 12:04 |
| ogra_ | indeed only if it is just the changelog bump :) | 12:05 |
| zyga-ubuntu | ogra_: well, I think it's good for spotting typos but I agree in general; given that those should be reviewed very quickly I wouldn't change much thoug | 12:06 |
| ogra_ | well, lets say they are "optional" then :) | 12:07 |
| cachio | mvo, hi | 12:11 |
| cachio | in rc3 it is failing to uninstall the network-manager | 12:11 |
| cachio | for db and pi3 | 12:11 |
| cachio | I can reproduce it running test tests/regression/lp-1606277 and then any other test | 12:12 |
| mvo | cachio: thanks, what is the error output? | 12:13 |
| cachio | mvo, https://paste.ubuntu.com/25540183/ | 12:14 |
| cachio | it works fine for example on pi2 | 12:14 |
| cachio | but for pi3 and db we get the same error | 12:14 |
| ogra_ | well, both have wlan | 12:15 |
| ogra_ | while pi2 doesnt | 12:15 |
| ogra_ | the log isnt really helpful since it only shows the final timeout after snap remove n-m | 12:16 |
| ogra_ | did you check what happens when you manually install/configure/remove n-m on such a device ? | 12:16 |
| mvo | cachio: hm, I would bet syscall filtering related, could you paste the dmesg output? | 12:16 |
| cachio | mvo, give me 5 please | 12:16 |
| mvo | cachio: oh, hold on, its dying on rmeove, right? | 12:16 |
| cachio | mvo, yes | 12:17 |
| mvo | cachio: in this case ogra_ may have a better theory, still the dmesg/syslog output will be helpful | 12:17 |
| ogra_ | i guess it cant deconfigure the wlan device properly | 12:17 |
| mvo | cachio: also, does reverting core fix it? wonder if it might be n-m related but the last stable is ~5 weeks old it seems so that is unlikely | 12:18 |
| cachio | mvo, give me 5 please, I am running the tests with -debug | 12:20 |
| mvo | cachio: thank you, no rush :) | 12:21 |
| mup | PR snapd#3921 opened: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3921> | 12:24 |
| jdstrand | mvo: fyi, ^ | 12:26 |
| jdstrand | mvo: and hi! :) | 12:26 |
| mvo | jdstrand: nice, thank you. and good morning! | 12:28 |
| cachio | mvo, dmesg https://paste.ubuntu.com/25540261/ | 12:35 |
| cachio | ogra_, for you too :) | 12:37 |
| cachio | this is the syslog when the error happened https://paste.ubuntu.com/25540285/ | 12:40 |
| === cachio is now known as cachio- | ||
| ogra_ | cachio_, can we get the full syslog without the tail -50 ? | 12:47 |
| cachio_ | yes | 12:48 |
| ogra_ | "Failed to initialize control interface '/run/wpa_supplicant'.#012You may have another wpa_supplicant process already running or the file was#012left by an unclean termination of wpa_supplicant" | 12:48 |
| mup | PR #12: Bugfix/lp1480248 test reenable <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/12> | 12:48 |
| ogra_ | that looks suspicious | 12:48 |
| ogra_ | boo ... mup | 12:49 |
| mup | PR snapd#3922 opened: snapstate: deal with snap user data in the /root/ directory <Created by mvo5> <https://github.com/snapcore/snapd/pull/3922> | 12:50 |
| * Chipaca reads http://schd.ws/hosted_files/ossna2017/91/Linuxcon%202017%20NERF.pdf and doesn't know if he should show it to ogra_, or hide him from it | 12:51 | |
| cachio_ | ogra_, https://paste.ubuntu.com/25540337/ | 12:52 |
| mvo | zyga-ubuntu: the error in 3920 is very confusing | 12:53 |
| mvo | zyga-ubuntu: no /snap/core/current on core | 12:53 |
| Chipaca | sergiusens: http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/ | 12:53 |
| ogra_ | cachio_, there you go ... the wlan got configured by systemd-networkd already (via some netplan setup i guess) ... i assume that is why n-m gets confused | 12:53 |
| Chipaca | sergiusens: could/should snapcraft warn about that? | 12:53 |
| mup | PR snapd#3923 opened: asserts,cmd/snap-repair: represent RepairID internally as an int <Created by pedronis> <https://github.com/snapcore/snapd/pull/3923> | 12:53 |
| pedronis | mvo: ^ | 12:53 |
| zyga-ubuntu | mvo: are we hit by a bad build of core? | 12:53 |
| mvo | pedronis: nice | 12:55 |
| mvo | zyga-ubuntu: not sure, I try to reproduce now | 12:55 |
| sergiusens | Chipaca about what? | 12:56 |
| * sergiusens doesn't know who anyone is with lacking avatars ;-) | 12:57 | |
| ackk | it is at all possible to install a lxd local snap? I get permission denied messages when it starts about reading /proc/self/attr/current and running aa-exec | 12:57 |
| ackk | (I did connect the lxd-support plug) | 12:57 |
| cachio_ | ogra_, that could be the reason, do you need any other log' | 12:58 |
| cachio_ | '' | 12:58 |
| cachio_ | ? | 12:58 |
| ogra_ | cachio_, well, not sure what to do here ... did your testing change that it leaves the wlan netplan config in place before installing nm where it didnt do that before or some such ? | 12:59 |
| ogra_ | nothing should have changed on core or in n-m in that area in ages | 12:59 |
| Chipaca | sergiusens: about a list of evil fake/typo packages in pypi | 13:00 |
| cachio_ | ogra_, no | 13:00 |
| Son_Goku | zyga-ubuntu: base-ish snaps for Fedora, openSUSE, and Mageia on demand: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap/pipelines/11803392 :D | 13:00 |
| * zyga-ubuntu hugs Son_Goku | 13:06 | |
| zyga-ubuntu | one small step for snap | 13:06 |
| Son_Goku | I need to rewrite the tool to use the DNF API instead of the CLI (better control over the solver) | 13:06 |
| Son_Goku | but it's a doing it | 13:07 |
| sergiusens | Chipaca oh, I think pip and PyPI itself should warn about that! | 13:08 |
| Son_Goku | zyga-ubuntu: note that it won't produce bootable core snaps either :( | 13:11 |
| ogra_ | cachio_, as a hack/workaround you could simply try to remove the file in /run or kill wpa_supplicant before installing n-m or some such | 13:12 |
| ogra_ | this is clearly not a use case we support (having two config mechanisms manage the same device) | 13:12 |
| ogra_ | mvo, ^^^ ? | 13:12 |
| ogra_ | it is either netplan or network-manager ... (netplan has a specific config option for this to hand off management of the device to n-m) | 13:14 |
| ogra_ | https://wiki.ubuntu.com/Netplan has info about this | 13:18 |
| ogra_ | you will need to switch the renderer option before installing n-m | 13:19 |
| mvo | ogra_: thanks, I was in a meeting. btw, PR with the fix for your /root/snap/ stuff is up. unfortunately it will not cleanup the past but at least it should stop doing so from now on (well, $now==when-it-gets-merged) | 13:29 |
| ogra_ | mvo, well, it is just cosmetic anyway | 13:30 |
| mvo | ogra_: sort of, there is a real bug there too, the userdata of /root does not get copied forward on refresh - so its good that you brought it up | 13:30 |
| ogra_ | heh, great | 13:31 |
| pedronis | mvo: I'm super confused, in my branch go vet seems to think the RepairID() is still a string in some places but test pass | 13:31 |
| cachio_ | ogra_, ok, i'll see how to rewrite that test in this case | 13:32 |
| cachio_ | thanks | 13:32 |
| ogra_ | cachio_, well, it shouold have failed before, interesting that it did not | 13:32 |
| ogra_ | also ... the n-m snap should probably be fixed to not steal an already otherwise managed interface | 13:33 |
| cachio_ | ogra_, perhaps it is a new test | 13:33 |
| cachio_ | i'll research a bit on that | 13:33 |
| ogra_ | ah | 13:33 |
| zyga-ubuntu | Son_Goku: bootable snaps are further down the line | 13:34 |
| zyga-ubuntu | Son_Goku: I would be happy with a working base | 13:34 |
| === Guest28588 is now known as ^arcade_droid | ||
| pedronis | mvo: niemeyer: I'm getting this (stalled run/no ouput): https://travis-ci.org/snapcore/snapd/builds/275875794?utm_source=github_status&utm_medium=notification | 13:56 |
| pedronis | there is nothing super interesting in the PR | 13:56 |
| pedronis | afaict | 13:58 |
| mup | PR snapd#3924 opened: asserts,cmd/snap-repair: introduce a mandatory summary for repairs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3924> | 13:58 |
| mvo | pedronis: strange, I saw this in some other PR recently too but it seems to be very rare | 13:58 |
| pedronis | mvo: I got it twice in a row | 13:58 |
| niemeyer | pedronis: Can't think of any reasonable reason | 13:59 |
| niemeyer | pedronis: Ah, now I can | 14:00 |
| niemeyer | pedronis: We have 100% utilization right now | 14:00 |
| niemeyer | pedronis: On Linode | 14:00 |
| niemeyer | Interestingly, a lot of machines are running for ~1h | 14:01 |
| niemeyer | Every machine I click, actually | 14:01 |
| niemeyer | This is below the halt timeout | 14:02 |
| niemeyer | And above what Travis would accept | 14:02 |
| niemeyer | Something strange happening with Travis... | 14:03 |
| niemeyer | "Ran for 5 hrs 29 min 42 sec" | 14:04 |
| niemeyer | I don't think that's true, somehow :) | 14:04 |
| ogra_ | niemeyer, i have that since weeks for the less frequently changing trees like core-build and core ... it will eventually time out with no results | 14:04 |
| ogra_ | (the tests dont even start) | 14:05 |
| niemeyer | https://usercontent.irccloud-cdn.com/file/wHpSvg9Y/image.png | 14:06 |
| ogra_ | pedronis, see my discussion with zyga-ubuntu above (around 12:50) | 14:06 |
| ogra_ | the verdict was: | 14:07 |
| ogra_ | zyga-suse> free, reliable, nice, | 14:07 |
| ogra_ | <zyga-suse> pick two | 14:07 |
| ogra_ | <ogra_> haha | 14:07 |
| ogra_ | :P | 14:07 |
| niemeyer | Definitely something bogus happening there.. look at this screenshot | 14:07 |
| niemeyer | It merged two independent runs together | 14:07 |
| ogra_ | oh | 14:07 |
| ogra_ | thats definitely more than i get | 14:07 |
| ogra_ | it doesnt even produce a log | 14:07 |
| niemeyer | ogra_: These cases are generally Travis being busy | 14:08 |
| ogra_ | looks more like a hang with the test itself somehow | 14:08 |
| niemeyer | ogra_: Either in general, or with our own project (too much activity, long queues) | 14:08 |
| ogra_ | yeah | 14:08 |
| ogra_ | one can usually work around by pulling the tree and PR into a user fork and have the tests run there then | 14:09 |
| ogra_ | i guess it is because it is tied to the snapcore organization | 14:09 |
| * zyga-ubuntu -> coffee | 14:14 | |
| niemeyer | pedronis: Something else is wrong.. found machines allocated by those stale Travis jobs.. they are there, allocated and sitting idle | 14:19 |
| niemeyer | I'm finding evidence that the machine was updating too | 14:20 |
| niemeyer | Installing things that spread requested, likely | 14:21 |
| niemeyer | Yeah.. | 14:21 |
| niemeyer | The best theory at the moment is that there was overutilization, machines were taking a while to actually allocate, and that cause them to go over the 10 mins without output of Travis, which meant they were killed while the machines were allocated, which caused more overutilization, and the problem cycles | 14:24 |
| niemeyer | In a few minutes we'll over our 2h halt timeout threshold.. let's see what happens | 14:25 |
| ogra_ | is anyone living close to the github datacenter so he could watch out for an atomic cloud ? | 14:29 |
| mup | PR snapd#3925 opened: snap-repair: implement `snap-repair {done,skip,retry}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3925> | 14:36 |
| === cory_fu_ is now known as cory_fu | ||
| niemeyer | If the theory above is confirmed, I think we should lower the halt timeout | 14:42 |
| === ikey is now known as ikey|work | ||
| niemeyer | No, something else must be causing those issues: | 14:51 |
| niemeyer | https://usercontent.irccloud-cdn.com/file/n6Bkt5zj/image.png | 14:52 |
| niemeyer | It froze mid-way through.. the only thing that might justify that is a bug in spread, or a bug in Travis | 14:52 |
| niemeyer | Spread would definitely display a warning if it was taking too long, and it's hard to believe that would happen in all 20 machines anyway, after they're already allocated | 14:53 |
| niemeyer | The fact we're getting this issue across multiple runs just now would hint at a problem on the infra side instead of Spread | 14:53 |
| === ShalokShalom_ is now known as ShalokShalom | ||
| mup | PR snapd#3926 opened: snap: implement `snap {repair,repairs}` and pass-through to snap-repair <Created by mvo5> <https://github.com/snapcore/snapd/pull/3926> | 15:03 |
| mup | PR snapd#3921 closed: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf for 2.28 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3921> | 15:05 |
| mvo | cachio_: any news about the network-manager issue ? mostly curious | 15:11 |
| cachio_ | mvo, no, ogra has a theory | 15:11 |
| cachio_ | mvo, seems to be a conflict between network-manager and netplan | 15:12 |
| cachio_ | mvo, if it is true, we should see what to do with those tests on pi3 and db | 15:13 |
| cachio_ | because when it fails, it breaks the wifi connection so i loose the conectivity | 15:13 |
| mvo | cachio_: aha, do we have a newer netplan in the newer core, could this be the reason? and does the problem go away with an older go? | 15:15 |
| === cachio_ is now known as cachio_lunch | ||
| cachio_lunch | mvo, not sure | 15:15 |
| cachio_lunch | we could try to create an image with the old one | 15:16 |
| mvo | hm, looks like the last netplan upload happend a while ago so not super likely | 15:16 |
| mvo | or just snap refresh --stable core | 15:16 |
| mvo | and run the particular test again | 15:16 |
| ogra_ | mvo, that test should have never been un like it does atm | 15:16 |
| cachio_lunch | mvo, is this network-manager test old? perhaps there was a change in the snap that is affecting the tests | 15:16 |
| ogra_ | mvo, if nplan manages the interface n-m can not ... if you want nplan and n-m to work together yu need a special nplan config that sets the renderer to n-m | 15:17 |
| ogra_ | mvo, see the renderer stuff at https://wiki.ubuntu.com/Netplan | 15:17 |
| ogra_ | mvo, the point here is though that n-m should ignore ine interface if nplan manages it, but it doesnt ... or that nplan needs a changed config that actually switches too the rigtht renderer ... now dont ask me why it only fails now | 15:18 |
| mvo | ogra_: well, that may well be, but why are things failing now and not before? | 15:19 |
| ogra_ | i have no idea really ... was that est always there ? | 15:19 |
| ogra_ | *test | 15:19 |
| ogra_ | or was it just recently added | 15:19 |
| mvo | ogra_: the test is old, but the test does not deal with n-m, something in prepare is dealing with it and the question is also why | 15:19 |
| ogra_ | all i can say is that it is completely wroong as it is now | 15:19 |
| mvo | cachio_lunch: the full test output might be nice, i.e. what tests ran before this one | 15:20 |
| ogra_ | mvo, well, the interface is aleady configured by systemd-networkd at the point the n-m install runs | 15:20 |
| ogra_ | so what prepare does seems to be to generate a nplan systemd-networkd config | 15:21 |
| ogra_ | and then blindly install n-m on top | 15:21 |
| ogra_ | which results in having two tools wrangle over the ownership | 15:21 |
| ogra_ | and n-m uninstall n-m tries to stop wpa_supplicant but does not own the file in /run so it cant really stooop it and hanfs | 15:22 |
| ogra_ | *hangs | 15:22 |
| mvo | ogra_: hm, that is interessting - is there a way to make this work, i.e. telling nm to not ouch the already-managed interfaces? | 15:23 |
| ogra_ | not anymore, but nplan can swirtch to the n-m renderer and reconfigure the device | 15:23 |
| ogra_ | n-m used too have an ignore thing in the past for ifupdown ... but i think thats gone | 15:23 |
| mvo | ogra_: hm, that sounds not ideal, I think I will switch the test to not run on the db then | 15:24 |
| ogra_ | yeah | 15:24 |
| ogra_ | same for the pi3 | 15:24 |
| ogra_ | the prob is that you need an interface at all to actually install n-m ... so there needs to be an initial configuration | 15:24 |
| ogra_ | and you can only switch the config once n-m is there ... by then they are already fighting over ownership though | 15:25 |
| mvo | ok | 15:28 |
| mup | PR snapd#3927 opened: tests: only run tests/regression/nmcli on amd64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3927> | 15:28 |
| ogra_ | mvo, is the same test unning on x86 ? | 15:29 |
| ogra_ | (i wonder why it doesnt fails therer if it gets run there) | 15:29 |
| * ogra_ goes and loks up where he can get single chery MX switches to fix his o and r on the kbd | 15:31 | |
| pedronis | mvo: did you see my small comments in the snap-repair list/show PR ? | 15:36 |
| niemeyer | I don't know what to take from this Travis issue.. | 15:41 |
| bschaefer | ogra_, so fun work around, manually unpack the overlayfs into system-boot (AlbertA found this) | 15:41 |
| niemeyer | I'll take the kid to school and be back to investigate more | 15:41 |
| ogra_ | bschaefer, overlayfs ? you mean overlays.tgz ? | 15:41 |
| bschaefer | yeah | 15:42 |
| ogra_ | bschaefer, that kind of points to a discrepancy between gadget and kernel snap on your device then | 15:42 |
| ogra_ | which is weird | 15:42 |
| bschaefer | yeah AlbertA hit the same issue as well after a core upgrade | 15:42 |
| ogra_ | can you paste me the "snap list" output from your pi ? | 15:43 |
| bschaefer | ogra_, http://paste.ubuntu.com/25541086/ | 15:44 |
| AlbertA | ogra_: it seems somehow after core upgrade | 15:44 |
| bschaefer | ive not seen kernel or gadget update for this last week | 15:44 |
| bschaefer | but core upgrades everyday | 15:44 |
| AlbertA | that partition gets corrupted and you get a bunch of fsck record files | 15:44 |
| AlbertA | and "overlays" folder disappears | 15:44 |
| ogra_ | AlbertA, well, the gadget carries the original overlays and the kernel carries the verlays.tgz | 15:44 |
| ogra_ | URGH! | 15:45 |
| ogra_ | now thats completely different | 15:45 |
| ogra_ | so your system-boot partition gets trashed | 15:45 |
| bschaefer | yeah i had a bunch of *.rec files | 15:45 |
| ogra_ | well, i can reproduce it here now but i dont have a trashed partition | 15:46 |
| ogra_ | ogra@localhost:~$ ls -l /dev/dri | 15:46 |
| ogra_ | ls: cannot access '/dev/dri': No such file or directory | 15:46 |
| bschaefer | ogra_, this started umm | 15:46 |
| * bschaefer gets version | 15:47 | |
| ogra_ | ogra@localhost:~$ ls -l /boot/uboot/overlays/|grep -v dtb | 15:47 |
| ogra_ | total 172 | 15:47 |
| ogra_ | ogra@localhost:~$ | 15:47 |
| ogra_ | i only have dtb files in there ... and als no other trace of fsck issue | 15:47 |
| bschaefer | the upgrade to 22913 | 15:48 |
| bschaefer | 2913* | 15:48 |
| bschaefer | a few days ago | 15:48 |
| ogra_ | well, it is unrelated t cre itself | 15:48 |
| ogra_ | *core | 15:48 |
| bschaefer | o hmm seemed like the only thing changing | 15:48 |
| ogra_ | a core update updates your bootlader config | 15:48 |
| mup | PR snapd#3919 closed: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3919> | 15:48 |
| ogra_ | the fsck might be related t that update ... but not to any content of core | 15:49 |
| AlbertA | ogra_: yeah it doesn't look like the whole partition is trashed... | 15:49 |
| ogra_ | but the other thing is that i can properly repro it here but without any corruption or fsck issues | 15:49 |
| AlbertA | only "overlays" dir for some reason | 15:49 |
| ogra_ | theer must be some difference between kernel and gadget dtbs if extracting the overlays helps | 15:49 |
| bschaefer | i could still boot/ssh into it and move around | 15:49 |
| bschaefer | and install snaps etc | 15:50 |
| bschaefer | didnt see anything else wrong with the fs | 15:50 |
| AlbertA | bschaefer: ogra_: right I can still boot up the device just no VC4 is available (as expected since "overlays" dissapears) | 15:50 |
| AlbertA | and this was without installing any snaps...simply flashed a fresh image (the one from yesterday), booted, core upgraded, rebooted. Then after a second reboot | 15:51 |
| AlbertA | I see the issue | 15:52 |
| ogra_ | right ... me too | 15:52 |
| ogra_ | but without any corruption in my case | 15:52 |
| AlbertA | oh interesting | 15:52 |
| ogra_ | ogra@localhost:~$ tar xf /snap/pi2-kernel/current/dtbs/overlays.tgz | 15:53 |
| ogra_ | ogra@localhost:~$ diff -ruN /boot/uboot/overlays/vc4-kms-v3d-overlay.dtb overlays/vc4-kms-v3d-overlay.dtb | 15:53 |
| ogra_ | ogra@localhost:~$ md5sum /boot/uboot/overlays/vc4-kms-v3d-overlay.dtb | 15:53 |
| ogra_ | 43ee3abf64b77fc3ba837817a7eb51f8 /boot/uboot/overlays/vc4-kms-v3d-overlay.dtb | 15:53 |
| ogra_ | ogra@localhost:~$ md5sum overlays/vc4-kms-v3d-overlay.dtb | 15:53 |
| ogra_ | 43ee3abf64b77fc3ba837817a7eb51f8 overlays/vc4-kms-v3d-overlay.dtb | 15:53 |
| ogra_ | ogra@localhost:~$ | 15:53 |
| ogra_ | and the files are identical ... | 15:53 |
| ogra_ | yet ... | 15:53 |
| phil_m | zyga-suse, zyga-ubuntu: and some progress made within Manjaro? | 15:53 |
| ogra_ | ogra@localhost:~$ ls -l /dev/dri | 15:53 |
| ogra_ | ls: cannot access '/dev/dri': No such file or directory | 15:53 |
| ogra_ | ogra@localhost:~$ | 15:53 |
| ogra_ | oh | 15:53 |
| ogra_ | one sec | 15:53 |
| ogra_ | i'm using a special gadget here | 15:54 |
| ogra_ | ogra@localhost:~$ grep vc4-kms-v3d-overlay.dtb /boot/uboot/config.txt | 15:54 |
| ogra_ | ogra@localhost:~$ | 15:54 |
| ogra_ | ok | 15:54 |
| === JanC_ is now known as JanC | ||
| ogra_ | ah, grepping for the wrong thing wont help | 15:55 |
| mvo | pedronis: I have not checked in detail, I will either address them later today or monday morning. but thanks for them in any case ! | 15:55 |
| ogra_ | ogra@localhost:~$ grep vc4-kms-v3d /boot/uboot/config.txt | 15:55 |
| ogra_ | #dtoverlay=vc4-kms-v3d | 15:55 |
| ogra_ | ogra@localhost:~$ | 15:55 |
| mvo | ogra_: yes, tests run on amd64 VM, however that does not have wifi | 15:55 |
| ogra_ | mvo, ah ! yeah, then they wont wrangle over wpa_supplicant files indeed | 15:56 |
| ogra_ | AlbertA, bschaefer, well, ok, i cant repro it *'yet* but will turn my bard back to use the vc4 driver now and check tomorrown after the next core update | 15:57 |
| ogra_ | *board | 15:58 |
| AlbertA | ogra_: thanks! | 15:58 |
| ogra_ | i definitely dont get any corruption here though ... and havent in a long time | 15:58 |
| ogra_ | are your SD cards old ? | 15:58 |
| bschaefer | ogra_, nope i just got my this last week | 15:59 |
| bschaefer | since my old one was ... bad | 15:59 |
| bschaefer | though i have reflashed it ... ~20 times this week | 15:59 |
| AlbertA | ogra_: I have a sandisk 32GB maybe about a year old now | 15:59 |
| ogra_ | (when runnign edge, every core update will write to the same spot on the card, so running edge can wear them out faster) | 15:59 |
| ogra_ | (that is ... for the bootloader config update ...) | 16:00 |
| AlbertA | ogra_: oh interesting idea.. yeah maybe those particular blocks are going bad, seems plausible | 16:00 |
| ogra_ | AlbertA, but that doesnt explain why bschaefer woould see it ... | 16:01 |
| mup | PR snapd#3928 opened: interfaces/system-observe: allow clients to enumerate DBus connection names <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3928> | 16:01 |
| noChance | We need to stop China from killing Bitcoin. The more people use BTCs the harder it will be for China to snuff it... https://freebitco.in/?r=7247637 -> get your own free Bitcoins. | 16:01 |
| ogra_ | also ... my 4GB card that i have currently in use is rather in the 3-5y ealm and running edge daily sincer abut a yea now | 16:02 |
| bschaefer | well that would suck, ive 32GB | 16:02 |
| === cachio_lunch is now known as cachio | ||
| ogra_ | i have only one out of like 30 cards here that i ave yet managed to wear out | 16:02 |
| bschaefer | same as AlbertA but yeah i got these over last weekend | 16:02 |
| ogra_ | so wear levelling is always my last guess after all ... | 16:03 |
| bschaefer | ogra_, i do like that /writable seems to resize now to the fullsize of the SD card now | 16:03 |
| * bschaefer use to run out of room a bunch due to the image size | 16:03 | |
| ogra_ | yeah, there was a bug for a short time ... but thats fixed now | 16:03 |
| ogra_ | the build did pull in the wrong initamfs-tools | 16:03 |
| bschaefer | ogra_, so future testing of this sort of thing, checking the dtbs in /boot? | 16:05 |
| ogra_ | bschaefer, welll, finding the reason why yu both get that breakage ... | 16:06 |
| ogra_ | the whole overlays stuff will change soon with the ability to upgrrade gadgets | 16:06 |
| bschaefer | o nice | 16:07 |
| bschaefer | yeah we do happen to have the same SD card IIRC | 16:07 |
| ogra_ | it isnt ... by chance listed with a red marker in teh table at http://elinux.org/RPi_SD_cards ? | 16:08 |
| ogra_ | (seems theer are a bunch of snadisk cards that dont play well with the Pi contoller) | 16:09 |
| bschaefer | ogra_, all the sandisk 32GB class 10 are green | 16:09 |
| ogra_ | ok | 16:09 |
| bschaefer | yeah i bet my older SD 8 GB was red on this... | 16:09 |
| bschaefer | class 2 or 4 | 16:10 |
| ogra_ | well, let me see whyt my system des here with the next update | 16:11 |
| ogra_ | also ... please bring the cards to NY ... i'lll have a Pi with me to play with | 16:11 |
| bschaefer | o yeah good idea | 16:11 |
| ogra_ | (in case i dont find the cause til then indeed) | 16:11 |
| bschaefer | ill bring my rapi3 + sd cards as well | 16:11 |
| bschaefer | dont have a monitor though :) | 16:12 |
| ogra_ | cool | 16:12 |
| bschaefer | there should be something about | 16:12 |
| ogra_ | the hotel room will ;) | 16:12 |
| bschaefer | o yeah haha | 16:12 |
| ogra_ | worst case | 16:12 |
| niemeyer | More unrelated Travis issues... | 16:16 |
| niemeyer | https://travis-ci.org/snapcore/spread-cron/builds/274621786 | 16:16 |
| zyga-suse | phil_m: yes and no. I fixed all the other issues but at least inside vmware I cannot get opengl to work. I plan to investigate on real hardware tomorrow. | 16:21 |
| zyga-suse | phil_m: and in any case send a PR to github so that the package can be added in the initial version, | 16:22 |
| cachio | mvo, https://paste.ubuntu.com/25535960/ | 16:26 |
| cachio | https://paste.ubuntu.com/25536062/ | 16:27 |
| cachio | https://paste.ubuntu.com/25540165 | 16:27 |
| cachio | mvo, it failed in those 3 runs | 16:27 |
| cachio | for db and pi3 | 16:27 |
| mvo | cachio: yeah, i pushed a "fix" | 16:29 |
| cachio | pr' | 16:30 |
| cachio | ? | 16:30 |
| mvo | cachio: yeah | 16:30 |
| mvo | cachio: I say "fix" because the test is just skipped | 16:30 |
| phil_m | zyga-suse: ok. we will see. thx for the effort so far. | 16:30 |
| mvo | cachio: but thats ok, we cannot install n-m and netplan for wifi at the same time currently | 16:30 |
| cachio | mvo, good :) it is a way to fix it | 16:30 |
| ogra_ | well, we can surely work on a real fix and have netplan use the n-m renderer | 16:31 |
| ogra_ | but thats some wrk | 16:31 |
| ogra_ | *work | 16:31 |
| zyga-suse | mvo: all good? | 16:50 |
| mvo | zyga-suse: yes, no? | 16:51 |
| * zyga-suse is worried we all work on Fridays so late | 16:51 | |
| mup | PR snapd#3904 closed: tests: test the real "xdg-open" from the core snap <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3904> | 16:55 |
| ogra_ | zyga-suse, thats all just the bad weather and stuff :P | 17:04 |
| lutostag_ | the xdg-open was working for me on gnome until an update today (on artful/gnome-wayland), now it isnt... :/ | 17:09 |
| zyga-ubuntu | lutostag_: I think this is a known issue that mvo is addressing with another release | 17:10 |
| mvo | lutostag_: as a workaround "snap refresh --candidate core" should bring it back | 17:22 |
| lutostag_ | mvo: no joy on the refresh, https://paste.ubuntu.com/25541837/ but I am just glad someone is looking into it, thanks guys ;) | 17:32 |
| * zyga-suse takes a break to do something non-coding | 17:35 | |
| mvo | lutostag_: hm, that lxd error rings a bell, maybe zyga-ubuntu remembers the details once he is back | 17:40 |
| zyga-suse | hmmm, holly molly | 17:51 |
| zyga-suse | no idea | 17:51 |
| zyga-suse | is that inside lxd? | 17:51 |
| niemeyer | Travis is out of the equation, btw.. I can reproduce the problem locally too. It's either a bug in Spread or something in the Linode API.. | 18:00 |
| niemeyer | I'm guessing Linode needs to be involved somehow, since this has shown up without Spread changing | 18:01 |
| mvo | lutostag_: iirc we had this issue with older version of lxd, iirc when snap was run inside lxd. if that is the case, what version of lxd do you use (inside and outside?) | 18:27 |
| lutostag_ | mvo: outside, then inside https://paste.ubuntu.com/25542158/ | 18:29 |
| lutostag_ | although I was running the snap refresh core --candidate on the outside | 18:30 |
| mvo | lutostag_: thanks, I wonder if lxd 2.17 would help | 19:52 |
| === chihchun_afk is now known as chihchun | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
