[04:55] <jibel> good morning
[04:55] <duflu> Morning jibel
[04:55] <duflu> Happy release day
[04:56] <duflu> Wait, no, tomorrow
[04:56] <duflu> Meh, it will still be the 18th when it's the 19th here :)
[04:59] <jibel> yes, 1 day to go.
[04:59] <jibel> and another release
[05:00] <jibel> that will be my 16th release
[05:00] <jibel> not counting phone OTAs
[05:04] <duflu> That's pretty unusual in the software world. In other circles you'd actually code freeze 6 months before release :)
[05:06] <duflu> By which I mean there would not be 2+ releases each year. Although it's mathematically possible with overlaps
[05:09] <jibel> what about the phone where we released 15 OTA in 2 years. Pretty short freezes
[05:16] <duflu> Prepare for the bug report spike
[06:01] <oSoMoN> good morning desktoppers
[06:12] <duflu> Morning oSoMoN
[06:14] <oSoMoN> hey duflu, how are things?
[06:14] <duflu> oSoMoN, things are OK. How about you?
[06:16] <oSoMoN> duflu, I'm doing good
[06:21] <duflu> Trevinho, hey remind me how/why mutter logs nothing by default?
[06:21] <duflu> I used to know this
[06:21] <Trevinho> duflu: hey
[06:22] <Trevinho> duflu: not reason... but you can enable the debugging flag at compile time also if you need more
[06:22] <duflu> Ah
[06:22] <duflu> Thanks Trevinho
[06:22] <duflu> That was nonobvious
[06:22] <oSoMoN> hey Trevinho
[06:23] <Trevinho> hi oSoMoN
[06:23] <Trevinho> good morning :)
[06:24] <Trevinho> duflu: it should be just --enable-debug iirc
[06:25] <duflu> That's a bit weird. You don't know you need the log until after an error happens. So disabling logging by default assumes you can always run it twice and reproduce an issue
[06:26] <Trevinho> duflu: it also depends the flag is for debugging log
[06:27] <Trevinho> for the rest just use the classic G_DEBUG or G_MESSAGES_DEBUG (=all) vars
[06:29] <didrocks> good morning
[06:30] <oSoMoN> salut didrocks
[06:31] <didrocks> ça va oSoMoN ?
[06:31] <oSoMoN> bien, et toi?
[06:31] <oSoMoN> Martin va mieux?
[06:32] <didrocks> il tousse encore, mais plus de fièvre…
[06:32] <didrocks> par contre, quinte de toux la nuit, donc niveau repos pour lui, bof
[06:35] <seb128> good morning desktopers
[06:36] <seb128> didrocks, oSoMoN, salut les frenchies
[06:36] <didrocks> salut seb128 !
[06:36] <flexiondotorg> Bonjour
[06:37] <seb128> oSoMoN, désolé j'ai vu ton msg hier soir en passant avant le diner et j'ai oublié de faire le sponsoring après, j'y ai repensé qu'une fois au lot
[06:37] <seb128> lit
[06:37] <seb128> je fais ça dans un moment (si personne ne s'en est occupé entre temps)
[06:37] <seb128> hey flexiondotorg
[06:37] <didrocks> bonjour flexiondotorg !
[06:39] <flexiondotorg> Sur le train. Aller au bureau de Londres.
[06:39] <didrocks> flexiondotorg: tu arrives à quelle heure ?
[06:40] <flexiondotorg> 8:30
[06:45] <flocculant> flexiondotorg: you're brave believing the train efficiency :D
[06:48] <flexiondotorg> It's supposed to arrive at 8:15, I've automatically given the commuter adjusted arrival time😉
[06:48] <flocculant> ha ha ha
[06:50] <didrocks> ;)
[07:22] <jibel> didrocks, any progress with debugging bug 1723577?
[07:22] <jibel> bonjour :)
[07:26] <didrocks> jibel: no, we did a lot of reverts, but still nothing. Here is syslogs with gdm in debug mode: https://launchpadlibrarian.net/341191466/Syslog3
[07:27] <didrocks> got a 3rd person complaining about his config not working (but he didn't detail his GPU)
[07:28] <didrocks> Oct 17 13:13:19 valeryan24-desktop gnome-shell[1206]: Failed to use linear monitor configuration: Invalid mode 775501120x892744761 (0,000001) for monitor 'ACI ASUS VW220'
[07:28] <didrocks> Oct 17 13:13:19 valeryan24-desktop gnome-shell[1206]: Failed to use fallback monitor configuration: Invalid mode 775501120x892744761 (0,000001) for monitor 'ACI ASUS VW220'
[07:28] <didrocks> is the only thing that could impact, maybe?
[07:29] <didrocks> jibel: we don't have any iso from the 5th or 6th, correct?
[07:30] <didrocks> we could go the other way, getting them booting an older iso and upgrading pieces by pieces
[07:31] <jibel> didrocks, we don't
[07:32] <jibel> didrocks, we do have the beta but it's more than a week older
[07:32] <didrocks> jibel: hum, maybe we can start from there… Better than nothing…
[07:33] <didrocks> apart from this monitor configuration, I don't see anything else wrong
[07:33] <didrocks> jibel: do you mind double checking if you spot anything in the debug gdm logs? ^
[07:33] <jibel> didrocks, yes
[07:33] <didrocks> it sounds like we are launching the gdm user session successfully
[07:33] <didrocks> going through the phases
[07:33] <didrocks> without any warning/errors
[07:34] <didrocks> Oct 17 13:13:21 valeryan24-desktop gnome-session-binary[1198]: DEBUG(+): GsmManager: starting phase WINDOW_MANAGER
[07:34] <didrocks> Oct 17 13:13:21 valeryan24-desktop gnome-session-binary[1198]: DEBUG(+): GsmManager: ending phase WINDOW_MANAGER
[07:34] <didrocks> -> this is where gnome-shell is launched
[07:34] <didrocks> (actually Oct 17 13:13:19 valeryan24-desktop /usr/lib/gdm3/gdm-wayland-session[1194]: gnome-session-binary[1198]: DEBUG(+): GsmManager: Phase DISPLAY_SERVER
[07:35] <didrocks> in gdm)
[07:45] <oSoMoN> seb128, looks like nobody did it yet
[07:46] <seb128> oSoMoN, good, I'm doing it now
[07:46] <oSoMoN> thanks!
[07:47] <seb128> yw!
[07:57] <willcooke> morning
[07:57] <oSoMoN> good morning willcooke
[07:57] <seb128> good morning willcooke
[07:58] <oSoMoN> seb128, I’ve updated the bug description (bug #1718446) to make it SRUable, do I need to subscribe ubuntu-sponsors?
[07:58] <seb128> oSoMoN, no, I'm handling that part
[07:59] <willcooke> duflu, seb128 - no BT meeting today
[07:59] <seb128> willcooke, oh, less meeting, good :)
[07:59] <willcooke> \o/
[07:59] <duflu> willcooke, OK. My mutter work thanks you. Predictably fixing one thing reveals more problems
[07:59] <oSoMoN> seb128, that's what I thought, thanks
[08:01] <didrocks> hey willcooke
[08:01] <Laney> morning!
[08:04] <didrocks> morning Laney
[08:10] <seb128> hey Laney
[08:12] <Laney> hey didrocks hey seb128
[08:12] <Laney> anything new?
[08:13] <didrocks> not much, didn't get yet to the bottom of the ATI bug, a little bit worried about that one
[08:13] <didrocks> (don't know how much widespread it is)
[08:24] <seb128> is anyone in the having an amd graphic machine?
[08:24] <duflu> seb128, I can make my dev machine into AMD easily but I've adopted too many bugs for the moment
[08:25] <seb128> duflu, k
[08:25] <duflu> It's probably advisable anyone ever working on the shell has some AMD and NVIDIA hardware at home
[08:25] <duflu> Even when I was working on Mir, often I was the only one who could test things
[08:27] <duflu> where things are Nvidia and AMD
[08:27] <seb128> yeah, we should probably expense some machines for that
[08:31] <Laney> is it possible to access things in the taipei lab graphically?
[08:32] <jibel> we do have access to nvidia and amd machines in the lab but not graphically
[08:32] <Laney> mmm
[08:33] <Laney> sounds like you can't tell from logs that it's broken for this bug?
[08:33] <jibel> no, I've been reading the logs but there is nothing obvious
[08:41] <didrocks> Laney: which is one of the issue
[08:41] <didrocks> ok, I requested more env variables to print mutter/wayland more debugs
[08:41] <didrocks> the only potential issue in syslogs is:
[08:41] <didrocks> Oct 17 13:13:19 valeryan24-desktop gnome-shell[1206]: Failed to use linear monitor configuration: Invalid
[08:41] <didrocks> mode 775501120x892744761 (0,000001) for monitor 'ACI ASUS VW220'
[08:42] <seb128> jamesh, hey
[08:42] <jamesh> seb128: hi
[08:42] <seb128> jamesh, could you have a look at bug #1724316 please?
[08:43] <jamesh> sure
[08:43] <seb128> jamesh, you might know if there is a way to re-enter credentials from the UI? or does one need to use the command line?
[08:43] <seb128> thanks
[08:43] <jamesh> seb128: gnome-software doesn't share credentials with the command line tool
[08:43] <seb128> jamesh, my artful is having the issue if some debug info or state details would be useful
[08:49] <liuxg> when I run a command inside a container like "ssh root@$IPADDR lxc-attach -P /usr/lib/lm_containers -n ivi -- ls *.rpm", it complains "ls: *.rpm: No such file or directory". does it mean that I cannot use * inside the command? If I remove the *, it runs well. what should I do? thanks
[08:51] <jamesh> seb128: I assume you'd previously entered U1 credentials into gnome-software?
[08:53] <seb128> jamesh, I guess I did? I installed that machine early in the cycle and don't remember the details of what I did
[09:12] <seb128> oSoMoN, k, gnome-session/gdm changes merged & uploaded, the SRU bug description looks good as well, thanks
[09:20] <oSoMoN> seb128, cheers
[09:51] <jamesh> seb128: still investigating, but I suspect the problem is in libsnapd-glib or snapd itself
[09:51] <jamesh> (added some intermediate info to the bug)
[10:08] <willcooke> didrocks, I just realised we're not adding the LibreOffice icons to the launcher by default, I /think/ we used to have them there.  Any reason either way?
[10:10] <didrocks> willcooke: we reviewed and discussed that at the fit and finish sprint: the decision we took was keeping ubuntu GNOME default list + adding amazon.
[10:10] <willcooke> :) thanks didrocks
[10:10] <didrocks> can be revisited for LTS ;)
[10:11] <didrocks> funny, we still have evolution.desktop in it
[10:11] <didrocks> should be cleaned up :p
[10:11] <didrocks> (and adding thunderbird, probably)
[10:11] <willcooke> I've added a card to the backlog to review
[10:13] <didrocks> thx!
[10:33] <didrocks> Last post of the cycle, Day 16 is out :)
[10:41] <willcooke> congrats ddi
[10:41] <willcooke> didrocks,
[11:58] <seb128> jamesh, thanks
[12:45] <tkamppeter> seb128, did you already have a look into the gvfs-mtp log file?
[12:46] <seb128> tkamppeter, yeah, but I'm a bit unclear what issues you have, the file copy was different from the other segfault right? did you report the copy one with apport? what was the backtrace?
[12:48] <tkamppeter> seb128, The apport crash reports are all of some plug/unplug/unlock event as an apport crash report did not happen yesyerday and only yesterday I tried to transfer files.
[12:48] <seb128> tkamppeter, what error did you get when trying to copy files then?
[12:48] <seb128> did it work under valgrind the copy?
[12:49] <tkamppeter> seb128, yesterday I only had that different valgrind apport report.
[12:54] <tkamppeter> Under Valgrind the copy also did not work. I get "Error transferring track, Could not open resource for writing.".
[12:55] <tkamppeter> seb128, ^^
[13:06] <seb128> tkamppeter, could you report that bug on bugzilla against gvfs mtp backend? include your device reference since it might be specific to it
[13:18] <seb128> detail but it looks like the "install third party software" installer option is not showing translated in french?
[14:05] <seb128> andyrock, you are assigning me bugs now? :)
[14:05] <andyrock> seb128: ahah I saw you proposed the patch upstream
[14:06] <seb128> :-)
[14:06] <seb128> thanks
[14:15] <willcooke> didrocks, cyphermox might have the right machine!
[14:15] <willcooke> Kernel driver in use: radeon
[14:15] <willcooke> Kernel modules: radeon, amdgpu
[14:15] <willcooke> cyphermox might be able to save the day again :)
[14:16] <willcooke> seb128,, jibel - FYI since you're in the loop ^
[14:16] <seb128> willcooke, upstream #gnome-shell has an idea of a problem in the code that could explain it
[14:16] <willcooke> ah nice
[14:17] <rbasak> I don't think I can help, but for future reference, I have an MSI R7 370: http://paste.ubuntu.com/25766124/
[14:17] <rbasak> I don't think it uses amdgpu though, and I won't be near this particular machine for a month or two :-/
[14:17] <seb128> rbasak, thanks
[14:17] <willcooke> thanks rbasak, good to know
[14:20] <didrocks> ok, so…
[14:20] <didrocks> should we revert the headless commits?
[14:21] <didrocks> which is what the user tried?
[14:21] <didrocks> and both seb & I tried those reverts to ensure that the Shell still starts?
[14:22] <willcooke> didrocks, I'd like to test the resume/suspend cycles as well
[14:22] <willcooke> can I install it?
[14:24] <didrocks> willcooke: sure, https://launchpad.net/~didrocks/+archive/ubuntu/ppa/+build/13591531
[14:24] <didrocks> install the 2 debs
[14:24] <didrocks> reboot
[14:25] <didrocks> willcooke: there shouldn't be any impact on resume/suspend, the commits aren't reverted or linked
[14:26] <willcooke> thanks didrocks, worth testing all the same
[14:26] <didrocks> yep :)
[14:26] <didrocks> willcooke: I'm preparing the real upload meanwhile
[14:26] <seb128> didrocks, you prefer reverting now than giving upstream let's say half an hour to suggest a fix?
[14:26] <didrocks> seb128: I'm away in half an hour and unsure the guy will be able to test the fix
[14:26] <didrocks> but if you handle it with the community guy, sure
[14:27] <seb128> well I was asking what you think is best if we ignore logistic
[14:27] <seb128> then we can see if logistic works so we can do what is best
[14:27] <seb128> or if we do plan B
[14:27] <didrocks> I'm unsure this headless mode really gives us anything for this release
[14:27] <didrocks> but if you feel it's important to us
[14:28] <seb128> no, but the #gnome-shell log suggests that before its change gnome-shell was segfaulting
[14:28] <didrocks> I would personnally go for a revert and proper fix as an SRU
[14:28] <seb128> that was sending users back to fallback
[14:28] <seb128> and I'm wondering if the segfault means apport prompts etc
[14:28] <didrocks> yeah, but at least, they are on xorg
[14:28] <seb128> right
[14:28] <seb128> due to timeline constrains I think I would agree with the revert
[14:29] <seb128> willcooke, Laney, others, ^ opinion?
[14:29] <Laney> ask Jonas what he thinks about that, but seems ok
[14:29] <willcooke> I think we should probably get things ship-shape before EOD.  So I'm +1 and then we can always SRU something tomorrow
[14:29] <didrocks> (only the gdm user gnome-shell is segfaulting AFAIK)
[14:29] <seb128> Laney, you should be on #gnome-shell :p
[14:29] <Laney> I am
[14:29] <seb128> oh, you are
[14:29] <seb128> ask then :)
[14:30] <Laney> :/
[14:30] <seb128> well anyway they asked for more info
[14:30] <seb128> it just takes roundtrip through contributor on forum
[14:30] <seb128> so it might take a while
[14:31] <willcooke> I'm happy with suspend here
[14:36] <tkamppeter> seb128, https://bugzilla.gnome.org/show_bug.cgi?id=789150
[14:37] <seb128> tkamppeter, thanks
[14:39] <andyrock> seb128: hey I proposed a fix for a crash we had in gnome-control-center when adding google accounts
[14:39] <andyrock> the fix is in gtk
[14:39] <andyrock> https://bugzilla.gnome.org/show_bug.cgi?id=789141
[14:39] <seb128> andyrock, I saw, thanks
[14:39] <andyrock> there was a first review
[14:39] <andyrock> seb128: you see everything
[14:39] <andyrock> :D
[14:39] <seb128> right
[14:39] <seb128> lol
[14:40] <andyrock> we might want to SRU the fix
[14:42] <seb128> yes
[14:42] <seb128> let's wait to get it reviewed another time, the first review was ebassi doing stylistic comments
[14:57] <cyphermox> seb128: willcooke: fwiw, wayland starts fine here.
[14:58] <willcooke> thanks cyphermox
[14:58] <willcooke> So we're dealing with a fairly narrow case then
[14:59] <seb128> we have a revert upload and it looks like upstream understands the issue and is working on a fix as well
[15:15] <cyphermox> willcooke: maybe I spoke too fast
[15:16] <cyphermox> not sure what's going on but I couldn't get back to my session again after screensaver started
[15:16] <cyphermox> I will lock my screen again now.
[15:17] <cyphermox> worked this time, I'll let you know / file a bug when I hit the same issue again
[15:36] <sil2100> Could you guys also give gnome-shell from artful-proposed some testing?
[16:33] <jbicha> didrocks: hi, I haven't read all the details about the ati stuff you were working on today, but…
[16:33] <jibel> sil2100, I can install on a test machine and do a quick check
[16:34] <jbicha> I used to have problems with some time my computer hanging on wake from suspend that I believe was fixed by the headless fixes
[16:34] <jibel> but it's an intel
[16:35] <jbicha> not loading at all is worse than having problems waking up, I'm just pointing out the potential downside :|
[16:37] <jibel> jbicha, can you help testing gnome-shell in proposed then and tell how bad are the wake up issues
[16:37] <jibel> ?
[16:39] <willcooke> jbicha, I /think/ that wake up issue was different.  proposed working fine here on Intel
[16:52] <jibel> sil2100, gnome-shell from proposed looks fine
[16:55] <sil2100> \o/
[16:56] <jbicha> sil2100: I'm going to test gnome-shell too in a minute
[17:07] <jbicha> I'm not able to duplicate the wake-on-suspend hang here. I think it'll take me an hour or so to test on the computer that had the problem until last week
[17:08] <jbicha> sil2100: didrocks ^
[17:09] <didrocks> good :)
[17:09] <sil2100> jbicha: thanks!
[17:09] <sil2100> I think it got enough testing so it's now migrating to the release pocket
[17:22] <v3n0m> very slow boot time of Ubuntu 17.10
[17:35] <didrocks> willcooke: It's nice to see that that the fix worked for smb (at least 4 persons in the limited testing, I guess it worthed it)
[17:35] <willcooke> neat!  I saw he said that it was broken, I didnt know it worked for him, so that is good news indeed
[17:35] <willcooke> nice work didrocks
[17:38] <didrocks> thx!
[17:38]  * didrocks really off now
[17:38] <willcooke> night didrocks
[17:38] <didrocks> night!
[17:38] <oSoMoN> night all
[17:51] <jbicha> ok, I tried 10 times and wasn't able to reproduce the hang on suspend with gnome-shell .26.1-0ubuntu4
[17:51] <willcooke> \o/
[17:52] <jbicha> I think my issue was fixed by last week's mutter uploads
[17:53] <willcooke> cool, I hoped that would be the case
[17:53] <jbicha> maybe even 3.26.1-2ubuntu1
[17:59] <willcooke> gonna call it a day, seems like everything is good to go.
[18:00] <willcooke> I'll be on telegram if needed, but otherwise catch you in the morning
[18:52] <ignoo> Hello,running ubuntu GNOME 16.04, have some issues with ubuntu Artful Aardvark: https://pastebin.com/BgBHExes ; Thank you for your Support.
[18:52] <jbicha> ignoo: thanks, but go away
[20:50] <vithiri> Does anyone else notice the battery status indicator always being at 100% in 17.10 currently? If I click it, the correct percentage will be displayed in the drop down menu.
[20:58] <jbicha> vithiri: I don't think it always shows 100%, but take a look at https://github.com/system76/pop-distro/issues/44
[21:01] <vithiri> jbicha: Hmm. Interesting. Thanks for the link.
[21:02] <vithiri> jbicha: I didn't let it drop below 60%, so I can't confirm if it's the same issue now. But I'll keep an eye on it.
[21:52] <jackpot51> I would like to thank everyone on a great Artful release!
[22:01] <vithiri> jackpot51: Is it already relesed or are we just celebrating CET+1 midnight? :)
[22:02] <dmj_s76> jbicha: Are you blocking on https://bugzilla.gnome.org/show_bug.cgi?id=788493 atm?
[22:03] <jbicha> no, but if we're going to a mutter SRU, we might as well include the fixes for that too
[22:03] <jbicha> since an SRU can take a week or two before it's published to -updates for all users
[22:04] <dmj_s76> do you know of any regressions with the patches for this bug?  I haven't looked very closely at it yet.
[22:04] <jbicha> I've not heard any reported yet
[22:05] <jbicha> I thought since I believe gaming performance is a priority for System76, you might want to work on filing the LP bug we need for tracking that fix
[22:06] <jackpot51> vithiri: I am celebrating the current version of Artful. The release will probably be the current set of packages in the release archive
[22:07] <jackpot51> Unless there are outstanding issues to fix
[22:07] <vithiri> jackpot51: Ah, yes. Based on using it for the past month, I'd say celebrating it sounds like a reasonable approach.
[22:13] <dmj_s76> Proper vsync (including gsync) behavior is definitely important to us.  We have some gaming customers though it's a minority of nvidia customers actually.
[22:14] <dmj_s76> jbicha: Might need to think more carefully about the vsync patch since it's claimed to cause tearing on videos in firefox.
[22:15] <dmj_s76> We definitely will get support calls about that.
[22:17] <dmj_s76> Previously the equivalent compiz plugin had an override to control fullscreen unredirection for windows of certain applications.
[22:18] <jbicha> comment 48 says there's a GNOME Shell extension you can have them install
[22:19] <jbicha> the behavior in mutter 3.26.1 was a regression from previous GNOME versions, I believe we want the behavior in 3.26.2
[22:20] <jbicha> it sounds like the problem is that Firefox doesn't enable hw acceleration by default on Linux ?
[22:44] <dmj_s76> jbicha: yeah, I think the right thing here is to allow unredirection&tearing if that's what the fullscreen app wants, but provide a mechanism to automatically override this for apps where tearing is an obviously wrong thing.
[22:57] <dmj_s76> Not to be ornery...will try to dig deeper and do some testing tomorrow :)
[22:58] <jbicha> no problem, I appreciate the help :)
[23:39] <vithiri> jbicha: I've let it run down to 52% now, and while the experience isn't great since the icon shows ~75% it seems to be by design.