[05:46] good morning [05:47] salut didrocks [05:54] ça va jibel ? [05:56] lut didrocks, matinal ce matin :) [05:57] good morning desktopers [05:57] seb128: comme tous les vendredi où je ne m'occupe pas de Martin [05:57] ;) [05:57] ah, ok :) [05:57] happy friday! [05:57] joyeux vendredi également [05:58] * didrocks already reponsded to user's "requiring" some "evident" work [05:58] redirected to my blog post explaining why we didn't do this + the hub for the rest [05:58] could be good documentation for the future [06:01] salut seb128 [06:01] cava didrocks et toi? [06:01] lut jibel! [06:04] ça va [06:36] Morning desktopers o/ [06:37] Morning didrocks, jibel, seb128, Wimpress [06:37] duflu: Morning o/ [06:37] Ages ago I brought up an issue of DRI3 not working. [06:38] We discussed it on the Ubuntu Discourse. [06:38] Yeah I saw that yesterday [06:38] I was barking up the wrong tree :-) [06:38] Finally found the fix :-D [06:38] Odd (but now I have seen that part of the Xorg source), makes sense [06:38] Wow, that was bad [06:38] Odd but now I have seen that part of the Xorg source it makes sense [06:39] Wimpress, in recent months I finally also learned how Xorg manages to tear at all even when the Intel kernel driver now forbids it [06:40] The answer was: by being dodgy [06:49] Wimpress, I find it both exciting and scary to think what kind of difference that fix could make to existing distros [06:49] -distros +releases [07:01] good morning desktoppers, happy Friday! [07:03] lut oSoMoN, happy friday! how is it going? [07:03] seb128, a bit tired as nights have been short this week, but I'm hoping for a productive day to close the week. you? [07:04] I'm good, a bit tired as well but it's friday so it's alright :) === pstolowski|afk is now known as pstolowski [07:59] morning [08:01] morning [08:02] hi de hi [08:07] Today's drama.. one of the LED spot lights in the kitchen has gone. It can't be more than a year old, but of course no receipt. These things cost a couple of quid, are full of plastic and extra components, cost about 3 quid each if you buy in bulk, and don't last more than a year. What a waste [08:08] Morning willcooke, marcustomlinson and Laney [08:08] hi duflu [08:08] willcooke, yeah I found some LED globes die quick but on average they last longer than the alternatives [08:08] yeah, I suppose one going isnt really a fair sample [08:10] hey willcooke marcustomlinson Laney, how is u.k today? [08:10] Which reminds me, I replaced a headlight on the car last weekend and found LED options for those. Might be interesting to try one day [08:11] seb128: still european [08:11] that's good :) [08:11] woo? [08:11] so good yeah [08:11] XD [08:12] morening duflu marcustomlinson willcooke seb128 [08:12] duflu, I seem to remember there being something about replacing headlights with LEDs causing odd electrical problems. That might have been indicators though - where the bulb itself was part of the timing flasher timing circuit [08:12] i'll be negative [08:12] it's GREY and BLOODY COLD [08:12] STILL [08:12] Sun is shining here :) [08:12] blow it up this way pls [08:12] * willcooke opens the window and puffs [08:12] also [08:12] ah you blew it too far, now we have it in Edinburgh [08:12] :) [08:13] * willcooke sucks [08:13] our Currys PC World thing in town takes light bulbs for recycling [08:13] and most other electronic stuff [08:13] worth knowing [08:13] ooh, I bet the tip do as well. I've got a load of glass to take, I will try that [08:14] annoying bit is when you replace it and the new one is a slightly different colour temperature [08:14] yes! [08:17] https://programmes.files.bbci.co.uk/programmes-frontend/images/error/500-3dc2a62f76.gif [08:17] BBC's error 500 page has that image :D [08:17] \o/ [09:12] https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/230196/comments/10 [09:12] Ubuntu bug 230196 in openoffice.org (Ubuntu) "[upstream] OpenOffice quickstarted shouldn't have a notification icon" [Wishlist,Won't fix] [09:12] how do we deal with that? ^ [09:14] marcustomlinson: file a new question on https://answers.launchpad.net/launchpad with a link [09:15] holy sh** [09:16] it's coming in fast [09:19] lots of different bugs getting spammed? [09:19] yeah [09:19] https://bugs.launchpad.net/~klfbfdlkfnf/+commentedbugs [09:19] https://answers.launchpad.net/~klfbfdlkfnf [09:19] ah, so same user? [09:20] yeah [09:20] Lets see if the snap store team can help [09:20] ?!?! [09:20] #launchpad if anything [09:21] they're pretty experienced with spam fighting [09:22] talking in #launchpad-ops on the Canonical IRC server [09:23] ah ok [09:23] and fwiw, the snap store team and the launchpad team are the same people [09:26] subset isn't it? [09:28] I was trying to give advice that didn't require an employment contract with Canonical [09:28] thanks though [09:28] (and the first route I gave doesn't interrupt anyone; that's why I always go there in the first instance) [09:29] Well people on #launchpad know it's being looked at too [09:29] thx [09:32] good advice, thanks Laney [09:32] yes thanks Laney and willcooke :) [09:37] yeah, usually filing a question on launchpad is acted upon quickly, in my experience [09:40] ye [09:41] right, there already were multiple questions regarding that spammer. I saw it coming in fast so thought perhaps there was a quicker way to get people aware [10:17] Bon weekend all [10:17] and mothers in particular [10:23] tkamppeter, hey! are you looking at that n-m autopkgtest failure on bionic? [10:32] tkamppeter, I suspect simply adding the allow-stderr restriction to the nm test would do the trick. the failure is triggered by the PyGIWarning being printed on stderr, not by it being an actual error [10:34] oSoMoN, I am not much experienced with autopkg tests as it rarelyhappened to me that they failed on a package. Where needs the allow-stderr be applied? [10:35] oSoMoN, and for which Ubuntu releases? [10:38] Wouldn't it be better to fix the actual stderr output it's printing? [10:38] That's just a gi.require_version() that's already in later releases [10:40] Laney, yeah, that's probably a better fix [10:41] I just ran that test in a bionic VM and it actually passes, so it's just the import warning being printed on stderr [10:41] nod [10:43] * Laney stabs 'git rebase -i' destroying merge commits [10:46] BUT! TIL that you can use 'git rebase -i' to generate *new* merge commits [10:46] like if you accidentally end up fixing a side issue, you can generate a branch for that using rebase -i [10:46] what a world we live in [10:47] tkamppeter, http://paste.ubuntu.com/p/9Hpsw3Fbhp/ should do the trick [10:50] ♥ [10:54] OK, thanks. [10:54] . O O ( wonder why pygobject started printing that message just now ) [10:55] It is probably only needed for Bionic. Is there a Bionic SRU bug report (with SRU in -proposed) where one can add this to the SRU and re-upload? [10:56] Laney, can it be that there was also some update on Python or pygobject which caused this? [10:56] tkamppeter: Not pygobject, but I'm not about to spend any time investigating what else it is - the fix is clearly right anyway. :-) [10:57] It could be that something else was importing those things and stopped doing it, so now the test is being blamed directly [10:57] and I'd say you can probably get away without an explicit SRU bug for this change if you explain it in the changelog [10:57] Laney, OK. I also would not search for another place to fix. Let us simply apply this fix to get the SRUs on NM and MM through. [11:03] Trevinho: done, merci! [11:06] tkamppeter, Laney, while we should fix it I wonder if that would make sense to ask the SRU team to unblock the current one by skipping the test to avoid having to do another round of verification on the new build and delay even more the SRU [11:08] note that this is not blocking only n-m, the kernel 4.15.0.49.51 SRU is also blocked by this [11:08] I think having a functional test is valuable. If it's red then you will probably not notice if it gets even more red. [11:09] If you want to argue with someone then I'd suggest making the argument based on the only changes between the previous upload and this one being a test fix. [11:09] seb128, that would really be a good idea. How to do it? In one of the two SRU bugs (nm, mm)? In both? By e-mail? IRC channel (which one)? [11:09] tkamppeter, you can ask the SRU team for their opinion [11:09] fine [11:09] maybe they are happy accepting a new upload which only change that [11:10] without requesting a new testing period reset to 0 and full testing [11:10] but then we might got bitten by any compiler/whatever issue than would create a problem in a new rebuild [11:10] but that's probably not likely [11:10] But where to ask? IRC? e-mail? one of the bugs? [11:11] you can try ask the SRU reviewer of the day [11:11] seb128, who is that? Where do I find who that is? [11:11] according to https://wiki.ubuntu.com/StableReleaseUpdates#Publishing it's tjaalton and vorlon today [11:12] tkamppeter, are you new around? ;) [11:12] It's not going to be released today anyway. [11:12] seb128, what do you mean with that? [11:12] Try to get the fix accepted today, and argue for a reduced (over the weekend) validation period. [11:13] Laney, do a proper round of testing on that update with the split vpn etc is non trivial work [11:13] seb128: Did you read what I said previously? [11:13] so depends if we are wanting to do that/if they are fine skipping full testing [11:13] Laney, yes, did you read what I wrote? ;) [11:14] OK, well I'm not sure why you'd talk about full validation when I was saying that you should try to get that waived. [11:14] tkamppeter, nothing, I though you had been around for long enough that you would know who is on the SRU team and where is the wiki :) [11:15] seb128, perhaps I did not run in such a situation before. [11:15] Laney, you mentioned the period, not what was being tested. Anyway I think we both are in agreement so not point making it sound like we are arguing [11:15] "we should ask the SRU team if they are fine doing a light handling of an upload with that change" [11:15] I think we both agree on that? [11:15] Right, OK then. [11:16] :-) [11:16] I want you to agree with me on the value of having tests be green too pelase [11:16] please [11:16] you probably do, but I want to be sure :> [11:16] yes I do [11:16] OK, then we can push the SRU team on this point of view [11:16] I would prefer for that SRU to go in without too much extra delay AND fix the test [11:17] yep [11:17] though it makes me a bit nervous to SRU a key component without a full testing round, but the chance we got bitten by toolchain/build issues is low [11:17] I mean there's SRUs going through all the time [11:17] if the toolchain is producing broken stuff then ... [11:18] yeah, probably just me being too paranoid [11:19] tkamppeter, get an upload with the test fix in the queue and ask the SRU team/ping tjaalton and vorlon on #ubuntu-release asking if that can be added to the current one without resetting the testing done [11:23] I am already asking them on ubuntu-devel. [11:24] seb128, I do not have upload rights for nm. The maximum I could do there is preparing a debdiff. [11:24] I'll sponsor it, no worries [11:26] tjaal_ton tells on ubuntu-devel that it is OK. We can simply fix the test and re-upload. [11:27] no re-testing needed. [11:27] what good guys [11:27] for sponsoring, a git branch would be a bit easier than a debdiff [11:41] Laney, the debdiff: https://paste.ubuntu.com/p/q5MSdT3nW9/ [11:43] cheers [11:43] Laney, sorry, did not see your last lines, was probably already off for starting to prepare the debdiff. [11:44] don't worry about it, I'll make it look like you committed it anyway ;-) [11:45] OK, thanks for sponsoring. Hope the SRU queue get cleaned soon then. [11:45] we can ping Timo once it's uploaded [11:46] OK. [11:51] * Laney is running the tests [12:10] fail [12:11] https://git.launchpad.net/network-manager/commit/?id=69675f0aa771475754428700976e960d91031df5 this is needed [12:15] Thanks Past Laney [12:25] ha [12:49] Laney, your upload of nm for Bionic is "waiting for approval" (got mail notification), did you already inform Timo? [12:51] see #ubuntu-devel [12:51] Laney, also thanks for adding the other fix (probably this issue was masked by the failure). [12:53] tkamppeter: no worries. It might not exist on the autopkgtest runners if they happen to have those things installed, but my autopkgtest-buildvm-ubuntu-cloud instance did not [13:47] tseliot, hey, iirc you confirmed https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/1822937 ... is that still something you are looking at? should it be assigned to you? (and maybe rls targetted?) [13:47] Ubuntu bug 1822937 in nvidia-settings (Ubuntu) "NVIDIA settings won't write to /etc/xorg" [Low,Confirmed] [13:48] seb128: I am not convinced it's an nvidia specific problem though. I wonder if it was caused by a change in polkit [13:49] but yes, it's still on my list [13:50] tseliot, I don't think polkit changed (much), but if you have a testcase/small code example doing something similar to what nvidia-settings is doing let me know we can have a look [13:50] tseliot, I assign it to you for now then [13:50] seb128: ok [13:50] thx [15:11] willcooke, Laney, k, as I though andyrock had let an update-notifier branch fixing the "shouldn't show indicator if livepatch is not in use", we were just behind on review ... just uploaded to eoan I will get that in the bionic SRU next [15:14] cool [15:14] it doesn't implement that full checkbox thing from the spec still though right? [15:15] it does, uploaded as well [15:15] well "full", I didn't read the spec [15:15] but he added a checkbox to software-properties to show/hide the indicator [15:15] and fixed the indicator to not show when livepatch is not in use [15:16] ok, I just looked at the diff to see if there was anything about a checkbox in there, maybe it's in a previous version [15:17] oh no I found it [15:17] https://launchpadlibrarian.net/423127873/software-properties_0.98.0_0.98.1.diff.gz [15:17] ah, k [15:17] looks good then, assuming it works right ;-) [15:17] the gsettings was already there [15:18] it works for me, but I give it another round of testing on bionic before upload [15:18] I tested on disco with hacked lsb-release info/faking livepatch being enabled :) [15:18] k, on that note moving location again, bbiab [15:19] argh [15:19] people without bouncers [15:23] :p [15:23] "great people", you meant Laney, right right right? :) [15:23] * Laney looks nervous [15:23] ...yeeeeeeeesss... [15:23] good answer! [15:28] (and back) [15:33] wb [15:34] seb128: wanted to link you to the spec before you went away: https://wiki.ubuntu.com/SoftwareUpdates#livepatch - probably useful for your testing [16:05] this is interesting to see that the mount syscall and the mount command aren't the same at all in term of magic :) [16:05] well interesting/surprising/giving more work :p [16:05] but on that… seeing in Lyon for some of you! have a great week-end [16:05] ORLY [16:06] isn't /bin/mount a fancy transformer into mount() calls? [16:06] Laney: don't stop at ORLY but at Saint Expéry airport [16:06] (yes, I know you are taking the train :p) [16:06] heh [16:06] Laney: yes and no [16:06] it has some enhancement like the "auto" special name [16:06] to detect the device type [16:06] also, the mount() syscall can only mount block devices [16:07] where mount can bindmount directories and regular files [16:07] and so, it creates a loop devices before calling mount syscall [16:07] https://lwn.net/Articles/759499/ [16:07] intriguing stuff [16:07] (which is where I'm coming from :p but toook some time to figure this out) [16:07] yeah ;) [16:08] went on this as well [16:08] didn't have my answer on block device though :p [16:08] fsmount would have been great, but not mapped by Golang [16:09] did it go in? [16:09] I don't know, I just grepped on the golang stdlib :p [16:09] heh [16:09] but yeah, maybe the kernel didn't implement it, I just went on the next grep in libmount.c ;) [16:09] well not being in the kernel would block that for sure :> [16:10] now you go away [16:10] see you sunday! [16:10] see you on sunday Laney! [16:16] Trevinho, do you happen to know if making the dock pips reflect windows that are on the same workspace as the dock is anywhere on the plans for upstream dock? [16:16] what I mean is: [16:17] I have the dock set so that each monitor is independent. So on monitor one I have my pinned icons, let's say terminal, browser and irc. [16:17] Then I have the same icons on Monitor 2 [16:17] If I have IRC on monitor 1, and I click on the icon on monitor 2 - then instead of taking me to IRC on monitor one, it launches another IRC. [16:17] That's my doing, because I wanted to try and get it working like Unity 7 [16:18] :) [16:18] but it would be a good feature for it not to do that IMO [16:18] Laney, thx for the spec url! [16:18] np === pstolowski is now known as pstolowski|afk [16:24] have a good week-end everyone! [16:32] willcooke: hey... No I don't think there's such plan [16:32] willcooke: but we can indeed do it [16:35] indeed there are various things to be tuned there to get the u7 behavior though... MOstly in multi monitor as you say [16:35] it something I'd like to find time for, but since we never defined what and when I [16:35] * Trevinho kf [16:35] err [16:36] if not generically, then I didn't move much forward [17:00] Trevinho,thx [17:01] Good night all, have a good weekend. Safe travels to those going to Lyon o/ [17:06] night also o/ [18:02] interesting [18:03] I've been poking at gnome-calendar for a week, upstreaming some bugs, nagging George about getting reviews and talking about backports/a new tarball on #gnome-calendar [18:03] and while I test the update Laney comes and beat me to it :p [18:03] well I guess I drop that and call it a week then! [18:03] have a nice w.e desktopers [18:03] seb128: you too! [18:04] seb128: safe travels [18:04] as short as it may be ;) === Guest59401 is now known as ahayzen[m]