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