[00:22] <zyga> I'll EODnow
[00:22] <zyga> tests in spread are more comprehensive
[00:22] <zyga> tomorrow I'll rebase on master and propose
[02:31] <cachio> ijohnson, nice, thanks
[06:28] <zyga> Uh
[06:28] <zyga> Tired
[06:38] <mborzecki> morning
[07:48] <zyga> hey
[07:48] <zyga> oooh
[07:48] <zyga> my tests passed
[07:48] <zyga> mborzecki: I massaged that silly session tool more
[07:48] <zyga> mborzecki: and learned a few interesting things along the way
[07:48] <mborzecki> zyga: hey
[07:49] <zyga> mborzecki: for instance, certain invocations of su/sudo spawn all the session services
[07:49] <zyga> mborzecki: and that may include pulseaudio, bluetooth, gpg daemon, apt daemon and a hell lot more
[07:49] <zyga> mborzecki: and they stick around
[07:49] <zyga> mborzecki: they are shut down asynchronously, roughly 10-20 seconds later
[07:50] <zyga> mborzecki: I think this could explain some cases of tests seeing weird processes
[07:50] <mborzecki> hahah
[07:50] <zyga> what is worse is that this is per-distro
[07:50] <zyga> it depends on PAM configuration
[07:50] <mborzecki> how come it evolved to be so complex
[07:50] <zyga> the upside is I know how to handle that
[07:50] <zyga> but it's not clear how to handle that for root
[07:50] <zyga> for non-root that's just loginctl kill-user test
[07:51] <zyga> for root I think we could enumerate sessions, kill all but the ssh incoming remote session
[07:51] <zyga> that would reliably shut stuff we run between invocations
[07:51] <zyga> _except_ if that populates the remote session
[07:51] <zyga> then we're SOL
[07:54] <mborzecki> in the meantime i'm trying differnt daily images in hope of triggering https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1865063
[07:54] <mup> Bug #1865063: snapd package hangs on deb postinst <focal> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1865063>
[07:54] <zyga> mborzecki: ready for the sprint?
[07:55] <zyga> oh
[07:55] <zyga> I remember hearing about it
[07:55] <zyga> mborzecki: what does postinst do?
[07:55] <zyga> mborzecki: could this be arm64?
[08:02] <pstolowski> morning
[08:02] <zyga> hey
[08:02] <zyga> is master better
[08:03] <zyga> I heard some horror stories from yesterday
[08:04] <mborzecki> hmm nothing super werid about postinst
[08:05] <zyga> mborzecki: does it interact with snap?
[08:05] <zyga> as in, run anything that would have it wait for snapd that's panicking
[08:07] <zyga> I stopped working at 2AM
[08:07] <zyga> please don't expect me to be around much today
[08:07] <zyga> I need to prepare for the sprint, specifically the apparmor prompting demo needs some work
[08:07] <mborzecki> zyga: no not really, there's services started ofc, so unless snapd was stopped it will be started on install and may do things it does on startup, like rebuilding seccomp profiles etc
[08:07] <zyga> and I have a haircut at 10:30
[08:08] <mborzecki> wow, haircut? :)
[08:08] <zyga> mborzecki: anything in autogen postinst?
[08:08] <zyga> mborzecki: I call it yak shaving
[08:09] <zyga> hmmm
[08:09] <zyga> mborzecki: and speaking of PAM
[08:10] <zyga> mborzecki: my test passed everything but debian
[08:10] <zyga> both sid and 9 hang
[08:10] <zyga> time to debug
[08:10] <zyga> oh well
[08:10] <zyga> I'll go upstairs and make another coffee
[08:10] <zyga> I feel so sleepy still
[08:10] <zyga> daughter woke me up at 6:40 by kicking me in the head
[08:22] <mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/8083 ?
[08:22] <mup> PR #8083: spread, data/selinux: add CentOS 8, update policy <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
[08:23] <mborzecki> hope we could land it today, as there's some selinux fixes included
[08:43] <mborzecki> mvo:  hey
[08:46] <mvo> hey mborzecki
[09:08] <zyga> mborzecki: yep
[09:09] <pedronis> hi, #7999 and #8185 need 2nd review.  #8185 shows some problems with test/mock code org, but I don't think it should be blocked on that.
[09:09] <mup> PR #7999: devicestate: allow encryption regardless of grade <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7999>
[09:09] <mup> PR #8185: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8185>
[09:10] <pedronis> see my comment here: https://github.com/snapcore/snapd/pull/8185#discussion_r385579873
[09:10] <zyga> mborzecki: done
[09:11] <zyga> I'm off for a yak shaving session
[09:11] <zyga> o/
[09:30] <zyga> zyga.shave()
[09:31] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/8083 ?
[09:32] <mup> PR #8083: spread, data/selinux: add CentOS 8, update policy <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
[09:32] <mborzecki> pstolowski: there's some selinux bits in there
[09:32] <pstolowski> mborzecki: will do
[09:32] <mborzecki> pstolowski: thanks!
[10:03] <pedronis> mborzecki: hi, I made an high-level comment in #8191
[10:03] <mup> PR #8191: [RFC] cmd/snap-recovery-chooser: add a recovery chooser <Needs Samuele review> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8191>
[10:05] <mborzecki> pedronis: thanks, it's totally up for discussion, we can surely brainstorm in FRA
[10:09] <pedronis> mborzecki: ok, also to clear we quite likely will need that kind of JSON I described somewhere in snapd, because snapd will a API endpoint to list the recovery systems
[10:09] <pedronis> *will have
[10:27] <pedronis> #8187 also needs a 2nd review
[10:27] <mup> PR #8187: boot: misc UC20 changes <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8187>
[10:39] <mup> PR snapd#8083 closed: spread, data/selinux: add CentOS 8, update policy <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
[10:39] <mborzecki> mvo: can you cherry-pick the patch? ^^
[10:39] <zyga> re
[10:39] <zyga> I think I know why debian is failing now
[10:40] <zyga> awk/gawk probably
[10:40] <mvo> mborzecki: yes, thank you!
[10:40] <zyga> running a test to confirm
[10:40] <zyga> I'll take a shower, my face is full of sharp pieces of hair
[10:40] <mvo> mborzecki: done
[10:42] <mborzecki> mvo: thanks!
[10:47] <mup> PR snapd#8214 opened: tests: test that after "remove-user" the system is unmanaged <Created by mvo5> <https://github.com/snapcore/snapd/pull/8214>
[11:05] <ogra> zyga, sorry, i was at embeddedworld this week, i havent used snapd-docker for a long time, technically it should still work, practically i think some defaults would need updating (IIRC it points to old releases etc)
[11:11] <pedronis> mvo: hi, still fixing tests issues?  as I mentioned there are UC20 things needing 2nd review, but maybe mborzecki is on those already
[11:13] <mvo> pedronis: in a meeting right now, was mostly on tests+2.44 cherry-picks today
[11:16] <mborzecki> pedronis: i've updated 8187, looking at 8185 now
[11:16] <pedronis> thx
[11:18] <mborzecki> zyga: so review tools is updated now?
[11:18] <zyga> mborzecki: dunno, I didn't hear anything about that
[11:19] <pedronis> mborzecki: updated for which issue?
[11:19] <pedronis> I think it has been updated for the setgid changes
[11:19] <mborzecki> pedronis: snapd setgid
[11:19] <zyga> shall we merge the revert then?
[11:21] <pedronis> in principle yes,  but really for mvo to decide, I see the PR is running tests atm, #8181
[11:21] <mup> PR #8181: packaging: revert "work around review-tools and snap-confine" <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8181>
[11:22] <mborzecki> pedronis: yeah, restated them just now, fwiw the change looks ok
[11:28] <mup> PR snapd#8215 opened: interfaces: make the network-status interface implicit on classic <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8215>
[11:32] <mborzecki> pedronis: heh, missed that odd wording thing when i moved the comments around
[11:37]  * pstolowski early lunch and sprint-related errand
[11:41] <mvo> pedronis, zyga +1 for reverting the setgid change
[11:41] <mborzecki> interestin failure with nonce is invalid https://paste.ubuntu.com/p/6F9z9rWZDy/
[11:41]  * zyga debugs the debian issue
[11:42] <zyga> easy to repro, just unclear why it hangs in something that passes elsewhere
[11:44] <mborzecki> heh when POSTing to /api/v1/snaps/auth/sessions there's sometimes 503 service unavailable recived back
[11:46] <zyga> so it's not mawk vs gawk
[11:46] <zyga> something more subtle ...
[11:49] <zyga> huh
[11:49] <zyga> NOW it works?
[11:49] <zyga> what did I fix
[12:03] <popey> https://forum.snapcraft.io/t/error-cannot-communicate-with-server-timeout-exceeded-while-waiting-for-response/15726
[12:03] <popey> :(
[12:04] <zyga> popey: that log is cut
[12:04] <zyga> could you get more with journalctl -u snapd.service please
[12:04] <zyga> ideally
[12:04] <popey> ok
[12:04] <zyga> journalctl -u snapd.service -o ... # e.g. -o cut
[12:04] <zyga> or something similar
[12:04] <zyga> this should give you all the logs
[12:04] <popey> sorry, give me one command
[12:04] <zyga> sure, one sec
[12:05] <zyga> sudo journalctl -u snapd.service -o short | cat
[12:05] <zyga> that ought to work
[12:05] <popey> i do not believe you will learn more from that output :D
[12:06] <popey> but okay :D
[12:06] <zyga> popey: current output is cut
[12:06] <zyga> but also, memory 1.7G
[12:06] <zyga> ouch :/
[12:07] <popey> ok, added to the forum post
[12:07] <zyga> popey: does snap version now work?
[12:08] <popey> snap version always worked
[12:08] <popey> snap refresh didnt
[12:08] <zyga> ok
[12:08] <zyga> just checking id daemon is up
[12:09] <zyga> how many snaps do you have?
[12:09] <popey> 311
[12:10] <popey> how many do you have? :)
[12:10] <mup> PR snapd#8203 closed: netlink: fix panic on arm64 with the new rawsockstop code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8203>
[12:10] <zyga> popey: about a dozen per system
[12:10] <zyga> popey: I think this is a real bug, just one we are not experiencing ourselves :)
[12:10] <pedronis> we have performance improvements related to systems with many snaps coming this cycle thanks to changes the store is doing, but nothing immediate
[12:10] <zyga> I guess the client times out, waiting for snapd to compute the response
[12:11] <popey> oh dear
[12:11] <zyga> popey: can you snap refresh foo # replace foo with one snap
[12:11] <mborzecki> zyga: yeah, that'd be my guess, that's the client deadline context bit
[12:11] <mup> PR snapd#8181 closed: packaging: revert "work around review-tools and snap-confine" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8181>
[12:11] <mborzecki> iirc the deadline is quite generous though, 10s or so
[12:11] <pedronis> popey: how big is your state.json for reference
[12:12] <zyga> but that's weird, everything is async
[12:12] <zyga> it must be slow to get the ansync response!
[12:12] <pedronis> mborzecki: for historical and complexity reasons we do some things synchronously in the refresh case, it's an issue, it will improve a bit this cycle
[12:13] <popey> 1269004
[12:14] <zyga> popey: if you gzip it, how big would it be?
[12:14] <zyga> anyway, that's probably not going to help
[12:14] <pedronis> it's not the problem anyway, not mainly
[12:14] <pedronis> here
[12:14] <popey> 183847
[12:15] <zyga> right, I suppose we block on O(N) requests somehow
[12:16] <pedronis> zyga: yes, the bulk assert refresh work will help here
[12:35] <zyga> hmmm
[12:35] <zyga> I managed to reproduce a hand once on my machine
[12:35] <zyga> then it's gone
[12:35] <zyga> reproduces ok in spread
[12:35] <zyga> ... what am I missing
[12:47] <zyga> now it breaks on focal
[12:47] <zyga> ok, feels like it's buffering
[12:47] <zyga> added fflush
[12:47] <mup> PR snapd#8173 closed: tests: adding arch-linux execution <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8173>
[12:49] <popey> I found a workaround
[12:49] <popey> https://forum.snapcraft.io/t/error-cannot-communicate-with-server-timeout-exceeded-while-waiting-for-response/15726/3
[13:05] <ogra> popey, sosumi ?!? wow !
[13:05]  * diddledan sues ogra
[13:05] <popey> hah
[13:06] <diddledan> live feed of new snaps as they appear: https://twitter.com/snapstats_org :-)
[13:06]  * diddledan promotes
[13:07] <diddledan> it's on a 30minute cycle
[13:07] <diddledan> so the longest you'll be behind live is 29 minutes :-)
[13:08] <popey> the day it gets overwhelmed in a 30 min period is a good day :D
[13:08] <diddledan> aye. usually only one or two snaps per weekday
[13:09] <popey> rarely zero per day
[13:09] <popey> there was a day recently when something like 22 landed in the store
[13:09] <diddledan> wow
[13:10] <diddledan> the graph is fairly linear: https://snapstats.org/
[13:11] <diddledan> those are weekly ticks
[13:17] <zyga> diddledan: what are "developer counts"?
[13:17] <zyga> number of developers publishing snaps?
[13:17] <diddledan> the number of developers that have a published snap
[13:17] <zyga> oh wow
[13:17] <diddledan> i.e. the number of unique developer names on publicly visible snaps
[13:18] <zyga> I wished for 2^X but
[13:19] <mborzecki> diddledan: nice!
[13:19] <diddledan> thanks :-)
[13:19] <mborzecki> diddledan: how often is the snap count updated? daily?
[13:19] <diddledan> every 30 minutes
[13:20] <diddledan> but then it gets thinned out to one per day
[13:20] <diddledan> ... at the end of each day
[13:20] <ogra> hmm, who is admin on the forum ? i would like to edit the pi4 thread to remove the links to my experimental images (and point to the new official ones) but i seem not to be able to edit my own posts there
[13:21] <zyga> ogra: hmmm
[13:21] <zyga> not sure
[13:21] <diddledan> I suspect popey can do that?
[13:21] <zyga> mvo: ^
[13:21] <diddledan> mvo would know for sure. good call.
[13:21] <popey> link?
[13:22] <diddledan> this one? https://forum.snapcraft.io/t/raspberry-pi-4-chromium-mir-kiosk/15725
[13:22] <popey> dont think so
[13:22] <diddledan> oh no. not that one
[13:22] <diddledan> https://forum.snapcraft.io/t/support-for-raspberry-pi-4/11970/4 ?
[13:23] <ogra> right ...
[13:23] <popey> you know what would be better
[13:23] <popey> put a readme in that folder and move the content out the way
[13:23] <diddledan> speaking of pis. you see they dropped the 1GB model and reduced the 2GB price?
[13:23] <ogra> yeah, i wanted to do that additionally
[13:24] <ogra> but most people might find the thread so i wouldnt want to detour them through people.c.c
[13:24] <diddledan> https://www.raspberrypi.org/blog/new-price-raspberry-pi-4-2gb/
[13:24] <popey> but people might find people.c.c too
[13:25] <ogra> yes, thats why i wanted to do it there additionally :)
[13:25] <zyga> hey
[13:25] <ogra> (do it: update readme etc)
[13:25] <zyga> tests passed!!!
[13:25] <zyga> awk is such a beast
[13:25] <ogra> use sed :P
[13:25] <diddledan> tests? pass? that's unpossible!
[13:25] <diddledan> there must be something wrong
[13:25] <ogra> awk is just for people that fear sed :)
[13:26] <zyga> diddledan: I was telling myself that for a few hours
[13:26] <popey> i have marked Steve's most recent post as "solution" so it's right at the top
[13:26] <popey> which should help
[13:26] <ogra> +1
[13:27] <ogra> i have never tried to edit such an old post, is it normal that it loses editing capabilities over time ?
[13:28] <popey> i guess
[13:28] <popey> discourse be discourse
[13:28] <ogra> hmpf ..
[13:46] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8216
[13:46] <mup> PR #8216: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
[13:46] <zyga> I think I cannot believe this really works
[13:46]  * zyga runs more tests
[13:46] <mup> PR snapd#8216 opened: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
[13:53] <ijohnson> pedronis: sorry I didn't finish those docs yesterday, please take a look at the booting doc again I finished the expected kernel mounting section just now
[13:54] <ijohnson> pedronis: also I went back and move some things that were in yellow in the boot envs doc to actual sentences and such in the "Run /var/lib/snapd/modeenv" section
[13:55] <mup> PR snapd#8187 closed: boot: misc UC20 changes <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8187>
[14:17] <ogra> zyga, https://forum.snapcraft.io/t/requesting-uninstall-reason-via-popup/15655 ... shouldnt the teardown of the namespace on uninstall kill all processes and their kids ?
[14:17] <zyga> in a call
[14:18] <zyga> I'll check soon
[14:27] <zyga> cmatsuoka: that was the bult-in laptop mic
[14:27] <zyga> cmatsuoka: I often use the external mic
[14:27] <zyga> cmatsuoka: and I sometimes use the built-in imac mic
[14:31] <ijohnson> ogra: could be a bug with systemd timers that are created for snaps
[14:36] <cmatsuoka> zyga: the sound quality was quite good frequency-wise, but it picked some background noise
[14:36] <mborzecki> https://www.reddit.com/r/linux/comments/fa8ewy/ubuntu_2004_lts_to_revert_gnome_calculator_and/ heh
[14:37] <diddledan> regarding that link, zyga, and ogra, does snapd not set up a cgroup to collect a snap's processes and kill the cgroup when it removes a snap?
[14:38] <zyga> diddledan: no
[14:38] <zyga> diddledan: not yet
[14:38] <diddledan> aah. that's coming?
[14:39] <zyga> diddledan: not exactly that
[14:39] <zyga> diddledan: we cannot kill some
[14:39] <diddledan> oh, I see
[14:39] <zyga> diddledan: because of compatibility
[14:39] <zyga> diddledan: but we can probably kill most (all desktop apps)
[14:39] <diddledan> bah. compatibility be damned :-p
[14:40] <zyga> diddledan: what will more likely happen is reverse
[14:40] <zyga> diddledan: snapd will tell you "you cannot remove this snap because it is still running"
[14:40] <zyga> diddledan: close "app foo" and try again
[14:40] <zyga> diddledan: this is compatible and in line with other work
[14:41] <diddledan> regarding uninstall surveys. if we want to support such a feature we could add a snap.yaml field for "uninstall url" that fires up the system web browser or prints the url on the terminal for non-gui installs
[14:41] <diddledan> that makes sense. I like that, rather than just killing stuff, give the user the choice
[14:42] <diddledan> I think uninstall surveys are a bit of an antipattern though
[14:42] <ogra> as long as there is also a --force option for admins that dont want to give heir users choices ;)
[14:43] <diddledan> I see them as the developer saying "I've annoyed you enough to make you uninstall my app. let me annoy you even more with this obnoxious survey."
[14:44] <diddledan> I get that the developer wants to understand what they did wrong. but an uninstall survey is the wrong way IMO
[14:45] <diddledan> however, snap needs to be pragmatic, and it is a common enough pattern that we might be wise to bend to the will
[14:52] <ijohnson> IMHO people should be able to uninstall snaps without going through a survey
[14:52] <ijohnson> OTOH, we should at least enable that use case for developers that want it
[14:52] <diddledan> that's my view, ijohnson
[14:52] <ijohnson> yeah agreed diddledan
[14:52] <ijohnson> not sure what the right technical solution is though
[14:52] <diddledan> stop stealing my ideas. get your own ;-p
[14:53] <ijohnson> haha but it's so hard to think on my own
[14:53] <diddledan> I hear that!
[14:53]  * diddledan goes to find a sheep to follow
[14:53] <roadmr> 🐑
[14:54] <diddledan> aww, that emoji doesn't work here :-(
[14:54] <diddledan> looks to be brave-specific failure thouhg
[14:55] <diddledan> it works fine in my terminal
[14:55] <roadmr> :(
[14:55]  * diddledan tries firefox
[14:55] <ijohnson> diddledan: do you use the lounge snap thing I seem to remember you worked on a while ago?
[14:55] <diddledan> yes, I do
[14:55] <ijohnson> seemed really cool but I haven't given it a try yet
[14:55] <diddledan> I'm chatting in it right now o/
[14:56] <diddledan> popey and Wimpress did a great job enabling ssl/tls support the other day
[14:56] <ijohnson> nice
[14:56] <diddledan> which means that if you access it through a mobile device you can enable push notifications
[14:57]  * cachio lunch and school
[15:32] <zyga> re
[15:34]  * zyga had a bowl of żurek for dinner
[15:37] <mup> PR snapd#8170 closed: snap-preseed: support for preseeding of snapd and core18 <Preseeding 🍞> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8170>
[15:57] <pedronis> ijohnson: I made some suggestion and add some bits to the doc
[15:57] <zyga> ijohnson: thank you for the review!
[15:58] <ijohnson> thanks pedronis looking now
[15:58] <ijohnson> yaw yga
[15:58] <ijohnson> zyga
[16:21] <mup> PR pc-amd64-gadget#38 opened: grub.cfg-recovery: fix typo, filter vars when loading them <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/38>
[16:25] <zyga> ijohnson: check this out :) https://github.com/snapcore/snapd/pull/8216/files#diff-a8fce2de6a6829d98f798117050b6c93R59
[16:25] <mup> PR #8216: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
[16:26] <ijohnson> zyga: ah much easier to read thanks
[16:26] <zyga> it's not a heredoc but has the same property
[16:26] <zyga> just a multi-line value :)
[16:26] <ijohnson> yes multi-line is what I was after, heredoc was just the first thing I could think of that was multi-line :-)
[16:46] <zyga> I want to make sure this really works
[16:46] <zyga> spawned this test across the fleet, with ... -repeat 100
[16:46] <zyga> it's a quick test
[16:46] <zyga> but this gives me more confidence
[16:46] <zyga> brb, coffee
[16:55] <zyga> back
[16:55] <zyga> daughter asleep :)
[16:55] <zyga> so quiet upstairs
[16:56] <zyga> let's try to solve the issue I've built this for :)
[17:10] <zyga> holly molly
[17:10] <zyga> zyga@focal:~/go/src/github.com/snapcore/snapd/tests$ git grep 'su -l' | wc -l
[17:10] <zyga> 114
[17:10] <zyga> that's a lot of tests to fix
[17:10] <zyga> ijohnson: ^
[17:11] <ijohnson> oh boy
[17:11] <zyga> there's one interesting thing
[17:11] <zyga> linger
[17:11] <ijohnson> linger?
[17:11] <zyga> https://www.freedesktop.org/software/systemd/man/loginctl.html < check for "linger"
[17:11] <zyga> Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services. Takes one or more user names or numeric UIDs as argument. If no argument is specified, enables/disables lingering for the user of the session of the caller.
[17:11] <zyga> it means we'd have a "test" user session that we can always hop into
[17:12] <ijohnson> ah seems cool
[17:12] <zyga> probably faster than spawning and shutting one for each command
[17:12] <zyga> I'll explore some more
[17:12] <zyga> I wonder if this means I can ssh into a system
[17:12] <ogra> pfft ... ln -s /usr/bin/nohup /usr/bin/linger
[17:12] <zyga> start a systemd user session
[17:12] <ogra> :P
[17:12] <zyga> and log out
[17:13] <zyga> and log in
[17:13] <zyga> and it's still there
[17:13] <zyga> with all dbus stuff and all the other good bits
[17:13] <zyga> ogra: that's so 90s :-)
[17:13] <ogra> :D
[17:13] <zyga> ogra: for context: https://github.com/snapcore/snapd/pull/8216
[17:13] <mup> PR #8216: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
[17:13] <zyga> ogra: you'd be proud of me, it's shell
[17:14] <zyga> and awk
[17:14] <zyga> and not even bash
[17:14] <zyga> and works with mawk
[17:14] <ogra> well, awk always makes me shudder :)
[18:07] <mtlsw> hi guys, I have two users, 1 has customizations(my account) and another has no activity(newly created) -- theres' a snap app that runs well on both but only on the first instance.  Is there a "log" for snap?
[18:43] <pedronis> ijohnson: I don't think I'll get to propose the separation of responsabilities between boottest and bootloadertest today, it's a bit more involved than I had hoped
[18:49] <ijohnson> pedronis: ok, safe travels, see you on Monday
[19:25] <NickZ> How do I set up an org on snapcraft.io?
[19:25] <mup> PR snapd#8205 closed: tests: just remove user when the system is not managed on create-user-2 test <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8205>
[20:15] <Lukewh> NickZ: orgs don't exist in the snap store. You can create an account, register snaps with that account and add other accounts as collaborators. They will have complete access, but the org will be listed as the publisher
[20:16] <NickZ> Right, I just figured that out
[20:16] <Lukewh> :)
[20:16] <Lukewh> sorry for the late reply
[20:19] <zyga> https://github.com/snapcore/snapd/pull/8216 is green :)
[20:19] <mup> PR #8216: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
[20:20] <diddledan> zyga, something must be wrong. I don't trust passing tests
[20:21] <zyga> I ran that new tests across all enabled backends 100 times, it passed
[20:21] <diddledan> the worst tests are the ones that pass first time out of the box
[20:21] <zyga> it's so weird
[20:21] <zyga> (after finding edges that broke in this for the past week)
[20:21] <zyga> diddledan: this one _eventually_ got to work, I spent far too much time on this tool
[20:21] <diddledan> :-)
[20:51] <fundatillus> I have one snap that won't start on my system and I receive no errors.
[20:51] <fundatillus> The snap is standard-notes, but all others work (atom, chromium, signal, etc).
[20:52] <fundatillus> I've reverted and also switched to --edge with no luck.
[20:52] <fundatillus> Any tips on troubleshooting?
[20:52] <fundatillus> Also removed and reinstalled.
[20:53] <fundatillus> My Google-fu is failing me...
[20:53] <mvo> fundatillus: can you check in "dmesg" if you see andthing that looks like "denials"
[20:54] <diddledan> fundatillus, try running `standard-notes` in the terminal - I'm seeing an error here when I do that
[20:54] <diddledan> specifically: Error: ENOENT: no such file or directory, open '/home/dllewellyn/snap/standard-notes/4/.config/Standard Notes/user-preferences.json'
[20:55] <fundatillus> I'm not seeing any denial messages.
[20:56] <diddledan> oh, the error is only first time - repeated attempts to launch silently fail though
[20:56] <fundatillus> The last entry having to do with standard-notes is about 5000 seconds (?) ago:
[20:56] <fundatillus> [34486.619880] audit: type=1400 audit(1582902701.832:432): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.standard-notes.standard-notes" pid=19147 comm="apparmor_parser"
[20:57] <fundatillus> I've contacted the publisher and they aren't able to duplicate...
[20:57] <fundatillus> I'm running kubuntu 19.10, if that matters.
[21:01] <mvo> fundatillus: I just tried on my 19.10 ubuntu system and it's ok here, sorry that this is not helpful. you could try (in a terminal): "snap run --strace standard-notes" and see if there is anything obvious(ish)
[21:05] <fundatillus> Checking it now... weird, it won't let me redirect it to a file. But there is definitely something going on, exit with code 1
[21:05] <fundatillus> Lots of errors like this:
[21:05] <fundatillus> [pid 25508] openat(AT_FDCWD, "/snap/standard-notes/6/gnome-platform/usr/lib/locale/en_US.UTF-8/LC_NAME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[21:05] <fundatillus> ll
[21:07] <fundatillus> [pid 25704] openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
[21:07] <fundatillus> Looks like it's looking for some locale files?
[21:09] <fundatillus> I'm seeing en and en_US locale directories, but not the en_US.UTF-8 it's looking for...
[21:12] <mvo> fundatillus: exit 1 is good, pasting (to e.g. pastebin.ubuntu.com) the last couple of lines before the exit 1 is probably helpful.
[21:12] <mvo> fundatillus: unfortunately I will have to go to bed soon here in my timezone but hopefully someone else in the channel can help
[21:13] <fundatillus> Thanks mvo. Appreciate the help.
[21:21] <mvo> fundatillus: my pleasure, good luck!
[21:50] <NickZ> jdstrand: did you reserve the freedoom snap name?
[21:51] <diddledan> NickZ, there's a freedoom package in the Ubuntu repository so, yes, it will have been reserved
[21:51] <NickZ> ah, I see
[21:51] <NickZ> I'll just request it
[21:51] <diddledan> bingo :-)
[21:51] <diddledan> unfortunately people are seeing the reserved message and assuming that means they're not allowed to claim it
[21:53] <jdstrand> NickZ: yeah, what diddledan said (and no, I didn't)
[21:53] <NickZ> ah hah, I saw that you had released a chocolate doom snap and I had guessed :)
[21:53] <diddledan> how do you like your hellspawn? covered in chocolate, natch