[02:28] 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:28] bug 1803840 in colord (Ubuntu) "color calibration with huey pro greenish" [High,Confirmed] https://launchpad.net/bugs/1803840 [02:29] It was previously reported by mpt and robert_ancell [02:30] Annoyingly, with all the hardware I own, I've never seen that bug myself [02:31] weird [02:34] Hm. [02:35] I don't think night mode *is* a colour profile, though? [02:35] Pretty sure that's just changing the gamma LUT. [02:35] Which won't appear as a colour profile to applications. [02:37] RAOF: It's not about night mode...(?) [02:38] The linked bug (that robert_ancell and mpt were on) talked about night mode. [02:38] RAOF: That's a true statement, but not relevant. [02:39] robert_ancell, what machine model did you experience that on? [02:40] duflu, that was on mpts laptop which I believe was an old Lenovo!? [02:41] 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] 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] Can't remember if it was Kmart cables that caused the problem or solved it :) [02:57] hi duflu [02:57] hola Trevinho [02:57] and hey RAOF... Do you know a bit the transformation code for Xorg? [02:57] RAOF: as I was hitting and looking at https://gitlab.freedesktop.org/xorg/xserver/issues/14 [02:57] 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] Urgh, vtable chains! [02:59] 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] I mean, I whish there was a XSerever destroyed thing, more than a CloseScreen [03:00] Why not break the ABI? [03:00] It is a Tuesday after all [03:00] * RAOF is reading the MR [03:00] for some [03:00] RAOF: not really a MR yet, just a commit [03:01] The Xorg ABI is pretty fluid :) [03:01] RAOF: well, that would imply rebuilding all the drivers, but.. [03:01] ah ok :) [03:01] At least it was last I checked. [03:01] 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] you can do the reviewing or you know who point me for that? As depending on that we can discuss it [03:02] like, if you can review / approve, and if breaking the ABI is feasible, we can do that :) [03:02] 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] mh, client side would be weird, isn't it? [03:09] RAOF: ^ [03:11] Snaps wouldn't be breaking on Xorg ABI changes. [03:12] I can't actually review, sorry; I've been out of the mainline of Xorg development for a while. [03:14] RAOF: It's not the snaps breaking, but doing the breaking (bug 1754693) [03:14] bug 1754693 in xorg-server (Ubuntu) "Xwayland/Xorg crashed with SIGSEGV in st_renderbuffer_delete() from _mesa_reference_renderbuffer_() [often when running Skype or Slack snaps]" [High,Confirmed] https://launchpad.net/bugs/1754693 [03:14] 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] Actually, maybe same theory but Mesa not Xorg [03:16] RAOF: ok, thanks anyways :) [03:17] Snaps *also* can't interact with GNOME Shell's dri loader 😀 [03:19] 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] (a way to test this hypothesis would involve using Xtrace to dump the protocol interactions) [03:21] Or maybe a llvmpipe bug. [03:44] duflu: thanks for joining together the gdm/plymouth bugs, I missed that you had asked for he new bug. :) thanks! [03:44] sarnold, I actually went looking for the bug he said he created today, but did not find it because of "Private Security" [03:45] duflu: yeah.. I wish the new bug form made it easier to mark a bug security without making it private [03:47] 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] --mode=ubuntu doesn't do it [03:48] duflu: are you using that in your home or different home? [03:48] Trevinho, a local build from home [03:49] duflu: ok in any case you'd need this https://github.com/micheleg/dash-to-dock/pull/825/ [03:49] Oh. I guess it needs to find extensions in a home-like location ? [03:49] micheleg issue (Pull request) 825 in dash-to-dock "dash, docking: remove Shell.GenericContainer" [Open] [03:49] duflu: so basically, install that in your home [03:49] that's for latest gnome-shell [03:49] Trevinho, thanks. I should have thought of the API break [03:50] duflu: I think the log was showing that [03:51] duflu: anyway, just apply that diff to the ubuntu-branch in case, and put that in your ~/.local/share/gnome-shell/extensions/ [03:51] generally I also use a different home for such stuff though [03:51] Yes, the log says that's the error [03:51] just passing env HOME, not really to use a different user [03:52] Maybe I'll just defer Ubuntu Dock work till it's all fixed in disco [04:11] duflu: well, as you wish it's not really a problem once you've set thungs up [04:12] duflu: I've something like this [04:12] `ls -l /data/GNOME/JHBUILD_HOME/.local/share/gnome-shell/extensions/ -l` [04:12] `lrwxrwxrwx 1 marco marco 18 ago 29 22:03 dash-to-dock@micxgx.gmail.com -> /data/dash-to-dock` [04:13] 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] 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] duflu: really, you should use jhbuild though :) [04:20] duflu: just add something like this as config (setting your paths) https://pastebin.com/tZXYfXnL [04:20] Then I wouldn't find all the build bugs before everyone else [04:21] 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] 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] or uninstall [04:22] I think I can handle typing --prefix= [04:22] and env PKG_CONFIG_PATH= [04:28] duflu: well, it's not just that especially for stuff that needs particular GIR stuff... [04:29] duflu: these should be the envs actually https://paste.ubuntu.com/p/cth7dKB6Yr/ [04:29] well a part from my local ones : [04:31] well better this [04:31] https://www.irccloud.com/pastebin/f3RfExzG/runner.sh [04:33] but well, that's for example to run gdm from that build installation, with a local gnome-shell or things like that === Class7_ is now known as Class7 [06:27] good morning desktopers! [06:29] tkamppeter, jamesh, hey, don't forget your weekly update on the hub [06:35] good morning [07:12] Hi seb128, jibel [07:20] Hi duflu [07:22] good morning [07:24] good morning desktoppers [07:24] salut oSoMoN [07:25] salut didrocks, ça va? [07:28] 'lo oSoMoN [07:28] 'lu oSoMoN :) [07:28] hey duflu, how goes? [07:29] oSoMoN, was going well but today the barber accidentally removed too much of my eyebrows. Otherwise good. You? [07:29] oSoMoN: ça va, et toi ? [07:30] I'm good, it was a short night but I feel rested and hopeful that this will be a productive day [07:32] sorry for your eyebrows duflu. luckily those things tend to grow again [07:32] Yes, they were needing combing, which is too long === pstolowski|afk is now known as pstolowski [08:50] Morning willcooke [08:50] Morning mpt. Can you remind me what model laptop had the colour profile issue? [08:56] morning duflu, all [08:56] hey willcooke [08:56] hi seb128, how goes? [08:56] good! you? [08:56] done with the post-holidays catch? no surprise in there? ;) [08:57] email firehose, but pretty much caught up. Yeah, no fires, thank you! [08:57] In other news, I have carpet and paint in my office [08:57] and a new monitor [08:57] No more squinting at a tiny screen \o/ [08:58] willcooke, are those two things also applied? :) [08:58] ha! Yes, they are in the right place [08:58] no paint on the carpet [08:58] I've seen rather too much of Ikea in the last week though [08:59] jamesh, tkamppeter, weekly summary reminder? [08:59] willcooke, nice :) which one did you pick? 26"? [08:59] * willcooke -> meeting. Will send reminder after that [08:59] enjoy! [08:59] seb128, 24" Dell ultrasharp. [08:59] it's lovely [08:59] good to know [08:59] * duflu highfives willcooke [09:00] PremierColor FTW [09:00] 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] I think DisplayPort does that as well as HDMI [09:01] yeah [09:01] hey [09:01] hey Laney [09:02] hey Laney, how are you? [09:02] It's nice not needing to calibrate a monitor, because then you avoid bug 1785764 [09:02] bug 1785764 in gnome-control-center (Ubuntu) "Chrome/Chromium and Image Viewer distort colours if a colour profile is enabled." [High,Confirmed] https://launchpad.net/bugs/1785764 [09:03] I though that there was a default/computed profile so users would hit that problem even without doing calibration? [09:05] 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] duflu, a MacBook 2008 vintage [09:06] k [09:07] Ah. Ta mpt [09:08] hey duflu seb128 [09:09] seb128: i'm good, got to meet the transport guy from the council last night and ask him about cycling [09:09] ...not much is coming... [09:09] you? [09:09] :( [09:09] I'm good! slept well, but I got up early, it feels like middle of the night now at 6:30 :/ [09:13] :< [09:13] its cold this week too [09:18] yeah, near 0°C here and windy brrrr [10:34] Hi, I'm experimenting with virtual gpus and wonder where to check best for what is actually used atm [10:34] I see in lspci that I ahve both (qxl by kvm and an intel HD card passed through) in the guest [10:34] and I see Xorg.0.log mentioning qxl and i965 drivers [10:35] what would be the best place to verify which e.g. xrandr outputs are of which driver and stuff like that? [10:35] 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] 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] the guest has multiple gpus now [10:37] thanks checking out glxinfo ... [10:41] 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] Although those are cards, vs render nodes. I think it would still answer your questions [10:43] duflu: yeah that clearly got me further [10:43] glxinfo was a lot of output and nothing clear - I assume I'd see multiple "Device" entries there if it fully initializes [10:43] but there is only one entry for a virtual device [10:44] yet the /dev/dri/card has both entries, so that is good at leas [10:44] t [10:44] 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] ah ok that would be ok for glxinfo then [10:45] 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] duflu: do you know how I know could make an application use card1-hdmi1 for example? [10:45] if that makes any sense [10:45] the UI itself seems on card0 with output "virtual0" [10:46] 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] 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] Hmm. Or do apps get away with just using render nodes? I'm not sure now [10:53] cpaelzer, one more tip before I log off. This will show you active monitors: grep . /sys/class/drm/*/enabled [10:53] grep . /sys/class/drm/*/enabled [10:54] or just: grep enabled /sys/class/drm/*/enabled [10:55] thanks [10:57] all seem enabled except a virtual port - I think that would only exist in a docking station, but that is fine [11:20] 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] Gnome bug 746422 in IP and DNS config "[CVE-2018-1000135] Unencrypted DNS queries leaked outside full-tunnel VPN" [Normal,Resolved: fixed] [11:20] ? [11:23] I would like to see that too, but will see what seb says [12:27] 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] 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] oSoMoN, wfm, we can also give it a solid round of testing once it's in proposed [13:55] oSoMoN, hit me up with the ppa and I will start testing [14:30] #startmeeting Desktop Team Weekly Meeting 2018-11-20 [14:30] 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] Available commands: action commands idea info link nick === meetingology changed the topic of #ubuntu-desktop to: Home of the Desktop Team, https://wiki.ubuntu.com/DesktopTeam | For help or questions, try #ubuntu | Work (read-only for non-developers): https://trello.com/b/RHiGQXZJ/ubuntu-desktop-1904-cycle | Amaterasu watches over you benevolently | Desktop Team Weekly Meeting 2018-11-20 | Current topic: [14:30] o/ [14:31] hey [14:31] o/ [14:31] Roll call: andyrock, dgadomski, didrocks, duflu (out), jbicha, jamesh (out), jibel, kenvandine, laney, oSoMoN, seb128, tkamppeter, trevinho, robert_ancell (out) [14:31] hey [14:31] 🐵/ [14:31] o/ [14:31] \o [14:31] * willcooke tries to remember how to do this [14:31] Lets review the rls bugs [14:32] Looks like everyone has updated their bugs (based on the hub post) [14:32] bb-incoming : http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html [14:32] nothing for us atm [14:33] rls-bb-tracking: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html [14:33] Everything is assigned [14:34] correction [14:34] L_aney assigned this to tjaalton https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1714178 [14:34] Ubuntu bug 1714178 in xorg-server (Ubuntu) "Triple 4K monitor display failed (modesetting driver limited to 8192x8192)" [Medium,Triaged] [14:35] and this: https://bugs.launchpad.net/amd/+bug/1770271 [14:35] Ubuntu bug 1770271 in mesa (Ubuntu Bionic) "VegaM support" [Undecided,New] [14:35] and this: https://bugs.launchpad.net/ubuntu/bionic/+source/mesa/+bug/1798597 [14:35] Ubuntu bug 1798597 in xorg-server (Ubuntu Bionic) "Backport packages for 18.04.2 HWE stack" [Undecided,New] [14:35] sounds good [14:36] cc incoming: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html [14:36] willcooke, on -bb you forgot https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1800135 [14:36] Ubuntu bug 1800135 in libssh (Ubuntu Bionic) "libssh-dev is missing cmake find module" [Undecided,Confirmed] [14:36] L_aney in his email recommends -notfixing [14:36] which I'm +1 with [14:37] ah, I didnt think that was one for us [14:37] ah, kk [14:37] it doesn't impact Ubuntu Desktop [14:37] yeah [14:37] +1 from me [14:37] let's do that then :) [14:37] looks like the tag is already gone [14:37] right, because it's nomination accepted [14:38] I wonder if rls-bb-notfixing works for those case? [14:38] I added it anyway [14:38] thx [14:38] cc-incoming: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html [14:39] https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1754693 [14:39] Ubuntu bug 1754693 in xorg-server (Ubuntu) "Xwayland/Xorg crashed with SIGSEGV in st_renderbuffer_delete() from _mesa_reference_renderbuffer_() [often when running Skype or Slack snaps]" [High,Confirmed] [14:39] IMO we should try and fix that one [14:39] +1 [14:39] but... it's wayland, so less important [14:39] hrm [14:39] I still think we need to, because it will be broken elsewhere [14:40] yeah, also it makes those snap not work as good [14:40] and wayland is default on some other distros [14:40] yeah [14:40] oki, +1 to fix [14:40] we need an assignee though [14:40] tjaalton, would you be able to take a look at it? ^ [14:40] tjaalton can you ... what will said :) [14:41] while we wait, https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1799293 [14:41] Ubuntu bug 1799293 in gnome-shell (Ubuntu) "gnome session: Must ask twice to lock the screen" [High,Confirmed] [14:41] +1 to accept the nomination [14:42] L_aney said it's pretty rare and edge-casey. I agree notfixing, but we work on it as time allows anyway [14:42] well it's a security issue if you close your laptop [14:42] and the lockscreen is no there when you re-open it [14:42] then dont enable auto login :) [14:42] I mean you suspend it [14:42] it's not only autologin [14:42] oh [14:43] ahhh [14:43] I'm pretty sure it has the same root case of dash-to-dock over lockscreen [14:43] this could be related to the problems that you were having jibel [14:43] at least in one varaint [14:43] andyrock, yeah [14:43] one of the comments mentions bg setting [14:43] I was going to say that [14:43] willcooke: okay [14:43] thank you tjaalton [14:43] andyrock, do you want to take on that? [14:43] the main variant of the dash-to-dock over lockscreen is that both are enabled [14:43] and I'm fixing it [14:44] +1 from me on nominating based on the fact that's it's screen failing to lock which is border security [14:44] in which case, thanks andyrock [14:44] than there is the other variant (and I think it shares the same main cause) [14:44] no idea what's the cause but it needs to be fixed [14:45] assigned it and targetted to C [14:45] it wouldnt let me target D [14:45] thx [14:45] and the next one is: http://launchpad.net/bugs/1769383 [14:45] Ubuntu bug 1769383 in gnome-shell-extension-ubuntu-dock (Ubuntu Disco) "Ubuntu dock/launcher is shown on the lock screen" [High,In progress] [14:45] which we covered above and is assigned [14:45] right [14:46] dd incoming: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html [14:46] I would target bionic for 1769383 too [14:47] andyrock, done [14:47] dd has the same bug as we already talked about [14:47] k, that's the end of the list I think [14:47] anyone want to talk about those before we move on to AOB [14:48] if they do, we can come back round again [14:48] #topic AOB === meetingology changed the topic of #ubuntu-desktop to: Home of the Desktop Team, https://wiki.ubuntu.com/DesktopTeam | For help or questions, try #ubuntu | Work (read-only for non-developers): https://trello.com/b/RHiGQXZJ/ubuntu-desktop-1904-cycle | Amaterasu watches over you benevolently | Desktop Team Weekly Meeting 2018-11-20 | Current topic: AOB [14:48] I remember there being a question from the hub [14:49] didrocks I think you suggested someone come and ask something, can you remember what? [14:49] yes, I don't remember the question though :p [14:49] I'll look [14:49] ah, it's something that clobrano already asked [14:49] IIRC [14:49] so, that's settled :) [14:50] in the meantime, do you think we will get the new d-2-d in D? With the window preview ordering "fixes"? [14:50] hey :D [14:50] hey clobrano :) [14:50] hey clobrano [14:50] unsure I have time currently with the installer work [14:50] hi willcooke , didrocks [14:50] so, probably in a quieter time, if no-one beats me to do the upload [14:50] didrocks, ack, thx [14:50] same for Yaru btw, would be need if someone cut a new release [14:51] nice* [14:51] nod [14:51] didrocks: what question? :) [14:51] clobrano: willcooke will have a look again [14:53] cant find it, I'll look it out after the meeting [14:53] anyone got anything else? [14:53] guess not. [14:53] #endmeeting === meetingology changed the topic of #ubuntu-desktop to: Home of the Desktop Team, https://wiki.ubuntu.com/DesktopTeam | For help or questions, try #ubuntu | Work (read-only for non-developers): https://trello.com/b/RHiGQXZJ/ubuntu-desktop-1904-cycle | Amaterasu watches over you benevolently [14:53] Meeting ended Tue Nov 20 14:53:50 2018 UTC. [14:53] Minutes: http://ubottu.com/meetingology/logs/ubuntu-desktop/2018/ubuntu-desktop.2018-11-20-14.30.moin.txt [14:53] thanks all [14:53] thanks [14:54] Ah, I found it - but it was from 5 months ago, and someone just replied now :) [14:54] so ignore me [14:55] thx [14:56] sorry, I missed the chance to update you on nvidia [14:56] thx [14:56] tseliot, np, now is good [14:56] tseliot, you can still do now :) [14:56] 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] nice! [14:56] thx [14:56] the new nvidia is still in NEW, so it might take a while [14:57] that's all I have [14:57] thanks tseliot [14:57] :) [15:29] added: rls-cc-tracking [15:29] 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:32] Ubuntu bug 1754693 in xorg-server (Ubuntu) "Xwayland/Xorg crashed with SIGSEGV in st_renderbuffer_delete() from _mesa_reference_renderbuffer_() [often when running Skype or Slack snaps]" [High,Confirmed] [15:40] thanks Laney [15:40] anything for #ubuntu-desktop 😘 [16:04] didrocks: https://github.com/micheleg/dash-to-dock/pull/843 [16:04] micheleg issue (Pull request) 843 in dash-to-dock " extension: Ensure signal disconnection " [Open] [16:04] could you take a look? [16:25] andyrock: will do tomorrow morning. Still in installer build [16:25] kk [17:18] 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] thanks oSoMoN, I will install it tomorrow and report back [17:20] or not [17:20] depending :) [17:21] :) === pstolowski is now known as pstolowski|afk [17:36] * oSoMoN calls it a day [17:36] have a good evening everyone [18:01] dinner time, night all [18:46] I <3 the update posts on discourse. Especially all the lovely icons and emoji! :D [21:26] seb128: still here? do you mind creating the ubuntu/cosmic branch for gnome-control-center ? [21:26] I want to prepare the SRU [21:54] andyrock, k, I can do that [22:01] andyrock, k, done, I created it from the 1:3.30.1-1ubuntu2 tag which is the current cosmic version [22:02] on that note, calling it a day, night desktopers [22:39] 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] 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] RAOF, the fix caused another issue so was abandoned. So it shouldn't be considered part of the SRU anymore. [22:51] Ok, there's something weird with that SRU. [23:18] robert_ancell: Aaah! I think someone accidentally accepted it into -proposed without a complete .changes list. [23:19] RAOF, yeah, I think I missed the -v when building the source package [23:19] Or maybe not? I'm not entirely sure how to read this launchpad output. [23:20] So it is in proposed, but I wonder if the bug being marked red means it will stay there [23:20] robert_ancell: Right, which is why the bug tracking is screwy. [23:20] robert_ancell: And why it hasn't actually been verified. [23:20] 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] RAOF, ok, I'll chase up the verifiers to reconfirm. [23:24] 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] RAOF, can I re-use the .7 version? [23:25] Nope, it'd need to be .8 [23:25] *sigh* [23:25] Launchpad has seen the .7 version, and what Launchpad sees cannot be unseen! [23:25] RAOF, so would you like me to do that then? [23:26] I think that would be simplest, yes. Please do so. [23:26] And the .changes should have changes from .5 .6 .7 and .8 in it right? [23:26] Correct. Everything since the current version in -updates [23:30] That will leave #1754864 incorrectly marked as fixed, I think, but I'll manually fix the status post-acceptance. [23:32] RAOF, uploaded [23:35] Ta. RAOF [23:42] Sorry about the faffing.