| 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:15 |
| 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 | 02:16 |
| oSoMoN | good morning | 07:12 |
| didrocks | good morning | 07:45 |
| lissyx | oSoMoN, good news bad news, llvm 15 has no x86-64 linux binary release over github | 08:04 |
| lissyx | oSoMoN, the only solution seems to use their apt repo, but I dont know how well that can work with snap build? | 08:05 |
| lissyx | https://snapcraft.io/docs/package-repositories#heading--examples ? | 08:11 |
| 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:50 |
| oSoMoN | falling back to the apt repo would be interesting, but they don't build armhf binaries | 08:52 |
| 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:53 |
| 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:54 |
| 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 | 08:58 |
| lissyx | I have some build starting with clang-15 from LLVM's apt repo | 09:01 |
| lissyx | oSoMoN, would switching to mozilla's bundled toolchain be a valid alternative? | 09:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| lissyx | oSoMoN, I think we support all those three, but arm* are cross-compiled for sure | 09:17 |
| lissyx | oSoMoN, yeah so no native toolchain on arm* | 09:24 |
| lissyx | oSoMoN, that being said, I'm still wondering if it's expected we build with gcc from gnome-sdk? | 10:20 |
| oSoMoN | lissyx, no, the C compiler should be clang | 10:23 |
| lissyx | oSoMoN, have a look at the build log then :) | 10:42 |
| 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 | 10:46 |
| Wimpy | Hello desktopers o/ | 12:08 |
| oSoMoN | hey Wimpy | 12:09 |
| Wimpy | Hello you :-) | 12:09 |
| Wimpy | Who here has good understand on creating "custom" GNOME sessions? | 12:12 |
| 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:15 |
| Wimpy | I've also created `/usr/share/xsessions/butterfly-xorg.desktop` and `/usr/share/wayland-sessions/butterfly-wayland.desktop` | 12:16 |
| Wimpy | Both the script in `/usr/libexec/butterfly` which starts `gnome-session --builtin --session=butterfly` | 12:18 |
| 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:19 |
| 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:20 |
| oSoMoN | Trevin_ho might be able to help | 12:21 |
| Wimpy | Is he on vacation? | 12:23 |
| oSoMoN | not as far as I can tell, but he's always working in an unpredictable time zone :) | 12:59 |
| Wimpy | Heh :-) | 13:00 |
| jbicha | good morning | 13:01 |
| Wimpy | o/ | 13:02 |
| 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:04 |
| oSoMoN | that doesn't look good | 13:06 |
| lissyx | no | 13:07 |
| lissyx | and you can see, ld.gold from gnome-sdk | 13:07 |
| 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:09 |
| 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:11 |
| lissyx | I tried to do that earlier this morning | 13:12 |
| lissyx | and it was failing due to obscure stuff around wasi-sdk | 13:12 |
| oSoMoN | yeah, I'm worried that it might not work because the latest release of wasi-sdk (16) is built against llvm 14 | 13:14 |
| 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:16 |
| lissyx | oSoMoN, hm even with correct CC/CXX I get wrong linker | 13:41 |
| lissyx | oSoMoN, so: https://paste.mozilla.org/p2PQpWWy | 14:05 |
| lissyx | oSoMoN, I'm getting stuff forward with that | 14:05 |
| lissyx | trying to re-instate PGO | 14:15 |
| === popey9 is now known as popey | ||
| lissyx | oSoMoN, ok, so I've put back PGO and it's broken again :) | 14:30 |
| lissyx | oSoMoN, https://firefox-source-docs.mozilla.org/build/buildsystem/pgo.html any reason you force --enable-linker=gold and --enable-lto=cross ? | 14:46 |
| === popey0 is now known as popey | ||
| oSoMoN | lissyx, gold is required to enable LTO, see https://llvm.org/docs/GoldPlugin.html | 15:57 |
| 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 | 15:59 |
| 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. | 16:02 |
| === popey1 is now known as popey | ||
| lissyx | oSoMoN, rust 1.64, no lto/gold, kept only pgo and still segfault. | 17:23 |
| 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:25 |
| 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:26 |
| oSoMoN | I don't think so, I ran the command locally (without modifications) in the snapcraft shell and it generated the file correctly | 17:27 |
| oSoMoN | which suggests there is something in the build environment that triggers this crash, rather than the xpcshell binary itself being faulty | 17:28 |
| lissyx | yes | 17:29 |
| 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:30 |
| 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:36 |
| lissyx | ok | 17:37 |
| lissyx | oSoMoN, same here. | 17:53 |
| lissyx | I'm wondering if xvfb-run could be acting? | 17:53 |
| 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:54 |
| 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 | 17:55 |
| 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:13 |
| 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 | 21:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!