[07:32] <didrocks> good morning
[07:45] <duflu> Morning didrocks
[07:45] <duflu> (really the first one today)
[07:48] <didrocks> good morning duflu ;)
=== pstolowski|afk is now known as pstolowski
[08:11] <tjaalton> duflu: btw, eglexternalplatform headers are now in debian new queue.. egl-wayland will follow, but knowing how slowly the queue is processed I should probably upload them for disco too
[08:14] <duflu> tjaalton, thanks. Is that the exact package name?
[08:14] <tjaalton> duflu: source package yes
[08:15] <tjaalton> -dev for the binary
[08:17] <duflu> tjaalton, that appears to be different to https://github.com/NVIDIA/egl-wayland though, right?
[08:17] <tjaalton> it's needed for egl-wayland
[08:18] <tjaalton> which isn't in the queue yet
[08:18] <duflu> Oh
[08:18] <duflu> So it is
[08:24] <tjaalton> eglexternalplatform uploaded to disco
[08:27] <RAOF> tjaalton: oh, could you kindly cherry-pick the two post-1.1.0 commits into egl-wayland?
[08:28] <tjaalton> RAOF: immediately after the tag?
[08:28] <RAOF> They're required for Mir in order to actually have the wl_eglstream_controller symbols exported.
[08:28] <RAOF> Yeah, immediately after the tag.
[08:28] <tjaalton> alright
[08:29] <RAOF> Oh.
[08:29] <RAOF> You probably also want https://github.com/NVIDIA/egl-wayland/commit/e3b96b859d6a6d8de717bd3e4a75139553fe7027
[08:30] <RAOF> So, maybe just pull master 😀
[08:31] <RAOF> The 1.1.0 release might not have been the finest release to start with 😀
[08:31] <tjaalton> yeah the top commit looks to be required as well
[08:59] <clobrano> good morning all o/
[08:59] <didrocks> hey clobrano
[08:59] <willcooke> morning guys
[09:00] <didrocks> morning willcooke
[09:00] <clobrano> hey didrocks, how's it going?
[09:00] <willcooke> hi didrocks, bien?
[09:00] <seb128> good morning desktopers
[09:00] <didrocks> clobrano: I'm good, thanks, yourself?
[09:00] <didrocks> willcooke: ça va, et toi ?
[09:01] <clobrano> didrocks: I'm good as well :)
[09:01] <willcooke> j'ai mal aux gorge.
[09:01] <didrocks> argh, chacun son tour :p
[09:02] <willcooke> The kids had a sickness bug over the weekend.  Back to normal now, but it was The Exorcist there for a while.  I wonder if I've picked something up from them
[09:02] <duflu> Morning clobrano, willcooke, seb128
[09:02] <Laney> mew
[09:02] <didrocks> willcooke: classical
[09:02] <didrocks> hey Laney
[09:02] <duflu> ruf Laney
[09:02] <clobrano> morning duflu, willcooke, seb128 :)
[09:03] <seb128> hey willcooke duflu Laney clobrano didrocks etc :)
[09:03] <willcooke> hi seb128, clobrano duflu Laney
[09:03] <didrocks> re seb128
[09:03] <Laney> what's up!!!!!!!
[09:03] <seb128> it's monday \o/
[09:03] <Laney> MAKE SOME NOISEEEEEEE
[09:04] <duflu> all the desktop people, in the, umm, house
[09:04]  * duflu goes to make a decaf and would offer Laney one too if he was closer
[09:04] <seb128> w.e are nice but exhausting, I feel tired and with a start of a cold again :/
[09:05] <Laney> :(
[09:05] <didrocks> argh seb128 ;)
[09:05]  * Laney brings seb128 a blanket and sends him away
[09:06] <didrocks> the benefit of this is no excuse for a hot chocolate :)
[09:06] <seb128> Laney, thx :)
[09:07] <willcooke> andyrock, seb128 - I heard back from Michele re: the ordering of the window previews in the launcher.  He's merged the code to make the previews appear in the same order and will be dropping the old way (most recently opened at the top) totally. Could we rebase our Ubuntu branch?  It should have landed in the upstream main now.  Also - I had to ask him something for you and I can't remember what.  I'll search the logs.
[09:08] <seb128> willcooke, commit access for andyroc_k
[09:08] <seb128> thx
[09:08] <willcooke> seb128, damn you're good.
[09:08] <willcooke> seb128, just to our branch right?
[09:08] <seb128> :)
[09:09] <seb128> yes, but unsure you can have acl by branch?
[09:09] <didrocks> yeah, you can, this is how it is setup now
[09:09] <didrocks> the thing is that you can't then create new branches
[09:09] <seb128> and yeah, it merged it upstream in https://github.com/micheleg/dash-to-dock/commit/86f4404df
[09:09] <didrocks> like a maintainance branch
[09:10] <seb128> well, that's fine I guess, we don't need those as often so requesting an admin is ok
[09:11] <seb128> though andy wanted to discuss just moving to use a standard gbp workflow on launchpad as we do for other desktop components
[09:11] <didrocks> agreed, and I don't think for non LTS version, those makes sense anyway
[09:11] <didrocks> hum
[09:11] <didrocks> I don't understand why people really hate just git merge && gbp buildpackage
[09:11] <didrocks> and prefer a 10 steps long feet process :/
[09:12] <seb128> I think the issue is principaly lack of consitency and having to figure out what is the worklow there
[09:12] <didrocks> especially as the current setup create the orig tarball and debian diff for you automatically
[09:12] <didrocks> yeah, if I don't have to make releases of it, I think, do the best for you
[09:12] <seb128> different location, different acl, different mp process
[09:12] <didrocks> I don't care about location/acl
[09:12] <seb128> I'm just guessing why he wanted it in the same format/location than others
[09:12] <didrocks> yeah, and those makes sense
[09:12] <seb128> but let's wait for him to be around rather than guessing :)
[09:13] <didrocks> however, degrading the release process by other a complicated one on this…
[09:13] <didrocks> if I'm not the one making upgrade/releases, on it then, I'm fine
[09:13] <didrocks> otherwise, I disagree
[09:13] <seb128> right
[09:15] <didrocks> the process will never be the same anyway: upstream tarballs won't be named ubuntu-dock
[09:16] <didrocks> and there is no debian VCS for ubuntu-dock
[09:20] <didrocks> (same than ubuntu-settings and other ubuntu-only projects, we might then want to release tarballs and move all of them if the argument is consistency, which is acceptable, but adding a lot of work for not a real gain + a lot of additional work at each release IMHO)
[09:23] <seb128> yeah, let's wait for andyrock, I'm unsure what was his main motivation
[09:23] <seb128> if that was the fact that he's difficult to find a sponsor/someone with acls as it's set up today
[09:24] <seb128> like I can't merge for him atm
[09:24] <didrocks> I have nothing against moving to launchpad, this adds a little bit of overhead, but fine
[09:24] <seb128> he's -> it's
[09:24] <didrocks> I'm more opposed in changing to a gbp workflow though
[09:24] <seb128> right, that sounds fair enough
[09:24] <seb128> especially if that's the sort of projects where we do snapshots rather than tarballs
[09:25] <seb128> which probably makes sense in that context
[09:25] <didrocks> exactly
[09:25] <seb128> so +1 from me
[09:25] <seb128> I'm fine with either moving the branch to launchpad or adding people to github if that's possible
[09:26] <didrocks> I have no strong opinion, the only difference is that we have 2 places to deal with when we add something upstream
[09:26] <didrocks> but I think it's doable
[09:26] <didrocks> if we are going to move to launchpad, we'll have to setup a proper project and so on, but nothing too hard
[09:31] <tjaalton> RAOF, duflu: egl-wayland uploaded to both debian new and disco
[09:31] <tjaalton> finally..
[09:32] <duflu> tjaalton, you're my hero
[09:32] <RAOF> Woot! Thanks!
[09:33] <duflu> Is there a URL for it? I can't find it
[09:35] <tjaalton> which url are you looking for?
[09:36] <duflu> The Debian page, but I guess it will update within minutes
[09:37] <tjaalton> yeah I think it'll take a while
[09:37] <tjaalton> in the meantime you'll have this https://launchpad.net/ubuntu/disco/+queue?queue_state=0&queue_text=
[09:37] <tjaalton> :)
[09:38] <duflu> For unrelated reasons I was going to do some Nvidia work soon, so I guess I can verify this too
[09:43] <willcooke> thanks tjaalton duflu RAOF
[10:14] <k_alam> seb128: Hi, good morning......we talked about reviewing unity patches
[10:15] <seb128> k_alam, hey, yes, were those the 2 u-c-c ones?
[10:15] <k_alam> one u-c-c, one u-s-d
[10:15] <k_alam> https://code.launchpad.net/~khurshid-alam/unity-settings-daemon/media-keys-fix/+merge/359935
[10:16] <k_alam> and
[10:16] <k_alam> https://code.launchpad.net/~khurshid-alam/unity-control-center/fix-image-preview/+merge/359937
[10:16] <seb128> I saw them on the list, I try to have a look today
[10:17] <k_alam> Thanks. :)
[11:52]  * andyrock forgot to say "good morning all"
[12:07] <jbicha> didrocks: "no debian vcs for ubuntu-dock" < I guess we could upload it to Debian…
[12:07] <jbicha> good morning
[12:31] <seb128> jbicha, hey, that comment is not very constructive/useful in the context of the discussion which was about whether it was fine to have the packaging branch or github
[12:33] <jbicha> I don't see it as unconstructive
[12:33] <jbicha> https://tracker.debian.org/pkg/gnome-shell-extension-appindicator is in Debian, but appindicator is a far simpler extension to package
[12:34] <seb128> it has nothing to do with the topic discussed though
[12:35] <seb128> but feel free to package it for Debian if you wish
[12:58] <popey> Where should bugs against https://snapcraft.io/snap-store go? (Also it's a bug that the page doesn't say where bugs go) kenvandine ?
[13:01] <seb128> popey, we don't have a standard solution for bug reporting against snaps do we?
[13:06] <jbicha> seb128: are you aware of https://forum.snapcraft.io/t/snaps-officially-supported-by-canonical/1719 ?
[13:07] <seb128> jbicha, yes, why?
[13:07] <popey> seb128: well, i tend to suggest people put bug links in the descriptions
[13:08] <popey> unfortunately the link jbicha provided is outdated
[13:08] <seb128> popey, k, that seems suboptimal :(
[13:08] <popey> indeed
[13:08] <seb128> well, that page is also a patch-solution at best
[13:08] <seb128> not a proper answer to the problem
[13:09] <popey> perhaps we need a bug against the snap store to allow is to expose how to file bugs against the snap-store snap
[13:09] <popey> :)
[13:10] <seb128> lol
[13:11] <popey> I mean, we do, really. I'll speak to store people and see what the plans are.
[13:11] <seb128> that would be nice
[13:17] <popey> https://forum.snapcraft.io/t/metadata-key-for-bug-trackers/1604
[13:17] <popey> looks like it was already briefly discussed, outcome "use the contact field". So we could do that in the short term.
[14:10] <willcooke> Anyone heard of a gnome-shell issue where once the screensaver kicks in you can't get back to a working desktop and have to reboot?
[14:10] <willcooke> 18.04 machine upgraded from 16.04
[14:10] <popey> Yes, if the system updated via unattended-upgrades while the screensaver was up
[14:11] <willcooke> oh ho ho
[14:11] <willcooke> that
[14:11] <willcooke> I thought we'd stopped that from happening though
[14:12] <willcooke> popey, aware of a fix?  Is it a dist-upgrade again?
[14:12] <popey> I just dropped to tty and kill the login manager
[14:12] <popey> so effectively reboot
[14:12] <willcooke> this is happening all the time though, not just during upgrade
[14:12] <willcooke> or am I missing somethign?
[14:12] <popey> oh
[14:12] <popey> I don't know about that
[14:12] <willcooke> kk
[14:13] <willcooke> thx
[14:13] <popey> np
[14:17] <seb128> willcooke, you mean you updated a 16.04 machine and it looked during the upgrade and you couldn't unlock then?
[14:18] <willcooke> seb128, no, it sounds like (and I've not seen the machine in question yet) but everytime the screensaver kicks in (and I assume it's actually suspending) it cant wake up again
[14:18] <willcooke> I've asked for logs, but I might go and look at this one, since Sarah said that someone else in the office has the same thing
[14:18] <kenvandine> popey: i'll add bug reporting to the snap-store snap in the store
[14:18] <popey> <3 thanks
[14:19] <kenvandine> once i decide where i want that to be :)
[14:19] <kenvandine> my first thought is gitlab
[14:19] <kenvandine> but we're ending up with bugs all over the place
[14:24] <willcooke> kenvandine, hey!  Is this anything to do with magazine view?  https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1806146
[14:24] <ubot5> Ubuntu bug 1806146 in gnome-software (Ubuntu) "/usr/bin/gnome-software:11:magazine_chain_pop_head:thread_memory_magazine1_alloc:g_slice_alloc:g_slice_alloc0:g_type_create_instance" [Undecided,New]
[14:24] <willcooke> Or just a clash of names
[14:24] <kenvandine> clash of names
[14:24] <willcooke> kk, thx
=== Class7_ is now known as Class7
[15:37] <popey> kenvandine: willcooke I have -1'd our catch up later. Our team are having fewer meetings this week. If you had anything specific to discuss, feel free to ping a mail over <3
[15:37] <willcooke> popey, ack, wfm
[15:37] <popey> Wimpress: ^
[15:45] <kenvandine> popey: wfm
[18:17] <willcooke> night all, cubs tonight
=== pstolowski is now known as pstolowski|afk