[00:36] <RAOF> robert_ancell: Would you kindly push wayland 1.0 to git? :)
[00:48] <robert_ancell> RAOF, debian git?
[00:48] <RAOF> Yup; pkg-xorg.
[00:48] <RAOF> http://git.debian.org/?p=pkg-xorg/wayland/wayland.git
[00:49] <RAOF> Ah. Or you might not actually have commit access there, I guess.
[00:49] <robert_ancell> RAOF, and it appears they use some sort of merge-upstream?
[00:50] <RAOF> Correct.
[00:50] <RAOF> Would you perhaps like me to do the merginating of your uploads?
[00:50] <robert_ancell> RAOF, go for it
[00:53] <RAOF> Probably time to upgrade to raring, too.
[00:55]  * TheMuso upgraded to raring when he got back.
[00:55] <TheMuso> RAOF: Note that there is no noverlay filesystem support of any kind in 3.7 thats in raring now, a kernel that fixes this is currently in proposed.
[00:55] <TheMuso> s/noverlay/overlay.
[00:56] <TheMuso> In other words, current 3.7 in raring proper has no aufs and overlayfs modules.
[00:56] <RAOF> Win!
[00:56] <RAOF> My suffering with btrfs finally pays dividends!
[00:56] <TheMuso> Cool.
[00:56] <TheMuso> I got bitten by no overlay support yesterday when attempting to use sbuild on 3.7.
[00:57] <TheMuso> Its times like this when being able to keep older kernels around is useful.
[00:58] <xnox> RAOF: well... i use lvm snapshots =) no btrfs suffering and pays same dividends =)
[00:58] <RAOF> :P
[00:59] <xnox> RAOF: also you hit my "btrfs" highlight ;-)
[00:59] <RAOF> Oh, really?
[00:59] <RAOF> Why do you have such a beast?
[00:59] <xnox> yeah =)
[01:00] <xnox> RAOF: look at the upload history of btrfs-tools ;-)
[01:00] <RAOF> Hah.
[01:04] <ajmitch> xnox: I'd look as well but LP timed out :P
[01:04]  * xnox timesout to sleep
[05:56] <didrocks> good morning
[06:36] <BigWhale> good morning didrocks! :)
[06:37] <didrocks> hey BigWhale!
[06:37] <BigWhale> *tumbleweed*
[06:37] <BigWhale> oh, you're here. :)
[06:37] <BigWhale> just ^W that ... :))
[07:44] <seb128> hey desktopers
[07:46] <RAOF> make install
[07:46] <RAOF> Heh.
[07:47] <didrocks> hey RAOF ;) salut seb128!
[07:47] <seb128> hey didrocks, RAOF
[07:47] <RAOF> Hey all!
[08:35] <chrisccoulson> good morning everyone
[08:36] <chrisccoulson> meh:
[08:36] <chrisccoulson> 491871 INFO Failed: 113
[08:36] <seb128> chrisccoulson, hey, how are you?
[08:37] <chrisccoulson> !!
[08:37] <seb128> what's that?
[08:37] <chrisccoulson> hi seb128, i'm good thanks. how are you?
[08:37] <chrisccoulson> seb128, firefox mochitests
[08:37] <seb128> good, thanks
[08:37] <chrisccoulson> although, that's a small number of failures really:
[08:37] <chrisccoulson> 491870 INFO Passed: 669557
[08:37] <chrisccoulson> ;)
[08:38] <larsu> Friday!
[08:38] <larsu> good morning chrisccoulson, seb128!
[08:38] <chrisccoulson> hi larsu :)
[08:38] <seb128> larsu, hey, how are you?
[08:39] <larsu> seb128, good thanks. Yourself?
[08:39] <chrisccoulson> yeah, i like fridays :)
[08:39] <seb128> larsu, I'm good thanks
[08:39] <chrisccoulson> when i was at college, i always used to get a bacon and hash brown sandwich at breakfast on a friday
[08:39] <seb128> hehe
[08:39] <chrisccoulson> we used to call it "fattening fry day"
[08:39] <chrisccoulson> ;)
[08:39] <seb128> lol
[08:39] <larsu> hah
[08:41] <larsu> seb128, did you try the pidgin package with messaging menu integration? People are saying it works, now
[08:41] <chrisccoulson> now i'm thinking about bacon :(
[08:42] <seb128> chrisccoulson, you made me want one for those fattening breakfast :p
[08:42] <chrisccoulson> heh :)
[08:42]  * seb128 is staying at didrocks' today, the guy doesn't eat breakfast or lunch, I'm scared
[08:43] <didrocks> s/scared/screwed/
[08:43] <seb128> see :(
[08:43] <didrocks> heh ;)
[08:43] <chrisccoulson> oh, here's one of the test failures:
[08:43] <chrisccoulson> http://hg.mozilla.org/mozilla-central/file/a50a77da3cf9/content/canvas/test/webgl/test_webgl_conformance_test_suite.html#l368
[08:43] <chrisccoulson> i guess that ones easy to fix
[08:43] <chrisccoulson> disable it ;)
[08:43] <larsu> didrocks, give this guy something to eat!
[08:43] <seb128> larsu, no, I wanted to do that and got carried in email backlog, giving it a try next
[08:44] <larsu> didrocks, and: happy Friday morning to you ;)
[08:44] <didrocks> good morning larsu, forcing feeding? what world are we living on?
[08:45] <larsu> didrocks, as long as its bacon I'm sure he doesn't mind :P
[08:45] <didrocks> larsu: tssssss :)
[08:45] <didrocks> only at UDS
[08:45] <larsu> :D
[08:45] <didrocks> no chance to find bacon here :)
[08:46] <didrocks> but butter + marmalade for seb128
[08:46]  * larsu would much prefer that for breakfast. Sans the butter
[08:46] <didrocks> this is the butter controversy
[08:46] <seb128> oh, didrocks finally agrees on adding the butter with the marmalade, shame that breakfast is over
[08:47] <didrocks> heh
[08:47] <seb128> dammit, larsu is in the no-butter side
[08:47] <didrocks> seb128: want another one? :)
[08:47] <larsu> NO BUTTER FTW!
[08:48] <seb128> larsu, right, wurst for breakfast in germany
[08:49] <larsu> seb128, not for me either (I don't like meat in the morning). Sorry to disappoint  :)
[09:06] <Laney> morning
[09:06] <Laney> damn you dpkg-gensymbols
[09:08] <hyperair> Laney: what's up with gensymbols?
[09:08] <Laney> c++
[09:08] <Laney> size_t
[09:08] <hyperair> oh
[09:08] <hyperair> i've had that
[09:08] <Laney> yes.
[09:08] <Laney> what's the solution?
[09:08] <hyperair> see libmediainfo
[09:08] <Laney> is it to use pkgkde-symbolshelper?
[09:08] <hyperair> i didn't.
[09:08] <hyperair> but some people say it helps
[09:08] <hyperair> i just used regexes
[09:09] <Laney> uh huh
[09:09] <hyperair> it works pretty well
[09:09] <hyperair> Laney: oh and i use the demangled symbols.
[09:09] <Laney> yes
[09:09] <hyperair> so it's sometihng like (c++|regex)
[09:09] <Laney> https://launchpadlibrarian.net/123173455/buildlog_ubuntu-raring-powerpc.webkit_1.10.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:10] <Laney> warning it's pretty big, maybe wget at vim it
[09:10] <Laney> s/at/and/
[09:10] <hyperair> ugh
[09:10] <hyperair> trust webkit to be huge in everything
[09:10] <Laney> shame it's a 3 hour turnaround
[09:12] <hyperair> ccache should help matters
[09:12] <hyperair> for local builds
[09:12] <Laney> probably
[09:13] <hyperair> Laney: actually i only see one size_t related symbol...
[09:13] <hyperair> Laney: the rest are valid additions imo
[09:15] <hyperair> size_t makes me wish it was a real distinct type instead of a typedef.
[09:15] <Laney> all looks like size_t to me
[09:15] <Laney> what do you see?
[09:34] <chrisccoulson> so, i've added autopkgtest support to firefox now: http://bazaar.launchpad.net/~chrisccoulson/firefox/firefox-trunk.autopkgtest/files/head:/debian/tests/
[09:34] <chrisccoulson> is there anything else i need to do to make that run when i upload?
[09:39] <Sarvatt> XS-Testsuite: autopkgtest in debian/control, unless that packaging is never going to be in debian then that doesn't matter :)
[09:40] <Sarvatt> oh its already there
[09:41] <mlankhorst> Sarvatt: what are you doing awake
[09:41] <mlankhorst> :P
[09:41] <mlankhorst> end that gaming session already >:D
[10:33] <chrisccoulson> gah, why do people email me to report bugs?
[10:35] <seb128> chrisccoulson, because you don't reply to IRC pings :p
[10:35] <chrisccoulson> lol
[10:35] <chrisccoulson> i get enough email without people mailing me with issues ;)
[10:36] <chrisccoulson> in this case, the latest upload to the firefox beta PPA completely broke the menubar thanks to a random build-ordering issue
[10:36] <chrisccoulson> but nobody reported a bug to launchpad
[10:36] <chrisccoulson> they just emailed me instead
[10:36] <chrisccoulson> which prevents anybody else from tracking it
[10:38] <chrisccoulson> ok, i added a comment to the PPA description: https://launchpad.net/~mozillateam/+archive/firefox-next
[10:38] <chrisccoulson> i wonder if anyone reads that ;)
[10:38] <Laney> "For questions and bugs with software in this PPA please contact Mozilla Team."
[10:39] <chrisccoulson> hmmm, that sucks. and i can't change that, can i?
[10:39] <Laney> not afaik
[10:40] <chrisccoulson> is that displayed when you do "add-apt-repository"?
[10:40] <chrisccoulson> ok, it's not. only the custom description is displayed
[10:41] <Laney> it gives a link to that page
[10:42] <chrisccoulson> ok, i updated the comment again ;)
[10:42] <chrisccoulson> "For questions and bugs with software in this PPA please *don't* contact mozillateam."
[10:42] <Laney> haha
[10:42] <Laney> rename the team
[10:43] <Laney> "Mozilla Team ← forget what that says"
[10:45] <Tm_T> Laney: that would be nice
[11:22] <seb128> Laney, hey, do you plan to do SRU brasero as well?
[11:24] <seb128> Laney, ignore that, the fix was already srued it seems
[11:24] <Laney> hmm?
[11:24] <Laney> I just copied from q-updates to r :-)
[11:24] <seb128> Laney, oh ok
[11:25] <seb128> Laney, I got confused, I though you did an upload which reminded me of bug #658004
[11:25] <ubot2> Launchpad bug 658004 in brasero (Ubuntu) "brasero dvd capacity estimation is broken" [Low,Triaged] https://launchpad.net/bugs/658004
[11:26] <Laney> ah, we could probably put that in bzr to pick it up next time
[11:26] <Laney> i'll do that
[11:58] <chrisccoulson> now nobody has an excuse not to read our bug reporting guidelines: https://wiki.ubuntu.com/MozillaTeam/Bugs
[11:58] <chrisccoulson> i added a nice little summary at the top ;)
[12:39] <xclaesse> seb128, I would be very happy if devhelp 3.6.1 can be pushed to quantal. For that fix: http://git.gnome.org/browse/devhelp/commit/?h=gnome-3-6&id=d7506a2eb5ae92136a8e400561d38817784107fb
[12:39] <xclaesse> the rest is only translations
[12:41] <seb128> xclaesse, can do
[12:41] <xclaesse> awesome, thanks :)
[12:42] <seb128> yw, thanks for pointing it
[16:24] <mterry> seb128, didrocks: any objections to 'unity-settings-appearance' for the package name for the appearance panel?
[16:24] <didrocks> mterry: sounds good to me
[16:25] <seb128> mterry, no strong opinion on the topic, works for me if you like it ... I'm not sure exposing "appearance" there is the best thing
[16:26] <seb128> compared to e.g -panel
[16:26] <seb128> but it's just a name and I'm not good at picking those ;-)
[16:26] <mterry> seb128, you're thinking we'd have one source package for all future panels?
[16:26] <seb128> if we have different unity panel why not ... which I don't think we plan to
[16:27] <seb128> but yeah, no need to have one source for each panel imho
[16:27] <mterry> seb128, hmm, then if we're doing a bucket package, I'd favor just "unity-settings"  (panel is too techy in my mind -- the name is never exposed to users(
[16:28] <seb128> mterry, that name would mislead users to think that's an ui to configure unity
[16:28] <seb128> keep the one you first suggested
[16:28] <jbicha> Privacy uses activity-log-manager-control-center which isn't the most intuitive
[16:29] <seb128> gnome-control-center-unity
[16:29] <seb128> to follow the gnome-control-center-signon leads ;-)
[16:29] <mterry> jbicha, that name is awful  :)
[16:30] <mterry> seb128, if there's precedent, that's fine
[16:30] <mterry> jbicha, though I guess gnome-control-center-unity isn't much better
[16:30] <seb128> mterry, dpkg -l gnome-control-center-signon
[16:31] <seb128> why is "picking a name" always that hard ;-)
[16:31] <mterry> seb128, it's important!  anyone that doesn't think so can go stand with tedg
[16:31] <kenvandine> :-D
[16:31] <larsu> it's an extension for gnome-control-center, so shouldn't it start with "gnome-control-center-"?
[16:32] <mterry> larsu, that's a fine point of view, but I was thinking its defining feature was that it was the settings for unity, and being a g-c-c panel was an implementation detail that might change in 20 years
[16:32] <tedg> mterry, It's easy, you just try a few and the first one that gets kenvandine to drop off IRC you use.
[16:32] <kenvandine> hehe
[16:33] <jbicha> g-c-c-unity is a bit ambiguous; it's possible that the designers will decide on a different panel besides Appearance in the future
[16:33] <mterry> jbicha, right, and then we wouldn't have to change the name.  feature, not bug, eh?
[16:33] <seb128> jbicha, why would -unity confuse anyone if they rename appearance?
[16:34] <larsu> mterry, right, in that case I'm for your first suggestion, without the -appearance suffix
[16:34] <seb128> larsu, unity-settings?
[16:34] <larsu> seb128, ya
[16:34] <seb128> isn't that going to mislead users to think that's a configuration ui
[16:34] <larsu> isn't it?
[16:34] <seb128> ?
[16:34] <jbicha> what if there's a new panel called Unity, and Ubuntu still wants to have a separate Appearance panel to set the wallpaper
[16:34] <mterry> seb128, there is  :)  g-c-c
[16:34] <larsu> seb128, I thought that's exactly what it is
[16:34] <mterry> jbicha, that unity panel would be part of this package
[16:35] <seb128> jbicha, we set we would batch all the unity panels (if there is ever extra ones) in that source
[16:35] <mterry> jbicha, we're talking about having a package that will house any future panels
[16:35] <seb128> we said*
[16:35] <jbicha> how about ubuntu-control-center? ;)
[16:35] <larsu> jbicha wins the internet!
[16:35] <seb128> that would mislead people to think it's our "fork of upstream g-c-c"
[16:35] <jbicha> seb128: it sort of is…
[16:35] <seb128> it's only one panel
[16:39] <mterry> OK, I'm going with gnome-control-center-unity
[16:39] <seb128> mterry, \o/
[16:40] <mterry> jbicha, another reason I don't like ubuntu-control-center is that this is unity-specific, not ubuntu-specific.  I like to reserve ubuntu for project-wide things if possible
[16:40] <mterry> jbicha, btw, did you see that I made separate deja-dup backends, so you can only seed the ones you want to in gnome3
[16:41] <jbicha> mterry: yes thank you :)
[17:57]  * didrocks waves good evening
[21:41] <qengho> Oh, sweet, learned that sys.executable (which Chromium uses in build tools) can be the empty string sometimes. So much fun.
[21:41] <qengho> Worked around it. So glad it's EOW.
[22:45] <LLStarks> how do i reset gnome? my g-c-c settings won't unlock unless i use gksu. can't change themes or make my clock am/pm.


[00:00] <_mup_> ensemble/expose-provisioning r253 committed by<EMAIL_ADDRESS>[00:00] <_mup_> Make explicit that a couple of methods are only to be used for testing
[00:39] <_mup_> ensemble/unit-agent-resolved r275 committed by<EMAIL_ADDRESS>[00:39] <_mup_> complete the change over to more transitions, fill out coverage
[00:48] <_mup_> ensemble/unit-agent-resolved-part-two r274 committed by<EMAIL_ADDRESS>[00:48] <_mup_> merge and resolve conflict
[01:01] <_mup_> ensemble/unit-agent-resolved-part-two r274 committed by<EMAIL_ADDRESS>[01:01] <_mup_> redo merge resolve conflict, grabbed the wrong resolved file
[02:11] <niemeyer> Yo!
[02:33] <niemeyer> hazmat: ping
[02:33] <hazmat> niemeyer, pong
[02:33] <niemeyer> hazmat: Yo
[02:33] <niemeyer> hazmat: I'm having some trouble to review the new unit-agent-resolved, for lack of a good based to compare it with
[02:33] <niemeyer> hazmat: ensemble-resolved, which is the pre-requisite, doesn't include the trunk yet
[02:33] <niemeyer> hazmat: the trunk doesn't include ensemble-resolved
[02:34] <niemeyer> hazmat: and unit-agent-resolved contains both
[02:34] <hazmat> niemeyer, no.. it doesn't, unit-agent-resolved is after ensemble-resolved in my pipeline
[02:34] <niemeyer> hazmat: So no matter what's the base, there are cross-changes
[02:34] <niemeyer> hazmat: Yes it is, thus, it includes the changes from it
[02:34] <hazmat> niemeyer, the base is ensemble-resolved
[02:34] <niemeyer> hazmat: Yes it is
[02:34] <hazmat> i need to push my latest which merges trunk
[02:34] <hazmat> of ensemble-resolved
[02:35] <hazmat> if you want to utilize it as a base
[02:35] <niemeyer> hazmat: unit-agent-resolved contains both the latest from trunk and the latest from ensemble-resolved
[02:35] <hazmat> niemeyer, yes
[02:35] <niemeyer> hazmat: I can't compare it with either without getting irrelevant changes
[02:35] <niemeyer> hazmat: (in the diff)
[02:36] <hazmat> niemeyer, the diff to ensemble-resolved looked fine to me
[02:36] <niemeyer> hazmat: The solution is to handle the ensemble-resolved merge on trunk, or to update it
[02:36] <niemeyer> -html_static_path = ['_static']
[02:36] <niemeyer> +#html_static_path = ['_static']
[02:36] <niemeyer> hazmat: That's part of that diff
[02:36] <niemeyer> hazmat: (and a lot of other things from trunk)
[02:37] <hazmat> pushing the latest ensemble-resolved
[02:37] <niemeyer> hazmat: That should handle it if you have trunk merged on it, thanks
[02:37] <hazmat> niemeyer, let me know if that fixes the issue
[02:37] <hazmat> its pushed
[02:38] <hazmat> that's current with trunk
[02:38] <niemeyer> hazmat: Yep, that did it, thank you
[02:39] <hazmat> niemeyer, cool, np
[03:01] <niemeyer> Phew, 2 to go
[03:01] <niemeyer> Tomorrow, though
[03:15] <_mup_> ensemble/config-set r216 committed by<EMAIL_ADDRESS>[03:15] <_mup_> checkpoint
[03:53] <_mup_> ensemble/auto-dependency-resolution r217 committed by<EMAIL_ADDRESS>[03:53] <_mup_> flesh out some tests using a new test ease of use api.
[04:17] <_mup_> ensemble/expose-provisioning r254 committed by<EMAIL_ADDRESS>[04:17] <_mup_> Test added to verify opened port parsing
[09:05] <kim0> morning folks
[10:37] <_mup_> ensemble/config-get r219 committed by<EMAIL_ADDRESS>[10:37] <_mup_> use get_formula_state in get_relation_endpoints, removes duplicate code
[10:39] <_mup_> ensemble/config-get r220 committed by<EMAIL_ADDRESS>[10:39] <_mup_> rename hook's local_* methods as get_local_*
[10:39] <_mup_> expanded test coverage
[10:41] <_mup_> ensemble/config-get r221 committed by<EMAIL_ADDRESS>[10:41] <_mup_> merge trunk
[10:44] <_mup_> ensemble/trunk r219 committed by<EMAIL_ADDRESS>[10:44] <_mup_> Merge config-get [r=niemeyer] [f=776605]
[10:44] <_mup_> Merge support for config-get cli tool for use in hooks. This makes local service options available within hooks.
[11:40] <kim0> config-get lovely :)
[14:01] <_mup_> Bug #777816 was filed: Ensemble should resolve dependencies upon deploy <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/777816 >
[14:27] <niemeyer> hazmat: Morning!
[14:28] <hazmat> niemeyer, morning
[14:30] <kim0> niemeyer: hazmat morning
[14:30] <hazmat> kim0, top of the morning
[14:30] <kim0> hehe
[14:31] <hazmat> morning always seems a bit arbitrary given the our globally distributed nature
[14:31] <kim0> Yeah .. maybe we should get a bot for translating timezone salutations
[14:32] <hazmat> from a symbolism perspective, morning is nice though, expressing at hope and joy at the beginning of a new day
[14:37] <hazmat> hmm.. puppet's changing licensing to apache
[14:41] <kim0> so how do I have to bribe to merge my doc branches :)
[14:41] <kim0> s/how/who/
[14:49] <hazmat> kim0, i'll do it now
[14:49] <hazmat> niemeyer, do you know if the bzr --author flag on commit takes  a full name or an lp name?
[14:50] <niemeyer> hazmat: I suppose it takes a full name
[14:50] <niemeyer> hazmat: Or, actually
[14:50] <niemeyer> hazmat: I think this is just metadata
[14:50] <hazmat> niemeyer, it is just metadata, but its displayed onlp
[14:50] <hazmat> niemeyer, the gopher ppa has the latest go packages?
[14:50] <niemeyer> hazmat: Displayed as is, I think
[14:50] <niemeyer> hazmat: It does
[14:50] <niemeyer> hazmat: ppa:gophers/go
[14:51] <hazmat> niemeyer, thanks
[14:51] <niemeyer> hazmat: np
[14:51] <niemeyer> Actually, I have to send those packages again.. some third-party libraries got included by mistake
[14:56] <_mup_> ensemble/trunk r220 committed by<EMAIL_ADDRESS>[14:56] <_mup_> merge kim0's new user guide and faq [a=kim0][r=niemeyer][f=734975]
[14:56] <_mup_> Provides a tutorial within the documentation taking the user through
[14:56] <_mup_> the process of getting started with Ensemble as well as an FAQ.
[14:57] <hazmat> kim0, done, and your noted as the author on lp and bzr history
[14:59] <hazmat> kim0, thanks again, that was much needed
[15:10] <_mup_> ensemble/auto-dependency-resolution r218 committed by<EMAIL_ADDRESS>[15:10] <_mup_> additional test for solving deps from both environment and formula repos.
[15:20] <hazmat> doing some bug milestone management, sorry about the noise
[15:31] <_mup_> ensemble/resolved-state-api r204 committed by<EMAIL_ADDRESS>[15:31] <_mup_> merge trunk
[15:33] <hazmat> niemeyer, should i change the relation resolved api now (it doesn't need the retry flag).. or just wait, since the entire stack uses the api..
[15:33] <kim0> hazmat: thanks man
[15:34] <hazmat> kim0, np
[15:35] <niemeyer> hazmat: Sorry, ECONTEXT
[15:35] <niemeyer> hazmat: What's that about again?
[15:36] <hazmat> niemeyer, sure.. the set_relation_resolved(relation_map) really just needs to be set_relation_resolved(relation_list) .. since retry hook has no meaning
[15:36] <hazmat> hmm.. i think i suggested that i just make the cli barf in this case
[15:36] <hazmat> i guess that api has other pending cleanups as well though
[15:36] <niemeyer> hazmat: Do we plan to make it retry in the future?
[15:36] <hazmat> niemeyer, hmm.. good question
[15:37] <hazmat> niemeyer, its concievable.. but not nesc. correct
[15:37] <hazmat> a hook execution may be obsolete in a relation context
[15:37] <hazmat> by the time we want to retry it
[15:39] <hazmat> i go ahead cli fix, and note is as something that needs adjustment as part of the staterequest protocol work
[15:39] <hazmat> ^it
[15:41] <hazmat> hmm.
[15:41] <hazmat> i guess i can try it and see how much work it really is
[15:44] <hazmat> niemeyer, thoughts on retry?
[15:45] <hazmat> uds sessions are posted
[15:52] <koolhead17> hi all
[15:53] <kim0> hey
[15:54] <koolhead17> kim0: am at https://code.launchpad.net/~kim0/ensemble/user-tutorial-and-FAQ/+merge/58861  will buzz you later :)
[15:55] <kim0> koolhead17: it's been merged .. http://people.canonical.com/~niemeyer/ensemble/user-tutorial.html
[15:56] <koolhead17> ok :)
[15:58] <niemeyer> hazmat: Sorry, was answering that message in the cloud ML
[15:58] <niemeyer> hazmat: Hmm
[15:59] <niemeyer> hazmat: So, let's try to come up with a scenario
[15:59] <niemeyer> hazmat: DNS goes off for whatever reason
[15:59] <niemeyer> hazmat: db-relation-changed explodes
[15:59] <niemeyer> hazmat: Intended change done by the other side of the relation isn't acted upon
[15:59] <niemeyer> hazmat: No other changes are done
[16:00] <niemeyer> hazmat: DNS goes live
[16:00] <niemeyer> hazmat: ensemble resolved unit/0 db
[16:00] <niemeyer> hazmat: Change is lost
[16:00] <hazmat> niemeyer, yes
[16:00] <hazmat> niemeyer, we could capture enough information to retry the hook
[16:00] <hazmat> but then say unit/0 departs
[16:01] <hazmat> should we be retrying a hook for something which doesn't exist anymore?
[16:01] <niemeyer> hazmat: How would that take place?
[16:01] <niemeyer> hazmat: resolved shouldn't work on a relation which doesn't exist (!?)
[16:01] <hazmat> niemeyer, the relation exists but the remote peer that caused the change has departed
[16:01] <hazmat> s/peer/unit
[16:03] <niemeyer> hazmat: Hmm
[16:03] <niemeyer> hazmat: Thinking
[16:03] <hazmat> some of this might be more clear if we do on disk persistence and recovery, since the merge of last known to current is applicable
[16:04] <niemeyer> hazmat: Hmm.. maybe
[16:04] <hazmat> niemeyer, i'll leave the api as is for now
[16:04] <niemeyer> hazmat: Sounds good
[16:05] <niemeyer> hazmat: Can you please [trivial] a comment explaining that debate please?
[16:05] <niemeyer> hazmat: Just enough to give us context for following on that conversation at a latter time
[16:05] <hazmat> niemeyer, sure in the commit, merge proposal, bug report, code ?
[16:05] <niemeyer> hazmat: Code feels more visible.. next to the API which we should change
[16:05] <hazmat> niemeyer, sounds good
[16:05] <niemeyer> hazmat: Thanks
[16:16] <_mup_> ensemble/expose-provisioning r255 committed by<EMAIL_ADDRESS>[16:16] <_mup_> Merged trunk & resolved conflicts
[16:16] <_mup_> ensemble/expose-dummy-provider r217 committed by<EMAIL_ADDRESS>[16:16] <_mup_> Merged trunk
[16:23]  * hazmat lunches
[16:25] <_mup_> ensemble/expose-dummy-provider r218 committed by<EMAIL_ADDRESS>[16:25] <_mup_> Use fail/succeed instead of inlineCallbacks for dummy methods w/o internal yield needs
[16:28] <niemeyer> hazmat: Enjoy
[16:28] <_mup_> ensemble/expose-provisioning r256 committed by<EMAIL_ADDRESS>[16:28] <_mup_> Merged upstream
[16:37] <niemeyer> One branch pending
[16:38] <niemeyer> jimbaker: Will review your lunch after lunch
[16:38] <niemeyer> Erm
[16:38] <niemeyer> jimbaker: Will review your branch after lunch
[16:38] <niemeyer> "Will review your lunch after branch" would be nice too
[16:40] <jimbaker> niemeyer, i believe i'm to have some sort of chicken soup to deal with my cold symptoms... i will see what my mother-in-law prepares ;)
[16:40] <niemeyer> jimbaker: ;-)
[16:47] <_mup_> ensemble/trunk r221 committed by<EMAIL_ADDRESS>[16:47] <_mup_> merge expose-dummy-provider [r=niemeyer][f=766241]
[16:47] <_mup_> Adds dummy provider support for port opening/closing.
[16:48] <_mup_> ensemble/expose-provisioning r257 committed by<EMAIL_ADDRESS>[16:48] <_mup_> Merged trunk
[16:49] <_mup_> ensemble/expose-hook-commands r249 committed by<EMAIL_ADDRESS>[16:49] <_mup_> CLI commands
[16:50] <_mup_> ensemble/expose-hook-commands r250 committed by<EMAIL_ADDRESS>[16:50] <_mup_> Merged upstream & resolved conflicts
[17:14] <_mup_> ensemble/resolved-state-api r205 committed by<EMAIL_ADDRESS>[17:14] <_mup_> document set_relation_resolved api todo discussion
[17:18] <_mup_> ensemble/resolved-state-api r206 committed by<EMAIL_ADDRESS>[17:18] <_mup_> doc string cleanups per review.
[17:47] <_mup_> ensemble/trunk r222 committed by<EMAIL_ADDRESS>[17:47] <_mup_> merge resolved-state-api [r=niemeyer][f=767762]
[17:47] <_mup_> Provides a get/set/clear/watch state api for marking unit errors as resolved.
[17:48] <_mup_> ensemble/trunk-merge r191 committed by<EMAIL_ADDRESS>[17:48] <_mup_> merge trunk
[17:54] <_mup_> ensemble/ensemble-resolved r259 committed by<EMAIL_ADDRESS>[17:54] <_mup_> update code comments per review comment
[17:57] <_mup_> ensemble/trunk r223 committed by<EMAIL_ADDRESS>[17:57] <_mup_> merge ensemble-resolved [r=niemeyer][f=767948]
[17:57] <_mup_> Provides a new ensemble resolved subcommand for marking unit errors
[17:57] <_mup_> as resolved.
[18:16] <niemeyer> Alright, last branch in review!
[18:26] <hazmat> niemeyer, i've got some comments on the unit-agent-resolved review that i would like to discuss
[18:26] <hazmat> already attached to the review
[18:41] <niemeyer> hazmat: Ok.. I'll need some time to go over this review I'm doing
[18:41] <_mup_> ensemble/unit-agent-resolved r279 committed by<EMAIL_ADDRESS>[18:41] <_mup_> address review comments re formatting
[19:14] <niemeyer> jimbaker: I really wish this branch was pushed in a more fine grained way
[19:15] <niemeyer> I'm not sure I'll be able to get through it today
[19:16] <jimbaker> niemeyer, there is an obvious split between the service changes and the specific support for provisioning
[19:17] <jimbaker> although the service changes are all very much boiler plate cut & paste
[19:17] <jimbaker> however, if you want me to split the branch in that way, i can certainly do so
[19:17] <niemeyer> jimbaker: Yeah, hundreds of lines of boilerplate ;)
[19:18] <niemeyer> jimbaker: That'd take even more time
[19:18] <jimbaker> niemeyer, i don't like any of it, but hopefully post budapest it can be removed
[19:18] <niemeyer> jimbaker: The idea is to not get into this state
[19:18] <niemeyer> jimbaker: As you said, there are several split points..
[19:18] <niemeyer> jimbaker: Pushing such a huge branch 3 days before UDS isn't good
[19:38] <hazmat>  niemeyer, jimbaker, bcsaller test api https://pastebin.canonical.com/47175/
[19:39] <hazmat> i'm implementing parts as part of the dependency resolver work
[19:39] <hazmat> most of it is cribbed from other test helpers we have around
[21:02] <_mup_> ensemble/trunk r224 committed by<EMAIL_ADDRESS>[21:02] <_mup_> merge unit-agent-resolved [r=niemeyer][f=767961]
[21:02] <_mup_> Provides a unit lifecycle support for processing resolved unit relations.
[21:35]  * niemeyer => break
[21:38] <_mup_> ensemble/unit-agent-resolved-part-two r279 committed by<EMAIL_ADDRESS>[21:38] <_mup_> update unit agent to use correct transition depending on retry setting.
[21:43] <_mup_> ensemble/trunk r225 committed by<EMAIL_ADDRESS>[21:43] <_mup_> merge unit-agent-resolved-part-two [r=niemeyer][f=776014]
[21:43] <_mup_> Provides unit agent support for transitioning resolved units and unit relations.
[21:50] <_mup_> ensemble/debug-hook-scope-guard r211 committed by<EMAIL_ADDRESS>[21:50] <_mup_> merge trunk
[22:03] <_mup_> Bug #778134 was filed: debug hook seems to have lost hook cli context when using hook api <Ensemble:New> < https://launchpad.net/bugs/778134 >
[22:03] <hazmat> we really do need to have ensemble changed in the environment
[22:03] <hazmat> or use byobu.. its hard to tell what the debug is actively working on otherwise
[22:09] <hazmat> sigh.. we need more release testing, or feature freezes before a release. so many new features this release, i'm seeing a few behavior regressions
[22:11] <jimbaker> hazmat, agreed - i haven't fired up AWS recently since i'm working on stuff that just needs unit testing, *for now*
[22:11] <jimbaker> but experience has shown repeatedly that we don't anticipate enough in our unit tests
[22:14] <_mup_> ensemble/debug-hook-scope-guard r212 committed by<EMAIL_ADDRESS>[22:14] <_mup_> switch to using byobu
[22:56]  * niemeyer_break waves
[23:04] <_mup_> ensemble/trunk r226 committed by<EMAIL_ADDRESS>[23:04] <_mup_> merge debug-hook-scope-guard [r=niemeyer][f=776014]
[23:04] <_mup_> Enables live hook debugging via screen/byobu, with better start/end condition handling.
[23:05] <_mup_> ensemble/expose-hook-commands r251 committed by<EMAIL_ADDRESS>[23:05] <_mup_> Hook command skeleton, plus parse_port_protocol for that arg
[23:58]  * niemeyer => dinner


[03:25] <mup> PR snapd#8903 opened: tests: new core config helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8903>
[05:13] <mborzecki> morning
[05:51] <mborzecki> mvo: hey
[05:53] <mborzecki> quick errand, brb
[05:54] <mvo> mborzecki: good morning
[06:32] <zyga> Good morning
[06:32] <zyga> I will start at 9
[06:32] <zyga> Good to see you mvo!
[06:33] <mvo> zyga: good morning. even better to see you :)
[06:33] <mvo> zyga: hope you are well (enough)!
[06:39] <mborzecki> re
[06:39] <mborzecki> zyga: hey
[06:40] <zyga> I’m going to be soon. Just had my morning painkillers
[06:40] <zyga> But even without them I think there is an improvement
[06:40] <mborzecki> zyga: something is off in centos 8 with the change from #8901
[06:40] <mup> PR #8901:  tests/lib/tools: apply linger workaround when needed  <Precious Logs> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901>
[06:40] <mvo> zyga: nice!
[06:41] <zyga> mborzecki: I’ll look in 20 minutes
[06:45] <mborzecki> zyga: thanks
[06:56] <mup> PR snapd#8904 opened: snapstate: use testutil.HostScaledTimeout() in snapstate tests <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8904>
[07:02] <zyga> re
[07:02] <zyga> in makeshift floor office
[07:02] <zyga> I'm on bug shift today
[07:06] <pstolowski> morning
[07:07] <mborzecki> pstolowski: heya
[07:11]  * zyga looks at the PRs
[07:12] <mborzecki> funny when syncing homes with a loptop through unison it takes significantly longer because of a bunch of 1gb files in snapd source tree that were left behind after i last played with uc20 imare prepare code for the spread tests
[07:12] <zyga> mborzecki: can you push the syntax fixes to https://github.com/snapcore/snapd/pull/8901/files please
[07:12] <mup> PR #8901:  tests/lib/tools: apply linger workaround when needed  <Precious Logs> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901>
[07:12] <zyga> heh
[07:13] <zyga> :)
[07:13] <mborzecki> haha
[07:13] <mborzecki> ok
[07:13] <zyga> commented in the RP
[07:13] <zyga> PR
[07:14] <mborzecki> zyga: ah, w8, the code that retries linger is further down
[07:14] <zyga> where?
[07:15] <zyga> I don't see any
[07:15] <mborzecki> zyga: line 161/169
[07:15] <zyga> hmm
[07:15] <mborzecki> zyga: w8, 143/151
[07:16] <zyga> ah I understand now
[07:17] <mborzecki> zyga: enabling twice should be harmless, right? it jus drops a file under /var/lib/ssytemd/linger
[07:17] <zyga> IIRC it does more than that
[07:17] <zyga> but it enabling twice should be harmless if it works right
[07:17] <zyga> I wonder what happens if we try and fail
[07:17] <zyga> fix the system
[07:17] <zyga> and try again
[07:18] <zyga> enabling linger does start all the user services
[07:18] <mborzecki> zyga: maybe we should disable/stop<EMAIL_ADDRESS>[07:18] <mborzecki> zyga: in the branch when enable fails
[07:18] <zyga> not sure, we'd have to look at logind to see what it does and where the current failure is placed in the sequence of calls
[07:31] <mup> PR snapd#8898 closed:  snapdtool: helper to check whether the current binary is reexeced from a snap <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8898>
[07:31] <mup> PR snapd#8900 closed: tests: extra worker for google-nested backend to avoid timeout error on uc20 <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8900>
[07:39] <zyga> ok, my plan for today is to work some more on the udev mystery
[07:39] <zyga> and then do bug triage
[07:39] <zyga> and some iteration on branches
[07:47]  * mborzecki wonders how to split a 2k 'WIP' commit nicely into smaller patches
[08:01] <Cruft> Why is there an autostart service running without snaps that require auto starting applications?
[08:04] <zyga> Cruft: the auto-start service runs once on session startup, in case there are things to do IIRC
[08:06] <Cruft> but through systemd and or X-gnome-autostart or whatever it is now "hidden" from freedesktop spec, wouldn't you not only be able to enable or disable the permission to do so individually but also know if that service should even run?
[08:07] <zyga> can you be more specific please, I'm not sure I understand what you meant
[08:08] <Cruft> its to help snapd make sure the snap program(s) that have autostart functionality are run on startup correct?
[08:08] <zyga> yes
[08:08] <Cruft> Wouldn't you already know upon installation and or boot that that was the case?
[08:08] <zyga> as those programs cannot use the normal method for starting
[08:08] <zyga> I'm sorry, know what?
[08:09] <zyga> that some programs auto-start?
[08:09] <Cruft> That they would otherwise autostart
[08:09] <Cruft> They are mounted on install right?
[08:09] <zyga> are you saying that the programs should notify the user somehow that they auto-start?
[08:09]  * zyga is confused as to what the exact problem is, sorry
[08:09] <zyga> yes, they are mounted
[08:09] <Cruft> No. I'm saying that the auto start service should not be run unless an auto start application exists
[08:10] <zyga> I see what you mean now
[08:10] <zyga> it's much easier this way
[08:10] <Cruft> Also that in the event that auto start applications exist, that it can be explicitly turned off if not already possible, therefor not running after
[08:10] <zyga> we'd have to enable or disable this
[08:10] <zyga> are you saying that you'd like to control this per app?
[08:11] <Cruft> both
[08:11] <Cruft> but A makes B easier
[08:11] <zyga> I think they are unrelated, A is a service that you can disable per user or globally
[08:11] <Cruft> I can control microphone permissions but not autostart? Eh.
[08:11] <zyga> B is new (per user) state that needs UI and APIs to drive
[08:12] <zyga> autostart is not an interface
[08:12] <zyga> I see what you mean but it's not done this way technically
[08:12] <Cruft> Is it just using freedesktop conventions to determine this?
[08:13] <Cruft> Within the snap(s)
[08:13] <zyga> somewhat, but it's more complex to prevent confinement escape
[08:13] <mborzecki> Cruft: kind of, the app cannot drop a random file under $HOME/.config/autostart, iirc the service looks inside ~/snap/<name>/ instead
[08:15] <Cruft> right so its using the same xdg / .config i guess per user autostart as a determination within the snap tree?
[08:15] <zyga> yes
[08:15] <zyga> there's also some extra layer
[08:15] <zyga> that matches the desktop file
[08:15] <zyga> again, to prevent confinement esape
[08:15] <zyga> we cannot just use the desktop file that was created by the app
[08:15] <Cruft> I'm more thinking in terms of deciding to run at all
[08:16] <zyga> eventually there will be a portal
[08:16] <zyga> and the UI will be nice
[08:16] <zyga> this makes it work with existing programs
[08:16] <zyga> without new APIs
[08:17] <mborzecki> Cruft: maybe it's somthing to consider, but the whole selecting which app runs by tweaking gnome session is a pita since the old days
[08:17] <Cruft> You must understand though that people who have no autostart snaps are now having their boot further slowed by a service to autostart snaps
[08:18] <zyga> is it this slow?
[08:18] <Cruft> Its not fast, it was slower than alot when I measured. That is how I found the service.
[08:19] <Cruft> I have many snaps but none autostart
[08:19] <mborzecki> Cruft: hmm the sevice actually globs inside ~/snap/*/current/.config/autostart
[08:19] <zyga> Cruft: unfortunately there's no easy way to make it conditional
[08:19] <Cruft> right so you would know at install time
[08:20] <zyga> Cruft: as snapd does not mediate the act of opting into or out of autostart
[08:20] <Cruft> to run the service in userspace
[08:20] <zyga> no, we don't know at install time
[08:21] <zyga> we only look in that auto-start service
[08:21] <zyga> and if the file is there and matches something in the snap definition
[08:21] <zyga> we start the snap app
[08:21] <zyga> we don't have an event when a running app enables auto-start
[08:23] <Cruft> So you have no first mount etc hook
[08:23] <Cruft> for current or whatever
[08:23] <zyga> this is not related to mounting
[08:23] <zyga> I don't think you understand how this works
[08:23] <zyga> when a running app decides to enable auto-start
[08:23] <zyga> it drops a file into an xdg location
[08:23] <zyga> we only re-map $HOME so it's not the real location
[08:24] <zyga> that's all
[08:24] <zyga> when a session starts, the auto-start service scans the per-snap $HOME of each snap
[08:24] <zyga> and looks for the xdg auto-start information
[08:24] <zyga> and then acts on it
[08:24] <zyga> that's it
[08:24] <zyga> there's no more logic
[08:24] <Cruft> So rather than scanning post mount it scans every time you boot
[08:25] <zyga> it's not post mount because this is dynamic
[08:25] <zyga> and it's not every time you boot
[08:25] <zyga> it's in the user session
[08:25] <zyga> there's no way to statically say you want to auto start an app via xdg
[08:25] <Cruft> So then why isn't the service disabled if no new snaps have been installed
[08:25] <zyga> you must create a desktop file in a specific location in the home directory
[08:26] <zyga> because it's not something we considered important, when there's nothing to do it's doing nothing pretty quickly
[08:26] <zyga> and making it better is really hard
[08:26] <zyga> and again
[08:26] <zyga> you misunderstand how it works when you talk about installed snaps, you can have one snap and it can opt in and out of autostart
[08:27] <zyga> so it's not about that
[08:27] <mborzecki> Cruft: w8, maybe i'm confused, which service are we discussing here? /etc/xdg/autostart/snap-userd-autostart.desktop ?
[08:27] <Cruft> I believe that was the one
[08:27] <Cruft> Let me check
[08:28] <Cruft> yes
[08:30] <mborzecki> Cruft: ok, so this one starts when your graphics session is coming up, scans ~/snap/*/current/.config/autostart for relevant desktop files, starts any snaps that want autostat and exits, if there are no desktop files dropped by the snaps, then it exits
[08:30] <ogra> Cruft, if it would scan post mount (i.e. before even GDM starts) it would have to scan *all* users homes instead of the home of the specific user that just logged in ... that would surely be a lot slower than running at session start
[08:31] <ogra> snaps are mouned by systemd during boot ... way before you reach any session you could access
[08:31] <ogra> *mounted
[08:31] <Cruft> Oh believe me, I saw.
[08:33] <mborzecki> Cruft: so you're saying the autostart service is running still after your session is fully up, or does it run slow during startup?
[08:33] <Cruft> Both
[08:33] <Cruft> and that it shouldn't be in either case.
[08:33] <ogra> sounds like these are simply bugs ...
[08:34] <mborzecki> Cruft: can you do `ps -ef |grep userd` ?
[08:34] <Cruft> It could literally check during updates at the same time
[08:34]  * zyga is confused about updates
[08:35] <Cruft> yes, there is a line with the pid, time, etc
[08:35] <mborzecki> Cruft: can you paste it?
[08:35] <Cruft> no, i'm not on that computer on this machine
[08:35] <Cruft> i can retype it i guess
[08:38] <mborzecki> Cruft: you can skip the pid, i'm interested in the command `snap userd ..`
[08:38]  * ogra could imagine that using a db instead of walking ~/snap/*/.config might speed up things quite a bit, but that would also mean completely moving away from freedesktop standards
[08:39] <Cruft> you could shard them out in sqlite if you use that
[08:39] <Cruft> as they currently stand
[08:40] <zyga> none of that matters if apps don't use that
[08:40] <zyga> so we support what apps do
[08:40] <Cruft> I'm not sure what you're asking me to type mborzecki
[08:40] <mborzecki> Cruft: `ps -ef|grep userd`, there should be a command in the last column that starts with `snap userd..`, please paste/type that in the channel
[08:40] <ogra> he wants the most right entry of the ps output 🙂
[08:41] <Cruft> snap userd
[08:41] <zyga> that's the other userd
[08:41] <zyga> not the auto-start thing
[08:45] <mborzecki> Cruft: that's the user session helper that exposes dbus api for snaps to request xdg-open, manage xdg-settings and some other thing i don't recall now, incoming requests are sanitized
[08:46] <ogra> ... and that specific one is rather unlikely to have any impact on session startup time ...
[08:46] <mborzecki> Cruft: so you're saying that one starts slow?
[08:46] <ogra> (as it starts async and nothing but snaps depend on it)
[08:46] <Cruft> Yes
[08:47] <Cruft> I can see that. I didn't realize this was go
[08:49] <Cruft> welp, looks like i need to Delve into it
[08:50] <mborzecki> Cruft: `snap userd` is actually started via dbus activation
[08:51] <mborzecki> Cruft: i don't think it shows up as a systemd --user service
[08:52] <Cruft> ah
[08:55] <Cruft> ok yeh I see the two dbus unconfined services for snapd userd
[08:59] <mborzecki> Cruft: yes, io.snapcraft.Settings and Launcher
[10:32] <zyga> mvo: o/
[10:32] <zyga> mvo: 2.45 is not released, right?
[10:33] <zyga> I mean, I see it in groovy
[10:33] <zyga> but focal has 2.44
[10:33] <mvo> zyga: I asked sil2100 to look at the 2.45.1 SRU, he said he will get to it today :)
[10:33] <mvo> zyga: but yeah, it's waiting in the unapproved queue
[10:34] <zyga> sure I just wanted to know
[10:34] <zyga> mvo: one more thing
[10:34] <zyga> mvo: the core snap is at 2.45 while snapd is at 2.45.1
[10:35] <zyga> is that expected?
[10:35] <mvo> zyga: maybe because of phasing, let me double check
[10:35] <mvo> zyga: hm, that sounds like we need to ask cachio what is going on there
[10:35] <zyga> okay
[10:36] <zyga> thanks, I just wanted to understand where we are to update bugs that are fix commited
[10:37] <mup> Bug #1878374 changed: UC20 stuck at installing system on specific Intel NVME stick <bot-comment> <uc20> <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1878374>
[10:38] <zyga> mvo: do you expect 2.45.1? I would like to update the launchpad milestones
[10:39] <zyga> oh. we have one :D
[10:39] <zyga> ok
[10:40] <mup> Bug #1878374 opened: UC20 stuck at installing system on specific Intel NVME stick <bot-comment> <uc20> <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1878374>
[10:43] <mup> Bug #1878374 changed: UC20 stuck at installing system on specific Intel NVME stick <bot-comment> <uc20> <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1878374>
[10:45] <zyga> I updated all the milestones that were open
[10:46] <zyga> mvo: is the next release going to be 2.45.2 or 2.46?
[10:50] <zyga> brb
[10:50] <mvo> zyga: there will be a 2.45.2 most likely we have some requests for this
[10:50] <zyga> I see
[10:52] <mup> PR snapd#8905 opened: bootloader: introduce managed bootloader, implement for grub <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8905>
[10:52] <mborzecki> pedronis: trivial piece ^^
[10:53] <pedronis> mborzecki: thanks, will try to look at it soon
[10:57] <mvo> degville: silly question, what should I use to add comments to a discourse page, i.e. something like "// XXX: needs update for the new fields" or similar?
[11:01] <degville> mvo: html comments work
[11:01] <degville> ie. <!-- comment -->
[11:02] <mvo> degville: is that what is what we use elsewhere too? if so, I will use it
[11:03] <mvo> degville: is the preview confused? in the preview the comment is displayed as is
[11:03] <degville> mvo: well, we use it on the docs pages because the html comments aren't visible in the final output. For general Discourse comments, though, it doesn't really matter - I don't think syntax highlighting works.
[11:04] <degville> mvo: it shouldn't be visible in the preview?
[11:05] <mvo> degville: hm, maybe I do something wrong, let me try again
[11:05] <degville> mvo: At least, I've just tried it and it's hidden for me.
[11:06] <mvo> degville: yeah, silly me, works
[11:06] <mvo> degville: thank you
[11:06] <degville> it's not very pretty.
[11:07] <mup> PR snapd#8906 opened: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8906>
[11:07] <mup> PR snapd#8907 opened: asserts: implement Database.FindSequence <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8907>
[11:33] <mup> PR snapcraft#3184 closed: build providers: check revision before switching <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3184>
[11:38] <zyga> mvo: is https://github.com/snapcore/snapd/pull/8436 something you wanted to cherry pick into 2.45.2?
[11:38] <mup> PR #8436: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8436>
[11:39] <zyga> I'm asking if I should target the bug report accordingly
[11:41] <zyga> I set the bug to target 2.46, if you want it in 2.45.2 just ping me and I'll adjust things
[11:41] <mvo> zyga: iirc it was not super urgent but I can double check
[11:41] <zyga> sure
[11:41] <zyga> 2.46 is fine
[11:41] <zyga> I'm only asking because it was squash merged
[11:50] <zyga> sil2100: are we using classic eth0 or the new "stable" names on core images?
[11:50] <zyga> sil2100: the context is a bug where pi4 has different behavior than prior images
[12:16] <pedronis> ijohnson: I re-reviewed #8683
[12:16] <mup> PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>
[12:17] <mup> PR snapd#8908 opened: overlord/snapstate: graceful handling of denied "managed" refresh schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8908>
[12:17] <mborzecki> pedronis: ^^
[12:36] <pedronis> mborzecki: reviewed
[12:37] <mborzecki> pedronis: thanks
[12:40] <zyga> pedronis: there's a request to extend the valid language for app commands to include the = sign, so that prog --opt=value would be allowed without wrappers
[12:41] <zyga> pedronis: currently the allowed app expression is:
[12:41] <zyga> var appContentWhitelist = regexp.MustCompile(`^[A-Za-z0-9/. _#:$-]*$`)
[12:41] <pedronis> zyga: it's related to snapcraft dropping wrappers support for core20
[12:41] <zyga> looking at this I think that adding = is probably okay
[12:41] <zyga> but I wanted to ask you for advice
[12:41] <zyga> indeed, it's mentioned in the bug report
[12:41] <pedronis> well, we need to think this through
[12:42] <zyga> sure, I've left it as whishlist
[12:42] <pedronis> zyga: feel free to assign to it to me
[12:42] <zyga> ok
[12:42] <pedronis> doesn't mean we'll get to it quickly, but it's blocked on me either way
[12:44] <zyga> sure
[12:44] <zyga> sil2100: do you know where to track bugs about raspberry pi kernel?
[12:44] <zyga> (on core)
[12:49] <ijohnson> Thanks pedronis
[12:56] <sil2100> zyga: hm, I guess I'd have to check with the ethernet device names, can't say from the top of my head
[12:56] <zyga> sil2100: the bug claims that pi4 uses eth0
[12:56] <zyga> sil2100: but earlier devices us en!@!#@!@#!
[12:56] <sil2100> zyga: as for the pi kernel bugs, I guess they're handled as any others - so fill in a bug for linux-raspi on LP :)
[12:57] <mup> PR snapd#8909 opened: interfaces/apparmor: allow snap-specific /run/lock <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8909>
[12:57] <zyga> thanks, that's what I needed
[12:58] <zyga> sil2100: hmm, no such project
[12:58] <zyga> oh well
[12:58] <zyga> standup time
[13:09] <sil2100> zyga: hah, it's not a project, it's a package: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/
[13:15] <ogra> zyga, linux-raspi for focal ... linux-raspi2 for anything before (see https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1881623 that was triaged by juerg (our pi kernel maintainer)
[13:15] <mup> Bug #1881623: USB support missing in initrd makes booting core with writable on USB impossible <linux-raspi (Ubuntu):New> <linux-raspi2 (Ubuntu):Confirmed> <linux-raspi2 (Ubuntu Xenial):New> <linux-raspi2 (Ubuntu Bionic):New> <linux-raspi (Ubuntu Focal):New> <https://launchpad.net/bugs/1881623>
[13:15] <zyga> ogra: ah, a source package
[13:15] <zyga> ogra: got that, thanks!
[13:15] <ogra> yep
[13:38]  * zyga breaks for lunch
[13:57] <mup> PR snapd#8904 closed: snapstate: use testutil.HostScaledTimeout() in snapstate tests <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8904>
[14:21] <zyga> re
[14:44] <mup> PR snapcraft#3179 closed: Maven plugin: improve error message when target libs are not found <bug> <Created by edumucelli> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3179>
[14:48] <pstolowski> i managed to reproduce https://bugs.launchpad.net/snapd/+bug/1882957 with my spread test. funny thing is it happend after fleshing things out in the test and re-arranging some ops
[14:48] <mup> Bug #1882957: Snapd `internal error: connection "[slot] [plug]" not found in state` <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1882957>
[14:58] <cachio> mvo, hey
[14:58] <cachio> mvo, the snap ubuntu-clock-app isnot in the repo anymore, so the test for unity fails
[14:59] <cachio> do you know any other snap that could be used instead
[14:59] <cachio> ?
[15:03] <mup> PR snapd#8910 opened: usersession: support additional zoom URL schemes <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8910>
[15:08] <mborzecki> hm gadget Update/Backup/Rollback could use a little refactor
[15:10] <mborzecki> anyways, errands, bbl
[15:14] <mvo> cachio: uh, a good question
[15:29]  * cachio lunch
[15:35] <abeato> zyga, hey, I have seen a problem with layouts, in a qemu environment where I installed NM, it looks like the layout is not really happening, I cannot see the files inside the snap. If I look at the mount namesapce, I see:https://paste.ubuntu.com/p/sDCdbm9Jqz/
[15:35] <zyga> hey!
[15:35] <abeato> hi :)
[15:35] <zyga> ah , //deleted
[15:35] <abeato> yeah...
[15:35] <zyga> I'm doing bug triage now, can you please show me some more context
[15:36] <abeato> I am installing on qemu, while running spread tests
[15:36] <abeato> I have a snap version with core18, and I install on top a core20 version of the snap
[15:36] <abeato> the first does not use layouts, the second does
[15:37] <abeato> if I reinstall the snap, things look good and there is no //deleted string
[15:39] <zyga> what are the layout definitions
[15:39] <zyga> actually, I think it's best if you report a bug
[15:39] <zyga> with all the details
[15:39] <zyga> I'll try to look at it in the evening
[15:39] <zyga> I have a few more bugs to go through today
[15:40] <abeato> zyga, sure will do - I wanted to double check if this was a known issue before
[15:40] <zyga> it may be known behavior
[15:41] <zyga> depending on the paths used
[15:41] <zyga> the //deleted thing is really interesting part of linux
[15:41] <zyga> I didn't know about it before I started working on snapd
[15:41] <abeato> seems like some timing problem, some times happens, some times it does not
[15:43] <zyga> abeato: I think it's not timing as snapd is freezing the world for mount changes
[15:43] <zyga> probably sequence
[15:43] <zyga> I'll gladly analyze it in detail and explain what's going on
[15:49] <ijohnson> cachio: for https://github.com/snapcore/snapd/pull/8902#issuecomment-648236050 how did you reproduce this ?
[15:49] <mup> PR #8902: tests: fix assertion disk handling for nested UC systems <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8902>
[15:52] <abeato> zyga, https://bugs.launchpad.net/snapd/+bug/1884806
[15:52] <mup> Bug #1884806: layouts are not honored some times <snapd:New> <https://launchpad.net/bugs/1884806>
[15:57] <zyga> abeato: thank you!
[15:58] <abeato> np
[15:59] <zyga> abeato: btw, what is /usr/var?
[16:00] <abeato> zyga, a folder with some config files for NM
[16:00] <zyga> I mean, I don't have /usr/var on my classic system
[16:00] <zyga> it's a weird location
[16:00] <zyga> is that hardcoded in n-m?
[16:01] <abeato> zyga, it is the default in nm, unless you change it with config options - which we do in the deb
[16:01] <abeato> for the snap anyway we override it
[16:01] <zyga> I see
[16:01] <zyga> ok
[16:02] <zyga> I'll look more closely
[16:02] <zyga> can you do one quick test perhaps
[16:02] <abeato> sure
[16:02] <zyga> refresh the exact same revision twice
[16:02] <zyga> just install --local perhaps
[16:02] <zyga> and see if that has the same effect
[16:02] <abeato> hm I did not know that one
[16:03] <abeato> zyga, not sure what is that? 'snap install --local' does not exist
[16:03] <abeato> zyga, refreshing the same revision actually works
[16:04] <abeato> zyga, also disabling then enabling the snap
[16:04] <zyga> ah, sorry
[16:04] <zyga> not local
[16:04] <zyga> I meant --dangerous :)
[16:04] <zyga> and just install the .snap file
[16:05] <zyga> instaling the same snap file twice tests if layout system can re-construct a no-update update
[16:07] <abeato> zyga, yeah, that works
[16:07] <zyga> abeato: thanks for checking, that's useful to know
[16:08] <zyga> abeato: perhaps there's an issue with core18 -> core20 transition
[16:08] <zyga> I'll debug this
[16:08] <abeato> great
[16:13] <mup> PR snapd#8911 opened: asserts,seed: split handling of essential/not essential model snaps <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8911>
[16:13] <pedronis> ijohnson: this ^ tries to address some of your concerns about the seed code
[16:14] <ijohnson> thanks I will take a look
[16:31] <mvo> pedronis: I updated 8889 a bit
[16:33] <pedronis> mvo: thx, adding it back to my queue
[16:44] <mup> PR snapcraft#3185 opened: cli: allow promoting from edge without --yes <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3185>
[16:59] <zyga> mvo: I'll take a break now, see you tomorrow
[16:59] <zyga> after Thursday typing won't be such a chore
[17:20] <cachio> ijohnson, sorry
[17:20] <cachio> spread -debug google-nested:ubuntu-16.04-64:/tests/nested/core/image-build
[17:20] <ijohnson> cachio: I am running `spread --debug -v google-nested:...:tests/nested/` now, and have not seen any failures yet
[17:20] <cachio> spread -debug google-nested:ubuntu-16.04-64:tests/nested/core/image-build
[17:21] <ijohnson> haha literally as I just sent that it failed on a tet
[17:21] <ijohnson> let me look
[17:21] <cachio> core-18 workerd perfect here
[17:22] <cachio> ijohnson, also failed with timeout uc20
[17:22] <ijohnson> cachio: yes I just saw the uc20 failure here, I will investigate
[17:22] <ijohnson> actually I need to break for lunch, but will investigate more afterwards
[17:22] <cachio> ijohnson, something that I forgot SPREAD_USE_CLOUD_INIT=false
[17:23] <cachio> you need to use that to force the use of the assertion disk
[17:23] <cachio> otherwise by default it will use cloud_init
[17:23] <ijohnson> cachio: let's chat a bit later after I'm back from lunch
[17:24] <cachio> ijohnson|lunch, sure
[17:46] <cachio> mvo, should we run the unity test in nightly in case there is not any unity snap available?
[17:52] <ijohnson|lunch> cachio: I didn't reproduce that error with my current patchset, let me push it up before my next meeting
[17:52] <ijohnson|lunch> cachio: I will attach the log from my run in the PR
[17:52] <cachio> sure
[17:53] <cachio> I'll make another tun
[17:53] <cachio> run
[17:55] <ijohnson> cachio: please pull from the branch, but here's the output from my most recent run https://github.com/snapcore/snapd/pull/8902#issuecomment-648321737
[17:55] <mup> PR #8902: tests: fix assertion disk handling for nested UC systems <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8902>
[17:55] <mvo> cachio: I think we can stop testing unity if we don't have any snaps. let's remove it
[17:56] <cachio> mvo, sure, thanks
[17:56] <mvo> yw
[17:56] <ijohnson> cachio: I didn't try with preparing all of these without cloud-init yet I just want to make sure that the PR is good when using cloud-init for the users, a followup will use the assertions disk
[17:57] <ijohnson> cachio: in other words the spread run I linked to in the PR comment doesn't have SPREAD_USE_CLOUD_INIT=false defined
[17:57] <ijohnson> cachio: so if you could test just normally that would be great to see
[17:57] <cachio> ijohnson, ok
[17:57] <ijohnson> thanks
[17:57] <cachio> let me try
[17:57] <ijohnson> I will look more after my meeting now
[18:19] <cachio> ijohnson, in core16 workerd with SPREAD_USE_CLOUD_INIT=false and without
[18:19] <cachio> so the fix works
[18:19] <cachio> let me check uc20
[18:34] <ijohnson> cachio: yes let me look at why the uc20 ones failed
[18:34] <mup> PR snapcraft#3186 opened: Riscv64 support <Created by xnox> <https://github.com/snapcore/snapcraft/pull/3186>
[18:34] <ijohnson> cachio: for me, only tests/nested/core20/basic and 64:tests/nested/manual/core20-early-config failed
[18:36] <cachio> ijohnson, yes, this is something different
[18:36] <cachio> I need to take a look tomorrow to that one
[18:57] <cachio> ijohnson, so, on uc20 the user assertion creates the user but then I see https://paste.ubuntu.com/p/zgDk4hWFqb/
[18:57] <cachio> error: too early for operation, device not yet seeded or device model not acknowledged
[18:57] <cachio> ijohnson, I am running again
[18:57] <ijohnson> cachio: ah interesting
[18:58] <ijohnson> cachio: I hit your bug with the /dev/mapper/loop2p1 issue, it's a race condition but I can fix it easily, I will push something up
[18:58] <roadmr> jdstrand: heads up, xnox is about to send your way a bug about making review-tools happy with a new architecture
[18:58] <cachio> perhaps we'll need to wait until seeding is copmleted, right?
[18:59] <ijohnson> cachio: perhaps
[18:59] <ijohnson> cachio: for uc20 probably yes, but the /dev/mapper issue is not related to seeding
[18:59] <ijohnson> (but I know how to fix it
[18:59] <ijohnson> )
[19:00] <jdstrand> roadmr: that will be interesting to fix, as I likely will need core20 but focal has bugs in various places
[19:00] <roadmr> the fun
[19:14] <ijohnson> cachio: did you ever figure out the deal with uc20 nested VMs rebooting constantly ?
[19:14] <cachio> ijohnson, well, it used to reboot 1 once by using -smp 1
[19:15] <ijohnson> cachio: in the log I'm looking at the nested VM got rebooted at least 10 times before the spread timeout got hit, looks like less than a minute after it booted it got rebooted
[19:15] <cachio> ijohnson, I saw different bug reports similar
[19:15] <cachio> but not sure the reason
[19:16] <cachio> ijohnson, reboots in install mode?
[19:16] <cachio> run mode?
[19:16] <ijohnson> cachio: in run mode
[19:16] <ijohnson> cachio: although actually maybe install mode too, don't remember
[19:16] <ijohnson> let me show you the log
[19:16] <cachio> it is the same I see
[19:16] <cachio> here in the last log
[19:19] <ijohnson> cachio: this is the serial boot log from the nested VM: https://pastebin.ubuntu.com/p/b9PHpFkFKm/
[19:20] <ijohnson> yeah it was rebooted 6 times I guess, all the unintended reboots were in run mode
[19:20] <cachio> ijohnson, well this is not normal
[19:20] <cachio> at least should reboot 1 extra time
[19:20] <cachio> but not more
[19:21] <ijohnson> haha yeah I would agree it is not normal for a VM to get randomly rebooted 6 times at random points in the boot sequence
[19:21] <cachio> perhaps it is related to the usr assertion
[19:21] <cachio> hehehe
[19:22] <ijohnson> cachio: could be, this run was with SPREAD_USE_CLOUD_INIT=false just to see what happens with the assertions on all the systems
[19:22] <cachio> I triggered new executions with and without user assertion to see if that could be the reason
[19:22] <ijohnson> it eventually made it to a successful boot and is running normally now, but it did not import the assertion on uc20
[19:23] <cachio> last run I did worked, it took 15 minutes to prepare the nested vm and connecto shrough ssh
[19:24] <ijohnson> cachio: it is very slow
[19:24] <cachio> ijohnson, yes
[19:24] <mup> PR snapcraft#3176 closed: tools: fix environment-setup to work on aarch64 <tooling> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3176>
[19:24] <cachio> perhaps there were some reboots
[19:25] <cachio> ijohnson, this is the last run https://paste.ubuntu.com/p/83MKxjngDv/
[19:25] <ijohnson> cachio: I think as long as this branch is working with the default  SPREAD_USE_CLOUD_INIT=true the way the tests run now, we should push forward with this branch and I can propose follow-ups to fix using assertions
[19:25] <cachio> ijohnson, sure
[19:25] <ijohnson> cachio: so it seems it is randomly failing with uc20 then
[19:26] <cachio> ijohnson, yes
[19:26] <cachio> this is related to some errors we have seen with kvm and gce
[19:26] <ijohnson> cachio: ok I just pushed up a fix for the loop device not available problem you saw, it should eliminate the race condition, I think we should probably merge this then and continue with a followup PR
[19:26] <cachio> if you run without kvm then never reboots
[19:26] <ijohnson> cachio: what do you think ?
[19:27] <cachio> ijohnson, it is ok
[19:27] <cachio> it is working pretty well now
[19:27] <cachio> just that problem but shouldn't affect the current nightly executions
[19:27] <ijohnson> cachio: what do you mean about not rebooting without kvm ?
[19:27] <ijohnson> cachio: you only see these random reboots with kvm enabled ?
[19:28] <cachio> we use qemu with kvm aceleration
[19:28] <ijohnson> i.e. -machine ubuntu-q35,accel=kvm ?
[19:28] <cachio> if I run without kvm acceleration those random reboots never happen
[19:28] <cachio> ijohnson, right
[19:28] <ijohnson> ah very interesting
[19:28] <cachio> the problem is that if we don't use kvm then the execution is very slow
[19:29] <ijohnson> right
[19:29] <cachio> and something interesting is that if we dont use ovmf the reboots don't happen
[19:30] <ijohnson> cachio: where did you report this bug again? I remember reading through your LP bug you filed but I don't remember where now
[19:30] <cachio> so it is a combination between could + ovmf + kvm
[19:30] <cachio> ijohnson, a time agou I created the bug in launchpad
[19:30] <cachio> in kvm project
[19:30] <ijohnson> do you have the link ?
[19:30] <cachio> ijohnson, let me check
[19:33] <cachio> ijohnson, https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1872803
[19:33] <mup> Bug #1872803: VM reboots using qemu and kvm with ovmf <qemu (Ubuntu):Expired> <https://launchpad.net/bugs/1872803>
[19:34] <cachio> ijohnson, this issue should address that https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1882774
[19:34] <mup> Bug #1882774: issues with secondary VMX execution controls <sts> <verification-done> <verification-done-focal> <Ubuntu Cloud Archive:New> <qemu (Ubuntu):Fix Released> <qemu (Ubuntu Focal):Fix Committed> <https://launchpad.net/bugs/1882774>
[19:36] <ijohnson> thanks cachio, very interesting
[19:56] <mup> Bug #1874156 changed: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156>
[20:05] <mup> Bug #1874156 opened: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156>
[20:08] <mup> Bug #1413410 changed: Unable to match embedded NULLs in unix bind rule for abstract sockets <aa-kernel> <aa-parser> <AppArmor:Fix Released by jjohansen> <AppArmor 2.9:In Progress> <Snappy:Invalid> <apparmor (Ubuntu):Fix Released> <https://launchpad.net/bugs/1413410>
[20:08] <mup> Bug #1874156 changed: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156>
[20:09] <ijohnson> cachio: interesting, another nested uc20 w/ assertions enabled failed due to all the random reboots, but it never got through to run mode: https://pastebin.ubuntu.com/p/4ggsB5mbhY/
[20:14] <cachio> ijohnson, let me try with the qemu from proposed
[20:15] <cachio> that could contains a fix
[20:35] <mup> PR snapcraft#3185 closed: cli: allow promoting from edge without --yes <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3185>
[20:38] <ddstreet> hi all, anyone know if snaps are building and/or providing dbgsyms yet? or is that still a future item?
[20:46] <ijohnson> hi ddstreet what's been recently implemented is support for gdbserver, where a gdbserver will be run from inside a snap's confinement such that you can then connect from outside snap confinement to that gdbserver to debug the snap
[20:46] <ijohnson> ddstreet: that will allow you to have dbgsysm exist on the host outside of the snap and debug the snap
[20:47] <ijohnson> there's a forum post about this here: https://forum.snapcraft.io/t/new-experimental-snap-run-experimental-gdbserver-option/18227
[20:48] <ddstreet> ijohnson thanks! and are snaps now built with dbgsyms included?
[20:48] <ijohnson> ddstreet: that is up to each snap, most are not built with dbgsyms afaik
[20:49] <ddstreet> hmm ok, so do you know if at least canonical-provided snaps include dbgsyms?  e.g. chromium?
[20:49] <ddstreet> or any documented way to tell if a snap includes dbgsym?
[20:49] <mup> PR snapd#8912 opened: tests: update unity app on nightly test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8912>
[20:49] <ijohnson> ddstreet: there is no documented way to tell if a snap includes dbgsym outside of just looking at it
[20:49] <ijohnson> ddstreet: why do you ask ?
[20:51] <ddstreet> more recently there's an email to ubuntu-devel-discuss asking how to debug chromium, and it was pointed out it's a snap now, which led to discussion about not being able to debug snaps
[20:51] <ddstreet> but more in general, i'm part of canonical sustaining engineering, and it's something that we are going to face at some point in the very near future
[20:52] <ijohnson> ddstreet: right so today you have both snap run --gdb chromium, which will run gdb inside snap confinement, but then you can't load debug symbols without modifying the snap to include those
[20:53] <ijohnson> ddstreet: that is helped by gdbserver, but where we still fall short is that we don't have equivalent debug symbol snaps that could be uploaded alongside the actual running snap
[20:53] <ijohnson> ddstreet: not sure if that's currently on the roadmap, but I know that's been discussed to have a new snap type just for debug symbols to be produced at the same time
[20:54] <jdstrand> roadmr: hey, in case you didn't see in the bug comment from 30 seconds ago, 20200623-2050UTC has the riscv64 update
[20:54] <roadmr> jdstrand: oh I didn't :)
[20:54] <jdstrand> roadmr: if you can pull whenever it makes sense for you, that would be great
[20:54] <roadmr> I'll queue it up!
[20:54] <jdstrand> thanks :)
[20:55]  * roadmr checks time
[20:55] <jdstrand> xnox: fyi (and thanks again)
[20:55] <roadmr> just enough time to land/QA today so maybe it can be deployed tomorrow
[20:55] <jdstrand> xnox: ^
[20:55] <roadmr> I'm off tomorrow but the awesome team might deploy
[20:55] <jdstrand> cool
[21:20] <mup> PR snapcraft#3173 closed: cli: use snap pack instead of mksquashfs <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3173>