[02:28] <duflu> RAOF: Another report of colour profiles being applied as too green has come in. Seems to be an issue consistently visible with whites appearing as lime green (bug 1803840)
[02:29] <duflu> It was previously reported by mpt and robert_ancell
[02:30] <duflu> Annoyingly, with all the hardware I own, I've never seen that bug myself
[02:31] <robert_ancell> weird
[02:34] <RAOF> Hm.
[02:35] <RAOF> I don't think night mode *is* a colour profile, though?
[02:35] <RAOF> Pretty sure that's just changing the gamma LUT.
[02:35] <RAOF> Which won't appear as a colour profile to applications.
[02:37] <duflu> RAOF: It's not about night mode...(?)
[02:38] <RAOF> The linked bug (that robert_ancell and mpt were on) talked about night mode.
[02:38] <duflu> RAOF: That's a true statement, but not relevant.
[02:39] <duflu> robert_ancell, what machine model did you experience that on?
[02:40] <robert_ancell> duflu, that was on mpts laptop which I believe was an old Lenovo!?
[02:41] <duflu> Yeah, still the same one I think. I will need to scroll back a lot to find his answer
[02:46]  * RAOF might need to acquire another colourhug, as his seems to have dropped off the USB.
[02:47] <duflu> RAOF: I seem to have had a couple of dicky USB cables. Took a while to find one that was reliable with it
[02:53] <duflu> Can't remember if it was Kmart cables that caused the problem or solved it :)
[02:57] <Trevinho> hi duflu
[02:57] <duflu> hola Trevinho
[02:57] <Trevinho> and hey RAOF... Do you know a bit the transformation code for Xorg?
[02:57] <Trevinho> RAOF: as I was hitting and looking at https://gitlab.freedesktop.org/xorg/xserver/issues/14
[02:57] <gitbot> xorg issue 14 in xserver "Xorg crashes when it tries to resume a scale transformation after that it has been closed" [Opened]
[02:58]  * duflu knows nothing if you're talking about the Xorg internals there
[02:58] <RAOF> Urgh, vtable chains!
[02:59] <Trevinho> RAOF: well, not either too much related to vtables as it's probably like the server tries to destroy something (the filters) earlier than the server is shut down
[02:59] <Trevinho> I mean, I whish there was a XSerever destroyed thing, more than a CloseScreen
[03:00] <RAOF> Why not break the ABI?
[03:00] <duflu> It is a Tuesday after all
[03:00]  * RAOF is reading the MR
[03:00] <duflu> for some
[03:00] <Trevinho> RAOF: not really a MR yet, just a commit
[03:01] <RAOF> The Xorg ABI is pretty fluid :)
[03:01] <Trevinho> RAOF: well, that would imply rebuilding all the drivers, but..
[03:01] <Trevinho> ah ok :)
[03:01] <RAOF> At least it was last I checked.
[03:01] <RAOF> At least a couple of years ago the ABI broke once per Xserver release, so rebuilding all the drivers is not really a blocking issue :)
[03:01] <Trevinho> you can do the reviewing or you know who point me for that? As depending on that we can discuss it
[03:02] <Trevinho> like, if you can review / approve, and if breaking the ABI is feasible, we can do that :)
[03:02] <duflu> Speaking of which... I have a theory that those Xorg crashes triggered by some snaps might be related to shipping ABI incompatibilities that Xorg isn't robust enough to handle
[03:03] <Trevinho> mh, client side would be weird, isn't it?
[03:09] <Trevinho> RAOF: ^
[03:11] <RAOF> Snaps wouldn't be breaking on Xorg ABI changes.
[03:12] <RAOF> I can't actually review, sorry; I've been out of the mainline of Xorg development for a while.
[03:14] <duflu> RAOF: It's not the snaps breaking, but doing the breaking (bug 1754693)
[03:14] <RAOF> <freenode_duf "Speaking of which... I have a th"> Snaps can't interact with the Xorg loader at all. They *might* be sending messages unknown to the server, but that code is pretty robust.
[03:15] <duflu> Actually, maybe same theory but Mesa not Xorg
[03:16] <Trevinho> RAOF: ok, thanks anyways :)
[03:17] <RAOF> Snaps *also* can't interact with GNOME Shell's dri loader 😀
[03:19] <RAOF> I'd expect that it's unrelated to snaps and the Skype client just makes the correct sequence of requests to trigger a common-or-garden Xserver bug.
[03:20] <RAOF> (a way to test this hypothesis would involve using Xtrace to dump the protocol interactions)
[03:21] <RAOF> Or maybe a llvmpipe bug.
[03:44] <sarnold> duflu: thanks for joining together the gdm/plymouth bugs, I missed that you had asked for he new bug. :) thanks!
[03:44] <duflu> sarnold, I actually went looking for the bug he said he created today, but did not find it because of "Private Security"
[03:45] <sarnold> duflu: yeah.. I wish the new bug form made it easier to mark a bug security without making it private
[03:47] <duflu> Trevinho, do you know how to make the Ubuntu Dock appear in a local build of gnome-shell? I can't get it to appear any more. Only the upstream dock
[03:47] <duflu> --mode=ubuntu doesn't do it
[03:48] <Trevinho> duflu: are you using that in your home or different home?
[03:48] <duflu> Trevinho, a local build from home
[03:49] <Trevinho> duflu: ok in any case you'd need this https://github.com/micheleg/dash-to-dock/pull/825/
[03:49] <duflu> Oh. I guess it needs to find extensions in a home-like location ?
[03:49] <gitbot> micheleg issue (Pull request) 825 in dash-to-dock "dash, docking: remove Shell.GenericContainer" [Open]
[03:49] <Trevinho> duflu: so basically, install that in your home
[03:49] <Trevinho> that's for latest gnome-shell
[03:49] <duflu> Trevinho, thanks. I should have thought of the API break
[03:50] <Trevinho> duflu: I think the log was showing that
[03:51] <Trevinho> duflu: anyway, just apply that diff to the ubuntu-branch in case, and put that in your ~/.local/share/gnome-shell/extensions/<extension-id>
[03:51] <Trevinho> generally I also use a different home for such stuff though
[03:51] <duflu> Yes, the log says that's the error
[03:51] <Trevinho> just passing env HOME, not really to use a different user
[03:52] <duflu> Maybe I'll just defer Ubuntu Dock work till it's all fixed in disco
[04:11] <Trevinho> duflu: well, as you wish it's not really a problem once you've set thungs up
[04:12] <Trevinho> duflu: I've something like this
[04:12] <Trevinho> `ls -l /data/GNOME/JHBUILD_HOME/.local/share/gnome-shell/extensions/ -l`
[04:12] <Trevinho> `lrwxrwxrwx 1 marco marco 18 ago 29 22:03 dash-to-dock@micxgx.gmail.com -> /data/dash-to-dock`
[04:13] <Trevinho> so basically /dat/dash-to-dock is the git repo of it, while I launch gnome-shell with `HOME=/data/GNOME/JHBUILD_HOME`
[04:17] <duflu> Trevinho, thanks. I haven't worked on dash-to-dock since switching to local builds. So I will do something like that next time I do
[04:20] <Trevinho> duflu: really, you should use jhbuild though :)
[04:20] <Trevinho> duflu: just add something like this as config (setting your paths) https://pastebin.com/tZXYfXnL
[04:20] <duflu> Then I wouldn't find all the build bugs before everyone else
[04:21] <Trevinho> once you've that you can just do `jhbuild build gnome-shell` and since there you've things set up, and you can also manually `ninja install` or whatever you prefer
[04:21] <Trevinho> but at least you've all upstream stuff setup in your prefix, without having to care much about things and being able to track things if you need to install
[04:21] <Trevinho> or uninstall
[04:22] <duflu> I think I can handle typing --prefix=
[04:22] <duflu> and env PKG_CONFIG_PATH=
[04:28] <Trevinho> duflu: well, it's not just that especially for stuff that needs particular GIR stuff...
[04:29] <Trevinho> duflu: these should be the envs actually https://paste.ubuntu.com/p/cth7dKB6Yr/
[04:29] <Trevinho> well a part from my local ones :
[04:31] <Trevinho> well better this
[04:31] <Trevinho> https://www.irccloud.com/pastebin/f3RfExzG/runner.sh
[04:33] <Trevinho> but well, that's for example to run gdm from that build installation, with a local gnome-shell or things like that
[06:27] <seb128> good morning desktopers!
[06:29] <seb128> tkamppeter, jamesh, hey, don't forget your weekly update on the hub
[06:35] <jibel> good morning
[07:12] <duflu> Hi seb128, jibel
[07:20] <jibel> Hi duflu
[07:22] <didrocks> good morning
[07:24] <oSoMoN> good morning desktoppers
[07:24] <didrocks> salut oSoMoN
[07:25] <oSoMoN> salut didrocks, ça va?
[07:28] <duflu> 'lo oSoMoN
[07:28] <duflu> 'lu oSoMoN :)
[07:28] <oSoMoN> hey duflu, how goes?
[07:29] <duflu> oSoMoN, was going well but today the barber accidentally removed too much of my eyebrows. Otherwise good. You?
[07:29] <didrocks> oSoMoN: ça va, et toi ?
[07:30] <oSoMoN> I'm good, it was a short night but I feel rested and hopeful that this will be a productive day
[07:32] <oSoMoN> sorry for your eyebrows duflu. luckily those things tend to grow again
[07:32] <duflu> Yes, they were needing combing, which is too long
[08:50] <duflu> Morning willcooke
[08:50] <duflu> Morning mpt. Can you remind me what model laptop had the colour profile issue?
[08:56] <willcooke> morning duflu, all
[08:56] <seb128> hey willcooke
[08:56] <willcooke> hi seb128, how goes?
[08:56] <seb128> good! you?
[08:56] <seb128> done with the post-holidays catch? no surprise in there? ;)
[08:57] <willcooke> email firehose, but pretty much caught up.  Yeah, no fires, thank you!
[08:57] <willcooke> In other news, I have carpet and paint in my office
[08:57] <willcooke> and a new monitor
[08:57] <willcooke> No more squinting at a tiny screen \o/
[08:58] <duflu> willcooke, are those two things also applied? :)
[08:58] <willcooke> ha!  Yes, they are in the right place
[08:58] <willcooke> no paint on the carpet
[08:58] <willcooke> I've seen rather too much of Ikea in the last week though
[08:59] <seb128> jamesh, tkamppeter, weekly summary reminder?
[08:59] <seb128> willcooke, nice :) which one did you pick? 26"?
[08:59]  * willcooke -> meeting.  Will send reminder after that
[08:59] <seb128> enjoy!
[08:59] <willcooke> seb128, 24" Dell ultrasharp.
[08:59] <willcooke> it's lovely
[08:59] <seb128> good to know
[08:59]  * duflu highfives willcooke
[09:00] <duflu> PremierColor FTW
[09:00] <willcooke> It's got this awesome audio-pass-through feature, so depending on which input is selected, thats the audio which comes out the speakers
[09:01] <duflu> I think DisplayPort does that as well as HDMI
[09:01] <willcooke> yeah
[09:01] <Laney> hey
[09:01] <duflu> hey Laney
[09:02] <seb128> hey Laney, how are you?
[09:02] <duflu> It's nice not needing to calibrate a monitor, because then you avoid bug 1785764
[09:03] <seb128> I though that there was a default/computed profile so users would hit that problem even without doing calibration?
[09:05] <duflu> seb128, Yes... but what I mean is with a factory calibrated monitor the workaround of not having a custom profile in software doesn't matter
[09:06] <mpt> duflu, a MacBook 2008 vintage
[09:06] <seb128> k
[09:07] <duflu> Ah. Ta mpt
[09:08] <Laney> hey duflu seb128
[09:09] <Laney> seb128: i'm good, got to meet the transport guy from the council last night and ask him about cycling
[09:09] <Laney> ...not much is coming...
[09:09] <Laney> you?
[09:09] <seb128> :(
[09:09] <seb128> I'm good! slept well, but I got up early, it feels like middle of the night now at 6:30 :/
[09:13] <Laney> :<
[09:13] <Laney> its cold this week too
[09:18] <seb128> yeah, near 0°C here and windy brrrr
[10:34] <cpaelzer> Hi, I'm experimenting with virtual gpus and wonder where to check best for what is actually used atm
[10:34] <cpaelzer> I see in lspci that I ahve both (qxl by kvm and an intel HD card passed through) in the guest
[10:34] <cpaelzer> and I see Xorg.0.log mentioning qxl and i965 drivers
[10:35] <cpaelzer> what would be the best place to verify which e.g. xrandr outputs are of which driver and stuff like that?
[10:35] <duflu> cpaelzer, if you have multiple GPUs then each app is free to choose which one it uses. Do you have one or multiple?
[10:36] <duflu> In that case, only the app can answer the question. To see what the default one is, install mesa-utils and then run 'glxinfo'
[10:37] <cpaelzer> the guest has multiple gpus now
[10:37] <cpaelzer> thanks checking out glxinfo ...
[10:41] <duflu> cpaelzer, you can also use standard Unix tools like lsof and fuser to find which GPU each process has open (/dev/dri/card*). You can also look at the outputs that are directly wired to each card in /sys/class/drm/...
[10:42] <duflu> Although those are cards, vs render nodes. I think it would still answer your questions
[10:43] <cpaelzer> duflu: yeah that clearly got me further
[10:43] <cpaelzer> glxinfo was a lot of output and nothing clear - I assume I'd see multiple "Device" entries there if it fully initializes
[10:43] <cpaelzer> but there is only one entry for a virtual device
[10:44] <cpaelzer> yet the /dev/dri/card has both entries, so that is good at leas
[10:44] <cpaelzer> t
[10:44] <duflu> cpaelzer, I think a GL/EGL/GLX context is only ever bound to one GPU. So 'glxinfo' will only ever give one answer
[10:44] <cpaelzer> ah ok that would be ok for glxinfo then
[10:45] <cpaelzer> also the /sys/class/drm looks good, essentially card0 (the virtual one) has 4 virtual outputs and the card1 (passthrough) has exactly the external port config of my system
[10:45] <cpaelzer> duflu: do you know how I know could make an application use card1-hdmi1 for example?
[10:45] <cpaelzer> if that makes any sense
[10:45] <cpaelzer> the UI itself seems on card0 with output "virtual0"
[10:46] <duflu> cpaelzer, it kind of makes sense. You have to tell the app (and the app must support) manual selection of a /dev/dri/cardN. Then once the card is selected you choose the output
[10:47] <duflu> However... APPS only use /dev/dri/cardN. The display server is fixed to whatever card you are physically plugged into, in the least
[10:48] <duflu> Hmm. Or do apps get away with just using render nodes? I'm not sure now
[10:53] <duflu> cpaelzer, one more tip before I log off. This will show you active monitors:   grep . /sys/class/drm/*/enabled
[10:53] <duflu> grep . /sys/class/drm/*/enabled
[10:54] <duflu> or just:  grep enabled /sys/class/drm/*/enabled
[10:55] <cpaelzer> thanks
[10:57] <cpaelzer> all seem enabled except a virtual port - I think that would only exist in a docking station, but that is fine
[11:20] <oSoMoN> seb128, re https://bugzilla.gnome.org/show_bug.cgi?id=746422#c60, do you reckon it would be acceptable to SRU n-m 1.10.14 to bionic
[11:20] <oSoMoN> ?
[11:23] <willcooke> I would like to see that too, but will see what seb says
[12:27] <seb128> oSoMoN, willcooke, the shorter/easier the diff the better I feel about a SRU, that one is non trivial but should be doable with proper testing I guess... depends how important we consider the issue to be and how risky the change is
[13:29] <oSoMoN> seb128, I can prepare test packages in a PPA to give it a solid round of testing before we decide what to do
[13:45] <seb128> oSoMoN, wfm, we can also give it a solid round of testing once it's in proposed
[13:55] <willcooke> oSoMoN, hit me up with the ppa and I will start testing
[14:30] <willcooke> #startmeeting Desktop Team Weekly Meeting 2018-11-20
[14:30] <meetingology> Meeting started Tue Nov 20 14:30:37 2018 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:30] <meetingology> Available commands: action commands idea info link nick
[14:30] <tseliot> o/
[14:31] <seb128> hey
[14:31] <Nafallo> o/
[14:31] <willcooke> Roll call: andyrock, dgadomski, didrocks, duflu (out), jbicha, jamesh (out), jibel, kenvandine, laney, oSoMoN, seb128, tkamppeter, trevinho, robert_ancell (out)
[14:31] <didrocks> hey
[14:31] <oSoMoN> 🐵/
[14:31] <andyrock> o/
[14:31] <kenvandine> \o
[14:31]  * willcooke tries to remember how to do this
[14:31] <willcooke> Lets review the rls bugs
[14:32] <willcooke> Looks like everyone has updated their bugs (based on the hub post)
[14:32] <willcooke> bb-incoming : http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[14:32] <willcooke> nothing for us atm
[14:33] <willcooke> rls-bb-tracking: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html
[14:33] <willcooke> Everything is assigned
[14:34] <willcooke> correction
[14:34] <willcooke> L_aney assigned this to tjaalton https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1714178
[14:35] <willcooke> and this: https://bugs.launchpad.net/amd/+bug/1770271
[14:35] <willcooke> and this: https://bugs.launchpad.net/ubuntu/bionic/+source/mesa/+bug/1798597
[14:35] <seb128> sounds good
[14:36] <willcooke> cc incoming: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html
[14:36] <seb128> willcooke, on -bb you forgot https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1800135
[14:36] <seb128> L_aney in his email recommends -notfixing
[14:36] <seb128> which I'm +1 with
[14:37] <willcooke> ah, I didnt think that was one for us
[14:37] <willcooke> ah, kk
[14:37] <seb128> it doesn't impact Ubuntu Desktop
[14:37] <willcooke> yeah
[14:37] <willcooke> +1 from me
[14:37] <seb128> let's do that then :)
[14:37] <willcooke> looks like the tag is already gone
[14:37] <seb128> right, because it's nomination accepted
[14:38] <seb128> I wonder if rls-bb-notfixing works for those case?
[14:38] <willcooke> I added it anyway
[14:38] <seb128> thx
[14:38] <willcooke> cc-incoming: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html
[14:39] <willcooke> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1754693
[14:39] <willcooke> IMO we should try and fix that one
[14:39] <seb128> +1
[14:39] <willcooke> but... it's wayland, so less important
[14:39] <willcooke> hrm
[14:39] <willcooke> I still think we need to, because it will be broken elsewhere
[14:40] <seb128> yeah, also it makes those snap not work as good
[14:40] <seb128> and wayland is default on some other distros
[14:40] <willcooke> yeah
[14:40] <willcooke> oki, +1 to fix
[14:40] <seb128> we need an assignee though
[14:40] <willcooke> tjaalton, would you be able to take a look at it? ^
[14:40] <seb128> tjaalton can you ... what will said :)
[14:41] <willcooke> while we wait, https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1799293
[14:41] <seb128> +1 to accept the nomination
[14:42] <willcooke> L_aney said it's pretty rare and edge-casey.  I agree notfixing, but we work on it as time allows anyway
[14:42] <andyrock> well it's a security issue if you close your laptop
[14:42] <andyrock> and the lockscreen is no there when you re-open it
[14:42] <willcooke> then dont enable auto login :)
[14:42] <andyrock> I mean you suspend it
[14:42] <seb128> it's not only autologin
[14:42] <willcooke> oh
[14:43] <willcooke> ahhh
[14:43] <andyrock> I'm pretty sure it has the same root case of dash-to-dock over lockscreen
[14:43] <willcooke> this could be related to the problems that you were having jibel
[14:43] <andyrock> at least in one varaint
[14:43] <willcooke> andyrock, yeah
[14:43] <seb128> one of the comments mentions bg setting
[14:43] <seb128> I was going to say that
[14:43] <tjaalton> willcooke: okay
[14:43] <willcooke> thank you tjaalton
[14:43] <seb128> andyrock, do you want to take on that?
[14:43] <andyrock> the main variant of the dash-to-dock over lockscreen is that both are enabled
[14:43] <andyrock> and I'm fixing it
[14:44] <seb128> +1 from me on nominating based on the fact that's it's screen failing to lock which is border security
[14:44] <willcooke> in which case, thanks andyrock
[14:44] <andyrock> than there is the other variant (and I think it shares the same main cause)
[14:44] <andyrock> no idea what's the cause but it needs to be fixed
[14:45] <willcooke> assigned it and targetted to C
[14:45] <willcooke> it wouldnt let me target D
[14:45] <andyrock> thx
[14:45] <willcooke> and the next one is: http://launchpad.net/bugs/1769383
[14:45] <willcooke> which we covered above and is assigned
[14:45] <seb128> right
[14:46] <willcooke> dd incoming: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html
[14:46] <andyrock> I would target bionic for 1769383 too
[14:47] <willcooke> andyrock, done
[14:47] <willcooke> dd has the same bug as we already talked about
[14:47] <willcooke> k, that's the end of the list I think
[14:47] <willcooke> anyone want to talk about those before we move on to AOB
[14:48] <willcooke> if they do, we can come back round again
[14:48] <willcooke> #topic AOB
[14:48] <willcooke> I remember there being a question from the hub
[14:49] <willcooke> didrocks I think you suggested someone come and ask something, can you remember what?
[14:49] <didrocks> yes, I don't remember the question though :p
[14:49] <willcooke> I'll look
[14:49] <didrocks> ah, it's something that clobrano already asked
[14:49] <didrocks> IIRC
[14:49] <didrocks> so, that's settled :)
[14:50] <willcooke> in the meantime, do you think we will get the new d-2-d in D?  With the window preview ordering "fixes"?
[14:50] <clobrano> hey :D
[14:50] <didrocks> hey clobrano :)
[14:50] <willcooke> hey clobrano
[14:50] <didrocks> unsure I have time currently with the installer work
[14:50] <clobrano> hi willcooke , didrocks
[14:50] <didrocks> so, probably in a quieter time, if no-one beats me to do the upload
[14:50] <willcooke> didrocks, ack, thx
[14:50] <didrocks> same for Yaru btw, would be need if someone cut a new release
[14:51] <didrocks> nice*
[14:51] <willcooke> nod
[14:51] <clobrano> didrocks: what question? :)
[14:51] <didrocks> clobrano: willcooke will have a look again
[14:53] <willcooke> cant find it, I'll look it out after the meeting
[14:53] <willcooke> anyone got anything else?
[14:53] <willcooke> guess not.
[14:53] <willcooke> #endmeeting
[14:53] <meetingology> Meeting ended Tue Nov 20 14:53:50 2018 UTC.
[14:53] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2018/ubuntu-desktop.2018-11-20-14.30.moin.txt
[14:53] <willcooke> thanks all
[14:53] <oSoMoN> thanks
[14:54] <willcooke> Ah, I found it - but it was from 5 months ago, and someone just replied now :)
[14:54] <willcooke> so ignore me
[14:55] <andyrock> thx
[14:56] <tseliot> sorry, I missed the chance to update you on nvidia
[14:56] <seb128> thx
[14:56] <willcooke> tseliot, np, now is good
[14:56] <seb128> tseliot, you can still do now :)
[14:56] <tseliot> willcooke: just FYI, I uploaded nvidia 410.78 in disco. It will be an additional flavour, in addition to 390, which will be a legacy driver. And I plan to backport 410 to Bionic.
[14:56] <willcooke> nice!
[14:56] <didrocks> thx
[14:56] <tseliot> the new nvidia is still in NEW, so it might take a while
[14:57] <tseliot> that's all I have
[14:57] <willcooke> thanks tseliot
[14:57] <tseliot> :)
[15:29] <Laney>  added: rls-cc-tracking
[15:29] <Laney> that's not a tag btw
[15:32]  * Laney nominates https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1754693 and makes sure tasks on other bugs have assignees :-)
[15:32]  * Laney the bug janitor
[15:40] <willcooke> thanks Laney
[15:40] <Laney> anything for #ubuntu-desktop 😘
[16:04] <andyrock> didrocks: https://github.com/micheleg/dash-to-dock/pull/843
[16:04] <gitbot> micheleg issue (Pull request) 843 in dash-to-dock " extension: Ensure signal disconnection " [Open]
[16:04] <andyrock> could you take a look?
[16:25] <didrocks> andyrock: will do tomorrow morning. Still in installer build
[16:25] <andyrock> kk
[17:18] <oSoMoN> willcooke, https://launchpad.net/~osomon/+archive/ubuntu/nm-lp1754671/+packages just built, I haven't actually tested, hopefully this doesn't break the internet badly
[17:20] <willcooke> thanks oSoMoN, I will install it tomorrow and report back
[17:20] <willcooke> or not
[17:20] <willcooke> depending :)
[17:21] <oSoMoN> :)
[17:36]  * oSoMoN calls it a day
[17:36] <oSoMoN> have a good evening everyone
[18:01] <willcooke> dinner time, night all
[18:46] <popey> I <3 the update posts on discourse. Especially all the lovely icons and emoji! :D
[21:26] <andyrock> seb128: still here? do you mind creating the ubuntu/cosmic branch for gnome-control-center ?
[21:26] <andyrock> I want to prepare the SRU
[21:54] <seb128> andyrock, k, I can do that
[22:01] <seb128> andyrock, k, done, I created it from the 1:3.30.1-1ubuntu2  tag which is the current cosmic version
[22:02] <seb128> on that note, calling it a day, night desktopers
[22:39] <robert_ancell> RAOF, I have a gnome-software 3.28.1-0ubuntu4.18.04.7 SRU which has one of the bugs as failed on the pending-sru page - this bug was in the .6 SRU and removed in .7 - do you know if this is holding back the SRU from being verified?
[22:40] <RAOF> robert_ancell: That probably would be holding back the verification (or, at least, would be preventing people from acting on it). Why is it still marked as failed?
[22:40] <robert_ancell> RAOF, the fix caused another issue so was abandoned. So it shouldn't be considered part of the SRU anymore.
[22:51] <RAOF> Ok, there's something weird with that SRU.
[23:18] <RAOF> robert_ancell: Aaah! I think someone accidentally accepted it into -proposed without a complete .changes list.
[23:19] <robert_ancell> RAOF, yeah, I think I missed the -v when building the source package
[23:19] <RAOF> Or maybe not? I'm not entirely sure how to read this launchpad output.
[23:20] <robert_ancell> So it is in proposed, but I wonder if the bug being marked red means it will stay there
[23:20] <RAOF> robert_ancell: Right, which is why the bug tracking is screwy.
[23:20] <RAOF> robert_ancell: And why it hasn't actually been verified.
[23:20] <RAOF> Only one of the green bugs on the pending-sru page has actually been verified against the version of the upload in -proposed.
[23:24] <robert_ancell> RAOF, ok, I'll chase up the verifiers to reconfirm.
[23:24] <RAOF> robert_ancell: I'm not entirely sure how to proceed here; the *simplest* thing for me would be to ask you to upload again with a correct .changes file, accept that, and it will trigger all the necessary “please verify” requests.
[23:25] <robert_ancell> RAOF, can I re-use the .7 version?
[23:25] <RAOF> Nope, it'd need to be .8
[23:25] <robert_ancell> *sigh*
[23:25] <RAOF> Launchpad has seen the .7 version, and what Launchpad sees cannot be unseen!
[23:25] <robert_ancell> RAOF, so would you like me to do that then?
[23:26] <RAOF> I think that would be simplest, yes. Please do so.
[23:26] <robert_ancell> And the .changes should have changes from .5 .6 .7 and .8 in it right?
[23:26] <RAOF> Correct. Everything since the current version in -updates
[23:30] <RAOF> That will leave #1754864 incorrectly marked as fixed, I think, but I'll manually fix the status post-acceptance.
[23:32] <robert_ancell> RAOF, uploaded
[23:35] <RAOF> Ta. RAOF
[23:42] <RAOF> Sorry about the faffing.