[02:17] PR snapcraft#2692 opened: internal: unknown apt packages aren't installed [04:57] PR snapd#7272 closed: interfaces/bluez: enable communication between bluetoothd and meshd via dbus [05:23] PR snapd#7341 closed: many: introduce package seed and seedtest [05:24] PR snapd#7336 closed: tests: add debug section to interfaces-contacts-service [05:25] PR snapd#7316 closed: tests: add unit tests for cmd_whoami [05:44] zyga: looks like 7370 has some real spread failurs (just fyi, not urgent :) [06:40] PR snapd#7369 closed: overlord/snapstate: check channel names on install (2.41) [06:52] PR snapd#7344 closed: snapstate: use strutil.VersionCompare() in checkVersion() === pstolowski|afk is now known as pstolowski [07:02] morning [07:02] mvo: yeah, looking [07:03] mvo: I tested a smaller subset last night so perhaps there's some outcome of the change [07:03] that is not handled by the rest of the code [07:04] ahhh [07:04] interesting [07:04] it failed on opensuse 15 [07:04] perhaps unified cgroup does not have that feature there, let me look [07:04] it's odd that it only _sometimes_ failed though [07:04] that's very weird [07:05] PR snapd#7371 opened: snapstate: add comment to checkVersion vs strutil.VersionCompare [07:05] hey pstolowski and zyga ! good morning [07:05] btw [07:05] zyga: aha, yeah, I did not look at what system failed just noticed it looked legit [07:05] does anyone know what may be behind [07:05] shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory [07:05] it spams all the logs [07:06] zyga: I have not seen (at least consciously) this [07:45] mvo, pedronis i think we have at least one more issue wrt track/risks change, see https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769/7 [07:49] mvo, pedronis related to 2nd part of my reply, one issue is the migration of old state (which i suppose Chipaca's patch will cover?), second is simply `snap install ` which defaults to "stable" in the state and again will be reported as such with v2/snaps tracking-channel (and confuse GUI) [07:50] pstolowski: indeed, that looks like a problem [07:57] pstolowski: I am a bit confused [07:59] pstolowski: didn't you discuss this with them under https://github.com/snapcore/snapd/pull/7255 ? [07:59] PR #7255: store: use track/risk for "channel" name when parsing store details [08:01] pedronis: yes, and the channels map is as we discussed. but there is also channel name at the top level which i haven't touched (shown in the snippet from Robert in that forum post) [08:15] mvo: pstolowski: I start to think that the overall change was premature [08:17] pedronis: I was wondering the same, if we should just revert it for 2.41 [08:18] mvo: let's talk after the town hall [08:19] which change? [08:19] Chipaca: track/risk behavior change [08:20] Chipaca: https://github.com/snapcore/snapd/pull/7199 [08:20] PR #7199: overlord/snapstate: keep current track if only risk is specified [08:20] and all that descended from that [08:21] Chipaca: https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769/7 [08:21] I think we do want that change [08:21] but we really need to roll it out a bit more carefully [08:21] and right now we are scrambling a bit [08:22] given the amount of work we now see is missing, i agree it looks like it's shorter to roll it back [08:23] Chipaca: I also not sure while the change makes sense at the CLI level [08:23] whether it makes sense at the API level [08:23] which means API tweaks [08:37] does gnome-software do refreshes now? [08:40] pedronis: i don't think so [08:40] pedronis: why? [08:58] Chipaca: I'm confused why we did #7255 already [08:58] PR #7255: store: use track/risk for "channel" name when parsing store details [09:02] pedronis: this was believed to be transparent to the ubu/gnome store as discussed with Robert before, and not requiring any special-casing on their side.. anyway, i'm prepping a revert of all this [09:09] mvo: btw, the test-snapd-tools track 2.0 didn't work? [09:09] pstolowski: not yet, sry, let me pick this up again [09:12] pstolowski: ok, either we should have a chat with mvo and Chipaca to see where we stand [09:13] pstolowski: its open now [09:15] mvo: \o/ thy! [09:18] pedronis: pstolowski: reverting from 2.41, right? [09:19] Chipaca: yes, but we have many pieces to revert, and we need to talk what next [09:20] Chipaca: also if you started working on a patch, we will need it at some point, so don't throw it away [09:21] pedronis: was planning on stashing it for now [09:21] pedronis: OTOH i might finish it first, not sure [09:21] Chipaca: if you are close, please finish it [09:25] Chipaca: i prepared revert for master with a plan to propose again after fixes. and yes revert for 2.41 as well [09:26] Chipaca: and i'd like to discuss that patch in the light of what was discussed this morning [09:27] Chipaca: pstolowski: mvo: does it work to have a HO now? [09:27] pedronis: yes, give me 3 minutes pls [09:27] can i get 10 minutes? [09:27] how the hell do iget snapcraft working on debian based distros whjen it says / does not have /home [09:27] for the app [09:27] what the hell [09:28] Chipaca: yes [09:28] 👍 [09:28] Psil0Cybin: could you try asking that again please? [09:28] maybe a little less sweary and with more context for us to understand it [09:30] Chipaca, sorry on debian when /home is somewhere else snapd does not work [09:30] and wont install / run an app [09:30] Psil0Cybin: snapd needs homes to be in /home, yes; taht is a limitation of snapd that is unlikely to go away in the short term [09:31] Psil0Cybin: especially because there's no good reason to not have homes in /home, either directly or via bind mounts [09:31] Psil0Cybin: also note the homes need to be always there, ie not automount, not auto-decrypt-on-login [09:31] okay but for example im using kali, how can i use snapd? [09:31] in that case? [09:31] i thought you said you were using debian [09:32] pedronis: ok ready when you are [09:32] Psil0Cybin: kali does many things differently, and breaks/blocks the way we set up confinement [09:33] Psil0Cybin: including confinement of x11 apps for example, they won't work on kali. Also apps that use the network. [09:34] Chipaca, i said debian because kali is debian based? [09:34] okay on that note, what if an application only has insturctions for snapd installs how do i go about obtaining that software? [09:34] pstolowski: Chipaca: I made an actual invite [09:35] anyway of getting around that, for example using this guide? (https://miloserdov.org/?p=2448&PageSpeed=noscript) [09:35] ? [09:36] pedronis: thank you === ricab_ is now known as ricab [09:40] Chipaca, or are you suggesting im out of luck from community support basically? [09:40] just would like to understand thx [09:57] i am assuming becasue your mia, im just out of luck? [10:00] Psil0Cybin: in a meeting, not mia [10:00] Chipaca, apologies. [10:01] i will wait now, sorry. [10:21] Psil0Cybin: is this with kali from a live cd, or installed? [10:21] zyga, hey, I'm seeing something weird related to the content interface [10:21] Psil0Cybin: some of the issues we've seen on kali are only on the live cd [10:21] tell me [10:22] pedronis: could you update the forum to let people (including rob) know we're reverting? [10:22] zyga, wifi-ap snap shares a socket named $SNAP_DATA/sockets/control [10:22] zyga, declared in slot as write: [10:22] - $SNAP_DATA/sockets [10:23] Chipaca: yes [10:23] zyga, and used in another snap as 'target: $SNAP_COMMON/sockets' [10:24] zyga, what I see in the target is $SNAP_COMMON/control , should it not be inside a sockets folder? [10:25] zyga, all that gets written in $SNAP_COMMON in the target is seen in $SNAP_DATA/sockets in the provider (wifi-ap) [10:25] pedronis: did you mean to revert also #7359 completely, or just https://github.com/snapcore/snapd/pull/7359/commits/4e54b6d8a2b6ffd1d539abdc9bf4af2438e691c6 ? [10:26] PR #7359: overlord/snapstate: check channel names on install [10:27] abeato: I understand, give me a moment to finish something here [10:27] sure [10:28] pstolowski: yes [10:28] Chipaca: https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769/8?u=pedronis [10:28] pedronis: yes - #7359 completely? [10:28] PR #7359: overlord/snapstate: check channel names on install [10:29] pstolowski: yes [10:29] pedronis: ok, ty. in that case i think i'll prep 2 reverts, otherwise it'll be slightly bug [10:30] *bug [10:30] *bug [10:30] *big [10:30] grr [10:31] pstolowski: thx, please mark me for reviewing those reverts [10:36] PR snapd#7372 opened: overlord/snapstate: revert track risk behavior change for 2.41 [10:39] PR snapd#7373 opened: overlord/snapstate: revert track risk behavior change [10:45] zyga, fyi, if I change the name of the target from $SNAP_DATA/sockets to something different to the folder in the provider, like $SNAP_COMMON/sockets-wifi-ap, I actually see $SNAP_COMMON/sockets-wifi-ap/control, as expected [10:46] PR snapd#7371 closed: snapstate: add comment to checkVersion vs strutil.VersionCompare [10:46] pedronis: i think i'll actually revert all that in same PRs, otherwise resolveChannel change will be annoying to review [10:48] mvo: ^ [10:50] mvo: patch patch sent sent [10:52] * mvo hugs Chipaca [10:52] Chipaca: thank you [10:52] pstolowski: thank you as well! [10:52] mvo: sorry, more stuff coming to the reverts you just reviewed.. [10:53] pstolowski: no worries [10:54] pedronis: 7345 has two +1 and is green, shall I merge? [11:03] PR snapcraft#2693 opened: rust plugin: support for s390x [11:04] zyga, this is the bug: https://bugs.launchpad.net/snapd/+bug/1838537 [11:04] Bug #1838537: Analyze wifi-ap's disk usage in SNAP_DATA

[11:04] mvo: yes, was about to (will apply couple of tweaks in the later work) [11:08] pedronis: cool, go for it! [11:09] PR snapd#7345 closed: overlord/devicestate,seed: small step, introduce seed.LoadAssertions and use it from firstboot [11:11] mvo: #7368 is the next in that series [11:11] PR #7368: cmd/snap,image,seed: move image.ValidateSeed to seed.ValidateFromYaml [11:13] * pstolowski lunch and a walk [11:13] * Chipaca hugs pstolowski [11:15] zyga, actually, hold on, I'm not 100% sure that is what is happening [11:15] PR snapd#7364 closed: overlord/snapstate: add migration function to fix invalid channel spec <⛔ Blocked> [11:23] mvo, hey [11:24] mvo, is protocol error fixed on 2.41? [11:28] cachio: it should be, yes [11:28] mvo, still see this https://travis-ci.org/snapcore/snapd/jobs/578207214#L7054 [11:33] cachio: thanks, let me look [11:35] cachio: thanks, I cherry-picked one more patch from master, hopefully that fixes it. really good catch! [11:35] thanks! [11:36] * zyga needs to take half of the day off [11:36] I must skip standup. Sorry [11:36] I will catch up in the evening [12:08] hmm google:ubuntu-core-16-64:tests/main/snap-info failure on my revert in master [12:09] pstolowski: can i see? [12:10] Chipaca: https://api.travis-ci.org/v3/job/578294589/log.txt [12:10] pstolowski: you should be able to run that one locally, if it helps [12:11] but [12:11] pstolowski: but [12:11] pstolowski: that's actually broken, now [12:11] pstolowski: I blame mvo [12:11] the test needs fixing, not related to your revert [12:11] Chipaca: ok, good, it got me confused [12:12] :) [12:12] pstolowski: I'll push a pr to fix it [12:12] ty [12:12] pstolowski: you're working on master, yes? [12:22] pstolowski: 7374 has the fix [12:23] PR snapd#7374 opened: tests/main/snap-info: update check.py for test-snapd-tools 2.0 [12:24] Chipaca: aaa it's because the new track i asked mvo to create :) [12:24] pstolowski: self-inflicted pain i see [12:26] it's really not a great day today [12:26] and super hot here [12:33] #7374 needs second review and it's required to unbreak master [12:33] PR #7374: tests/main/snap-info: update check.py for test-snapd-tools 2.0 [12:34] ... and we will need to cherry pick it for 2.41 i suppose === ricab is now known as ricab|lunch [12:58] PR snapd#7343 closed: tests: moving tests to nightly suite [13:57] Chipaca, i have it installed [13:57] on my hard drive,i am trying to see if perhaps there is a work around i uninstalled it and purged the install i am wondering if i should try again? [13:58] Psil0Cybin: where is your home? [13:58] I just had so many errors, after getting snap.d to run it would not run the program i forgot the exact error message, but I am wondering if maybe you had experience before I attempted again? [13:59] Chipaca, its /username [13:59] Psil0Cybin: why? [13:59] instead of /home/username i assume [13:59] no idea [14:00] quite [14:00] default installed it like so [14:00] Psil0Cybin: you can work around that in particular with a bind mount [14:00] Psil0Cybin: shouldn't be a blocker [14:00] Oh amazing! Perhaps you have a guide i can reference too when i install it (i am working from home today -- remote) [14:00] so i appreciate that! [14:00] I do not have a guide, at present === ricab|lunch is now known as ricab [14:01] not enough kali users to write a guide [14:01] Psil0Cybin: but you could write one [14:01] you know what I will its about time i contribute to the community, okay im going to give it an install after a webex meeting and give it a go :) [14:01] Thanks! Chipaca you gave me hope [14:01] Psil0Cybin: i'll be here for anohter couple of hours, otherwise we can continue tomorrow [14:03] thank you Chipaca you are amazing! [14:04] * Chipaca writes that down [14:07] PR snapd#7374 closed: tests/main/snap-info: update check.py for test-snapd-tools 2.0 <⚠ Critical> [14:11] PR snapd#7375 opened: tests: fix snap info test <⚠ Critical> [14:11] ^ cherry pick for 2.41 [14:17] mvo, tests on spread https://travis-ci.org/snapcore/spread/builds/578357987?utm_source=github_status&utm_medium=notification [14:17] mvo, really good news [14:17] https://www.irccloud.com/pastebin/6p15warB/ - installing snaps causes my USB devices to exhibit some strange behavior - effectively disconnects my monitors through my USB-C dock (and maybe they come back without having to unplug). anyone have any ideas on what may be causing that? [14:28] cjp256: I bet that's because we do a udev rebuild [14:28] I believe we trigger a hotplug or something similar to reparse everything [14:34] yes, we trigger udevadm control --reload-rules and/or a few variants of udevadm trigger ... depending on circumstances [14:35] cachio: nice [14:36] roadmr: hi! can you pull 20190829-1435UTC? [14:37] jdstrand: sure! [14:41] mvo could you please take a quick look to #7375 ? [14:42] PR #7375: tests: fix snap info test <⚠ Critical> [14:42] mvo, we will need it as part of 2.41 as well :) [14:42] pstolowski, thanks for the fix [14:42] cachio: credit goes to Chipaca [14:43] cachio: thanks, cherry picked [14:45] thanks diddledan pstolowski, that's helping me narrow it down to which udev calls are doing it :) [14:49] cjp256: this is related to the installation of specific snaps and interfaces (plugs) that they have, some interfaces declare udev rules and interact with udevadm when connected [14:51] mvo: #7375 is already a cherry-pick for 2.41 :) [14:51] PR #7375: tests: fix snap info test <⚠ Critical> [14:52] I'm eagerly awaiting 2.41 to be in the candidate or stable channels [14:56] * cachio bank [14:57] pstolowski: any workaround to preventing the kind of behavior i'm seeing? for me, it pretty much prohibits the use of my usb-c dock when working with snaps, particularly for displays. Probably due to X/gnome, but resorting to unplugging/plugging the displays is only about a 1 in 3 shot of recovering. [14:57] diddledan: what in particular? [14:57] popey: code that I added that will enable me to progress with makemkv stabilisation :-) [14:57] diddledan: me too :D PROTOCOL_ERROR fix *crosses fingers* [14:57] pstolowski: also, my audio device is on usb and it freaks out when this happens. [14:57] diddledan: nice! [15:00] I'm really keen to get makemkv stable :-) [15:00] I've had quite a few people requesting it [15:02] `udevadm trigger --subsystem-nomatch=input` appears to be the source of the behavior [15:02] or perhaps at least one of them [15:05] cjp256, popey : we probably need to revisit our udevadm backend and see if we can restrict that reloading more to specific classes of devices (nb, it is not related to our hotplug support, it has always been like that with our udev backend) [15:13] * pstolowski quick errand, bbiab [15:46] re [15:47] fwd [15:47] #7375 needs second +1 [15:47] PR #7375: tests: fix snap info test <⚠ Critical> [15:48] mvo: and i've requested your re-review on 7373 since there was one more revert after you initial review [15:49] ok [15:49] pstolowski: in a meeting right now, will look after it [15:57] wrt to my display issues, I think it boils down to trigger subsystem=drm [15:58] and triggering it alongside other subsystems at the same time makes breakage much more likely [16:05] aww, netflix doesn't like snapped chromium :-( [16:07] netflix and chi.. er no :( [16:10] not for linux users :-( [16:11] s/linux/snap/ [16:11] cjp256: would you mind filing a bug report (https://bugs.launchpad.net/snapd) and capture all the details you found? [16:43] PR snapd#7375 closed: tests: fix snap info test <⚠ Critical> === pstolowski is now known as pstolowski|afk [17:06] pstolowski: will do [17:36] pstolowski: https://bugs.launchpad.net/snapd/+bug/1841971 i'll update it when I figure out anything more, thank you :) [17:37] Bug #1841971: installing and removing snaps triggers display failures [18:34] PR snapcraft#2693 closed: rust plugin: support for s390x === ricab is now known as ricab|brb [19:30] PR snapd#7376 opened: image,o/devicestate,seed: oops, make sure to clear seedtest helpers [22:59] PR snapcraft#2692 closed: internal: unknown apt packages aren't installed