=== epod is now known as luk3yx
zygamborzecki: hey :)05:56
zygamborzecki: making breakfast, how are you?05:56
mborzeckizyga: hey05:56
mborzeckizyga: how's your back?05:56
zygamborzecki: better, not sure what happened yesterday, wasn't my typical thing05:57
mborzeckizyga: glad that it's better05:58
mborzeckiheh, so debian sid has some really new version of go, and tests/unit/go bails out do to gofmt changes :006:14
zygamborzecki: yeah, I noticed :|06:21
zygawe should disable those or figure out if we can pin the format06:22
zygamborzecki: I solved the unit test issues that happen when building in sbuild06:22
zygalet me push a patch against master06:22
zygano, that is still off06:23
zygabut I will investigate that next06:23
zygaI need to compile a few programs on sid toolchain and buster toolchain06:23
mborzeckiit'd be nice to run the unit tests on sid06:28
zygayeah, that's still somewhat away06:28
mborzeckiwe'll probably need to add an off switch for gofmt in run-checks06:28
zygathe key difference was not sid06:28
zygajust sbuild06:28
mborzeckii meant #6406, it's failing due to gofmt from go 1.11 which uses a different indent length when aligning struct field values & comments06:29
mupPR #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
mupPR snapd#6409 opened: interfaces/apparmor: mock presence of overlayfs root <Created by zyga> <https://github.com/snapcore/snapd/pull/6409>06:32
zygamborzecki: I have more patches but those are of the simple kind that disable stuff06:33
zygamborzecki: the key thing I achieved yesterday, was to build a process where it is easy and fast to iterate on this06:34
=== cpaelzer__ is now known as cpaelzer
=== phoenix_firebrd is now known as murthy
zygaback now07:22
zygamvo: hello :)07:22
zygamvo: how are you doing after the game last night?07:22
mvozyga: hey, still feel a bit battered but ready for work07:23
=== murthy is now known as phoenix_firebrd_
=== phoenix_firebrd_ is now known as murthy
zygamvo: I pushed one PR already07:27
zygait contains the fixes for unit tests that are applicable to master07:27
zygamvo: I also, just now, opened another pull request07:27
zygathat adds a program to release-tools07:28
mupPR snapd#6410 opened: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410>07:28
zygato improve the process on working on debian packaging07:28
zygaright now the package builds but needs review (it's non-trivial) and it needs more love to fix lintian isues07:28
zygaadt tests also fail but I didn't investigate any more than that07:28
zygaplease have a look at 6410 as a starting point if that's okay07:28
mvozyga: sure07:30
mvozyga: thanks!07:30
zygamvo: 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/snapd07:30
mvozyga: ok07:31
mvozyga: 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
zygamvo: it has one E so I think at least that must be fixed07:32
zygamvo: I suspect I did something silly in my meld-based-merge07:32
zygaand we can get rid of most of W-s easily07:33
zygamvo: my smoke test would be to install the package and run a few snaps quickly07:33
mborzecki#6409 needs a 2nd review and can land07:33
mupPR #6409: interfaces/apparmor: mock presence of overlayfs root <Created by zyga> <https://github.com/snapcore/snapd/pull/6409>07:33
mborzeckimvo: morning07:33
mvomborzecki: good morning07:33
mvozyga: yeah, that sounds sensible07:34
mvomborzecki: did a second review on 6409 - just one tiny question07:34
mborzeckimvo: https://github.com/snapcore/snapd/pull/6405 has a suggestion from Chipaca that can be applied via github07:37
zygamvo: replied07:38
mupPR #6405: run-checks: ensure we use go-1.10 if available <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6405>07:38
mupPR 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
mupPR 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
mvozyga: thanks, also cherry-picked it now07:39
zygathank you!07:39
mvozyga: thank *you* :)07:40
mvozyga: one thing less to worry about07:40
zygamvo: yeah07:40
zygamvo: after getting to the point where I can run interactive shell inside sbuild inside debian 10 vm07:40
zygamvo: and finding my way around the odd way dh-golang arranges the source code07:41
zygait was okay07:41
zygamvo: all of the patches I remade/added are in https://salsa.debian.org/zyga-guest/snapd/commits/debian-patches07:41
zygamvo: I will look at seccomp now, could you look at lintian please?07:42
zygaand just see if what I made makes any sense07:42
murthyOlivier Tilloy thanks for making chromium with vaapi working  snap.07:52
mvozyga: yeah, could you please pastebin the errors again?07:53
mvozyga: or point me to it?07:53
mvozyga: I have lintian and your tree etc, looking at this now08:39
mvozyga: please apply http://paste.ubuntu.com/p/YkfDs69XSq/ (I can do a formal pull rquest if you prefer)08:42
mvozyga: test building that now08:42
zygamvo: re, sorry, had some things happening at home08:54
zygamvo: applying08:54
mvozyga: ta - also your changelog needs one extra space after me@zygoon.pl> and before Thu,09:00
mvozyga: there must be two spaces there or lintian is unhappy09:01
mvozyga: I look at the ones produced by the binary build now09:01
mvozyga: fwiw, the way this can be driven via gbp: http://paste.ubuntu.com/p/YYqSsxV2g6/09:02
mvozyga: this builds fine in sbuild under bionic fwiw09:03
mvozyga: (i.e. no unit test or other issues)09:03
mvozyga: the other warning that is easy to fix is that snap-discard-ns.8 has "section: 5" in the .rst file, trivial to fix09:08
zygaI see09:08
mvozyga: there are some more warnings that we should probably just lintian override09:08
mvozyga: but I think they are ok for now09:08
ackkhi, given a .snap file, is it possible to know which arch is it built for? "snap info" doesn't provide that info AFAICT09:30
zygaackk: you can look at meta/snap.yaml, at the architecture field09:34
zygabut there's nothing quick and easy I'm afraiid09:34
ackkzyga, I ses, so I guess I have to mount the snap filesystem for that09:36
zygaor extract that file09:36
ackkzyga, ok, thanks09:37
ackkzyga, maybe it could be an improvement of "snap info" ? :)09:37
zygaackk: do we show that with snap info --verbose?09:39
zygaor -v09:39
ackkzyga, no09:43
mvozyga: yeah, that sounds like a bug09:45
mvoackk: ups, sorry, I mean that sounds like a missing feature09:45
mvoackk: you can look at the filename09:45
mvoackk: but its *very* crude09:45
Chipacapedronis: you around?09:46
mvoChipaca: he is off today09:49
Chipacaah i thought that was yesterday09:49
Chipacamvo: zyga: let's add architecture to the info backlog :-)09:51
mvoChipaca: +109:53
mupPR 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
zygamvo: (sorry for the lag, this machine is pretty slow)10:31
zygaso, I built and installed the package10:31
zygaI think we should make a few more tweaks10:32
zygaautoimport, core-fixup should probably be removed10:32
zygasnap-repair and system-shutdown, as well10:32
zygasnapd.failure.service, not sure about that one10:32
zygamvo: I'll do some more exploratory testing10:33
zygamvo: we should upload the package today10:33
zygamvo: will the upload impact disco in any way?10:33
mvozyga: yeah, all these services can go10:34
mvozyga: it shouldn't impact disco10:34
mvozyga: we will see10:35
zygamvo: I pushed to salsa again, just to ensure that if this crusty machine falls apart we won't lose anything :)10:35
mvozyga: +110:35
zygaI'm running microk8s now10:36
zygaI will run a few more snaps as well10:36
zygamvo: I think we need a proper plan on how to bring this back to master10:36
zygaI feel that despite the effort and progress we are still in "we'll see when we release" state10:36
zygamvo: 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.110:39
zygamvo: but we should discuss with samuele about what to realistically do about long term plan for snapd release readiness10:39
mvozyga: there is a PR up for that :)10:44
zygamvo: you mean your PR with sbuild?10:44
mvozyga: I mean, we have a plan, we just need to merge your latest additions into 639610:44
mvozyga: and then we are good10:44
zygamvo: I think we still need to figure out how to work with patches10:44
zygamvo: we either keep those patches and teach people to work with them10:45
mvozyga: well, if we break a patch we break the build in 639610:45
zygamvo: or figure out how to avoid patches10:45
mvozyga: I think that is acceptable for now and we try to reduce the patches10:45
zyga1st requires more learning on all the team members, 2nd requires some ideas and more engineering10:45
zygamvo: I would like to adjust debian to use my makefile10:45
zygait handles things like "this is for core only, don't ship it"10:45
mvozyga: yeah, but the patches are very tiny and isolated, we can always help if they get out of sync10:45
mvozyga: quick HO for faster communication?10:46
zygaI mean, as I said, this is much better :)10:46
mvozyga: yeah, one step at a time10:46
zygabut we still need to get through a few releases with no issues10:46
mvozyga: I mean, I'm not disagreeing with anything :)10:46
zygamvo: we can HO but I think we are in agreement :)10:46
mvozyga: 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
mvozyga: excellent10:46
mvozyga: then lets HO later :)10:47
mvozyga: but yeah, there is more work and open questions down the road!10:47
mvozyga: and thanks for working on this!10:47
zygamvo: "what about Debian Zygmunt?" :D10:48
zygaplaying with microk8s, I think it works ok :)10:49
mvozyga: cool10:56
zygaanother build in progress10:58
zygamborzecki: while fresh in my head, I'd like to look at https://github.com/snapcore/snapd/pull/6111 next11:00
mupPR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>11:00
zygamborzecki: I will merge master and resolve conflicts11:00
zygaI would like to merge it as-is11:00
zygato avoid bitrot in the makefile11:00
zygathen use this for 2.3711:01
mupPR 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
Chipacazyga: AIUI Neal's comments were phrased as strong suggestions but seem to be actual blockers, or did I misunderstand?11:07
zygaChipaca: I don't think those are blockers, the package works OK11:07
zygamore of a "this is the style to follow", at least in my eyes11:07
Chipacazyga: what's the thing about debuginfo subpackages11:07
zyganothing new AFAIK, just a desire to be able to tweak go flags11:09
zygaChipaca: 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 fedora11:11
zygaI don't mind improvements, just want to walk before I run :)11:11
ackkmvo, well actually I get that file via snap download and it's like  snapname_rev.snap. but I can look at the meta.yaml file11:39
ackkI mean meta/snap.yaml11:43
mvoackk: aha, ok11:46
Chipacaackk: but you know the architecture before you download, right?11:55
Chipacaackk: or, rather, you can request a particular architecture :-)11:55
Chipacaso then you'd know that's the architecture you got11:56
ackkChipaca, 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 possile11:56
Chipacaackk: what do you then do with the architecture?11:57
ackkChipaca, don't ask :)11:57
Chipacaackk: I ask because I wonder if you contemplate "all" vs ["amd64", "i386"] etc11:58
Chipacabah, ["all"]11:58
ackkChipaca, it's used to populate the Architecture field of a debian/control11:58
ackkwell, currently it's not, but that's the idea11:58
Chipacaackk: does debian/control support multiple values?11:59
ackknot sure11:59
* Chipaca guesses no11:59
* Chipaca might not be guessing11:59
ackkyeah I would think no11:59
ackkI think it's either "all" or a single arch11:59
Chipacaackk: man deb-control, fwiw12:00
zygaswitched back to my main machine12:00
zygaman that thinkpad has slow cpu ;012:00
ackkah, TIL12:00
ackkChipaca, btw how do you build a snap for more than one arch?12:01
Chipacaackk: wait, you're creating debs from snaps?12:01
Chipacaackk: build-on vs run-on12:02
Chipacaackk: 1 sec, there's an example12:02
ackkChipaca, I said don't ask :)12:02
Chipacaackk: https://forum.snapcraft.io/t/architectures/4972?u=chipaca example 612:03
zygamvo: I'm happy with CLI testing, I'll do one quick pass over graphical snaps on up-to-date debian-1012:06
zygamvo: then I will ask you to have a last look and dput, okay?12:06
popeyChipaca: is there any plan to make snap find more readable on a standard 80x25 terminal?12:06
ackkChipaca, thanks, that's nice I didn't know about it12:07
Chipacapopey: no plan as yet. I'm aware it's not ideal, and have proposed a few solutions that were shot down12:08
Chipacapopey: 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 line12:08
popeypeople pipe the output of snap find?12:09
Chipacapopey: my proposals broke both of those :-)12:09
popeyisn't that what an API is for?12:09
Chipacapopey: snap find | grep yadda, yes people do12:10
Chipacaand that's reasonable, but I'm hoping we can do something like dpkg -l does which breaks (1) but only lightly12:10
Chipacathat'll be my next offering12:10
Chipacawhen i get to it12:10
Chipaca(but it's a blue item)12:11
Chipacapopey: do you have any particularly egregious example?12:11
popeywell, the output is barely readable in a stock terminal12:13
zygapopey: (I think we agree)12:17
zygapopey: we just need a solution12:17
popeyThis has been solved by apt/dpkg years ago :(12:17
Chipacapopey: not really12:18
zygawhat is the solution?12:18
popeylook at the output from dpkg -l or apt search foo12: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 not12:20
zygaChipaca: in defense of the idea, I believe find should not require grepping12:20
popeywell, apt does warn you not to use the output as it's not stable, but can be grepped12:21
popeyapt search firefox | grep ubufox12:22
popeyapt search firefox | grep -A 1 ubufox12:22
ChipacaI mean, you need to use perl -00 -p '/.../'12:22
Chipacaor, that12:23
* Chipaca itches to write the right perl but stops himself12:23
Chipacabut we're arguing over non-essentials I think12:24
ChipacaI agree with you that it's not ideal, and I've proposed solutions for it, and the discussion of how to address it is ongoing12:24
Chipacasnap find, snap list, snap changes, they're all bad in this sense12:25
Chipaca'snap info' and the progress bars are ok afaik12:26
popeyOk. I won't bug you then. Just a shame  ::(12:26
Chipacaas long as we ignore unicode width that is (e.g. 'snap info unifonter')12:26
popeysnap info word wraps the summary oddly, snap info libreoffice12:26
Chipacaseems finie here12:27
Chipacapopey: how's it odd?12:27
popey"  slideshows and databases"12:27
Chipacayou did say summary12:28
Chipacai was looking at description12:28
Chipacai'll fix that12:28
zygaW: snapd: systemd-service-file-refers-to-unusual-wantedby-target lib/systemd/system/snapd.seeded.service cloud-final.service12:30
zygasnapd doesn't start after reboot12:41
zygaboot hangs12:41
zygaI guess the package needs more love12:41
zygaah, I was following edge12:47
zygaswitched to stable to really use the package we made12:47
zygareboot and same behavior12:48
zygamvo: snapd.service, failedwith result 'timeout'12:51
zyga(then we get killed with sigterm)12:51
zygasnapd.service has onfailure=snapd.failure.service, I guess that should be patched out?12:51
zygawe are type=notify12:52
zygastarting it by hand works ok12:53
zygano idea,12:53
zygalet's see what happens with more debugging12:54
zygahmm, not much12:55
mborzeckioff to pick up the kids13:00
zygaI've added error handling around sd_notify13:09
zygapstolowski|afk: hey13:31
zygaman, build cycle is  ~20+ minutes13:40
zygasnapd.service times out starting https://www.irccloud.com/pastebin/F1Jh1CRa/13:43
zygamvo: around?13:43
Chipacazyga: can you try that again with debug?13:44
zygait *is* with debug13:44
Chipacazyga: or  was the first time already debug13:44
Chipacathe first run i mean, that timed out, can you repro it?13:44
zygalooks like we block somewhere early on13:44
zygano, only during reboot13:44
zygawhen we start up13:44
zygamaybe sanity check mount thing?13:44
zygagosh I hate patching packaging13:47
zygaquilt is the monumental suck13:47
mvozyga: yes, sorry for the delay13:48
zygano worries :)13:48
zygaI'm adding more debugging13:48
zygabut ideas welcome13:48
zygaif you want we can HO13:48
mvozyga: pstolowski|afk is not around this week13:49
zygai see13:49
mvozyga: I'm looking at the backlog - do you have a short summary hwat the issue is?13:50
mvozyga: aha, start operation timed out?13:50
zygasnapd works fine13:50
zygaon reboot it just hangs13:50
zygaswitching to a vt magically unblocks it13:50
zygaadding debug to pinpoint where13:50
zygano more ideas13:50
mvozyga: on reboot only? or on stop as well?13:50
zygaon boot up13:51
zyganot shutdown part of reboot13:51
mvozyga: oh, on bootup - how strange13:52
zygamvo: I pushed all the patches to salsa13:52
zygaI can also share a .deb for debugging13:52
mupPR snapcraft#2446 opened: Update schema/snapcraft.yaml <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/2446>13:52
zygaadded more and running another build now, ~~ 20 minutes till results show up13:53
mvozyga: can you set SNAPD_DEBUG=1 in /etc/environment13:53
zygaI did13:53
zygathe log above was with that in place13:53
mvozyga: oh13:53
zygaright? curious13:53
mvozyga: so nothing between Starting ... and timeout :/13:53
zygamy hunch is on mount13:53
zygawe'll ee13:54
zygasee, gosh keyboards13:54
mvosty 22 14:41:30 debian-10 systemd[1]: Starting Snappy daemon...13:54
mvosty 22 14:42:35 debian-10 snapd[1040]: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network13:54
Chipacazyga: can you dump "systemd-analyze --plot" somewhere?13:54
mvozyga: well, second start takes 1m05 until output13:54
zygaon it13:54
mvozyga: so strange13:54
zygamvo: it starts only after I switch vt13:54
Chipacazyga: also systemd-analyze blame13:54
mvozyga: strace would be great, but I guess thats hard - or could you ssh into it?13:55
zygamvo: I'll try13:55
zygapastebinit broken on debian13:56
zygaI hate that it just doesn't work on fedora / debian normally13:56
Chipacazyga: snap it :-D13:56
mborzeckizyga: huh, broken even for paste.debian.net?13:57
zygamborzecki: echo broken | pastebinit13:57
zygait's broken if that doesn't work13:57
zygait doesn't work13:57
zygaif you have to configure it it is broken13:57
Chipacamborzecki: this being debian, I assume it needs post-install tweaking to work13:57
Chipacazyga: doesn't snapd have after: snapd.seeded?13:58
Chipacaor was snapd.seeded a snapd thing13:58
mvozyga: journalctl -u snapd.seeded?13:59
mborzeckisnapd.seeded pokes snapd13:59
zygai cannot paste the .svg file13:59
zygabecause reasons on pastebin13:59
Chipacaah, seeded is after=snapd13:59
Chipacaso snapd does not need seded, indeed13:59
Chipacazyga: copy it to people.c.c (or dump it in your lab :-) )14:00
* Chipaca stands up14:00
Chipacaand then?14:00
mborzeckimaybe it's slow key generation?14:00
mborzeckissh is also slow to start14:00
zygassh is slow yes14:00
zygano idea14:00
zygathat's for snapd.seeded.service14:02
Chipacazyga: how's your random pool?14:09
zygaChipaca: hard to say but that kernel seems to log and hand out randomness that's not really random14:10
zygalet me reboot and see14:10
Chipacazyga: sysctl kernel.random.entropy_avail14:10
zygabooting now14:11
zygathank for the tip :)14:11
Chipacazyga: maybe in a ExecStartPre14:11
zygait's possible14:11
zygathat it was it14:11
zygaand by logging in on vt3 I add entropy14:11
mborzeckihaha omg :)14:11
Chipacathat would also explain ssh being slow14:12
zygaafter logging in I got 86114:12
mborzeckizyga: can you prepare a new machine and install heaveged on it?14:12
zygainstall what?14:12
zygastarted after adding more debugging  https://www.irccloud.com/pastebin/9oE0zyy1/14:13
zygamborzecki: sure, I can clone this machine14:13
zygaand see if that helps14:13
mborzeckibtw. multipass ought to be using virtio-rng too (probably is)14:13
zygathis is vmware14:13
mupPR #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
Chipacazyga: did you add the ExecStartPre line?14:38
zygahold on, not yet14:40
popeyHm, 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 file14:43
popeyI wonder why snapcraft does that?14:43
popeywhy not copy it to snapname.png to match the desktop file?14:44
Chipacapopey: 'old on14:45
Chipacapopey: that's the icon _of the snap_14:45
Chipacapopey: there aren't desktop files for snaps14:45
Chipacapopey: it's separate from the icon for the apps in the snap, which are referenced from desktop files14:46
Chipacapopey: for example if you were packing an office suite, the icon for the suite would be distinct from the icons for each component application14:46
popeyis that because i put the icon: outside the apps: ?14:47
Chipacapopey: 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
popeywould it work if I put icon: in the apps: stanza?14:47
Chipacapopey: snaps don't yet know about per-app icons (desktop files do)14:47
popeywhy is this so hard :(14:47
Chipacapopey: if it were easy, ubuntu wouldn't exist14:47
Chipacathe reason distributiosn exist is ebcause this stuff is hard :-)14:48
popeyi 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 icon14:48
Chipacaalso typing is hard14:48
popeyright, but I thought we were supposed to be making this easier14:48
popeythis isn't easier, it's brutal14:48
Chipacapopey: we try14:48
Chipacapopey: doesn't the desktop file get included in the snap already?14:48
mborzeckizyga: a thought, could it be that we regenrate security profiles?14:49
zygaIn a call14:49
popeythe desktop file is included if i use desktop: to point to it, sure14:49
popeyah well.14:49
Chipacamaybe snapcraft should have per-app icons? but not sure what it'd to with them other than copy them14:50
Chipacadoes 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
popeyok, i have bodged it for now by editing the desktop file14:51
zygamborzecki: I checked that, we just don't get started15:01
zygamborzecki: so it's not that15:01
zygamborzecki: i added a patch with extra debug logs around startup15:01
zygamborzecki: in the end it was entropy15:01
zygajust hitting random keys is enough to boot instantly without any timeouts15:01
zygaI will have some food now and then get back to releasing this properly15:02
diddledanwho rocks your socks?!?15:06
diddledanme! I rock your socks! *chants* I rock your socks. I rock your socks. Ess Oh See Ess.15:07
diddledanI mean Ess Oh See KayEss15:08
Chipacadiddledan: https://www.reddit.com/r/Jokes/comments/1pbq6b/a_spanish_man_who_spoke_no_english_went_into_a/15:11
mvozyga: I did some smoke testing with the debian deb and all is looking well, will try to run autopkgtest now too15:26
Chipacamvo: is this on your top secret debian box with a nuclear RNG15:27
jdstrandroadmr: hi! would you mind pulling the review-tools r1178?15:34
jdstrandroadmr: and happy new year :)15:34
roadmrjdstrand: hello! Sure, I'll queue that. Happy new year to you too!15:34
jdstrandroadmr: thanks. no rush15:35
zygamvo: thank you15:49
mvozyga: autopkgtest is tricky, but I have not given up yet15:52
zygado you mean more than sbuild --run-adt15:52
* cachio lunch15:53
mvozyga: I wanted to run it in a separate vm, but I can try the other option too15:54
* zyga resumes work in the office16:02
Chipacamvo: how are we for point releases of 2.37? anything going on there?16:05
zygamvo: I added a trello card as we talked16:12
zygamvo: I feel it would be nice to have a "process" card16:12
zyganot a feature, not a bug16:12
zygaI mean, card label16:12
zygaoh, I see there are now two cards, sorry for not looking earlier16:13
mvoChipaca: I think we will have a .1 release but no firm plans yet, it looks pretty good so far16:17
mupPR # closed: core-build#11, core-build#22, core-build#26, core-build#3716:21
mupPR # opened: core-build#11, core-build#22, core-build#26, core-build#3716:22
Chipacamvo: I'll tag a low-priority pr for 2.37 then, but no biggie if it doesn't make it16:22
om26erIs 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
om26erfound on: https://www.ubuntu.com/download/iot/raspberry-pi-2-316:23
mvoChipaca: sounds good, is it up yet?16:23
Chipacamvo: no16:23
Chipacamvo: writing tests16:23
om26erafaik, Pi3 UbuntuCore 18 image ships Linux 4.15 (which is new enough?)16:23
mvoChipaca: ta16:27
mvoom26er: 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 accurate16:28
cwayneIt's not accurate16:28
mvocwayne: ok, thank you16:34
mvodegville: 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
degvillemvo: I don't know for certain, but I can likely find the repo and create a PR to get it changed.16:37
mvopopey: *cough* thank you16:38
mvodegville: nevermind, thanks to popey I found the "bugreport" thing, I will just paste the irc conversation16:38
degvillemvo: ok, cool.16:39
degvillemvo / 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
mvocwayne, om26er https://github.com/canonical-websites/www.ubuntu.com/issues/457716:41
mvodegville: -^16:41
om26erthanks mvo16:42
mvoom26er: thank you for reporting this16:42
mvozyga: autopkgtest in a full debian sid vm running, fingers test16:43
mupPR snapd#6411 opened: cmd/snap: wrap "summary" better <Created by chipaca> <https://github.com/snapcore/snapd/pull/6411>16:43
zygamvo: super, fingers indeed crossed :)16:43
Chipacapopey: https://github.com/snapcore/snapd/pull/6411#issuecomment-45647287916:49
mupPR #6411: cmd/snap: wrap "summary" better <Created by chipaca> <https://github.com/snapcore/snapd/pull/6411>16:49
Chipacamvo: ^ that's the thing I think wouldn't be bad in 2.37.116:50
mvoChipaca: ta16:51
Chipacamvo: did you get a chance to look at #6389 ?16:53
mupPR #6389: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <https://github.com/snapcore/snapd/pull/6389>16:54
zygamvo: I'm trying to recall the passphrase to my gpg key :|16:56
Chipacazyga: was it "Vishok7oc,"16:57
* Chipaca has apg and knows how to use it16:57
zygaeh, I wish I used this more often16:58
zygagot it :)17:03
zygaand published (I changed the expiry date)17:06
sparkiegeekhmm, what's the bug for SRUing snapd 2.37 into e.g. Bionic?17:10
mupBug #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
sparkiegeekzyga: thanks17:11
sparkiegeekah, was hidden from search because the main task is Fix Released17:12
=== ricab is now known as ricab|bbiab
=== ricab|bbiab is now known as ricab
jdstrandmvo: 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
zygajdstrand: (responding in place of mvo): I think we are open to a 2.37.117:45
zygajdstrand: the point of 2.37 now is to hit debian17:45
jdstrandok, well, I'll pick that up then and target both master and 2.3717:48
zygaif you target master I think we can cherry pick, as long as you tag them as 2.3717:49
mvojdstrand: should hopefully be trivial, master and 2.37 are not that different yet17:59
* zyga EODs18:06
jdstrandmvo: yeah, wasn't worried about that-- just wanted to understand your timing. thanks!18:37
mupPR 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
mupPR 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
mupPR 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
mupPR 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
roadmrjdstrand: hi! hey I notice the base declaration added two interfaces (personal-files and system-files). Do these count as "superprivileged" ones?19:47
roadmrjdstrand: 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 expected19:47
jdstrandroadmr: they are superprivileged,19:49
jdstrandin terms of the base decl, they follow that same pattern19:49
roadmrjdstrand: ok, so this seems to be copacetic then. I'll go ahead with the merge, thanks!19:51
jdstrandroadmr: cool, thanks!19:56
=== phoenix_firebrd is now known as murthy
mupPR 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!