| === epod is now known as luk3yx | ||
| zyga | hello | 05:49 |
|---|---|---|
| mborzecki | morning | 05:55 |
| zyga | mborzecki: hey :) | 05:56 |
| zyga | mborzecki: making breakfast, how are you? | 05:56 |
| mborzecki | zyga: hey | 05:56 |
| mborzecki | zyga: how's your back? | 05:56 |
| zyga | mborzecki: better, not sure what happened yesterday, wasn't my typical thing | 05:57 |
| mborzecki | zyga: glad that it's better | 05:58 |
| mborzecki | heh, so debian sid has some really new version of go, and tests/unit/go bails out do to gofmt changes :0 | 06:14 |
| zyga | mborzecki: yeah, I noticed :| | 06:21 |
| zyga | we should disable those or figure out if we can pin the format | 06:22 |
| zyga | mborzecki: I solved the unit test issues that happen when building in sbuild | 06:22 |
| zyga | let me push a patch against master | 06:22 |
| mborzecki | seccomp? | 06:22 |
| zyga | no, that is still off | 06:23 |
| zyga | but I will investigate that next | 06:23 |
| zyga | I need to compile a few programs on sid toolchain and buster toolchain | 06:23 |
| mborzecki | it'd be nice to run the unit tests on sid | 06:28 |
| zyga | yeah, that's still somewhat away | 06:28 |
| mborzecki | we'll probably need to add an off switch for gofmt in run-checks | 06:28 |
| zyga | the key difference was not sid | 06:28 |
| zyga | just sbuild | 06:28 |
| mborzecki | i meant #6406, it's failing due to gofmt from go 1.11 which uses a different indent length when aligning struct field values & comments | 06:29 |
| mup | PR #6406: tests: enable debian sid as part of the main suite on travis <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6406> | 06:29 |
| mup | PR snapd#6409 opened: interfaces/apparmor: mock presence of overlayfs root <Created by zyga> <https://github.com/snapcore/snapd/pull/6409> | 06:32 |
| zyga | mborzecki: I have more patches but those are of the simple kind that disable stuff | 06:33 |
| zyga | mborzecki: the key thing I achieved yesterday, was to build a process where it is easy and fast to iterate on this | 06:34 |
| === cpaelzer__ is now known as cpaelzer | ||
| zyga | afk | 06:56 |
| === phoenix_firebrd is now known as murthy | ||
| zyga | back now | 07:22 |
| zyga | mvo: hello :) | 07:22 |
| zyga | mvo: how are you doing after the game last night? | 07:22 |
| mvo | zyga: hey, still feel a bit battered but ready for work | 07:23 |
| === murthy is now known as phoenix_firebrd_ | ||
| === phoenix_firebrd_ is now known as murthy | ||
| zyga | mvo: I pushed one PR already | 07:27 |
| zyga | it contains the fixes for unit tests that are applicable to master | 07:27 |
| zyga | mvo: I also, just now, opened another pull request | 07:27 |
| zyga | that adds a program to release-tools | 07:28 |
| mup | PR snapd#6410 opened: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410> | 07:28 |
| zyga | to improve the process on working on debian packaging | 07:28 |
| zyga | right now the package builds but needs review (it's non-trivial) and it needs more love to fix lintian isues | 07:28 |
| zyga | adt tests also fail but I didn't investigate any more than that | 07:28 |
| zyga | please have a look at 6410 as a starting point if that's okay | 07:28 |
| mvo | zyga: sure | 07:30 |
| mvo | zyga: thanks! | 07:30 |
| zyga | mvo: you can reproduce my progress with that PR (just grab the script, it's not tied to the rest of the tree) and the "debian" branch from https://salsa.debian.org/zyga-guest/snapd | 07:30 |
| mvo | zyga: ok | 07:31 |
| mvo | zyga: if the package builds and works and lintian is not worse than before, can we push it to the archive? or is anything else missing? | 07:32 |
| zyga | mvo: it has one E so I think at least that must be fixed | 07:32 |
| zyga | mvo: I suspect I did something silly in my meld-based-merge | 07:32 |
| zyga | and we can get rid of most of W-s easily | 07:33 |
| zyga | mvo: my smoke test would be to install the package and run a few snaps quickly | 07:33 |
| mborzecki | #6409 needs a 2nd review and can land | 07:33 |
| mup | PR #6409: interfaces/apparmor: mock presence of overlayfs root <Created by zyga> <https://github.com/snapcore/snapd/pull/6409> | 07:33 |
| mborzecki | mvo: morning | 07:33 |
| mvo | mborzecki: good morning | 07:33 |
| mvo | zyga: yeah, that sounds sensible | 07:34 |
| mvo | mborzecki: did a second review on 6409 - just one tiny question | 07:34 |
| mborzecki | mvo: https://github.com/snapcore/snapd/pull/6405 has a suggestion from Chipaca that can be applied via github | 07:37 |
| zyga | mvo: replied | 07:38 |
| mup | PR #6405: run-checks: ensure we use go-1.10 if available <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6405> | 07:38 |
| mup | PR snapd#6402 closed: spread: increase default kill-timeout to 30min <Simple 😃> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6402> | 07:39 |
| mup | PR snapd#6409 closed: interfaces/apparmor: mock presence of overlayfs root <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6409> | 07:39 |
| mvo | zyga: thanks, also cherry-picked it now | 07:39 |
| zyga | thank you! | 07:39 |
| mvo | zyga: thank *you* :) | 07:40 |
| mvo | zyga: one thing less to worry about | 07:40 |
| zyga | mvo: yeah | 07:40 |
| zyga | mvo: after getting to the point where I can run interactive shell inside sbuild inside debian 10 vm | 07:40 |
| zyga | mvo: and finding my way around the odd way dh-golang arranges the source code | 07:41 |
| zyga | it was okay | 07:41 |
| zyga | mvo: all of the patches I remade/added are in https://salsa.debian.org/zyga-guest/snapd/commits/debian-patches | 07:41 |
| zyga | mvo: I will look at seccomp now, could you look at lintian please? | 07:42 |
| zyga | and just see if what I made makes any sense | 07:42 |
| murthy | Olivier Tilloy thanks for making chromium with vaapi working snap. | 07:52 |
| mvo | zyga: yeah, could you please pastebin the errors again? | 07:53 |
| mvo | zyga: or point me to it? | 07:53 |
| mvo | zyga: I have lintian and your tree etc, looking at this now | 08:39 |
| mvo | zyga: please apply http://paste.ubuntu.com/p/YkfDs69XSq/ (I can do a formal pull rquest if you prefer) | 08:42 |
| mvo | zyga: test building that now | 08:42 |
| zyga | mvo: re, sorry, had some things happening at home | 08:54 |
| zyga | mvo: applying | 08:54 |
| mvo | zyga: ta - also your changelog needs one extra space after me@zygoon.pl> and before Thu, | 09:00 |
| mvo | zyga: there must be two spaces there or lintian is unhappy | 09:01 |
| mvo | zyga: I look at the ones produced by the binary build now | 09:01 |
| mvo | zyga: fwiw, the way this can be driven via gbp: http://paste.ubuntu.com/p/YYqSsxV2g6/ | 09:02 |
| mvo | zyga: this builds fine in sbuild under bionic fwiw | 09:03 |
| mvo | zyga: (i.e. no unit test or other issues) | 09:03 |
| Chipaca | mooing | 09:04 |
| ogra | meow | 09:06 |
| mvo | zyga: the other warning that is easy to fix is that snap-discard-ns.8 has "section: 5" in the .rst file, trivial to fix | 09:08 |
| zyga | ah | 09:08 |
| zyga | I see | 09:08 |
| mvo | zyga: there are some more warnings that we should probably just lintian override | 09:08 |
| mvo | zyga: but I think they are ok for now | 09:08 |
| ackk | hi, given a .snap file, is it possible to know which arch is it built for? "snap info" doesn't provide that info AFAICT | 09:30 |
| zyga | ackk: you can look at meta/snap.yaml, at the architecture field | 09:34 |
| zyga | but there's nothing quick and easy I'm afraiid | 09:34 |
| zyga | *afraid | 09:34 |
| ackk | zyga, I ses, so I guess I have to mount the snap filesystem for that | 09:36 |
| zyga | or extract that file | 09:36 |
| ackk | zyga, ok, thanks | 09:37 |
| ackk | zyga, maybe it could be an improvement of "snap info" ? :) | 09:37 |
| zyga | ackk: do we show that with snap info --verbose? | 09:39 |
| zyga | or -v | 09:39 |
| ackk | zyga, no | 09:43 |
| mvo | zyga: yeah, that sounds like a bug | 09:45 |
| mvo | ackk: ups, sorry, I mean that sounds like a missing feature | 09:45 |
| mvo | ackk: you can look at the filename | 09:45 |
| mvo | ackk: but its *very* crude | 09:45 |
| Chipaca | pedronis: you around? | 09:46 |
| mvo | Chipaca: he is off today | 09:49 |
| Chipaca | ah i thought that was yesterday | 09:49 |
| Chipaca | mvo: zyga: let's add architecture to the info backlog :-) | 09:51 |
| mvo | Chipaca: +1 | 09:53 |
| mup | PR snapd#6407 closed: tests: get test-snapd-dbus-{provider,consumer} from the beta channel <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6407> | 10:02 |
| zyga | mvo: (sorry for the lag, this machine is pretty slow) | 10:31 |
| zyga | so, I built and installed the package | 10:31 |
| zyga | I think we should make a few more tweaks | 10:32 |
| zyga | https://www.irccloud.com/pastebin/uLToDeBM/ | 10:32 |
| zyga | autoimport, core-fixup should probably be removed | 10:32 |
| zyga | snap-repair and system-shutdown, as well | 10:32 |
| zyga | snapd.failure.service, not sure about that one | 10:32 |
| zyga | mvo: I'll do some more exploratory testing | 10:33 |
| zyga | mvo: we should upload the package today | 10:33 |
| zyga | mvo: will the upload impact disco in any way? | 10:33 |
| mvo | zyga: yeah, all these services can go | 10:34 |
| mvo | zyga: it shouldn't impact disco | 10:34 |
| mvo | zyga: we will see | 10:35 |
| zyga | mvo: I pushed to salsa again, just to ensure that if this crusty machine falls apart we won't lose anything :) | 10:35 |
| mvo | zyga: +1 | 10:35 |
| zyga | I'm running microk8s now | 10:36 |
| zyga | I will run a few more snaps as well | 10:36 |
| zyga | mvo: I think we need a proper plan on how to bring this back to master | 10:36 |
| zyga | I feel that despite the effort and progress we are still in "we'll see when we release" state | 10:36 |
| zyga | mvo: after today I would like to work on feature I'm due to produce, I'm happy to make more progress in 2.38 or 2.37.1 | 10:39 |
| zyga | mvo: but we should discuss with samuele about what to realistically do about long term plan for snapd release readiness | 10:39 |
| mvo | zyga: there is a PR up for that :) | 10:44 |
| zyga | mvo: you mean your PR with sbuild? | 10:44 |
| mvo | zyga: I mean, we have a plan, we just need to merge your latest additions into 6396 | 10:44 |
| mvo | zyga: and then we are good | 10:44 |
| zyga | mvo: I think we still need to figure out how to work with patches | 10:44 |
| zyga | mvo: we either keep those patches and teach people to work with them | 10:45 |
| mvo | zyga: well, if we break a patch we break the build in 6396 | 10:45 |
| zyga | mvo: or figure out how to avoid patches | 10:45 |
| zyga | yes | 10:45 |
| mvo | zyga: I think that is acceptable for now and we try to reduce the patches | 10:45 |
| zyga | 1st requires more learning on all the team members, 2nd requires some ideas and more engineering | 10:45 |
| zyga | mvo: I would like to adjust debian to use my makefile | 10:45 |
| zyga | it handles things like "this is for core only, don't ship it" | 10:45 |
| mvo | zyga: yeah, but the patches are very tiny and isolated, we can always help if they get out of sync | 10:45 |
| zyga | yeah | 10:46 |
| mvo | zyga: quick HO for faster communication? | 10:46 |
| zyga | I mean, as I said, this is much better :) | 10:46 |
| mvo | zyga: yeah, one step at a time | 10:46 |
| zyga | but we still need to get through a few releases with no issues | 10:46 |
| mvo | zyga: I mean, I'm not disagreeing with anything :) | 10:46 |
| zyga | mvo: we can HO but I think we are in agreement :) | 10:46 |
| mvo | zyga: just 1. we release from salsa 2. we import salsa into our tree 3. we run the debian packaging on debian-sid in spread 4. ... | 10:46 |
| mvo | zyga: excellent | 10:46 |
| mvo | zyga: then lets HO later :) | 10:47 |
| zyga | yeah | 10:47 |
| zyga | +1 | 10:47 |
| mvo | zyga: but yeah, there is more work and open questions down the road! | 10:47 |
| mvo | zyga: and thanks for working on this! | 10:47 |
| zyga | mvo: "what about Debian Zygmunt?" :D | 10:48 |
| zyga | playing with microk8s, I think it works ok :) | 10:49 |
| mvo | zyga: cool | 10:56 |
| zyga | another build in progress | 10:58 |
| zyga | mborzecki: while fresh in my head, I'd like to look at https://github.com/snapcore/snapd/pull/6111 next | 11:00 |
| mup | PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111> | 11:00 |
| zyga | mborzecki: I will merge master and resolve conflicts | 11:00 |
| zyga | I would like to merge it as-is | 11:00 |
| zyga | to avoid bitrot in the makefile | 11:00 |
| zyga | then use this for 2.37 | 11:01 |
| mup | PR snapd#6405 closed: run-checks: ensure we use go-1.10 if available <Simple 😃> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6405> | 11:05 |
| Chipaca | zyga: AIUI Neal's comments were phrased as strong suggestions but seem to be actual blockers, or did I misunderstand? | 11:07 |
| zyga | Chipaca: I don't think those are blockers, the package works OK | 11:07 |
| zyga | more of a "this is the style to follow", at least in my eyes | 11:07 |
| Chipaca | zyga: what's the thing about debuginfo subpackages | 11:07 |
| zyga | nothing new AFAIK, just a desire to be able to tweak go flags | 11:09 |
| zyga | Chipaca: also looking at that comment, I'm not sure if that's actually something to do with suse or a preference to make it better for eventual use in fedora | 11:11 |
| zyga | I don't mind improvements, just want to walk before I run :) | 11:11 |
| ackk | mvo, well actually I get that file via snap download and it's like snapname_rev.snap. but I can look at the meta.yaml file | 11:39 |
| ackk | I mean meta/snap.yaml | 11:43 |
| mvo | ackk: aha, ok | 11:46 |
| Chipaca | ackk: but you know the architecture before you download, right? | 11:55 |
| Chipaca | ackk: or, rather, you can request a particular architecture :-) | 11:55 |
| Chipaca | so then you'd know that's the architecture you got | 11:56 |
| ackk | Chipaca, well yes and no. this is run from a jenkins job, which takes the revision as parameter. so yes the user know it but I wanted to avoid having to pass it. it's not a big deal at the moment as we're only building amd64, so it can be hardcoded. it'd be nice to have that in "snap info" though, it possile | 11:56 |
| Chipaca | ackk: what do you then do with the architecture? | 11:57 |
| ackk | Chipaca, don't ask :) | 11:57 |
| Chipaca | ackk: I ask because I wonder if you contemplate "all" vs ["amd64", "i386"] etc | 11:58 |
| Chipaca | bah, ["all"] | 11:58 |
| ackk | Chipaca, it's used to populate the Architecture field of a debian/control | 11:58 |
| ackk | well, currently it's not, but that's the idea | 11:58 |
| Chipaca | ackk: does debian/control support multiple values? | 11:59 |
| ackk | not sure | 11:59 |
| * Chipaca guesses no | 11:59 | |
| * Chipaca might not be guessing | 11:59 | |
| ackk | yeah I would think no | 11:59 |
| ackk | I think it's either "all" or a single arch | 11:59 |
| Chipaca | ackk: man deb-control, fwiw | 12:00 |
| zyga | switched back to my main machine | 12:00 |
| zyga | man that thinkpad has slow cpu ;0 | 12:00 |
| ackk | ah, TIL | 12:00 |
| ackk | Chipaca, btw how do you build a snap for more than one arch? | 12:01 |
| Chipaca | ackk: wait, you're creating debs from snaps? | 12:01 |
| Chipaca | ackk: build-on vs run-on | 12:02 |
| Chipaca | ackk: 1 sec, there's an example | 12:02 |
| ackk | Chipaca, I said don't ask :) | 12:02 |
| Chipaca | ackk: https://forum.snapcraft.io/t/architectures/4972?u=chipaca example 6 | 12:03 |
| zyga | mvo: I'm happy with CLI testing, I'll do one quick pass over graphical snaps on up-to-date debian-10 | 12:06 |
| zyga | mvo: then I will ask you to have a last look and dput, okay? | 12:06 |
| popey | Chipaca: is there any plan to make snap find more readable on a standard 80x25 terminal? | 12:06 |
| ackk | Chipaca, thanks, that's nice I didn't know about it | 12:07 |
| Chipaca | popey: no plan as yet. I'm aware it's not ideal, and have proposed a few solutions that were shot down | 12:08 |
| popey | :( | 12:08 |
| Chipaca | popey: currently we want (1) output unchanged (other than minor cosmetic changes) whether it's going to a terminal or to a pipe, and (2) a single result per line | 12:08 |
| popey | people pipe the output of snap find? | 12:09 |
| Chipaca | popey: my proposals broke both of those :-) | 12:09 |
| popey | isn't that what an API is for? | 12:09 |
| Chipaca | popey: snap find | grep yadda, yes people do | 12:10 |
| Chipaca | and that's reasonable, but I'm hoping we can do something like dpkg -l does which breaks (1) but only lightly | 12:10 |
| Chipaca | that'll be my next offering | 12:10 |
| Chipaca | when i get to it | 12:10 |
| Chipaca | (but it's a blue item) | 12:11 |
| Chipaca | popey: do you have any particularly egregious example? | 12:11 |
| popey | well, the output is barely readable in a stock terminal | 12:13 |
| popey | https://usercontent.irccloud-cdn.com/file/Wsj2NdJH/Screenshot%20from%202019-01-22%2012-14-06.png | 12:14 |
| zyga | popey: (I think we agree) | 12:17 |
| zyga | popey: we just need a solution | 12:17 |
| popey | This has been solved by apt/dpkg years ago :( | 12:17 |
| Chipaca | popey: not really | 12:18 |
| zyga | what is the solution? | 12:18 |
| popey | look at the output from dpkg -l or apt search foo | 12:19 |
| Chipaca | 'apt-cache search' just prints the name and the summary; 'apt search' is ungreppable; dpkg -l has you guessing as to whether it's the whole package name or not | 12:20 |
| zyga | Chipaca: in defense of the idea, I believe find should not require grepping | 12:20 |
| popey | well, apt does warn you not to use the output as it's not stable, but can be grepped | 12:21 |
| popey | apt search firefox | grep ubufox | 12:22 |
| popey | apt search firefox | grep -A 1 ubufox | 12:22 |
| Chipaca | I mean, you need to use perl -00 -p '/.../' | 12:22 |
| Chipaca | or, that | 12:23 |
| * Chipaca itches to write the right perl but stops himself | 12:23 | |
| Chipaca | but we're arguing over non-essentials I think | 12:24 |
| Chipaca | I agree with you that it's not ideal, and I've proposed solutions for it, and the discussion of how to address it is ongoing | 12:24 |
| Chipaca | snap find, snap list, snap changes, they're all bad in this sense | 12:25 |
| Chipaca | 'snap info' and the progress bars are ok afaik | 12:26 |
| popey | Ok. I won't bug you then. Just a shame ::( | 12:26 |
| Chipaca | as long as we ignore unicode width that is (e.g. 'snap info unifonter') | 12:26 |
| popey | snap info word wraps the summary oddly, snap info libreoffice | 12:26 |
| Chipaca | seems finie here | 12:27 |
| Chipaca | fine* | 12:27 |
| Chipaca | popey: how's it odd? | 12:27 |
| popey | https://usercontent.irccloud-cdn.com/file/CLXey6IM/Screenshot%20from%202019-01-22%2012-27-36.png | 12:27 |
| popey | " slideshows and databases" | 12:27 |
| Chipaca | agh | 12:28 |
| Chipaca | you did say summary | 12:28 |
| Chipaca | i was looking at description | 12:28 |
| Chipaca | i'll fix that | 12:28 |
| popey | thanks | 12:29 |
| zyga | W: snapd: systemd-service-file-refers-to-unusual-wantedby-target lib/systemd/system/snapd.seeded.service cloud-final.service | 12:30 |
| zyga | hmmm | 12:30 |
| zyga | hmmm | 12:41 |
| zyga | snapd doesn't start after reboot | 12:41 |
| zyga | boot hangs | 12:41 |
| zyga | I guess the package needs more love | 12:41 |
| zyga | ah, I was following edge | 12:47 |
| zyga | switched to stable to really use the package we made | 12:47 |
| zyga | reboot and same behavior | 12:48 |
| zyga | hmm | 12:48 |
| zyga | mvo: snapd.service, failedwith result 'timeout' | 12:51 |
| zyga | (then we get killed with sigterm) | 12:51 |
| zyga | snapd.service has onfailure=snapd.failure.service, I guess that should be patched out? | 12:51 |
| zyga | we are type=notify | 12:52 |
| zyga | hmmmm | 12:52 |
| zyga | starting it by hand works ok | 12:53 |
| zyga | no idea, | 12:53 |
| zyga | let's see what happens with more debugging | 12:54 |
| zyga | hmm, not much | 12:55 |
| mborzecki | off to pick up the kids | 13:00 |
| zyga | I've added error handling around sd_notify | 13:09 |
| zyga | pstolowski|afk: hey | 13:31 |
| zyga | around? | 13:31 |
| zyga | man, build cycle is ~20+ minutes | 13:40 |
| zyga | hmmm | 13:43 |
| zyga | snapd.service times out starting https://www.irccloud.com/pastebin/F1Jh1CRa/ | 13:43 |
| zyga | mvo: around? | 13:43 |
| Chipaca | zyga: can you try that again with debug? | 13:44 |
| zyga | it *is* with debug | 13:44 |
| Chipaca | zyga: or was the first time already debug | 13:44 |
| Chipaca | the first run i mean, that timed out, can you repro it? | 13:44 |
| zyga | looks like we block somewhere early on | 13:44 |
| zyga | no, only during reboot | 13:44 |
| zyga | when we start up | 13:44 |
| zyga | maybe sanity check mount thing? | 13:44 |
| zyga | gosh I hate patching packaging | 13:47 |
| zyga | quilt is the monumental suck | 13:47 |
| mvo | zyga: yes, sorry for the delay | 13:48 |
| zyga | no worries :) | 13:48 |
| zyga | I'm adding more debugging | 13:48 |
| zyga | but ideas welcome | 13:48 |
| zyga | if you want we can HO | 13:48 |
| mvo | zyga: pstolowski|afk is not around this week | 13:49 |
| zyga | i see | 13:49 |
| zyga | ok | 13:49 |
| mvo | zyga: I'm looking at the backlog - do you have a short summary hwat the issue is? | 13:50 |
| mvo | zyga: aha, start operation timed out? | 13:50 |
| zyga | snapd works fine | 13:50 |
| zyga | on reboot it just hangs | 13:50 |
| zyga | switching to a vt magically unblocks it | 13:50 |
| zyga | adding debug to pinpoint where | 13:50 |
| zyga | no more ideas | 13:50 |
| mvo | zyga: on reboot only? or on stop as well? | 13:50 |
| zyga | on boot up | 13:51 |
| zyga | not shutdown part of reboot | 13:51 |
| mvo | zyga: oh, on bootup - how strange | 13:52 |
| zyga | mvo: I pushed all the patches to salsa | 13:52 |
| zyga | I can also share a .deb for debugging | 13:52 |
| mup | PR snapcraft#2446 opened: Update schema/snapcraft.yaml <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/2446> | 13:52 |
| zyga | added more and running another build now, ~~ 20 minutes till results show up | 13:53 |
| mvo | zyga: can you set SNAPD_DEBUG=1 in /etc/environment | 13:53 |
| zyga | I did | 13:53 |
| zyga | the log above was with that in place | 13:53 |
| mvo | zyga: oh | 13:53 |
| zyga | right? curious | 13:53 |
| mvo | zyga: so nothing between Starting ... and timeout :/ | 13:53 |
| zyga | correct | 13:53 |
| zyga | my hunch is on mount | 13:53 |
| zyga | deadlock/ | 13:53 |
| zyga | we'll ee | 13:54 |
| zyga | see, gosh keyboards | 13:54 |
| mvo | sty 22 14:41:30 debian-10 systemd[1]: Starting Snappy daemon... | 13:54 |
| mvo | sty 22 14:42:35 debian-10 snapd[1040]: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network | 13:54 |
| Chipaca | zyga: can you dump "systemd-analyze --plot" somewhere? | 13:54 |
| mvo | zyga: well, second start takes 1m05 until output | 13:54 |
| zyga | on it | 13:54 |
| mvo | zyga: so strange | 13:54 |
| zyga | mvo: it starts only after I switch vt | 13:54 |
| Chipaca | zyga: also systemd-analyze blame | 13:54 |
| mvo | zyga: strace would be great, but I guess thats hard - or could you ssh into it? | 13:55 |
| zyga | mvo: I'll try | 13:55 |
| zyga | sigh | 13:56 |
| zyga | pastebinit broken on debian | 13:56 |
| zyga | I hate that it just doesn't work on fedora / debian normally | 13:56 |
| Chipaca | zyga: snap it :-D | 13:56 |
| mborzecki | zyga: huh, broken even for paste.debian.net? | 13:57 |
| zyga | mborzecki: echo broken | pastebinit | 13:57 |
| zyga | it's broken if that doesn't work | 13:57 |
| zyga | it doesn't work | 13:57 |
| mborzecki | damn | 13:57 |
| zyga | if you have to configure it it is broken | 13:57 |
| Chipaca | mborzecki: this being debian, I assume it needs post-install tweaking to work | 13:57 |
| zyga | https://pastebin.ubuntu.com/p/XDpPTRhsG8/ | 13:57 |
| zyga | snapd.seeded | 13:57 |
| Chipaca | zyga: doesn't snapd have after: snapd.seeded? | 13:58 |
| Chipaca | or was snapd.seeded a snapd thing | 13:58 |
| mvo | zyga: journalctl -u snapd.seeded? | 13:59 |
| mborzecki | snapd.seeded pokes snapd | 13:59 |
| zyga | i cannot paste the .svg file | 13:59 |
| zyga | because reasons on pastebin | 13:59 |
| Chipaca | ah, seeded is after=snapd | 13:59 |
| Chipaca | so snapd does not need seded, indeed | 13:59 |
| zyga | standup | 14:00 |
| Chipaca | zyga: copy it to people.c.c (or dump it in your lab :-) ) | 14:00 |
| * Chipaca stands up | 14:00 | |
| Chipaca | and then? | 14:00 |
| mborzecki | maybe it's slow key generation? | 14:00 |
| mborzecki | ssh is also slow to start | 14:00 |
| zyga | ssh is slow yes | 14:00 |
| zyga | no idea | 14:00 |
| zyga | https://www.irccloud.com/pastebin/rTkZQ1hN/ | 14:02 |
| zyga | that's for snapd.seeded.service | 14:02 |
| Chipaca | zyga: how's your random pool? | 14:09 |
| zyga | Chipaca: hard to say but that kernel seems to log and hand out randomness that's not really random | 14:10 |
| zyga | let me reboot and see | 14:10 |
| Chipaca | zyga: sysctl kernel.random.entropy_avail | 14:10 |
| zyga | booting now | 14:11 |
| zyga | thank for the tip :) | 14:11 |
| Chipaca | zyga: maybe in a ExecStartPre | 14:11 |
| zyga | it's possible | 14:11 |
| zyga | that it was it | 14:11 |
| zyga | and by logging in on vt3 I add entropy | 14:11 |
| mborzecki | haha omg :) | 14:11 |
| Chipaca | that would also explain ssh being slow | 14:12 |
| zyga | after logging in I got 861 | 14:12 |
| mborzecki | zyga: can you prepare a new machine and install heaveged on it? | 14:12 |
| zyga | install what? | 14:12 |
| mborzecki | haveged | 14:13 |
| zyga | started after adding more debugging https://www.irccloud.com/pastebin/9oE0zyy1/ | 14:13 |
| zyga | mborzecki: sure, I can clone this machine | 14:13 |
| zyga | and see if that helps | 14:13 |
| mborzecki | btw. multipass ought to be using virtio-rng too (probably is) | 14:13 |
| zyga | this is vmware | 14:13 |
| zyga | https://github.com/snapcore/snapd/pull/6367 | 14:15 |
| mup | PR #6367: cmd/snap-update-ns: allow switching to user mount namespace <Per-user mount ns 🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6367> | 14:15 |
| zyga | https://www.irccloud.com/pastebin/IQQwkG13/ | 14:37 |
| Chipaca | zyga: did you add the ExecStartPre line? | 14:38 |
| zyga | hold on, not yet | 14:40 |
| popey | Hm, if I set icon: somepath/foo.png then it copies that icon to meta/gui/icon.png which isn't the actual filename, and isn't what's in the desktop file | 14:43 |
| popey | I wonder why snapcraft does that? | 14:43 |
| popey | why not copy it to snapname.png to match the desktop file? | 14:44 |
| Chipaca | popey: 'old on | 14:45 |
| Chipaca | popey: that's the icon _of the snap_ | 14:45 |
| Chipaca | popey: there aren't desktop files for snaps | 14:45 |
| Chipaca | popey: it's separate from the icon for the apps in the snap, which are referenced from desktop files | 14:46 |
| Chipaca | popey: for example if you were packing an office suite, the icon for the suite would be distinct from the icons for each component application | 14:46 |
| popey | huh | 14:46 |
| popey | is that because i put the icon: outside the apps: ? | 14:47 |
| Chipaca | popey: granted if it's a single app they'll often be the same, in which case you'd have duplicated (or carefully point at the one from the other, which is harder) | 14:47 |
| popey | would it work if I put icon: in the apps: stanza? | 14:47 |
| Chipaca | popey: snaps don't yet know about per-app icons (desktop files do) | 14:47 |
| popey | why is this so hard :( | 14:47 |
| Chipaca | popey: if it were easy, ubuntu wouldn't exist | 14:47 |
| Chipaca | ¯\_(ツ)_/¯ | 14:47 |
| Chipaca | the reason distributiosn exist is ebcause this stuff is hard :-) | 14:48 |
| popey | i have an app which has an icon in its tree and a desktop file, i guess I need to ninja the desktop file and move the icon | 14:48 |
| Chipaca | also typing is hard | 14:48 |
| popey | right, but I thought we were supposed to be making this easier | 14:48 |
| popey | this isn't easier, it's brutal | 14:48 |
| Chipaca | popey: we try | 14:48 |
| Chipaca | popey: doesn't the desktop file get included in the snap already? | 14:48 |
| zyga | https://salsa.debian.org/zyga-guest/snapd | 14:48 |
| mborzecki | zyga: a thought, could it be that we regenrate security profiles? | 14:49 |
| zyga | In a call | 14:49 |
| popey | the desktop file is included if i use desktop: to point to it, sure | 14:49 |
| popey | ah well. | 14:49 |
| Chipaca | hmmm | 14:50 |
| Chipaca | maybe snapcraft should have per-app icons? but not sure what it'd to with them other than copy them | 14:50 |
| Chipaca | does it tweak the desktop file so the icon path is in the snap, or does the dev need to do that? | 14:50 |
| Chipaca | (sounds hard for snapcraft to know that) | 14:51 |
| popey | ok, i have bodged it for now by editing the desktop file | 14:51 |
| zyga | re | 15:01 |
| zyga | mborzecki: I checked that, we just don't get started | 15:01 |
| zyga | mborzecki: so it's not that | 15:01 |
| zyga | mborzecki: i added a patch with extra debug logs around startup | 15:01 |
| zyga | mborzecki: in the end it was entropy | 15:01 |
| zyga | just hitting random keys is enough to boot instantly without any timeouts | 15:01 |
| zyga | I will have some food now and then get back to releasing this properly | 15:02 |
| diddledan | https://forum.snapcraft.io/t/snapcraft-schema-validation-in-vscode/9609 | 15:06 |
| diddledan | \o/ | 15:06 |
| diddledan | who rocks your socks?!? | 15:06 |
| diddledan | me! I rock your socks! *chants* I rock your socks. I rock your socks. Ess Oh See Ess. | 15:07 |
| diddledan | I mean Ess Oh See KayEss | 15:08 |
| Chipaca | diddledan: https://www.reddit.com/r/Jokes/comments/1pbq6b/a_spanish_man_who_spoke_no_english_went_into_a/ | 15:11 |
| diddledan | haha | 15:12 |
| mvo | zyga: I did some smoke testing with the debian deb and all is looking well, will try to run autopkgtest now too | 15:26 |
| Chipaca | mvo: is this on your top secret debian box with a nuclear RNG | 15:27 |
| jdstrand | roadmr: hi! would you mind pulling the review-tools r1178? | 15:34 |
| jdstrand | roadmr: and happy new year :) | 15:34 |
| roadmr | jdstrand: hello! Sure, I'll queue that. Happy new year to you too! | 15:34 |
| jdstrand | roadmr: thanks. no rush | 15:35 |
| zyga | mvo: thank you | 15:49 |
| zyga | :) | 15:49 |
| mvo | zyga: autopkgtest is tricky, but I have not given up yet | 15:52 |
| zyga | do you mean more than sbuild --run-adt | 15:52 |
| * cachio lunch | 15:53 | |
| mvo | zyga: I wanted to run it in a separate vm, but I can try the other option too | 15:54 |
| * zyga resumes work in the office | 16:02 | |
| Chipaca | mvo: how are we for point releases of 2.37? anything going on there? | 16:05 |
| zyga | mvo: I added a trello card as we talked | 16:12 |
| zyga | mvo: I feel it would be nice to have a "process" card | 16:12 |
| zyga | not a feature, not a bug | 16:12 |
| zyga | I mean, card label | 16:12 |
| zyga | oh, I see there are now two cards, sorry for not looking earlier | 16:13 |
| mvo | Chipaca: I think we will have a .1 release but no firm plans yet, it looks pretty good so far | 16:17 |
| mup | PR # closed: core-build#11, core-build#22, core-build#26, core-build#37 | 16:21 |
| mup | PR # opened: core-build#11, core-build#22, core-build#26, core-build#37 | 16:22 |
| Chipaca | mvo: I'll tag a low-priority pr for 2.37 then, but no biggie if it doesn't make it | 16:22 |
| om26er | Is this statement still true for Ubuntu Core 18 as well ? "the older kernel shipped with this image can trigger Wi-Fi issues during first boot, a network cable is recommended." | 16:22 |
| om26er | found on: https://www.ubuntu.com/download/iot/raspberry-pi-2-3 | 16:23 |
| mvo | Chipaca: sounds good, is it up yet? | 16:23 |
| Chipaca | mvo: no | 16:23 |
| Chipaca | mvo: writing tests | 16:23 |
| om26er | afaik, Pi3 UbuntuCore 18 image ships Linux 4.15 (which is new enough?) | 16:23 |
| mvo | Chipaca: ta | 16:27 |
| mvo | om26er: UC18 ships with 4.15, I don't know about this specific problem to know if it is fixed or not, but maybe someone from the kernel team (like ppisati knows if"the older kernel shipped with this image can trigger Wi-Fi issues during first boot, a network cable is recommended." is still accurate | 16:28 |
| mvo | ) | 16:28 |
| cwayne | It's not accurate | 16:28 |
| mvo | cwayne: ok, thank you | 16:34 |
| mvo | degville: do you know who the best person is to talk to abouthttps://www.ubuntu.com/download/iot/raspberry-pi-2-3 ? the phrase "- the older kernel shipped with this image can trigger Wi-Fi issues during first boot, a network cable is recommended." is apparently no longer needed in a 4.15 kernel world (cc ppisati cwayne om26er ) | 16:36 |
| popey | (there's a bug report link at the bottom? ) | 16:37 |
| degville | mvo: I don't know for certain, but I can likely find the repo and create a PR to get it changed. | 16:37 |
| mvo | popey: *cough* thank you | 16:38 |
| mvo | degville: nevermind, thanks to popey I found the "bugreport" thing, I will just paste the irc conversation | 16:38 |
| degville | mvo: ok, cool. | 16:39 |
| degville | mvo / popey: ...although it looks like it could get lost in a sea of issues. I'll take a look and see if it's easy to change. | 16:41 |
| mvo | cwayne, om26er https://github.com/canonical-websites/www.ubuntu.com/issues/4577 | 16:41 |
| mvo | degville: -^ | 16:41 |
| om26er | thanks mvo | 16:42 |
| mvo | om26er: thank you for reporting this | 16:42 |
| mvo | zyga: autopkgtest in a full debian sid vm running, fingers test | 16:43 |
| mup | PR snapd#6411 opened: cmd/snap: wrap "summary" better <Created by chipaca> <https://github.com/snapcore/snapd/pull/6411> | 16:43 |
| zyga | mvo: super, fingers indeed crossed :) | 16:43 |
| Chipaca | popey: https://github.com/snapcore/snapd/pull/6411#issuecomment-456472879 | 16:49 |
| mup | PR #6411: cmd/snap: wrap "summary" better <Created by chipaca> <https://github.com/snapcore/snapd/pull/6411> | 16:49 |
| popey | <3 | 16:49 |
| Chipaca | mvo: ^ that's the thing I think wouldn't be bad in 2.37.1 | 16:50 |
| mvo | Chipaca: ta | 16:51 |
| Chipaca | mvo: did you get a chance to look at #6389 ? | 16:53 |
| mup | PR #6389: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <https://github.com/snapcore/snapd/pull/6389> | 16:54 |
| zyga | mvo: I'm trying to recall the passphrase to my gpg key :| | 16:56 |
| Chipaca | zyga: was it "Vishok7oc," | 16:57 |
| * Chipaca has apg and knows how to use it | 16:57 | |
| zyga | eh, I wish I used this more often | 16:58 |
| zyga | got it :) | 17:03 |
| zyga | whee | 17:03 |
| zyga | and published (I changed the expiry date) | 17:06 |
| sparkiegeek | hmm, what's the bug for SRUing snapd 2.37 into e.g. Bionic? | 17:10 |
| zyga | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1811233 | 17:10 |
| mup | Bug #1811233: [SRU] 2.37 <verification-done> <verification-done-bionic> <verification-done-cosmic> <verification-done-trusty> <verification-done-xenial> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):Fix Committed> <snapd (Ubuntu Xenial):Fix Committed> <snapd (Ubuntu Bionic):Fix Committed> | 17:10 |
| mup | <snapd (Ubuntu Cosmic):Fix Committed> <https://launchpad.net/bugs/1811233> | 17:10 |
| sparkiegeek | zyga: thanks | 17:11 |
| sparkiegeek | ah, was hidden from search because the main task is Fix Released | 17:12 |
| === ricab is now known as ricab|bbiab | ||
| === ricab|bbiab is now known as ricab | ||
| jdstrand | mvo: hey, we spoke before about policy updates for 2.37 that I'd do the week after the sprint (ie, now). It seems like 2.37 is released (I saw the disco SRU). should I postpone these for 2.38 or submit to 2.37? | 17:43 |
| zyga | jdstrand: (responding in place of mvo): I think we are open to a 2.37.1 | 17:45 |
| zyga | jdstrand: the point of 2.37 now is to hit debian | 17:45 |
| jdstrand | ok, well, I'll pick that up then and target both master and 2.37 | 17:48 |
| zyga | if you target master I think we can cherry pick, as long as you tag them as 2.37 | 17:49 |
| mvo | jdstrand: should hopefully be trivial, master and 2.37 are not that different yet | 17:59 |
| * zyga EODs | 18:06 | |
| jdstrand | mvo: yeah, wasn't worried about that-- just wanted to understand your timing. thanks! | 18:37 |
| mup | PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10> | 19:06 |
| mup | PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11> | 19:06 |
| mup | PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10> | 19:07 |
| mup | PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11> | 19:07 |
| roadmr | jdstrand: hi! hey I notice the base declaration added two interfaces (personal-files and system-files). Do these count as "superprivileged" ones? | 19:47 |
| roadmr | jdstrand: adding the new r1178 release of the tools made some of my tests fail because these new interfaces appeared, and are being compared against a list of so-called superprivileged ones. I can update this list, just checking with you this is expected | 19:47 |
| jdstrand | roadmr: they are superprivileged, | 19:49 |
| jdstrand | yes | 19:49 |
| jdstrand | in | 19:49 |
| jdstrand | jeez | 19:49 |
| jdstrand | in terms of the base decl, they follow that same pattern | 19:49 |
| roadmr | jdstrand: ok, so this seems to be copacetic then. I'll go ahead with the merge, thanks! | 19:51 |
| jdstrand | roadmr: cool, thanks! | 19:56 |
| === phoenix_firebrd is now known as murthy | ||
| mup | PR snapd#6412 opened: tests: interfaces tests normalization <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6412> | 21:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
