[00:40] <mup> PR snapcraft#2749 closed: storeapi: add StoreErrorList to handle store errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2749>
[05:23] <mborzecki> morning
[06:40] <mborzecki> zyga: i'm playing a bit with repck in spread, instead of a 5.5MB archive i usually got, i'm getting 2.8MB now
[06:50] <mborzecki> mvo:  morning
[06:56] <mvo> hey mborzecki ! good morning
[06:57] <mup> PR snapd#7582 closed: spread: include mounts list in task debug output <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7582>
[07:04] <pstolowski> morning
[07:05] <zyga> Good morning
[07:05] <zyga> I’ll start later today, just doing morning dog walk
[07:05] <zyga> See you in 30
[07:06] <zyga> mborzecki: try that with spread doing gitignore and the matching snapd branch please
[07:31] <zyga> back
[08:05] <pstolowski> mvo: #7558 can land, or do want to wait for Samuele?
[08:05] <mup> PR #7558: boot,dirs,image: various refinements in the prepare-image code switched to seedwriter <Created by pedronis> <https://github.com/snapcore/snapd/pull/7558>
[08:09] <zyga> mborzecki: I updated https://github.com/snapcore/snapd/pull/7547/files a little
[08:09] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[08:21] <bloodearnest> Chipaca: o/ - FYI, I worked around the this issue with services failing on refresh, and filed this bug for your consideration:
[08:21] <bloodearnest> https://bugs.launchpad.net/snapd/+bug/1847723
[08:21] <mup> Bug #1847723: Config hook is run after services start during refresh <snapd:New> <https://launchpad.net/bugs/1847723>
[08:22] <Chipaca> bloodearnest: what about the different -refresh hooks?
[08:22] <Chipaca> bloodearnest: e.g. post-refresh?
[08:22] <Chipaca> bloodearnest: ISTR post-refresh comes right before start-services
[08:23] <bloodearnest> Chipaca: so, my fix was to regenerate the config in post-refresh in my snap. But I think that that argubly shouldn't be nessesary?
[08:23] <Chipaca> ah i see you mention that i the bug
[08:23] <bloodearnest> yeah
[08:23] <bloodearnest> I'm sure there's things I'm missing, but it was a suprise to me that the config hook ran after services had been started
[08:24] <Chipaca> bloodearnest: I'll let pstolowski and/or pedronis figure out whether the current behaviour is correct or not :-)
[08:24] <bloodearnest> sure, thanks for your time
[08:30] <pstolowski> bloodearnest, Chipaca yes, this (config hook running after services start) has been known for a long time (and we know it's annoying), we touched that briefly with pedronis even recently with the conclusion that we might reconsider the order if there are strong arguments
[08:32] <bloodearnest> pstolowski: great. Well, consider that bug this user's vote on the isssue :) It's a dual of the install/config hook interplay really, where services can start before config hook as run there too.
[08:48] <Chipaca> bloodearnest: OTOH I can imagine snaps with the opposite problem, needing the services running for 'configure' to make sense?
[08:53] <Chipaca> brb, installing eoaiun
[08:53] <zyga> Chipaca: oh my :-)
[08:53] <zyga> I wonder what your experience will be like
[08:53] <Chipaca> zyga: slow
[08:54] <Chipaca> the only machines i have that i'm willing to sacrifice to the goddess eoan are slow
[08:55] <mup> PR snapd#7586 opened: interfaces/optical-drive: additional permission needed by mir-kiosk-kodi <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7586>
[09:00] <mup> PR snapd#7587 opened: spread: generate delta when using google backend <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7587>
[09:01] <mborzecki> zyga: mvo: ^^ this should fix the source package size uploaded by spread for a while
[09:01] <zyga> nice
[09:01] <zyga> thank you
[09:13] <bloodearnest> Chipaca: very possiblly :)
[09:13] <mvo> mborzecki: nice one!
[09:14] <xiaoji> does anyone know How to statistics the number of software in gnome-software
[09:15] <zyga> xiaoji: gnome-software is a tarball, what it shows when you build and run depends heavily on configuration
[09:20] <Chipaca> xiaoji: by "software" do you mean packages? apps? binaries?
[09:20] <Chipaca> xiaoji: and do you mean the number installed, available for install, ...?
[09:21] <Chipaca> xiaoji: and do you mean how many does gnome-software show, or do you mean how do you get gnome-software to show you the number?
[09:27] <xiaoji> thanks
[09:27] <xiaoji> yes
[09:28] <xiaoji> I want to know how many software can be installed and have been installed in gnome-software
[09:28] <mup> PR snapd#7588 opened: cmd/snap: add a "snap internal portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
[09:31] <Chipaca> jamesh: that's not the first internal command we have, any reason to add the new toplevel 'internal', etc?
[09:32]  * zyga installs gobs of updates
[09:33] <Chipaca> xiaoji: why are you asking in this channel?
[09:35] <xiaoji> I have asked on many channel and many IM..
[09:35] <xiaoji> sorry
[09:36] <Chipaca> xiaoji: where?
[09:37] <Chipaca> xiaoji: as zyga pointed at, gnome-software is the frontend to a number of backends, and not all those backends offer a count. Also you haven't told me what "software" is, nor on what distro you are
[09:38] <Chipaca> for example, if "software" is a package, and you are on a debian-derived distro, you can answer "how many are installed" via the backend tools
[09:38] <Chipaca> i guess the same is true for other distros
[09:38] <Chipaca> so it's not clear you know what you are asking
[09:38] <Chipaca> so, how to answer you? your question is unclear, to begin with
[09:38] <xiaoji> I am on ubuntu 18.04
[09:39] <Chipaca> are you using flatpak?
[09:39] <xiaoji> no,only install software from software-center
[09:40] <Chipaca> i thought you could get flatpak via the software-center, but ok
[09:40] <Chipaca> xiaoji: and, what is "software"?
[09:41] <Chipaca> xiaoji: is a library-only debian package, "software"?
[09:41] <Chipaca> xiaoji: is bash "software"?
[09:46] <xiaoji> .. I dont know
[09:47] <Chipaca> xiaoji: ok. Going back a step, why do you want to know statistics about this?
[09:48] <xiaoji> I saw many software in gnome-software,they have icon. I want know how many
[09:51] <mup> PR snapd#7558 closed: boot,dirs,image: various refinements in the prepare-image code switched to seedwriter <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7558>
[09:56] <jamesh> Chipaca: I seem to remember zyga suggesting it during previous discussions, and it seemed like a reasonable idea.  I can remove that part of the PR quite easily though
[09:59] <zyga> jamesh: I still like it
[10:09] <Chipaca> jamesh: i don't think it's a bad idea, and i like the refactor, but i feel it should be separate from the feature
[10:09] <Chipaca> and maybe we should discuss moving other internal commands to this
[10:10] <jamesh> Chipaca: I can split it out easily enough: it's the first commit.
[10:10] <Chipaca> jamesh: neat
[10:10] <Chipaca> jamesh: I'd expect pedronis to have an Opinion about that, and he's off today
[10:10] <Chipaca> just fyi
[10:17] <Chipaca> Wimpress: is there anything like an eoan mate installer already?
[10:19] <Chipaca> facubatista: "eoan mate", https://flic.kr/p/6wqZBC
[10:20] <Chipaca> xiaoji: so, for an approximation
[10:20] <Chipaca> xiaoji: open a terminal, and see if you have the "appstreamcli" command
[10:21] <Chipaca> xiaoji: if you do, then the number of things gnome software offers you is the number in Summary of "appstreamcli status", *plus*, the output of "wc -l /var/cache/snapd/names"
[10:22] <Chipaca> approximately; some things might be counted twice in the above
[10:22] <Chipaca> if you _don't_ have appstreamcli, you need to 'sudo apt install appstream' and then 'sudo apt update' for the number to be right
[10:23] <Chipaca> both numbers should be ~2k or more
[10:23] <Chipaca> although it varies by arch and region
[10:41] <mup> PR snapd#7589 opened: cmd/snap: add ability to register "snap internal" commands <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
[10:50] <Wimpress> Chipaca: Do you mean an iso image for Ubuntu MATE 19.10?
[10:51] <Chipaca> Wimpress: i think i found it at http://cdimage.ubuntu.com/ubuntu-mate/daily-live/current/HEADER.html
[10:51] <Chipaca> heh, dunno why google took me to the header, but ok
[10:51] <Wimpress> Yep, that's what you want 👍
[11:03] <mborzecki> pstolowski: replied in #7443
[11:03] <mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
[11:04] <pstolowski> mborzecki: ok
[11:21] <Chipaca> Wimpress: ooh, installer crashed :-)
[11:23] <facubatista> Chipaca, a mate, indeed, why eoan?
[11:23] <Chipaca> facubatista: eoan → mañanero
[11:23] <Chipaca> roughly
[11:23] <facubatista> Chipaca, ah, didn't know that
[11:24] <Chipaca> facubatista: https://en.wikipedia.org/wiki/Eos
[11:24] <Chipaca> facubatista: "diosa de la aurora"
[11:25] <Chipaca> facubatista: I would've written that as "diosa del aurora" but maybe la->el to avoid vowel clash is frowned on these days?
[11:25] <facubatista> Chipaca, much funnier name the roman equivalent
[11:26] <facubatista> "mater matuta"
[11:26] <Chipaca> facubatista: :)
[11:27] <Chipaca> xnox: if the ubuntu installer crashes, is there anything useful or interesting for you?
[11:27] <Chipaca> or should i just do over
[11:27] <Chipaca> (maybe not pick zfs next iteration)
[11:28] <xnox> Chipaca:  if it installed /var/log/installer otheriwse /var/log/syslog /var/log/partman and like /var/log/ubiquity
[11:29] <xnox> Chipaca:  possibly check with didrocks & jibel as they have been working on zfs bit in desktop iso.
[11:29] <Chipaca> xnox: it did not install, I don't think, it was fairly early in the process
[11:29] <xnox> ack
[11:29] <Chipaca> I now (after a few minutes) got the "system program problem detected" dialogue
[11:29] <Chipaca> maybe the "report problem" button gets all those bits of info?
[11:29]  * Chipaca might be overly optimistic
[11:29] <xnox> it will
[11:30] <xnox> but you can also do $ ubuntu-bug ubiquity
[11:30] <xnox> (will ask for SSO login.....)
[11:30]  * Chipaca clicks the button and waits patiently
[11:30] <Chipaca> xnox: ack
[11:30] <mborzecki> zyga: hmm lxd snap https://paste.ubuntu.com/p/HzGx7PG4pc/
[11:30] <jibel> Chipaca, give me the bug # once it's reported
[11:31] <Chipaca> jibel: will do, thanks
[11:31] <Chipaca> still waiting on apport
[11:32] <Chipaca> xnox: the "report bug" button didn't seem to do anything fwiw, at least, no apport activity from there
[11:32] <xnox> Chipaca:  ubuntu-bug ubiquity
[11:32] <Chipaca> yep
[11:32] <xnox> Chipaca:  at least that should make a thing in /var/crash/*
[11:33] <xnox> Chipaca:  any files from /var/crash/* will be useful
[11:33] <Chipaca> oh god my lp password with no password manager
[11:33]  * Chipaca reaches for scp
[11:37] <Chipaca> jibel: #1847748
[11:37] <mup> Bug #1847748: installer crashed <amd64> <apport-bug> <eoan> <ubiquity-19.10.18> <ubuntu-mate> <ubiquity (Ubuntu):New> <https://launchpad.net/bugs/1847748>
[11:38] <Eighth_Doctor> mvo, zyga, mborzecki: https://bugzilla.redhat.com/show_bug.cgi?id=1760568
[11:38] <Eighth_Doctor> any of you have any idea of a way to fix this?
[11:38] <Chipaca> jibel: let me know if you need any more info from the system before i nuke it and start over
[11:39] <mborzecki> Eighth_Doctor: saw it in the monring, but wanted to try it myself
[11:39] <Eighth_Doctor> 👍️
[11:39] <jibel> Chipaca, thanks. I'll comment on the report
[11:40] <mborzecki> Eighth_Doctor: but yes, /var/home is a problem
[11:41] <mborzecki> Eighth_Doctor: also, not sure why silverblue is not using a bind mount for /var/home -> /home
[11:41] <zyga> Eighth_Doctor: looking
[11:41] <zyga> aha, this one
[11:41] <Eighth_Doctor> mborzecki: that's what langdon and I said too...
[11:41] <Eighth_Doctor> but unfortunately it's an ostree thing :(
[11:41] <zyga> there is a way to fix it but not anytime soon IMO
[11:42] <zyga> enough stuff to fix :/
[11:42] <zyga> we could remap $HOME to /home/$LOGNAME
[11:42] <zyga> but that's far from close
[11:42]  * pstolowski walk & lunch
[11:46] <zyga> output from gtest is an unreadable mess
[11:48] <mborzecki> zyga: duh, they changed it like 2 releases back
[11:48] <zyga> yeah, but it only matters when you have to look
[11:55] <Eighth_Doctor> zyga: can we add `/var/home` as an allowed redirection?
[11:55] <Eighth_Doctor> or maybe just follow the symlink and bind-mount the target?
[11:56] <Eighth_Doctor> (I assume that's what we're doing here with the homedir perm?)
[11:56] <kjackal> Is there an interface that would allow a command to stop and/or start a service? https://forum.snapcraft.io/t/stop-and-or-start-a-service-from-a-command/13649
[11:56] <zyga> Eighth_Doctor: not easily
[11:56] <zyga> there's more to it than that
[12:01] <mborzecki> off to pick up the kids
[12:02] <Chipaca> jibel: from your comment I gather you don't need more info and I can re-install
[12:02] <ondra> Chipaca mvo https://github.com/snapcore/snapd/pull/7590
[12:02] <mup> PR #7590: seed: seed16: run adding snaps in parallel <Created by kubiko> <https://github.com/snapcore/snapd/pull/7590>
[12:02] <mup> PR snapd#7590 opened: seed: seed16: run adding snaps in parallel <Created by kubiko> <https://github.com/snapcore/snapd/pull/7590>
[12:02] <ondra> Chipaca if you help me to land this, I will owe you one extra beer :P
[12:05] <Chipaca> ondra: hmmmmmmmmmmmm
[12:05] <Chipaca> ondra: I suspect it needs locks in addEssential, at least
[12:05] <Chipaca> ondra: but that's just a quick pass
[12:05] <Chipaca> ondra: I'll take a deeper look later
[12:05] <ondra> Chipaca not really
[12:05] <ondra> Chipaca I did keep order there
[12:06] <Chipaca> ondra: you are writing to a shared map from multiple goroutines
[12:06] <ondra> Chipaca have a look, only non assync is gadget
[12:06] <Chipaca> ondra: that's what i mean
[12:06] <ondra> Chipaca errors are written to shared map
[12:06] <ondra> Chipaca but there does not seem to be anything which would be related othetrwise
[12:07] <ondra> have a look
[12:07] <Chipaca> will do
[12:07] <Chipaca> ondra: in any case just the fact that you found out this speedup opportunity is awesome
[12:08] <Chipaca> so I'm happy
[12:08] <Chipaca> I might be even happier after reviewing this, who knows
[12:08] <Chipaca> i just don't have the mental bandwidth right now to do it properly :-)
[12:09] <ondra> Chipaca of course, this is not critical :)
[12:09] <ondra> Chipaca and it's not remedy to all, make no different on single core, or if you have 3 snaps
[12:10] <Chipaca> ondra: yeah, for that we need go to take ian's sha3 patches
[12:10] <Chipaca> ondra: there we get ~60% speedups across all armhf
[12:10] <ondra> Chipaca imagine combined those two :)
[12:10] <Chipaca> ondra: ikr
[12:11] <ondra> Chipaca unless that assembly code also utilises multicore
[12:12] <Chipaca> i'm sure there exist people that can write multicore assembly
[12:12] <Chipaca> i think it's all black magic anyway
[12:26] <vidal72[m]> hi, every time I open firefox it tries to read /var/lib/snapd/desktop/icons which is blocked by apparmor. Is it something fixable?
[12:27] <Chipaca> vidal72[m]: what snapd version are you on?
[12:28] <vidal72[m]> Chipaca: one from ubuntu 19.04
[12:28] <Chipaca> vidal72[m]: what does 'snap version' say?
[12:29] <vidal72[m]> I'm not on that machine atm, give me a sec
[12:31] <vidal72[m]> Chipaca: 2.42 series 16
[12:32] <Chipaca> vidal72[m]: are you sure you're seeing these messages with that version? (it's from yesterday)
[12:32] <ogra> old stuff then :P
[12:32] <vidal72[m]> yes, just reproduced minute ago
[12:32] <Chipaca> jamesh: have you seen this?
[12:33] <ogra> vidal72[m], is that on app startup or if you do some specific action (opening a file or whatnot)
[12:33] <jibel> Chipaca, yes, I've enough info, thanks
[12:34] <Chipaca> jibel: good because i'm already finishing the re-install :-) this time around i had no issues
[12:35] <jamesh> Chipaca: it's not surprising that apps would try to read various paths under /var/lib/snapd/desktop: that directory is included in $XDG_DATA_DIRS, and various specs say to check all locations contained there
[12:35] <vidal72[m]> ogra: app startup
[12:35] <Chipaca> jamesh: hrm, i thought we'd added desktop/icons as ok as part of your icons work
[12:35] <Chipaca> maybe i was confused then
[12:36] <jamesh> Chipaca: not for the benefit of confined apps: that was for the host
[12:36] <Chipaca> ah
[12:36] <Chipaca> should we add a rule just to not have it spam syslog?
[12:37] <Chipaca> (i don't mean a rule to allow the read)
[12:37] <vidal72[m]> +1
[12:38] <jamesh> perhaps
[12:38] <vidal72[m]> is it sensitive dir? I think desktop/applicationds are allowed to read
[12:38] <jamesh> browser-support currently allows access to /var/lib/snapd/desktop/applications, yes
[12:39] <jamesh> but it probably shouldn't
[12:39] <jamesh> it's not really useful and is a data leak
[12:40] <vidal72[m]> I think those should be both allowed or both denied
[12:41] <vidal72[m]> my icons folder is empty anyway
[12:42] <jamesh> presumably firefox was trying to access /var/lib/snapd/desktop/icons previously, but it didn't warn due to the directory not existing
[12:43] <jamesh> as long as we have that directory in XDG_DATA_DIRS, I agree that warnings for access denials are just noise
[12:48] <vidal72[m]> jamesh: desktop-legacy also allows desktop/applications https://github.com/snapcore/snapd/blob/release/2.42/interfaces/builtin/desktop_legacy.go#L229
[12:49] <jamesh> vidal72[m]: yep.  I don't think it is useful there either, since neither interface provides a way to launch those applications or access e.g. referenced icons
[12:51] <vidal72[m]> heh, why it was added then? isn't it needed for xdg-open?
[12:51] <vidal72[m]> which doesn't work in ff anyway but that's another story...
[12:52] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7591
[12:52] <mup> PR #7591: cmd/snap-confine: remove loads of dead code <Created by zyga> <https://github.com/snapcore/snapd/pull/7591>
[12:53] <mup> PR snapd#7591 opened: cmd/snap-confine: remove loads of dead code <Created by zyga> <https://github.com/snapcore/snapd/pull/7591>
[12:53] <Chipaca> zyga: can you lead the standup? I don't think I'm going to make it
[12:54] <zyga> syre
[12:54] <zyga> *sure
[12:54] <Chipaca> zyga: thynks
[12:54] <zyga> ny proolbm
[12:54] <Chipaca> :)
[12:54] <jamesh> vidal72[m]: I wouldn't be surprised if the rules grew out of watching the audit logs for various apps without fully thinking through whether it made sense
[12:55] <zyga> see you at the standup
[12:55] <Chipaca> zyga: probably not, that's the point :)
[12:55] <vidal72[m]> jamesh: should I make PR which deny desktop/{applications,icons} then?
[12:55] <jamesh> vidal72[m]: similar to the icons case, /var/lib/snapd/desktop/applications existed, so it would generate audit messages without the rule allowing read access
[12:55] <Chipaca> vidal72[m]: jamesh: suspect jdstrand might need to peep into this
[12:56] <jamesh> vidal72[m]: perhaps start a thread on the forum and tag @jdstrand.
[12:56] <vidal72[m]> ok
[12:57] <vidal72[m]> another thing: did anyone considered allowing writing to @{PROC}/@{pid}/clear_refs https://forum.snapcraft.io/t/call-for-testing-chromium-browser-deb-to-snap-transition/11772/17
[13:01] <Chipaca> zyga: wait i thought mvo was off today
[13:04] <degville> Chipaca: he's here - he changed his mind apparently.
[13:08] <mvo> Chipaca: I was considering it
[13:08] <vidal72[m]> jamesh: done https://forum.snapcraft.io/t/reading-var-lib-snapd-desktop-applications-icons/13650
[13:36] <zyga> mvo: thank you for the review :)
[13:36] <zyga> did you read the commit messages?
[13:36] <vidal72[m]> interestingly snap-store snap wants to read my /home/user/documents dir on each startup which is blocked
[13:45] <sparkiegeek> hmm, how does one use (install, run) snaps inside a docker container? is that even plausible?
[13:46] <roadmr> 🤯
[13:46] <sparkiegeek> roadmr: you have tips? :)
[13:46] <roadmr> only to run away as fast as you can!
[13:46]  * roadmr does, woohooo
[13:47] <sparkiegeek> well I was hoping zyga would just tell me that it all works :D
[13:47] <zyga> sparkiegeek: no can do :(
[13:47] <zyga> sorry, docker is not able to run docker either
[13:48] <sparkiegeek> k, am I basically SOL?
[13:48] <zyga> I'm afraid so
[13:48] <roadmr> sparkiegeek: why must it be docker?
[13:49] <sparkiegeek> zyga: np, knowing is better than flailing around
[13:49] <sparkiegeek> roadmr: Reasons™
[13:49] <roadmr> aha, got it :0
[13:49] <roadmr> heeh :)
[13:57] <Chipaca> man this system feels slow even over ssh
[13:57] <ijohnson> ondra, Chipaca: IIRC the SHA3 NEON assembly is not parallelized, so each core has it's own NEON processor and the parallel speedup that ondra has should multiple together with the assembly patches
[13:59] <ogra> we should also test on an imx6ull to see if there is any impact on single-core SoCs (positive or negative)
[14:03] <ijohnson> the imx6ull would definitely benefit from the SHA3 patches (I actually tested on one of those :-D ), probably not so much from ondra's parallelization patch though
[14:03] <ogra> well, the first is a given, the latter is what caused my question :)
[14:04] <ogra> it might improve, leaving the ordering to the kernel effectively ... or it might degrade because it tries to parallelize where it can not
[14:12] <ondra> ogra go seems to be somehow smart about loading, so if one tasks pegs the core, it will probably not try to run too many in parallel
[14:14]  * zyga -> lunch
[14:20] <Chipaca> cmatsuoka: after much chuntering, I have a booted core!
[14:22] <Chipaca> jibel: not being too scientific, it seems on this system I need to let it finish disk activity for partitioning before choosing country and creating the user, or it fails
[14:22] <Chipaca> jibel: "not too scientific" == tried it both ways twice
[14:36] <Chipaca> popey: Wimpress: I think mate would be better if it waited for seeded before giving you login
[14:36] <Chipaca> better first boot, you'd get the welcome app for one
[14:41] <ogra> ondra, well, i'd still perfer if you could hand it to cwayne to see actual results on real imx6ull hw
[14:46] <Chipaca> cmatsuoka: - Update assets from gadget "pc" (44) (cannot read current gadget snap details: invalid volume "pc": invalid structure #2 ("Recovery"): invalid role "system-recovery": unsupported role)
[14:46] <Chipaca> cmatsuoka: expected?
[14:50] <ondra> ogra feel free to get him involved
[14:50] <ogra> well, you got the patched binary :P
[14:50] <ogra> i'm just sayig we should make sure to have them in the loop before this goes to stable
[14:51] <ogra> i guess they'll run QA anyway
[14:51] <ogra> (on that HW)
[14:59] <Chipaca> cmatsuoka: mvo: core20 needs to drop the ConditionKernelCommandLine=snap_core from snapd.system-shutdown.service
[14:59] <Chipaca> :)
[14:59] <Chipaca> i need to dig into what creates that now that it's automagically put in etc by somethingorother
[14:59] <Chipaca> not now tho; now, tea
[15:00] <abeato> sil2100, hey, not sure if you saw my update to https://github.com/CanonicalLtd/ubuntu-image/pull/175 ?
[15:00] <mup> PR CanonicalLtd/ubuntu-image#175: Little kernel bootloader support <Created by alfonsosanchezbeato> <https://github.com/CanonicalLtd/ubuntu-image/pull/175>
[15:03] <mvo> chrisccoulson: indeed, good point
[15:06] <chrisccoulson> mvo, was that meant for me?
[15:08] <mvo> chrisccoulson: sorry, for Chipaca
[15:09]  * Chipaca hands chrisccoulson a "got called Chipaca" beginners badge
[15:11]  * roadmr is now nown as Choadmr
[15:13]  * Chipaca wonders if roadmr knows what a choad is
[15:13]  * roadmr googles
[15:13]  * roadmr is now known as google-before-changing-nick-mr
[15:13] <Chipaca> :)
[15:23] <ijohnson> Chipaca: thoughts on #1847788 ? is this a bug or "AsDesigned"?
[15:23] <mup> Bug #1847788: reverting and installing a snap deletes a disabled revision that should be kept <snapd:New> <https://launchpad.net/bugs/1847788>
[15:24] <kjackal> Is there a problem if I maintain a channel branch (eg edge/strict) with a strictly confined snap revision while the rest of the snap revisions in the channel are classic? https://forum.snapcraft.io/t/mixing-strictly-confined-and-classic-snap-revisions-in-a-channel/13652
[15:25] <zyga> kjackal: migrations from one and the other are not automatic
[15:25] <zyga> you can go classic -> strict
[15:25] <Chipaca> ijohnson: the one that's removed is _blacklisted_ (because revert)
[15:25] <zyga> but not the other way around
[15:25] <Chipaca> ijohnson: so that changes the behaviour a bit
[15:25] <Chipaca> ijohnson: you could instead snap refresh --revision x1, that should dwyw?
[15:25] <ijohnson> Chipaca: I want to keep revision x2 though
[15:26] <ijohnson> (though this is for a test, so bit of an arbitrary use case)
[15:26] <kjackal> thanks zyga, it is going to be only me using this channel branch for demo purposes (i hope)
[15:26] <Chipaca> ijohnson: yeah, it sounds like you want a refresh, not a revert
[15:26] <Chipaca> ijohnson: it's also possible it's a bug, but i think the refresh should leave x2 there
[15:26] <ijohnson> basically I want to keep like 4 revisions of a snap around, going back and forth between them with reverts and refreshes without any of them being garbage colledged
[15:26] <Chipaca> if that makes sense
[15:27] <zyga> kjackal: you can use a branch
[15:27] <zyga> kjackal: not a channel
[15:27] <Chipaca> ijohnson: why not with refreshes?
[15:27] <zyga> that's good for demos
[15:27] <ijohnson> I do need a revert though because I'm testing that revert does the right thing too :-)
[15:28] <Chipaca> ijohnson: ¯\_(ツ)_/¯ revert will discard things after 'current'
[15:28] <kjackal> zyga: I am probably messing up the terminology edge/strict is a channel with strict being a branch, yes/no ?
[15:28] <zyga> no, that's a risk level
[15:28] <ijohnson> Chipaca: yes that seems to be what it does now, but do you think that's a bug or AsDesigned?
[15:28] <zyga> you can create an actual branch
[15:28] <zyga> like demo
[15:28] <zyga> edge/demo
[15:28] <zyga> or demo/edge, I don't recall
[15:29] <zyga> people need to refresh to it explicitly
[15:29] <Chipaca> ijohnson: i mean, https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L291
[15:29] <ijohnson> zyga: demo/edge has demo as a track, while edge/demo has demo as a branch IIRC
[15:29] <Chipaca> ijohnson: // discard everything after current
[15:29] <Chipaca> ijohnson: it's very intentional :-)
[15:29] <kjackal> I thought the channel had a <track>/<risk>/<branch> format
[15:30] <zyga> you are probably right, as I said I don't recall
[15:30] <zyga> my whole point is that it's a good way for actual demos
[15:30] <Chipaca> kjackal: it should be fine, subject to the limitations of branches
[15:30] <kjackal> yeap, thank you people
[15:30] <Chipaca> i mean, they expire after a while unless you keep on pushing to them
[15:30] <Chipaca> that sort of thing
[15:31] <ijohnson> Chipaca: git blame says this was from mvo with commit message "review feedback" :-/
[15:31] <ijohnson> alright if it is AsDesigned that's fine I guess
[15:31] <ijohnson> just makes my tests more complicated
[15:31] <zyga> "review feedback" is the worst
[15:31] <Chipaca> ijohnson: https://github.com/snapcore/snapd/pull/1457
[15:31] <mup> PR #1457:  snapstate: drop revisions after "current" on refresh <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1457>
[15:32] <Chipaca> i mean, it's not good, but you grab the commit hash and look it up and you see the review feedback
[15:32] <Chipaca> so it's not _the worst_ :)
[15:32] <Chipaca> oh god, "retest this please"
[15:33]  * Chipaca hugs spread
[15:35] <Chipaca> ijohnson: what do you need the revision to still be there after revert for?
[15:35] <Chipaca> ijohnson: i mean, which is the path that you're testing for?
[15:36] <ijohnson> because I want to reuse the revision later in a different permutation, i.e. one test case is reverting backwards in time to that revision to make sure things work, another use case is to refresh to that revision
[15:36] <ijohnson> I think if I re-order how I have the tests to do the reverts last it should be simpler, but also some of my tests could be using refresh instead of revert
[15:38] <ijohnson> Chipaca: if it's helpful look at the comment at the top of https://github.com/snapcore/snapd/blob/e1d284981c5380ee9252bb77b878b44716a92829/tests/main/disabled-svcs-kept-happy/task.yaml
[15:44] <Chipaca> ijohnson: you can also refresh back and then revert forwards
[15:44] <ijohnson> hmmmm yes I suppose I could revert forwards couldn't I
[15:45] <mup> PR snapd#7591 closed: cmd/snap-confine: remove loads of dead code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7591>
[16:06] <mvo> ijohnson: uh, what did I do ? also - sorry for the terrible commit message
[16:06] <ijohnson> mvo: no worries, your PR from 3 years ago just makes my PR more complicated
[16:06] <mvo> ijohnson: I will read backlog after dinner hopefully
[16:06] <mvo> ijohnson: sorry for that
[16:07] <ijohnson> mvo: it's not important you don't need to read the backlog unless you want to
[16:07] <Chipaca> mvo: after dinner it's THE WEEKEND
[16:08] <ijohnson> Chipaca is right, the weekend is more important :-)
[16:16] <mup> PR core-build#56 opened: writable-paths: enable create writable /etc/systemd/user <Created by mvo5> <https://github.com/snapcore/core-build/pull/56>
[16:17] <mvo> Chipaca: *cough* good point
[17:04] <Chipaca> ok, I'm EOW'ing
[17:04] <Chipaca> have a good'un, those of you who remain! but do get out of here and do other stuff also
[18:46] <mup> PR snapcraft#2750 opened: cli: clean up StoreClientCLI <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2750>
[20:14] <mup> PR snapcraft#2750 closed: cli: clean up StoreClientCLI <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2750>
[22:26] <mup> PR snapd#7554 closed: recovery: update fde-utils calls <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7554>
[22:32] <mup> PR snapcraft#2751 opened: tests: move cli store push/upload tests to FakeStoreCommands <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2751>