| mup | PR snapcraft#2080 opened: project_loader: support architectures for CI <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2080> | 00:00 |
|---|---|---|
| mup | Issue snapcraft#1680 closed: Documentation overhaul for scriptlets and setters <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1680> | 02:09 |
| mwhudson | bah the snapcraft autopkgtests failed in bionic | 02:21 |
| mwhudson | snapcraft.internal.errors.StagePackageDownloadError: Failed to fetch stage packages: Error downloading packages for part 'python2': The package 'python-distutils' was not found.. | 02:21 |
| mwhudson | i guess that patch wasn't quite right | 02:21 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| mborzecki | morning | 05:06 |
| zyga | Cześć | 05:15 |
| mborzecki | zyga: hej | 05:17 |
| zyga | https://forum.snapcraft.io/t/unexpected-reboot-during-snapd-tests-execution-on-ubuntu-core-16/5009 | 05:19 |
| mup | PR snapd#5024 closed: systemd: add helper for opening stream file descriptors to the journal <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5024> | 05:21 |
| zyga | There is a new kernel there | 05:21 |
| zyga | And one of the logs looks like OOM | 05:21 |
| mborzecki | zyga: this is with the new kernel? | 05:21 |
| zyga | But others did not | 05:21 |
| zyga | I didn’t check cachio’s post in detail but I assume so | 05:21 |
| zyga | Just woke up :-) | 05:22 |
| mvo | hey zyga and mborzecki | 05:25 |
| mborzecki | mvo: hey there | 05:25 |
| mup | PR snapd#4989 closed: tests: add arch to CI <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4989> | 05:26 |
| mborzecki | mvo: #5059 is something you want to merge or just wanted to run it through the CI? | 05:27 |
| mup | PR #5059: tests: add pending shutdown detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/5059> | 05:27 |
| mvo | mborzecki: both, its fine to keep it open for now I will also want to backport it to 2.32. it hopefully helps us to get clues about the reboot issue that cachio is reporting | 05:29 |
| mborzecki | ok | 05:29 |
| mborzecki | mvo: about the changelog, is this some tool that picks up the commit messages? (git-bp?) | 05:30 |
| mvo | mborzecki: yeah, its a hand written one that is not very good in lp:~mvo/+junk/snappy-dch | 05:33 |
| zyga | good morning | 05:41 |
| zyga | mborzecki: now you know about mvo's secret stash of secrets :) | 05:42 |
| zyga | is there any script that creates an image, prepares it for testing and runs tests against it | 05:46 |
| zyga | I always have to hand-craft things and that feels weak | 05:46 |
| zyga | yesterday I installed elementary to test a collection of snaps there | 05:46 |
| zyga | and I noticed that elementary ships HWE kernels by default | 05:47 |
| mborzecki | zyga: maybe they like running recent-ish kernels? | 05:49 |
| zyga | yeah, just more leaky kernels | 05:49 |
| zyga | but that's fine, the fix will come out soon enough | 05:49 |
| zyga | mvo: do you suspect the error is just OOM again? | 05:49 |
| zyga | after the last log from cachio late last night I think that's just it | 05:50 |
| mvo | zyga: maybe it is that. I just had one run that was completely good and now I got a kernel oops with a _dma_segment_allow failure | 06:02 |
| mvo | zyga: hm, /proc/meminfo looks happy, I don't think its just mem | 06:04 |
| mvo | zyga: I wonder if we should add a more generic check for kernel oopses during the test runs | 06:08 |
| mvo | zyga: just like the oom test | 06:08 |
| zyga | mmm, good idea | 06:10 |
| zyga | so do you think the new kernel is just busted? | 06:10 |
| mvo | zyga: not sure, I refresh to stable now and re-run the tests | 06:12 |
| mvo | zyga: its strange no reboot so far for me | 06:12 |
| zyga | how are you running tests? | 06:12 |
| zyga | spread + external backend + ... | 06:12 |
| mvo | zyga: yeah, tests/external-backends.md | 06:13 |
| mvo | zyga: so 1. build image using ubuntu-image (from the deb in my case) 2. create user on image 3. slavishly follow steps in tests/external-backends.md | 06:13 |
| zyga | graargh | 06:13 |
| zyga | yeah | 06:14 |
| zyga | so handheld test | 06:14 |
| mvo | zyga: I think sergio has better code for this | 06:14 |
| mvo | zyga: I'm just a bit set in my ways (and I almost never do that kind of tests) | 06:14 |
| zyga | casual testing on elementary shows everything is ok with 2.32.5 | 06:20 |
| zyga | om26er: installing sublime-text now, thank you! | 06:31 |
| om26er | great to know | 06:32 |
| mup | PR snapd#5060 opened: tests: detect kernel oops during tests and abort tests in this case <Created by mvo5> <https://github.com/snapcore/snapd/pull/5060> | 06:35 |
| zyga | om26er: is the snap owned by upstream developers? | 06:37 |
| zyga | om26er: I would love if they could se the percentage of snap vs native package userss | 06:37 |
| om26er | zyga: not yet, there is an ongoing discussion with them, will se where that goes | 06:38 |
| om26er | currently its under snapcrafters | 06:39 |
| zyga | ok | 06:39 |
| zyga | it works just great so thank you :) | 06:39 |
| zyga | om26er: is there a chance to put dev builds in edge? | 06:39 |
| om26er | @zyga: that should be possible, I think they have public apis with which we can check the latest dev build version | 06:41 |
| zyga | the dev build is just in a different archive | 06:41 |
| zyga | I don't know how this snap is built but if you can use a different archive for edge vs stable then it should be painless | 06:41 |
| om26er | this has to be done externally though as their project is proprietary and we dont have access to its vcs | 06:41 |
| om26er | zyga: https://github.com/snapcrafters/sublime-text/blob/master/snap/snapcraft.yaml | 06:42 |
| om26er | I am working on a service that notifies us when a new release is available upstream | 06:43 |
| zyga | where is SNAPCRAFT_PROJECT_VERSION coming from | 06:43 |
| zyga | and that's some unusual variable replacement | 06:43 |
| om26er | sublime, android studio and probably others could benefit | 06:43 |
| zyga | not shell compatible (cc sergiusens) | 06:44 |
| zyga | om26er: ack, thank you | 06:44 |
| zyga | ah, I see version is just placed there | 06:44 |
| mup | PR snapd#5061 opened: tests: ensure interfaces-network-bind daemon is really stopped <Created by mvo5> <https://github.com/snapcore/snapd/pull/5061> | 06:58 |
| zyga | mvo: does this mean we remove snaps incorrectly on cleanup | 07:04 |
| zyga | That is, keep processes up and running | 07:04 |
| mvo | zyga: maybe - or maybe my analysis was too shallow | 07:05 |
| mvo | zyga: it was a drive-by while searching for the real bug | 07:06 |
| mvo | zyga: but there is definitely a runaway process that caused the journalctl --sync hangs | 07:06 |
| mup | PR snapd#5062 opened: tests: skip interfaces-content test on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/5062> | 07:07 |
| mvo | zyga: ^- is the reason for the reboot (or one reason, not sure yet, need to keep this running) | 07:07 |
| mvo | zyga: but it all makes sense | 07:07 |
| pedronis | mvo: ah :( | 07:12 |
| mvo | pedronis: no :( more :) because we found the issue and its just test related and the fix is easy | 07:12 |
| zyga | Pho | 07:14 |
| zyga | Oho | 07:14 |
| zyga | But why is that rebooting the system | 07:14 |
| zyga | Is that test special? It just checks content connection | 07:15 |
| pedronis | it's removing state.json | 07:15 |
| mvo | zyga: it purges the state which triggers a download of core and for core core wants to remove | 07:15 |
| mvo | to reboot | 07:16 |
| mvo | sorry | 07:16 |
| zyga | Aha | 07:16 |
| zyga | I didn’t remember that test is doing such things | 07:16 |
| pedronis | mvo: well, on core it shouldn't download core | 07:16 |
| pedronis | but it might trigger a reboot if strange things happen | 07:16 |
| pedronis | or maybe nowadays it download core even on core? | 07:17 |
| mvo | pedronis: indeed you are right, it is not downloading core, it is seeding again it seems | 07:17 |
| pedronis | I'm not sure, given the new prereq code | 07:18 |
| pedronis | it might be even trying to do both | 07:18 |
| mvo | pedronis: the snap change output here indicates its seeding that is happening | 07:18 |
| pedronis | ok | 07:18 |
| mvo | pedronis: and in the content snap I don't see it tries to fetch core | 07:18 |
| pedronis | mvo: there is a small change that it could try to do both tough | 07:21 |
| mvo | pedronis: aha, its interessting. its is not core that triggers the reboot (because we are smart and know that we already have that). it is the kernel seeding | 07:21 |
| mvo | pedronis: interessting, there might be a race here? | 07:22 |
| pedronis | mvo: we start Loop and we start accepting api calls, the first ensure pass will create the tasks for seeding, but is not super clear that an install api couldn't come in before | 07:23 |
| pedronis | rarely | 07:23 |
| * mvo nods | 07:23 | |
| * zyga read the test just now | 07:24 | |
| zyga | (back from the walk) | 07:24 |
| pedronis | mvo: don't think is something to worry about now, but we should think about it some more | 07:25 |
| zyga | I see this test was re-purposed a ltitle | 07:25 |
| zyga | "ensure that prereq installs work even with an empty state" | 07:26 |
| mvo | yes | 07:27 |
| mborzecki | mvo: runaway process, may this be caused by the changes that affected `systemctl stop` and postrm doing exactly that to stop the services? | 07:28 |
| mvo | mborzecki: possible but unlikely unless special syntax is used nothing changes (i.e. you need to set stop-mode in snap.yaml for this to trigger) | 07:28 |
| zyga | mvo: we also leak some other things but probably started by individual tests | 07:29 |
| mvo | mborzecki: also we had the journalctl --sync hangs before but never figured out what triggered it | 07:29 |
| zyga | mvo: most notably dbus-daemon | 07:29 |
| mvo | zyga: good point | 07:29 |
| zyga | there's enough of them to use up all ram on intense testing loops | 07:29 |
| zyga | (I ran into it a few times but I didn't find the responsible test) | 07:29 |
| mvo | zyga, mborzecki hrm, hrm, it looks like we already stop so my PR is probably too simplisitc | 07:29 |
| mvo | zyga: prepare-restore.sh has a couple of checks now, we could add one more for runaway dbus | 07:30 |
| zyga | yes, more whack-a-mole | 07:30 |
| zyga | but yes | 07:30 |
| mvo | zyga: well, yes whack-a-mole but this time each whack also closes the hole for the moles so hopefully instead of always having to whack N holes with this approach on each step its just N-1 holes :) | 07:31 |
| zyga | mvo: we could also check that there are no new processes since test startup | 07:32 |
| zyga | mvo: I mainly oppose ad-hoc solutions to system problems | 07:32 |
| pstolowski | mornings | 07:33 |
| mborzecki | pstolowski: o/ | 07:33 |
| mvo | zyga: +1 | 07:33 |
| mvo | hey pstolowski | 07:33 |
| zyga | hey pawel, good morning | 07:34 |
| mborzecki | maybe we should run the tests through systemd-run | 07:50 |
| mborzecki | but this would probably have to go up to spread, and the benefit is only the processes started inside the test would get cleaned up automatically | 07:52 |
| mup | PR snapd#5058 closed: packaging: fix incorrectly auto-generated changelog entry for 2.32.5 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5058> | 07:52 |
| pedronis | pstolowski: hi, yes, I can look at the interface hooks PR again today | 08:00 |
| pstolowski | pedronis: great, thank you! | 08:00 |
| Chipaca | moin moin | 08:00 |
| pedronis | mvo: does it all means we need a .6 ? | 08:02 |
| zyga | hey chipaca | 08:04 |
| Chipaca | zyga: how many ways can an X app set its icon | 08:07 |
| Chipaca | zyga: :-) | 08:07 |
| zyga | Chipaca: ETOOMANY | 08:07 |
| mborzecki | hm if we're to do .6, #5024 and #5034 would be nice, this would fix the user autostart logging this | 08:07 |
| mup | PR #5024: systemd: add helper for opening stream file descriptors to the journal <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5024> | 08:07 |
| mup | PR #5034: userd: set up journal logging streams for autostarted apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5034> | 08:07 |
| Chipaca | zyga: sorry, your answer was wrong. The right answer is: -1. | 08:07 |
| Chipaca | .6 is happening? | 08:08 |
| Chipaca | i was joking about it yesterday | 08:08 |
| zyga | Chipaca: I think .7 will be it | 08:08 |
| zyga | it's also a lucky number | 08:08 |
| mborzecki | as many as we need ;) | 08:08 |
| Chipaca | what's broken in .5? | 08:11 |
| mvo | Chipaca, zyga what are you guys talking about? .5 is perfect. PERFECT | 08:14 |
| zyga | mvo: it's perfect in vacuum in flat space | 08:14 |
| Chipaca | mvo: <pedronis> mvo: does it all means we need a .6 ? | 08:14 |
| Chipaca | mvo: that's all i know | 08:15 |
| mvo | pedronis: I don't think we need .6, its all in tests so far | 08:15 |
| mvo | Chipaca: ok :) | 08:15 |
| mvo | Chipaca: I though you were pulling my leg | 08:15 |
| mvo | pedronis: also tests that affect only core itself which we don't run via autopkgtest | 08:15 |
| zyga | mborzecki: updated https://github.com/snapcore/snapd/pull/5033 | 08:54 |
| mup | PR #5033: cmd: generalize locking to global, snap and per-user locks <Created by zyga> <https://github.com/snapcore/snapd/pull/5033> | 08:54 |
| mborzecki | zyga: thanks, looking | 08:54 |
| Chipaca | niemeyer: good news and bad news: when using bolt directly, both in rw and ro mode, RSS is ~5MB after the call to debug.FreeOSMemory() | 08:55 |
| Chipaca | so, we're probably being too clever with caching, interfaces, something else, or all of the above | 08:56 |
| Chipaca | I might dig, or I might refactor the whole thing to be less loopy | 08:56 |
| zyga | Chipaca: are you saying something just leaks memory or that we keep something deliberately open for extended period | 09:04 |
| Chipaca | zyga: yes | 09:07 |
| pedronis | Chipaca: are those numbers for the small example? or for snapd? | 09:07 |
| Chipaca | pedronis: it's a small example | 09:08 |
| Chipaca | pedronis: yesterday this same small example with rw was using 14MB | 09:08 |
| Chipaca | pedronis: the difference between that and this is that that one used snapd/store's decodeCatalog, calling advisor's AddSnap, and this one uses bolt directly for that bit | 09:09 |
| Chipaca | it still queries using advisor | 09:09 |
| Chipaca | 14MB that dropped to (IIRC) 12MB after FreeOSMemory; this one uses 8MB before, 5MB after | 09:10 |
| Chipaca | so, we're caching the store, and its http client | 09:10 |
| Chipaca | (today's loads a local json file directly) | 09:11 |
| Chipaca | and we're probably caching other stuff as well, i'd have to dump or sth to know in full | 09:11 |
| Chipaca | and we're using interfaces a lot, which puts pressure on the heap | 09:12 |
| mborzecki | and runtime | 09:12 |
| Chipaca | yeah, i'm just looking at memory, as this is mostly io-bound | 09:12 |
| pedronis | Chipaca: I see, but most of those changes aren't applicable inside snapd itself | 09:12 |
| mborzecki | is there a chance we cache some responsese from the store? | 09:12 |
| Chipaca | pedronis: well, maybe. I'll be adding things back now to see :-) | 09:12 |
| Chipaca | first up, using an http client | 09:13 |
| Chipaca | holy crap | 09:19 |
| Chipaca | changing the os.Open to do a net/http Get went from 5/8/5 rss to 8/13/11 | 09:20 |
| pedronis | Chipaca: this is go 1.6 ? or something else | 09:24 |
| pedronis | slightly curious if newer go uses less or more memory for this | 09:25 |
| Chipaca | checking | 09:25 |
| Chipaca | pedronis: go 1.10: 6/11/9 | 09:26 |
| Chipaca | that's before writing, after writing, after debug.FreeOSMemory | 09:27 |
| mup | PR snapd#5063 opened: tests: run interfaces-boradcom-asic-control early <Created by mvo5> <https://github.com/snapcore/snapd/pull/5063> | 09:42 |
| pedronis | Chipaca: so 1.10 does a bit better | 09:48 |
| Chipaca | ish, yes | 09:49 |
| Chipaca | (1.10 uses more memory in the boring case) | 09:50 |
| Chipaca | (5/4 vs 6/5) | 09:50 |
| Chipaca | but that's the case we don't care about :-) | 09:50 |
| Chipaca | remember when there were revision control systems that used inodes for stuff so you couldn't cp things around? | 09:57 |
| * Chipaca just copied a git tree and was greatful | 09:58 | |
| vidal72[m] | mborzecki: this isn't true anymore since 4.14: https://github.com/snapcore/snapd/blob/master/tests/regression/lp-1618683/task.yaml#L3 , linux,linux-lts and linux-hardened have user_ns enabled but restricted to root by default. They use same patch as debian but I don't see debian mentioned there so probably Arch shouldn't be there also: https://wiki.archlinux.org/index.php/Security#Sandboxing_applications | 10:01 |
| mborzecki | vidal72[m]: thanks, i'll update the test | 10:04 |
| vidal72[m] | mborzecki: also you use vanillia "go" package in test: https://github.com/snapcore/snapd/blob/master/tests/lib/pkgdb.sh#L561 , while "go-pie" is used in package: https://github.com/bboozzoo/aur-snapd/blob/master/PKGBUILD#L15 . Maybe switch to "go-pie" in test as well. Anyway thx for supporting Arch :) | 10:12 |
| mborzecki | vidal72[m]: hah, thanks for noticing ;) | 10:13 |
| Chipaca | mmm, pie | 10:33 |
| mup | PR snapd#5064 opened: tests: smaller fixes for Arch tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5064> | 10:45 |
| * Chipaca -> lunch | 11:24 | |
| === pstolowski is now known as pstolowski|lunch | ||
| Chipaca | is https://forum.snapcraft.io/t/request-automatic-alias-for-ubuntu-make/4958/5 missing something to be treated like an alias request? | 11:46 |
| pedronis | Chipaca: the original request didn't sound like one | 11:47 |
| zyga | Chipaca: I updated #4889 based on Gustavo's feedback | 11:50 |
| mup | PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889> | 11:50 |
| zyga | could you please look at https://github.com/snapcore/snapd/pull/4889/commits/f371bf27d2189c12f9ce5f29b0ed220aaa06101a and give me some quick feedback if that makes sense to you? | 11:50 |
| Chipaca | zyga: how quick exactly :) | 11:51 |
| Chipaca | zyga: e.g. can i do it after lunch | 11:51 |
| zyga | sure, that's fine | 11:51 |
| * Chipaca said lunch but then didn't | 11:51 | |
| Chipaca | k | 11:51 |
| * Chipaca afk | 11:51 | |
| zyga | Ha. I should go too | 11:52 |
| zyga | mvo: how are we looking wrt release | 12:06 |
| zyga | all green, no smoke on the horizon? | 12:06 |
| mborzecki | off to pick up my daughter from school | 12:11 |
| Chipaca | popey: ERROR: ld.so: object '/snap/shattered-pixel-dungeon/5/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsedsp.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. | 12:11 |
| popey | Chipaca: which revision? | 12:11 |
| Chipaca | popey: based on the /5/, 5 | 12:12 |
| popey | lulz | 12:12 |
| Chipaca | :-) | 12:12 |
| Chipaca | popey: it's /snap/shattered-pixel-dungeon/5/lib/libpulsedsp.so | 12:13 |
| popey | wtf, this used to work | 12:13 |
| ogra_ | works fine here | 12:14 |
| Chipaca | ogra_: sound? | 12:14 |
| ogra_ | (16.04, stable chanel) | 12:14 |
| ogra_ | yep | 12:14 |
| ogra_ | i played 1-2h per day since sat.... sound and all works fine | 12:15 |
| Chipaca | 16.04, stable channel (even for core! need to fix that), and no sound | 12:15 |
| Chipaca | and get that error on startup | 12:15 |
| Chipaca | ogra_: unity? | 12:15 |
| Chipaca | bah, it says error, but the game works (just without sound) | 12:15 |
| ogra_ | yes, standard 16.04 | 12:15 |
| Chipaca | oi hold on | 12:16 |
| ogra_ | core also stable | 12:16 |
| Chipaca | other things also don't have sound | 12:16 |
| ogra_ | susie, sitting next to me has it running on her laptop as well ... sounds works there too | 12:16 |
| pedronis | pstolowski|lunch: lgtm, couple of comments, I think jdstrand might want to look a bit at the policy checks changes | 12:18 |
| Chipaca | popey: um | 12:18 |
| Chipaca | popey: sound does work | 12:18 |
| Chipaca | popey: my bad | 12:18 |
| popey | \o/ | 12:18 |
| popey | wot u do? | 12:18 |
| Chipaca | popey: firmware update left me with no sound out of my speakers | 12:18 |
| popey | oof | 12:19 |
| Chipaca | popey: so that's _probably_ not your snap | 12:19 |
| Chipaca | it also no longer detects headphone inserts | 12:19 |
| ogra_ | sounds pretty low-level then | 12:19 |
| Chipaca | double yew tea eff | 12:20 |
| zyga | Chipaca: oops :/ | 12:20 |
| zyga | how did you apply the update? | 12:20 |
| ogra_ | with a funnel ? | 12:20 |
| Chipaca | zyga: machine rebooted, it spent a bunch of time doing 'updating bios' and 'updating the stuff intel uses to hack your machine' and such | 12:21 |
| Chipaca | maybe I need to re-dkms or sth | 12:21 |
| Chipaca | popey: but, that ERROR thing is still there fwiw (because as stated the file is not there but in lib) | 12:22 |
| popey | ok, will take a look after my call | 12:22 |
| Chipaca | good ol' java falling back gracefully and making debugging harder | 12:22 |
| mvo | zyga: all green so far | 12:23 |
| ogra_ | popey, Chipaca https://paste.ubuntu.com/p/MXBYZKhr4w/ ... everything works though ... (joystick interface not connected since i have none on my laptop) | 12:24 |
| ogra_ | looks like it would like "process-control" too | 12:25 |
| popey | most games do | 12:25 |
| popey | they used to crash, but since 2.32 they carry on even though they dont have it | 12:25 |
| mup | PR snapd#5053 closed: release-tools: handle the snapd-x.y.z version <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5053> | 12:34 |
| zyga | thanks mvo | 12:34 |
| mvo | zyga: thank *you* | 12:35 |
| Chipaca | zyga: changes in 4889 sgtm | 12:35 |
| zyga | thansk! | 12:36 |
| cachio | mvo, hey | 12:38 |
| cachio | I ran with -m 2000 and the new kernel and I could not reproduce the reboot error | 12:38 |
| zyga | I wonder if we run with -m 512 | 12:38 |
| cachio | but, it failed in the refresh scenario | 12:39 |
| zyga | ogra_: how much does smallest product you are aware of has? | 12:39 |
| zyga | *memory* | 12:39 |
| zyga | how much memory it has | 12:39 |
| cachio | I am now rexecuting the refresh scenario with the systemctl-redirector snap | 12:39 |
| Chipaca | zyga: I think ondra had a 256MB one somewhere | 12:39 |
| Chipaca | but I'm not sure | 12:39 |
| ogra_ | zyga, we always said our lowest end is the beaglebone ... so typically the low end products are also in that area, 256M ... | 12:39 |
| zyga | thanks guys | 12:40 |
| zyga | while running our test suite is not the same as running a single purpose product | 12:40 |
| zyga | I wonder how we fare in such world | 12:40 |
| === pstolowski|lunch is now known as pstolowski | ||
| mvo | cachio: hey, I think we are good, I added some infrormation to the forum post and did some digging | 12:43 |
| mvo | cachio: some open PRs based on that but with those applied I am at run 4 now and still no issues | 12:44 |
| cachio | mvo, yes, I saw your comments | 12:49 |
| cachio | thanks for adding that info | 12:49 |
| cachio | I am rexecuting the refresh scenario now beacuse it failed | 12:49 |
| cachio | and I added the systemctl-redirector in case it fails again | 12:50 |
| cachio | the regular beta execution is working properly | 12:50 |
| * Chipaca goes to grab a cuppa | 12:58 | |
| ogra_ | zyga, well even in the sigle purpose low-level products customers ask for wifi-ap and network-manager to be preinstalled etc ... | 12:59 |
| jdstrand | oSoMoN: I just saw it (was off yesterday). I'll look into it | 13:05 |
| jdstrand | oSoMoN: where is the snapcraft.yaml for chromium? | 13:09 |
| kenvandine | sergiusens, what's the status of snapcraft being able to build on a bionic base? | 13:13 |
| oSoMoN | jdstrand, https://git.launchpad.net/~chromium-team/chromium-browser/+git/snappy-packaging/tree/snap/snapcraft.yaml | 13:20 |
| jdstrand | ratliff: interesting: https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/8 | 13:21 |
| jdstrand | oSoMoN: thanks | 13:21 |
| ratliff | jdstrand: is that causing all electron apps to fail automated review currently? | 13:23 |
| jdstrand | ratliff: I suspect so | 13:23 |
| jdstrand | chromium is failing because the store has r1021 and not r1022 | 13:24 |
| jdstrand | ratliff (cc roadmr): ^ | 13:24 |
| roadmr | hi :) | 13:25 |
| jdstrand | and cc oSoMoN ^ | 13:25 |
| * roadmr checks | 13:25 | |
| oSoMoN | jdstrand, what's in r1022 ? | 13:25 |
| jdstrand | + don't enforce 'app' snaps that have setuid/setgid overrides since they can't resquash properly without fakeroot or similar | 13:25 |
| roadmr | jdstrand: I never added 1022 to the store :( 1021 was added/enabled last Thursday and the next one I have in the queue is r1025 | 13:26 |
| jdstrand | roadmr: yes, 1022+ is all that is needed | 13:27 |
| jdstrand | roadmr: but it seems the electron-builder is unsquashing then running its own mksquashfs with extra arguments that would affect the resquash. Let's turn the resquash off for now. I will investigate | 13:29 |
| jdstrand | popey: please see https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/8 | 13:29 |
| jdstrand | popey: what is signal using, electron-builder? | 13:29 |
| kalipso | is there a way to gat old versions of snap packets? the update to lxd 3.0 broke all of our containers, we have to revert to 2.0 but someone in our team deleted snap cache. | 13:30 |
| kalipso | s/gat/get | 13:31 |
| jdstrand | stgraber: fyi, ^ | 13:31 |
| jdstrand | oSoMoN: I'm manually approving chromium | 13:32 |
| oSoMoN | jdstrand, thanks! | 13:32 |
| jdstrand | oSoMoN: (it passes with the review-tools snap, which as r1022) | 13:32 |
| jdstrand | has* | 13:32 |
| oSoMoN | yeah, I ran that locally and didn't get any errors, which is why I was puzzled by the store rejection | 13:33 |
| oSoMoN | glad that you sorted this out already | 13:33 |
| jdstrand | the harder one will be what popey is seeing | 13:33 |
| popey | jdstrand: i believe it's electron-builder, yes | 13:33 |
| jdstrand | popey: I need to *know* since I will be filing a bug against the project | 13:34 |
| jdstrand | popey: :) | 13:34 |
| popey | (also, one of our ISVs has sent a mail telling me he is using 2.35 so just hit this problem, because he can't use newer than 2.35 because patchelf breaks it) | 13:34 |
| roadmr | jdstrand: ok, sorry I missed that (5 minutes only!). Turning off resquashfs enforcement now. | 13:35 |
| jdstrand | popey: that ISV needs to work with sergiusens so they aren't stuff forever. they could work around this by unsquashing and calling mksquash with the appropriate args | 13:35 |
| popey | they could, but this is yet another issue they've had in the last 2 weeks. | 13:35 |
| popey | I have offered them turning off patchelf in 2.40 | 13:35 |
| jdstrand | popey: but, see what roadmr just said. this is only temporary until electron-builder issue is worked out | 13:35 |
| popey | I am loathe to give them a bunch of commands to work around this. | 13:35 |
| popey | the ISV isn't using electron-builder (I am though) | 13:36 |
| roadmr | they don't need to :) I've turned off enforcement, popey, so their snaps will work as they did last week before Thursday | 13:36 |
| jdstrand | popey: that doesn't matter. I asked roadmr to turn off resquash inforcement for everything | 13:36 |
| jdstrand | roadmr: but they need to get on 2.40 | 13:36 |
| jdstrand | err | 13:36 |
| roadmr | jdstrand: (I'm quite happy we went the extra centimeter to add the feature flag, super easy to flip this behavior) | 13:36 |
| jdstrand | popey: but they need to get on 2.40 | 13:36 |
| jdstrand | roadmr: yes | 13:37 |
| popey | Sure. But we can't _force_ people to upgrade if our tools are broken | 13:37 |
| popey | Yes, I will speak to sergio :) | 13:37 |
| kalipso | is there a way to build snap packages from source? when yes where do i find them? | 13:37 |
| jdstrand | popey: did they turn off patchelf? | 13:38 |
| jdstrand | popey: and upgrade? if so, they will be fine when we turn this back on | 13:38 |
| popey | I asked them to | 13:39 |
| popey | Not replied yet | 13:39 |
| jdstrand | popey: can you tell me definitively if signal-desktop is using electron-builder? I see that you referenced the snap-template.sh (great!) but if they are using something else, that also needs to be fixed | 13:48 |
| popey | jdstrand: it is using electron builder | 13:49 |
| sergiusens | kenvandine: that's on 2.40 already, 2.41 to take into account some breaking changes that got into bionic; there is no container build support though and if doing classic you need to install core18 manually (as it is not on stable) | 13:52 |
| sergiusens | a build-snaps entry should solve that ;-) | 13:52 |
| pedronis | niemeyer: for reference this is the topic about gadget connections: https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 | 13:52 |
| cachio | mvo, I managed to reproduce the reboot error running the refresh scenario | 13:52 |
| cachio | same log than what we saw yesterday | 13:53 |
| kenvandine | sergiusens, so it'll build confined snaps for core18? | 13:53 |
| cachio | it is stable image using a core snap from beta | 13:53 |
| kenvandine | we want to rebuild our snaps for core18/bionic | 13:53 |
| sergiusens | kenvandine: yes, BjornT_ is using it for maas I believe | 13:54 |
| sergiusens | kenvandine: you need to specify `base: core18` in snapcraft.yaml, also `snap info core18` | 13:55 |
| kenvandine | sergiusens, awesome | 13:55 |
| kenvandine | thx | 13:55 |
| sergiusens | I don't think the snapd team is committing to its stability yet | 13:55 |
| kenvandine | sergiusens, hopefully by release day :) | 13:58 |
| sergiusens | kenvandine: heh, I think it is closer to .1; mvo any timelines? Not rushing, just having timelines makes us all align better ;-) | 13:59 |
| mvo | cachio: the reboot error means it did reboot out of order? | 13:59 |
| cachio | mvo, yes | 13:59 |
| cachio | it is using an old kernel | 13:59 |
| kenvandine | mvo, our how was to have our default snaps built against core18 for release | 14:00 |
| cachio | mvo, I have seem similar issues in the last execution | 14:00 |
| kenvandine | but it is late now... | 14:00 |
| cachio | mvo, I mean, in the previous | 14:00 |
| mvo | sergiusens, kenvandine yeah, .1 is our target for core18 | 14:00 |
| mvo | cachio: could you run it with PR#5059 cherry picked? | 14:00 |
| cachio | mvo, |sure | 14:01 |
| mvo | cachio: this should give us a hint when something triggers a shutdown | 14:01 |
| mvo | cachio: thank you | 14:01 |
| mvo | kenvandine: well, we can make sure to not remove debs at this point | 14:01 |
| mvo | kenvandine: from the core18 | 14:01 |
| kenvandine | mvo, that should be good enough | 14:01 |
| kenvandine | any chance of getting core18 into stable? | 14:01 |
| cachio | mvo, I already applied that change for current execution | 14:02 |
| cachio | mvo, we will see | 14:02 |
| mvo | kenvandine: when do you need it there? | 14:02 |
| mvo | cachio: cool | 14:02 |
| kenvandine | mvo, now'ish :) | 14:02 |
| sergiusens | kenvandine: also, I have not tested the DLC aspects of using a different base than core | 14:03 |
| mvo | kenvandine: is thursday now'ish enough? I would like to poke at it a little bit before moving it to stable | 14:03 |
| kenvandine | mvo, totally! | 14:03 |
| sergiusens | and you do not need core18 on the host unless you are going classic | 14:03 |
| mup | PR snapd#5041 closed: interfaces/apparmor: don't reload unchanged profiles <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5041> | 14:03 |
| mup | PR snapd#5049 closed: interfaces/apparmor: workaround kernel memory leak <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5049> | 14:03 |
| kenvandine | mvo, that would be much appreciated | 14:03 |
| mvo | kenvandine: ok | 14:04 |
| zyga | pedronis: do you think https://github.com/snapcore/snapd/pull/4996 should be merged? | 14:04 |
| mup | PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996> | 14:04 |
| mup | PR snapd#5033 closed: cmd: generalize locking to global, snap and per-user locks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5033> | 14:04 |
| pedronis | zyga: I need to look at it again | 14:04 |
| pedronis | there's also the question of the name and the comment pawel made | 14:05 |
| oSoMoN | jdstrand, thanks for the manual approval of chromium. I requested manual review for the other 3 architectures that were built at the same time, would you mind approving? | 14:05 |
| zyga | cachio: I'm seeing this in my PR: | 14:05 |
| zyga | E: Unable to locate package linux-image-extra-4.15.0-1001-gcp | 14:05 |
| jdstrand | oSoMoN: ok | 14:05 |
| zyga | cachio: do we need another bump? | 14:05 |
| zyga | full log is in https://api.travis-ci.org/v3/job/367633842/log.txt | 14:05 |
| zyga | jdstrand: hey, FYI, I closed the workaround PRs | 14:05 |
| cachio | zyga, the systemctl-redirector it is not logging anymore after a reboot | 14:06 |
| zyga | cachio: oh? that's odd, is the service enabled? | 14:06 |
| zyga | or maybe something kills it for whatever reason | 14:06 |
| mborzecki | wow, the go toolchain in arch appears to be broken after all | 14:06 |
| niemeyer | cprov: ping | 14:07 |
| cachio | bin-systemctl.mount loaded failed failed Replace real systemctl with systemctl.fake | 14:07 |
| cachio | zyga, I see that | 14:07 |
| zyga | what's the status of the unit? | 14:08 |
| cachio | zyga, I don't see it | 14:10 |
| cachio | it is not listed | 14:10 |
| zyga | cachio: and systemctl status bin-systemctl.mount | 14:10 |
| cachio | zyga, https://paste.ubuntu.com/p/9xm6GWNpPJ/ | 14:11 |
| zyga | can you start it now? | 14:11 |
| zyga | maybe it runs at the wrong time | 14:11 |
| zyga | sicne it uses "current" | 14:11 |
| zyga | and not the real revision | 14:11 |
| zyga | so it doesn't get automatic dependency chaining | 14:11 |
| zyga | that's proably it | 14:11 |
| jdstrand | zyga: I see that. thanks! I haven't read all email yet but see that a fix for the memleak was found (yay!) | 14:15 |
| cachio | zyga, I already started it | 14:20 |
| cachio | and it is working again | 14:20 |
| cachio | Let's see if it give us more info about the current run | 14:20 |
| cachio | zyga, thanks for the help | 14:20 |
| ondra | Chipaca for small memory devices, ogra is best person to ask | 14:28 |
| Chipaca | niemeyer: https://pastebin.ubuntu.com/p/qhjrwh9N8n/ | 14:46 |
| Chipaca | niemeyer: rss grows with number of concurrent bolts | 14:46 |
| Chipaca | niemeyer: btw wrt 'acq', that is how much Go's gotten (dynamically) from the operating system | 14:50 |
| niemeyer | Chipaca: "write N" means N concurrent bolts? | 14:56 |
| Chipaca | niemeyer: open for writing, yes | 14:56 |
| niemeyer | Chipaca: Okay, that's pretty reasonable then | 14:56 |
| SuperJonotron | is there an equivalent to dmidecode for core to access bios information? | 14:57 |
| SuperJonotron | need to use some hardware parameters to determine installation flags for a program | 14:57 |
| Chipaca | SuperJonotron: you'd need to ship dmidecode in a snap | 14:57 |
| niemeyer | Chipaca: Some level of memory increase is to be expected.. just cannot be close to N x <first one>. | 14:57 |
| SuperJonotron | chipaca: i had a feeling that was going to be the answer. no other alternative for bios access in core? | 14:58 |
| Chipaca | SuperJonotron: no, but also mu | 15:00 |
| Chipaca | SuperJonotron: as in, I don't understand exactly what you're trying to do but it sure feels like you're doing something unexpected | 15:00 |
| Chipaca | SuperJonotron: what is trying to determine installation flags for what program? | 15:01 |
| SuperJonotron | Chipaca: software i'm installing utilizes the docker via the docker snap and is designed to run on specific hardware platforms which can be detected by bios settings since each platform will require slightly different runtime flags required by docker | 15:01 |
| SuperJonotron | Chipaca: I can get around this by making the user select the correct device, was hoping to simplify that process | 15:02 |
| Chipaca | SuperJonotron: so the software you're installing is inside docker, that's inside a snap, and the software on the inside needs to know the hardware the snap is running on? | 15:03 |
| SuperJonotron | Chipaca: yes, which it does because dmidecode is a part of that docker container but the installer runs outside of all that which doesn't have dmidecode | 15:03 |
| Chipaca | SuperJonotron: why not ship dmidecode yourself? | 15:03 |
| Chipaca | i assume this 'installer' is a snap, but i don't know | 15:04 |
| SuperJonotron | Chipaca: it is not, it is just some bash scripts that collect all the data necessary to put the docker image in the snap with all appropriate flags for the hardware | 15:04 |
| Chipaca | SuperJonotron: actually, i was wrong | 15:04 |
| Chipaca | SuperJonotron: we do ship dmidecode in core | 15:04 |
| * Chipaca looks | 15:05 | |
| Chipaca | augh | 15:05 |
| Chipaca | SuperJonotron: scratch that again, i was wrong | 15:05 |
| Chipaca | SuperJonotron: accidentally looked in the wrong snap | 15:05 |
| SuperJonotron | possibly stripped out in the UC16 image for Dell Gateways or is it it's own snap I need to download? | 15:06 |
| Chipaca | SuperJonotron: no, i was just wrong | 15:06 |
| Chipaca | SuperJonotron: but, if you're creating a snap for the installer, you can drop dmidecode in there and it should work (given the appropriate permissions) | 15:06 |
| SuperJonotron | I might go that route in the future but for now i'll just make the installer be a manual hardware selection process | 15:07 |
| SuperJonotron | Chipaca: thanks for confirming | 15:07 |
| cprov | niemeyer pong | 15:22 |
| zyga | SuperJonotron: you don’t need dmidecode, there are sysfs entries for everything | 15:22 |
| niemeyer | cprov: Heya, having lunch now.. do you have time for us to go over the chart this afternoon, after your lunch? | 15:25 |
| joc | sergiusens: could you take a quick look at this error, I feel like something changed in snapcraft to cause it, any ideas?: https://pastebin.canonical.com/p/7qWNQvNrd6/ | 15:25 |
| SuperJonotron | zyga: sysfs: command not found | 15:26 |
| cprov | niemeyer: yes, absolutely, finishing lunch too. | 15:26 |
| zyga | SuperJonotron: one sec :-) | 15:27 |
| zyga | SuperJonotron: so | 15:29 |
| zyga | it's not a command | 15:29 |
| zyga | SuperJonotron: cd /sys/class/dmi/id | 15:29 |
| zyga | SuperJonotron: ls -l | 15:29 |
| zyga | and look around | 15:29 |
| SuperJonotron | zyga: perfect, exactly the type of data i was after, thanks | 15:31 |
| cachio | mvo, https://paste.ubuntu.com/p/Q6nJm7nqXs/ | 15:36 |
| cachio | I see this | 15:37 |
| zyga | 2 Doing 2018-04-17T15:30:38Z - Initialize system state | 15:37 |
| zyga | is this what I think this is | 15:37 |
| zyga | are we re-initializing system state in each test? | 15:38 |
| cachio | well, perhaps it was the state when it was saves preparing the project | 15:39 |
| zyga | SuperJonotron: there are no interfaces that expoese all of dmi information | 15:39 |
| pedronis | zyga: that's seeding, if we start with an empty state we would | 15:39 |
| zyga | SuperJonotron: but if you hvae a use-case let us know and we can add one | 15:39 |
| pstolowski | Son_Goku: hey Neal! quick question, do you know if %{gofindfilter} macro is a new addition? I'm having failures trying to use it | 15:39 |
| cachio | zyga, https://paste.ubuntu.com/p/Yv5MCy8gnm/ | 15:39 |
| cachio | this is the log from the snap | 15:39 |
| zyga | pedronis: yes, the question is if we start with an empty state in each test | 15:40 |
| zyga | I hope not | 15:40 |
| cachio | shutdown +10 -r reboot | 15:40 |
| pedronis | well that test does | 15:40 |
| zyga | pstolowski: hey, are you using mock? | 15:40 |
| pedronis | it does rm state.json | 15:40 |
| pedronis | so that's expected there | 15:40 |
| zyga | cachio: I see the systemctl-redirector snap is useful :) | 15:40 |
| pedronis | on classic | 15:40 |
| cachio | zyga, yes | 15:40 |
| cachio | zyga, thanks for this :) | 15:41 |
| zyga | I'm surprised how many things it shows at once | 15:41 |
| zyga | that systemd relays all of the things through that command | 15:41 |
| zyga | I will fix the reboot issue if I can, so that it's always on | 15:41 |
| pstolowski | zyga: mock? | 15:41 |
| zyga | pstolowski: yes, mock | 15:41 |
| zyga | pstolowski: are you familiar with it? | 15:41 |
| pstolowski | zyga: no | 15:41 |
| zyga | pstolowski: install it, it's your best friend | 15:41 |
| zyga | it's very useful | 15:41 |
| SuperJonotron | zyga: no use case yet, nothing dmidecode provides was necessary except for some of the things already available in that directory | 15:41 |
| zyga | SuperJonotron: sure, just let us know if you get into confinement issues | 15:42 |
| zyga | SuperJonotron: normally you will not be able to read those files from a snap | 15:42 |
| SuperJonotron | zyga: luckily for this instance, I need to read it from outside of a snap before interracting with one so it works perfectly for my use case | 15:43 |
| cachio | zyga, the shutdown is called when the test tests/main/interfaces-content is executed | 15:43 |
| pstolowski | zyga: looks useful indeed, thanks (although I don't think it's going to help we my current issue) | 15:43 |
| zyga | pstolowski: it may | 15:43 |
| zyga | the macro can be easily checked for by running mock against rawhide | 15:43 |
| zyga | pstolowski: also mock helps you find missing dependencies | 15:44 |
| zyga | pstolowski: let me know if you need help using it, I love mock | 15:44 |
| pstolowski | zyga: ah, I see, nice, so it can spin a completely different FC environment | 15:46 |
| zyga | yes | 15:46 |
| zyga | just build your spec to srpm with mock | 15:46 |
| zyga | tell it to use given release (e.g. f28) | 15:46 |
| zyga | or f29 | 15:46 |
| zyga | then use mock again to build what you want | 15:46 |
| zyga | mock caches everything so things are pretty fast after once run | 15:46 |
| zyga | *one run | 15:46 |
| cachio | zyga, mvo in this case the problem seems to be that it is starting the core snap 1441 | 15:51 |
| cachio | it is the one which comes by default | 15:51 |
| cachio | I think the problem is that we are keeping both core snaps in the state and we should remove the old one in the reset | 15:52 |
| cachio | zyga, mvo https://paste.ubuntu.com/p/G9mGjg2Ck2/ | 15:54 |
| cachio | current should be 4486 | 15:54 |
| cachio | some test is making a mess | 15:54 |
| cachio | in this case the error seems to be a testing problem | 15:54 |
| cachio | it is not the same we saw yesterday | 15:55 |
| pedronis | cachio: this is classic right? | 15:55 |
| Chipaca | niemeyer: so, given https://gist.github.com/chipaca/b1861183bbcda2f2d4e14ab3f74e60b2 | 15:55 |
| cachio | pedronis, ubuntu-core-16-64 | 15:55 |
| pedronis | cachio: mvo has a branch to disable the test there | 15:55 |
| Chipaca | niemeyer: hammering that servier with 100 concurrent requests until 1M requests are served, not one request is lost | 15:56 |
| cachio | pedronis, which tests? | 15:56 |
| Chipaca | at least so far :-) | 15:56 |
| pedronis | cachio: interface-content | 15:56 |
| cachio | ahh | 15:56 |
| cachio | ok | 15:56 |
| pedronis | cachio: https://github.com/snapcore/snapd/pull/5062 | 15:56 |
| mup | PR #5062: tests: skip interfaces-content test on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/5062> | 15:56 |
| pedronis | I think it said that in the standup and in the topic | 15:56 |
| pedronis | s/it/he/ | 15:56 |
| cachio | pedronis, ahh, ok, I missed that | 15:57 |
| Chipaca | niemeyer: that's the good news | 15:57 |
| cachio | thanks | 15:57 |
| Chipaca | niemeyer: the bad news is that http.Server.Shutdown is 1.8+ | 15:57 |
| mup | PR snapd#5062 closed: tests: skip interfaces-content test on core devices <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5062> | 15:59 |
| pedronis | Chipaca: I have ported Shutdown already to our daemon by hand | 16:00 |
| Chipaca | pedronis: :-D | 16:00 |
| zyga | can we depend on golang 1.10 somehow | 16:00 |
| pedronis | at least something close enough | 16:00 |
| Chipaca | pedronis: sssh i was trying to bring us kicking and screaming to 1.10 :-) | 16:00 |
| pedronis | Chipaca: anyway please do look at daemon | 16:01 |
| zyga | at least we could build with 1.10 in core snap | 16:01 |
| Chipaca | pedronis: I was kidding, if we've alreay got it even better | 16:01 |
| Chipaca | pedronis: there was a 'graceful' package for 1.6 but i was hoping to avoid it | 16:02 |
| Chipaca | pedronis: so this is perfect | 16:02 |
| Chipaca | all we need to do is just go away | 16:02 |
| Chipaca | and, not restart more than 5 times in any 10 seconds | 16:02 |
| Chipaca | :-) | 16:02 |
| Chipaca | (or set StartLimitBurst=0 which is easily the most ill-documented bit of service files) | 16:03 |
| Chipaca | also love that you can do StartLimitAction=reboot -> if apache is flapping, just reboot the server | 16:04 |
| pedronis | Chipaca: sorry, what I meant, it would be good to check if my port of Shutdown works well enough | 16:05 |
| Chipaca | pedronis: ah | 16:05 |
| pedronis | it's writte as small wrapper, so it shouldn't be too hard | 16:06 |
| * cachio lunch | 16:10 | |
| Chipaca | pedronis: so finishShutdown() is Shutdown()? | 16:11 |
| pedronis | yes | 16:12 |
| sergiusens | joc: that works with 2.35 and fails with this? | 16:12 |
| pedronis | Chipaca: where do you close the listener? | 16:13 |
| pedronis | Chipaca: ah, that's diffferent 1.8 closes listeners for you, in my case it's manual | 16:15 |
| pedronis | Chipaca: Shutdown = close listener + finishShutdown | 16:15 |
| pedronis | if I'm making sense | 16:16 |
| Chipaca | pedronis: it still seems to work though | 16:18 |
| niemeyer | Chipaca: I think we can control the shutdown as we already have some view over the connections going in, IIRC | 16:20 |
| Chipaca | niemeyer: pedronis pointed out we can already shutdown as he backported it | 16:21 |
| Chipaca | niemeyer: dameon.Daemon uses a daemon.shutdownServer :-) | 16:22 |
| niemeyer | Chipaca: Cool.. so the question is whether there's something to tweak on the example | 16:23 |
| niemeyer | Chipaca: It'd be worth adding some random sleeps, both inside the handler and outside after shutdown, and increasing the number of requests it's handling | 16:26 |
| niemeyer | Chipaca: As it is right now it at least looks like an extremely performant application handling one request and exiting quickly | 16:26 |
| Chipaca | niemeyer: it handles anything between 30 and 100 before exiting | 16:27 |
| Chipaca | pedronis: and if I don't close the listener, up to about ~300 :-) | 16:28 |
| niemeyer | Chipaca: Can we have the sleeps, delaying from 1~3 seconds, and something like ~5 before exiting? | 16:29 |
| niemeyer | (after shutdown, before exiting) | 16:30 |
| Chipaca | niemeyer: you mean, starting the shutdown after handling ~5? | 16:30 |
| niemeyer | Chipaca: I mean sleeping for 5 seconds after Shutdown | 16:30 |
| Chipaca | niemeyer: fwiw i also tested with starting the shutdown at ~100, already, with 100ms sleeps | 16:30 |
| Chipaca | ok... | 16:31 |
| niemeyer | Chipaca: IOW, testing the behavior of those connections coming in as we terminate the previous process | 16:31 |
| Chipaca | niemeyer: 1-3 seconds sleep in the request handler, and the 5s after shutdown and before exiting | 16:31 |
| niemeyer | Chipaca: To make sure systemd is in fact taking the same old socket and handing these connections that were made to the old process into the new one | 16:32 |
| niemeyer | Chipaca: Then we just need to ensure the client testing it is properly reporting unexpected EOFs.. | 16:32 |
| niemeyer | Chipaca: If all of that work, then let's go out and have a beer :P | 16:32 |
| Chipaca | yes, i'd errors on stderr if it EOF'ed | 16:34 |
| niemeyer | Chipaca: Worth sending some data as well, perhaps.. to make sure everything is being handled correctly, instead of just taking the connection and closing it. | 16:36 |
| Chipaca | 36 /36 26898 1 | 16:36 |
| Chipaca | 37 /37 27168 3 | 16:36 |
| mvo | cachio: https://paste.ubuntu.com/p/Q6nJm7nqXs/ <- this one if fixed with 5062 | 16:36 |
| Chipaca | ^ request #36 handled by pid 26898, request #37 handled by a different pid (5s later) (out of order) | 16:36 |
| mup | PR #36: Refactored the test scripts and split the travis runs <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapd/pull/36> | 16:36 |
| niemeyer | Chipaca: E.g. send N integers on one end, on exit of both ends ensure no gaps and what the max was. | 16:36 |
| Chipaca | niemeyer: client is sending request number, server is echoing it back | 16:37 |
| niemeyer | Chipaca: Ah, perfect | 16:37 |
| niemeyer | Chipaca: Then I assume it's checking later that no gaps/correct max? | 16:37 |
| Chipaca | I'm doing that with shell stuff, yes | 16:38 |
| Chipaca | correct max i'm just eyeballing :-) | 16:38 |
| Chipaca | 'does it end on 9999' | 16:38 |
| niemeyer | +1 | 16:39 |
| niemeyer | Just plain diff on sorted outputs should do I guess | 16:39 |
| niemeyer | Chipaca: Well, that's looking very promising.. in that case maybe we can simply look at the Ensure timer, and if there are no snaps we can shutdown | 16:41 |
| niemeyer | Chipaca: Hmm.. | 16:41 |
| niemeyer | Chipaca: There's something curious here, though.. we did have to make our own client reconnect on errors.. remember that? | 16:41 |
| Chipaca | the last test you requested is still running (no failures yet) | 16:42 |
| niemeyer | Why was it breaking, assuming all of this was already in place back then | 16:42 |
| pedronis | I think the retry code is older than my shutdown backport | 16:42 |
| pedronis | fwiw | 16:42 |
| pedronis | before my changes there our shutdown was a bit violent | 16:43 |
| niemeyer | pedronis: Aha, interesting | 16:43 |
| Chipaca | i think the client timeout is also fairly aggressive, but i'm not sure offhand | 16:44 |
| * zyga -> grocieries | 16:45 | |
| niemeyer | Very promising either way | 16:45 |
| Chipaca | niemeyer: test finished, success | 17:04 |
| niemeyer | Chipaca: \o/ | 17:04 |
| Chipaca | and, soft eod from me | 17:04 |
| niemeyer | Chipaca: Thanks for those tests | 17:04 |
| Chipaca | np | 17:04 |
| Chipaca | now we need a good way of answering 'can we shutdown' that won't have us racing with ourselves | 17:05 |
| Chipaca | e.g. a way to accept a change but not run it, so that we can 202 things that are already in the pipeline after we closed the listener | 17:06 |
| Chipaca | (reminder that daemon does EnsureBefore(0) in a bunch of places) | 17:07 |
| mup | PR snapcraft#2081 opened: elf: patch everything instead of a subset of elf files <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2081> | 17:13 |
| om26er | Is it possible to snap a python utility *without* shipping python with it ? Something that links to python installation in the core snap. | 17:18 |
| ogra_ | i think (probably that changed) your snap can see the actual python interpreter from core | 17:25 |
| ogra_ | but snapcraft will try to re-write the hashbang line in your script | 17:25 |
| ogra_ | (to point to a shipped one) | 17:25 |
| zyga | om26er: technically yes | 17:26 |
| zyga | om26er: just do it manually :) | 17:26 |
| ogra_ | so if you dont need any modules and use i.e. the nil plugin in snapcraft, just shipping a self-contained python script should be possible | 17:26 |
| om26er | ogra_: zyga its a python package that I want to snap, it has setup.py etc, just instead of shipping a new copy of python want it to use one from core | 17:27 |
| om26er | is there an example project that does that ? | 17:28 |
| * ogra_ doubts that ... | 17:28 | |
| zyga | I don't know sadly, perhaps there is something on the python plugin that can be done | 17:28 |
| zyga | I honestly don't know | 17:28 |
| ogra_ | as soon as you use any of the python plugins in snapcraft it will try to re-write the interpreter line though | 17:28 |
| kyrofa | niemeyer, have you had a chance to look at https://github.com/snapcore/spread/pull/39 ? | 17:52 |
| mup | PR spread#39: Fix sshd_config sed expression (Issue #38) <Created by Saviq> <https://github.com/snapcore/spread/pull/39> | 17:52 |
| Pharaoh_Atem | ? | 18:00 |
| niemeyer | kyrofa: Not yet, sorry about that, but hope to integrate it today still | 18:00 |
| kyrofa | niemeyer, alright, thank you | 18:01 |
| Chipaca | om26er: can we talk about why you're wanting so badly to take over packaging of httpie? | 18:37 |
| om26er | @Chipaca: heh, nothing specific but I am trying to pursue upstream to support it officially, so thought the first step would be to get that under snapcrafters. | 18:54 |
| om26er | anyways, If there is a positive response from upstream this time, we can definitely get that alias transferred to them. | 18:55 |
| Chipaca | om26er: https://github.com/jakubroztocil/httpie/pull/561/files | 18:55 |
| mup | PR jakubroztocil/httpie#561: Add the packaging metadata to build the httpie snap <Created by elopio> <https://github.com/jakubroztocil/httpie/pull/561> | 18:55 |
| Chipaca | om26er: I also had made them aware of my packaging efforts, which predate snapcraft | 18:56 |
| om26er | Chipaca: I was pointed to that a few minutes ago here https://github.com/jakubroztocil/httpie/issues/672 | 18:56 |
| Chipaca | so, I mean, I snapped httpie ages ago, and have kept it updated | 18:57 |
| om26er | Chipaca: alright, lets see if they show interest this time. (will bug you if needed) | 18:58 |
| Chipaca | I reached out to upstream then (they showed little to no interest) | 18:58 |
| om26er | thanks, its a very useful tool. | 18:58 |
| Chipaca | I looked into moving to snapcraft, and it's too much work (if it's possible at all) | 18:59 |
| Chipaca | so, do as you will | 18:59 |
| Chipaca | om26er: but know that you're coming across as reasonably hostile or aggressive with this | 19:01 |
| Chipaca | _un_reasonably | 19:01 |
| om26er | Chipaca: no such intentions really, maybe wrong choice of words on my side. | 19:02 |
| * om26er revisits the email text. | 19:04 | |
| Chipaca | om26er: you: "hey we want to be co-maintainers" me: "no because a b c" you: "but x y z"×3 also you: "hey upstream take my patch" | 19:04 |
| Chipaca | it's not the words, it's the actions | 19:04 |
| mup | PR snapcraft#1966 closed: grammar: support `to` statement in source <do-not-merge-yet> <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1966> | 19:05 |
| om26er | I searched for 'snap' in their GH issues, nothing came up, so opened a new issue with a paste of very rough snapcraft.yaml that I did to verify if httpie was doing any system calls that would otherwise be deemed security-sensitive, found out that was not the case. Only just found in your email that you also ship unix socket extension of it. | 19:12 |
| om26er | Chipaca: applogies if the email felt agressive, though I had no reason to be agressive to start with ;-) | 19:13 |
| mup | Issue snapcraft#1685 closed: Implement support for architecture in snapcraft.yaml <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1685> | 19:47 |
| mup | PR snapcraft#2080 closed: project_loader: support architectures for CI <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2080> | 19:47 |
| popey | om26er: "so thought the first step would be to get that under snapcrafters." (no). First step is a pull request upstream IMO | 21:13 |
| popey | if you have a pull request and they say yes, all is good. If they say "no" then -> snapcrafters perhaps | 21:13 |
| om26er | popey: ok, in this case Leo has a pull request already. | 21:13 |
| popey | awesome | 21:14 |
| mwhudson | um um | 21:20 |
| mwhudson | snapcraft in bionic needs to depend on python3-distutils... | 21:20 |
| popey | kyrofa: ^ | 21:21 |
| mwhudson | maybe there should be a autopkgtest that actually invokes the binary :) | 21:21 |
| mwhudson | kyrofa: https://paste.ubuntu.com/p/wD3gmWVd3P/ | 21:21 |
| mwhudson | maybe i should just upload the fix myself... | 21:23 |
| kyrofa | mwhudson, ah, good catch, thank you | 21:24 |
| mup | PR snapcraft#2082 opened: Ignore me, throwing to CI <do-not-merge-yet> <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2082> | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!