[02:15] <KGB-0> amtk upstream/latest 867f0b2 Sébastien Wilmet amtk/meson.build meson.build * build: don't specify any 'soversion' or 'version' for the library * https://deb.li/3BR6M
[02:15] <KGB-0> amtk upstream/latest af960f7 Sébastien Wilmet amtk/meson.build * build: set 'soversion' to 0 in the library() call * https://deb.li/ZLZ1
[02:15] <KGB-0> amtk upstream/latest f0029cf Sébastien Wilmet NEWS meson.build * Release 5.6.1 * https://deb.li/3LooN
[02:15] <KGB-2> amtk pristine-tar 576f4a1 Jeremy Bicha amtk_5.6.1.orig.tar.xz.delta amtk_5.6.1.orig.tar.xz.id * pristine-tar data for amtk_5.6.1.orig.tar.xz * https://deb.li/ip4xg
[02:15] <KGB-0> amtk upstream/latest 91359fd Jeremy Bicha NEWS amtk/meson.build meson.build * New upstream version 5.6.1 * https://deb.li/0mqV
[02:16] <KGB-0> tepl signed tags b0efddb Jeremy Bicha upstream/6.2.0 * Upstream version 6.2.0 * https://deb.li/3Z4hs
[02:16] <KGB-2> tepl pristine-tar eac6a94 Jeremy Bicha tepl_6.2.0.orig.tar.xz.delta tepl_6.2.0.orig.tar.xz.id * pristine-tar data for tepl_6.2.0.orig.tar.xz * https://deb.li/xKg4
[02:16] <KGB-0> tepl upstream/latest 2a70a41 Jeremy Bicha * pushed 26 commits (first 5 follow) * https://deb.li/BNiv
[02:16] <KGB-0> tepl upstream/latest 828539c Sébastien Wilmet tests/other-tests/test-utils-gsettings.c * utils: test tepl_utils_can_use_gsettings_key() * https://deb.li/30lcn
[02:16] <KGB-0> tepl upstream/latest 6f6dbaf Sébastien Wilmet docs/reference/api-breaks.xml * docs: ABI breaks, just need to re-compile the program * https://deb.li/dl0e
[02:16] <KGB-0> tepl upstream/latest 5d04dd8 Sébastien Wilmet docs/ more-information.md reference/intro.xml * docs: about the library soname * https://deb.li/31mC0
[02:16] <KGB-0> tepl upstream/latest 763708c Sébastien Wilmet meson.build * build: rework libtool/soname version handling * https://deb.li/3pL2A
[02:16] <KGB-0> tepl upstream/latest afe64d3 Sébastien Wilmet tests/interactive-tests/test-tab.c * test-tab: remove TeplIoErrorInfoBar tests * https://deb.li/iQo9i
[07:12] <oSoMoN> good morning
[07:45] <didrocks> good morning
[08:04] <lissyx> oSoMoN, good news bad news, llvm 15 has no x86-64 linux binary release over github
[08:05] <lissyx> oSoMoN, the only solution seems to use their apt repo, but I dont know how well that can work with snap build?
[08:11] <lissyx> https://snapcraft.io/docs/package-repositories#heading--examples ?
[08:50] <oSoMoN> salut didrocks 
[08:50] <oSoMoN> salut lissyx
[08:50] <oSoMoN> lissyx, yes, I hadn't bumped the llvm dependency precisely because there was no linux binary available on github
[08:50] <oSoMoN> it's probably worth asking whether they intend to produce one
[08:52] <oSoMoN> falling back to the apt repo would be interesting, but they don't build armhf binaries
[08:53] <lissyx> oSoMoN, so it's up to contributors to uploading one
[08:53] <lissyx> I'm trying to do that apt alternative, but I get weird behavior
[08:53] <lissyx>  0:01.43 checking for the target C compiler... /snap/gnome-3-38-2004-sdk/current/usr/bin/gcc
[08:53] <lissyx> does it makes sense we try to use gcc from gnome-sdk ?
[08:53] <oSoMoN> lissyx, is that the official answer you got from the LLVM project (re release assets)?
[08:54] <lissyx> I dont know if it qualifies as official answer from llvm project
[08:54] <lissyx> but several people asked about that on discourse and this was the reply
[08:54] <lissyx> also this is what sylvestre and glandium told me on matrix :)
[08:58] <oSoMoN> I just found https://github.com/llvm/llvm-project/issues/58004
[08:58] -ubottu:#ubuntu-desktop- Issue 58004 in llvm/llvm-project "clang+llvm-15.0.1-amd64-unknown-linux-gnu builds" [Open]
[08:58] <oSoMoN> looks like whoever usually produces the linux x86-64 builds is MIA
[09:01] <lissyx> I have some build starting with clang-15 from LLVM's apt repo
[09:08] <lissyx> oSoMoN, would switching to mozilla's bundled toolchain be a valid alternative?
[09:10] <oSoMoN> lissyx, if it's available for all the architectures we need to support (amd64, arm64, armhf), absolutely
[09:10] <lissyx> oSoMoN, I'm getting a weird build failure now
[09:11] <lissyx> > 6:25.53 /bin/sh: 1: --stop-server: not found
[09:11] <lissyx> which is likely from client.mk's call to sccache stop
[09:11] <lissyx> but it should not be done...?
[09:11] <oSoMoN> looks like the name of the executable is missing from the call
[09:11] <lissyx> oh no
[09:12] <lissyx> it's a fallout from a previous failure
[09:12] <lissyx> 4:11.51 clang: error: unable to execute command: Executable "wasm-ld-15" doesn't exist!
[09:17] <lissyx> oSoMoN, I think we support all those three, but arm* are cross-compiled for sure
[09:24] <lissyx> oSoMoN, yeah so no native toolchain on arm*
[10:20] <lissyx> oSoMoN, that being said, I'm still  wondering if it's expected we build with gcc from gnome-sdk?
[10:23] <oSoMoN> lissyx, no, the C compiler should be clang
[10:42] <lissyx> oSoMoN, have a look at the build log then :)
[10:46] <oSoMoN> https://launchpadlibrarian.net/633853973/buildlog_snap_ubuntu_focal_amd64_firefox-snap-beta_BUILDING.txt.gz reports that clang is being used to build firefox
[12:08] <Wimpy> Hello desktopers o/
[12:09] <oSoMoN> hey Wimpy 
[12:09] <Wimpy> Hello you :-)
[12:12] <Wimpy> Who here has good understand on creating "custom" GNOME sessions?
[12:15] <Wimpy> I've made a custom session which is just Mutter and appropriate settings components, defined in `/usr/share/gnome-session/sessions/butterfly.session`
[12:16] <Wimpy> I've also created `/usr/share/xsessions/butterfly-xorg.desktop` and `/usr/share/wayland-sessions/butterfly-wayland.desktop`
[12:18] <Wimpy> Both the script in `/usr/libexec/butterfly` which starts `gnome-session --builtin --session=butterfly`
[12:19] <Wimpy> LightDM and GDM both see the sessions I've added, and both can start the Butterfly Xorg session. But Butterfly Wayland fails to start and drops back to the display manager.
[12:19] <Wimpy> I can't see any obvious errors in the logs.
[12:20] <Wimpy> Testing in a QEMU VM and the Ubuntu session works just fine, so I don't believe this is an issue with drivers/GL support.
[12:21] <oSoMoN> Trevin_ho might be able to help
[12:23] <Wimpy> Is he on vacation?
[12:59] <oSoMoN> not as far as I can tell, but he's always working in an unpredictable time zone :)
[13:00] <Wimpy> Heh :-)
[13:01] <jbicha> good morning
[13:02] <Wimpy> o/
[13:04] <lissyx> oSoMoN, interesting, locally I see the GCC from GNOME SDK being used
[13:04] <lissyx> oSoMoN, also, moving to rust 1.64 I'm hitting a new failure:  5:33.94 /snap/gnome-3-38-2004-sdk/current/usr/bin/ld.gold: fatal error: out of file descriptors and couldn't close any
[13:06] <oSoMoN> that doesn't look good
[13:07] <lissyx> no
[13:07] <lissyx> and you can see, ld.gold from gnome-sdk
[13:09] <lissyx> oSoMoN, I've disabled PGO as well as the xvfb-run call, maybe this explains why it picks the incorrect compiler?
[13:09] <lissyx> either way we should make sure it's not possible
[13:11] <oSoMoN> I'm running a local build with clang-15 from apt.llvm.org, I'll let you know how that goes (my machine is not as beefy as yours so it takes a while)
[13:12] <lissyx> I tried to do that earlier this morning
[13:12] <lissyx> and it was failing due to obscure stuff around wasi-sdk
[13:14] <oSoMoN> yeah, I'm worried that it might not work because the latest release of wasi-sdk (16) is built against llvm 14
[13:16] <lissyx> either way, if gnome-sdk has some compiler we should likely force CC/CXX in mozconfig.in to use the clang one we want
[13:41] <lissyx> oSoMoN, hm even with correct CC/CXX I get wrong linker
[14:05] <lissyx> oSoMoN, so: https://paste.mozilla.org/p2PQpWWy
[14:05] <lissyx> oSoMoN, I'm getting stuff forward with that
[14:15] <lissyx> trying to re-instate PGO
=== popey9 is now known as popey
[14:30] <lissyx> oSoMoN, ok, so I've put back PGO and it's broken again :)
[14:46] <lissyx> oSoMoN, https://firefox-source-docs.mozilla.org/build/buildsystem/pgo.html any reason you force --enable-linker=gold and --enable-lto=cross ?
=== popey0 is now known as popey
[15:57] <oSoMoN> lissyx, gold is required to enable LTO, see https://llvm.org/docs/GoldPlugin.html
[15:59] <oSoMoN> and --enable-lto=cross is for performing LTO between C++ code and Rust code (see https://bugzilla.mozilla.org/show_bug.cgi?id=1546438)
[15:59] -ubottu:#ubuntu-desktop- Mozilla bug 1546438 in Firefox Build System "add `--enable-lto=cross` option" [Normal, Resolved: Fixed]
[15:59] <oSoMoN> so those two options are LTO-specific, not PGO
[15:59] <oSoMoN> IIRC this is how upstream builds are produced too
[16:02] <lissyx> oSoMoN, ok, well, even if we install binutils in build-packages section of firefox part, it still uses ld.gold from gnome-sdk ...
[16:02] <lissyx> and it fails on that, somehow.
=== popey1 is now known as popey
[17:23] <lissyx> oSoMoN, rust 1.64, no lto/gold, kept only pgo and still segfault.
[17:25] <oSoMoN> lissyx, do you also see the segfault when running xpcshell to generate a file that describes the local Normandy client, or is it failing somewhere else?
[17:25] <lissyx> I'm not yet that far
[17:26] <lissyx> I was hoping to was llvm14 + rust 1.65 ...
[17:26] <lissyx> but now I'm certain it's not the case
[17:26] <lissyx> so i'll try and poke around there yes
[17:26] <lissyx> I know it's a long shot, but the double '/' might
[17:27] <oSoMoN> I don't think so, I ran the command locally (without modifications) in the snapcraft shell and it generated the file correctly
[17:28] <oSoMoN> which suggests there is something in the build environment that triggers this crash, rather than the xpcshell binary itself being faulty
[17:29] <lissyx> yes
[17:30] <lissyx> and the env contains: 242:47.79 env LD_LIBRARY_PATH="/snap/gnome-3-38-2004-sdk/current/usr/lib/x86_64-linux-gnu:/snap/gnome-3-38-2004-sdk/current/usr/lib:../../dist//bin" :)
[17:30] <lissyx> 'dist//bin'
[17:30] <lissyx> oSoMoN, how exactly did you manually ran?
[17:36] <oSoMoN> lissyx, I ran `snapcraft --use-lxd --debug` to ensure I'm dropped into a shell when the failure happens, then I cd'ed to /root/parts/firefox/build/obj-x86_64-pc-linux-gnu/instrumented/dist/bin and ran the command that's reported to cause the segfault
[17:37] <lissyx> ok
[17:53] <lissyx> oSoMoN, same here.
[17:53] <lissyx> I'm wondering if xvfb-run could be acting?
[17:54] <oSoMoN> lissyx, that should be easy enough to test, if you're there
[17:54] <oSoMoN> (I have a clean build running now)
[17:54] <lissyx> well I tested and it did not repro
[17:54] <lissyx> but I'm not sure it's completely valid test
[17:55] <lissyx> there are so many env var we miss running manually?
[17:55] <lissyx> and I need to go now
[17:55] <oSoMoN> yes indeed, and they are not easy to set up
[17:55] <oSoMoN> let's continue debugging this tomorrow then
[21:13] <KGB-0> gedit signed tags 1a315a2 Jeremy Bicha upstream/43.1 * Upstream version 43.1 * https://deb.li/3q9Bh
[21:13] <KGB-2> gedit pristine-tar 5aeb3a9 Jeremy Bicha gedit_43.1.orig.tar.xz.delta gedit_43.1.orig.tar.xz.id * pristine-tar data for gedit_43.1.orig.tar.xz * https://deb.li/E0RI
[21:13] <KGB-0> gedit upstream/latest 2257a5f Jeremy Bicha * pushed 170 commits (first 5 follow) * https://deb.li/3iff2
[21:13] <KGB-0> gedit upstream/latest 9789717 Sergej A po/ru.po * Update Russian translation * https://deb.li/i203C
[21:13] <KGB-0> gedit upstream/latest 3e29105 Sébastien Wilmet gedit/gedit-io-error-info-bar.c * io-error-info-bar: minor code simplification * https://deb.li/wHDR
[21:13] <KGB-0> gedit upstream/latest 6f8c2ff Sébastien Wilmet gedit/gedit-io-error-info-bar.c * io-error-info-bar: better use gtk_info_bar_set_show_close_button() * https://deb.li/3t9sv
[21:13] <KGB-0> gedit upstream/latest eff97e8 Sébastien Wilmet gedit/gedit-io-error-info-bar.c * io-error-info-bar: conversion error info bar: small improvements * https://deb.li/Gfzz
[21:14] <KGB-0> gedit upstream/latest ff6ac78 Sébastien Wilmet gedit/gedit-tab.c * tab: don't use gtk_info_bar_set_default_response() * https://deb.li/3y0Us