[06:22] <didrocks> good morning
[06:22] <jibel> Salut didrocks
[06:22] <jibel> hi all
[06:22] <didrocks> salut jibel
[06:33] <duflu> Morning didrocks and jibel
[06:33] <duflu> And good morning oSoMoN
[06:33] <didrocks> hey duflu
[06:33] <didrocks> & oSoMoN
[06:33] <oSoMoN> good afternoon duflu, bonjour didrocks
[06:34] <oSoMoN> and good day to you all desktoppers!
[06:34] <Wimpress> o/
[06:36] <duflu> Hi Wimpress
[06:37] <didrocks> hey Wimpress
[06:40] <oSoMoN> hi Wimpress
[08:01] <marcustomlinson> good morning all
[08:02] <seb128> good morning desktopers
[08:02] <Laney> hey there!!!!!!
[08:02] <marcustomlinson> hey seb128 and Laney, how goes it?
[08:03] <duflu> Morning marcustomlinson, seb128 and Laney
[08:03] <marcustomlinson> yo duflu
[08:03] <didrocks> hey marcustomlinson, seb128, Laney
[08:04]  * marcustomlinson remembers the opening scene from Monty Python's The Meaning of Life
[08:05] <seb128> hey Laney marcustomlinson duflu didrocks, how is everyone today?
[08:05] <duflu> Bruce?
[08:06] <duflu> Oh, no. Different skit
[08:06] <duflu> seb128, feeling exhausted again today. But yesterday was weirdly great. How are you?
[08:06] <seb128> I'm good, my back is mostly unblocked :)
[08:09] <Laney> hey marcustomlinson duflu didrocks seb128
[08:10] <Laney> I'm alright thanks! how are you?
[08:10] <marcustomlinson> https://youtu.be/WQEkAbLJ5L8
[08:11]  * Laney gives seb128 some deep heat
[08:11] <seb128> thx
[08:12] <Laney> dunno if they have that over there, must be something similar i guess
[08:19] <seb128> yeah, they do
[08:19] <seb128> but it's ok, today is already better than yesterday :)
[08:29] <oSoMoN> marcustomlinson, makes you think, doesn't it? ;)
[08:29] <marcustomlinson> :D
[08:30] <didrocks> good, busy on tests already
[08:31] <didrocks> with corner zfs/zsys and grub menu ordering (like what dataset was the latest?)
[08:31] <Laney> testing that this food tastes nice, testing that that puppy really is as fluffy as it looks, testing that the sun lounger is nice to lie in
[08:31]  * Laney likes testing
[08:31] <didrocks> ahah
[08:47] <Laney> didrocks: do you have a tag for yaru 19.04.2 lying around by chance?
[08:57] <tkamppeter> Hi, could someone sponsor the systemd SRU upload for bug 1754671? The fix could perhaps also help on the regressions of the n-m SRU.
[09:15] <didrocks> Laney: what do you mean by having a tag?
[09:15] <Laney> for the upload that went into disco
[09:16] <Laney> you did that one, so thought you might have tagged it :-)
[09:16] <didrocks> looking
[09:16] <seb128> xnox, ^ can you help tkamppeter with that systemd SRU?
[09:19] <didrocks> Laney:pushed on correct commit
[09:20] <Laney> merci!
[09:20] <seb128> jamesh, kenvandine, https://bugs.launchpad.net/ubuntu/+source/gnome-calculator/+bug/1797734/comments/6 ... is that normal that the platform does pixbuf queries/cache update/etc still? (on first start)
[09:20] <Laney> ah yay, I branched at the right one
[09:21] <jamesh> seb128: yes.  We don't have a good solution for that
[09:21] <seb128> :-(
[09:21] <jamesh> seb128: for example, look at /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache -- there are absolute paths to the plugins
[09:22] <jamesh> the gnome-platform snap is mounted under $SNAP, which is different for each application
[09:22] <seb128> right :/
[09:23] <seb128> we can't fix that with layouts and always mount to the same location then?
[09:24] <jamesh> that probably is an option
[09:25] <jamesh> and it would have to be layouts: the content interface won't let us mount to locations outside of $SNAP
[09:25] <jamesh> (or a few other locations controlled by the snap)
[09:26] <seb128> right
[09:26] <seb128> jamesh, thx for the reply!
[09:30] <jamesh> it's something that we should be easier to automate with the newer snapcraft extension system
[11:57] <GunnarHj> Hi seb128, do you have time to sponsor the ibus-libpinyin stuff? There are two of them, bug #1829947 and bug #1768166. Proposed uploads in https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus-libpinyin
[11:57] <seb128> GunnarHj, hey, sure
[11:58] <seb128> I will do it in a bit, thx for working on it!
[11:58] <GunnarHj> yw
[12:12] <tkamppeter> xnox, hi
[12:14] <tkamppeter> xnox, did you see seb128's message about the systemd SRU upload for bug 1754671? There is a debdiff for an SRU attached and it seems that the SRU is very important to accompany the already done SRU of network-manager.
[13:01] <seb128> tkamppeter, did you identify that systemd change to fix the regressions reported? or is that just to help moving forward with getting the split vpn dns working?
[13:07] <kenvandine> seb128, jamesh: We should be able to improve that with layouts in the gnome snapcraft extension
[13:07] <seb128> hey kenvandine
[13:18] <tkamppeter> seb128, I have no proof that the systemd fix solves the regressions, but the regressions have a certain similarity with the original problem, so I would like the reporters of the regressions to try the systemd fix.
[13:20] <seb128> tkamppeter, you could get it in a ppa meanwhile?
[13:22] <xnox> Laney:  sil2100: heya, https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/+merge/355544 looks stale, is that being reviewed? is it good? bad?
[13:24] <tkamppeter> seb128, yes, this is also a possibility, and when we get n-m solved, independent whether the regression gets solved by systemd or not, we can do the systemd SRU.
[13:24] <tkamppeter> seb128, I will put systemd on my PPA then.
[13:24] <Laney> xnox: it's not stale
[13:24] <Laney> as it happens I'm looking at it atm
[13:25] <seb128> xnox, hey, did you see that systemd ping? We have problems with the recent network-manager SRU went to update creating issues, see eg https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1829838
[13:26] <seb128> xnox, users have been reporting that openvpn-systemd-resolved is unhappy since the update
[13:26] <seb128> xnox, unsure what's the right way to ask help for foundations though, direct ping or email to Pat/Steve to it on your trello board/with proper resource allocation?
[13:43] <seb128> GunnarHj, that bug got no report so far, I don't think we should care about cosmic at this point, it's neither LTS nor current stable
[13:45] <GunnarHj> seb128: I don't really care much about cosmic; just thought it was needed due to version logic. What do you mean by "got no report"?
[13:45] <seb128> GunnarHj, the bug has no duplicate, if it exists since bionic and wasn't raised before it probably doesn't annoy lot of users
[13:46] <seb128> GunnarHj, SRU team said it's fine for the maintainer to decide to skip a serie while doing SRUs, they prefer to have fixes in all versions but it's not an hard requirement
[13:53] <GunnarHj> seb128: I see. As regards annoying, there are 16712 reported crashes of the most common type:
[13:53] <GunnarHj> https://errors.ubuntu.com/problem/cd3fa9b145c79364f535cede0267ffe384b9ced8
[13:54] <GunnarHj> seb128: Getting rid of that seems to be a good idea IMO.
[13:55] <seb128> GunnarHj, what are you talking about? The bug you pinged me about is not a segfault/error, it's just some chars not being inputed after chinese glyphs?
[13:55] <seb128> ah, I see, you listed another issue
[13:55] <GunnarHj> seb128: Right.
[13:55] <seb128> GunnarHj, I don't think the diff in your ppa is likely to address the segfault, is it?
[13:56] <seb128> ah, you did a version update for those series
[13:56] <seb128> I understand now :)
[13:57] <GunnarHj> seb128: Sorry for the confusion. ;)
[13:57] <seb128> no worry/not your fault :)
[13:58] <seb128> GunnarHj, the version update is not going to work with that diff for bionic, the update has quite some code changes so we would to convince the SRU team that a full update is needed and that we have a solid testplan
[13:59] <seb128> GunnarHj, would be best to find the commit that fixed that issue...
[14:03] <GunnarHj> seb128: No solid test plan exists. :( It's about files in ~/.cache/ibus/libpinyin getting corrupted. The error tracker is the best I can point at. No reported 19.04 crashes of the most common type so far.
[14:08] <seb128> GunnarHj, the backtrace has a libpiniyin function, I'm not sure the fix is not in the lib
[14:09] <seb128> GunnarHj, like https://github.com/libpinyin/libpinyin/commit/b708ceef ... that's a call to the function that is in the bt
[14:12] <GunnarHj> seb128: That's why the proposal includes libpinyin too, not just ibus-libpinyin.
[14:15] <seb128> GunnarHj, I feel like we don't know those components well enough to be confident SRUing new versions would have no side effect/regression/bug on any of our desktops... (just my opinion, I'm not stopping you to try to convince the SRU team/find a sponsor)
[14:16] <Trevinho> morning
[14:17] <Laney> moin Trevinho
[14:17] <Trevinho> yey Ianuss
[14:17] <Laney> what's upé
[14:19] <GunnarHj> seb128: Wouldn't uploading to the bionic queue be the simplest way to pass the question to the SRU team? The fact that the base for the proposal is a bit vague is shown very clearly in the bug description.
[14:20] <seb128> hey Trevinho, how are you?
[14:21] <seb128> GunnarHj, it would be better to sort out before uploading, otherwise you just make it the next person problem and they are likely to let it sit in the queue until they decide to reject because they don't know what to do with it
[14:22] <GunnarHj> seb128: Ok, I'll ping someone in the SRU team then.
[14:23] <seb128> GunnarHj, thx
[14:24] <GunnarHj> seb128: Thanks for looking at it!
[14:24] <seb128> yw!
[16:23] <GunnarHj> seb128: When you tested the docs videos (bug #1804786), did you use Nouveau or some other driver?
[16:32] <tkamppeter> seb128, I have now uploaded systemd to my PPA and posted on the regression bug reports for their OPs to test the PPA.
[17:04] <Laney> night!
[17:22] <seb128> 'night Laney & desktopers
[17:22] <seb128> GunnarHj, intel, I don't have other configs
[17:22] <seb128> tkamppeter, k, thx, I pinged foundations to see if they can help with the sponsoring/SRU
[17:29] <GunnarHj> seb128: So to a large extent it seems to be a Nouveau issue then, as duflu indicated on the bug report. Plus the 'power
[17:30] <GunnarHj> of the hardware.
[19:30] <oSoMoN> night all