[05:14] <mborzecki> morning
[05:43] <zyga> o/
[05:44] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/8726
[05:44] <zyga> it's a one liner and I have a follow-up it opens
[05:44] <mup> PR #8726: tests: silence stderr from dbus-monitor <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8726>
[05:46] <mborzecki> zyga: ack
[05:47] <zyga> for some context, privately I've been using a version of https://github.com/snapcore/snapd/pull/8728
[05:47] <mup> PR #8728: tests: detect stray dbus-daemon <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8728>
[05:48] <zyga> and it essentially prints a TODO list of tests to improve
[05:49] <zyga> mborzecki: I replied but let's chat here
[05:49] <zyga> right now there's nothing more on stderr, if it goes to a file it'd be rather short-lived as that directory goes away when session-tool quits
[06:13] <mborzecki> zyga: if something fails does is the directory removed too?
[06:16] <zyga> yes
[06:16] <zyga> I looked at the rest of the script and we log other things there
[06:16] <zyga> but it's a remnant of development when I just would comment out the cleanup logic
[06:21] <pedronis> fedora-32 is listed in the workflows but doesn't exist in spread.yaml, this is making it fail constantly
[06:24] <zyga> pedronis: oh?
[06:24] <zyga> perhaps mvo added that with the caching PR
[06:25] <pedronis> seems so
[06:25] <pedronis> zyga: see here:  https://github.com/snapcore/snapd/pull/8729
[06:25] <mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8729>
[06:27] <zyga> yeah, indeed, it's there in the patch
[06:28] <zyga> it's not marked as requires so it was masked by opensuse failing as well, I suspect
[06:29] <zyga> if we cannot get a working image today I'll drop it from the matrix with a comment
[06:29] <pedronis> it was marked as required
[06:29] <pedronis> or maybe I'm confused
[06:29] <pedronis> anyway
[06:30] <pedronis> #8729 needs a 2nd review
[06:30] <mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8729>
[06:37] <mborzecki> i'll fix the sanpd selinux policy today so we'll be able to merge cachio's fedora 32 pr
[06:39] <zyga> pedronis: https://github.com/snapcore/snapd/pull/8729#pullrequestreview-418005303
[06:39] <mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8729>
[06:39] <pedronis> mvo: mborzecki: hi, Pawel's #8697 needs reviews
[06:39] <zyga> mborzecki: cool
[06:39] <mup> PR #8697: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
[06:41] <mvo> pedronis: sure, looking
[06:42] <mup> PR snapd#8723 closed: github: remove workaround for bug 133 in actions/cache <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8723>
[06:43] <mup> PR snapd#8721 closed: devicestate, sysconfig: revert support for cloud.cfg.d/ in the gadget <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8721>
[06:55] <mup> PR snapd#8729 closed: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8729>
[07:03] <pstolowski> morning
[07:14] <mup> PR snapd#8730 opened: data/selinux: allow snapd to remove/create the its socket <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8730>
[07:16] <mborzecki> quick drive by fix when testing package updates pushed by Eighth_Doctor ^^
[07:16] <pstolowski> mborzecki: hi, can you take another look at https://github.com/snapcore/snapd/pull/8697 ?
[07:16] <mup> PR #8697: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
[07:16] <mborzecki> sure
[07:22] <zyga> pstolowski: small comment https://github.com/snapcore/snapd/pull/8697/files#r430205753
[07:22] <mup> PR #8697: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
[07:23] <zyga> not incorrect, just spreading the awesomeness of make
[07:30] <pstolowski> zyga: that's nice, thank you
[07:31] <mvo> zyga: oh, nice!
[07:31] <pedronis> mvo: the prereq has landed squash merged, now #8711 needs a 2nd review and hopefully to be (almost) green
[07:31] <mup> PR #8711: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout <Needs Samuele review> <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8711>
[07:31] <mvo> zyga: this should make some of the other stuff we do much more readable if we use this trick
[07:32] <mvo> pedronis: \o/ I have a look
[07:32] <zyga> mvo: cool :)
[07:33] <zyga> mvo: it's annoying we need to repeat this across packaging
[07:33] <zyga> I wish we'd use snaps.mk more
[07:34] <zyga> brb
[07:34] <mvo> zyga: unfortunately I don't think that's an option for debian/ because if we ever want someone to maintain this it has to be as clsoe as possible to a "standard"
[07:35] <zyga> mvo: I don't think so, it's not unlike dh_auto* and using a makefile in the upstream project
[07:35] <zyga> mvo: it's all about integrating dpkg-buildflags inside our native makefile
[07:43] <mup> PR snapd#8731 opened: snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8731>
[07:43] <mvo> pedronis: I backported 8711 to 2.45, straight cherry-pick did unfortunately not work
[07:44] <pedronis> mvo: it's because of the prereq? #8729 ?
[07:44] <mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8729>
[07:44] <pedronis> or something in it itself?
[07:46] <pedronis> mvo: ah, you backported the prereq actually https://github.com/snapcore/snapd/pull/8731 ?
[07:46] <mup> PR #8731: snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8731>
[07:47] <pedronis> mvo: there's a bit of extra tests in boot, do they pass?
[07:51] <pedronis> mvo: we should backport #8721
[07:51] <mup> PR #8721: devicestate, sysconfig: revert support for cloud.cfg.d/ in the gadget <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8721>
[07:59] <zyga> pstolowski: with this trick we could actually reduce quite a lot of clutter in the code building commands
[07:59] <zyga> pstolowski: with this trick we could actually reduce quite a lot of clutter in the code building commands
[07:59] <pstolowski> zyga: ok, but perhaps as followups
[07:59] <zyga> yes, totally
[07:59] <pstolowski> zyga: i'd really like to get this landed to unblock stuff
[07:59] <zyga> let me do it after your bits land
[08:02] <mvo> pedronis: 8721> yes, looking at this too
[08:09] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/8730 ?
[08:09] <mup> PR #8730: data/selinux: allow snapd to remove/create the its socket <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8730>
[08:13] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8656#discussion_r430233548
[08:13] <mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
[08:16] <pstolowski> siure
[08:20] <mborzecki> i'll force push to cachio's f32 pr and drop the last commit he made
[08:20] <mup> PR snapd#8726 closed: tests: silence stderr from dbus-monitor <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8726>
[08:21] <zyga> ta mvo
[08:21] <zyga> and mborzecki :)
[08:21] <mup> PR snapd#8725 closed: testutil/exec.go: set PATH after running shellcheck <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8725>
[08:24] <mup> PR snapd#8730 closed: data/selinux: allow snapd to remove/create the its socket <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8730>
[08:25] <mup> PR snapd#8604 closed: interfaces/builtin/desktop: do not mount fonts cache on distros with quirks <Squash-merge> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8604>
[08:41] <mvo> 8351 needs a second review
[08:44] <mvo> pedronis: do you want to do a review of 8661? it has two +1 at this point (but none from you)
[08:47] <mup> PR snapd#8732 opened: data/selinux: update policy to allow forked processes to call getpw*() <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8732>
[08:47] <mborzecki> pstolowski: another one for you ^^
[08:47] <pstolowski> mborzecki: siure
[08:47] <pstolowski> grr
[08:47] <pstolowski> *sure
[08:48] <pstolowski> zyga: can you remind me where in the spread suite do we check for leftovers from namespaces etc?
[08:48] <zyga> pstolowski: what do you mean by leftover from namespaces?
[08:49] <pstolowski> zyga: sorry, probably mount changes; anything that lxd can leave behind
[08:50] <zyga> I see
[08:50] <zyga> I don't think we do that regularly
[08:50] <zyga> we kind of do it in one spot in mount-ns test
[08:50] <zyga> a branch that I have long open tried to but it picked up too many failures so it was unable to land
[08:50] <zyga> we may get that, a bit, with invariant-tool
[08:50] <pstolowski> zyga: aah, mount-ns test, i think that was it
[08:50] <zyga> but it needs to be done still
[08:52] <pstolowski> thanks
[08:57] <zyga> brb
[09:00] <pedronis> mvo: ? I don't see the 2nd review
[09:01] <pedronis> mvo: as I remarked I think we should apply mborzecki idea of trying not to restart if nothing has changed
[09:01] <pedronis> mvo: I think it needs a review from pstolowski
[09:03] <pstolowski> pedronis, mvo i'll review it in a bit (and also the vitality PR)
[09:04] <zyga> re
[09:06] <mup> PR snapd#8711 closed: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout <Needs Samuele review> <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8711>
[09:06] <pedronis> mvo: ^ I squash-merged it
[09:08] <mvo> pedronis: \o/
[09:09] <mvo> pedronis: re 8661> sorry, ian did two +1 I misread that
[09:10] <pedronis> ah, was confused for a sec
[09:10] <pedronis> pstolowski: actualFsTypeAndMountOptions doesn't need to return an error anymore as well
[09:10] <pstolowski> pedronis: missed that, thanks
[09:11] <pedronis> pstolowski: np, but that's where I started thinking about this, because I had move the call to it and then wondered if it would change the failure modes but actually it can't error in itself
[09:12] <pedronis> *I had you
[09:13] <pedronis> pstolowski: mvo: do we need/want the preseed fixes in 2.45.1 ?
[09:14] <mborzecki> quick errand, back in 30
[09:16] <mup> PR core20#65 closed: Do not attempt signing changes during snap build <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/65>
[09:16] <pedronis> mvo: this is the comment I was referring to in 8661: https://github.com/snapcore/snapd/pull/8661#discussion_r427920348
[09:16] <mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
[09:16] <pstolowski> pedronis: that would be nice to have
[09:17] <mup> Issue core20#63 closed: fix travis builds with new subiquity from git <Created by xnox> <Closed by xnox> <https://github.com/snapcore/core20/issue/63>
[09:17] <mup> Issue core20#66 opened: Use focal base in travis <Created by xnox> <https://github.com/snapcore/core20/issue/66>
[09:17] <pstolowski> otherwise it will take long time before it's easily usable with lxd
[09:19] <mvo> pedronis: preseed> it would be a good idea, yes
[09:20] <mvo> pedronis: 8661> aha, sorry, I will look at this
[09:24] <mup> PR core20#49 closed: fix broken symlinks in /etc/writable <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/49>
[09:26] <zyga> mvo: I will most likely miss standup today
[09:26] <zyga> mvo: I'll send notes to the standup doc
[09:27] <zyga> I may join from a phone if I have the conditions to
[09:30] <mvo> zyga: ok
[09:30] <pedronis> pstolowski: mvo: #8697 failed on centos-8, seems unrelated but not sure
[09:30] <mup> PR #8697: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
[09:31] <pstolowski> pedronis: yes, i've restarted it
[09:35]  * zyga goes to look at 8697 restart not wasting money anymore
[09:47] <mborzecki> re
[10:07] <pedronis> mborzecki: Ian made a suggestion in #8718 then it should be good to go
[10:07] <mup> PR #8718: boot, many: require mode in modeenv <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8718>
[10:18] <mborzecki> pedronis ijohnson  thanks for the reviews
[10:18]  * zyga hugs mvo
[10:18] <zyga> mvo: the caching behavior is BRILLIANT
[10:18] <zyga> 2 seconds
[10:18] <mborzecki> need to address some commentrs in 8716 too
[10:18] <zyga> 0.00 cost
[10:18] <mborzecki> zyga: hah nice :P
[10:18] <zyga> I wonder if this will show up in load charts on the spread runner
[10:19] <zyga> as we're usually bound by memory
[10:19] <ijohnson> morning folks
[10:20] <mborzecki> ijohnson: heya
[10:20] <ijohnson> zyga: re: your comment on 8729 about the header being one byte larger than magic, the magic bytes is just 4 bytes, so a header of 20 bytes already is 16 bytes larger ?
[10:20] <ijohnson> hey mborzecki
[10:20] <zyga> ijohnson: yeah but it's a constannt
[10:20] <mup> PR snapd#8733 opened: tests: port document-portal-activation to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8733>
[10:20] <zyga> it's okay but not for the right reasons :)
[10:20] <ijohnson> zyga: so you think it should be only 5 bytes ?
[10:21] <zyga> I think it should be exactly len(magic) + 1
[10:21] <zyga> :D
[10:21] <ijohnson> got it
[10:23] <mup> PR snapd#8734 opened: tests: port interfaces-wayland to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8734>
[10:23] <mup> PR snapd#8735 opened: snap/snapfile,squashfs: followups from 8729 <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8735>
[10:23] <ijohnson> zyga: applied in a followup ^
[10:23] <zyga> super
[10:23] <zyga> thanks!
[10:24] <zyga> I was going to do it myself but I was working on a streak of patches
[10:33] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8736
[10:33] <mup> PR #8736: tests: log stderr from dbus-monitor <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8736>
[10:33] <pedronis> ijohnson: not a fan of len(magic)+1, it's not particularly better or worse than the existing especially now that its in squashfs itself
[10:33] <mup> PR snapd#8736 opened: tests: log stderr from dbus-monitor <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8736>
[10:34]  * zyga returns to https://github.com/snapcore/snapd/pull/7825
[10:34] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[10:34] <pedronis> ijohnson: I'll push something else there
[10:34] <ijohnson> pedronis: ok
[10:34] <pedronis> ijohnson: I mean a 5 bytes file is never a valid squashfs anyway
[10:34] <ijohnson> well that's not really for us to decide ?
[10:35] <ijohnson> unsquashfs is the ultimate decider of if it's a valid squashfs ?
[10:35] <pedronis> ijohnson: not but as a predictor this is worse than before
[10:35] <pedronis> ijohnson: if we didn't care we could use len(magic) and Equal
[10:35] <ijohnson> I mean for something that's called magic I wouldn't expect it to be perfect
[10:36] <pedronis> why the +1
[10:36] <pedronis> anyway I will do yet something else
[10:36] <ijohnson> and I think we are splitting hairs over a tiny thing
[10:36] <ijohnson> sure feel free
[10:36] <ijohnson> I just took zyga's suggestion
[10:36] <ijohnson> I have no strong feelings about this really
[10:36] <ijohnson> just feels a bit pointless
[10:36] <pedronis> ijohnson: I know, I disagree with the suggestion, doing nothing would have been fine
[10:37] <pedronis> ijohnson: also fn to f is not an improvement either
[10:37] <pedronis> ijohnson: anyway, it's not your problem anymore, I will push something there
[10:37] <mup> PR snapd#8737 opened: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8737>
[10:41] <pstolowski> Cannot allocate google:opensuse-tumbleweed-64: cannot allocate new Google server for opensuse-tumbleweed-64: invalid value for field 'resource.shieldedInstanceConfig': ''. Shielded VM Config can only be set when using a UEFI-compatible disk
[10:49] <zyga> pstolowski: known
[10:49] <zyga> sergio needs to fix the images
[10:49] <pstolowski> ok
[11:07] <mup> PR snapd#8731 closed: snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8731>
[11:12] <mup> PR snapd#8737 closed: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8737>
[11:13] <mup> PR snapd#8738 opened:  snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8738>
[11:25] <pedronis> ijohnson: once I was looking there, I added some tests to 8735 as well
[11:25] <ijohnson> pedronis: ok, seems the scope of the PR has greatly increased though
[11:27] <ijohnson> anyways approved it
[11:27]  * ijohnson afk for bit
[11:32] <pedronis> pstolowski: zyga: I tweaked/expanded a little bit #8729, it needs a re-review
[11:32] <mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8729>
[11:32] <zyga> yeah, reviewing now
[11:32] <pstolowski> okay
[11:32] <pstolowski> pedronis: i've commented on the tooling proposal
[11:35] <zyga> pedronis: reviewed
[11:37] <pstolowski> pedronis: hmm but 8729 was merged?
[11:37] <pedronis> heh sorry
[11:38] <pedronis> pstolowski: I meant #8735, but another review is not stricly needed anymore
[11:38] <pstolowski> ah 8735 i guess
[11:38] <mup> PR #8735: snap/snapfile,squashfs: followups from 8729 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8735>
[11:38] <pstolowski> yep
[11:40] <pedronis> pstolowski: seems 8697 can be merged now
[11:41] <pedronis> which should unblock 8533
[11:42] <zyga> pstolowski: thanks for commenting there
[11:42] <zyga> pedronis: I agree with pawel's comments
[11:43] <zyga> pedronis: I don't think we need a distinction between suite/task in the name, a common prefix plus something relevant to the tool function is good for me
[11:43] <mup> PR snapd#8697 closed: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8697>
[11:43] <zyga> pedronis: if you pick a name for session tool I'll do a test mass patch to see how it looks like
[11:44] <pedronis> zyga: I'm not against the prefix, my issue is that I really care about distinguishing things that affects state across tasks vs not
[11:45] <zyga> hmmm
[11:46] <mup> PR core20#67 opened: tests: use SNAPCRAFT_PRIME dir instead of hardcoding "prime" <Created by mvo5> <https://github.com/snapcore/core20/pull/67>
[11:46] <zyga> so things like retry-tool vs things like lxd cleanup?
[11:48] <zyga> pedronis: under this classification, session tool does not affect state across tasks, correct?
[11:51] <pedronis> zyga: well session can survive if don't clean them up, no?
[11:51] <zyga> pedronis: sure but the point is to pair session prepare and restore
[11:52] <pedronis> so it affects state across task, unless you use it just right
[11:52] <pedronis> the classification is based on ideal usage, it's about what gets touched
[11:52] <zyga> I think virtually everything has this property
[11:52] <zyga> mkdir does
[11:53] <pedronis> zyga: mkdir is a tool
[11:53] <pedronis> sorry
[11:53] <pedronis> mkdir is not a tool
[11:54] <zyga> so what is it?
[11:57] <pedronis> zyga: for analogy, it's the difference between a helper function vs a methond on the suite struct in go
[11:57] <zyga> ok
[11:57] <pedronis> we have some stateless helpers attached to suite sometimes
[11:58] <zyga> I think attaching this to suite is misleading as it reflects a particular way we use it, I look at it more like a context manager in python, it's an enter/exit pair with user code in between
[11:58] <pedronis> zyga: we don't have a with statement
[11:58] <mborzecki> pedronis: ijohnson: https://github.com/snapcore/snapd/pull/8716 is updated now
[11:58] <zyga> as such it could be used with the same vailidity, at the level of a task or the level of a suite
[11:58] <mup> PR #8716: o/devicestate: refactor current system handling <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8716>
[11:59] <zyga> pedronis: sure but the pairing nature is similar to one, it's just an analogy
[11:59] <pedronis> zyga: anyway it seems you are objecting to suite. , not to the dinstiction
[11:59] <zyga> yes, and I understand your point better now
[12:00] <zyga> so that glancing at the tool name gives some context as to what is the possible impact
[12:00] <pedronis> yes
[12:00] <zyga> I don't know if I have a better name suggestion but I see the goal
[12:03] <pedronis> zyga: pstolowski: how much is short names a goal for you?
[12:04] <zyga> pedronis: I'm okay with a non-short name
[12:04] <mborzecki> time to revisit https://github.com/snapcore/snapd/pull/7414
[12:04] <zyga> I prefer test- to tst- or similar
[12:04] <mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
[12:04] <zyga> mborzecki: looking
[12:04] <zyga> mborzecki: could that be framed in the terms of invariant-tool?
[12:06] <zyga> I think we should be more about detecting issues than automatically fixing the issue as that is easy not to know about; while somewhat more verbose I'd prefer to see a test both install and remove a package rather than rely on another layer computing and removing everything
[12:06] <zyga> just my 0.02
[12:06] <zyga> ok, folks, I'm arriving at my mom's place, I will miss the standup but I'll write something in the document; remember it's mother's day :)
[12:07] <ijohnson> zyga: interesting mother's day in the US was like 2 weekends ago
[12:07] <zyga> oh really? :)
[12:07] <ijohnson> I didn't realize it was different in different countries
[12:07] <zyga> same here
[12:07] <zyga> wonder why :)
[12:07] <mborzecki> zyga: yeah, it's mother's day in pl and maybe some other countries
[12:07] <ijohnson> yeah it's may 10th in US
[12:07] <zyga> ok, ttyl
[12:07] <zyga> I'll be back online when we leave
[12:08] <mborzecki> wow, checked wikipedia, actually may 26 is mothers day only in PL
[12:08] <pstolowski> pedronis: not super important
[12:08] <pstolowski> mborzecki, ijohnson heh, interesting
[12:08] <ijohnson> haha yeah that's interesting
[12:12] <pedronis> mborzecki: 8716 looking good, couple small comments
[12:17] <pstolowski> cachio: hi, i've addressed you comments to #8710
[12:18] <mup> PR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
[12:22] <pedronis> mborzecki: ijohnson: seededSystem and System are internal vs external and have different content, in theory we can unify seededSystem and currentSystem by adding an optional omitempty actions to the former
[12:22] <pedronis> ijohnson: would that help?
[12:23] <pedronis> also those struct definitions should probably move to systems.go as well
[12:23] <ijohnson> yes that sounds like it would help but I don't want to be a bother so if y'all are ok with it as is then it's fine for me too
[12:23] <pstolowski> we're at the brink of having 4th page of PRs..
[12:24] <cachio> pstolowski, thanks
[12:27] <pstolowski> zyga: do you have a moment for https://github.com/snapcore/snapd/pull/8709 ?
[12:27] <mup> PR #8709: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8709>
[12:39] <pedronis> ijohnson: mborzecki: let's land it as is for now, and I'll look into it
[12:39] <mborzecki> ack
[12:39] <ijohnson> fine with me thanks
[12:39] <pstolowski> pedronis: does https://github.com/snapcore/snapd/pull/8608 still need to be blocked? was it blocked because of 2.45?
[12:39] <mup> PR #8608: configcore: issue a warning on core16 when journal.persistent option is set <Squash-merge> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8608>
[12:40] <pedronis> pstolowski: it's blocked becausse mvo made the good point that we should auto-remove the warning if there's a reboot
[12:40] <pedronis> pstolowski: that needs a bit of infra work I fear
[12:41] <pstolowski> pedronis: ah.. good point indeed. i think the comment was made elsewhere, i wasn't aware
[12:42] <pedronis> anyway, it's a bit unclear if it's a good time to work on that
[12:42] <pedronis> let me put this in it at least
[12:42] <cachio> pstolowski, I left few comments
[12:42] <cachio> it is almost ready
[12:42] <pedronis> pstolowski: ah, you did
[12:42] <cachio> just 1 thng to fix
[12:42] <pedronis> pstolowski: thx
[12:45] <pstolowski> pedronis: ok, i can pick it up when time permits and there is nothing more pressing
[12:45] <pstolowski> cachio: thanks
[12:45] <pedronis> pstolowski: exactly
[12:45] <pedronis> pstolowski: I think early config stuff, services stuff, and probably after that snapshot stuff is higher priority
[12:46] <pedronis> and making sure preseed works as well
[12:47] <pstolowski> ack
[12:48] <pstolowski> pedronis: what's the conclusion re preseed fixes for lxd & 2.45.1?
[12:48] <pedronis> pstolowski: I think mvo said yes, but he can reconfirm
[12:55] <mup> PR snapd#8736 closed: tests: log stderr from dbus-monitor <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8736>
[12:58] <mvo> pstolowski: yes please unless it's a ton of work
[13:14] <pstolowski> mvo: ok, will do once the remaining 2 PRs land i nmaster
[13:15] <pstolowski> *in master
[13:15] <mup> PR snapd#8732 closed: data/selinux: update policy to allow forked processes to call getpw*() <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8732>
[13:23] <mup> PR snapcraft#3143 closed: cli: migrate close to use the new channel map <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3143>
[13:23] <mup> PR snapd#8718 closed: boot, many: require mode in modeenv <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8718>
[14:00] <ackk> sergiusens, jdstrand, hi, FTR it seems even the new review-tools still complain about the $SNAP/bin/python symlink which snapcraft creates. I workaround'd it by excluding it via "prime" as it's not really needed, but it seems something either snapcraft or review-tools should handle?
[14:03] <mborzecki> afk for some time
[14:14] <zyga> running out of battery, more work back home
[14:14] <zyga> o/
[14:21] <mup> Bug #1880698 opened:  /etc/writable is double mounted <uc20> <Snappy:New> <https://launchpad.net/bugs/1880698>
[14:24] <mup> PR snapd#8739 opened: tests: port interfaces-desktop-* to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8739>
[14:30] <mup> PR core20#67 closed: tests: use SNAPCRAFT_PRIME dir instead of hardcoding "prime" <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/67>
[14:36] <mup> PR snapd#8740 opened: spread.yaml: apply yaml formatter/linter <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8740>
[14:37] <mvo> cachio: 8693 has a conflict
[14:38] <cachio> mvo, thanks
[14:39] <cachio> I'll fix it
[14:40] <mvo> cachio: thanks!
[14:57] <jdstrand> ackk: hey, which snap was that again? I don't think the new review-tools is in prod yet
[15:10] <roadmr> jdstrand: it is, went to prod yesterday
[15:10] <mup> PR snapd#8735 closed: snap/snapfile,squashfs: followups from 8729 <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8735>
[15:15] <mup> PR snapd#8656 closed: snap-mgmt: perform cleanup of user services <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8656>
[15:16] <mup> PR snapd#8738 closed:  snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8738>
[15:19] <pedronis> mvo: ^ great, now we can port the fix?
[15:19] <pedronis> *backport
[15:19] <mup> PR snapd#8741 opened: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8741>
[15:20] <pedronis> ah :)
[15:20] <pedronis> thx
[15:20] <mvo> pedronis: you want 8656 for 2.45 ?
[15:21] <pedronis> mvo: the feaure is experimental, but yes, it would make sense
[15:21] <pedronis> if it's not too disruptive
[15:21] <mvo> pedronis: sure, let me double check
[15:25] <mup> PR snapd#8742 opened: snap-mgmt: perform cleanup of user services (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8742>
[15:25] <mvo> 8351 needs a second review
[15:26] <ijohnson> mvo is https://github.com/snapcore/snapd/pull/8661 ready out of curiosity ?
[15:26] <mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
[15:27] <ijohnson> also mvo did you see my comment in the SU doc about needing to port https://github.com/snapcore/snapd/pull/8706 to 2.45 ?
[15:27] <mup> PR #8706: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed devices <Created by tsunghanliu> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8706>
[15:27] <ijohnson> it was a few days ago
[15:40]  * cachio lunch
[15:41] <zyga> I’m home eating lunch
[15:41] <zyga> Back in some time
[15:44] <mup> PR snapd#8743 opened: tests: cherry-pick test fixes from master <Created by mvo5> <https://github.com/snapcore/snapd/pull/8743>
[16:01] <cmatsuoka> ijohnson: I created a model for the pi but my boot is failing because the assertion is signed with an expired key, I think it's caused by the system date being completely wrong there
[16:02] <cmatsuoka> ijohnson: how do you fix the date in order to be able to boot?
[16:05] <ijohnson> cmatsuoka: you mean that it's failing to do the first boot of install mode when the seed is verified during the initramfs?
[16:05] <cmatsuoka> ijohnson: it's failing in install mode
[16:06] <cmatsuoka> the-tool[285]: [ - assertion is signed with expired public key ...
[16:06] <ijohnson> cmatsuoka: but to be clear the error is in the initramfs correct?
[16:06] <cmatsuoka> yes, it's in the initramfs
[16:09] <ijohnson> cmatsuoka: do you know how far back the time is in the initramfs? I.e. what time the pi thinks it is?
[16:10] <cmatsuoka> ijohnson: I don't know, can I read that from uboot?
[16:10] <ogra> its the birthday of the granny of the founder of broadcom ...
[16:11] <ogra> you cant read it from u-boot
[16:12] <pedronis> ijohnson: cmatsuoka: we should be able to apply fixes like the one we do from the real systems from snap-bootstrap I suppose
[16:12] <ogra> (you could patch u-bot to read an RTC if there was a RTC ... but there isnt one on the pi)
[16:12] <ogra> *u-boot
[16:12] <cmatsuoka> ogra: how do you deal with this situation? I'm sure you went through this before
[16:13] <ogra> i wrote the fixrtc script 🙂
[16:13] <ijohnson> cmatsuoka: I can show you how to flash a new boot.scr when I'm back from lunch
[16:13] <ogra> but i think thats been dropped for some new thing that xnox worked on
[16:13] <ijohnson> That way you can add dangerous to kernel cmdline  and get an initramfs debug shell when the-tool fails
[16:14] <cmatsuoka> ijohnson: ok, I'll have lunch too and will be back in 30 min or so
[16:14] <ijohnson> Okay
[16:18] <mup> PR snapd#8716 closed: o/devicestate: refactor current system handling <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8716>
[16:19] <mup> PR core20#68 opened: static: make /etc/writable mode "transition" in writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/68>
[16:20] <xnox> cmatsuoka:  why did you create a new model for the pi? we have all the models one may need avaiable. including dangerous ones.
[16:20] <xnox> cmatsuoka:  or is it not good somehow?
[16:20] <xnox> cmatsuoka:  can you share the model please?
[16:27] <jdstrand> ackk: I found the snap
[16:28] <ackk> jdstrand, ah sorry, missed your earlier message
[16:31] <jdstrand> ackk: ok, I see the issue
[16:31] <jdstrand> cc sergiusens ^
[16:31] <ackk> jdstrand, it's canonical-rbac. https://dashboard.snapcraft.io/snaps/canonical-rbac/revisions/241/ is an example of one failure
[16:31] <jdstrand> yep
[16:31] <jdstrand> thanks
[16:32] <ijohnson> mvo: approved #8741 to 2.45 for you
[16:32] <mup> PR #8741: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8741>
[16:33] <mvo> ijohnson: \o/
[16:33] <ijohnson> mvo: also did you see my earlier ping re: the serial-port regex PR for 2.45 ?
[16:33] <ijohnson> mvo: i.e. https://github.com/snapcore/snapd/pull/8706
[16:33] <mup> PR #8706: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed devices <Created by tsunghanliu> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8706>
[16:34] <mvo> ijohnson: I did not see that, cherry-pick should be fine
[16:34] <ijohnson> mvo: ack just an FYI that I requested jdstrand review it, but it was merged before he could review it, not sure if that affects your cherry-pick decision or not
[16:34] <mvo> ijohnson: done
[16:34] <mvo> ijohnson: well, now it would have - oh well
[16:34] <ijohnson> sorry
[16:34] <ijohnson> I should have made that more clear
[16:35] <mvo> ijohnson: it's okay, it looks harmless enough
[16:35] <ijohnson> agreed, I think in the future I will mark as blocked PR's that require jdstrand's review so that this doesn't happen again
[16:42] <mvo> ijohnson: I added a needs-security label now
[16:42] <ijohnson> mvo: ok, sounds good
[16:45] <ijohnson> cmatsuoka: so when you're back, install u-boot-tools via apt, then take this script, https://pastebin.ubuntu.com/p/Nrd5N8n8BV/ and run:
[16:45] <ijohnson> cmatsuoka: `mkimage -A arm64 -O linux -T script -C none -n "boot script" -d bootscript.rpi /media/your-sd-card/ubuntu-seed/boot.scr`
[16:45] <ijohnson> cmatsuoka: that script should be named bootscript.rpi for example
[16:46] <mup> PR snapd#8744 opened: interfaces-ssh-keys: Support reading /etc/ssh/ssh_config.d/ <Created by andrewsomething> <https://github.com/snapcore/snapd/pull/8744>
[16:47] <jdstrand> ijohnson, mvo: PR reviews start today. I'll do that one first
[16:48] <ijohnson> thanks jdstrand
[16:48] <mvo> ta
[17:00] <sergiusens> jdstrand: thanks
[17:04] <cmatsuoka> ijohnson: thanks! in this case it seems that the cause was a key that was new and not valid yet :(
[17:05] <cmatsuoka> ijohnson: I'm rebuilding the image with the dangerous model and overriding channels, that should work
[17:05] <cmatsuoka> ijohnson: but the store is incredibly slow right now
[17:05] <ijohnson> :-(
[17:47] <mup> PR snapcraft#3145 opened: cli: migrate upload and release to new channel-map <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3145>
[17:53] <mup> PR snapcraft#3131 closed: plugin handler: debug build commands if developer debug enabled <enhancement> <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3131>
[18:01] <mup> PR core20#68 closed: static: make /etc/writable mode "transition" in writable-paths <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/68>
[18:34] <mup> PR snapd#8741 closed: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8741>
[19:05] <zyga> re
[19:05] <zyga> cachio: hey
[19:05] <cachio> zyga, hey
[19:06] <zyga> cachio: hey, I missed the standup today
[19:06] <zyga> I wanted to ask about opensuse images
[19:06] <zyga> did you notice those are not working now?
[19:06] <cachio> zyga, I am updating those
[19:06] <cachio> but takes a bit of time
[19:06] <zyga> ah, great, thank you :)
[19:06] <cachio> it should be ready in 15 minutes
[19:06] <cachio> both
[19:06] <cachio> zyga, np
[19:06] <zyga> sounds good
[19:07] <zyga> and another question, is fedora 32 operational?
[19:07] <zyga> if not perhaps we should disable it form the test matrix
[19:07] <cachio> zyga, https://github.com/snapcore/snapd/pull/8693/checks?check_run_id=709950381
[19:07] <cachio> last tests passed
[19:07] <mup> PR #8693: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>
[19:07] <zyga> oh that's great
[19:07] <cachio> I need to fix other images and then we can merge the pr
[19:07] <zyga> ok, once those are rolled out we should be green
[19:07] <zyga> ok
[19:08] <cachio> today I applied the changes suggested in the pr and those worked
[19:09] <mup> PR snapd#8734 closed: tests: port interfaces-wayland to session-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8734>
[19:53] <mvo> a "review" for 8743 would be great, all just cherry picks from master to fix various test failures in 2.45 (probably more to come but this is a good start)
[19:53] <mup> PR snapd#8740 closed: spread.yaml: apply yaml formatter/linter <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8740>
[20:00] <jdstrand> sil2100: hey, fyi, you may have noticed that the core snap was blocked on manual review due to tzdata updates in xenial-updates shuffling around files. wondering if you feel like that was useful or if it would be better to skip checking usr/share/zoneinfo
[20:00]  * jdstrand approved all of those btw
[20:04] <zyga> jdstrand: o/
[20:06] <mup> PR snapd#8521 closed: snap-bootstrap,secboot: clear tpm if provisioning fails <UC20> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/8521>
[20:12] <mup> PR snapcraft#3146 opened: build providers: snap sw to channels if injecting <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3146>
[20:25] <zyga> cachio: o/ are the suse images out?
[20:26] <cachio> zyga, yes
[20:26] <zyga> thanks, I'll re-trigger a few of my tests
[20:26] <zyga> this job caching makes running tests just magical
[20:34] <cachio> zyga, indeed
[20:45] <jdstrand> hey zyga :)
[20:51]  * cachio afk
[20:57] <mup> PR snapcraft#3147 opened: Use `pylxd` instead of `lxc exec` <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/3147>
[21:10] <mup> PR snapd#8739 closed: tests: port interfaces-desktop-* to session-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8739>
[22:52] <mup> PR snapd#8745 opened: tests: port xdg-open-compat to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8745>
[22:58] <mup> PR snapd#8746 opened: tests: port xdg-open to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8746>
[22:58]  * zyga wraps up for the night
[22:58] <zyga> cachio: ^ if you have energy left :)
[23:05]  * zyga really EODs
[23:05] <zyga> (I had one more branch ready)
[23:05] <mup> PR snapd#8747 opened: tests: port snap-routine-portal-info to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8747>
[23:10] <cachio> zyga, I'll take a look


[04:39] <xu-irc90w> hi
[04:39] <xu-irc90w> someone use xubuntu on ryzen 5 3500u laptop ?
[04:40] <xu-irc90w> it has a problem ?
[04:40] <xu-irc90w> i wanna use it
[06:31] <nikolam> Seems like xfce4 weather applet works again in panel, updating weather data over internet
[06:32] <nikolam> I'll check if it sonnected maybe with me installing GNOME to check it out a bit. (GNOME seems totally useless comparing to Xfce btw.. )
[06:35] <Unit193> That'd be entirely unrelated.
[06:38] <nikolam> Unit193, ok.
[06:39] <Unit193> xfce4-weather-plugin would use nothing from GNOME.
[06:41] <nikolam> Btw, GNOME really seems useless DE. I don't understand how it can be effectively used at all. I so take for granted Xfce panel customization ability, I didn't even see GNOME having desktop icons, active applications..
[06:41] <nikolam> It is only me of Xfce really seems so much useful then GNOME, wonder if there are other opinions and experiences.
[06:42] <Unit193> You can install different plugins to make GNOME slightly more useful, but generally speaking it's made for you to use it as they set it up, not how you do.
[06:43] <Unit193> They're interested in 'brand recognition', so limit how you can customize it.
[06:44] <nikolam> Unit193, seems like I would stay on Xfce4 forever. I were bit bored over the years, but I see now it's more blessing using Xfce then anything else.
[06:45] <Unit193> You could try KDE, LXQt, Openbox, AwesomeWM, i3wm, sway, etc if you'd like to liven things up!
[06:45] <nikolam> Seems like brand recognition in Gnome backfires a lot on Ubuntu in general comparing to proprietary competition.
[06:46] <Unit193> It seems to work for some folks.
[06:46] <nikolam> Unit193, yeah, I have BTRFS with apt-btrfs-snapshot, so I can install , try and come back to previous system state, but I have a quite good impression I think over the years what othe Wm's ot DE's would bring. But sure, I could try them all what they bring today.
[06:47] <Unit193> Heh, snazzy!
[06:48] <nikolam> I had a neighbor I put Ubuntu on the laptop for, and I think she stopped using laptop at all, started using Android phone almost exclusively.. Maybe it's not GNOME's fault, but Mobile phone form factor convenience
[06:48] <Unit193> Huh, I don't see it in the repos.
[06:49] <nikolam> Unit193, yes and ZFS mounted /home/user folders :P
[06:49] <nikolam> Unit193, apt-btrfs-snapshot is the package name
[06:51] <Unit193> Ah, Ubuntu only.  Checked on the wrong host.
[06:51] <nikolam> One can update ext4 to btrfs in-place. Btrfs also supports expanding boot disk to software RAID1 but need to command it to mirror both data and metadata etc.
[06:52] <Unit193> ...TIL that too. 0_o
[06:53] <Unit193> Interesting as Ubuntu seems to have more of a focus on zfs, which is somewhat understandable as btrfs is still pretty young and sometimes has integrity issues from what I recall.
[06:55] <nikolam> Well, I don't think Btrf is young. ZFS is truly older and longer in production, especially well supported with OpenZFS, but I Btrfs has it's benefits, like being in-kernel, having multiple different RAID levels per-dataset.., so I use Btrfs for Linux system and ZFS for important data :P
[06:56] <nikolam> If wanting to avoid on-boot fsck , then ZFS is better solution, yes. (Think XFS also does not require it on boot)
[06:56] <Unit193> The in-place bit is interesting, as are some btrfs features.  Though as of late ext4 even grew some features.  ZFS is avilable in the installer now, and IIRC redhat changed to XFS.
[06:58] <nikolam> Starting with snapshots, data and metadata checksums, zfs send / btrfs send for replication, transparent compression (and transparent encryption on OpenZFS), I for 10 years don't see any point in using Ext4.. and I stay away from LVM as far as possible, because those layers are included in Btrfs and ZFS
[07:00] <nikolam> I don;t think I could install on ZFS last time I have run Ubuntu installer.. Or at least it required reformatting whole drive or somehting.. not installing on existing ZFS or on partition, so I opted for Btrfs for Linux install still.
[07:23] <Unit193> Curious, do you know how much extra space apt-btrfs-snapshot requires?
[07:44] <jehutydegression> Xfce is miles better than GNOME, IMO. Xfce is easily customized, easy to use, and runs well on older and newer hardware.
[07:44] <jehutydegression> And it's stable. What more can you ask for?
[08:47] <nikolam> Unit193, shapshots on zfs and btrfs do not require additional space, they are Copy-On-Write file systems.
[08:48] <jphilips> testing week announcement - https://xubuntu.org/news/xubuntu-21-04-testing-week/
[08:48] <nikolam> It can use more space over time, as you progress and make changes, so best is to remove oldest snapshots
[08:49] <nikolam> Snapshots are quite useful for replications and backups, faster and better then rsync
[08:50] <nikolam> It does not exlude using rsync of course. Btrfs snapshots are by default read-write , behave as separate FS (read-only with -s option) and zfs snapshots are read-only by default (accessible under .zfs folder)
[08:51] <nikolam> jehutydegression, that is exactly true. I am just curious to see how other DEs are doing after all those years. Been using MATE (GNOME2 continuation) ono non-Linux distro for some time, too.
[16:08] <xu-irc53w> hi, I accidently removed wifi settings/options from right side of lower bar. Xubuntu, newbie. Can anybody help me, please?
[16:20] <jphilips> xu-irc53w: hi. how did you remove it?
[16:23] <xu-irc53w> red  - Remove
[16:23] <xu-irc53w> I tried to add it again but list of items does not contain it :(
[20:36] <xu-irc53w> hi, I accidently removed wifi settings/options from right side of lower bar. Xubuntu, newbie. Can anybody help me, please?
[20:36] <xu-irc53w> I tried to add it again but list of items does not contain it :(
[20:42] <krytarik> xu-irc53w: I'd look for Indicator plugin first.
[21:16] <piscvau> Hello I am running xubuntu Bionic 18.04 and I would like to upgrade to 20.04. I do not have the package do-release-updgrade and if I type in terminal apt-get install do-release-upgrade it says cannot find the package. any solution?
[21:22] <krytarik> piscvau: 'ubuntu-release-upgrader-core' would be the package that includes it.


[01:33] <cheeseboy> hi
[01:33] <cheeseboy> why cant i ping my server?
[01:33] <cheeseboy> but it can ping other pcs
[01:33] <cheeseboy> and other pcs can ping other pcs
[01:34] <cheeseboy> internet is working
[03:22] <cheeseboy> anyone there
[03:37] <olem> yap
[03:38] <cheeseboy> cal u help
[03:38] <cheeseboy> can*
[03:39] <olem> beg you pardon?
[03:41] <olem> have you got any problem/issue?
 why cant i ping my server?
 but it can ping other pcs
 and other pcs can ping other pcs
 internet is working
[03:41] <olem> netmask issue?
[03:41] <cheeseboy> how i check?
[03:41] <olem> I mean, perhaps you set a incorrect netmask value on your server, for example:
[03:41] <olem>  . you're on (V)LAN /26
[03:41] <olem>  . you set a /24 netmask on your server
[03:41] <olem>  . so your server can ping others
[03:41] <olem>  . while other cannot
[03:41] <cheeseboy> i dont rember setting that
[03:41] <cheeseboy> ever
[03:41] <cheeseboy> put it can ping others
[03:42] <olem> see your network admin, he will probably help you better than I (I dunno you network plan)
[03:42] <cheeseboy> im network admin
[03:42] <olem> yes. you can if you've got a broader netmask (and are in the same wire)
[03:42] <olem> ah.
[03:42] <olem> so you're sure about your netmask on your server?
[03:42] <cheeseboy> no
[03:42] <olem> I mean, sure to be the correct one?
[03:43] <cheeseboy> dunno how to check or change
[03:43] <olem> to check, see /etc/network/interfaces
[03:44] <olem> for example, a valid entry could be:
[03:44] <olem> iface eth0 inet static
[03:44] <olem>  address <IP_ADDRESS>
[03:44] <olem>  network <IP_ADDRESS>
[03:44] <olem>  netmask <IP_ADDRESS>
[03:44] <olem>  broadcast <IP_ADDRESS>
[03:44] <olem>  gateway <IP_ADDRESS>
[03:44] <cheeseboy> eth1 is set
[03:44] <cheeseboy> but supposed to be eth0
[03:45] <cheeseboy> olem so if i change to eth0 think thayll fix it?
[03:46] <olem> can you issue an 'sudo mii-tool' to see what iface is connected out there ?
[03:46] <cheeseboy> i usally dhclient eth0 to bring internet up
[03:46] <olem> can you copy/paste here your /etc/network/interfaces ?
[03:46] <cheeseboy> how?
[03:47] <cheeseboy> i have no x
[03:47] <olem> ah... then... manually copy past it :-)
[03:47] <olem> (albeith you have mouse support of course)
[03:47] <cheeseboy> X(
[03:47] <cheeseboy> ??
[03:48] <olem> so, what you're /etc/network/interfaces tells us about eth0 and eth1 ?
[03:48] <cheeseboy> auto lo
[03:48] <cheeseboy> iface lo inet loopback
[03:48] <olem> ok - fine
[03:48] <olem> next
[03:48] <cheeseboy> that all u want?
[03:49] <olem> next : eth0 and eth1
[03:49] <olem> lo is the loopback iface (lo0/<IP_ADDRESS>)
[03:49] <cheeseboy> iface eth0 inet static
[03:49] <cheeseboy> i just changed from eth1
[03:50] <cheeseboy> adress <IP_ADDRESS>
[03:50] <cheeseboy> netmask 255.255.0
[03:50] <cheeseboy> gateways wrong too
[03:50] <cheeseboy> h/o
[03:51] <cheeseboy> gateway <IP_ADDRESS>
[03:51] <cheeseboy> auto eth0
[03:51] <cheeseboy> thats it
[03:51] <olem> ok. I see the following error: s/adress/address/
[03:52] <cheeseboy> ??
[03:52] <olem> and, are you sure to be on a Class B network (/16) ? not in a Class C (/24) ?
[03:52] <cheeseboy> no i dont even know what that means
[03:52] <olem> I guess your in a Class C. If so, your issue is 'netmask 255.255.0' which should be 'netmask <IP_ADDRESS>'
[03:53] <olem> Class B network are 'large' network from 16xxx addresses.
[03:53] <cheeseboy> oh yea it is that
[03:53] <cheeseboy> typo my bad
[03:53] <cheeseboy> how i reset all my internet on ubuntu?
[03:53] <olem> Class C are 'tiny' networks (even if your may subnet them in tinier ones) for 255 addresses
[03:54] <olem> what do you mean by "resetting all my internet"?
[03:54] <cheeseboy> disconnect reconnect w/ new settings
[03:54] <olem> If you want to 'restart your network' to apply new parameters, you just have to issue 'sudo /etc/init.d/networking restart'
[03:55] <olem> but be sure of your parameters prior to network restart... if you're teleworking :-)
[03:55] <cheeseboy> failed to bring up eth0
[03:55] <olem> sudo tail -f /var/log/messages ?
[03:56] <olem> could inform you about why
[03:57] <cheeseboy> not much info there
[03:57] <olem> ok. so, you should issue an 'sudo mii-tool'
[03:57] <olem> to see to what physical iface you've got a jack plugged in.
[03:57] <olem> (to be sure about eth0 and eth1)
[03:58] <cheeseboy> fails on both
[03:58] <olem> for example, on my laptop, I don't use eth0 and when I issue 'sudo mii-tool', it returns me something like :
[03:58] <olem> olem@lembox:~$ sudo mii-tool
[03:58] <olem> eth0: no link
[03:58] <olem> SIOCGMIIPHY on 'eth1' failed: Operation not supported
[03:58] <cheeseboy> yes
[03:58] <olem> to tell me:
[03:58] <olem>  . hey dude, no cable in eth0 ('no link')
[03:58] <cheeseboy> cept  oppisite eth0 and eth 1
[03:59] <cheeseboy> eth1 no link
[03:59] <cheeseboy> eth0 that other error
[03:59] <olem>  . hey dude, I cannot stat about your eth1 (cause it's the wireless iface, and don't support this interrogation)
[03:59] <olem> what does eth0 tells?
[03:59] <olem> exactly
[03:59] <cheeseboy> yes its wireless
[04:00] <olem> So, you'r mii-tool reports that :
[04:00] <olem>  . eth1 is a wired interface, with no link (no cable in)
[04:00] <olem>  . eth0 ??? (I did not understand)
[04:00] <olem> ?
[04:00] <cheeseboy> no..
 eth0: no link
 SIOCGMIIPHY on 'eth1' failed: Operation not supported
[04:01] <cheeseboy> cept switch et1 w/ eth0
[04:01] <olem> so you're mii-tool tells you that:
[04:02] <olem>  . SIOCGMIIPHY on 'eth0' failed: Operation not supported
[04:02] <olem>  . eth1: no link
[04:02] <olem> ?
[04:02] <cheeseboy> yes
[04:02] <olem> and your /etc/network/interfaces is configured this way:
[04:02] <olem> auto lo0
[04:02] <olem> oups...
[04:02] <olem> auto lo
[04:02] <olem> iface lo inet loopback
[04:02] <olem> # wireless
[04:03] <olem> iface eth0 inet dhcp
[04:03] <olem> # wired
[04:03] <olem> iface eth1 inet static
[04:03] <olem> address <IP_ADDRESS>
[04:03] <cheeseboy> eth0 and eth1 are wireless
[04:04] <cheeseboy> but eth1 doesnt work
[04:04] <cheeseboy> and i have eth0 configures as static
[04:04] <cheeseboy> so i can rember ip easier
[04:05] <olem> hum... strange mii-tools returned a eth1 with 'no link' if it's a wireless iface... but, well, who knows (perhaps some drivers support this PHy...)
[04:05] <olem> anyway, can you please spell me the /etc/network/interfaces relating to eth0, to be sure there is no issue?
[04:06] <cheeseboy> auto lo
[04:06] <cheeseboy> iface lo inet loopback
[04:06] <cheeseboy> iface eth0 inet static
[04:07] <cheeseboy> adress 192168.1.102
[04:07] <cheeseboy> netmask<PHONE_NUMBER>
[04:07] <olem>   ==> be sure to have exactly : address <IP_ADDRESS>
[04:07] <cheeseboy> ya typos here
[04:07] <olem> (2 'd' to address)
[04:07] <olem> ok.
[04:07] <olem> and netmask <IP_ADDRESS> :)
[04:07] <cheeseboy> gateway <IP_ADDRESS>
[04:08] <cheeseboy> auto eth0
[04:08] <olem> add (before auto eth0) :
[04:08] <olem>  network <IP_ADDRESS>
[04:08] <olem>  broadcast <IP_ADDRESS>
[04:09] <olem> and /etc/init.d/networking restart again
[04:09] <olem> (after saving the file of course :)
[04:09] <cheeseboy> olem
[04:10] <cheeseboy> failed to bring up eth0
[04:10] <olem> ok :(
[04:10] <olem> can you comment all the declarative parts for you eth0 and try these ones:
[04:10] <olem> iface eth0 inet dhcp
[04:10] <olem> auto eth0
[04:11] <olem> and (save) /etc/init.d/networking restart ?
[04:11] <cheeseboy> ya h/o
[04:11] <olem> just to see
[04:11] <cheeseboy> dhclient brings it up
[04:11] <olem> what does your ifconfig (or ip addr show) returns?
[04:12] <olem> regarding eth0 of course
[04:12] <cheeseboy> <IP_ADDRESS> wen i use dhclient
[04:12] <olem> netmask/broadcast/ ?
[04:13] <cheeseboy> ??
[04:14] <olem> 'ip addr show' should returns you something like that, relating to eth1 :
[04:14] <olem> inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global eth1
[04:14] <olem> s/eth1/eth0 :)
[04:15] <olem> In fact, if you can negociate an @IP via DHCP and ping outside, you are sure you wireless conf is okay (wpa_supplicant.conf I suppose)
[04:16] <cheeseboy> i nvr touched it
[04:16] <olem> So, if your /etc/network/interfaces configured in static mode (iface eth0 inet static, and all the stuff) does not bring up your iface, the problem is in the /etc/network/interfaces : a typo error or something like that
[04:17] <Burgundavia> olem: can you pastebin your /etc/network/interfaces?
[04:17] <olem> From my point of view, with what I understand of your network topology, your /etc/network/interfaces should be exactly this one :
[04:17] <olem> # loopback
[04:17] <olem> auto lo
[04:17] <Burgundavia> olem: ahh, pastebin
[04:17] <olem> iface lo inet loobpack
[04:17] <olem> # eth0 - wireless but static
[04:17] <olem> auto eth0
[04:17] <cheeseboy> Burgundavia, olem is helping me w/ the problem
[04:18] <olem> iface eth0 inet static
[04:18] <Burgundavia> right, sorry
[04:18] <olem>  address <IP_ADDRESS>
[04:18] <olem>  network <IP_ADDRESS>
[04:18] <olem>  netmask <IP_ADDRESS>
[04:18] <olem>  broadcast <IP_ADDRESS>
[04:19] <cheeseboy> i had those but in different order
[04:19] <olem>  gateway 192.168.1.XXX (I dunno what is your gw, but you should)
[04:19] <Burgundavia> olem: please use pastebin next time
[04:19] <olem> place them in that order (I'm not sure this will impact)
[04:19] <Burgundavia> you also will want a auto eth0 before the iface line
[04:19] <cheeseboy> thats what it said
[04:19] <olem> Burgundavia, why do you want me to c/p my /etc/network/interfaces with all my gory comments in there? :)
[04:20] <Burgundavia> olem: because I thought you were cheeseboy
[04:20] <Burgundavia> cheeseboy can you pastebin that file?
[04:20] <cheeseboy> no
[04:20] <cheeseboy> no x
[04:20] <olem> Burgundavia, I dunno what the hell you're drinking, but I'm okay for the same thing ;)
[04:21] <olem> uh... 4:20 AM! I'm gonna go to bed...
[04:21] <cheeseboy> where i put auto eth0?
[04:22] <cheeseboy> wait olem
[04:22] <cheeseboy> i need help :(
[04:22] <olem> you can put 'auto eth0' before, or after the declaration segment for an iface.
[04:22] <olem> usually, I place them in the begining of my /etc/network/interfaces
[04:22] <olem> like:
[04:22] <olem> auto lo
[04:22] <olem> auto eth0
[04:22] <olem> auto eth1
[04:23] <olem> and then, I declare those interfaces (lo, eth0 and eth1)
[04:23] <olem> but, well, you can in fact place the 'auto' directive anywhere in you file, excepted in a declarative bloc
[04:23] <olem> (man interfaces for more
[04:24] <olem> ok. I'm gonna go to bed.
[04:24] <cheeseboy> X(
[04:24] <olem> cheeseboy, cross check your /etc/network/interfaces with Burgundavia
[04:24] <cheeseboy> it broke worst
[04:24] <cheeseboy> now says network is down
[04:24] <Burgundavia> cheeseboy: can you pm me that file then?
[04:25] <olem> I' pretty sure you've got an error in it. It's trivial to correct, if you repeat _exactly_ your /etc/network/interfaces here.
[04:25] <olem> thx Burgundavia :)
[04:25] <olem> seeya
[04:25] <cheeseboy> Burgundavia, how?
[04:25] <cheeseboy> Burgundavia, i have to type it all :(
[04:27] <cheeseboy> Burgundavia, wait it just magically fixed
[04:27] <cheeseboy> X(
[04:29] <cheeseboy> how i add samba user and pass?
[05:37] <foo> w22
[04:35] <massctrl> hi all, does ubuntu server have xen packages?
[04:42] <necrite_> hi all
[04:43] <lionel> hi necrite_
[04:43] <lionel> massctrl: yes, xen packages are in ubuntu server.
[04:44] <massctrl> tnx lionel
[04:44] <massctrl> I have found a link meanwhile
[04:50] <massctrl> k I'm not familiar with ubuntu-server, what's the default mailserver ?
[04:50] <massctrl> is it exim like Debian's ?
[05:13] <lionel> massctrl: no one is installed by default
[06:16] <massctrl> lionel: ok good to know, docs are talking about postfix,... https://help.ubuntu.com/ubuntu/serverguide/C/email-services.html
[06:16] <massctrl> my fav anyway ;-)
[06:16] <massctrl> by the way anyone knows if there are any hardware vendors that will support ubuntu server ?
[06:16] <lionel> I would also advice postfix, but you're free to choose :)
[06:17] <massctrl> I mean Hp is offering commercial debian support, which is kind of nice, ... but i'm not that keen on debian,...
[06:17] <lionel> massctrl: I use Dell, HP is also well supported (as used in Canonical DC :))
[07:09] <Ali_ix> hi
[07:09] <Ali_ix> does apt-pinning work on ubuntu at all?
[07:09] <Ali_ix> how do i get it working on feisty?
[07:52] <shawarma> It just does.
[07:52] <shawarma> If that's all the detail you're going to give, all I can say is: it already works.
[08:26] <Ali_ix> thanks shawarma,
[08:27] <Ali_ix> shawarma: i want to exclude linux-headers and linux-image package to being updated with auto update,
[08:27] <Ali_ix> how can i do this? which priority  to set?
[09:08] <shawarma> Ali_ix: Just put them on hold.
[09:08] <shawarma> Ali_ix: Much easier.
[09:08] <shawarma> Ali_ix: Heck, it's even easier than that. :)
[09:08] <Ali_ix> shawarma: on hold? ho to do this?
[09:08] <shawarma> Ali_ix: Just remove linux-image.
[09:09] <shawarma> Ali_ix: Not linux-image-2.6.whatever, but linux-image and either linux-image-server or linux-image-generic.
[09:09] <shawarma> Ali_ix: Those are the packages that depend on the newest and hence it's them that take care of having your kernel uptodate.
[09:09] <shawarma> Ali_ix: Why do you want to do this?
[09:10] <Ali_ix> shawarma: i have some good and stable config with 2.6.20-13 kernel on ubuntu, and dont need any kernel update now :}
[09:10] <Ali_ix> shawarma: i want to exclude kernel-related packages fro auto update
[09:10] <shawarma> Ali_ix: Um.. Ok.
[09:10] <Ali_ix> shawarma: some one advised to use pinning
[09:11] <shawarma> Ali_ix: There's no need.
[09:11] <shawarma> Ali_ix: You using the server images?
[09:11] <Ali_ix> shawarma: no, desktop images on feisty
[09:12] <shawarma> Ali_ix: Ok. "apt-get remove linux-image-generic"
[09:12] <shawarma> Ali_ix: That should do it.
[09:13] <shawarma> Ali_ix: I'm curious why you're asking here, though?
[09:13] <Ali_ix> shawarma: isnt it nessecary for later?
[09:13] <Ali_ix> *necessary
[09:14] <Ali_ix> shawarma: what is within linux-image-generic-* package? just linux headers and sources? :)
[09:14] <shawarma> Ali_ix: Well.. Yes, in the same sense as the kernel updates are necessary, but it's those you don't want?
[09:14] <shawarma> Ali_ix: linux-image-generic-* are the actual kernels.
[09:14] <shawarma> Ali_ix: The headers are in linux-headers-generic-*
[09:15] <shawarma> Ali_ix: You should *not* remove linux-image-generic-*.
[09:15] <shawarma> Ali_ix: Only linux-image-generic.
[09:15] <shawarma> (no suffix)
[09:15] <Ali_ix> oh, got it :d
[09:15] <Ali_ix> thanks shawarma :)
[09:16] <Ali_ix> shawarma: this is a virtual package to the latest apackage build, isnt it?
[09:17] <shawarma> Ali_ix: Yes. That's how we make sure people get kernel updates.
[09:17] <shawarma> Ali_ix: Well.. Kernel updates when there are ABI changes, anyway.
[09:17] <shawarma> Ali_ix: If you want to be completely sure nothing updates your kernel without asking, you should do:
[09:18] <shawarma> Ali_ix: "echo linux-image-generic-`uname -r` hold | sudo dpkg --set-selections"
[09:18] <shawarma> Ali_ix: Gotta run!
[09:18] <Ali_ix> :D some strange command :D
[09:18] <Ali_ix> shawarma: thanks very much
[09:33] <Ali_ix> shawarma: thanks again, and bye ;)


[14:50] <lynorian> wxl alternates are not building for the past two days
[14:51]  * lynorian can't remember the sight with the build logs
[14:57] <tsimonq2> O_O
[14:57]  * tsimonq2 confirms
[14:57] <tsimonq2> nice catch lynorian!
[14:57] <tsimonq2> wait no
[14:57] <tsimonq2> yeah, whoops
[14:58] <lynorian> only alternate
[14:58] <lynorian> not desktop
[14:58] <tsimonq2> the 20160617 dir has been created but nothing happens
[14:58] <tsimonq2> so
[14:58]  * tsimonq2 finds build logs
[16:21] <tcoupload> i bought an printer HP 2130, in HP page said lubunt drivers were not the latest so i download them from HP, i run the setup and all seems ok... but when i print the test page the printer starts but froze at the middle...
[16:29] <teward> tcoupload: HP drivers are proprietary and the Lubuntu team can't maintain them
[16:29] <teward> just keep that in mind
[16:29] <teward> also, support in #lubuntu :)
[17:02] <tcoupload> i know that
[17:02] <tcoupload> but syslog give another reading of facts
[17:08] <tcoupload> teward: in opinion what is the better brand to choise?
[18:59] <agaida> brother, ricoh
[18:59] <lynorian> agaida, tcoupload has left the channel
[19:00] <agaida> upps - no patience


[00:00] <Logan> :(
[00:00] <Logan> joining channels on Matrix is hard
[00:02] <Unit193> Yeah matrix...isn't really a good client.  Also, somehow I ended up with the libcrypt.so.1 -> libcrypt.so.1.1.0 symlink, seems nothing is broken for me.
[00:03] <Logan> lucky you
[00:03] <Unit193> No idea how I managed that..
[01:22] <nicolas17> this git package has been building for more than an hour... might be the slowest tests I have seen
[19:19] <tarzeau> no xpdf for focal???
[19:19] <tarzeau> what's my chances after the freeze to get meshlab fixed for 20.04?
[19:23] <mitya57> "unmaintained, not compatible with the new poppler", also debian #848631
[19:27] <tarzeau> mitya57: thanks for the summary!


[00:00] <RAOF> mlankhorst: Oh, I think I know why Mir clients are failing on new mesa; I ran into it before.
[08:15] <mlankhorst> RAOF: go on
[08:16] <mlankhorst> is this thep oint where the killer makes another move and you die before you can tell what the important information is? ;-)
[10:05] <alan_g> alf: I'm looking at some of the valgrind errors we see in my SwitchingBundle proposal and have found some very misleading reporting. What do you make of this: http://pastebin.ubuntu.com/6924718/
[10:11] <anpok> lacking support for c++11
[10:17] <alan_g> Rats. valgrind can't detect std::atomic wrappers on types that don't need a lock. (Because the wrapper gets optimised away.)
[10:17] <alan_g> That's a load of noise.
[10:30] <alf> alan_g: :/
[10:31] <anpok> there is also no _GLIBCXX_SYNCHRONISATION_WHATEVER .. in atomic
[10:31] <alan_g> Yeah. tvoss suggested threadsanitizer - which isn't quite as wrong with the example
[10:33]  * alan_g wanders off to talk to folks that know this stuff in detail
[10:41] <alf> alan_g: anpok: I wonder if helgrind can understand hardware instructions with acquire/release semantics (e.g. probably used by atomic<> implementations)... probably not
[10:42] <alan_g> alf: no. It is discussed on the valgrind lists - the opcodes are identical (for basic types anyway)
[11:21] <mlankhorst> RAOF: yeah the refresh fixed things.. I'm curious though since it seems to remove a bunch of free-s. Why were those removed?
[11:21] <mlankhorst> -+   free(dri2_surf->dri_buffers[__DRI_BUFFER_FRONT_LEFT]);
[11:21] <mlankhorst> -+   free(dri2_surf->dri_buffers[__DRI_BUFFER_BACK_LEFT]);
[11:51] <greyback> folks, I've a little C++ issue I need advice on: http://pastebin.ubuntu.com/6925097/
[11:52] <greyback> I think I'm not fully understanding a reference to a pointer of an object and how to properly create one
[11:55] <alan_g> greyback: C++ won't let you bind a non-const reference to a temporary
[11:58] <alan_g> s/QScopedPointer<MockBuffer> buffer(new MockBuffer);/mir::graphics::Buffer* buffer{nullptr};/
[11:58] <greyback> alan_g: interesting. Do I not need that MockBffer at all?
[12:00] <alan_g> greyback: I doubt it: swap_buffers() is used to get a pointer to a buffer provided by the compositor and optionally return one
[12:02] <alan_g> BTW swap_buffers got some drastic changes last week and that code is using the old version
[12:02] <greyback> alan_g: ah really? Ok, well this is more an experiment than anything else.
[12:03] <greyback> alan_g: thanks for the help, you've pointed me in the right direction
[13:54] <alf> fginther: Hi! Do we need to do something to deploy the change for the pbuildjenkins scripts?
[13:59] <alf> rsalveti: ogra_: How do you want to handle the package dependency of e.g. libmirclient to its platforms? libmirclient Depends: libmirclientplatform-mesa | libmirclientplatform-android ?
[14:00] <ogra_> alf, right, and then se seed libmirclientplatform-android in touch and libmirclientplatform-mesa everywhere else
[14:12] <fginther> alf, It's all deployed now, you should be good to go
[14:13] <alf> fginther: excellent, thanks
[14:24] <alf> ogra_: rsalveti: Also, do you want mesa and android to have the same priority (in terms of dpkg alternatives), or different priorites, possibly depending on platform?
[14:25] <ogra_> alf, i assume they will never be installed together anyway
[14:25] <ogra_> so they can have the same
[14:26] <alf> ogra_: if a package with the same priority as an already existing one gets installed, does the alternative change to the new one or stick to the current one?
[14:27] <ogra_> i thinkit gets changed
[14:28] <alf> ogra_: hmm, let's see if I can find out for sure (to the sources!). The problem I am trying to avoid is someone using mir on the desktop, playing with packages, and installing the -android backend => broken system
[14:29] <ogra_> use Conflicts/Breaks in the control file
[14:29] <ogra_> then he needs to approve the removal ... (apt will ask Y/N )
[14:29] <ogra_> thats at least one stop gap
[14:31] <alf> ogra_: Then what is the point of having alternatives in the first place? We could just Conflict/Break from the start... I thought the (future) goal was to be able to install in parallel and have runtime selection?
[14:31] <ogra_> but that would happen inside one package anyway, or not ?
[14:37] <rsalveti> alf: ogra_: I'd put the android with a lower priority
[14:37] <rsalveti> as our touch image is ro anyway
[14:37] <ogra_> indeed
[14:38] <rsalveti> then we're still good for the desktop
[14:38] <ogra_> though my statement still stands, for the runtime selection we want both in one package
[14:40] <alf> rsalveti: ogra_: would it make sense to have mesa < android on armhf, mesa > android otherwise?
[14:45] <alf> rsalveti: ogra_: from the update-alternatives manpage: "If the group is in automatic mode, and the newly added alternatives' priority is higher than any other  installed  alterna‐ tives for this group, the symlinks will be updated to point to the newly added alternatives
[14:46] <ogra_> alf, right, well, do it like you described above
[14:46] <rsalveti> alf: we don't want to assume anything for armhf
[14:46] <rsalveti> as we now have the x86 emulator as well
[14:47] <alf> rsalveti: ogra_: ok, I will make them equal, hopefully what the manpage says is accurate, so just installing the package won't mess up a system with an existing equal alternative
[14:48] <rsalveti> right :-)
[14:55]  * alf didn't know what he was missing by not using ccache when developing/rebuilding packages
[14:56] <kgunn> mterry: didn't mean to abandon you....
[14:57] <kgunn> mterry: so what you wanted to know was where in the mir code does a client know his buffer is about to be "used" for composition consumption
[14:57] <kgunn> that right ?
[15:00] <mterry> kgunn, yeah...  I want to know when a buffer with non-zero content is about to be used.  (i.e. not just transparent; I don't know if Mir optimizes such frames out anyway)
[15:00] <mterry> kgunn, oh and this is from compositor side
[15:01] <mterry> kgunn, I tried inspecting buffers but didn't know how to get actual pixel data
[15:02] <kgunn> alf: or anpok ^ can you help out mterry...
[15:03] <mterry> anpok and alan_g, you two were helping me yesterday with buffer stuff.  I have instrumented USC to insert itself into the surface/session creation process.  Now I have these buffers that the surface wants to swap
[15:03] <mterry> But how do I inspect actual pixel data?  (I want to see if there's actual pixels to draw, it's not just all transparent -- does Mir optimize that away?)
[15:04] <anpok> mir would not optimize that away
[15:05] <anpok> also if you look at current system behavior you regularly see white or black buffers show up.. so we seem to display things before actual content shows up - I dont know exactly where that happens though
[15:06] <mterry> anpok, hm.  But I have a mg::Buffer object.  I can't seem to do anything sensible with the native_buffer_handle, but how might I get the pixel data?
[15:08] <alan_g> mterry: I don't think that's an intended use. Maybe alf can suggest a way?
[15:10] <greyback> mterry: do you want to inspect the actual pixel data, or just be notified that a client has drawn its first frame?
[15:11] <mterry> greyback, well you showed me you had something in the works for frame notification
[15:11] <mterry> greyback, I suspect Qt is sending a dummy background before the Qml is fully loaded and drawn
[15:11] <mterry> greyback, so I wanted to be able to inspect data to see if that is true and to detect the first non-empty frame
[15:16] <greyback> mterry: when mir creates a Surface, it may be some time until the buffer is actually drawn to by the client. So I wanted to be notified after the client has drawn to the buffer, as then it is non-empty
[15:17] <greyback> so I wasn't going to actually inspect the pixel data. I just wanted to know that the client swapped a buffer, which means it drew to it
[15:18] <greyback> mterry: are you using the SurfaceManager in unity-mir by any chance?
[15:18] <mterry> greyback, no, I'm currently looking to do this in USC
[15:18] <greyback> mterry: ok
[15:18] <mterry> greyback, so who does have access to the pixel data?  Seems hard to find in mir source  :)
[15:19] <greyback> mterry: so what I think Mir needs to export is some kind of event which says "Session has a Buffer ready" to be composited/drawn on screen (i.e. one which the client has actually drawn to)
[15:20] <mterry> That would help, yeah
[15:21] <alan_g> mterry: the pixel data is platform dependent typically in a GL texture
[15:23] <mterry> alan_g, hmmm OK
[15:25] <alan_g> As far as Mir is concerned if a client has sent a buffer via swap_buffers()  there is data. So I'm not sure what else this event you're discussing would be.
[15:46] <mterry> alan_g|tea, what about the idea of a client Mir session being able to indicate to the server that it is "ready" to be composited?  It seems not unreasonable that a compositor would want to keep some animation going or draw something to the screen while a client loads up
[15:48] <alan_g> mterry: why doesn't it do that by posting a buffer?
[15:49] <mterry> alan_g, yeah but when does it stop the buffer?
[15:50] <alan_g> I don't understand
[15:51] <mterry> alan_g, so here's the problem I'm working with
[15:51] <mterry> alan_g, USC starts, and lightdm kicks off a greeter session and a user session around the same time.  There's a race there, but USC knows to keep the greeter on top when it does show up
[15:52] <mterry> alan_g, but user session sometimes wins the race and appears for a second before the greeter
[15:52] <alan_g> ack that's what we discussed yesterday
[15:52] <mterry> alan_g, I'd like to be able to hide the user session when it appears (easy with Session::hide())
[15:52] <alan_g> sure
[15:52] <mterry> alan_g, but I need to know when to unhide it (i.e. when the greeter is "done")
[15:52] <mterry> alan_g, and the greeter is posting frames before it is ready (presumably empty transparent frames)
[15:53] <mterry> Qt is doing that I think for me
[15:54] <mterry> alan_g, the situation would be very similar once USC gets boot animation support.  We need to know when to transition from the animation to the greeter when it is ready to be shown
[15:54] <alan_g> So the answer to "why doesn't it do that by posting a buffer?" is that Qt posts buffers before it is ready?
[15:54] <mterry> alan_g, well.  I mean, I could imagine a client like the unity8 shell not wanting to be "ready" before its scopes are loaded or whatever
[15:55] <mterry> alan_g, "readyness" doesn't necessarily translate into frames being posted
[15:55] <mterry> alan_g, but in this case, for the greeter, sure.  It's because Qt is posting before there is actual content to load
[15:55] <mterry> alan_g, I think the Qt window is drawn and its waiting for the Qml stuff to load and draw etc
[15:55] <mterry> at a guess, I haven't dived into it
[15:57] <alan_g> I don't like the sound of inspecting buffers to guess when they have "real" content. Too much can go wrong
[15:57] <mterry> alan_g, I get that.  What about some Mir signal that a client could post to its server?
[15:58] <alan_g> It sounds like a weird client that posts buffers before it is ready.
[15:59] <alan_g> Is this really a general problem or something restricted to greeter <-> USC?
[15:59] <mterry> alan_g, I get that from a theoretical perspective.  But there are a lot of layers between a Qml file that knows "Component.onCompleted: isReady()" and Mir
[16:00] <mterry> alan_g, those abstractions tend to mean that Qt/Qml throws data at Mir willy nilly
[16:01] <mterry> alan_g, well, when an app launches...  We throw up a white screen right?   What if the shell wanted to show an animation while it loaded
[16:01] <mterry> alan_g, it would need to know when to stop the animation.  When the app is "ready"
[16:02] <anpok> for those cases the first frame is good sign of readyness
[16:02] <alan_g> mterry: I've got a hangout - back in ~10min
[16:02] <mterry> anpok, that's fair.  I suppose click apps are tiny enough
[16:03] <anpok> i wonder whether other configuration changes will come up later
[16:03] <anpok> configuration changes the shell might request from a client..
[16:04] <mterry> anpok, alan_g: I'd be happy if Qt/Qml wouldn't post any frames until everything was loaded.  Is that a feasible change to make?  Ideally we could start "frozen" and unfreeze...  maybe Qt has internal support for doing that
[16:05] <anpok> seems like worthwhile to look into qt for that
[16:05]  * mterry isn't super familiar with Mir and Qt integration, but digs into it
[16:12] <mterry> Maybe it's as easy as not doing show() until we're ready
[16:21] <alan_g> mterry: I don't know much Qt but that sounds like a logical approach
[16:58] <greyback> mterry: I'm not aware of any easy way to prevent Qt drawing until things are "ready"
[16:59] <mterry> greyback, yeah I haven't been able to stop it yet.  Looks like QMirServerApplication even does it somewhere deep down?
[17:01] <greyback> mterry: nope, it doesn't touch render loop. Render loop will spin once the QML scene is ready. But it won't render if the "window" is marked hidden. So maybe http://qt-project.org/doc/qt-5.0/qtgui/qwindow.html#hide might do it
[17:01] <mterry> greyback, I tried removing all the QQuickView code from unity8, but it still is seemingly posting non-null buffers to swap_buffers
[17:02] <greyback> mterry: thing is, Mir is doing the compositing. Is user session appears first, Mir shows it first. It just means Qt hasn't drawn its surface faster than the user session has
[17:02] <mterry> greyback, maybe I don't understand how swap_buffers works, but it seems to be receiving valid buffers from the qml-less shell
[17:03] <mterry> greyback, yeah that makes sense to me. I can have the compositor hide the user session until the greeter is ready
[17:03] <greyback> mterry: as soon as a client asks Mir for a surface to render on, Mir will be aware of that surface and start compositing it - even though nothing has been drawn to that surface yet. So you see black
[17:03] <mterry> greyback, I just need a way to know when the greeter is ready so I can unhide it
[17:03] <mterry> greyback, or in the greeter's alpha case, transparency
[17:04] <greyback> mterry: I don't know how to get Mir to create a Surface invisible by default. But maybe position it off-screen initially, or mark it fully transparent?
[17:04] <mterry> greyback, well I've been using swap_buffers.  Did your approach you mentioned the other day to detect frames use a different mechanism?
[17:04] <greyback> mterry: well that's step 2, no? That once the user session buffer has been drawn to you can then show it?
[17:04] <mterry> greyback, there is a way to get it to allow transparency:  https://code.launchpad.net/~mterry/unity-mir/alpha-greeter/+merge/204069
[17:05] <greyback> mterry: indeed. I need to review that...
[17:06] <mterry> greyback, I actually don't care so much about when the user session is ready.  I just want to know when the greeter is ready so I can show the user session (ready or not) behind it
[17:06] <mterry> Eventually I'll probably be interested in that information too, to add a little "waiting for session" animation
[17:07] <greyback> mterry: oh ok, I misread.In Qt, you can connect to this signal https://qt-project.org/doc/qt-5.1/qtquick/qquickwindow.html#frameSwapped
[17:07] <greyback> mterry: else you need to get that info out of Mir somehow
[17:08] <mterry> greyback, I'm saying that even without the shell creating any windows, Mir compositor is seeing swap_buffer calls with non-null buffers.  So I'm having a hard time determining when a frame is posted if that's not the right way.  You said you had something similar.  Does it rely on swap_buffers or something else in Mir?
[17:11] <greyback> mterry: yep, I added something to ms::BasicSurface::swap_buffers so that I was notified when an actual buffer was swapped
[17:12] <mterry> greyback, yeah I noticed you added a flag_for_render thing?
[17:12] <mterry> Haven't dived into your branch yet, but looks like that's my next step
[17:12] <mterry> But first, lunch
[17:12] <greyback> mterry: yes that's it. That event was emitted when an actual client puffer was swapped
[17:12] <greyback> worked nicely for my purposes
[17:13] <mterry> greyback, that's something you added, right?  I don't see it in trunk
[17:14] <greyback> mterry: yep
[18:28] <mterry> greyback, oh, I see why flag_for_render isn't in trunk, it got removed...
[19:57] <mterry> So I'm seeing swapped buffers from just mir::run_mir's use of DisplayServer...
[19:58]  * mterry is wondering what could be posting buffers internally
[20:09]  * anpok mumbles something unintelligible
[20:20] <anpok> mterry: when the display is on the compositor threads will start drawing the first frame
[20:21] <anpok> if you look in mir::compoistor::MultiThreadedCompositor::start I believe
[20:21] <anpok> schedules a composition for each active output
[20:22] <anpok> so with no surfaces you should get an initial glClear ... and swap buffers for
[20:22] <mterry> anpok, huh without data from the client?
[20:24] <anpok> I think this mainly about getting the display in the right state after turning it on again (or maybe the cause why we see old buffer contents - because we get the trigger before clients can send proper surface contents)
[20:24] <anpok> havent played with that code yet.. so.. add a grain of guessing from my side
[20:24] <mterry> anpok, huh.  OK, I'll need to find a way to tell these apart from client-driven swap_buffer calls.  Maybe only start listening for them after client is set up
[20:25] <anpok> mterry: I wonder if that is proper behavior
[20:26] <anpok> make waiting for the first round of new client buffers is better.. or just informing the shell and letting it decide what to do ..
[20:26] <anpok> you could try without scheduling the first draw - just to be sure
[20:27] <anpok> btw do you happen to know where the "Accept" decision is handled after an incoming call in unity8
[20:27] <anpok> s/make waiting/maybe waiting/ o_O
[20:40] <mterry> anpok, the accept notification is from telephony-service
[21:06] <anpok> mterry: so they then launch the dialer app to take the call
[21:06] <anpok> they==that service
[21:07] <anpok> or searches for a running dialer app
[21:07] <mterry> anpok, yeah
[21:08] <mterry> anpok, launches it via upstart yeah, which either opens or focuses it


[18:46] <yano> https://www.usnews.com/news/best-states/rankings/opportunity/affordability
[18:46] <jenni> [ Best States for Affordability | US News Best States ] - https://bit.ly/2wl98Xi