[04:00] PR snapcraft#1943 closed: Release/2.39.2+18.04 (DO NOT MERGE) [04:18] PR snapcraft#2078 opened: Release/2.41+18.04 [04:34] zyga: thanks a lot for your patience. so the most common way for a download tool like https://github.com/pbek/lmdownload is to tell the user that they only can download files to their home folder if they are installing the snap package? [05:10] morning === King_InuYasha is now known as Son_Goku [05:44] good morning [05:44] zyga: hello [05:45] pbek: I'm not sure I understand, is the download tool itsel a snap? [05:45] hey :) [05:45] * zyga is a bit hurt today :) [05:45] good morning, zyga [05:46] yes, the tool downloads pdfs to the current folder and is snapped [05:46] https://github.com/pbek/lmdownload/blob/develop/snap/snapcraft.yaml [05:47] but of course downloading just works in the /home folder when the tool is started as snap [05:47] pbek: you can check if you are in /var/lib/snapd/void, if so, tell the user to do something else [05:48] pbek: that directory is used if the original working directory cannot be represented in a snap [05:49] mvo: some good news, the leak is gone [05:49] mvo: but the case is not fully cloesd, we need to talk to the kernel team [05:51] zyga: strange, the tool never told me that it was in that directory (I print out the directory where the tool wants to strore the pdf file). the directory was always the one I really was in bash, but I got a write permissions error when I was storing the file. the tool is written in go [05:51] pbek: it only does so if it is in a directory that cannot be represented [05:51] pbek: it may be in a directory that is represented but cannot be written to [05:54] zyga: ok, I can output a more propper error message then, but I cannot get around the fact that the tool can only write to the home-folder while in snap confinement, right? [05:54] pbek: that's correct [05:55] pbek: snaps should wite to $SNAP_USER_DATA or $SNAP_USER_COMMON [05:55] thank you again for your patience, zyga! [05:55] pbek: eventually you may use xdg portals to write to more places [05:55] yes, I found that out already (and am using using it for storing settings) [05:55] zyga: hey, good morning. yeah, I saw the mail [06:37] PR snapd#5050 opened: many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043 [06:40] * zyga tries to get through his inbox today [06:54] PR snapd#5051 opened: snap,wrappers: address review feedback from #5043 [07:01] PR snapd#5044 closed: 'system' nickname for 'core' in snap get/set (2.32) [07:02] PR snapd#5045 closed: overlord/snapstate: poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap (2.32) [07:16] morning [07:20] hey pawel [07:20] * zyga spent all of saturday and sunday outdoors, walking and biking a lot [07:20] and now endures the pain in all kinds of places :) [07:25] if anyone feels like doing some reading https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 [07:27] mborzecki: yeah [07:28] btw. i think there's a bug in nm, some signal not emitted at the right time/place [07:28] at least when switching connection to metered from the cli, you don't see the Metered property changed on the main NM object [07:28] had to restart NM and then it got updated [07:32] hi, is there a fix for the pip error when building a python package with snacraft: subprocess.CalledProcessError: Command '['/bin/sh', '/tmp/tmp7036_63f', '/home/ack/canonical/src/gitlptools/parts/gitlptools/install/usr/bin/python3', '-m', 'pip']' returned non-zero exit status 1 [07:39] mborzecki: replied [07:39] zyga: good points [07:40] good morning [07:41] Pharaoh_Atem: snap-confine package contains all kinds of things in fedora [07:42] Pharaoh_Atem: we should really disband that package and move those files over to snapd [07:43] disband ;) reminds me of civ [07:50] mborzecki: ha, yeah [07:50] disband militia in 2050 :) === mborzeck1 is now known as mborzecki [08:14] moin moin [08:15] wow, my network is flaky today [08:16] mvo: I will update the GitHub release page [08:16] although I plan to skip the .1 and .2 tarballs [08:16] just go to .4 [08:16] I will use it to make the openSUSE release now === mborzeck1 is now known as mborzecki [08:19] mvo: hi, are you going to create .5 today? [08:29] pedronis: yes, I will do that hopefully ready around lunch time. do you have anything pending? [08:30] no [08:31] I saw you merged the doMountSanp/readInfo stuff [08:32] pedronis: can you update https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954 to include the latest status of that issue please [08:33] pedronis: yeah, I looked over it and it looked like a good idea to have it [08:36] I'll update it in a bit [08:36] #3 is wontfix, #4 has had some error-catching fixes, #5 is almost fixed right? [08:50] any prs needing reviews? [08:52] Can you look at my trespassing pr [08:53] zyga: #4889 ? already did [08:53] PR #4889: cmd/snap-update-ns: don't trespass on host filesystem [08:53] Ah, then no idea :-) [08:53] zyga: btw. it needs deconflicting [08:53] Oh thanks. I’ll do that shortly [09:05] #4983 needs a second review [09:05] PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json [09:12] can't linux mint run classic snaps? [09:14] is there a way to tell what type of confinement is supported by the system, other than running `snap debug confinement` ? [09:17] zyga: updated [09:17] thanks! [09:18] mborzecki: what do you mean? [09:20] mborzecki: http snapd:///v2/system-info | jq .result.confinement [09:20] mborzecki: ? [09:20] Chipaca: when you run `snap debug confinement` you actually see the confinement mode supported on the host (strict|partial), but I don't see a way to get this information using cli and not 'debug' command (which is hidden btw) [09:22] mborzecki: AFAIK there isn't [09:22] mborzecki: i mean, not via 'snap' [09:22] mborzecki: maybe we want it in 'snap version' or sth? [09:23] mborzecki: (what for?) [09:23] Chipaca: when the user runs hello-world.evil they will on unconfined system they will see the message 'If you see this line the confinement is not working correctly, please file a bug', but they may not have confinement in the first place [09:24] mborzecki: 'please file a bug with your distribution' :-p [09:24] i was thinking that we could update the message with eg. 'Try running snap version to check if your system supports confinement blah blah' [09:25] mborzecki: why not make .evil run 'snap debug confinement' or equivalent itself? [09:26] Chipaca: hm doable, but snap debug is hidden (or pretends to be at least), snap version would be nicer, https://paste.ubuntu.com/p/JRn57pP99Q/ [09:26] mborzecki: is this on arch btw? [09:27] Chipaca: yes [09:33] mborzecki: is there any info we could put next to 'arch' in the output of 'snap version'? [09:34] i know it's rolling, but maybe, the time of the last update? [09:34] dunno [09:34] mborzecki: we could add confinement to distro info instead of as a new line if the new line is frowned on [09:34] Chipaca: - ? [09:36] Chipaca: https://paste.ubuntu.com/p/CGJZ9XPnSv/ [09:37] mborzecki: aw :-) ok [09:38] IMO putting this on the distribution version is silly [09:38] let's just do it properly [09:38] confinement: seccomp(...), cgroup(device, freezer), namespace(mount), apparmor(...) [09:41] zyga: note that that's not exposed via system info yet [09:41] +1 to it or something like it if it were [09:42] PR snapd#5050 closed: many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043 [09:42] zyga: seccomp(...) as in actions? [09:42] yeah, some version details there [09:49] hmm maybe we should have a separate `snap confinement` command or some --verbose switch to snap version, this is getting a bit verbose [09:50] then we could print apparmor features, seccomp actions, available cgroups (those that are mounted), and namespaces (those listed under /proc/$$/ns of snapd daemon) [09:57] mvo: updated https://github.com/snapcore/snapd/releases/tag/2.32.4 [09:57] mborzecki: I think we have too many commands but I agree we should have some way to s how this [09:58] mborzecki: I doubt most users will undertstand more than I said initially on a single-line confinement value [09:58] ok, so maybe `confinement: (strict|partial)` in snap version is all that we need [09:59] zyga: thanks! .5 is rolling forward [10:01] mvo: so .5 doesn't include 5051 ? [10:02] PR snapd#5052 opened: cmd/snap: handle distros with no version ID [10:02] Chipaca: ^^ [10:02] pedronis: no, I think its fine, its cosmetic but if you feel strongly about it I can include it too [10:04] mvo: that's odd, we had that patched before [10:04] mborzecki: +1 [10:04] ah [10:04] I see what the patch does now [10:04] mvo: ping me when .5 tarball is up [10:05] diddledan: you havint trouble with irccloud today? [10:05] fails to launch here on core stable, and I just get 3 dots in the screen constantly [10:06] mvo: mostly fearing a bit of confusion about the log, and if we need to do a .6 [10:06] * zyga does /o\ [10:06] why would we need a 6? [10:06] exactly, we don't know [10:06] that's how that stuff happens [10:09] zyga: what is odd? [10:09] mvo: nothing, I misunderstood the output [10:09] mvo: - vs "" [10:09] pedronis: ok, I will pull it into release/2.32 just in case we need a .6 [10:09] pedronis: it does make sense [10:09] mvo: https://github.com/snapcore/snapd/pull/5053 [10:09] PR #5053: release-tools: handle the snapd-x.y.z version [10:10] zyga: ta, I have a look. .5 is available in the ppa, one sec, I look for a direct link for you [10:10] mvo: FYI I have tested jj's fix and it's stable over extended periods of time [10:10] mvo: oh, neat [10:10] just push the tag, I'll do the rest :) [10:10] zyga: tag is pushed as well [10:10] PR snapd#5051 closed: snap,wrappers: address review feedback from #5043 [10:10] PR snapd#5053 opened: release-tools: handle the snapd-x.y.z version [10:10] zyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/8990918/+listing-archive-extra has the build [10:10] Son_Goku: good morning [10:12] diddledan: must have been corrupted config, removed and reinstalled the snap and it's fine \o/ [10:12] PR snapd#5054 opened: snap,wrappers: address review feedback from #5043 (2.32) [10:15] PR snapd#5055 opened: release: 2.32.5 [10:20] mvo: https://github.com/snapcore/snapd/releases/tag/2.32.5 [10:21] can you please check if I got the refresh/stop mode bits right [10:23] mvo: .5 failed to build for ppc [10:23] zyga: looking, I suspect a stray failure [10:24] pedronis: https://bugs.launchpad.net/snappy/+bug/1764069 [10:25] Bug #1764069: Can't install snaps (X-Ubuntu-Series header is required - connection refused) [10:32] * zyga -> walk [10:32] popey: notepad++ looks bad on high-dpi system [10:32] not sure if there's anything we can do to tell wine" hide" [10:32] "hidpi" [10:32] Indeed [10:33] We don't pass through pixel doubling in some apps [10:33] not just WINE [10:37] popey: do you know what we need to pass through? [10:37] i dont think there is anything we can do for WINE, but for some other apps, Wimpress mentioned looked bad on his hidpi machine, i think he knows [10:38] * Chipaca tries to make a joke about sulphites, and fails [10:46] PR snapd#5052 closed: cmd/snap: handle distros with no version ID [10:46] 5052 for 2.32 in case we do a .6 release? ;) [10:48] mborzecki: too much regression potential [10:49] :-p [10:49] zyga: afaict that's a DNS problem [10:53] Ok [10:59] mvo: this changelog line looks strange: daemon: support 'system' as nickname of the core snapchange it is [10:59] + possible to do: [11:00] change it is ... seems spurious [11:03] pedronis: my fault, i tend to include how the command output looks like in the commit messages [11:04] I'm not sure, the whitespace is wrong either way [11:08] pedronis: yeah, the whitespace there is incorrect. good catch [11:08] pedronis: look like the script that generates them has a bug there, I look into it [11:16] PR snapd#5056 opened: cmd/snap: make confinement mode part of `snap version` output [11:17] * Chipaca trundles off in search of something to lunch [11:23] re [11:23] * zyga works on .5 release for opensuse === pstolowski is now known as pstolowski|lunch [11:25] zyga: .6 is where it's at [11:25] * Chipaca runs [11:25] Chipaca: what?!? [11:25] are we doing a .6 now [11:26] is this what "eventually released" software is like? [11:32] .5.4.3.2.1 [11:33] approximating towards 2.33 [11:34] Chipaca: should we use LazyUnmount= in our .mount units? [11:34] effectively :) [11:34] (that was about approx 2.33) [11:35] mvo, should I start testing .5 or I should wait for a .6? [11:35] cachio: I don't think we plan a .6 atm [11:36] pedronis, ah, ok [11:36] thanks, I'll run beta validation for .5 in that case [11:37] mborzecki, hey, amazon linux image is ready [11:37] but you just can use it [11:37] if you use this spread [11:37] 2.32.4 is building for all opensuse systems now [11:37] mborzecki, https://github.com/snapcore/spread/pull/57 [11:37] PR spread#57: Adding preserve option for systems to keep the default image size [11:37] mborzecki, beasuse the filesystem cannot be resized [11:38] cachio: what's the system name in spread.yaml? [11:38] mborzecki, basically it is not possible to shrink xfs filesystems [11:39] - amazon-linux-2-64: [11:39] workers: 1 [11:39] preserve: true [11:39] mborzecki, you can add that [11:39] with that branch [11:41] ok [11:41] mborzecki, I'll going the the kinesiology now, I'll explain better during the standup [11:41] cachio: i'll try to run it, thanks [11:42] mvo, there is not changelog for 2.32.4 -> 2.32.5 [11:45] cachio: I made "some" changelog [11:45] cachio: https://github.com/snapcore/snapd/releases/2.32.5 [11:51] Caelum: I updated snapd twice to 2.32.4 and now to 2.32.5 [11:51] Caelum: let me know if you run into any issues [11:51] Caelum: although this release should be very stable now [11:58] mvo: maybe I could look at updating the debian package [11:59] Pharaoh_Atem: I will have a small selinux patch for you to review soon [12:01] does anyone know what networkd-dispatcher is for? [12:02] mvo: how is our upload to bionic like? [12:02] mvo: can we upload .5 now? [12:02] and similar question about xenial SRU [12:03] off to get the kids [12:08] mborzecki: when you return - did you have any luck with nvidia on 18.04? I got from zyga that it's somewhat of a lost cause? [12:09] popey: with classic snaps [12:09] popey: otherwise it should work [12:09] popey: with classic snaps it can work but the snap needs to understand the particular layout of the host [12:09] This needs documenting somewhere. [12:13] popey: yes, no disagreement there [12:15] mvo: when we have more bases and more core18 things [12:16] mvo: I was thinking that we should drop the "series 16" line from snap version [12:16] we could show it on core devices [12:16] and actually show the name of the bootable base [12:16] I think right now it's not a very useful/informative thing [12:18] Bug #1764069 changed: Can't install snaps (X-Ubuntu-Series header is required - connection refused) [12:18] mvo: hey, is issue #5 solved with 2.32.5 now? [12:20] PR snapd#4833 closed: tests: add a detector for kernel bug https://pad.lv/1755563 [12:23] mvo: given that #5043 is for 2.32.x, do you still plan to make additional release (that is, .6)? [12:23] PR #5043: many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode

[12:28] zyga: reading backlog now [12:30] cachio: http://people.canonical.com/~mvo/core-changes/html/beta/2.32.4r4443_2.32.5r4486.html <- that looks ok (modulo missing space) [12:31] Son_Goku: hey! I've proposed go-udev https://bugzilla.redhat.com/show_bug.cgi?id=1567819 but just got a comment there that go packaging has been revamped? haven't yet looked at the guidelines [12:32] zyga: 5043 has lnaded in .5, no? [12:32] zyga: or what am I missing? [12:32] * kalikiana lunch [12:33] mvo: has it? the branch is open [12:33] ah [12:33] sorry [12:33] I mean 5054 [12:34] mvo: I think my question was about the status of the forum post, if issue #5 is fixed let's mark it as solved [12:34] zyga: checking [12:34] pstolowski|lunch, I think he's talking about this new form: https://src.fedoraproject.org/rpms/golang-gopkg-yaml/blob/master/f/golang-gopkg-yaml.spec [12:35] mup #5054 [12:35] PR #5054: snap,wrappers: address review feedback from #5043 (2.32) [12:35] mvo: offtopic, remember those 100s of threads? my bionic shows 11 threads in .5 [12:35] zyga: 5054 is just cosmetic, but given the amount of questions about it I should have included it. its now in release/2.32 so *if* there is anohter one it will be in [12:35] zyga: I do remember that [12:35] mvo: understood now, thanks [12:35] Son_Goku: okay, i'll dig into the new guideline after lunch [12:36] zyga: thank you! so the 100s threads I don't see on my two bionic machines [12:36] zyga: so not sure what is going on there [12:36] huh, gnome software has a 'restart and install' button [12:36] zyga: #5 *should* be fixed in beta but I hope to get confirmation from a real world test case later today [12:36] Chipaca: for installing updates? [12:37] Chipaca: yes, for some years now :) [12:37] cachio: thanks for the sru validation! [12:37] mvo: I'm guessing what it describes as firmware is a bios update [12:37] Chipaca: it's a very old systemd/fedora/pkgkit feature [12:37] cachio: also yeah beta validation for .5 sounds great! [12:37] it's not related to firmware [12:38] it's related to a mode where all updates are downloaded but not installed, the machine reboots and goes into a special boot mode where systemd installs all updates and reboots back to normal mode [12:39] pstolowski|lunch, guideline in question is documented here: https://fedoraproject.org/wiki/More_Go_packaging [12:39] zyga: I don't open gnome-software often (i've only recently had enough memory to keep it installed at all) [12:41] zyga: what is the link to the 18.04 post again? then I can update #5 [12:41] mvo: https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954 [12:42] zyga: ta! [12:43] zyga: funny pr 4954 is also a fix for 2.32 as is the above forum topic (ok, maybe not that funny). i update it now [12:43] PR #4954: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store (2.32) [12:44] zyga: updated, thanks you [12:46] mvo: we have new pam and netplan [12:48] zyga: yeah, changelog looks mostly harmless [12:48] yes === pstolowski|lunch is now known as pstolowski [13:32] re [13:32] zyga: to be clear, the snap which I am having trouble with is _not_ a classic snap. [13:36] arch updated to 2.32.5 [13:36] I'll speak to snapcraft chaps, as it could be that. [13:37] popey: still mame thing? [13:37] yeah [13:37] i posted the logs from friday in the LP bug report [13:37] you mentioned rpath, but I dont know what *I* am doing wrong here [13:37] yeah, I saw. [14:04] niemeyer: will you have some time to talk about hotplug after your current meeting? [14:29] mvo, zyga: hello! would you all be alright with the apparmor memory leak bug (bug #1750594) being fixed in the first SRU kernel of 18.04 or do you feel it is urgent enough that the 18.04 kernel be respun again before the release? [14:29] Bug #1750594: Eventual OOM with profile reloads [14:30] tyhicks: I think it's not that critical, it only affects systems that run our test suite as far as we are aware [14:30] PR snapcraft#2074 closed: Release changelog for 2.41 [14:30] it's annoying but not user-critical from my POV [14:30] mvo: ^ [14:30] tyhicks: will live kernel patches fix it? [14:30] that's my understanding of the bug, as well [14:30] zyga: no, we don't plan to do a livepatch for it [14:31] we'd really only want to respin if it affected installs or made the out of box experience bad but, AFAIK, this bug doesn't show up in normal use cases [14:32] tyhicks: hi, in a meeting right now [14:32] tyhicks: let me reply as quick as I can [14:32] thanks [14:35] pstolowski: I'm just off and have a few minutes before lunch.. can you talk now? [14:36] niemeyer: yes [14:36] pstolowski: Ok, standup then === deanman_ is now known as deanman [14:47] PR snapd#5057 opened: tests: bring back one missing test in snap-service-stop-mode [14:53] niemeyer: 10MB unaccounted for after creating a bolt db. Will continue digging. [14:53] RSS of a simple thing goes from 4MB to 14MB [14:54] Chipaca: That sounds very promising [14:55] Chipaca: One data point worth gathering is what happens if we open that same file in RO mode [14:57] niemeyer: 8MB rss [14:57] pedronis: hey, will you find some time this week to make another pass on iterface hooks PR? i've addressed your last comments [14:58] Chipaca: Unaccounted or total? That is, 4 to 12, or 4 to 8? [14:58] niemeyer: actually 10MB if the code to create it is still there, just not used [14:58] niemeyer: total [14:58] * Chipaca needs to step away for a bit, will bbl [15:02] niemeyer: time.Sleep -> 4MB, ro bolt: 8MB, ro bolt and rw code unused: 10MB; rw bolt: 14MB [15:02] * Chipaca afk [15:04] mvo, https://paste.ubuntu.com/p/Z59BDC4VWq/ [15:04] running beta validation for 64 bits [15:05] mvo, it is like the system was rebooted after line 53 [15:05] but it shouldn't [15:06] cachio: yeah, this is stange, anything in syslog? [15:06] Chipaca: hacked a small tool that prints package sizes (*.a that end up in the binary, unless go does some lto at the end) https://gist.github.com/bboozzoo/a363e591075cb4d4faae39b4066ac411 [15:06] mvo, this is from syslog [15:07] mvo, I already saw that doing refresh from stable too [15:07] similar problem [15:08] cachio: uh uh [15:08] cachio: is this on a core device? or 16.04? [15:09] mvo, from journalctl https://paste.ubuntu.com/p/DsqmKfDGNv/ [15:10] it is core-16-64 [15:10] a vm [15:10] this is very uncommon [15:10] Apr 16 14:31:53 localhost.localdomain snapd[993]: ERROR cannot open snap: open /tmp/snapd-sideload-pkg-105860667: no such file or directory [15:10] PR #16: Feature/git buildpackage