[04:00] <mup> PR snapcraft#1943 closed: Release/2.39.2+18.04 (DO NOT MERGE) <do-not-merge-yet> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1943>
[04:18] <mup> PR snapcraft#2078 opened: Release/2.41+18.04 <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2078>
[04:34] <pbek> 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] <mborzecki> morning
[05:44] <zyga> good morning
[05:44] <mborzecki> zyga: hello
[05:45] <zyga> pbek: I'm not sure I understand, is the download tool itsel a snap?
[05:45] <zyga> hey :)
[05:45]  * zyga is a bit hurt today :)
[05:45] <pbek> good morning, zyga
[05:46] <pbek> yes, the tool downloads pdfs to the current folder and is snapped
[05:46] <pbek> https://github.com/pbek/lmdownload/blob/develop/snap/snapcraft.yaml
[05:47] <pbek> but of course downloading just works in the /home folder when the tool is started as snap
[05:47] <zyga> pbek: you can check if you are in /var/lib/snapd/void, if so, tell the user to do something else
[05:48] <zyga> pbek: that directory is used if the original working directory cannot be represented in a snap
[05:49] <zyga> mvo: some good news, the leak is gone
[05:49] <zyga> mvo: but the case is not fully cloesd, we need to talk to the kernel team
[05:51] <pbek> 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] <zyga> pbek: it only does so if it is in a directory that cannot be represented
[05:51] <zyga> pbek: it may be in a directory that is represented but cannot be written to
[05:54] <pbek> 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] <zyga> pbek: that's correct
[05:55] <zyga> pbek: snaps should wite to $SNAP_USER_DATA or $SNAP_USER_COMMON
[05:55] <pbek> thank you again for your patience, zyga!
[05:55] <zyga> pbek: eventually you may use xdg portals to write to more places
[05:55] <pbek> yes, I found that out already (and am using using it for storing settings)
[05:55] <mvo> zyga: hey, good morning. yeah, I saw the mail
[06:37] <mup> PR snapd#5050 opened:  many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5050>
[06:40]  * zyga tries to get through his inbox today
[06:54] <mup> PR snapd#5051 opened: snap,wrappers: address review feedback from #5043 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5051>
[07:01] <mup> PR snapd#5044 closed: 'system' nickname for 'core' in snap get/set (2.32) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5044>
[07:02] <mup> PR snapd#5045 closed: overlord/snapstate:  poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5045>
[07:16] <pstolowski> morning
[07:20] <zyga> hey pawel
[07:20]  * zyga spent all of saturday and sunday outdoors, walking and biking a lot
[07:20] <zyga> and now endures the pain in all kinds of places :)
[07:25] <mborzecki> if anyone feels like doing some reading https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001
[07:27] <zyga> mborzecki: yeah
[07:28] <mborzecki> btw. i think there's a bug in nm, some signal not emitted at the right time/place
[07:28] <mborzecki> 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] <mborzecki> had to restart NM and then it got updated
[07:32] <ackk> 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] <zyga> mborzecki: replied
[07:39] <mborzecki> zyga: good points
[07:40] <kalikiana> good morning
[07:41] <zyga> Pharaoh_Atem: snap-confine package contains all kinds of things in fedora
[07:42] <zyga> Pharaoh_Atem: we should really disband that package and move those files over to snapd
[07:43] <mborzecki> disband ;) reminds me of civ
[07:50] <zyga> mborzecki: ha, yeah
[07:50] <zyga> disband militia in 2050 :)
[08:14] <Chipaca> moin moin
[08:15] <mborzeck1> wow, my network is flaky today
[08:16] <zyga> mvo: I will update the GitHub release page
[08:16] <zyga> although I plan to skip the .1 and .2 tarballs
[08:16] <zyga> just go to .4
[08:16] <zyga> I will use it to make the openSUSE release now
[08:19] <pedronis> mvo: hi, are you going to create .5 today?
[08:29] <mvo> pedronis: yes, I will do that hopefully ready around lunch time. do you have anything pending?
[08:30] <pedronis> no
[08:31] <pedronis> I saw you merged the doMountSanp/readInfo stuff
[08:32] <zyga> 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] <mvo> pedronis: yeah, I looked over it and it looked like a good idea to have it
[08:36] <pedronis> I'll update it in a bit
[08:36] <mborzecki> #3 is wontfix, #4 has had some error-catching fixes, #5 is almost fixed right?
[08:50] <mborzecki> any prs needing reviews?
[08:52] <zyga> Can you look at my trespassing pr
[08:53] <mborzecki> zyga: #4889 ? already did
[08:53] <mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
[08:53] <zyga> Ah, then no idea :-)
[08:53] <mborzecki> zyga: btw. it needs deconflicting
[08:53] <zyga> Oh thanks. I’ll do that shortly
[09:05] <mborzecki> #4983 needs a second review
[09:05] <mup> PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
[09:12] <Chipaca> can't linux mint run classic snaps?
[09:14] <mborzecki> is there a way to tell what type of confinement is supported by the system, other than running `snap debug confinement` ?
[09:17] <pedronis> zyga: updated
[09:17] <zyga> thanks!
[09:18] <Chipaca> mborzecki: what do you mean?
[09:20] <Chipaca> mborzecki: http snapd:///v2/system-info | jq .result.confinement
[09:20] <Chipaca> mborzecki: ?
[09:20] <mborzecki> 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] <Chipaca> mborzecki: AFAIK there isn't
[09:22] <Chipaca> mborzecki: i mean, not via 'snap'
[09:22] <Chipaca> mborzecki: maybe we want it in 'snap version' or sth?
[09:23] <Chipaca> mborzecki: (what for?)
[09:23] <mborzecki> 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] <Chipaca> mborzecki: 'please file a bug with your distribution' :-p
[09:24] <mborzecki> 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] <Chipaca> mborzecki: why not make .evil run 'snap debug confinement' or equivalent itself?
[09:26] <mborzecki> 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] <Chipaca> mborzecki: is this on arch btw?
[09:27] <mborzecki> Chipaca: yes
[09:33] <Chipaca> mborzecki: is there any info we could put next to 'arch' in the output of 'snap version'?
[09:34] <Chipaca> i know it's rolling, but maybe, the time of the last update?
[09:34] <Chipaca> dunno
[09:34] <Chipaca> mborzecki: we could add confinement to distro info instead of as a new line if the new line is frowned on
[09:34] <mborzecki> Chipaca: - ?
[09:36] <mborzecki> Chipaca: https://paste.ubuntu.com/p/CGJZ9XPnSv/
[09:37] <Chipaca> mborzecki: aw :-) ok
[09:38] <zyga> IMO putting this on the distribution version is silly
[09:38] <zyga> let's just do it properly
[09:38] <zyga> confinement: seccomp(...), cgroup(device, freezer), namespace(mount), apparmor(...)
[09:41] <Chipaca> zyga: note that that's not exposed via system info yet
[09:41] <Chipaca> +1 to it or something like it if it were
[09:42] <mup> PR snapd#5050 closed:  many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5050>
[09:42] <mborzecki> zyga: seccomp(...) as in actions?
[09:42] <zyga> yeah, some version details there
[09:49] <mborzecki> 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] <mborzecki> 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] <zyga> mvo: updated https://github.com/snapcore/snapd/releases/tag/2.32.4
[09:57] <zyga> mborzecki: I think we have too many commands but I agree we should have some way to s how this
[09:58] <zyga> mborzecki: I doubt most users will undertstand more than I said initially on a single-line confinement value
[09:58] <mborzecki> ok, so maybe `confinement: (strict|partial)` in snap version is all that we need
[09:59] <mvo> zyga: thanks! .5 is rolling forward
[10:01] <pedronis> mvo: so .5 doesn't include 5051 ?
[10:02] <mup> PR snapd#5052 opened: cmd/snap: handle distros with no version ID <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5052>
[10:02] <mborzecki> Chipaca: ^^
[10:02] <mvo> pedronis: no, I think its fine, its cosmetic but if you feel strongly about it I can include it too
[10:04] <zyga> mvo: that's odd, we had that patched before
[10:04] <Chipaca> mborzecki: +1
[10:04] <zyga> ah
[10:04] <zyga> I see what the patch does now
[10:04] <zyga> mvo: ping me when .5 tarball is up
[10:05] <popeycore> diddledan: you havint trouble with irccloud today?
[10:05] <popeycore> fails to launch here on core stable, and I just get 3 dots in the screen constantly
[10:06] <pedronis> 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] <zyga> why would we need a 6?
[10:06] <pedronis> exactly, we don't know
[10:06] <pedronis> that's how that stuff happens
[10:09] <mvo> zyga: what is odd?
[10:09] <zyga> mvo: nothing, I misunderstood the output
[10:09] <zyga> mvo: - vs ""
[10:09] <mvo> pedronis: ok, I will pull it into release/2.32 just in case we need a .6
[10:09] <mvo> pedronis: it does make sense
[10:09] <zyga> mvo: https://github.com/snapcore/snapd/pull/5053
[10:09] <mup> PR #5053: release-tools: handle the snapd-x.y.z version <Created by zyga> <https://github.com/snapcore/snapd/pull/5053>
[10:10] <mvo> zyga: ta, I have a look. .5 is available in the ppa, one sec, I look for a direct link for you
[10:10] <zyga> mvo: FYI I have tested jj's fix and it's stable over extended periods of time
[10:10] <zyga> mvo: oh, neat
[10:10] <zyga> just push the tag, I'll do the rest :)
[10:10] <mvo> zyga: tag is pushed as well
[10:10] <mup> PR snapd#5051 closed: snap,wrappers: address review feedback from #5043 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5051>
[10:10] <mup> PR snapd#5053 opened: release-tools: handle the snapd-x.y.z version <Created by zyga> <https://github.com/snapcore/snapd/pull/5053>
[10:10] <mvo> zyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/8990918/+listing-archive-extra has the build
[10:10] <zyga> Son_Goku: good morning
[10:12] <popeycore> diddledan: must have been corrupted config, removed and reinstalled the snap and it's fine \o/
[10:12] <mup> PR snapd#5054 opened: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5054>
[10:15] <mup> PR snapd#5055 opened: release: 2.32.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5055>
[10:20] <zyga> mvo: https://github.com/snapcore/snapd/releases/tag/2.32.5
[10:21] <zyga> can you please check if I got the refresh/stop mode bits right
[10:23] <zyga> mvo: .5 failed to build for ppc
[10:23] <mvo> zyga: looking, I suspect a stray failure
[10:24] <zyga> pedronis: https://bugs.launchpad.net/snappy/+bug/1764069
[10:25] <mup> Bug #1764069: Can't install snaps (X-Ubuntu-Series header is required - connection refused) <Snappy:New> <https://launchpad.net/bugs/1764069>
[10:32]  * zyga -> walk
[10:32] <zyga> popey: notepad++ looks bad on high-dpi system
[10:32] <zyga> not sure if there's anything we can do to tell wine" hide"
[10:32] <zyga> "hidpi"
[10:32] <popey> Indeed
[10:33] <popey> We don't pass through pixel doubling in some apps
[10:33] <popey> not just WINE
[10:37] <Chipaca> popey: do you know what we need to pass through?
[10:37] <popey> 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] <mup> PR snapd#5052 closed: cmd/snap: handle distros with no version ID <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5052>
[10:46] <mborzecki> 5052 for 2.32 in case we do a .6 release? ;)
[10:48] <Chipaca> mborzecki: too much regression potential
[10:49] <Chipaca> :-p
[10:49] <pedronis> zyga: afaict that's a DNS problem
[10:53] <zyga> Ok
[10:59] <pedronis> mvo: this changelog line looks strange:   daemon: support 'system' as nickname of the core snapchange it is
[10:59] <pedronis> +      possible to do:
[11:00] <pedronis> change it is ...  seems spurious
[11:03] <mborzecki> pedronis: my fault, i tend to include how the command output looks like in the commit messages
[11:04] <pedronis> I'm not sure, the whitespace is wrong either way
[11:08] <mvo> pedronis: yeah, the whitespace there is incorrect. good catch
[11:08] <mvo> pedronis: look like the script that generates them has a bug there, I look into it
[11:16] <mup> PR snapd#5056 opened: cmd/snap: make confinement mode part of `snap version` output <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5056>
[11:17]  * Chipaca trundles off in search of something to lunch
[11:23] <zyga> re
[11:23]  * zyga works on .5 release for opensuse
[11:25] <Chipaca> zyga: .6 is where it's at
[11:25]  * Chipaca runs
[11:25] <zyga> Chipaca: what?!?
[11:25] <zyga> are we doing a .6 now
[11:26] <zyga> is this what "eventually released" software is like?
[11:32] <pedronis> .5.4.3.2.1
[11:33] <mborzecki> approximating towards 2.33
[11:34] <zyga> Chipaca: should we use LazyUnmount= in our .mount units?
[11:34] <pedronis> effectively :)
[11:34] <pedronis> (that was about approx 2.33)
[11:35] <cachio> mvo, should I start testing .5 or I should wait for a .6?
[11:35] <pedronis> cachio: I don't think we plan a .6 atm
[11:36] <cachio> pedronis, ah, ok
[11:36] <cachio> thanks, I'll run beta validation for .5 in that case
[11:37] <cachio> mborzecki, hey, amazon linux image is ready
[11:37] <cachio> but you just can use it
[11:37] <cachio> if you use this spread
[11:37] <zyga> 2.32.4 is building for all opensuse systems now
[11:37] <cachio> mborzecki, https://github.com/snapcore/spread/pull/57
[11:37] <mup> PR spread#57: Adding preserve option for systems to keep the default image size <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/57>
[11:37] <cachio> mborzecki, beasuse the filesystem cannot be resized
[11:38] <mborzecki> cachio: what's the system name in spread.yaml?
[11:38] <cachio> mborzecki, basically it is not possible to shrink xfs filesystems
[11:39] <cachio>             - amazon-linux-2-64:
[11:39] <cachio>                 workers: 1
[11:39] <cachio>                 preserve: true
[11:39] <cachio> mborzecki, you can add that
[11:39] <cachio> with that branch
[11:41] <mborzecki> ok
[11:41] <cachio> mborzecki, I'll going the the kinesiology now, I'll explain better during the standup
[11:41] <mborzecki> cachio: i'll try to run it, thanks
[11:42] <cachio> mvo, there is not changelog for 2.32.4 -> 2.32.5
[11:45] <zyga> cachio: I made "some" changelog
[11:45] <zyga> cachio: https://github.com/snapcore/snapd/releases/2.32.5
[11:51] <zyga> Caelum: I updated snapd twice to 2.32.4 and now to 2.32.5
[11:51] <zyga> Caelum: let me know if you run into any issues
[11:51] <zyga> Caelum: although this release should be very stable now
[11:58] <zyga> mvo: maybe I could look at updating the debian package
[11:59] <zyga> Pharaoh_Atem: I will have a small selinux patch for you to review soon
[12:01] <zyga> does anyone know what networkd-dispatcher is for?
[12:02] <zyga> mvo: how is our upload to bionic like?
[12:02] <zyga> mvo: can we upload .5 now?
[12:02] <zyga> and similar question about xenial SRU
[12:03] <mborzecki> off to get the kids
[12:08] <popey> 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] <zyga> popey: with classic snaps
[12:09] <zyga> popey: otherwise it should work
[12:09] <zyga> popey: with classic snaps it can work but the snap needs to understand the particular layout of the host
[12:09] <popey> This needs documenting somewhere.
[12:13] <zyga> popey: yes, no disagreement there
[12:15] <zyga> mvo: when we have more bases and more core18 things
[12:16] <zyga> mvo: I was thinking that we should drop the "series 16" line from snap version
[12:16] <zyga> we could show it on core devices
[12:16] <zyga> and actually show the name of the bootable base
[12:16] <zyga> I think right now it's not a very useful/informative thing
[12:18] <mup> Bug #1764069 changed: Can't install snaps (X-Ubuntu-Series header is required - connection refused) <Snappy:Invalid> <https://launchpad.net/bugs/1764069>
[12:18] <zyga> mvo: hey, is issue #5 solved with 2.32.5 now?
[12:20] <mup> PR snapd#4833 closed: tests: add a detector for kernel bug https://pad.lv/1755563 <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4833>
[12:23] <zyga> mvo: given that #5043 is for 2.32.x, do you still plan to make additional release (that is, .6)?
[12:23] <mup> PR #5043: many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode <Critical> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5043>
[12:28] <mvo> zyga: reading backlog now
[12:30] <mvo> 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] <pstolowski|lunch> 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] <mvo> zyga: 5043 has lnaded in .5, no?
[12:32] <mvo> zyga: or what am I missing?
[12:32]  * kalikiana lunch
[12:33] <zyga> mvo: has it? the branch is open
[12:33] <zyga> ah
[12:33] <zyga> sorry
[12:33] <zyga> I mean 5054
[12:34] <zyga> 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] <mvo> zyga: checking
[12:34] <Son_Goku> 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] <mvo> mup #5054
[12:35] <mup> PR #5054: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5054>
[12:35] <zyga> mvo: offtopic, remember those 100s of threads? my bionic shows 11 threads in .5
[12:35] <mvo> 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] <mvo> zyga: I do remember that
[12:35] <zyga> mvo: understood now, thanks
[12:35] <pstolowski|lunch> Son_Goku: okay, i'll dig into the new guideline after lunch
[12:36] <mvo> zyga: thank you! so the 100s threads I don't see on my two bionic machines
[12:36] <mvo> zyga: so not sure what is going on there
[12:36] <Chipaca> huh, gnome software has a 'restart and install' button
[12:36] <mvo> zyga: #5 *should* be fixed in beta but I hope to get confirmation from a real world test case later today
[12:36] <mvo> Chipaca: for installing updates?
[12:37] <zyga> Chipaca: yes, for some years now :)
[12:37] <mvo> cachio: thanks for the sru validation!
[12:37] <Chipaca> mvo: I'm guessing what it describes as firmware is a bios update
[12:37] <zyga> Chipaca: it's a very old systemd/fedora/pkgkit feature
[12:37] <mvo> cachio: also yeah beta validation for .5 sounds great!
[12:37] <zyga> it's not related to firmware
[12:38] <zyga> 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] <Son_Goku> pstolowski|lunch, guideline in question is documented here: https://fedoraproject.org/wiki/More_Go_packaging
[12:39] <Chipaca> zyga: I don't open gnome-software often (i've only recently had enough memory to keep it installed at all)
[12:41] <mvo> zyga: what is the link to the 18.04 post again? then I can update #5
[12:41] <zyga> mvo: https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954
[12:42] <mvo> zyga: ta!
[12:43] <mvo> 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] <mup> PR #4954: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4954>
[12:44] <mvo> zyga: updated, thanks you
[12:46] <zyga> mvo: we have new pam and netplan
[12:48] <mvo> zyga: yeah, changelog looks mostly harmless
[12:48] <zyga> yes
[13:32] <kalikiana> re
[13:32] <popey> zyga: to be clear, the snap which I am having trouble with is _not_ a classic snap.
[13:36] <mborzecki> arch updated to 2.32.5
[13:36] <popey> I'll speak to snapcraft chaps, as it could be that.
[13:37] <mborzecki> popey: still mame thing?
[13:37] <popey> yeah
[13:37] <mborzecki> i posted the logs from friday in the LP bug report
[13:37] <popey> you mentioned rpath, but I dont know what *I* am doing wrong here
[13:37] <popey> yeah, I saw.
[14:04] <pstolowski> niemeyer: will you have some time to talk about hotplug after your current meeting?
[14:29] <tyhicks> 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] <mup> Bug #1750594: Eventual OOM with profile reloads <AppArmor:Fix Committed> <https://launchpad.net/bugs/1750594>
[14:30] <zyga> 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] <mup> PR snapcraft#2074 closed: Release changelog for 2.41 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2074>
[14:30] <zyga> it's annoying but not user-critical from my POV
[14:30] <zyga> mvo: ^
[14:30] <zyga> tyhicks: will live kernel patches fix it?
[14:30] <tyhicks> that's my understanding of the bug, as well
[14:30] <tyhicks> zyga: no, we don't plan to do a livepatch for it
[14:31] <tyhicks> 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] <mvo> tyhicks: hi, in a meeting right now
[14:32] <mvo> tyhicks: let me reply as quick as I can
[14:32] <tyhicks> thanks
[14:35] <niemeyer> pstolowski: I'm just off and have a few minutes before lunch.. can you talk now?
[14:36] <pstolowski> niemeyer: yes
[14:36] <niemeyer> pstolowski: Ok, standup then
[14:47] <mup> PR snapd#5057 opened: tests: bring back one missing test in snap-service-stop-mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/5057>
[14:53] <Chipaca> niemeyer: 10MB unaccounted for after creating a bolt db. Will continue digging.
[14:53] <Chipaca> RSS of a simple thing goes from 4MB to 14MB
[14:54] <niemeyer> Chipaca: That sounds very promising
[14:55] <niemeyer> Chipaca: One data point worth gathering is what happens if we open that same file in RO mode
[14:57] <Chipaca> niemeyer: 8MB rss
[14:57] <pstolowski> 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] <niemeyer> Chipaca: Unaccounted or total? That is, 4 to 12, or 4 to 8?
[14:58] <Chipaca> niemeyer: actually 10MB if the code to create it is still there, just not used
[14:58] <Chipaca> niemeyer: total
[14:58]  * Chipaca needs to step away for a bit, will bbl
[15:02] <Chipaca> niemeyer: time.Sleep -> 4MB, ro bolt: 8MB, ro bolt and rw code unused: 10MB; rw bolt: 14MB
[15:02]  * Chipaca afk
[15:04] <cachio> mvo, https://paste.ubuntu.com/p/Z59BDC4VWq/
[15:04] <cachio> running beta validation for 64 bits
[15:05] <cachio> mvo, it is like the system was rebooted after line 53
[15:05] <cachio> but it shouldn't
[15:06] <mvo> cachio: yeah, this is stange, anything in syslog?
[15:06] <mborzecki> 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] <cachio> mvo, this is from syslog
[15:07] <cachio> mvo, I already saw that doing refresh from stable too
[15:07] <cachio> similar problem
[15:08] <mvo> cachio: uh uh
[15:08] <mvo> cachio: is this on a core device? or 16.04?
[15:09] <cachio> mvo, from journalctl https://paste.ubuntu.com/p/DsqmKfDGNv/
[15:10] <cachio> it is core-16-64
[15:10] <cachio> a vm
[15:10] <mvo> this is very uncommon
[15:10] <mvo> 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] <mup> PR #16: Feature/git buildpackage <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/16>
[15:10] <cachio> mvo, yes, first time I see this
[15:12] <mvo> cachio: confusing
[15:13] <cachio> mvo, this has more info https://paste.ubuntu.com/p/2ty37JM39W/
[15:15] <mvo> cachio: yeah, more info but still very confusing. I wonder what change from .4 -> .5 might cause this :(
[15:15] <niemeyer> Chipaca: Hmm.. are we keeping the file open? If we close the database and discard the structure, does the extra RSS memory go away?
[15:15] <oSoMoN> the latest build of the chromium snap on launchpad failed automated review in the store ("checksums do not match"), is that a known issue with the store/snapcraft, or could it be just that specific snap?
[15:15] <mvo> cachio: is it reproducible?
[15:15] <niemeyer> Chipaca: If it doesn't, that must be a bug
[15:15] <niemeyer> Chipaca: If it does, then we should probably just do that for the release
[15:15] <cachio> mvo, I don't know
[15:15] <cachio> I'll try
[15:15] <mvo> cachio: thank you!
[15:16] <niemeyer> Chipaca: Or at least keep it RO, if it impacts runtime of advice too much
[15:16] <mvo> cachio: it looks very fishy, is this in a VM ? or on real HW?
[15:16]  * niemeyer lunch
[15:16] <cachio> mvo, it is a vm
[15:16] <mvo> cachio: hm, hm, then that is double confusing
[15:17] <mvo> cachio: I was wondering if there might be some HW issue that triggered the reboot but not in a VM
[15:17] <mvo> (usually)
[15:17] <cachio> in parallel I was running i386
[15:17] <cachio> and it worked fine
[15:17] <mvo> cachio: it *might* be the oom issue but given that we have not seen that beforre on non !i386 its unlikely
[15:17] <mvo> cachio: ok, cool. at least that is good to know
[15:36] <oSoMoN> I just rebuilt the chromium snap again on launchpad, and got the same error (checksums do not match) : https://code.launchpad.net/~chromium-team/+snap/chromium-snap-stable/+build/193033
[15:36] <oSoMoN> known issue?
[15:37] <oSoMoN> ah, apparently it is bug #1763641
[15:37] <mup> Bug #1763641: Checksum mismatch error when uploading a snap to the store <Canonical Click Reviewers tools:Fix Committed by jdstrand> <https://launchpad.net/bugs/1763641>
[15:42] <oSoMoN> however the bug says that this shouldn't happen with snapcraft 2.40, but the chromium snap is built on LP and the log says it's using snapcraft 2.40 (deb)
[15:42] <mup> PR snapcraft#2079 opened: repo: catch error updating the package cache <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2079>
[15:43] <Caelum> zyga: nice, will look in a bit, and also post to factory list
[15:51] <zyga> Thanks!
[15:54] <pedronis> mvo: that's the new checking code in doMountSnap
[15:55] <mup> PR snapd#5055 closed: release: 2.32.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5055>
[15:57] <mvo> pedronis: oh, so it already caught a case where things did not quite work correctly?
[15:57] <mup> PR snapd#5058 opened: packaging: fix incorrectly auto-generated changelog entry for 2.32.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5058>
[15:57] <pedronis> mvo: maybe, or we are misunderstanding something
[15:58] <mvo> cachio: -^
[15:58] <cachio> mvo, not yet
[15:59] <mvo> pedronis: cool, I need to leave in a wee bit to play hockey but I will read backlog, would be great to learn if we introduced a regression
[15:59] <cachio> working on that
[15:59] <mvo> cachio: thank you
[15:59] <sergiusens> zyga, jdstrand any insight on https://paste.ubuntu.com/p/ZP6R7WM4Kz/ ?
[15:59] <mvo> cachio: just wanted to let you know that pedronis  has an idea where the error comes from but its not clear yet if it is just making an existing error visible or if its something new
[16:00] <cachio> mvo, ok
[16:00] <cachio> mvo, perhaps it is not new but it is cannot be reproduced easily
[16:01] <cachio> mvo, I'll make many executions today to see if I can reproduce it
[16:01] <cachio> mvo, pedronis  I'll keep you updated in case I find something
[16:02] <mvo> cachio: thank you!
[16:03] <mvo> cachio: thanks to pedronis we have much improved error checking around this area of code now, so maybe it surfaces something that existed before. I will read backlog, need to play hockey now
[16:03] <cachio> mvo, nice, enjoy it
[16:04] <mvo> cachio: thank you! yeah, I am excited
[16:10] <pedronis> cachio: it's strange because it seems we are rebooting in the middle of installing a local snap
[16:11] <pedronis> Chipaca: what happens if we reboot when installing a local snap?  it seems the snap is copied into /tmp, but tmp will be cleared on reboot
[16:13] <pedronis> cachio: am I misreading that there's a reboot going on at the start of that test?
[16:14] <pedronis> cachio: do we have a bug about stopping refreshes during some of the core tests?
[16:17]  * kalikiana eod
[16:19] <cachio> pedronis, I don't think so, but let me re-check
[16:28] <Chipaca> pedronis: AFAIK it fails if it happens before the (snap.Container).Install, otherwise it succeeds
[16:28] <Chipaca> pedronis: (that's the bit that copies the local snap into /var/lib/snapd/snaps iirc)
[16:28] <pedronis> it seems we are hitting the scenario in a test
[16:28] <Chipaca> hehe
[16:29] <pedronis> but I'm not sure why there is rebooting going on though
[16:30] <pedronis> Chipaca: do you agree that there is some system restarting going on here:  https://paste.ubuntu.com/p/DsqmKfDGNv/ ?
[16:31] <pedronis> there's too much starting, early, stuff and systemd talking about early boot stuff
[16:31] <Chipaca> niemeyer: we are not keeping the file open, and we do a commit and close on the db
[16:31] <pedronis> Chipaca: another theory is that snapd and the test starts before the cleaning of tmp happens
[16:31] <Chipaca> niemeyer: the only reason snapd uses boltdb is to write that databse, having it ro is like not having it
[16:32] <niemeyer> That's pretty awkward. Why would the memory stay resident
[16:32] <Chipaca> pedronis: looking
[16:32] <pedronis> bu that makes sense only if tmp is not a tmpfs
[16:32] <Chipaca> niemeyer: ＭＡＧＩＣ
[16:32] <niemeyer> Chipaca: I guess Go's GC
[16:33] <niemeyer> Chipaca: There is (was?) a method in the runtime package to "encourage" the GC to give memory back to the system
[16:34] <Chipaca> pedronis: no that doesn't look like early boot stuff
[16:34] <Chipaca> pedronis: it looks like snapd starts, and systemd says 'ok i'm done'
[16:34] <Chipaca> niemeyer: runtime.GC()?
[16:36] <niemeyer> Chipaca: No, that just kicks the GC.. let me check
[16:36] <pedronis> Chipaca: but we are after a reboot, right?
[16:37] <pedronis> Chipaca: otherewise there would not be that Reached target stuff
[16:37] <Chipaca> niemeyer: runtime/debug's FreeOSMemory?
[16:37] <niemeyer> Yes!
[16:38] <cachio> pedronis, now error on i386 https://paste.ubuntu.com/p/hkxVgZDZgk/
[16:39] <pedronis> I don't see an "error" in that log
[16:40] <Chipaca> niemeyer: it helps a little (14 -> 12 for rw, 10->9 for ro w/unused rw)
[16:40] <cachio> pedronis, this is for 64 bits https://paste.ubuntu.com/p/5MHzmfjJP8/
[16:41] <cachio> pedronis, no errors
[16:41] <cachio> but suddenly rebooted
[16:41] <pedronis> ah
[16:41] <pedronis> so we are getting reboots
[16:41] <cachio> pedronis, yes
[16:42] <pedronis> I don't see anything about "core" in those logs
[16:42] <pedronis> not sure what would provoke reboots
[16:42] <pedronis> that is new
[16:42] <pedronis> I understand why reboot would make other things fail
[16:42] <pedronis> but not what make us reboot
[16:42]  * pedronis -> dinner
[16:49] <Chipaca> blame spectre
[16:50] <oSoMoN> jdstrand, have you seen my comment on bug #1763641 ? If I read the bug correctly I shouldn't be seeing this error with snapcraft 2.40, but I am
[16:50] <mup> Bug #1763641: Checksum mismatch error when uploading a snap to the store <Canonical Click Reviewers tools:Fix Committed by jdstrand> <https://launchpad.net/bugs/1763641>
[16:50] <oSoMoN> I ran reviews-tool from edge on the snap and got no such error
[16:56] <zyga> sergiusens: did corebird work before?
[16:56] <zyga> PAM got updated recently but I don’t think we’d break abi
[16:58] <diddledan> I might have told the build to not prime libkrb5
[17:13] <pedronis> zyga: we are getting random reboots on .5
[17:13] <pedronis> cachio: we didn't see these reboots with .4 ?
[17:14] <zyga> Hmmmm
[17:14] <zyga> What do we know?
[17:14] <cachio> not for beta scenario at least
[17:14] <zyga> .5 has new PAM and nplan
[17:14] <diddledan> danke popey
[17:15] <popey> I didnt know we had source-checksum!
[17:15] <popey> TIL
[17:15] <diddledan> inorite
[17:15] <cachio> pedronis, I just saw some problems but for factory release to beta
[17:15] <zyga> Changelog from for .5 is not extensive, mainly new API and a bugfix
[17:16] <zyga> Is there any chance this is caused by new stop restart mode
[17:16]  * Chipaca afk
[17:16] <cachio> pedronis, zyga perhaps something else in the beta image it is causing this
[17:16] <cachio> new kernel
[17:16] <zyga> Oh
[17:16] <zyga> Which one?
[17:18] <zyga> I will be home soon
[17:21] <zyga> pedronis: who reported this and how?
[17:21] <pedronis> cachio
[17:21] <pedronis> running the validation
[17:21] <cachio> zyga, at least for dragonboard there was a new one
[17:22] <cachio> pedronis, there are 2 scenarios, first is to create a beta image  and run  the tests for that image
[17:22] <cachio> last execution I didn't see any error
[17:22] <cachio> pedronis, this time I saw this reboot
[17:23] <cachio> pedronis, but it is not failing 100% of the cases
[17:23] <cachio> so, perhaps the same error was present in the previous validation and I did not reproduce it
[17:24] <cachio> but today first exec I saw the errror
[17:24] <cachio> for core-16-64
[17:24] <cachio> and core-16-32 worked properly
[17:24] <cachio> 100% pass
[17:25] <zyga> cachio: on what hardware?
[17:25] <cachio> then I rexecuted both and both failed
[17:25] <cachio> I am running those on vms
[17:25] <pedronis> probably worth trying  a couple runs with .4 I suppose
[17:25] <zyga> So amd64/kvm
[17:25] <pedronis> to see if it's really .5
[17:25] <zyga> Yes
[17:25] <zyga> Let’s test .4 in the same host
[17:26] <cachio> ok
[17:26] <cachio> I'll do that
[17:26] <zyga> Thank you
[17:27] <pedronis> of course if it's new kernel we need to separate that somehow
[17:29] <zyga> It could also be the oom bug
[17:30] <pedronis> does it provokes reboots though?
[17:30] <zyga> It is disabled on 32bit systems but also happens on 64 big systems the same,  just takes longer
[17:30] <pedronis> or only errors?
[17:30] <zyga> It eats all ram over time till kernel crashes
[17:30] <zyga> With swap it’s a slow painful death
[17:30] <zyga> Without swap it is quick and clear
[17:32] <zyga> As an option we can do .6 with one of my workarounds
[17:47] <diddledan> for the coders among us, Brenden Eich on Javascript's evolution: https://www.youtube.com/watch?v=3-9fnjzmXWA
[17:54] <ogra_> there are coders among us ?
[17:57]  * popey steps back
[17:58] <kyrofa> Yes, but I heard the word "javascript" and ran
[17:58] <diddledan> :-p
[17:59]  * zyga looks at the reboot issue
[17:59] <zyga> pedronis, cachio: we have a forum thread for the problem?
[18:09] <cachio> zyga, no yet
[18:10] <cachio> zyga, I'll create it
[18:10] <zyga> thank you
[18:15] <zyga> the pastebin I read looks very weird, I doubt that's OOM
[18:16] <zyga> it looks like we really trigger a graceful shutdown shomehow
[18:16] <zyga> cachio: does it happen in one spot or in some random place during testing
[18:17] <cachio> the pattern that I saw in the syslog is
[18:18] <cachio> https://paste.ubuntu.com/p/DVJNqD5yHP/
[18:18] <cachio> in all the cases I saw something like this before the reboot
[18:19] <nacc> how can i change the owner of a snap in the store
[18:20] <cachio> zyga, and then this
[18:20] <cachio> https://paste.ubuntu.com/p/vTM3bYx2Ph/
[18:21] <cachio> I am running now 16-2.32.4 to see if I can reproduce it
[18:23] <cachio> zyga, I thinks  2/3 cases happened installing snapd
[18:23] <cachio> snaps
[18:23]  * zyga dinner, I will check soon
[18:26] <nacc> i specifically need to adjust the ownership of git-ubuntu, git-ubuntu-stable and git-ubuntu-beta away from my user
[18:41] <sergiusens> nacc: to canonical, snapcrafters or another individual user?
[18:45] <popey> nacc: post on the forum in the store category
[19:06] <kyrofa> Hey niemeyer, I can't get the LXD backend of spread to ever work for 17.10 or 18.04, they always end up failing with "2018-04-16 19:01:30 Discarding lxd:ubuntu-17.10 (spread-8-ubuntu-17-10), cannot connect: cannot connect to lxd:ubuntu-17.10 (spread-8-ubuntu-17-10): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain"
[19:06] <kyrofa> Any ideas?
[19:09] <om26er> popey: up ?
[19:09] <popey> om26er: yo!
[19:09] <om26er> oh boy you are always online, cool.
[19:10] <om26er> popey: sublime is broken and I hope we can land its fix ASAP.
[19:10] <om26er> we do have it published in edge channel but it won't start
[19:10] <popey> ok, let me take a look now.
[19:10] <popey> oh, it's classic. Are you on nvidia?
[19:11] <om26er> popey: no, Intel
[19:11] <popey> ok, lemme see
[19:14] <popey> ok, merged your PR, lets see what that builds
[19:14] <om26er> great stuff.
[19:14] <om26er> thanks popey
[19:14] <popey> np
[19:17] <zyga> cachio: any news
[19:18] <cachio> I ran 2.32.4 and I didn't see any error yet
[19:18] <cachio> zyga, I am re-executing now
[19:19] <zyga> can you upload the manifest
[19:19] <cachio> I created images using candidate
[19:19] <cachio> channel
[19:19] <cachio> and ran the tests
[19:19] <cachio> zyga, but no errors yet
[19:19] <cachio> zyga, the same it is failing 66% of the times on beta
[19:19] <zyga> cachio: so mvo suggested some ideas
[19:19] <zyga> can you upload the manifests somewhere
[19:20] <cachio> zyga, sure
[19:20] <zyga> mvo said it would be in /usr/share/dpkg/snap* something
[19:20] <zyga> also how big is the image
[19:20] <zyga> can you upload the failing image as you got it now
[19:21] <cachio> zyga, sure
[19:21] <zyga> thanks!
[19:21] <cachio> it is also very easy to generate it
[19:21] <cachio> and faster
[19:21] <cachio> with my wifi it could take long to upload
[19:21] <cachio> zyga, clone git@github.com:sergiocazzolato/validator.git
[19:21] <cachio> and then run
[19:22] <cachio> ./create.sh beta pc-amd64
[19:22] <cachio> ./create.sh beta pc-i386
[19:22] <zyga> trying
[19:22] <cachio> that will be faster
[19:23] <zyga> which ubuntu-image are you using?
[19:23] <zyga> from deb/snap
[19:23] <zyga> and which version
[19:23] <cachio> deb
[19:24] <cachio> ubuntu-image 1.3+16.04ubuntu2
[19:25] <zyga> I'm on 1.3+18.04ubuntu2
[19:25] <zyga> but I'll make an image and try this way first
[19:25] <zyga> if my image works can you upload your image
[19:25] <zyga> we can compare binary stuff inside
[19:25] <cachio> zyga, sure
[19:26] <zyga> maybe overnight
[19:26] <zyga> so we can analyze tomorrow
[19:31] <niemeyer> kyrofa: I think there is a patch from Saviq that fixes that, from long ago.. sorry for not having merged it yet.. will try to have a look today still
[19:31] <kyrofa> niemeyer, ah, excellent, okay thank you
[19:31] <zyga> cachio: my dpkg.list from /usr/share/snappy/dpkg.list http://paste.ubuntu.com/p/JWPqJFWH7D/
[19:31] <zyga> cachio: can you check if you have the same one
[19:32] <zyga> cachio: I'm running kernel 4.4.0-121-generic
[19:32] <kyrofa> Yep, that looks like it
[19:32] <cachio> ok
[19:39] <zyga> cachio: are you running the same thing on your test machine?
[19:40] <cachio> zyga, checking
[19:42] <cachio> zyga, the kernel is the same
[19:43] <cachio> zyga, same
[19:43] <cachio> the list is the same
[19:43] <zyga> ok, thanks
[19:43] <cachio> zyga, I am running again now
[20:01] <mvo> cachio: I just chatted with zyga and he told me about the reboot issues (and you did so as well earlier). I just checked, might be worth running with the kernel from stable, looks like the kernel in beta got released just today
[20:02] <cachio> mvo, you mean the kernel snap?
[20:03] <zyga> yes
[20:03] <mvo> cachio: yes
[20:03] <cachio> let me cehck that
[20:03] <mvo> cachio: I was just looking at the things that changed recently and noticed that this might be something
[20:04] <mvo> cachio: I will also run the testsuite against a freshly build image to see if I can find any clues
[20:04] <cachio> mvo, I just created a new image 20 minutes ago
[20:04] <cachio> and I am running again against this new one
[20:05] <cachio> so far no errors
[20:05] <cachio> mvo, but just 31/199 yes
[20:05] <cachio> yet
[20:06] <cachio> mvo, I am in i386 and I have  pc-kernel  4.4.0-120.144  111   beta      canonical  kernel
[20:07] <cachio> there is a new one in beta
[20:07] <cachio> 4.4.0-121.145
[20:07] <cachio> I'll regenerate also i386 image to see if the problem persist
[20:10] <mvo> cachio: thanks. I just build an amd64 image, is that correct?
[20:10] <mvo> cachio: aha, nice if you have an i386 image with an older kernel its interessting to see if the new kernel changes anything
[20:11] <cachio> mvo, :(
[20:11] <cachio> I just delete it
[20:11] <cachio> overwrite it
[20:12] <mvo> cachio: no worries
[20:26] <om26er> popey: https://github.com/snapcrafters/sublime-text/pull/10
[20:26] <mup> PR snapcrafters/sublime-text#10: Remove architectures stanza as it breaks auto builds <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/10>
[20:29] <om26er> ...and this https://github.com/snapcrafters/android-studio/pull/20 (though not urgent)
[20:29] <mup> PR snapcrafters/android-studio#20: remove architectures stanza <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/20>
[20:30] <popey> om26er: merged both
[20:30] <popey> thank you!
[20:31] <om26er> super!
[20:33] <om26er> we probably need to define some kind of "trust" chain (equivalent of MOTU/Core dev ?), so that we don't always have to bug you to get things landed.
[20:33] <popey> there are others who have access :)
[20:36] <om26er> apart from Martin, ev and you ? talking about snapcrafters repos only
[20:36] <popey> yeah, currently the three of us
[20:36] <om26er> its generally difficult to get a hold of flexiondotorg
[20:37] <popey> he's Wimpress  now :)
[20:37] <om26er> ev, I am not sure if he hangs around here.
[20:37] <popey> he doesn't
[20:37] <om26er> aah
[20:37] <popey> he hates irc
[20:37] <popey> like, passionately :)
[20:37] <Wimpress> It is I
[20:38] <Wimpress> And popey will burn in the embers of the heat death of the universe for being a lying #&$%
[20:38] <om26er> alright, its the two of you then ;-)
[20:38] <mvo> cachio: tests with stable kernel still going strong, I had one issue with python3 /nsap/network-bind-consumer/x1/bin/consumer eating all cpu and producing log messages I think we need to ensure in the relevant test that we kill it
[20:39] <Wimpress> I see the reference to hating IRC was not attributed to me.
[20:39] <Wimpress> #carryon
[20:39] <om26er> popey: Wimpress still when snaps take over the world, MOTU/Core dev like access may be necessary.
[20:39] <cachio> mvo, which is the test?
[20:39] <popey> om26er: well, ideally these would all be gone from snapcrafters and owned upstream :)
[20:39] <om26er> not today, but hopefully soon -__-
[20:39] <popey> :)
[20:40] <cachio> mvo, I am rnnning refresh scenario too
[20:40] <cachio> mvo, let's see how it goes
[20:41] <mvo> cachio: I'm not sure what test triggers this, just noticed
[20:41] <cachio> mvo, ok, I'll check it
[20:42] <om26er> popey: sublime text is good now
[20:42] <om26er> \o/
[20:42] <om26er> zyga: ^ its in edge
[20:42] <zyga> thanks!
[20:42] <zyga> mvo: I have a helper snap for redirecting systemctl
[20:43] <popey> om26er: alias works too?
[20:43] <om26er> popey: yep, subl
[20:43] <popey> wow, that launches fast
[20:43] <popey> om26er: released. thanks so much for all your work on this!
[20:43] <popey> Sorry it took so long.
[20:44] <popey> https://snapcraft.io/sublime-text
[20:44] <mvo> cachio: and I noticed sometihng interessting too, when I log into the VM while the test is running I see a "system is going gown" message, so there is a planned reboot triggered by a test, for me the planned reboot message starts at 22:38 and the following tests run then http://paste.ubuntu.com/p/d3xsB4KQMP/ so one of these tests triggers a change that includes core/kernel which triggers the reboot
[20:44] <om26er> popey: no problem, lets see if the upstream wants it now
[20:45] <cachio> mvo, weird
[20:45] <popey> maybe wait till we promote it and get more installs :)
[20:45] <cachio> I didn't see any reboot scheduled
[20:45] <cachio> well, there is a reboot schedulet but for a really long time
[20:46] <cachio> which should not be affecting the testst
[20:46] <om26er> sure
[20:46] <mvo> cachio: if you ssh into the machine, do you get Broadcasting messages as well?
[20:46] <cachio> mvo, no
[20:46] <cachio> I just saw in the logs
[20:46] <cachio> in the vm I didn't see any broadcastig message
[20:54] <zyga> mvo, cachio: sudo snap install systemctl-redirector --beta
[20:54] <cachio> zyga, what's this?
[20:54] <zyga> then touch /var/log/systemctl.fake.log
[20:55] <zyga> then sudo /snap/systemctl-redirector/current/bin/install
[20:55] <zyga> then run all tests
[20:55] <zyga> in the end collect the log file
[20:55] <zyga> this logs all invocations of systemctl
[20:55] <mup> PR snapd#5059 opened: tests: add pending shutdown detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/5059>
[20:55] <zyga> (reboot and all kinds of systemctl commands)
[20:55] <zyga> mvo: ideas for improvement welcome
[20:57] <mvo> zyga: thanks, I also pushed the above pR to break when we detect something that triggered a shutdown
[20:57] <zyga> yeah
[20:57] <zyga> looks good
[20:57] <mvo> zyga: lets attack it from multiple angles
[20:58] <mvo> cachio: iif you cherry pick the change from 5059 into your tree hopefully this also gives you an error when the shutdown is triggered
[20:58] <mvo> cachio: when running -debug maybe it gives us clues
[20:58] <zyga> cachio: if you run tests with this snap installed and with the install script invoked we should collect more info about what is going on
[20:58] <cachio> mvo, zyga, ok
[20:59] <cachio> I'll run it now
[20:59] <mvo> ta
[20:59] <zyga> thanks
[20:59] <mvo> I will soon need to crahs :/
[20:59] <mvo> but I start the tests now to see if I also notice anything
[20:59] <zyga> me too
[20:59] <mvo> and also login the VM to see any wall messages
[20:59] <cachio> with the last kernel seems to be working better
[20:59] <cachio> I didn't see any reboot yet}
[21:02] <zyga> cachio: I refreshed the systemctl-redirector snap to improve the log messages
[21:04] <cachio> ok, I'll start a run in 10 minutes
[21:04] <cachio> zyga, could you reproduce the error?
[21:04] <cachio> with the new kernel snap?
[21:05] <zyga> I didn't run full test run yet
[21:05] <cachio> zyga, I regenerated the image with the new kernel snap and I couldn't reproduce it anymore
[21:06] <cachio> zyga, wait
[21:06] <cachio> I did :)
[21:07] <zyga> did you install and configure my snap on your VM
[21:08] <cachio> zyga, https://paste.ubuntu.com/p/KMR33JvpyG/
[21:08] <cachio> not for this run
[21:08] <cachio> I'll do it for next one
[21:09] <zyga> Apr 16 20:45:41 localhost kernel: [ 3071.152512] modprobe: page allocation failure: order:7, mode:0x2080024
[21:09] <mup> PR #16: Feature/git buildpackage <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/16>
[21:09] <cachio> zyga, because if I install it during execution it is gonna be deleted on reset
[21:09] <cachio> zyga, yes
[21:09] <zyga> on reset?
[21:09] <zyga> ah
[21:09] <zyga> snaps are removed :/
[21:09] <zyga> looks like we ran out of ram
[21:09] <cachio> zyga, I am configuring vms with -m 1500
[21:10] <cachio> zyga so far it was enough
[21:11] <zyga> cachio, mvo: the allocation that failed was for 524288 bytes
[21:11] <zyga> not a lot
[21:11] <zyga> it looks like we ran out of ram, plain and simple
[21:11] <mvo> zyga: I also run with a 1500m VM, interessting
[21:11] <zyga> cachio: which kernel is that?
[21:11] <mvo> I keep it running
[21:13] <zyga> 4.4
[21:13] <cachio> zyga, pc-kernel                         4.4.0-121.145  113   beta
[21:14] <zyga> right, I see
[21:14] <zyga> guys, I need to go to sleep
[21:14] <zyga> cachio: before you EOD write what you know on the forum
[21:14] <cachio> zyga, sure
[21:14] <cachio> zyga, go to bed :)
[21:16] <zyga> Thank you. Good night!
[21:17] <mvo> zyga, cachio I need to crash as well, I will keep the tests running and check in my morning, I run with beta kernel and the shutdown detection patch from the PR above
[21:17]  * mvo waves
[21:37] <kyrofa> nacc, any idea why building git-ubuntu on arm64 would fail unable to find ffi.h? libffi-dev seems to be in stage-packages
[21:38] <kyrofa> Does it need to be a build-package as well?
[21:38] <kyrofa> Not sure how this is setup
[21:43] <nacc> kyrofa: log?
[21:45] <kyrofa> nacc, https://pastebin.ubuntu.com/p/mGjrtbBdfJ/
[21:50] <kyrofa> nacc, note that this worked fine on amd64
[21:51] <nacc> kyrofa: otp, looking now
[21:51] <kyrofa> No problem
[21:54] <nacc> kyrofa: i have no idea :/
[21:54] <nacc> kyrofa: i've never tried to build on arm64
[21:54] <kyrofa> nacc, ah, that's what I was going to ask
[21:54] <kyrofa> Okay, that's not unusual