[07:12] <didrocks> good morning
[07:13] <duflu> Morning didrocks 
[07:15] <lissyx> hello
[07:17] <didrocks> hey duflu, lissyx 
[07:18] <lissyx> i'm experimentign a lot of crashes of rdd process on firefox nightly (non snap) on 22.04
[07:18] <duflu> Hi lissyx 
[07:18] <lissyx> this is due to us enabling va-api recently by default
[07:18] <lissyx> cf https://bugzilla.mozilla.org/show_bug.cgi?id=1777200 and https://bugzilla.mozilla.org/show_bug.cgi?id=1752494
[07:18] <ubottu> Mozilla bug 1777200 in Core "Crash in [@ __strlen_avx2 | __vfprintf_internal]" [S2, New]
[07:18] <ubottu> Mozilla bug 1752494 in Core "Enable VA-API by default in nightly" [--, Resolved: Fixed]
[07:18] <lissyx> now it looks like we expected AMD GPUs to behave well on Mesa 21.0+, and it seems not to be the case
[07:20] <lissyx> I'd like to confirm first it is a driver-side issue, would you know some context on that matter?
[07:28] <jibel> Good morning 
[07:44] <duflu> Morning jibel 
[08:06] <seb128> hey there, I think I went head down in resuming things I started yesterday and forgot the morning greeting today!
[08:13] <duflu> Hi seb128, you didn't really miss anything
[08:20] <seb128> hey duflu, great :)
[08:36] <lissyx> stransky told me it looks like an upstream issue, so https://gitlab.freedesktop.org/mesa/mesa/-/issues/6767
[08:36] <ubottu> Issue 6767 in mesa/mesa "AMD Ryzen 7 PRO 5850U / Cezanne segfault on VA-API usage from Firefox" [Opened]
[08:38] <lissyx> seb128, ^ do you need me to also file an issue on launchpad?
[08:39] <seb128> lissyx, it wouldn't hurt, especially if upstream gets a fix and we want to cherry pick/SRU it for Ubuntu
[08:41] <lissyx> whaa...
[08:41] <lissyx> https://bugs.launchpad.net/ubuntu/+filebug redirects me to wiki instructions ?!
[08:43] <RikMills> lissyx: it should do that. you need to file the bug against the correct source package
[08:43] <lissyx> pretty sure in the past it used not to
[08:43] <lissyx> maybe long time ago
[08:43] <lissyx> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1980341
[08:43] <ubottu> Launchpad bug 1980341 in mesa (Ubuntu) "AMD Ryzen 7 PRO 5850U Cezanne crashes with Firefox VA-API usage" [Undecided, New]
[08:44] <RikMills> it was changed so we do not get lots of bugs filed against just 'ubuntu' which is not very helpful
[08:44] <lissyx> (it's just links to upstream, I dont think it's useful I copy/paste all the same infos)
[10:09] <seb128> lissyx, the bugsquad members don't have the redirect, maybe you were member and expired?
[10:10] <lissyx> I dont think
[10:10] <lissyx> since I dont know what that is :)
[10:10] <seb128> k, maybe you remember from before the time they changed that, or you tried on a package name and not ubuntu/ before
[11:23] <seb128> lissyx, btw how do I tell if firefox is managing to use vaapi on my machine?
[11:59] <jbicha> good morning
[12:03] <KGB-0> gnome-shell ubuntu/master f9faf0d Nathan Pratta Teodosio debian/ (7 files in 2 dirs) * Drop support for the old gnome-control-center * https://deb.li/5Gm2
[12:06] <lissyx> seb128, I dont remember :)
[12:23] <seb128> jbicha, hey, I commented on gitlab but in case you don't regularly check email, the issue with gcc and RTL is that we are currently missing gtk4 translations and the direction is defined in the translation
[12:24] <jbicha> seb128: so it's a duplicate of bug 1947698 ?
[12:24] <ubottu> Bug 1947698 in gtk4 (Ubuntu) "window buttons alignment is wrong in RTL locales" [Undecided, New] https://launchpad.net/bugs/1947698
[12:25] <seb128> jbicha, likely
[12:25] <seb128> how come we don't have translations for gtk4 and didn't notice? :-(
[12:26] <seb128> and why is gtk4 not using dh-sequence-gnome despite having a control.in? how is that even working?
[12:26] <Wimpy> Afternoon desktoppers o/
[12:26] <seb128> hey Wimpy, how are you?
[12:27] <Wimpy> Very well thanks seb128 :-)
[12:27] <Wimpy> Yourself?
[12:27] <jbicha> gtk uses an extra complicated debian/control.in structure. I don't think the complication is necessary but I didn't know if it was worth dismantling it
[12:28] <seb128> Wimpy, I'm alright thanks, buuuusy as usual!
[12:29] <seb128> jbicha, I assigned you a card, please try to work on it this week + SRU if possible, we need that fixes for .1
[12:29] <Wimpy> seb128: What is keeping you busy? Anything fun? :-)
[12:30] <jbicha> seb128: do you know when we can start getting kinetic langpacks built?
[12:31] <seb128> jbicha, we already have, see https://launchpad.net/ubuntu/+source/language-pack-gnome-fr for example from june 26th
[12:32] <jbicha> good
[12:32] <seb128> Wimpy, atm I'm mostly trying to stick on top of LTS issues like ^, .1 freeze is coming
[12:32] <Wimpy> seb128: wow .1 already? When is it due?
[12:33] <seb128> jbicha, you can probably copy my libnma debian/rules hack if we don't want to use dh-gnome
[12:33] <seb128> Wimpy, early august, which means freeze end of july, with review&validation delays for the SRUs it means we need to land things in the next weeks
[12:34] <Wimpy> Comes around fast doesn't it :-)
[12:34] <seb128> Wimpy, how are things for you? liking the work? still having time for ubuntu mate fun? ;)
[12:35] <Wimpy> WOrks is good. Conference season so been mega busy for weeks. Taking a few days off for my daughters birthday :-)
[12:35] <Wimpy> seb128: I've been working on a different hobby project recently. It uses gnome-flashback.
[12:36] <Wimpy> In fact, I have a question. What are the conditions for the Yaru theme variant chooser to be made visible in gnome-control-center?
[12:37] <Wimpy> seb128: I've put together a minimal desktop as an escape hatch for my project. g-c-c is working, but missing a couple of features.
[12:37] <Wimpy> Probably because gnome-shell is entirely absent.
[12:37] <Wimpy> Anyway, the project is a retro game emulation OS for Raspberry Pi built with Ubuntu 22.04 :-)
[12:39] <seb128> sounds like a fun one :)
[12:41] <lissyx> seb128, there's a VAAPI in about:support but it just shows if it's going to try it 
[12:43] <jbicha> Wimpy: it only shows when "ubuntu" is present in XDG_CURRENT_DESKTOP (default session is ubuntu:GNOME) but you're going to get all the other Ubuntu customizations that way too
[12:44] <Wimpy> jbicha: Ah, thanks.
[12:44] <seb128> lissyx, so nothing telling you once you started playing if that's actually using the right backend? chromium has an about://media-internals giving you those details
[12:44] <Wimpy> jbicha: I'll test it and see what happens :-)
[12:44] <lissyx> seb128, I'm not really working on media, so I dont really know
[12:44] <lissyx> I can ask
[12:45] <jbicha> the goal is to get the color switcher into upstream GNOME, hopefully for GNOME 43
[12:45] <seb128> lissyx, don't bother, I was asking in case because I was curious whether my intel setup was using vaapi after seeing your morning report
[12:45] <lissyx> seb128, for sure you should see it on stdout/stderr when it tries to load vaapi
[12:45] <seb128> jbicha, is anyone working on that?
[12:46] <seb128> lissyx, I managed to get output from libva by setting MOZ_LOG="PlatformDecoderModule:1" but I'm unsure if that tells me the end result
[12:46] <seb128> anyway, not important
[12:46] <jbicha> seb128: I haven't seen any progress on it this cycle. From our side, I believe Trevinho wanted to work on it
[12:47] <lissyx> seb128, so, it looks like we have a new hire working on that and it's expected to land next week
[12:47] <lissyx> so next week, nightly should show actual status in about:support
[12:47] <seb128> jbicha, right, after tilling and libadwaita and $stack_of_things_we_need_magic_marco_for, not likely
[12:47] <seb128> lissyx, ah, great, thanks
[12:47] <jbicha> I meant this is the libadwaita thing basically
[12:48] <seb128> jbicha, well we first need to unblock the discussion and get an agreement of what would be acceptable
[12:48] <seb128> which seems stucked
[12:48] <seb128> then we need to work on the solution...
[12:49] <jbicha> yeah, it's a lot to do in a short time, so GNOME 44 is more likely
[12:56] <seb128> jbicha, I'm a bit confused at why xdg-desktop-portal-gnome fileselector are showing translations if gtk translations aren't there
[12:57] <seb128> hum, seems like it retranslate some of the existing strings from its own sources, that would explain
[12:58] <jbicha> it's a mix of translated & untranslated for me so maybe the fileselector reimplements the gtk fileselector
[12:59] <seb128> they use gtk_file_chooser_dialog_new , https://gnome.pages.gitlab.gnome.org/gtk/gtk4/class.FileChooserDialog.html
[12:59] <seb128> which let you specify the dialog actions and label
[13:00] <seb128> k, that explains
[13:00] <seb128> it also explain why some of the strings in the selector are untranslated which I was wondering about but didn't find time to investigate
[13:00] <jbicha> yeah, it's basically the header and footer bars which are translated
[13:00] <seb128> I didn't expect it would turn out being the gtk translation being missing :/
[13:01] <seb128> jbicha, and the favorite folder names
[13:01] <seb128> since that's coming from the xdg config
[13:01] <jbicha> right & I didn't accept the dialog to translate those :) :)
[13:42] <jbicha> seb128: the gtk debian/control.in magic is ancient, lol https://salsa.debian.org/gnome-team/gtk4/-/commit/041ded809
[13:42] <ubottu> Commit 041ded8 in gnome-team/gtk4 "* Rewrite and cleanup the build process completely."
[13:43] <seb128> lol
[13:44] <jbicha> I'll go ahead and do a simple fix now, but I believe there won't be objections to just doing it like the rest of Debian GNOME later
[13:45] <seb128> 👍
[13:47] <jbicha> seb128: I guess it's because gtk4 uses meson that it was affected but not gtk3
[13:50] <KGB-0> gtk4 ubuntu/master 3fc54d9 Jeremy Bicha * pushed 44 commits (first 5 follow) * https://deb.li/Z6rG
[13:50] <KGB-0> gtk4 ubuntu/master 986fd99 Matthias Clasen gtk/gtktext.c * Merge branch 'blink-assertion-for-4-6' into 'gtk-4-6' * https://deb.li/vp3U
[13:50] <KGB-0> gtk4 ubuntu/master 91d2e1b Matthias Clasen gtk/a11y/gtkatspicontext.c * Merge branch 'stackpage-fix-for-4-6' into 'gtk-4-6' * https://deb.li/3sSJF
[13:50] <KGB-0> gtk4 ubuntu/master 15ea0c4 Laurent Bigonville debian/ control control.in * debian/control.in: Disable librsvg BD on architectures where it's not building * https://deb.li/arZU
[13:51] <KGB-0> gtk4 ubuntu/master 75821de Matthias Clasen gdk/wayland/cursor/wayland-cursor.c * wayland: scale cursors to the right size * https://deb.li/3drTM
[13:51] <KGB-0> gtk4 ubuntu/master 1523fec Matthias Clasen gdk/wayland/cursor/wayland-cursor.c * Merge branch 'wayland-cursor-scale2-for-4-6' into 'gtk-4-6' * https://deb.li/uQYy
[13:52] <seb128> jbicha, ?
[13:52] <seb128> jbicha, the reason is works for gtk3 is because we have that delta
[13:52] <seb128>     + debian/control.in: Build-Depend on dh-sequence-translations
[13:52] <seb128> why do you mean by because of meson?
[13:55] <jbicha> never mind, I was looking at the wrong branch
[14:00] <seb128> brb, changing location
[16:47] <Eickmeyer> Hey! Can somebody open a track for the gnome-3-28-1804 snap? I need a stable/ubuntu-##.## as I need it seeded in Ubuntu Studio.
[16:53] <diddledani> Eickmeyer: I'm not sure. The Ubuntu desktop-minimal seed for jammy shows `* snap:snap-store` as an item, but somehow that gets converted to installing a jammy-specific channel IIRC
[16:54] <Eickmeyer[m]> diddledani: Here's the issue I'm running into: https://launchpadlibrarian.net/610430884/buildlog_ubuntu_kinetic_amd64_ubuntustudio_BUILDING.txt.gz
[16:55] <Eickmeyer[m]> The snap "freeshow" (which is mine, btw) is an electron app which requires gnome-3-28-1804 (for some reason), which has no stable/ubuntu-##.## track for some reason.
[16:55] <diddledani> aah, you're missing a track in the gnome platform snap. I figured you were asking to override which track it was installed from (or maybe you're asking for either?)
[16:56] <Eickmeyer[m]> Yeah, that's the issue.
[16:56] <Eickmeyer[m]> And there's no way to specify a track in a seed that I'm aware of.
[16:57] <diddledani> odd. there's no tracks for the `gnome-3-38-2004` either and that's seeded in Jammy for Ubuntu desktop-minimal
[16:58] <Eickmeyer[m]> Yeah, which is funny because I have that seeded for Firefox no problem.
[17:01] <diddledani> there's no tracks for freeshow, either, and that got installed fine despite the commandline requesting `snap download --cohort= --channel=stable/ubuntu-22.10 freeshow`. This seems flakey - the command lines are arbitrarily flipflopping between requesting a stable/ubuntu-22.10 channel and not
[17:01] <Eickmeyer[m]> That's because, per the instructions (and mwhudson 's instructions) I made a track temporarily and closed it.
[17:02] <diddledani> aah
[17:02] <Eickmeyer[m]> So, that's really all that has to happen. A track needs to be opened and closed with that format.
[17:53] <jbicha> Eickmeyer[m]: could you update the snap to use gnome-3-38-2004 instead of the older version?
[17:53] <Eickmeyer[m]> jbicha: I wish. Unfortunately, electron-builder is stuck on the older 3-28-1804 and I've reseached ways to update it to no avail.
[17:56] <jbicha> Eickmeyer[m]: could you email Ken and Seb about needing the track opened and mention why you need the older gnome content snap?
[17:57] <Eickmeyer[m]> I'm going to throw a github issue up and explain that 1804 is hitting EOSS and that they should update it to the newer snap dep asap, but that doesn't fix the problem now.
[17:58] <Eickmeyer[m]> jbicha: I can do that. This is a problem for any electron app to be seeded at all, I just happen to be the guinea pig.
[18:04] <diddledani> Eickmeyer[m]: try setting the seed to `* snap:gnome-3-28-1804=latest/stable`
[18:04] <Eickmeyer[m]> I'll try that, thanks.
[18:04] <diddledani> (I've been going deep into google and launchpad-git repos to figure out how the live builder works
[18:04] <diddledani> ref https://git.launchpad.net/livecd-rootfs/tree/live-build/functions#n715
[18:05] <Eickmeyer[m]> diddledani: If this works, you'll be a life saver.
[18:06] <Eickmeyer[m]> The cron job hasn't started yet (should in the next few minutes), so we'll see soon.
[18:07] <diddledani> looks like it can be in the form of snap_name/classic=track/risk/branch (the /classic is optional and indicates to use --classic to install the snap, and =track/risk/branch is also optional to indicate the channel to install from)
[18:07] <diddledani> if the channel isn't specified and it's not core* then it will default to using `stable/ubuntu-$(release_ver)`
[18:13] <Eickmeyer[m]> I see. I hadn't investigated the code, tbh, nor did I know where to look.
[18:14] <seb128> diddledani, Eickmeyer[m], could you avoid such hacks please?
[18:14] <seb128> Eickmeyer[m], also do you have a report about the why electron-builder couldn't use new gnome versions?
[18:15] <Eickmeyer[m]> seb128: I would love to if I knew the proper way to do things.
[18:15] <Eickmeyer[m]> Or if it were properly documented.
[18:15] <diddledani> seb128: it's hardly a hack when it's intended as a feature of livecd-rootfs
[18:15] <seb128> diddledani, it's wrong though
[18:15] <Eickmeyer[m]> seb128: It's hard-coded and hasn't seen an update in over two years, prior to 20.04's release.
[18:15] <Eickmeyer[m]> The snap backend, that is.
[18:16] <diddledani> why is it wrong?
[18:16] <seb128> the reason we have a per-serie track and default to that is to have a safeguard in case of issue with that serie
[18:16] <seb128> we can reopen and publish to the serie and the installed system would default to it
[18:16] <seb128> you basically remove that safeguard by doing what you suggest
[18:24] <KGB-0> gtk4 signed tags 5d04f2b Jeremy Bicha ubuntu/4.6.5+ds-1ubuntu4 * gtk4 Debian release 4.6.5+ds-1ubuntu4 * https://deb.li/3ZpiE
[18:24] <KGB-0> gtk4 ubuntu/master c967583 Jeremy Bicha * pushed 6 commits (first 5 follow) * https://deb.li/BsAl
[18:24] <KGB-0> gtk4 ubuntu/master fb854b8 Jeremy Bicha debian/ control control.in * Build-Depend on dh-sequence-translations * https://deb.li/30thI
[18:24] <KGB-0> gtk4 ubuntu/master a4ebe87 Jeremy Bicha debian/changelog * releasing package gtk4 version 4.6.5+ds-1ubuntu2 * https://deb.li/dtej
[18:24] <KGB-0> gtk4 ubuntu/master 6916e68 Jeremy Bicha debian/rules * debian/rules: gtk4 builds 2 translation templates so handle them both * https://deb.li/31e2R
[18:24] <KGB-0> gtk4 ubuntu/master c2ca82d Jeremy Bicha debian/changelog * releasing package gtk4 version 4.6.5+ds-1ubuntu3 * https://deb.li/3pS0D
[18:24] <KGB-0> gtk4 ubuntu/master 04b5ecf Jeremy Bicha debian/rules * Fix the build directory for the previous upload * https://deb.li/iQsCz
[18:24] <KGB-0> gtk4 signed tags fe35d77 Jeremy Bicha ubuntu/4.6.5+ds-1ubuntu2 * gtk4 Debian release 4.6.5+ds-1ubuntu2 * https://deb.li/xt81
[18:30] <Eickmeyer[m]> seb128: I have an answer for you, and I can probably get a pull request going against this along with a github issue. Their default template is still referencing gnome-3-28-1804 for all electon apps. https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/templates/snap/snapcraft.yaml
[18:32] <Eickmeyer[m]> But, in the meantime, that still hinders Ubuntu Studio's iso images from building without the hack that diddledani showed me, so I'll go with that until a track can be opened, and until electron can fix the builder.
[18:47] <diddledani> seb128: oh I see, you mean specifically on the gnome platform snap, not on seeded snaps in general?
[18:48] <diddledani> I see no reason to avoid specifying a track for an app snap for example - ie one that isn’t part of the snap ecosystem, but maintained by a third party
[18:50] <diddledani> I get where you’re coming from for the gnome platform snap tho as there might be interactions with the desktop. However if there is a bad interaction then it should be fix for everyone now just the one Ubuntu release, so I still don’t understand the need for release specific tracks
[18:51] <diddledani> The gnome platform snaps aren’t specific to Ubuntu but are used wherever snaps run. Therefore a problem affecting an Ubuntu release will likely affect other distros too
[18:53] <diddledani> The whole point of snaps is that there shouldn’t be distro or release of distro changes for individual snaps including the platform snaps - if we’re doing a fix for one Ubuntu release then imo we’ve failed
[18:56] <seb128> diddledani, I think you didn't understand what I was saying
[18:58] <seb128> diddledani, the issue is that we ship Ubuntu, including for example $greatsoftware published by $new_nice_people as the default music player
[18:58] <seb128> diddledani, our user install Ubuntu and trust us for their working system
[18:59] <seb128> now in 3 years that publisher decide to do something to the software that screw our users
[19:00] <seb128> as Ubuntu we don't own the software nor it's published and can't fix it
[19:00] <seb128> but we can publish to that special channel and unscrew our users
[19:00] <diddledani> So you’re saying don’t seed a third party app at all?
[19:00] <seb128> we do, firefox for example
[19:01] <seb128> I'm just saying we need to be able to protect our OS and our users against anything wrong that could be done to the snap and would automatically reach every of our users
[19:01] <diddledani> so my suggestion of specifying the channel was specifically to unblock Eric because the gnome platform snap doesn’t have the track and the live build is failing because of that
[19:02] <seb128> right, it would have taken me less time to open that track than to have to argue that you shouldn't do that hack
[19:02] <seb128> which I'm doing now
[19:02] <diddledani> Ie specifying it on the first party snap of gnome-3-28-1804
[19:03] <Eickmeyer[m]> seb128: just let me know when you've got the track open so I can fix the ubuntustudio seed.
[19:03] <seb128> Eickmeyer[m], you need it for 22.10?
[19:03] <Eickmeyer[m]> BTW, fwiw, latest build succeeded.
[19:03] <Eickmeyer[m]> seb128: Yes.
[19:04] <Eickmeyer[m]> I'll be sending the electron-builder devs a PR.
[19:05] <diddledani> electron builder has often dragged behind the rest of the snap world so it’s not surprising they’re still using core18
[19:05] <ogra> Eickmeyer[m], note that you want to bump the `base:` along with the extension ... if you bump to the -2004 gnome extension the package build should use the core20 base
[19:06] <Eickmeyer> ogra: Yeah, figured.
[19:06] <ogra> k
[19:09] <seb128> Eickmeyer, diddledani, bah, unlucky it seems I'm not a collaborator on that specific snap and Ken just left for holidays and won't be back before a while, I guess you can keep the hack for now...
[19:10] <Eickmeyer[m]> seb128: ack
[19:10] <diddledani> Bah!
[19:11] <Eickmeyer[m]> I'll just email Ken so there's a paper trail since he's not likely to see this.
[19:11] <seb128> we should automate that for every seeded Canonical snap on new serie opening
[19:11] <seb128> Eickmeyer[m], +1
[19:11] <diddledani> Hopefully Ken sent my job application to Mark before leaving 😉
[19:11] <Eickmeyer[m]> seb128: That's a really good idea, would prevent situations like this from happening in the future.
[19:12] <diddledani> Agreed. I was gonna suggest that we get some automation on new series to open tracks on all the snaps that have series specifics
[19:15] <seb128> diddledani, he did
[19:16] <diddledani> yey
[19:16]  * diddledani twiddles her thumbs
[19:16] <seb128> diddledani, the issue with automation is that you need the automation to be owned by someone who is contributor to all the snaps
[19:16] <seb128> which I'm unsure we have
[19:16] <diddledani> aah. yeah.
[19:16] <diddledani> that's a sticky point
[19:17] <seb128> but we could at least automate the ones we one + emails to the publishers of the other ones with steps they need to do
[19:20] <KGB-0> libsoup3 ubuntu/jammy 4e74352 Jeremy Bicha debian/ control control.in gbp.conf * Update Vcs fields * https://deb.li/8rDn
[19:20] <KGB-0> libsoup3 ubuntu/jammy d67a2a2 Jeremy Bicha debian/changelog * releasing package libsoup3 version 3.0.7-0ubuntu1 * https://deb.li/3oBo7
[19:21] <KGB-2> libsoup3 signed tags 075f040 Jeremy Bicha ubuntu/3.0.7-0ubuntu1 * libsoup3 Debian release 3.0.7-0ubuntu1 * https://deb.li/SAj0
[19:37] <diddledani> is livecd-rootfs project used by anyone other than ubuntu projects via launchpad? if not then it might be worth disabling the ability to specify/override the series-specific track once we've got processes in place to ensure the snaps are all appropriately configured on new series start-of-development
[20:33] <lissyx> seb128, not sure how much important that is, but my 22.04 was an upgrade during beta cycle (early march) from 21.10
[20:33] <lissyx> seb128, we just found out vainfo was showing inconsistency, since jammy is supposed to be 22.0.1 mesa but vainfo was returning 21.0.1
[20:33] <lissyx> seb128, I found about the inconsistency another way and fixed the va-api issue by reinstalling mesa-va-drivers
[20:34] <lissyx> seb128, what I am unsure iswhether I messed up manually or if it could have been some upgrade that silently failed at some point and got un-noticed
[20:35] <lissyx> (on the tram, about to get back home first two days in the paris office since more than two years now)
[20:35] <lissyx> seb128, so maybe a blip in space, or something good to know in case you get other reports of weird crashes on va-api related