[02:18] <mup> PR snapd#5659 opened: tests: remove manual from openvswitch test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5659>
[05:56] <mup> PR snapd#5601 closed: seccomp: conditionally add socketcall() based on system and base <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5601>
[05:57] <mup> PR snapd#5633 closed: seccomp: conditionally add socketcall() based on system and base - 2.35 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5633>
[07:15] <palasso> Hello, I'm wondering why there's multiple "core" snaps (core, core16, core18) instead of one core snap with tracks
[07:27] <mvo> palasso: its mostly because we need to install core18 and core in parallel. i.e. you can have a ubuntu core 16 device and install snaps that require core18. otherwise it would be nice and elegant to just use tracks
[07:28] <palasso> mvo: Thank you for the response. I didn't know it's not possible to install different versions from tracks in parallel. Is there a reason it's not possible?
[07:29] <mvo> palasso: its not implmented yet, we will support this in RSN
[07:29] <palasso> Ah that's good news
[07:29] <mvo> palasso: https://github.com/snapcore/snapd/pull/5596
[07:29] <mup> PR #5596: (WIP) parallel installs integration <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>
[07:29] <palasso> After it's implemented could this mean that the "core" snaps would utilize tracks?
[07:29] <mvo> palasso: this is the PR that tracks the work, I would estimate ~3-4 weeks until its available in some beta
[07:30] <palasso> mvo: tyvm for your response :)
[07:30] <mvo> palasso: this will also allow stuff like "snap install go_1.6 --channel=1.6"
[07:31] <mvo> palasso: which I personally look forward to :)
[07:31] <palasso> So then  instead of a go_1.6 it'd be go? and it'd be snap install go --channel=1.6?
[07:32] <palasso> Actually there's already a "go" with tracks as such
[07:34] <mvo> palasso: it would be go_1.6 and I could have go_1.10 at the same time installed
[07:34] <mvo> palasso: or the same snap (database_test, database_prod) even
[07:34] <mvo> palasso: its a cool feature
[08:31] <pedronis> mvo: I answered one of your comments on pawel PR
[08:39]  * pedronis reboot
[09:09] <mvo> pedronis: thank you!
[09:14] <mvo> pedronis: hm, I don't see the reply, is GH slow or is it somehow pending?
[09:18] <pedronis> mvo: it's there, but some comments are collapsed, or you mean you didn't get an email?  anyway https://github.com/snapcore/snapd/pull/4767#discussion_r210202153
[09:18] <mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
[09:19] <mvo> pedronis: oh, ok
[09:19] <mvo> pedronis: yeah, I missed this one - thanks for pointing this out
[09:20] <pedronis> mvo: anyway I still hope long term we will not need these functions/checks
[09:20] <pedronis> well medium term
[09:20] <mvo> pedronis: right - that would be neat
[09:20] <pedronis> hopefully
[09:21] <mvo> pedronis: do you have an opinion about https://github.com/snapcore/snapd/pull/5618#discussion_r210186520 btw?
[09:21] <mup> PR #5618: overlord: instantiate UDevMonitor <Created by stolowski> <https://github.com/snapcore/snapd/pull/5618>
[09:21]  * mvo hugs Chipaca for his wise word on 5656
[09:22] <Chipaca> mvo: I blame you for making me be aware of that quote
[09:25] <pedronis> mvo: it sorts of feel like it would be nice if the monitor was embedded in a manager
[09:26] <pedronis> that woudln't solve exactly the problem you mention though
[09:29] <mvo> pedronis: oh, thats an interessting idea, could it become its own manager?
[09:30] <mvo> pedronis: and we pass ifmanager into it or something
[09:30] <pedronis> maybe but it doesn't help avoiding the mocking
[09:30] <pedronis> for places that really use the full overlord
[09:30] <pedronis> which seems your worry
[09:30] <pedronis> but it avoids some ad hoc code
[09:31] <pedronis> otoh afaik that code started that way
[09:31] <mvo> pedronis: oh, ok
[09:31] <mvo> pedronis: and gustavo was in favor of moving it?
[09:31] <pedronis> and then it came to this
[09:31] <pedronis> I don't remember
[09:31] <mvo> pedronis: "there is nothing new under the sun" :)
[09:31] <pedronis> I think one issue is that managers have Stop
[09:31] <pedronis> but not Start
[09:31] <pedronis> but in the new world where some of this thing are optional
[09:31] <mvo> pedronis: indeed
[09:31] <pedronis> it would be possible to add that
[09:32] <pedronis> without needing to touch everything
[09:32]  * mvo nods
[09:32] <mvo> pedronis: I can play around a bit, but yeah, my concern is that we need to mock a lot of place now and it looks like we did not even caught all the places yet
[09:35] <mvo> pedronis: anyway, I will create a PR based on pawels with my idea and see what it looks like - if its bogus I will just discard
[09:36] <pedronis> mvo: ok
[09:36] <pedronis> mvo: btw  I commented on your seed sorting PR, I fear we need to do the thing at first boot (as well)
[09:42] <mvo> pedronis: yeah, I saw it, also your comment about proper topsort, makes me wonder if I should just close it and we go all the way or if its still worth having as an intermediate step
[09:57] <pedronis> mvo: I don't think the intermediate step is useful as is, as I said it doesn't fix the actually reported case
[09:57] <mvo> pedronis: yeah, good point.
[09:59] <pedronis> mvo: I have mixed feelings about the all thing to be honest, our waiting for content providers is a bit for strange reasons, auto connect itself is symmetrical
[10:01] <pedronis> mvo: the problematic code is here:  https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L591
[10:03] <pedronis> mvo: in theory we could also fix the default-provider problem there, with code like the one pawel had at some point, then the sorting would only need to be about bases which is simpler
[10:03] <pedronis> and at some point we probably could remove most of the special code there
[10:04] <pedronis> mvo: we can have chat about this if you want at some point
[10:04] <ogra> mvo, thanks for the answer in the model assertions thread, i added a comment and will stay quiet on the topic now :)
[10:08] <pedronis> mvo: let me know
[10:12] <mvo> pedronis: talking about this sounds great, I am still playing with the overlord/udevmon but maybe this afternoon?
[10:12] <mvo> ogra: thanks
[10:16] <pedronis> mvo: ok
[10:16] <pedronis> mvo: anyway this afternoon or tomorrow might be better for me, I have other things to look into
[10:16] <pedronis> as well
[10:17] <pedronis> mvo: tomorrow is probably better tbh
[10:23] <mvo> pedronis: ok, then tomorrow it is
[10:24] <sparkiegeek> hmm, the email gateway for forum.snapcraft.io appears to be broken? is that known?
[10:25] <sparkiegeek> https://paste.ubuntu.com/p/vNpx2n3znq/
[10:25] <sparkiegeek> when replying to a notification
[10:53] <mup> PR snapd#5611 closed: devicestate: only run device-hook when fully seeded <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5611>
[11:01] <Chipaca> sparkiegeek: I don't think that's known
[11:01] <Chipaca> sparkiegeek: in fact it worked, before
[11:02] <sparkiegeek> Chipaca: ok, I wasn't sure because I never used it before. Have only tried it recently (i.e. post the move of owners) and both times it broke,
[11:04] <Chipaca> sparkiegeek: are you  going to go pester the new owners now?
[11:05] <Chipaca> :-)
[11:05] <sparkiegeek> Chipaca: I could do :) would be nice if I could get confirmation that it's not Just Me™ for which it fails
[11:05] <sparkiegeek> *whom
[11:06] <Chipaca> sparkiegeek: this is when replying to an email notification?
[11:06] <sparkiegeek> Chipaca: correct
[11:10] <ogra> mvo, so how do we tackle that auto-update issue with edge where snapd hangs on shutdown
[11:11] <ogra> (what should i capture next time it happens ... sadly it is only reproducable when auto-updating so hard to tell in advance when it happens)
[11:11] <mvo> ogra: do you have any logs? that is a "normal" uc16 system?
[11:11] <mvo> ogra: oh, only auto-update - thats interessting
[11:11] <mvo> ogra: and annoying of course :/
[11:17] <Saviq> hey all, is it on purpose that core18 does not have /etc/ssl/certs ?
[11:18] <ogra> mvo, no logs yet since i always only notice it when the system is already rebooting ...
[11:19] <ogra> mvo, and yes, core 16 edge in qemu
[11:19] <ogra> i can set up my VMs to captuer stuff constantly, i just need to know what ;)
[11:20] <Chipaca> sparkiegeek: confirmed, i got the same posting error email (well, not the *same* one, but)
[11:20] <Chipaca> sparkiegeek: [snapcraft.io] Email issue -- Posting error
[11:21] <sparkiegeek> Chipaca: mine was titled 'Unknown To: Address'
[11:21] <Chipaca> oh wait
[11:21] <Chipaca> sparkiegeek: this might actually mean my email worked
[11:21] <Chipaca> sparkiegeek: if I actually _read_ the email, it says the body was too short
[11:22] <sparkiegeek> Chipaca: ah..
[11:22] <mvo> ogra: the journalctl output when it shuts down would be great
[11:22] <Chipaca> sparkiegeek: I'll try again :-)
[11:22] <sparkiegeek> Chipaca: thanks, I'll prepare the aforementioned pester but hold off on sending
[11:25] <ogra> mvo, ok, i'll simply enable persistent journald by default in my VMs ... lets see what i can get there
[11:25] <ogra> will ping once i have something
[11:25] <Chipaca> sparkiegeek: https://forum.snapcraft.io/t/error-cannot-install-hello-world-post/6849/7?u=chipaca
[11:25] <sparkiegeek> Chipaca: ho hum
[11:26] <mvo> ogra: thank you
[11:26] <pedronis> ogra: what do you mean with hangs on shutdown?
[11:26] <pedronis> it's designed to wait on shutdown
[11:27] <ogra> pedronis, i get a systemd unit timeout (the typical 1:30 thingie with countdown in red)
[11:27] <ogra> i dont get that in normal reboots, only when there was an auto-upgrade and the system reboots out of the blue
[11:28] <pedronis> mvo: did we add watchdog stuff? does it interfere with the way we do shutdowns?
[11:29] <ogra> (note that i'm working with kiosk stuff, so i'm usually not logged in on console when that happens to see the shutdown warning)
[11:29] <pedronis> anyway logs  or  sending a SIGQUIT to the "hanging" snapd and logs would be useful
[11:31] <pedronis> I see we added watchdog stuff in main.go, otoh the reboot sleep should be 1m
[11:31] <pedronis> not 1:30
[11:31] <ogra> yeah, logs are fine ... i cant sent any signals when not logged in via ssh though
[11:32] <ogra> the 1:30 is a systemd thing it adds when a process doesnt respond ... so perhaps thats even expected behaviour in the end
[11:32] <ogra> (the red in the shutdown just caught my attention, and i dont see it on normal reboots)
[11:33] <pedronis> ogra: well we stop the main loop and close sockets but setup a 1m  shutdown and sleep for 10 minutes
[11:33] <pedronis> but now we have watchdog stuff
[11:33] <pedronis> that might get upset about that
[11:34] <pedronis> or we might hang before that (that would be a more serious issue)
[11:34] <pedronis> anyway the log should tell us that
[11:34] <pedronis> ogra: if the logs contains "Waiting for system reboot"   is just  some annoying behavior (we should still fix), if they don't it might be a more serious issue
[11:38] <ogra> we'll see ... i have a VM set up with persistent logging now and will leave it idling in bg until it auto-reboots
[11:38] <Chipaca> ogra: persistent logging and SNAPD_DEBUG?
[11:39] <Chipaca> ogra: https://forum.snapcraft.io/t/extremely-slow-snap-downloads/4668/2?u=chipaca
[11:39] <ogra> Chipaca, ah, not yet, do i set that in the systemd unit or is /etc</environment enough ?
[11:39] <Saviq> mvo: hey, where can I find / file bugs for the core18 snap?
[11:40] <pedronis> Chipaca: Waiting for system reboot is a Noticef
[11:40] <Chipaca> ogra: if you don't mind seeing a lot of debug even from 'snap', setting SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 in /etc/environment would work also
[11:41] <ogra> yeah, thats fine, i'll leave the VM idle anyway so there shouldnt be anything from snap commands
[11:46] <Chipaca> pedronis: a'ight (but debug would tell us more, presumably)
[11:48] <pedronis> Chipaca: yes
[11:48] <pedronis> espcially if it's not there
[11:49] <pedronis> though in the worst case not a lot,  then we would need to dump goroutines ideally
[11:49] <ogra> Chipaca, another thing ... https://forum.snapcraft.io/t/snapd-is-now-doing-a-little-sanity-check-on-install/3566 ... could the technology behind this that rolls back or removes the snaps be hooked into install hooks somehow ? (tony will ask you about this later today i guess)
[11:49] <ogra> so one could test for certain conditions via the install hook that prevent a snap to be installed at all on a system
[11:50] <Chipaca> ogra: can't the install hook fail and abort the installation?
[11:51] <ogra> Chipaca, that seems to not work as tony expects it ... i'll leave the core of the request to him, just wanted to trigger your brain to think about it ;)
[11:51] <ogra> i just remembered that feature and was thinking that code is already there and could perhaps be wired up differently
[11:54] <Chipaca> ogra: "exit 1" in the install hook causes the installation to abort
[11:54] <Chipaca> just tried it
[11:58] <Chipaca> ogra: I'll wait for tony before thinking much more about this :-)
[12:02] <ogra> heh, ok
[12:06] <ogra> diddledan, !!!! tvheadend !!!!
[12:07] <ogra> (/me work on https://snapcraft.io/vdr-kiosk (still not done yet though, but i got it building with vc libs for the pi)
[12:13] <ogra> diddledan, do you include oscam in the snap ?
[12:28] <pedronis> mvo: should we close 5612 for now?
[12:33] <mvo> pedronis: yeah, lets do that
[12:34] <mvo> pedronis: fwiw, thiw bug hit CE, they added "core" but it was sorted too late
[12:34] <mvo> pedronis: this happend while you were on vac
[12:34] <mup> PR snapd#5612 closed: [RFC] image: do simple seed.yaml snap sorting <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5612>
[12:34] <mvo> pedronis: this is why we added the following special case https://github.com/snapcore/snapd/pull/5610
[12:34] <mup> PR #5610: image: ensure "core" is ordered early if base: and core is used <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5610>
[12:34] <pedronis> mvo: as I said I think we need to fix for bases like this, I don't think we want to fix it like this for content providers, anyway we can chat tomorrow
[12:35] <pedronis> but the fix needs to start in first boot code
[12:35] <mvo> pedronis: yeah, lets talk tomorrow
[12:35] <mvo> pedronis: ok
[12:38] <pedronis> mvo: sorry, I just want to make sure we do something consistent and possibly simple (and also easy to remove if some bit is not needed anymore)
[12:39] <mvo> pedronis: all good, we are in agreement :)
[12:41]  * mvo dives back into understanding why autopkgtest on cosmic fails
[13:25] <mup> PR snapcraft#2213 closed: Revert "ci: disable osx tests until a new pyyaml is released" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2213>
[14:02] <om26er> sitter: ping ?
[14:05] <diddledan> ogra: I've not got oscam in there yet
[14:16] <mup> PR snapcraft#2215 opened: provider changes <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2215>
[14:24] <Voziv> Hi all, I'm getting "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks" whenever I try tro run htop, slack, spotify, or PHPStorm snaps. This started happening after a reboot
[14:24] <mup> PR snapd#5656 closed: debian: add missing breaks on cosmic <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5656>
[14:25] <Voziv> I'm running on Ubuntu 18.04.1 and I noticed that my apparmor profiles lists "docker-default (enforce)", not sure if this is related
[14:32] <mup> PR snapd#5660 opened: wayland: add extra sockets that are used by older toolkits (e.g. gtk3) <Created by gerboland> <https://github.com/snapcore/snapd/pull/5660>
[14:43] <om26er> can I make a snap read/write for debugging ?
[14:46] <diddledan> om26er: only if you keep the build locally, use `snap try` instead of `snap install foo_amd64.snap`
[14:50] <mvo> ogra: did you say the pi2 dtbs from the bionic kernel are backward compatible. do I remember this right? so we could update the pi gadget with the latest dtbs without the world falling appart?
[14:51] <mvo> ogra: or do I misremember that?
[15:02] <Voziv> If I run "snap run slack" from my command line I also get "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks"
[15:05] <pedronis> mvo: did we have a fix for this ^ ?  or it needs z-yga ?
[15:09] <mvo> pedronis: its a precaution - Voziv where do you see this error? what distro are you using and what does "snap version" output?
[15:10] <mvo> niemeyer: it looks like I don't have repo access to "github.com/cm3-gadget" could you please add me so that I can write there?
[15:10] <niemeyer> mvo: On it
[15:10] <mvo> niemeyer: thank you
[15:10] <Voziv> I see it after a reboot when trying to launch slack, phpstorm, or spotify. They simply don't launch. I see the error message when I either run it from the CLI (snap run slack), or in my syslog. I'm on Ubuntu 18.04.1
[15:11] <Voziv> my snap version is 2.34.3 series 16, kernel 4.15.0-32-generic
[15:11] <Voziv> I just did a "sudo systemctl restart apparmor" and now slack has launched successfully. Going to reboot my machine and see what happens again
[15:11] <niemeyer> mvo: Done, hopefully
[15:12] <mvo> niemeyer: \o/ works. thank you
[15:13] <niemeyer> np, not sure why we have a separate team for those gadgets.. we should probably unify at some point
[15:13] <mvo> niemeyer: +1
[15:14] <ogra> mvo, i think you mis-remember ... i dont think 4.4 will bot with 4.15 dtb's
[15:14] <ogra> *boot
[15:14] <mvo> ogra: ok, thats fine as well
[15:14] <mvo> ogra: a bit sad
[15:14] <mvo> ogra: but fine
[15:15] <ogra> mvo, well, try it .. but generally dtb's are not compatible between main version bumps (we had that issue initially when switching from 4.2 to 4.4 already ...) though the most reliable source here is indeed paolo (who isnt around)
[15:16] <ogra> mvo, also the cm3-gadget source is at https://github.com/snapcore/cm3-gadget
[15:17] <ogra> not sure what github.com/cm3-gadget is but surely not what we used
[15:17] <jdstrand> Voziv: it sounds like the snap-confine profile didn't get loaded. there are forum topics on this and this is also something zyga has looked at
[15:18] <ogra> niemeyer, ^^^ (teh gadget sources should all be owned by snapcore)
[15:18] <Voziv> mvo, jdstrand: Post reboot results: https://gist.github.com/Voziv/9e9db4bd952f61b73f11267cd160627e
[15:18] <niemeyer> There's no "snapcore" team
[15:19] <ogra> oh, i thought the subdir there translates to a team ... LP spoiled me :P
[15:19] <Voziv> I have no clue why restarting the app armor results in a different set of profiles being loaded
[15:19] <Voziv> jdstrand: I did find several threads, but nothing really helped out with solving the problem, I kept getting the error, though now I have a reproducable way to get them working
[15:19] <Voziv> I'll make a forum post with the gist results
[15:20] <jdstrand> Voziv: so, that gist indicates that the apparmor unit isn't running on your system. docker will load its own profile, which is why it is showing up
[15:23] <jdstrand> Voziv: you might look at 'sudo systemctl status apparmor' and 'sudo journalctl --unit=apparmor.service' after a reboot
[15:23] <jdstrand> Voziv: otherwise look at journalctl for clues
[15:24] <Voziv> hmm, you're right. It's disabled
[15:26] <Chipaca> jdstrand: o/
[15:27] <jdstrand> Chipaca: hey
[15:28] <Chipaca> jdstrand: I'm not sure if you read about the hostname-control issue in 18.04
[15:28] <Chipaca> jdstrand: I added what info I had to the PR that's failing
[15:28] <mup> PR snapd#5661 opened: tests: normalize tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5661>
[15:28] <Chipaca> jdstrand: that's #5593
[15:28] <mup> PR #5593: tests: new test for hostname-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593>
[15:29] <jdstrand> Chipaca: I saw you mentioned it yesterday and took a note to look at it (wanted to yesterday)
[15:29] <Chipaca> jdstrand: ah ok
[15:29] <Chipaca> jdstrand: that's all i ask :-)
[15:33] <jdstrand> Chipaca: it is one of just a handful of things I need to look at before I get back to pedronis. really hoping for today Samuele! :)
[15:34] <mvo> ogra: do you happen to know if the dragonboard also need firmware upgrades to work with the 4.15 kernels?
[15:35] <ogra> mvo, i dont think so ... the dragonboard FW should be independent from the kernel
[15:35] <mvo> ogra: excellent
[15:36] <ogra> mvo, the pi FW is fully backwards compatible though (unlike the dtbs that must come from the kernel deb)
[15:36] <mvo> ogra: what about the dtbs from the dragonboard? does it need one? does that needs updating?
[15:36] <ogra> so just make sure your git pull is new enough for that
[15:37] <ogra> mvo, dtbs on dragonboard are coming from the kernel snap
[15:37] <ogra> only the pi ships them in gadget
[15:37] <ogra> (and it is the only system that does that to my knowledge)
[15:38] <ogra> (due to the fact that the binary blob needs to read them from vfat directly)
[15:38] <mvo> ogra: great
[15:39] <mvo> ogra: so no issues there hopefully
[15:40] <ogra> yeah, only pi is painful
[15:48] <ogra> mvo, hmm, any reason why you grep for linux-modules instead of linux-image in your change ?
[15:48] <mvo> ogra: yeah, the dtbs moved
[15:48] <ogra> rae the dtb's in bionic not shipped in linux-image anymore ?
[15:48] <ogra> urg
[15:48] <diddledan> this is a fun one https://github.com/canonical-websites/snapcraft.io/issues/1021
[15:49] <ogra> so if i would install without using modules i wouldnt get a bootable install ?
[15:49] <ogra> thats a weird decision
[15:49] <ogra> but well :)
[15:51] <mvo> ogra: I have no insight in this, but when I tried to build the snap I noticed it (that was a couple of days ago when I updated the universal pi snap)
[15:53] <ogra> mvo, yeah, will only harm people that create their rootfs manually .... it just feels weird that you can install linux-image (the kernel) without -modules and then end up without any dtbs
[15:54] <ogra> mvo, looked over all pi gadget changes and approved them ...not sure if you want to wait for additional ondra approval too
[15:54] <ogra> they look all fine to me
[16:01] <pedronis> jdstrand: was about to ping actually :)
[16:02]  * jdstrand nods
[16:07] <mvo> ogra: I need to wait for the channel creation on the store side anyway
[16:07] <mvo> ogra: so no problem
[16:08] <ogra> well, the have ondra take a look too, 4 eyes etc ;)
[16:08] <ogra> *then
[16:10]  * cachio lunch
[16:23] <Chipaca> mvo: question about core in the beta channel: does 5275 (from 17:51z today) include the proxy+vault fix?
[16:24] <Chipaca> oh wait no
[16:24] <Chipaca> it's from 17:51z yesterday
[16:24] <Chipaca> so, no it doesn't
[16:24] <Chipaca> kthx
[16:24] <diddledan> glad I could help, Chipaca
[16:25] <Chipaca> diddledan: I'm just happy to be in such capable hands
[16:25] <diddledan> :-D
[16:35] <mup> PR snapd#5662 opened: tests: avoid using the journalctl cursor when it has not been created yet <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5662>
[16:42]  * Chipaca going afk for a while
[16:42] <Chipaca> cachio: does 5662 mean you found the problem with the cursors?
[16:42] <Chipaca> haven't looked yet, will look when i get back
[16:42] <Chipaca> but, woo
[16:47] <cachio> Chipaca, it is a problem
[16:48] <cachio> Chipaca, it is not "the problem"
[16:48] <cachio> I am still researching a problem with some info not found in the journal
[17:43] <mup> PR snapcraft#2216 opened: spread tests: keep sources local <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2216>
[17:52] <cachio> Chipaca, are you looking this test which is failing? TestFullDeviceRegistrationHappyWithHookAndNewProxy
[17:55] <cachio> mvo, do you?
[17:58] <pedronis> cachio: where? on master?
[17:58] <cachio> yes
[17:58] <cachio> pedronis, https://api.travis-ci.org/v3/job/416382933/log.txt
[18:01] <pedronis> yes, this is from a recent branch from Chipaca
[18:02] <pedronis> it might just be a combination with the change mvo did
[18:02] <pedronis> on a different branch
[18:03] <cachio> pedronis, yes, all the branches are failing now because of this test
[18:06] <pedronis> yea
[18:06] <pedronis> I see
[18:06] <pedronis> it's mvo code vs Chipaca tests
[18:07] <pedronis> fix is easy
[18:07] <pedronis> one sec
[18:08] <cachio> pedronis, great, thanks
[18:11] <mup> PR snapd#5663 opened: overlord/devicestate: fix tests, set seeded in registration through proxy tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/5663>
[18:11] <pedronis> cachio: fix ^
[18:12] <pedronis> I suspect it also needs backporting to 2.35
[18:16] <cachio> pedronis, tx
[18:40] <mvo> Chipaca: do you need a core with the fix? I can build you one
[18:41] <mvo> pedronis: \o/ thanks for the fix
[18:45] <Chipaca> mvo: we already have one AFAIK: edge was built after this landed in master
[18:45] <Chipaca> mvo: unless by 'this fix' you mean 5663 (in which case no, because it's just tests that change)
[18:46] <Chipaca> mvo: if you mean a 2.35 with the fix, I think they just want to be sure that 2.35 includes it, not that they need it for testing at this time
[18:46] <Chipaca> cachio: I wasn't because I wasn't here :-)
[18:47] <Chipaca> and I'm about to not be here again (went for a run, now going to the supermarket)
[18:47] <Chipaca> (dog is hopeful supermarket includes a walk)
[18:47] <Chipaca> (dog is right to be hopeful)
[18:48] <mvo> Chipaca: yeah, was wondeirng if you need a build to test this
[18:48] <mvo> Chipaca: but it sounds like no
[18:48] <mvo> Chipaca: iirc I cherry picked it already into 2.35
[18:48] <Chipaca> mvo: yes, you did
[18:48] <Chipaca> mvo: it's just not built yet
[18:49] <mvo> Chipaca: ok
[18:49] <Chipaca> mvo: the people waiting have been informed as much
[18:49] <mvo> Chipaca: they should just use edge, thats a fine channel anyway :)
[18:49] <Chipaca> yep yep
[18:53] <cachio> niemeyer, hey, some machines in gce are being created on us-west1-b
[18:54] <cachio> niemeyer, ug131404-380926 and aug131603-777502
[18:54] <cachio> created by travis?
[18:54] <cachio> are you aware of this?
[18:56] <cachio> I think are vms of snapcraft
[18:56] <cachio> the problem is that our garbage collection is not gonna clean them
[18:56] <cachio> because of the different zone
[18:58]  * cachio afk
[19:20] <niemeyer> cachio: We don't limit, so people might be firing on other regions.. it doesnt make much sense if it's for Travis though
[19:20] <niemeyer> cachio: We'll need to cover other regions on cleanup either way
[19:48] <Chipaca> oh, fun
[19:48] <Chipaca> mvo: #1787254 in case you weren't aware
[19:49] <mup> Bug #1787254: Possibly demote fwupdate to universe? <fwupdate (Ubuntu):New> <fwupdate-signed (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1787254>
[20:08] <cachio> niemeyer, ok
[20:57] <jdstrand> tyhicks: hey, would you mind taking a look at my comments here: https://github.com/snapcore/snapd/pull/5593#issuecomment-413333946
[20:57] <mup> PR #5593: tests: new test for hostname-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593>
[20:58] <tyhicks> jdstrand: hey - can't right now - getting pulled into a regression fix bug
[20:58] <jdstrand> tyhicks: it has to do with AssumedAppArmorLabel= and dbus activated services
[20:58] <jdstrand> ok
[20:58] <tyhicks> jdstrand: I got the email notification and will look as soon as I can
[20:59] <jdstrand> tyhicks: thanks
[22:28] <Caelum> zyga: hey you're back, I want to help fix the gentoo overlay
[22:29] <Caelum> zyga: I'll help get the opensuse stuff finished too at some point
[22:30] <mup> PR snapd#5664 opened: interfaces: workaround for activated services and newer DBus <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5664>
[23:03] <mup> PR snapcraft#2217 opened: Travis test <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2217>
[23:15] <mup> PR snapcraft#2216 closed: spread tests: keep sources local <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2216>


[08:32] <dholbach> good morning
[12:52] <HakanS> I need some advice about the LoCo Team Contact.
[13:02] <UmmmYeah> hello???
[13:02] <UmmmYeah> Ummm
[13:03] <UmmmYeah> anyone there?
[13:03] <UmmmYeah> I need help.
[13:04] <UmmmYeah> Hehlow?
[13:05] <UmmmYeah> ug
[13:05] <UmmmYeah> ugh*
[15:11] <HakanS> I need some advice about the job for LoCo Team Contact.
[15:16] <YoBoY> HakanS: hi, advice ?
[15:19] <HakanS> YoBoY: Hi. What's in a Team Contact's duties?
[15:22] <YoBoY> he make the link with canonical, the loco council, the other loco teams. He receive the mails, respond to them, forward the global events, the calls (open week, dev week, translation, ...). He fill the demands for the live cds and other stuffs. And perhaps some other things...
[15:24] <HakanS> And if he (or she) doesn´t do anything of that?
[15:25] <HakanS> How to handle that?
[15:26] <YoBoY> hum... ask him to leave the job to someone who have more time to take that in charge ^^"
[15:28] <YoBoY> he can choose or your team can elect someone else after that.
[15:28] <YoBoY> If nothing work, you can bring this case to the loco council
[15:29] <HakanS> YoBoY: First I will call him.
[15:31] <HakanS> One more question. How do you handle off-topic discussions in your irc channel? It feels we have 90 percent off topic discussions in our channel.
[15:34] <YoBoY> well... i'm not really  the right person to answer that, but the French team choose to have the #ubuntu-fr channel for support only, and another channel #ubuntu-fr-offtopic for offtopic discussions. We have also other chans for dedicated purpose (webdev, system administration, events organisation, ...) because the offtopic is also too active ^^"
[15:38] <czajkowski> 0/c
[15:39] <HakanS> YoBoY: Maybe it's a good idea for us to have a offtopic channel.
[15:40] <YoBoY> how many people on your chan ?
[15:45] <HakanS> Just now. 99 (but only 5-10 active).
[15:46] <YoBoY> good, talk to you team, if a majority think the same, ask the ircop the autorisation to create the new offtopic chan
[15:48] <HakanS> YoBoY: OK.
[15:48] <HakanS> Time to go home.


[13:59] <scott-work> astraljava: sorry for not responding yet about the meeting, been traveling and also sick for several days, really starting to feel myself again today finally
[13:59] <scott-work> astraljava: sure, i'll handle the meeting this weekend, also thank you for reminding me ;)
[15:20] <astraljava> scott-work: Good, good. Yeah, I'm travelling myself at that time, and I'm not sure about the connectivity then.
[19:19] <len> scott-work: Quick question about live DVDs.
[19:21] <len> How much memory to they require? If they are able to show people all the software US comes with tat sounds like a lot. US installed on the hard drive takes 4gig (about)
[19:22] <len> I guess I am asking if a live dvd is even doable for a machine with only 1 gig memory (or less)
[19:23] <micahg> 1GB RAM?
[19:26] <charlie-tca> The size of the dvd doesn't matter if the computer has enough memory to run studio
[19:26] <charlie-tca> The entire dvd won't load into memory
[19:42] <len> Ok, It is just that I was thinking about the live cds I have run and our dvd is already more than twice the size at almost 2G.
[19:43] <len> I don't remember for sure but it seems the ram disk was about 500mb. If we add the software as installed on the dvd, what size will the dvd end up?
[19:58] <holstein> len: check out dynebolic, or AVlinux
[19:58] <holstein> those are really similar to the size a live ubuntustudio would be
[19:58] <holstein> the size and performance probably
[20:00] <len> Ok.  I guess to answer my question I should try one on one of these machines. Do you know if they work run off the USB stick?
[20:00] <holstein> len: should... though i have only tried an earlier version of AV from usb using unet
[20:01] <holstein> no reason why they shouldnt, though i wouldnt expect hybrid iso's
[20:01] <holstein> unless that is stated...
[20:01] <len> which is the better to try? In your opinion...
[20:01] <holstein> AV
[20:02] <holstein> thought the newest dynebolic is arguably more similar to US
[20:02] <holstein> the early db is quite amzing live
[20:02] <holstein> very out of date though
[20:03] <len> Seems everything is... just by looking at it.
[20:03] <len> That didn't come out right
[20:03] <len>  It seems by the time I see anything it is out of date
[20:04] <holstein> hehe
[20:04] <holstein> i hear you... i just try and hop in the water somewhere and go along for the ride
[20:05] <len> I am finding out my MB is over 10yrs old... at least the internal sound is that outdted
[20:09] <len> Pre 2004 anyway
[20:09] <holstein> len: eh.. internal cards dont matter much anyways
[20:09] <holstein> len: i appreciate all your testing
[20:09] <holstein> and i like to keep an eye on older hardware
[20:09] <holstein> i hate discluding for no good reason
[20:10] <len> The AC97 is not much good for tracking due to sync issues. Some of them are ok at 48K though. I have a d66 instead.
[20:12] <len> My big thing right now is docs. We don't really have any at all. I am mostly putting together a collection of links.
[20:13] <holstein> its challenging
[20:13] <holstein> theres been a lot of fragmentation
[20:14] <holstein> and everyone's hardware case is differnt
[20:14] <holstein> per release
[20:14] <holstein> and sometimes, per kernel rev
[20:14] <holstein> makes working with different hardware, and having a definitive "how-to" challening to say the least
[20:17] <len> I try to make sure I say something about it not being definitive. But pointing to the right web site helps.
[20:20] <holstein> yeah, til alsa gets rev'd
[20:20] <holstein> or a kernel update breaks it
[20:21] <holstein> but... i dont want to be dark
[20:21] <holstein> its just challenging
[20:23] <len> What I found challenging, was searching for all these things with no direction. I hope to save someone some trouble. Should be good for as long as 12.04 goes though.
[20:24] <holstein> len: you are a gentleman and a scholar!
[20:25] <len> My next trick is to put it all in a package...