[05:02] <mup> PR snapd#8592 opened: Add initial support for the hardware-control interface <Created by devec0> <https://github.com/snapcore/snapd/pull/8592>
[07:13] <pstolowski> morning
[07:25] <zyga> Hi
[07:58] <BjornT> hi. i get this when trying to install a snap in a fresh ubuntu:20.04 lxd container: error: too early for operation, device not yet seeded or device model not acknowledged
[07:59] <zyga> Hey BjornT
[08:00] <zyga> This is a rather unfortunate part of our current implementation. After installing snapd there is a brief moment when snapd responds on the socket but is otherwise unable to do anything yet, as it is setting up some stuff
[08:00] <zyga> Normally it lasts a moment
[08:00] <zyga> Does it still happen?
[08:00] <BjornT> zyga: yes, it doesn't seem to go away
[08:01] <zyga> Can you run “snap changes” please
[08:01] <BjornT> zyga: https://paste.ubuntu.com/p/XmmVZfjgNG/
[08:02] <zyga> I can you try doing what you wanted before again? It seems that initialization is now done
[08:03] <BjornT> zyga: ah, yes, now it works
[08:04] <zyga> Cool
[08:13] <klaasvakie> Hi, if I have a snap refresh timer set to our maintenance windows, is there a way to check if there is actually a new snap that's going to be installed during that time?
[08:23] <zyga> klaasvakie: I don't believe there is, we don't have "snap refresh --dry-mode"
[08:23] <zyga> but there's a chance you could guesstimate that by looking at snap info
[08:23] <zyga> and checking the revision numbers installed on your system
[08:23] <zyga> and the channel you are tracking
[08:23] <zyga> and checking if snap info reports a different revision in the channel that is being tracked
[08:24] <zyga> if so, "snap refresh" will pick that revision
[08:27] <zyga> pstolowski: challenge for today, figure out what nukes some packages so that we don't have user-session services
[08:27] <klaasvakie> ok, thanks zyga. I'll script something around this. It basically makes the difference whether I have to stay at work on Friday nights or if I get to go home :)
[08:27] <zyga> the tests/main/session-tool-support test picks it up
[08:27] <zyga> normally this test passes all the time but there's an interaction with another thet where /{,usr/}lib/systemd/user/dbus.socket goes away
[08:28] <zyga> we probably remove the package with --autoremove or something similar
[08:28] <zyga> it's only occurring on deb-based systems so it may be using something hand-coded to apt-get remove stuff
[08:28] <zyga> klaasvakie: have you thought of using an enterprise proxy?
[08:28] <zyga> it's a fantastic way to manage your fleet
[08:28] <zyga> no need to worry about anything
[08:28] <zyga> it lets you control the revisions your systems see
[08:29] <zyga> https://docs.ubuntu.com/snap-store-proxy/en/
[08:29] <zyga> it's super nice iMO
[08:29] <klaasvakie> I have read about it, but I only started playing with 20.04 and snapd recently so I still have lots to learn
[08:30] <zyga> klaasvakie: you install the proxy on your network and configure each device to use it
[08:30] <zyga> klaasvakie: and then the proxy acts both as a cache
[08:30] <zyga> and as a control point where you can pick which revisions are "current"
[08:30] <zyga> let's you manage upgrades this way
[08:30] <klaasvakie> I'll consider the enterprise proxy, thanks for pointing it out
[08:32] <zyga> pstolowski: check this out please
[08:32] <zyga> https://github.com/snapcore/snapd/pull/8592/checks?check_run_id=641794081
[08:32] <mup> PR #8592: Add initial support for the hardware-control interface <Created by devec0> <https://github.com/snapcore/snapd/pull/8592>
[08:33] <zyga> panic in overlord/ifacestate tests
[08:34] <pstolowski> zyga: oh, not good, will check
[09:06] <pstolowski> zyga: running ifacestate tests in a loop, no panic so far (will run hooktest too)
[09:08] <zyga> is mvo off today?
[09:17] <seb128> zyga, yes, according to hr.c.c at least
[09:17] <zyga> ah, thank you
[09:17] <seb128> np
[09:17] <seb128> he should be back tomorrow according to the calendar
[09:22] <pstolowski> zyga: i think they took a swap day for the sprint
[09:22] <zyga> yeah
[09:22] <zyga> well deserved
[10:22] <mup> PR snapd#8593 opened: Stumb implementation of image.Prepare for darwin <Created by stolowski> <https://github.com/snapcore/snapd/pull/8593>
[10:25] <pstolowski> zyga: ^
[10:25] <zyga> oh :)
[10:26] <pstolowski> zyga: it's fine as is in master but fails on my other PR, so making it a prerequisite to reduce diff there
[10:26] <zyga> ok
[10:28] <pstolowski> i've tweaked the description
[10:28] <zyga> +1
[10:29] <pstolowski> ty
[11:23] <zyga> so, what's the most broken thing on master today
[11:24] <zyga> actually the preseed test
[11:24] <zyga> pstolowski: is the test fixed?
[11:24] <zyga> pstolowski: IIRC you sent updates
[11:25] <zyga> is it just unlucky, can it land now?
[11:25] <pstolowski> let me check
[11:25] <zyga> thank you
[11:26] <pstolowski> ah no, it landed. where is it failing?
[11:26] <pstolowski> zyga: ^
[11:26] <zyga> ah, great
[11:26] <zyga> I just need to rebase then
[11:26] <zyga> older branch from last week
[11:26] <pstolowski> ok
[11:33] <pstolowski> zyga: i see tests/main/interfaces-audio-playback-record failure
[11:33] <zyga> yeah
[11:33] <pstolowski> it's interesting
[11:33] <pstolowski> + rm -rf /run/user/12345 /home/test/.config/pulse
[11:33] <pstolowski> 1476
[11:33] <pstolowski> rm: cannot remove '/run/user/12345/doc': Is a directory
[11:33] <zyga> https://github.com/snapcore/snapd/pull/8581
[11:33] <zyga> :|
[11:34] <zyga> maybe I could merge all the fix branches
[11:34] <mup> PR #8581: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
[11:34] <zyga> and just merge them together
[11:39] <pstolowski> ah, that, right..
[11:44] <zyga> I guess
[11:44] <zyga> with some luck
[11:44] <zyga> we can land them
[11:45] <zyga> just reduce the failure ratio one by one
[11:46] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8578 is rather simple if you want to look
[11:46] <mup> PR #8578: interfaces: add host-docs interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
[11:46] <pstolowski> zyga: right, i'll
[12:10] <oSoMoN> forum.snapcraft.io appears to be down
[12:12] <slyon> hey #snappy! What is the best way to build a snap, which uses "base:core20"? The "core20" release does not yet seem to be available inside multipass, which makes my build fail...
[12:13] <zyga> slyon: that's a great question, I don't actually know
[12:13] <mup> PR snapcraft#3096 closed: pluginhandler: export SNAPCRAFT_BUILD_BASE to build environment <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3096>
[12:13] <zyga> slyon: core20 beta will be released soon,
[12:13] <zyga> slyon: I suspect it will be generally available after that
[12:16] <oSoMoN> jdstrand, when you have a chance, can you comment on bug #1876442, please?
[12:16] <mup> Bug #1876442: [snap] chromium causing many audit messages in syslog <snap> <chromium-browser (Ubuntu):New> <https://launchpad.net/bugs/1876442>
[12:17] <slyon> zyga, hmm... thanks for the reply, anyway!
[12:17] <cjp256> slyon: you should be able to use core20 if using snapcraft from candidate/edge channels.  there are rough edges still, so it's not yet in the stable channel.
[12:21] <zyga> jamesh: hey
[12:22] <zyga> jamesh: it's kind of late, are you around by any chance?
[12:36] <ijohnson> morning folks
[12:36] <zyga> hey Ian
[12:36] <zyga> roses are red
[12:36] <zyga> and so is master
[12:36] <zyga> there is no rhyme
[12:36] <zyga> it's a disaster
[12:36] <ijohnson> just like there is no green
[12:36] <zyga> # just made up on the spot
[12:36] <zyga> :D
[12:37] <ijohnson> is it just you and pstolowski today?
[12:37] <zyga> so far
[12:37] <pstolowski> hi ijohnson !
[12:37] <ijohnson> o/ pstolowski
[12:37] <ijohnson> I think Claudio said it was a public holiday there, not sure about Sergio
[12:37] <pstolowski> ijohnson: one tiny nitpick to our lxd test PR, i'm happy to approve
[12:37] <ijohnson> sure, let me look now
[12:38] <zyga> pstolowski: thanks for spotting that, I missed it!
[12:38] <zyga> my back hurts, I would like to exercise a little
[12:38] <zyga> maybe after standup
[12:40] <ijohnson> zyga: so what's all red, is it many things?
[12:40] <ijohnson> zyga: is it anything related to the session-tool stuff we landed last week?
[12:40] <zyga> ijohnson: random stuff we fixed last week that we couldn't land because $(other_thing)
[12:40] <ijohnson> ah
[12:40] <zyga> ijohnson: nothing new AFAIK
[12:40] <zyga> ijohnson: I think we can push it all in with some luck in sequencing
[12:40] <zyga> ijohnson: I'd love to land the pulse test first as it fails most often
[12:41] <zyga> ijohnson: there _is_ something new, something picked up by one of the new tests (session-tool-support)
[12:41] <zyga> ijohnson: something removes a debian package in during execution
[12:41] <zyga> and that breaks all session tests as systemd --user has no service definitions for dbus anymore
[12:41] <ijohnson> ah right I remember you talking with Maciej about this a bit last week
[12:41] <zyga> that's the dbus-user-session package
[12:41] <zyga> I'm trying to find it but no luck yet (though I was distracted with general catch-up and the shutdown bug from Alex)
[12:42] <zyga> ijohnson: if all else fails let's "apt-get install" it in per-test prepare
[12:42] <zyga>  or flag its absence in restore
[12:42] <ijohnson> zyga: re the shutdown bug, did you see my notes on that in the SU doc?
[12:42] <zyga> I'll try to get to that later today but if you beat me to it I'd love to
[12:42] <zyga> oh, no
[12:42] <zyga> let me look
[12:42] <zyga> reading
[12:43] <zyga> My gut feeling was
[12:43] <zyga> it's the same bug we fixed recently in the context of lxd-in-classic
[12:43] <zyga> it's a core system so perhaps this is a false trail
[12:44] <zyga> but perhaps it's a "snap stop ..." command that runs in ExecStop=
[12:44] <zyga> and the sequence is that core18 unmounted snapd
[12:44] <zyga> but we have core
[12:44] <zyga> and now there's a skew
[12:44] <zyga> I wonder what happens on a core system
[12:44] <zyga> where get core18 + snapd
[12:44] <ijohnson> zyga: let's discuss the bug in the internal channel
[12:44] <zyga> and core
[12:44] <zyga> ok
[13:01] <ijohnson> zyga: SU?
[13:01] <zyga> joining
[13:42] <cachio> pstolowski, https://travis-ci.org/github/snapcore/spread-cron/builds/682751904#L3799
[13:42] <cachio> error in the preseed test
[13:43] <cachio> cmatsuoka, https://travis-ci.org/github/snapcore/spread-cron/builds/682751904#L4031
[13:43] <cachio> error in encript test
[13:45] <pstolowski> cachio: thanks, i'll investigate
[13:45] <cachio> pstolowski, thanks
[13:45] <zyga> pstolowski: so journal test failed again
[13:46] <zyga> makes me wonder about something you said recently
[13:46] <zyga> that restarting journal restarts snapd
[13:46] <zyga> do I remember that correctly?
[13:46] <pstolowski> zyga: yes
[13:46] <zyga> pstolowski: on core or on classic as well?
[13:46] <pstolowski> zyga: but now i'm sending sigusr1. i added some debug to the test
[13:47] <pstolowski> zyga: it's core-only config, i didn't check classic
[13:47] <zyga> I tried various things on my system and journal restarts fine
[13:47] <zyga> and snapd does *not* restart
[13:47] <zyga> I wonder why it would behave differently on core
[13:47] <pstolowski> zyga: i think it was only on core 16
[13:48] <pstolowski> zyga: do you have a log from this failure?
[13:48] <zyga> pstolowski: yeah,
[13:49] <zyga> I just restarted journal on core16 - no snapd impact
[13:49] <pstolowski> hmm
[13:50]  * ijohnson -> quick break
[13:50] <zyga> pstolowski: the failure was on
[13:50] <zyga> https://github.com/snapcore/snapd/runs/642670950
[13:50] <zyga> I need a break to stretch my back
[13:50] <zyga> but I will look next
[13:50] <zyga> don't worry :)
[13:58] <pstolowski> zyga: my debug there shows: Process: 21744 ExecStart=/usr/lib/snapd/snapd (code=killed, signal=PIPE)
[13:58] <zyga> oh :)
[13:58] <zyga> hahah
[13:58] <zyga> funny
[13:59] <zyga> sigpipe is ignored in systemd in the future
[13:59] <zyga> I bet we just need a small tweak
[13:59] <zyga> let me check this, this is great hint!
[13:59] <pstolowski> zyga: but why is this?
[13:59] <zyga> pstolowski: I will explain in a sec, just need to check it
[14:00] <zyga> pstolowski: stdout/stderr are piped to journald
[14:00] <zyga> pstolowski: https://github.com/cybozu-go/well/issues/13
[14:00] <pstolowski> zyga: aaaah
[14:01] <pstolowski> zyga: that's annoying, becuase we tell journald to just reload config :/
[14:01] <pstolowski> not to restart
[14:01] <zyga> software
[14:01] <pstolowski> sigusr1
[14:02] <zyga> must be broken somehow :)
[14:02] <zyga> it may just to that, it's still closing the pipe apparently
[14:02] <zyga> I wonder though
[14:02] <zyga> if that leaves us without any logging
[14:02] <zyga> because if we ignore it
[14:02] <zyga> ...
[14:02] <zyga> do we log anywhere?!
[14:03] <zyga> https://bugs.freedesktop.org/show_bug.cgi?id=84923
[14:03] <pstolowski> heh, indeed
[14:03] <zyga> oh my god
[14:03] <zyga> this is so bad
[14:03] <zyga> I mean
[14:03] <zyga> it's just literally killing snapd at _arbitrary_ point due to snap set
[14:03] <zyga> well
[14:03] <zyga> first thing is first
[14:03] <zyga> let's fix the test not to break
[14:03] <zyga> then let's figure out what needs to be done
[14:04] <pstolowski> it's worse, it's killing it while in configure hook
[14:05] <pstolowski> the test cannot be fixed really afaiu, snapd simply gets killed as snap set is being executed
[14:06] <zyga> pstolowski: https://bugs.freedesktop.org/show_bug.cgi?id=84923#c9
[14:06] <zyga> this is the killer
[14:06] <zyga> pstolowski: essentially on core16 we cannot have this feature
[14:06] <zyga> pstolowski: OR
[14:06] <zyga> pstolowski: we need to architect it so that snapd saves state and organizes a controlled "semi shutdown", anticipating SIGPIPE
[14:07] <zyga> pstolowski: we should escalate this
[14:09] <pstolowski> yes
[14:10] <pstolowski> i can prepare a PR that disables the feature & test for now (but not reverts it, just disables)
[14:10] <pstolowski> and then we can think
[14:14] <pstolowski> ah, we can disabled it just on core16
[14:14] <pstolowski> *disable
[14:15] <pstolowski> zyga: thanks for finding these bug reports!
[14:17] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8594
[14:17] <mup> PR #8594: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8594>
[14:17] <zyga> pstolowski: I think we should consider disabling this *feature* on core16
[14:17] <zyga> or consider a backport of journald fix - if feasable - from foundations
[14:18] <mup> PR snapd#8594 opened: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8594>
[14:21] <pstolowski> zyga: giving that core16 will eventually *cough* go away...
[14:21] <zyga> pstolowski: in 2016 ;)
[14:22] <pstolowski> zyga: thank you for the PR, looks great, i wonder if we shouldn't make retry conditional on core16 though, so we don't hide potential issue on other cores
[14:22] <zyga> yeah, I thought about that for a sec
[14:22] <zyga> it's testing now, if it passes I'll send a tweak
[14:22] <pstolowski> sounds good
[14:25] <zyga> pstolowski: ohh
[14:25] <zyga> https://www.theverge.com/2020/5/4/21245940/macbook-pro-13-inch-apple-new-magic-keyboard-price-release-date
[14:30] <zyga> ijohnson, pstolowski, cmatsuoka: please review https://github.com/snapcore/snapd/pull/8594 - mvo can merge this later today if it's +2
[14:30] <mup> PR #8594: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8594>
[14:31] <ijohnson> zyga: looking
[14:31] <cmatsuoka> zyga: ack, checking it
[14:31] <zyga> to clarify, retry-tool there just gives us more chances
[14:31] <zyga> snapd still restarts
[14:31] <zyga> but snap the client, may get a chance to talk to it after reconnection more often
[14:31] <zyga> and may eventually work
[14:31] <zyga> that's all
[14:32] <zyga> this test fails in master randomly but often enough to be annoying
[14:32] <pstolowski> yeah, my only remark is to make retry conditional on core16
[14:39] <ijohnson> zyga: reading backlog, IMHO I think this needs to be escalated to foundations for a core16 backport
[14:39] <ijohnson> zyga: this feature was originally slated for a uc16 customer IIRC
[14:39] <ijohnson> so we can't just not have this feature on uc16 I think
[14:41] <ijohnson> also I agree with pstolowski I think we should only do this on uc16
[14:45] <zyga> I agree on both
[14:46] <zyga> Afk because back pain
[14:59] <mup> PR snapcraft#3104 opened: packaging: use git-based versioning for python package <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3104>
[15:03]  * cachio lunch
[15:07] <zyga> I made the modifications and will push after round of local testing
[15:29] <zyga> pushed now
[15:31] <zyga> pstolowski, ijohnson: the relevant systemd commit is 13790add4bf648fed816361794d8277a75253410
[15:31] <zyga> I will look if we can have a backport
[15:32] <ijohnson> thanks for digging into that zyga, a LP bug is probably a good place to co-ordinate with foundations?
[15:32] <zyga> yeah, I will file one today
[15:32] <ijohnson> cool
[15:32] <pstolowski> zyga: \o/
[15:36] <zyga> ugggh
[15:36] <zyga> ijohnson: it's hopeless
[15:36] <zyga> we are on 219
[15:36] <zyga> we need at least 236
[15:36] <ijohnson> damn
[15:36] <zyga> the infrastructure to support it is substantial
[15:37] <zyga> journald passes a bunch of FDs to save to systemd
[15:37] <zyga> restartes
[15:37] <zyga> *restarts
[15:37] <zyga> and gets them back
[15:37] <zyga> there's no other way
[15:37] <zyga> so I guess ... SOL
[15:37] <zyga> I need to rest again, my back is killing me today :/
[15:37] <zyga> if I forget, please escalate this tomorrow to mvo
[15:37] <ijohnson> of course
[15:38] <ijohnson> I will put some thoughts into the SU doc so we don't forget
[15:38] <zyga> thank you!
[15:46] <ijohnson> pstolowski: so when we go to change the persistence of journald, can we change a config file and then just reboot the whole system ?
[15:46] <ijohnson> it wouldn't be  great that we have to restart the system just to change logging but it's certainly better than having things all randomly die
[15:47]  * ijohnson goes to read the implementation in snapd
[15:47] <pstolowski> ijohnson: reboot is not needed, it's a problem only with core16
[15:48] <ijohnson> pstolowski: no I mean for core16 could we reboot?
[15:48] <pstolowski> ijohnson: ah, i see. well, yes we could i suppose
[15:48] <ijohnson> pstolowski: because afaict the issue is that when we reload journald it kills everything which is bad, so maybe instead of reloading journald we just change some config file behind journald's back and then reboot the system so upon boot it would be fixed
[15:49] <ijohnson> I presume that journald is not inotify'ing the config files, etc.
[15:49] <pstolowski> ijohnson: heh, there is no config file
[15:49] <ijohnson> pstolowski: so there's just the dir that's created in /var/log/journal?
[15:49] <pstolowski> ijohnson: you just create /var/log/journal
[15:49] <pstolowski> ijohnson: and reboot
[15:50] <ijohnson> pstolowski: hmm maybe worth a try
[15:50] <pstolowski> ijohnson: normally you send sigusr1 to notify journald about change
[15:51] <ijohnson> right, so on uc16, instead of sending sigusr1, we would just request a restart
[15:52] <pstolowski> ijohnson: yes
[15:52] <ijohnson> pstolowski: would we need some kind of special code to make the change/tasks associated with this work, or could I just try putting in handleJournalConfiguration a call to restart snapd ?
[15:53] <ijohnson> hmm although that's probably not the level we want to restart things
[15:53] <ijohnson> err I mean reboot the system
[15:54] <pstolowski> ijohnson: that's a fair point
[15:55] <ijohnson> alright well I'll just leave this idea in the SU docs for folks to think about, I have a bit too much on my plate to dig more deeply on this
[16:08] <ijohnson> pstolowski: did you see I assigned you a bug on Friday related to hotplug and auto-connect?
[16:08] <ijohnson> https://bugs.launchpad.net/snapd/+bug/1876356
[16:08] <mup> Bug #1876356: greedy auto-connect doesn't work with hotplug <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1876356>
[16:08] <ijohnson> just curious if you have any thoughts on why that doesn't "just work"
[16:08] <pstolowski> ijohnson: ah, no, i didn't
[16:08] <ijohnson> no worries, I think it's a lowish priority thing
[16:10] <pstolowski> ijohnson: thanks for all the details in the report, i'll see if there is anything obvious
[16:10] <pstolowski> missing
[16:20] <mup> Bug #1876478 changed: Automatic snap refreshes changes state of service from stopped to running <Snappy:Invalid> <https://launchpad.net/bugs/1876478>
[16:41] <mup> PR snapcraft#3105 opened: build provider: clean incompatible build-environments <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3105>
[17:11] <zyga> it seems the portal test is leaking stuff
[17:11] <zyga> | |-/run/user/12345                   tmpfs                                                                                tmpfs      rw,nosuid,nodev,relatime,size=377196k,mode=700,uid=12345,gid=12345                                   shared
[17:11] <zyga> | | `-/run/user/12345/doc             /dev/fuse                                                                                fuse       rw,nosuid,nodev,relatime,user_id=12345,group_id=12345                                                shared
[17:11] <zyga> oh well
[17:11] <zyga> another test to fix
[17:14] <ijohnson> zyga: could we just do `[ -d $XDG_RUNTIME_DIR/doc ] && umount $XDG_RUNTIME_DIR/doc` ?
[17:14] <ijohnson> at the end of teardown_portals ?
[17:16] <zyga> ijohnson: perhaps but I doubt that is the problem
[17:16] <zyga> the problem is more comple
[17:16] <zyga> *complex
[17:16] <zyga> we *activate* portals each time we invoke a program that seems to have a desktop plug (at all)
[17:16] <zyga> so any test using snap run may trigger it
[17:16] <ijohnson> Hmm really?
[17:16] <zyga> yeah
[17:17] <zyga> I suspect we run a program via su -u test
[17:17] <zyga> and that runs the portal outside of the session
[17:17] <zyga> so just happily in the space
[17:17] <zyga> I'll add a small check and run all the tests
[17:17] <zyga> what we really need is proper session teradown
[17:18] <zyga> we may need to change session-tool --restore to wait for linger shutdown as well, I need t ocheck
[17:18] <zyga> but first, need to find that test that leaks this
[17:18] <zyga> saving the log archive
[17:21] <zyga> we ran this before: 2020-05-04T16:33:35.0630508Z 2020-05-04 16:33:35 Preparing google:ubuntu-19.10-64:tests/main/interfaces-desktop-document-portal (may041608-600544)...
[17:24] <zyga> https://www.irccloud.com/pastebin/y3YiWMAY/
[17:24] <zyga> it's one of those tests for sure :)
[17:25] <zyga> ijohnson: oh my
[17:25] <zyga> that test *badly* need session-tool
[17:27] <zyga> why is that test using snap-try?
[17:28] <zyga> ijohnson: session-tool beats su not because of any technical choices but simply becaues it puts the damn username before the damn command
[17:28] <ijohnson> Hahaha
[17:29] <ijohnson> Yeah I will look into this some more after lunch if you haven't figured it out
[17:29]  * ijohnson -> lunch
[17:32] <zyga> done
[17:32] <zyga> ijohnson: I'll send a PR shortly
[17:36] <zyga> ijohnson: I wonder if I should grep for "su" in the code
[17:36] <ijohnson> you might be afraid of what you find
[17:37] <mup> PR snapd#8595 opened: o/ifacestate/handlers.go: fix typo <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8595>
[17:39] <mup> PR snapd#8589 closed: tests: port user-session-env to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8589>
[17:39] <mup> PR snapd#8594 closed: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8594>
[17:39] <zyga> wooooot
[17:40] <mup> PR snapd#8581 closed: tests: port pulseaudio test to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8581>
[17:40] <mup> PR snapd#8587 closed: tests: session-tool allows preparing/restoring for many users <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8587>
[17:47] <ijohnson> yay mvo for the win
[17:55] <zyga> interesting stuff I find
[17:55] <zyga> I wonder if 19.10 specific
[17:55] <zyga> maybe some fluke of bugs interacting
[17:56] <zyga> so on 19.10 session-tool -u test --prepare
[17:56] <zyga> seems to ... not make a session
[17:56] <ijohnson> that's the only reason snaps work at all sometimes is that bugs interact and cancel each other out
[17:56] <zyga> ??!
[17:56] <zyga> hahaha
[17:56] <ijohnson> so session-tool has become the-tool
[17:56] <zyga> isn't that like half of current physics theories ;)
[17:56] <ijohnson> on 19.10 at least
[17:56] <zyga> all the infinities cancel each outher ;)
[17:56] <ijohnson> yep!
[18:01] <zyga> ijohnson: totally off-topic, over weekend I got an i2c DS 1307 RTC add-on to my raspberry pi
[18:01] <zyga> maybe next weekend I'll have a snap that manages time
[18:01] <ijohnson> very nice
[18:01] <zyga> though not perfectly (late boot)
[18:01] <zyga> I wonder if there would be a way to run some super-special things earlier via snapd
[18:01] <ijohnson> I have an RTC board too ... somewhere in my collection of random add-on things
[18:01] <zyga> (with appropriate interfaces)
[18:01] <zyga> cool
[18:02] <ijohnson> true, it would be most useful to have a RTC available during early boot
[18:02] <zyga> I wonder if it uses the same chip, I heard DS 1307 is popular
[18:02] <zyga> ijohnson: sadly it's not a /dev/rtc kind of thing
[18:02] <zyga> maybe it could be if device tree said something
[18:02] <ijohnson> yeah most rpi things seem to not be quite as simple plug and play like that
[18:02] <zyga> but I don't know how to do that
[18:02] <ijohnson> yeah I haven't looked into that at all either
[18:03] <zyga> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt <- it seems to be supported
[18:06] <ijohnson> nice so I bet with your own pi gadget it would probably just work
[18:07] <zyga> I don't know how to use DBTs though :)
[18:07] <zyga> more to learn
[18:36] <zyga> digging deeper
[18:36] <zyga> but I will EOD soon
[18:37] <zyga> really not well today
[18:37] <zyga> and it's late
[18:38] <mup> PR snapd#8595 closed: o/ifacestate/handlers.go: fix typo <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8595>
[18:48] <zyga> drat
[18:48] <zyga> my daughter turned off my laptop
[19:21] <zyga> I see a pattern now, I wonder what's the cause
[19:21] <zyga> but I also have a solution
[19:22] <zyga> just cannot justify it apart from "it seems to work"
[19:22] <zyga> I guess some systemd sources are to be read
[19:38] <mup> PR snapcraft#3106 opened: sources: enable git, local, and tar handlers for all platforms <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3106>
[19:39] <mup> Bug #1875543 changed: Ubuntu 20.04 "A stop job is running for Snappy Daemon" during shutdown <20.04> <ubuntu> <Snappy:New> <https://launchpad.net/bugs/1875543>
[19:42] <mup> Bug #1876478 opened: snap stop does not explain that automatic snap refreshes starts stopped, enabled svcs <Snappy:Confirmed for morrisong> <https://launchpad.net/bugs/1876478>
[19:46] <zyga> ijohnson: around? :)
[19:46] <ijohnson> yep
[19:47] <zyga> ijohnson: so here's what I learned: on 19.10 loginctl disable-linger leaves<EMAIL_ADDRESS>in user-12345.slice
[19:47] <zyga> why? I don't know yet
[19:47] <zyga> stopping the slice reliably stops everything and /run/user/12345 goes away
[19:48] <zyga> on 20.04 I don't see it
[19:48] <ijohnson> huh
[19:48] <zyga> I wonder if there's an interplay with some workarounds
[19:48] <ijohnson> that feels like a bug to me
[19:48] <zyga> so I patched session-tool to add the stops and the extra check for /run/user/12345 (for the test user obviously)
[19:48] <ijohnson> in systemd that is
[19:48] <ijohnson> wait but shouldn't the systemd version be basically the same between 19.10 and 20.04 ?
[19:49] <zyga> and I'm running a pass to see how it affects the "fleet" of systems running user-mounts test
[19:49] <zyga> ijohnson: 242 vs 245
[19:49] <zyga> ijohnson: we have a logind workaround for 242 (fixed in ... wait for it ... 243!)
[19:49] <zyga> ijohnson: so maybe more bugs bugs bugs
[19:49] <zyga> ijohnson: I've yet to look at logind source but that's my next plan
[19:50] <zyga> I kind of want core 20 now
[19:50] <zyga> at least so many systemd bugs are gone there
[19:50] <ijohnson> haha
[19:51] <zyga> ijohnson: with the change user-mounts with trivial restore (session-tool -u test --restore) leaves no junk behind
[19:51] <zyga> and I bet this improves interplay with other tests
[19:51] <zyga> but why? :D
[19:51] <zyga> beats me
[19:51] <ijohnson> bugs that's why
[19:52] <zyga> it's super late and my wife looks at me with that very clear "STOP WORKING" eyesight
[19:52] <zyga> so I'll defer that
[19:52] <ijohnson> ttyl zyga :-)
[19:52] <zyga> but I'll send the patch for user-mounts in today still
[19:52] <zyga> now suppe r:)
[20:44] <zyga> ijohnson: session-tool patch https://github.com/snapcore/snapd/pull/8596
[20:44] <mup> PR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>
[20:44] <mup> PR snapd#8596 opened: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>
[20:44] <ijohnson> Nice
[20:45] <zyga> it's not perfect because "Unknown reasons" but it's progress
[20:46] <zyga> I also suspect this could have some impact on other tests, as they were effectively leaking more bits
[20:47] <zyga> plus this is a PR for master after mvo landed all the good fixes
[20:47] <zyga> so with a bit of hope it won't fail
[20:52] <zyga> ijohnson: and this is the user-mounts test
[20:52] <zyga> https://github.com/snapcore/snapd/pull/8597
[20:52] <mup> PR #8597: tests: port user-mounts test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8597>
[20:52] <zyga> and some typo fixes
[20:53] <mup> PR snapd#8597 opened: tests: port user-mounts test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8597>
[20:53] <zyga> I'll break for an hour and walk the dog
[21:05] <ijohnson> zyga approved the session-tool one and commented on the other one
[21:05]  * ijohnson EODs
[22:20] <mup> PR snapcraft#3106 closed: sources: enable git, local, and tar handlers for all platforms <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3106>


[01:10] <hardwire> I am having a bit of a rough time figuring out how to properly mark a "working" configuration/version set and then allowing a rollback to that set if healthchecks are not passed after an OTA update.
[01:10] <hardwire> on core20/core18
[01:11] <hardwire> anybody experienced with this?
[01:14] <hardwire> goal is to use iot edge agents to initiate a snap refresh of product code and potentially OS level code and issue a reboot, do health checks, and then eventually mark a working set - ultimately allowing for a user to power off the device and power it back on reverting to a previous marked set.
[01:14] <hardwire> near as I can tell snap keeps old versions around.
[01:42] <ogra> hardwire, canonical is shot down for the last two weeks of each year ... better ask in the forum
[01:54] <hardwire> ok thanks for the heads up
[01:54] <hardwire> off to the source
[02:01] <ivo_cavalcante> didn't know this, ogra; good to know
[02:02] <ivo_cavalcante> was really finding activity on snap forums kind of low, from Canonical employess
[02:02] <ivo_cavalcante> now I know why
[02:02] <ivo_cavalcante> :)
[02:03] <ogra> yeah, we do that every year ...
[02:04] <ivo_cavalcante> that's new to me


[09:53] <xnox>     def run_success_cmd(self):
[09:53] <xnox>         if self.success_cmd != '':
[09:53] <xnox>             self.debconf_progress_info(
[09:53] <xnox>                 self.get_string('ubiquity/install/success_command'))
[09:53] <xnox>             execute_root('sh', '-c', self.success_cmd)
[09:53] <xnox> realtime-neil:  ^
[09:53] <xnox> i see no checking of failures =)
[09:54] <xnox> it's logged, and true/false returned, but return from it is not checked. What do you expect to happen?
[09:54] <xnox> success_command is normally meant for calling home, after install is completed.
[09:55] <xnox> `preseed/early_command` and `preseed/late_command`  => are executed from initrd for ubiquity, and are normally meant to generate/affect preseeding.
[13:27] <realtime-neil> xnox: I understand; I'll have to dig into what I was doing with the `preseed/{early,late}_command` to get more detail on what wasn't working for me.
[13:28] <realtime-neil> xnox: When you say that the `preseed/late_command` is "executed from the initrd", that affects the calling context only, correct? And not the expected ordering? I.e., it executes after (almost) everything in the ubiquity is done, correct?


[12:29] <ogra_> highvoltage, hmpf, so i need the invoice to get the box ... can you (have someone) scan it and mail it to me ?
[12:30] <highvoltage> ogra_: ok. will get it for alkis too
[12:33] <ogra_> silly stuff
[12:33] <ogra_> i had it in my hands already
[15:12] <stgraber> highvoltage: what's the status of the slideshow for Edubuntu?
[15:13] <stgraber> highvoltage: knome just poked me in #ubuntu-release for a UIFe for Xubuntu for some changes, so I'm going to upload it later today, would be nice to bundle any relevant Edubuntu change
[15:16] <highvoltage> stgraber: we're not going with a new nice fancy slideshow this time (too late), but I'd like to go through it again (I'll do that this afternoon then) just to make sure that what it says is still correct
[15:17] <stgraber> highvoltage: ok. Push directly to the branch and file a UIFe for the changes you're making so I can approve it and upload it before EOD
[16:42] <micahg> bencer: you should close the FFe on upload
[16:42] <micahg> (i.e. include it in the changelog)
[16:42] <bencer> on the changelog you mean? or can i do it manually?
[16:42] <bencer> ideally changelog i guess
[16:43] <stgraber> yeah, changelog is preferred, that way people can see that the FFe was granted for a specific upload containing new features
[16:43] <micahg> bencer: you also need to include any debian dir changes in the changelog
[16:44] <bencer> ok, i will review that with the final upload
[18:16] <stgraber> highvoltage: how's that slideshow work going?
[18:19] <highvoltage> stgraber: I pushed it, does it really really need an FFe filed?
[18:20] <stgraber> highvoltage: yes, UIFe actually
[18:20] <stgraber> just file a generic bug against ubiquity-slideshow-ubuntu with the list of what you changed and I'll ack it
[18:20] <highvoltage> ah right. ok
[18:23] <highvoltage> stgraber: https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1051023
[18:24] <stgraber> highvoltage: thanks
[18:26] <stgraber> granted
[18:26] <stgraber> will look at refreshing the translations and upload now
[18:28] <stgraber> highvoltage: I'll update the LTSP slide as Applications -> Other no longer exists in Unity
[18:31] <highvoltage> stgraber: k
[18:31] <stgraber> also, arkose-nautilus doesn't exist for nautilus3, will remove that line
[18:40] <stgraber> highvoltage:
You can try out a demo from this live environment by clicking on the LTSP Liver icon in the launcher.
 ?
[18:40] <stgraber> *LTSP Live
[18:42] <highvoltage> yep


 I tried running the clock app AP tests on a fresh vivid install and I get the following error http://paste.ubuntu.com/10596507/
[22:48] <daz_> anyone available to help?
[22:56] <daz_> got it


[12:04] <xnox> apw, any plans to do mainline builds for s390x?
[12:04] <xnox> e.g. http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety/
[12:05] <apw> xnox, hmmm, i wonder how we decide
[12:05] <xnox> we are way ahead of everyone else and quite often bugs like "works everywhere but ubuntu" is actually "broke in mainline since X.Y"
[12:05] <xnox> there is ppc64el builds....
[12:05] <xnox> *are
[12:06] <apw> xnox, seem we have a nice non-maintable list ... yay ... so presumably for X+ right ?
[12:07] <xnox> apw, yes please.
[12:08] <apw> xnox, ok added, deployed, and a v4.6 rebuild requested
[12:08] <apw> xnox, we'll see what happens
[12:08] <xnox> cool
[12:39] <rtg> cyphermox, UEFI test kernels at ppa:canonical-kernel-team/unstable
[12:40] <apw> rtg, there was a lot of failure messages in my inbox, was that intentional "don't waste cycled build" failures ?
[12:41] <rtg> apw, I had trouble getting 3.13 to build. It wasn't parsing the ABI number correctly when I added a '~uefi' into the version. I prolly forgot to cancel one of the failing builds before uploading again.
[12:41] <apw> rtg, ahh ok
[12:42] <rtg> it still doesn't build arm64, but I think we can just turn off UEFI on that arch
[12:42] <apw> rtg, sounds like we are missing some packaging back there
[12:42] <apw> rtg, in older releases likely yes we can, but newer ones it may well exist i think
[12:42] <rtg> apw, yeah, I was too tired to figure it out, so I just dropped the '~uefi'
[12:43] <rtg> vivid and wily built OK
[12:58] <rtg> apw, did you change CONFIG_UNIX=m in the mainline build ?
[13:01] <apw> rtg, no, that comes directly from the unstable configs
[13:01] <apw> rtg, so bugger, that means i will ahve to rebuild that _again_ when you fix it
[13:01] <rtg> apw, one of the bug reporters suggested the correct fix was in udev or initrd, though I suppose I could revert the config change for now
[13:01] <apw> xnox, ok s390x builds are now in there anyhow
[13:02] <apw> rtg, it is a trick chicken and egg issue as module loading is handled on demand by udev
[13:03] <rtg> apw, reverted and pushed
[13:03] <apw> rtg, i'll respin that 4.6 so it gets the update
[13:03] <apw> and whoever was testing and failing, can retest
[14:09] <cyphermox> rtg: great. so does that mean there hasn't really been much testing for all of it?
[14:10] <cyphermox> rtg: apw: how far are we from a kernel SRU cycle so we can SRU $everything $everywhere ? ;)
[14:10] <rtg> cyphermox, I've done my own local testing to make sure it does what I think it should. I'm sure these patches could use a bit more exposure.
[14:10] <apw> cyphermox, we start a new cycle next week, so nominally patches need to be avilable today to hit this cycle
[14:11] <rtg> cyphermox, next SRU cycle starts Monday
[14:11] <cyphermox> right, I'm trying to decide if we want to SRU everything now and test there if we're confident enough that things are good, or wait another three weeks or whatever to give us time to test everything in a PPA, on all releases, upgrades, etc.
[14:12] <apw> cyphermox, if we wait 3 weeks can we still hit the point release ?
[14:12] <rtg> cyphermox, given the difficulties consumers of DKMS may face, I'd advise testing, testing, testing
[14:12] <cyphermox> it definitely wouldn't be better to fail to validate and block other things though
[14:13] <cyphermox> 16.04.1 would be July 21st, we'd start to cut it close
[14:14] <cyphermox> I said three weeks, but I really means next one of your SRU cycles
[14:14] <rtg> cyphermox, are all of the user space bits well on their way to -updates ?
[14:14] <apw> cyphermox, will all the rest of the bits be out before then, and do they have to be, i assume they do
[14:14] <cyphermox> rtg: no, things will land along with the kernel, in proposed at the same time
[14:14] <apw> rtg, in theory all of this new code is rendered sterile of we turn off enforcement by default right ?
[14:15] <apw> rtg, so we could consider applying all but that (assuming there is a kernel command line to turn it on for testers)
[14:15] <rtg> apw, its a CONFIG option only right now
[14:15] <rtg> otherwise it kinda defeats the purpose
[14:16] <cyphermox> yeah, I think we shouldn't mess with that especially since it's pretty much what we want to test
[14:19] <apw> mamarley, the v4.6 mainline kernel has been rebuilt with the AF_UNIX thing reverted (in theory)
[14:19] <mamarley> apw: Cool, thanks!
[17:24] <cyphermox> rtg: what about a precise kernel? that seems to be missing from the PPA (or I'm not looking at the right place)
[17:25] <rtg> cyphermox, the Precise kernel did not support signed modules, so we'll have to make do with the LTS Trusty kernel
[17:26] <cyphermox> that's not in the PPA though?
[17:27] <rtg> cyphermox, nope, but you can install the Trusty kernel by hand into a Precise user space
[17:28] <cyphermox> this is a cutoff point at which we won't be making any more of any kernels that can't do signed modules, otherwise we'd be diminishing the value of having a new key (although we haven't got a new key just yet, that will go later)
[17:29] <rtg> cyphermox, personally I think we should just leave Precise as is.
[17:30] <rtg> that, or you'll have to make the new shim dependent on LTS Trusty kernel.
[17:33] <cyphermox> as long as we're supporting precise, I think we can't discount the fact that there may be kernel or other updates -- there's just one key for signing Secure Boot stuff, so I think we need to care about it
[17:34] <cyphermox> afaict that's 10 more months of support, seems unlikely that there won't be some security issue to fix within that time, but I won't pretend I pay much attention to how often kernel SRUs happen on precise :)
[17:35] <rtg> cyphermox, I really don't know either, but I'm sure there will be at least one.
[17:36] <cyphermox> ok
[17:39] <cyphermox> so we should start validating 16.04 since 16.04.1 what's coming up fastest; then trusty (point release in august), and as time permits wily and precise
[17:39] <rtg> cyphermox, ack
[17:40] <cyphermox> rtg: do you have time to do testing on your own with everything? I mean including the userland bits and enabling dkms packages, upgrading to a new release, etc. ?
[17:40] <rtg> cyphermox, we also support LTS Utopic and Vivid for awhile yet.
[17:40] <cyphermox> I have the userland pieces at ppa:cyphermox/efi
[17:40] <cyphermox> ok
[17:41] <rtg> cyphermox, as long as a QEMU instance is OK for testing
[17:41] <cyphermox> needless to say this all means it can't land in the SRU cycle this coming Monday
[17:41] <cyphermox> rtg: should be
[17:41] <cyphermox> you'll want to insert certificates to enable secureboot with the right signature checking
[17:42] <rtg> cyphermox, that is how I tested these kernels thus far, i.e., enrolled my own keys
[17:42] <cyphermox> https://wiki.ubuntu.com/SecurityTeam/SecureBoot
[17:42] <cyphermox> right
[17:42] <rtg> cyphermox, yep, I used jdstrand's script to enroll keys. worked like a charm
[17:43] <cyphermox> I have an unbroken system that can do hardware SB with the MS keys now, so I'll reinstall 16.04 there now and start it
[17:43] <cyphermox> rtg: cool; I haven't had as much luck, but I was able to enroll keys otherwise
[17:43] <rtg> cyphermox, I don't have a bare metal box that will allow me to enroll keys, so I've had to use QEMU.
[17:44] <cyphermox> well
[17:44] <cyphermox> the only keys you ever need enrolled are the Microsoft ones
[17:44] <cyphermox> we're not changing shim itself, so past this it can be done programmatically in MokManager
[17:44] <cyphermox> I think the wiki is missing the relevant info for this; I'll see about adding it
[17:45] <rtg> ok, good point
[17:45] <cyphermox> MS> at the firmware level
[17:45] <cyphermox> Canonical> at the MokManager level
[17:45] <cyphermox> this means your signing keys for the PPA also need to happen at the MokManager level
[17:46] <rtg> I guess that is a change from what I understood needed to happen.
[17:46] <cyphermox> sudo mokutil --import $cert
[17:47] <cyphermox> what did you understand?
[17:47] <rtg> I thought we had to update shim with a new key.
[17:47] <cyphermox> we will
[17:47] <cyphermox> but we're not there yet
[17:47] <rtg> ok
[17:47] <cyphermox> that will be the very last piece, along with an updated grub that disables loading unsigned
[17:48] <rtg> cyphermox, lemme know when the wiki is updated and I'll get started testing.
[17:49] <cyphermox> rtg: ok, but you got the jist of it -- you want to re-sign stuff with your own key since we don't have the PPAs certificate, and then import that cert with the mokutil command above
[17:49] <rtg> yup
[17:49] <cyphermox> on reboot that will get you a blue screen that will have you confirm adding the key
[17:50] <rtg> makes sense
[17:51] <rtg> cyphermox, that reminds me, you don't expect older kernels to read that key from MOK, right ? Only Xenial+ knows how to do that.
[17:52] <rtg> the only recourse for DKMS users on anything prior to Xenial is to disable secure boot.
[17:55]  * rtg pops out for some lunch
[18:18] <cyphermox> well, we at least expect that sudo mokutil --disable-validation will DTRT, and let people boot and load unsigned kernels.
[18:18] <cyphermox> and load unsigned modules
[18:22] <rtg> cyphermox, yes. I have tested that functionality.
[18:41] <cyphermox> rtg: right
[18:42] <cyphermox> well, I'm writing a trusty image to USB now to give this a shot ; I need to test something else to at the same time anyway
[20:02] <cyphermox> rtg: will you add linux-lts-wily and others to the ppa?
[20:04] <rtg> cyphermox, not unless you really want me to. The non-LTS Wily kernel is functionally identical, just built with a newer toolchain.
[20:07] <cyphermox> rtg: it's kind of easier to just dist-upgrade the system with the PPAs enabled rather than mucking around to install various extra packages
[20:07] <cyphermox> we want to make sure upgrades between distros and package upgrades will work, so it's good to be able to pick things up as if they were from the official archive.
[20:08] <rtg> cyphermox, alright, but it'll likely be Monday before they are ready.
[20:09] <rtg> cyphermox, I assume you want all 4 LTS kernels in Trusty ? e.g., Utopic, Vivid, Wily, Xenial
[20:09] <cyphermox> ideally, yes. we want to test everything very carefully and then do the uploads to proposed
[20:09] <rtg> cyphermox, ok


[11:48] <davmor2> morning all
[11:49] <davmor2> ara: did you turn twitter into just a method to publicise what your liking on last.fm ;)
[11:53] <ara> davmor2, did I? I didn't know it was somehow linked, I have to unlink them
[11:55] <davmor2> ara: ignore me it's my new android phone.  I forgot it had my last.fm details too.
[11:56] <ara> davmor2, good to hear :)


[01:53] <nhaines> Meeting coming up in 7 minutes!
[02:00] <nhaines> #startmeeting
[02:00] <nhaines> Welcome to the Ubuntu California meeting for September 9th, 2018.
[02:00] <nhaines> Today's agenda can be found at https://wiki.ubuntu.com/CaliforniaTeam/Meetings/18September09
[02:00] <nhaines> #topic Upcoming events
[02:01] <nhaines> Canonical is thinking about a machine learning seminar based around Kubernetes in the SoCal area end of this month or early next month, but I haven't heard from them as quickly as I expected.  So maybe October (or never) is more like it.
[02:02] <nhaines> They'd like to work with us to put on the event if possible, so I'll keep everyone up to date if plans solidify.
[02:03] <nhaines> Ubuntu 18.10, the "Cosmic Cuttlefish" release, is scheduled to release on October 18th, which is in five and a half weeks!
[02:03] <nhaines> #topic Announcements
[02:03] <nhaines> Are there any announcements to be made at this time?
[02:04] <nhaines> #topic Agenda
[02:04] <nhaines> There are no items on tonight's agenda.
[02:04] <nhaines> #topic Other business
[02:05] <nhaines> Any other business before we wrap up this meeting?
[02:10] <nhaines> Okay, our next meeting is September 23rd.  See everyone then!
[02:10] <nhaines> #endmeeting


[12:03] <shtylman> evand: the brnach I will be working out of is ~shtylman/ubiquity/kde_themeing currently, I have just started to make the transition to the new theme the frist one or two pages work
[12:04] <evand> shtylman:  okay, thanks for the heads up.
[14:10] <CIA-3> ubiquity: mterry * r3323 trunk/ (54 files in 6 dirs): add emacs modelines for ease of tabbing
[14:13] <CIA-3> ubiquity: mterry * r3324 trunk/ (3 files in 2 dirs): remove horizontal separator in gtk dialog
[14:15] <davmor2> cjwatson, evand: is there a reason for the padlock on today's cd's ubiquity desktop icon?
[14:16] <cjwatson> usually means you can't write to it, but don't know
[14:16] <cjwatson> bet I have a guess though
[14:17] <evand> it's owned by root in this case
[14:17] <cjwatson> I reckon busybox sed -i doesn't preserve ownership
[14:17] <cjwatson> you might want a manual chown in there, in casper
[14:17] <evand> indee
[14:17] <evand> d
[14:18] <davmor2> evand: I just noticed it was owned by root :)
[14:18] <CIA-3> ubiquity: mterry * r3325 trunk/ (debian/changelog ubiquity/frontend/noninteractive.py): fix noninteractive bug when setting the user's language
[14:20] <cjwatson> davmor2: BTW can you check to see if aufs is in use? 'ps aucx | grep unionfs-fuse' should say nothing, and 'lsmod | grep aufs' should list aufs
[14:20] <cjwatson> the kernel team put that back in recently
[14:22] <davmor2> aufs 150604 1
[14:22] <davmor2> and ps aucx showed nothing
[14:22] <cjwatson> rock on
[14:27] <CIA-3> casper: evand * r654 casper/ (debian/changelog scripts/casper-bottom/10adduser): Busybox sed does not preserve ownership, so chown after using it.
[14:27] <davmor2> so the padlock is nothing to worry about then :)
[14:27] <evand> nope
[14:27] <davmor2> cool :)
[17:09] <cjwatson> evand: can you confirm when you're planning to upload usb-creator with the windows backend? it needs to be Monday at the latest for a3
[19:10] <CIA-3> partman-lvm: cjwatson * r1223 ubuntu/lib/lvm-base.sh: fix lock detection
[19:11] <CIA-3> partman-lvm: cjwatson * r1224 ubuntu/lib/lvm-base.sh: typo
[19:11] <CIA-3> partman-md: cjwatson * r937 auto-setup/lib/md-base.sh: fix lock detection
[21:18] <CIA-3> partman-crypto: cjwatson * r684 auto-setup/ (5 files in 3 dirs): (log message trimmed)
[21:18] <CIA-3> partman-crypto: * Add a menu under "Configure encrypted volumes", making this more in line
[21:18] <CIA-3> partman-crypto:  with partman-lvm and partman-md.
[21:18] <CIA-3> partman-crypto: * Rearrange crypto configuration per the
[21:18] <CIA-3> partman-crypto:  foundations-karmic-server-installer-improvements specification. Instead
[21:18] <CIA-3> partman-crypto:  of requiring partitions to be set for use as physical volumes for
[21:18] <CIA-3> partman-crypto:  encryption first, we now offer all partitions that could be used as
[21:19] <cjwatson> foundations-karmic-server-installer-improvements done bar the uploads
[21:33] <juliux> hi
[21:33] <juliux> is there a list online which packages are installed if i choose ubuntu-cli system?
[21:40] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.hardy/structure, start at standard (http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.hardy/standard) and then also look at the depended-upon sets listed in the structure file
[21:40] <cjwatson> in other words, http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.hardy/standard plus http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.hardy/minimal plus http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.hardy/required


[02:23] <aedend> cyberanger, made some changes. Was able to drop all the ip's except for the ones from google
[02:24] <cyberanger> How?
[02:25] <cyberanger> I read a little more on that site, and I think it's a flawed test
[02:26] <aedend> server.conf changed added push "redirect-gateway autolocal"
[02:26] <aedend> added also, push "dhcp-option DNS <IP_ADDRESS>"  and  push "dhcp-option DNS <IP_ADDRESS>"
[02:29] <aedend> also added dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf
[02:31] <aedend> cyberanger, I tried https://ipleak.net/ and it gave even more info. still have dns leak
[02:49] <cyberanger> hrm
[02:49] <cyberanger> I think it's a false positive
[02:51] <aedend> from two different sites?
[02:55] <cyberanger> yeah, if they are running the same code to check, same method
[17:47] <aeden__d> cyberanger: sorry about last night. Disconnected and it got late so I called it quits for the night
[17:48] <aeden__d> Just wanted to say thank you for all your help. I really appreciate it


 welcome @DiogoConstantino
 thanks for the live UTW help on the podcast.
 Tested today the latest daily 20210409 with VBox and all good (re @RikMills: @Leokolb A fix for the Kubuntu installer crash on safe graphics/VM has been uploaded to debian. Hopefully that will be synced to Ubuntu later)
 Thanks \o/ (re @Leokolb: Tested today the latest daily 20210409 with VBox and all good)
 plasma 5.21.4 bugfix and translation update should be hitting the hirsute release pocket soon. please test if on Kubuntu or Studio
 you're welcome (re @philipz: thanks for the live UTW help on the podcast.)
 I still have to do some follow up on bugs
 hope to do it on the weekend
 I want to give a personal thank you to all of you who got involved! And for those of you who were first timers, I hope it was a good experience and you keep testing!
 The only thing I want is to start preparing earlier next time
 also it would be cool if the qa website got some, and some flavours made it easier for those that use the qa website to report bugs on the write place
 also it would be cool if the qa website got some attention from the web team, and some flavours made it easier for those that use the qa website to report bugs on the write place (edited)
[16:07] <qydw_> Plasma 5.21.5 has the fix for the window size of maximized GTK apps under wayland. will ubuntu 21.04 get the update?
[16:08] <qydw_> https://bugs.kde.org/show_bug.cgi?id=432326
 Those are some great ideas, and we'll have some more intentional feedback gathering well before the next testing cycle starts to find out how we can make it more user-friendly and efficient. (re @DiogoConstantino: also it would be cool if the qa website got some attention from the web team, and some flavours made it easier for those that use the qa website to report bugs on the write place)
 Too bad i couldn't help testing this time around and hope i can around the time we get closer to the final release of 21.04.
 stumbled on this yesterday and see that we thought of nearly an identical logo for the group :
 hopefully the announcement will be even bigger next time, so more people, podcasts and news outlets get notice of it earlier. (re @DiogoConstantino: The only thing I want is to start preparing earlier next time)
 the great thing about daily builds is that testing happens year round :D (re @Maik_aD: Too bad i couldn't help testing this time around and hope i can around the time we get closer to the final release of 21.04.)
 Ha! True.
 Exactly! Every day can be Testing Day. :)
 Boy is that true..
 Except for the few days after a release when there are no dailies :D
 This was my first time.  I hope to be included in giving feedback.  My plan is to be more involved in testing and in bug reporting from now going forward.
 \o/ That’s great news :) (re @rwkeating: This was my first time.  I hope to be included in giving feedback.  My plan is to be more involved in testing and in bug reporting from now going forward.)
 Installer says screenreader included but system-settings says otherwise! :
 welcome to the party (re @rwkeating: This was my first time.  I hope to be included in giving feedback.  My plan is to be more involved in testing and in bug reporting from now going forward.)
 think the installer screenshot needs updating. has kubuntu also shifted to calamares? (re @saivinob: )
 I don’t think so but Rik would know for sure (re @philipz: think the installer screenshot needs updating. has kubuntu also shifted to calamares?)
 No, we have not
 oh my bad.
 At the moment I am more concerned on fixing the crash that happens when you try to enable a wifi connection from withing the KDE installer front end
 At the moment I am more concerned on fixing the crash that happens when you try to enable a wifi connection from within the KDE installer front end (edited)
 If anyone use qbittorent, then please check the version in hirsute is ok
 It got removed from hirsute and debian as a library it depended on had copyright issues. That is now fixed, and I re-uploaded to Ubuntu earlier. Would be nice to know the build works ok
 may be a few hrs before it is available


[02:08] <alindeman> Expect more attacks
[02:08] <alindeman> I'm trying to quell them before they make it to channels
[02:08] <nalioth> lovely
[02:09] <jdong> is it party time?
[02:11] <nalioth> clone swarms now trumpeting potter details
[02:11] <nalioth> or not, but still being troublesome
[02:12] <mc44> jrib: see Grigory's last part message too
[02:13] <jdong> GRR WTF
[02:13] <jdong> someone posted a sudo worm on UbuntuForums.org
[02:13] <jdong> GRR
[02:13] <jrib> mc44: how nice
[02:14] <mc44> jdong: a worm!? on leenux?!
[02:14] <jdong> mc44: sudo phish
[02:14] <nalioth> mc44: it's not funny
[02:15] <mc44> nalioth: i've just never seen one before
[02:15] <nalioth> mc44: it's called "social engineering"
[02:15] <mc44> ooh
[02:15] <mc44> that kind
[02:15] <nalioth> mc44: it's not a linux worm, it's a user psychology worm
[02:16] <jdong> yeah, phishing worm...
[02:20] <jdong> ah, ok, jailed and user PM'ed...
[02:20] <jdong> back to dinner
[02:32] <jdong> does ircnick "derekson_" ring a bell with anyone?
[02:32] <nalioth> nope
[02:33] <jdong> interesting
[02:33] <jdong> mmkay I'll play with him for a bit longer then
[02:37] <jdong> wtf little bugger is !ops-ing for someone to kick him....
[02:37] <jdong> meh if hey says so...
[02:47] <Tm_P> hu?
[12:10] <effie_jayx> The IRC council reserves the right to remove idlers from the channel <--- cool :D
[12:11] <effie_jayx> that last line makes me not "idle"
[12:11] <effie_jayx> :D
[12:11] <PriceChild> hehe wonder what brought about that line *looks at logs*
[12:23] <jenda> effie_jayx: you've been idle for over 5 minutes...
[12:23] <jenda> you're exposing yourself to grave dangers :)
[12:23] <effie_jayx> no no no please nooo
[12:24] <effie_jayx> jenda,  besides LongPointyStick  is sleeping...
[12:26] <jenda> :)
[12:33] <elkbuntu> actually, LongPointyStick is at work
[12:34] <effie_jayx> well that's better :D
[12:35] <effie_jayx> I just hope I don't get a delayed DOOM (tm)
[12:35] <PriceChild> LongPointyStick, never sleeps
[12:44] <stefg> some user kos is trolling in #ubuntu, asking for Suse-cd's .  :P
[01:25] <jenda> But it's a no-good job anyway ;)
[01:25] <jenda> hehe
[01:25] <PriceChild> I'm sure i'll find something
[01:25] <PriceChild> I've got lots lined up for this time next year....
[01:26] <elkbuntu> someone needs to give me a damn job too
[01:26] <PriceChild> elkbuntu, give me the job of finding you a job
[01:26] <PriceChild> we all end up happy?
[01:26] <elkbuntu> ok. it pays $0.
[01:26] <PriceChild> is travel included thoguh?
[01:27] <elkbuntu> unfortunately no.
[01:49] <PriceChild> Hey harrisony, can I help?
[03:35] <stefg> spammer IxBrad[AFK]  needs a ban
[03:36] <Hobbsee> done
[03:51] <GazzaK> mc44 needs a ban too
[06:21] <PriceChild> MikeRotch just joined #ubuntu :s
[06:25] <jenda> PriceChild: hahah :)
[07:19] <PriceChild> *is talking to metbsd...*
[07:22] <Jordan_U> Troll in #Ubuntu
[07:23] <elkbuntu> Jordan_U, already dealt with
[07:23] <Jordan_U> Yup, saw that, thank you
[07:23] <elkbuntu> Jordan_U, if you see an op talking while there's a troll around, there's no need to divert our attnetions to here
[08:43] <jenda> tsmithe!
[08:43] <tsmithe> aha jenda
[08:43] <jenda> oops, wrong channel, let's move to #ubuntuforums :)
[08:43] <GazzaK> jenda,
[08:49] <jenda>
[10:33] <jdong> guys ubunut is back
[10:33] <jdong> llook in -motu
[10:33] <jdong> !ftp factoid...
[10:35] <PriceChild> grr
[10:36] <jdong> can't we block the last octet of him?
[10:36] <jdong> I doubt he can switch his octect that quickly
[10:37] <PriceChild> Hobbsee's the only one online in the channel and she's asleep...
[10:37] <PriceChild> oh wait she has no access anyway
[10:38] <PriceChild> jdong, poke jenda :)
[10:38] <jdong> jenda jenda jenda!
[10:38] <jdong> lol
[10:38] <GazzaK> can I poke him?
[10:39] <jdong> GazzaK: not in the backports though
[10:39] <GazzaK> lol
[10:40] <jdong> haha
[10:40] <jdong> that's futile unless you block <IP_ADDRESS>/8 :D
[10:47] <jenda> hmm?
[10:47] <jenda> jdong, PriceChild
[10:47] <jdong> jenda: block ubunut by any means necessary
[10:48] <jdong> 16:33 < jdong> !ftp
[10:48] <jdong> 16:33 < ubunut> ftp://meklort.isa-geek.com user:star + pass:star
[10:48] <jdong> 16:33 < ubotu> FTP clients: !Nautilus, !gFTP (for !GNOME) - !Konqueror,  !Kasablanca, !KFTPGrabber (for !KDE) - See also !FTPd
[10:48] <jdong> 16:33 < jdong> the fsck...
[10:48] <jenda> what's he doing?
[10:48] <jdong> it's the same spambot from yesterday
[10:48] <jenda> oh
[10:48] <jenda> ok
[10:48] <jdong> also goes by geem
[10:49] <PriceChild> jdong, he's not a bot
[10:49] <jdong> PriceChild: he's not much of a human either
[10:49] <jdong> PriceChild: he responds to !ftp instantly...
[10:49] <jdong> identically each time
[10:50] <jdong> so at least it's a human-bot android hybrid
[10:50] <PriceChild> he has a script loaded in his client
[10:51] <jenda> I believe it's called a cyborg ;)
[10:51] <nalioth> has he/it spoken in -motu, jdong PriceChild ?
[10:51] <jdong> 15:52 < geem> those bastards
[10:51] <jdong> something like that :)
[10:52] <nalioth> has he/it talked in the last few minutes?
[10:52] <PriceChild> nalioth, jdong's !ftp triggered it. He was around yesterday, went into +1 after it was mentioned here, trolled, then didn't take it too well when we wouldn't unban immediately from #ubuntu after that.
[10:52] <nalioth> right
[10:52] <GazzaK> send him to me, i'll sort him out
[10:52] <jdong> GazzaK: he's not into backports either.
[10:53] <GazzaK> meh
[10:53] <nalioth> GazzaK: i can show you where he went

[10:53] <PriceChild> jdong, !
[10:54] <jdong> I love you too :)
[10:54] <nalioth> y'all let me know if ubunut comes back
[10:54] <jdong> ure thing
[11:28] <PriceChild> Anyone around wanting to help suggest what to add to the irc operator guidelines? (Re: message on ubuntu-irc list)
[11:30] <nalioth> i think the guidelines are fine
[11:30] <PriceChild> I know, and so do I... but the CC are not going to budge on this.
[11:30] <nalioth> i think that harsher penalties need to be asessed on 'those who take things into their own hands'
[11:30] <nalioth> adding stuff like they want to the above, belittles those of us with sense
[11:31] <PriceChild> I think the reason the guidelines didn't work/go into effect last time because there was no governance structure, not because they were defective.
[11:34] <PriceChild> I tried summing up the existing guidelines, including operator & coc, quoting to explain how they should ward against "nasty" behaviour but they're not having it... they need something in these guidelines to be happy and give a +1
[11:35] <nalioth> i don't think what they're wanting belongs on the guidelines
[11:35] <nalioth> because it is already there
[11:35] <PriceChild> That's my opinion too.
[11:36] <PriceChild> With all due respect, these point all refer to existing guidelines.
[11:36] <PriceChild> The only reason we're having this discussion is because a previous
[11:36] <PriceChild> incident involving Ubuntu IRCops has demonstrated that the existing
[11:36] <PriceChild> guidelines, de facto, are not sufficient.
[11:36] <PriceChild> - james troup
[11:37] <nalioth> is he ever on irc, PriceChild ?
[11:37] <PriceChild> elmo
[11:37] <PriceChild> lots
[11:37] <PriceChild> he's away atm
[11:37] <PriceChild> mark then seconded the reply an hour later
[11:37] <nalioth> perhaps we should have a discussion with him
[11:38] <PriceChild> I suppose that could be a lot more productive than me trying to sum up all our thoughts in slow emails
[11:39] <PriceChild> writing these emails i've been very anxious, hoping that I am putting across what "we" think.
[11:40] <PriceChild> (anyone else around with thoughts?)
[11:40] <mc44> you could put "Dont do anything Seveas wouldn't" in the guidelines, but that probably wouldn't help :D
[11:41] <PriceChild> (anyone else around [minus mc44]  with thoughts?)
[11:41] <mc44> :P
[11:44] <PriceChild> I should have started poking whilst elkbuntu was still awake, will keep poking tomorrow morning over thoughts, and where's Ljl been :S
[11:44] <harrisony> morning all, anything real interesting i missed last night? any killer bots attack, ##windows was flodded last night. Any of that carry over here
[11:44] <PriceChild> nalioth, Do you want me to try to get hold of elmo and sort out a little meeting for us to discuss then?
[11:45] <PriceChild> (us being whoever's interested in participating)
[12:22] <nalioth> PriceChild: if you like
[12:23] <nalioth> poke seveas
[12:23] <PriceChild> hmmm i must've missed him signing off
[12:23] <PriceChild> is he back for good or was that just another quick hi?
[12:24] <PriceChild> I think I remember him saying he was flying off somewhere... anyway will poke elmo


[11:44] <PatrickDickey> Just wanted to pop in and say hi. And to let you know, that if you're in the #ubuntu channel, and type !manual the bot gives a link to our manual. :D
[11:49] <CarstenG> Hi Patrick
[11:49] <CarstenG> Nice to see you :-)
[11:49] <CarstenG> !manual
[12:02] <PatrickDickey> Nice to see you too CarstenG.
[12:02] <PatrickDickey> Any word on when we'll be starting the Raring manual, or are we going to wait for the next LTS?
[12:03] <CarstenG> We will do a version for raring.
[12:03] <CarstenG> But I don't know when we start
[12:04] <CarstenG> I think Kevin will organize a meeting for it.
[12:05] <CarstenG> The raring branch is already started and can be used.
[12:07] <CarstenG> The next LTS will be 14.04, or?
[12:25] <CarstenG> Hi Sylvie
[12:35] <cqfd93> Hi Carsten!
[13:26] <PatrickDickey> I'll have to install it on my laptop.