[08:06] <seb128> goood morning desktopers!
[08:15] <nteodosio> hey seb128, good morning!
[08:15] <seb128> nteodosio, hey Nathan, how are you doing?
[08:16] <nteodosio> I'm fine seb128, how about you?
[08:17] <seb128> nteodosio, I'm alright thanks!
[11:35] <KGB-0> rhythmbox tags 6dd75fb Sebastien Bacher ubuntu/3.4.7-1ubuntu1 * https://deb.li/3z8Dj
[11:35] <KGB-0> rhythmbox ubuntu/master 6dd75fb Sebastien Bacher * pushed 12 commits (first 5 follow) * https://deb.li/33J44
[11:35] <KGB-0> rhythmbox ubuntu/master 6082435 Simon McVittie debian/ control control.in * d/control.in: Drop compatibility with old libgdk-pixbuf2.0-dev package * https://deb.li/iOuzD
[11:35] <KGB-0> rhythmbox ubuntu/master e153d25 Laurent Bigonville debian/rules * debian/rules: Fix -Dgudev=disabled flag for no-linux arches * https://deb.li/MNFv
[11:35] <KGB-0> rhythmbox ubuntu/master 6488288 Jeremy Bicha (107 files in 28 dirs) * Update upstream source from tag 'upstream/3.4.7' * https://deb.li/UDTF
[11:35] <KGB-0> rhythmbox ubuntu/master db38281 Jeremy Bicha debian/changelog * New upstream release * https://deb.li/378P1
[11:35] <KGB-0> rhythmbox ubuntu/master f8d1657 Jeremy Bicha debian/ control control.in * Build with libsoup3 * https://deb.li/mJOd
[11:45] <lissyx> so
[11:45] <lissyx> ffmpeg decoder broken in snap? https://bugzilla.mozilla.org/show_bug.cgi?id=1839852
[11:45] -ubottu:#ubuntu-desktop- Mozilla bug 1839852 in Core "Snap package fails to find audio decoder for mp4a with media.allow-audio-non-utility = false" [--, New]
[12:08] <seb128> lissyx, is that issue specific to nighly?
[12:08] <lissyx> no
[12:08] <lissyx> if I'm right on the cause it might affect all branches
[12:09] <lissyx> PR_LoadLibraryWithFlags is failing from Utility process
[12:09] <lissyx> our sandbox is blocking the access to libavcodec.so.58
[12:09] <seb128> what is that media.allow-audio-non-utility flag doing?
[12:09] <seb128> 'our' as upstream or snap?
[12:09] <lissyx> it's blocking the ability to perform any audio decoding outside of the utility process
[12:09] <lissyx> "our" as in "mozilla"
[12:11] <lissyx> seb128, i've been fighting over telemetry for weeks to try and identify why some people are not doing audio decoding on utility process but on content process
[12:11] <lissyx> seb128, since at some point we were not be able to find actionable items, I decided to land this change where we completely block in the hope for bug reports.
[12:12] <seb128> I'm not familiar enough with firefox to tell what's the difference between playing from content or utility
[12:13] <lissyx> we want to reduce the attack surface on content process
[12:13] <lissyx> that's why we introduced RDD (and then Utility) so those codecs runs in a different, more sandboxed, process
[12:14] <seb128> I turned on that setting, installed h264ify and tried to play a youtube random video and it works including sound
[12:14] <lissyx> which version?
[12:14] <seb128> 114.0.2-1
[12:15] <lissyx> it landed on nightly like one / two days ago :p
[12:15] <seb128> you just said it was not specific to nightly?
[12:15] <lissyx> if you profile your playback, you should see that audio decoding is done on rdd (or worst on content)
[12:16] <lissyx> the underlying problem is not specific to nightly
[12:16] <lissyx> we just surfaced it on nightly
[12:16] <seb128> but I can only reproduce the error if I try nightly?
[12:16] <lissyx> yes
[12:16] <lissyx> but it might be somethign we want to uplift to beta for example
[12:16] <seb128> ah ok, that's what I was asking 5 min when I asked if that was specific to nightly
[12:17] <lissyx> ok
[12:17] <seb128> sorry if the question was unclear
[12:17] <lissyx> issue == "audio decoding on the wrong process" in my mind
[12:17] <seb128> let me try with nightly 
[12:17] <lissyx> np
[12:17] <lissyx> 'been focused on that for months now so ...
[12:17] <seb128> how do I ask firefox where it's doing the decoding?
[12:17] <lissyx> you dont
[12:17] <lissyx> about:processes or profiler are your best friends for that
[12:18] <lissyx> or you need MOZ_LOG debugging
[12:19] <seb128> trying at least made me notice those warnings on the core22 snap
[12:19] <seb128> libva info: Trying to open /snap/firefox/2801/gnome-platform/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
[12:19] <seb128> libva error: /snap/firefox/2801/gnome-platform/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so has no function __vaDriverInit_1_0
[12:19] <seb128> libva info: va_openDriver() returns -1
[12:19] <seb128> libva info: Trying to open /snap/firefox/2801/gnome-platform/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
[12:19] <seb128> libva info: Found init function __vaDriverInit_1_10
[12:19] <seb128> libva error: /snap/firefox/2801/gnome-platform/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
[12:19] <seb128> libva info: va_openDriver() returns -1
[12:20] <seb128> on core20 it is
[12:20] <seb128> libva info: Trying to open /snap/firefox/2800/gnome-platform/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
[12:20] <seb128> libva info: Found init function __vaDriverInit_1_7
[12:20] <seb128> libva info: va_openDriver() returns 0
[12:20] <seb128> so might be another thing buggy in the core22 build
[12:22] <lissyx> :[
[12:23] <lissyx> seb128, which process?
[12:24] <seb128> that's the output of 'firefox'
[12:24] <seb128> and I can confirm that the edge channel snap with that setting fails to find an audio decoder
[12:25] <lissyx> it's working as intended
[12:25] <lissyx> that's perfect
[12:25] <seb128> :)
[12:26] <seb128> since it sounds like you are saying that it's an upstream sandbox problem and not a snap one I will let you deal with it :)
[12:29] <lissyx> looks like I'm unable to rebuild nightly locally though :(
[12:31] <seb128> so yes I can confirm that gpu rendering isn't working on core22 :-/
[12:32] <seb128> intel_gpu_top shows Video at 0% where it has activity on core20
[12:33] <lissyx> seb128, please file a bug i guess?
[12:33] <seb128> lissyx, yes
[12:33] <lissyx> try with MOZ_DISABLE_GPU_SANDBOX=1
[12:35] <lissyx> seb128, you can also run with MOZ_SANDBOX_LOGGING=1
[12:36] <seb128> doesn't make a difference, but that's not surprising from the log
[12:36] <seb128> iHD_drv_video.so has no function __vaDriverInit_1_0
[12:36] <seb128> sounds like a mismatch in version between libva and the driver from the sdk
[12:37] <lissyx>  https://bugzilla.mozilla.org/show_bug.cgi?id=1760941 ?
[12:37] -ubottu:#ubuntu-desktop- Mozilla bug 1760941 in Firefox Build System "VAAPI: Update Snap to core22 to have an intel-media-driver version that supports Iris Xe" [S4, New]
[12:49] <seb128> lissyx, right, that sdk update/fix broke it
[12:50] <seb128> firefox bundles its own libva copy and doesn't use the sdk one and that's too old now for the updated driver
[12:50] <seb128> I will try to repack firefox without libva see if that resolves it
[12:50] <seb128> I downgraded the sdk to an older revision and gpu rendering is working
[12:50] <lissyx> is SNAPCRAFT_BUILD_ENVIRONMENT_CPU still a thing with core22 / snapcraft 7.x ?
[12:51] <lissyx> because it only uses two CPUs here.
[12:52] <lissyx> https://github.com/canonical/craft-providers/issues/212
[12:52] -ubottu:#ubuntu-desktop- Issue 212 in canonical/craft-providers "Incorrectly handling SNAPCRAFT_MAX_PARALLEL_BUILD_COUNT" [Open]
[12:56] <seb128> yet another reason to use lxc...
[12:56] <lissyx> well i'm using lxc
[12:56] <seb128> so that's not the bug mentioned in there with multipass
[12:56] <seb128> afaik that option should still be working...
[13:04] <lissyx> ok weird it's working again
[13:05] <lissyx> we're lucky, given the telemetry of users of snap with h264ify
[14:25] <seb128> lissyx, another question about the debug symbol thing, rebuilds on the same version string will keep being an issue going forward with the current system? if so could you make the system add the build timestamp to the index so differenciate builds even if they use the same version?
[14:26] <seb128> lissyx, I just pushed a fix for libva on core22 which is going to trigger a snap rebuild but now I wonder if that means that rebuild isn't going to get its debug symbols imported?
[14:26] <lissyx> I already tried to use revision id but there were problem unfortunately (I dont remember which one)
[14:35] <seb128> the revision is a store thing so if it's still uploading or failed to upload it might be missing
[14:36] <seb128> but the buildpage has some uniq identifier
[14:36] <seb128> like vcs revision
[14:49] <seb128> bbiab
[15:18] <lissyx> seb128, as much as I remember, the last time we evaluated the situation, the situations where you rebuild a package without a version bump was rare enough we said it's not a big deal
[15:21] <seb128> lissyx, ok, that might still be the case. We will have rebuilds when we do packaging fixes or tweaks like here which is not uncommon, but in 'normal business' times most builds are just version updates still