[02:18] PR snapcraft#2225 closed: build providers: environment setup for projects [02:51] PR snapcraft#2247 closed: yaml loading: properly handle unhashable types [03:50] what is "black"? [03:51] run_tests.sh requires it but I don't know what package it's located in [03:53] ah hah, it's in the snap store, of course [03:56] "The linker version '2.23' used by the base 'core' is incompatible with files in this snap:" [03:56] that's an issue i haven't seen before [03:57] any idea what this means? [03:59] ah, I was using the release candidate snapcraft [04:06] "warning: working around a Linux kernel bug by creating a hole of 2097152 bytes in ‘/tmp/tmpyf6y6pvu’" [04:07] now THATS quality! [04:09] uhm [04:10] does the AppVeyor CI run the self test for snapcraft? [04:40] is `./runtests.sh static` on snapcraft broken for anyone else? mypy throws a bunch of type errors [04:51] PR snapcraft#2248 opened: plugin: update catkin plugin to support melodic [04:51] there we go [05:07] morning [05:27] hm got a failure in unit tests with gccgo: https://paste.ubuntu.com/p/prG9CTRNJm/ [05:27] it's in snapshotSuite.TestRestoreIntegration [05:34] Hey hey [05:35] zyga: hoho [05:36] zyga: how's the first week of school? [05:39] I think successful [05:39] Janek likes his new school [05:39] And committing is ok, he is doing it by himself now [05:39] that's great :) [05:43] And for you? [05:47] zyga: so far so good, kids have already gotten into the daily routine [06:05] ok, installed in my office now :) [06:31] PR snapd#5776 closed: tests: port proxy test to use python tinyproxy [06:31] PR snapd#5784 closed: tests: run account-control test with different bases === pstolowski|afk is now known as pstolowski [07:01] morning [07:01] hey pawel [07:01] reading your hot plug PRs now :) [07:01] I'll be right back, I could use another coffee [07:08] anyone upgraded to g 1.11 already? [07:11] mborzecki: not in tumbleweed [07:11] I did not yet, its in cosmic but not in bionic [07:12] anything new and interesting? [07:12] damn, gocode stopped working, stracing it i found it's poking some silly locations under pkg/linux-amd64 (note - not _) === sparkieg` is now known as sparkiegeek [07:37] mborzecki: actually, I should just upgrade go on macOS [07:37] * zyga does just that [07:38] we have spam on the forum [07:38] who has editorial rights to kill that? [07:38] morning. [07:39] not I. [07:39] :-p [07:41] zyga: i know Chipaca, maybe mvo as well? [07:43] mborzecki: maybe - whats the link to the spam zyga ? [07:45] sent in private [07:48] zyga: thanks, removed post and user [07:58] pstolowski: just curious but did you find any leads on the test failure? [07:59] mvo: i only got succesful build in the ppa this morning a while ago, pushing some more debug. i had a long fight with debian toolchain yesterday ;} [08:00] (succesful = failing on unit tests as expected) [08:02] PR snapd#5789 opened: snap: only show "next" refresh time if its after the hold time [08:03] pstolowski: aha, great, so you can reproduce it and get useful debug out of it? great. is it worth it for me to push a tiny branch that skips the test for now so that we get edge builds back or is the fix close enough to not bother? [08:03] pstolowski: (again, no pressure just trying to estimate what the best next step is) [08:03] Chipaca: good morning [08:04] mvo: no fix in sight, issue not yet understood, so yeah, feel free to disable the test if it's blocking [08:04] mvo: it is! good morning to you too sir [08:05] zyga: missied your earlier message, thanks for looking at my hotplug PRs! [08:05] the name code is intricate [08:06] pstolowski: thank you [08:10] PR snapd#5790 opened: overlord: skip testUpdateWithAutoconnectRetry temporarily [08:12] pstolowski: 5782 reviewed [08:12] zyga: ty! [08:16] is there any documentation on "allow-auto-connection" for plugs? [08:17] Doctor_Nick: yep [08:17] Doctor_Nick: 1 sec [08:17] Doctor_Nick: https://forum.snapcraft.io/t/process-for-aliases-auto-connections-and-tracks/455 [08:18] Chipaca: btw, does http://paste.ubuntu.com/p/yZjys58FKc/ ring any bells? [08:18] Chipaca: happend in a recent spread run, iirc in one of mborzecki PRs [08:18] nice :-/ [08:19] mvo: ha, pasted it in the morning :) but nobody was around [08:20] Chipaca: thanks [08:20] mvo: mborzecki: it does not ring a bell [08:20] Chipaca: mvo: https://paste.ubuntu.com/p/prG9CTRNJm/ [08:20] mvo: mborzecki: but something is obviously wrong [08:20] mborzecki: what mahcine? [08:20] machine* [08:21] Chipaca: this was with gccgo, ubuntu something, sorry don't have more details [08:21] Chipaca: wait, sorry, I meant the syntax for it [08:21] Doctor_Nick: what do you mean, the syntax? [08:21] Doctor_Nick: do you have a brand store? [08:21] the syntax for the snapcraft.yaml file [08:22] not yet [08:22] it doesn't go in snapcraft.yaml [08:22] theese are private snaps so far [08:22] it is put in the snap declaration assertion through the store [08:22] what goes in the yaml is the connection [08:22] not the auto-connection of the connection :-) [08:23] on that front brand store owners have control, we are also working to make it so that knowning the syntax is not needed [08:24] but is not something that can be done for one own's snaps in the main store [08:25] private or not [08:30] Is it possible to declare common environment variables for apps in snapcraft.yaml? https://forum.snapcraft.io/t/snapcraft-yaml-reference/4276 only lists apps..environment, which I interpret as “currently not” [08:30] dot-tobias: I think so, just try it [08:30] I mean, snap.yaml certainly allows that [08:32] zyga: When I add apps.environment to snapcraft.yaml, snapcraft complains with “Issues while validating snapcraft.yaml: The 'apps/environment' property does not match the required schema: 'command' is a required property” → “environment” is interpreted as an app name here? [08:32] dot-tobias: move environment to top-level [08:32] everyone seen this on reddit yday? https://www.reddit.com/r/linux/comments/9dfag7/the_correct_frontrunner_in_the [08:33] Yes :) [08:34] seb128: iirc you added some info about metered and network manager into the forum. I misplaced the link, could you sent it to me again please? [08:35] mvo, I didn't because I found https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 that has all the technical detail and I though there was not much point creating a new post [08:35] popey: seb128: I was meaning to update you both on this, but then seb128's train got in the way and then I forgot: yesterday at the standup we talked about enabling the feature by default, and we agreed to move forward on it -- with some level of testing to be done asap [08:35] I believe that's what mvo is on right now in fact :-) [08:35] but dunno :-D [08:35] ah, great [08:35] let us know if we can help in desktop [08:36] you can always help in desktop [08:36] Chipaca: great, lemme know if I can test stuff [08:36] (also would be good to have something to respond to review saying that flatpak cares about their users bandwith where we don't) [08:36] zyga: Right, makes sense. And works. Thank you! 🙏 [08:36] seb128: where's that review? [08:37] Chipaca, see the most recent post on that forum topic I just pasted [08:37] Chipaca: yeah, was just looking into this (cc seb128 ) [08:39] mvo, you rock :) [08:39] seb128: "snapd supports disabling updates on metered connections; the support is not enabled by default should be soon unless field testing shows anything breaking with it enabled" would work? [08:40] seb128: and a link to the forum post perhaps [08:40] seb128: is that wyat you meant as a response? [08:41] seb128: "snapd supports disabling updates on metered connections, on all supported distros that have a new enough netowkr manager (on Ubuntu that means 16.04 on); the support is not enabled by default should be soon unless field testing shows anything breaking with it enabled" [08:41] seb128: if you want to include more detail :-) [08:41] PR snapd#5791 opened: [WIP] overlord/snapstate: improve consistency, use validateInfoAndFlags also in InstallPath [08:42] seb128: typo and a missing "but" [08:42] Chipaca: I created https://github.com/snapcore/snapd/pull/5791 to see how it goes, at least overlord tests doesn't seem to fail with it [08:42] PR #5791: [WIP] overlord/snapstate: improve consistency, use validateInfoAndFlags also in InstallPath [08:42] seb128: or, I can answer that myself if you'd rather keep clear of omg [08:43] Chipaca, if you want to reply that would be nice, thanks :) [08:43] seb128: OTOH, nothing in the usually acrid comments seems to mention metered at all [08:43] oh wait there ar emore comments [08:43] pedronis: yep, will look in a mo [08:44] right, I'm just concerned that's one of those topics where one day someone is going to be pissed off because snapd refreshed in background and created them a bill of 100€ on roaming and then it becomes a topic of the day for ranting against snapd and getting used to say that flatpak at least does things right blablabla [08:44] eh, i'll add a comment [08:45] what about a use case where there's a device which is always connected over [234]G? [08:47] mborzecki: then we'll refresh at the slowest pace we can [08:47] mborzecki: right? [08:47] mborzecki: dude you wrote this :-) [08:47] Chipaca: heh, doesn't mean i remember all the details :P [08:47] seb128: comment added, but I had the temerity to include a link so it's waiting for moderation [08:47] mborzecki: point :-) [08:48] Chipaca: i'll refresh after 60 days anyway [08:48] mborzecki: in the most dire real-world use case i know of the person could get onto wired once a month or so [08:48] quesion whether that's frequent enough [08:48] so I'm happy with it [08:48] mborzecki: that's what we decided was the longest tolerable refresh [08:49] seb128: if you create forum topic I can reference it in my commit changelog :) [08:50] Chipaca: right, so that's 100€ bill every 2 months :) [08:51] mborzecki: i'm trying to decide if you're trolling or not [08:51] haha [08:51] Chipaca: if you or someone else followup in the forum please let me know, wouldbe nice to include the latest discussion in the commit as a pointer to the right forum entry [08:52] reminds me of a time in my previous jobs where we'd screw up stuff in redboot and they actually had to take cars, and visit some of the power line poles or trees the base stations were mounted on :) [08:52] mvo: I replied to the omgubuntu thread, as i said [08:52] mvo: and pointed them to https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 [08:53] Chipaca: thanks, I missed that it was on omgubuntu [08:55] a snap inside of a flatpak inside of a docker container inside of a lxc container [08:55] Doctor_Nick: Don't forget appimage!!!! [08:55] of course [08:55] Doctor_Nick: running on windows in a VM in a browser on a mac [08:58] we need a spread test for that [08:58] zyga: on an x86 emulator running on chrome on a phone [08:58] guys, let me know if you need more input about metered support than that's already in the forum [08:58] mborzecki: I think popey and seb128 need a clearcut this-is-how-you-test-it and this-is-what-to-test-that-we-are-not-sure-about [08:59] plus one [08:59] mborzecki: especially useful if we enable it by default in edge (or beta or w/e) and then have a mini call for testing there [09:00] ack, i'll finish up with the store thing i'm on right now and will add some notes to the forum thread [09:01] Chipaca, mborzecki https://github.com/snapcore/snapd/compare/master...mvo5:refresh-metered-tweaks?expand=1 is the code change. but I am a bit lost about the process (sorry for that). should it get proposed now or shall we wait until we got testing results from users first? [09:02] mvo, you mean for the "turn it on by default", isn't what that topic is about? I'm happy to create another one if you would prefer though [09:03] I think we do need a separate topic if we're going to have a call for testing -- pointing people to a thread with 18 unrelated comments is not good for a call to action [09:04] k [09:04] mvo: same here. I guess if nobody knows a _concrete_ case where it fails, enabling it in preparation for a call for testing is good [09:04] mvo: especially as we tweaked the ux a bit [09:05] mvo: process questions aside, the code lgtm [09:06] * mvo nods [09:06] thanks, I proposed it now, lets see how that goes :) [09:06] PR snapd#5792 opened: [RFC] {config,snap}state: add new refresh.metered=force option and flip default [09:08] pedronis: about the wip pr, +1 fwiw (but also: tests?) [09:08] pedronis: but i do get that the pr is just to see what breaks :-) [09:08] Chipaca: yes, exactly [09:09] if everything passes I'll see what needs testing [09:09] mborzecki: second time through gccgo in the three places we run it without repro'ing the bug [09:09] mborzecki: if you see it again, i need to know how [09:09] mborzecki: it makes no sense to me :-( [09:10] like two things were mkdir'ing $HOME/snaps/, or sth [09:10] s/three/four/ fwiw :-) [09:12] mborzecki: let's land 5793 [09:12] mborzecki: I'm preparing another iteration of the trespassing patch-set without the noise [09:13] PR snapd#5793 opened: cmd/snap-update-ns: separate OpenPath from the Secure struct [09:17] what's the default shell in snaps? [09:17] Doctor_Nick: what do you mean specifically? [09:18] my shell script in this snap package isn't working and I think it's because it's not using bash [09:18] Doctor_Nick, /bin/sh is dash normally ... [09:18] ah hah [09:18] Doctor_Nick: just use bash explicitly [09:18] yup [09:18] if you want to use bash then explicitly use /bin/bash in the shebang [09:19] yeah [09:19] (but live with the overhead :P ) [09:19] (typically there is no reason to not adapt your code to be POSIX compliant ...) [09:20] https://wiki.ubuntu.com/DashAsBinSh has hints [09:21] yeah, it was an easy fix to use the alternative setup script [09:28] mmh, almost back to 50 PRs [09:39] More than 20 of those are still from the review board [09:39] 19 have open reviews [09:40] (moin!) [09:41] dot-tobias: To be clear, there's no default [09:41] It's whatever was used in the bangline, as usual [09:42] niemeyer: I think you meant to ping Doctor_Nick ? ;-) [09:42] dot-tobias: Sorry :) [09:43] niemeyer: no problemo :-) (&& moin) [09:45] 5606 needs a second review then it can go in [09:46] and 5763 a first review, hopefully simple as its just shuffling tests around [09:50] mvo: doing [09:50] niemeyer: snap run --shell runs bash, that's the most defaultish thing we have :-) [09:50] imo we could add --shell= [09:51] Chipaca: That seems a bit cumbersome, even more because the _what_ may not be available inside the snap [09:51] niemeyer: I mean, keep --shell, but add the ability for the user to say what shell they want [09:51] go-flags supports this fwiw [09:52] Chipaca: The issue asked was about a shell script as well, so wouldn't help here either way [09:52] i know [09:52] Chipaca: Right, I got that [09:52] Chipaca: It won't help if they want zsh, though, or csh, or ... [09:52] Chipaca: The snap does not offer it [09:52] niemeyer: if you're using a base that offers /bin/sh but not /bin/bash, it won't work for ex [09:53] Chipaca: We should just fallback to /bin/sh in those case [09:53] s [09:53] niemeyer: or, e.g., snap install busybox-static, and try to snap run --shell busybox-static [09:54] niemeyer: in this one, /bin/sh is provided by the snap itself (it uses the bare base, which has nothing) [09:54] still, this is all academic [09:54] i need to go [09:54] * Chipaca goes [09:56] Chipaca: o/ [10:03] yessss [10:03] our entire backend is snapped now [10:04] yay, congrats ! [10:04] (whatever backend that is :) ) [10:04] now I just have to charm it [10:05] do a feather dance :) [10:06] https://www.youtube.com/watch?v=dxk1BSQo8bg&feature=youtu.be&t=20 [10:08] oh lord [10:08] heh [10:10] mvo: done [10:11] zyga: ta [10:12] mvo: Do we have a snapd.failure.service file? [10:14] niemeyer: we do [10:14] mvo: Huh.. that's a curious service :) [10:14] niemeyer: yes [10:14] niemeyer: when adding a "OnFailure=" bit in systemd this needs to be a service AFAIK [10:15] niemeyer: this is why we have this one. do you think the name is not good or do you think the fact that we have it at all is problematic? [10:15] mvo: I think it's fine given the context.. I just wasn't aware that we had it [10:16] * mvo nods [10:16] mvo: Do we run snap-repair on desktops or only on core? [10:16] niemeyer: only on core [10:17] mvo: Wonder why people are getting the message that those units are disabled [10:17] It doesn't look like a bug.. [10:17] But people seem to think so [10:17] https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1776622 [10:17] Bug #1776622: snapd on cosmic never finishes installing/updating. Can't install any other updates.

[10:19] niemeyer: yeah, I quickly scanned our postinst and its just using the systemd debhelper stuff, would be nice to get the output of "ps afx" when this hangs [10:19] niemeyer: just to see what processes are hanging around and blocking dpkg [10:19] mvo: One person there mentioned the context [10:19] mvo: the 2nd PR is pretty long :) [10:19] pushing on [10:19] moon127: Comment #15 [10:19] PR #15: do not panic if a priv.Mutex is taken/released/taken again [10:19] mup: Good try [10:19] niemeyer: I really wish I understood what you're trying to do. [10:20] mup: It's okay.. you're often helpful [10:20] niemeyer: Unknown commands are unknown. [10:22] niemeyer: hi, #5683 needs a re-review by you [10:22] PR #5683: overlord/patch: support for sublevel patches [10:30] thx [10:31] mvo: almost done [10:31] mvo: reading the new parts now [10:32] mvo: done [10:32] brb, coffee [10:35] mvo: i've a suspiction about the cause of managers test failures, might have a fix, testing [10:38] pedronis: Thanks, looking [10:41] pedronis: thanks for all the reviews [10:42] pedronis: i'll be landing https://github.com/snapcore/snapd/pull/5761 when it's green [10:42] PR #5761: store: use stable instance key in store refresh requests [10:42] (or pushing one last update if #5763 lands first) [10:42] PR #5763: store: refactor tests so that they work as store_test package [10:43] is there an easy way to set network restrictions on snaps, like "only accept connections from localhost"? [10:46] Chipaca: https://api.travis-ci.org/v3/job/425643055/log.txt [10:47] pstolowski: #5683 is good to go [10:47] PR #5683: overlord/patch: support for sublevel patches [10:47] Chipaca: this one too https://api.travis-ci.org/v3/job/425601674/log.txt it's gccgo always [10:48] Chipaca: I reviewed the warning one, some small comments/wonderings [10:49] niemeyer: great, ty! re-starting travis tests [10:50] niemeyer: I contemplated your suggestions about having the managers giving input into the "go-socket-activated" mode. I did a sketch of this now in https://github.com/snapcore/snapd/compare/master...mvo5:stop-on-no-snaps-standby-helper?expand=1 - all names are strawman for now, sugestions welcome. the idea is to have a "standbyHelper" that asks around for opinions if snapd can go to sleep. it gets input from snapmanager ab [10:50] out num snaps, devicestate about seeded, overlord about if ensure was run at least once and the daemon about the connections (check daemon.go and standby.go for the interessting bits). is this what you had in mind? [10:50] (tests missing but I will re-add them if this looks promising) [10:50] zyga: thank you! [10:51] re [10:52] Doctor_Nick: no, there's no support for that at this time [10:52] mvo: Yeah, something around those lines indeed, thanks for making it real. I'll read through the code after lunch and we can quickly sync in the standup. [10:52] dag [10:52] PR snapd#5606 closed: many: add refresh.rate-limit core option [10:53] how about setting a user for a snap daemon? [10:53] Doctor_Nick: this is on the roadmap but it is not implemented yet [10:53] ok [10:53] it's designed and described extensively on the forum [10:53] Oh, can I build against core18 now? [10:53] mvo: are you going to finalize #5324 soon? or should it be closed for now [10:53] PR #5324: snap: run snap-confine from the re-exec location [10:53] juliank: indeed you can [10:54] I'd like to get apt snaps going [10:54] :) [10:54] pedronis: 5324? [10:54] juliank: yes you can :) [10:54] mvo: sorry, #5234 [10:54] I have two things I want to snap: apt and flatpak. The latter mostly for lolz [10:54] PR #5234: snap: add `snap list --format=...` option [10:54] even older ;) [10:55] zyga: is there a way to set a user as part of the snap group and just restrict what they're able to connect? [10:55] Doctor_Nick: what do you mean by "snap group"? [10:55] Doctor_Nick: and how is that related to connections? sorry, I don't understand your question [10:55] pedronis: :( yeah, its a mess of conflicts, I had not mustered the energy yet but I will make a extra strong cup of tea after lunch and give it a go again [10:55] wait, sorry [10:56] i had imagined that there was a snap group that gave users permissions to install snaps [10:56] no, that's managed with policy kit [10:56] and with root vs non-root [10:56] right [10:57] basically I just want to run these things as non-privileged users and only give them access to the network interface [11:02] heh, i'm trying to chec this refresh on metered thing, but i can't get nm to connecto to my phone :/ [11:05] zyga: thanks, the store test PR just had lots of conflicts because the rate limit was landed - oh well :) [11:06] zyga: but now I just need to wait for tests, thanks a lot ofr the review [11:06] mvo: doing more [11:06] Bug #1755568 changed: Snaps are refreshed on metered connection [11:07] Trevinho: Are you still a collaborator on the telegram-desktop snap? [11:07] If so, can you change the homepage to reference telegram desktop and not your personal website please? [11:07] https://snapcraft.io/telegram-desktop [11:07] zyga: cool [11:11] does this ring a bell? [11:11] FAIL: snapstate_test.go:10904: snapmgrTestSuite.TestInstallDefaultProviderRunThrough [11:12] c.Check(len(s.fakeBackend.ops), Equals, len(expected)) [11:12] ... obtained int = 27 [11:12] ... expected int = 28 [11:17] mvo: https://github.com/snapcore/snapd/pull/5771#issuecomment-419408625 [11:17] PR #5771: selftest: add test to ensure selftest.checks is up-to-date [11:23] zyga: ta [11:24] Chipaca: hey, wanna see a snapshot unit test error? [11:24] zyga: aha, yes. silly me. the problem is of course that on 14.04 the kernel selftest fails [11:24] zyga: so this test cannot yet be enabled [11:24]