[01:47] <callmepk> good morning
[01:52] <duflu> Morning callmepk 
[01:55] <callmepk> morning duflu
[06:12] <didrocks> good morning
[06:19] <callmepk> morning didrocks 
[06:29] <duflu> Hi didrocks 
[06:33] <didrocks> hey callmepk, duflu!
[06:40] <oSoMoN> good morning desktoppers
[06:40] <duflu> Hi oSoMoN 
[06:40] <oSoMoN> hey duflu 
[06:46] <didrocks> salut oSoMoN 
[06:46] <oSoMoN> salut diddledan 
[06:46] <oSoMoN> grrr
[06:46] <oSoMoN> didrocks, 
[07:21] <seb128> goood morning desktopers and happy friday!
[07:39] <duflu> Hi seb128, happy Friday
[07:41] <seb128> hey duflu, how are you? ready for the weekend?
[07:42] <duflu> seb128, I'm well, you? Yes I will enjoy the rest and aim to see family
[07:46] <seb128> I'm alright, a bit tired but it's friday!
[07:51] <oSoMoN> salut seb128 
[07:55] <didrocks> hey seb128!
[08:03] <Laney> morning
[08:04] <marcustomlinson> happy friday desktoppers
[08:05] <duflu> Morning Laney and marcustomlinson 
[08:09] <seb128> lut oSoMoN, didrocks, comment ça va aujourd'hui?
[08:09] <seb128> hey marcustomlinson, Laney, how are you?
[08:10] <marcustomlinson> seb128: not too shabby, and yourself?
[08:10] <seb128> marcustomlinson, I'm alright, it's friday :)
[08:13] <marcustomlinson> hey duflu
[08:18] <Laney> moin duflu & seb128 
[08:18] <Laney> happy friday to you
[08:20] <didrocks> seb128: ça va. on se bat avec eiffage pour l'electricite mais bon...
[08:20] <didrocks> hey Laney
[08:21] <Laney> ahoy didrocks 
[08:41] <seb128> didrocks, ils ont pas de crénaux pour passer chez vous ,
[08:41] <seb128> ?
[08:45] <didrocks> seb128: ils passent 10 min mais ne fo t 
[08:46] <didrocks> font rien*
[08:46] <seb128> :(
[08:46] <didrocks> prétextant que le cable ne passe pas. Le constrcteur l'a passé seul pourtant...
[08:47] <didrocks> bref, compliqué :(
[08:56] <jamesh> oSoMoN: another Chromium/snap bug report: https://forum.snapcraft.io/t/chromium-snap-kernel-has-no-file-descriptor-comparison-support-operation-not-permitted/18921 -- sounds like it might be doing something seccomp or AppArmor prohibits
[09:11] <oSoMoN> seb128, ça va bien, merci! (désolé j’ai loupé la notification)
[09:11] <oSoMoN> jamesh, looking, thanks
[09:13] <jamesh> oSoMoN: Mesa in Bionic revved from 19.2 to 20.0 four days ago, so it's quite possible that the new drivers are hitting some sandbox restriction as snaps get rebuilt
[09:14] <oSoMoN> this was also reported yesterday as bug #1887793, but I didn't know what to make of it, and was waiting for further information from the OP
[09:26] <jamesh> if it is Mesa related to the new Mesa, perhaps ask what GPU they've got
[09:47] <oSoMoN> jamesh, https://forum.snapcraft.io/t/chromium-snap-kernel-has-no-file-descriptor-comparison-support-operation-not-permitted/18921/2 suggests that this might have to do with fontconfig (again)
[09:48] <oSoMoN> https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=af9ed0cec8cdfcc2972b8a3e13a750516b358211 might be related, although I'm not sure how
[09:49] <jamesh> ugh :-(
[09:50] <jamesh> oSoMoN: I did put together a prototype for how we could handle fontconfig caches better here: https://forum.snapcraft.io/t/shared-fontconfig-cache-prototype/18660
[09:50] <jamesh> still needs work to get beyond the proof of concept stage though
[09:51] <seb128> those font cache issues are annoying :(
[09:52] <jamesh> yep.  My thoughts are to ignore all host caches completely
[09:52] <jamesh> not even make them visible by default
[09:55] <seb128> it's a shame that we can't get those to work :/
[09:56] <seb128> adding content sharing and plugs to connect does make things look more complex at the end
[09:57] <jamesh> given that changing either fontconfig version or freetype version can alter the contents of the cache files, it seems like a losing battle
[09:58] <jamesh> if you can makes sure what's inside the sandbox is always at least as new as the host, things will probably work
[09:58] <jamesh> if the sandbox is older, the cache might indicate the fonts provide features that the app's libraries can't actually use
[10:03] <seb128> right
[11:11] <sil2100> Laney, seb128: hey guys! A quick question: there are those OEM meta packages that we have a special process for:
[11:11] <sil2100> https://bugs.launchpad.net/oem-priority/+bugs/?field.tag=oem-meta-packages
[11:11] <sil2100> My question is: are those needed for .1?
[11:12] <Laney> yeah
[11:12] <Laney> I'm sponsoring them now
[11:13] <sil2100> Thanks, I can do the AA bits if needed
[11:13] <Laney> cheers
[11:13] <Laney> I'm thinking sponsor to focal and copy-up, does that sound ok?
[11:15] <Laney> sil2100: ^-
[11:17] <sil2100> Laney: sounds ok, but from what I heard from xnox, we don't want those in groovy actually?
[11:18] <Laney> I dunno really
[11:18] <Laney> focal's the main thing
[11:18] <Laney> we need to figure out the non-lts situation a bit better
[11:19] <sil2100> Yeah, for now I'd just do focal
[11:19] <Laney> I would be ok to not copy if you don't mind, we can still sort out the rest of it later
[11:19] <sil2100> We can copy forward anytime
[11:19] <Laney> was trying to be policy compliant™
[11:20] <sil2100> +1! We do have a few packages that are series-specific, so it should be fine for now
[11:43] <GunnarHj> Hi seb128, any chance you can upload ibus-typing-booster today?
[14:40] <sil2100> Laney: hey! Did you manage to sponsor some of the OEM packages? As I didn't see those in the NEW queue
[14:41] <Laney> sil2100: I found that they hadn't yet uploaded the packages to the oem archive and asked them to do that
[14:42] <Laney> if you prefer we can accept to proposed anyway
[14:43] <sil2100> Laney: no, that's fine, we can do that on Monday - was just curious
[14:43] <sil2100> Thanks!
[14:43] <sil2100> :)
[20:23] <KGB-0> mutter tags 23d029e Marco Trevisan upstream/3.36.4 * Upstream version 3.36.4 * https://deb.li/iiQh0
[20:25] <KGB-0> mutter upstream/3.36.x f57ec26 Marco Trevisan * pushed 36 commits (first 5 follow) * https://deb.li/3izZG
[20:25] <KGB-0> mutter upstream/3.36.x 1ec91cc Carlos Garnacho src/wayland/ meta-wayland-data-device.c meta-wayland-data-device.h * wayland: Send clipboard offers to all data devices from the same client * https://deb.li/i2noM
[20:25] <KGB-0> mutter upstream/3.36.x d721750 Carlos Garnacho src/wayland/ meta-wayland-data-device-primary.c meta-wayland-data-device-primary.h * wayland: Send primary offer to all data devices from the same client * https://deb.li/wE2n
[20:25] <KGB-0> mutter upstream/3.36.x 9acb823 Carlos Garnacho src/ (11 files in 2 dirs) * wayland: Rename gtk primary protocol files to "legacy" * https://deb.li/3tA97
[20:25] <KGB-0> mutter upstream/3.36.x 76e4b5d Carlos Garnacho src/meson.build * build: Build scaffolding for primary-selection wayland protocol * https://deb.li/GzSU
[20:25] <KGB-0> mutter upstream/3.36.x 59cb259 Carlos Garnacho src/ (11 files in 2 dirs) * wayland: Add support for wayland-protocols primary selection protocol * https://deb.li/3ynXF
[20:25] <KGB-0> mutter pristine-tar 170dde8 Marco Trevisan (Treviño) mutter_3.36.4.orig.tar.xz.delta mutter_3.36.4.orig.tar.xz.id * pristine-tar data for mutter_3.36.4.orig.tar.xz * https://deb.li/E6Hi
[23:55] <xnox> Laney:  yeah, i was requiring them that oem suite is open & packages available there.
[23:55] <xnox> Laney:  cause otherwise it's not obvious if the UbuntuArchive version is lower than the target suites or not.