[clang] [compiler-rt] [lld] [llvm] [Coverage][WebAssembly] Add initial support for WebAssembly/WASI (PR #111332)

glandium wrote: I bisected a bustage building clang with PGO on Windows to this change. While building clang with a profile-generate-enabled build of clang to gather a profile, the compiler crashes with: ``` PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include

Bug#948523: nss FTCBFS for ppc64el: wrong OS_TYPE

On Thu, Jan 09, 2020 at 09:01:18PM +0100, Helmut Grohne wrote: > Source: nss > Version: 2:3.48-1 > Tags: patch > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > > nss fails to cross build from source for ppc64el, because it passes a > wrong OS_TYPE. Thus detection of whether to build hw c

Bug#1083111: ITP: git-cinnabar -- Git remote helper to interact with mercurial repositories

Package: wnpp Severity: wishlist Owner: Mike Hommey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: git-cinnabar Version : 0.7.0~beta.2 Upstream Contact: Mike Hommey * URL : https://github.com/glandium/git-cinnabar * License : MPL-2.0 and GPL-2.0

Bug#1083111: ITP: git-cinnabar -- Git remote helper to interact with mercurial repositories

Package: wnpp Severity: wishlist Owner: Mike Hommey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: git-cinnabar Version : 0.7.0~beta.2 Upstream Contact: Mike Hommey * URL : https://github.com/glandium/git-cinnabar * License : MPL-2.0 and GPL-2.0

Bug#1083111: ITP: git-cinnabar -- Git remote helper to interact with mercurial repositories

Package: wnpp Severity: wishlist Owner: Mike Hommey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: git-cinnabar Version : 0.7.0~beta.2 Upstream Contact: Mike Hommey * URL : https://github.com/glandium/git-cinnabar * License : MPL-2.0 and GPL-2.0

Bug#1002056: Supporting alternative zlib implementations

On Wed, Sep 25, 2024 at 01:55:17AM +0200, Guillem Jover wrote: > Hi! > > On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote: > > * Guillem Jover [2024-09-24 17:45]: > > > Personally, I think fully migrating from zlib to zlib-ng would sound > > > great (even for trixie), but I guess we can

Bug#1002056: Supporting alternative zlib implementations

On Wed, Sep 25, 2024 at 01:55:17AM +0200, Guillem Jover wrote: > Hi! > > On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote: > > * Guillem Jover [2024-09-24 17:45]: > > > Personally, I think fully migrating from zlib to zlib-ng would sound > > > great (even for trixie), but I guess we can

Re: Supporting alternative zlib implementations

On Wed, Sep 25, 2024 at 01:55:17AM +0200, Guillem Jover wrote: > Hi! > > On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote: > > * Guillem Jover [2024-09-24 17:45]: > > > Personally, I think fully migrating from zlib to zlib-ng would sound > > > great (even for trixie), but I guess we can

[clang] Thread Safety Analysis: Differentiate between lock sets at real join points and expected/actual sets at function end (PR #105526)

glandium wrote: Before this change the following (reduced) code didn't emit a warning, but now does: ``` class __attribute__((capability("mutex"))) StaticMutex { public: void Lock() __attribute__((exclusive_lock_function())) { /* unimplemented */ } void Unlock() __attribute__((unlock_fun

Bug#1080470: firefox: upgrade to firefox 130.0-1 does not access external sites

> The problem is resolved by upgrading libnss3 to version 2:3.103-1, which > includes the libfreeblpriv3.so library > > Previous versions of firefox depended on the latest version of libnss3 but > 130.0-1 does not. > Upgrading libnss3 fixes this problem with firefox 130.0-1 Thank you for fising

Bug#1078468: libnss3: Fails to verify chain correctly (works on Firefox though)

clone 1078468 -1 reassign -1 libpurple0 forwarded -1 https://issues.imfreedom.org/issue/PIDGIN-17886/Certificate-verification-errors-with-NSS-3.103 thanks See the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1913047 On Sun, Aug 11, 2024 at 12:53:20PM +1000, James Tocknell wrote: >

[clang] Add flag to suppress overflow errors in C++ constant expressions. (PR #102390)

glandium wrote: > and the fix is already applied from looking at > https://android.googlesource.com/platform/frameworks/native/+/master/libs/nativewindow/include/android/hardware_buffer.h#329 it's not part of any released NDK, and it's common to be stuck with older NDKs. Most people are probab

[clang] [clang] Emit bad shift warnings (PR #70307)

glandium wrote: > > > We (Chrome) no longer need a revert - we patched the NDK locally. > > > > > > Patching the NDK is not a solution that is nice everywhere, though. And the > > new warning is an error that can't be disabled. > > FWIW, we addressed this issue and backported the fix in #1004

[clang] [clang] Emit bad shift warnings (PR #70307)

glandium wrote: > We (Chrome) no longer need a revert - we patched the NDK locally. Patching the NDK is not a solution that is nice everywhere, though. And the new warning is an error that can't be disabled. https://github.com/llvm/llvm-project/pull/70307 __

Re: Removing support for Python 3.6 (even 3.7?) this cycle (for upcoming hg-6.9)

On Thu, Jul 25, 2024 at 06:07:01AM -0700, Gregory Szorc wrote: > Historically Python version support was tied to OS’s within support windows. > And the long tail there is usually RHEL. Those timelines are listed at > https://access.redhat.com/product-life-cycles?product=Red%20Hat%20Enterprise%20L

Re: Removing support for Python 3.6 (even 3.7?) this cycle (for upcoming hg-6.9)

On Thu, Jul 25, 2024 at 06:07:01AM -0700, Gregory Szorc wrote: > Historically Python version support was tied to OS’s within support windows. > And the long tail there is usually RHEL. Those timelines are listed at > https://access.redhat.com/product-life-cycles?product=Red%20Hat%20Enterprise%20L

Bug#1076747: AttributeError: partially initialized module 'threading' has no attribute 'RLock'

Package: mercurial Version: 6.8-1 Severity: grave Dear Maintainer, Running mercurial (simply running `hg`) on trixie fails with: ``` Traceback (most recent call last): File "/usr/bin/hg", line 57, in from mercurial import dispatch File "", line 1360, in _find_and_load File "", line 13

Bug#1076747: AttributeError: partially initialized module 'threading' has no attribute 'RLock'

Package: mercurial Version: 6.8-1 Severity: grave Dear Maintainer, Running mercurial (simply running `hg`) on trixie fails with: ``` Traceback (most recent call last): File "/usr/bin/hg", line 57, in from mercurial import dispatch File "", line 1360, in _find_and_load File "", line 13

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

glandium wrote: The sad part is that MSVC and some old versions of GCC don't like `template` being added here :( https://github.com/llvm/llvm-project/pull/98547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mai

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

glandium wrote: Well, I guess this is working as intended, as adding `template` before `StorageT` fixes it. https://github.com/llvm/llvm-project/pull/98547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

glandium wrote: This broke building abseil-cpp (cd75cb4ae32c46c84cef9a9c78b42174f22ed0ac as of writing). STR: - Clone https://github.com/abseil/abseil-cpp - `cmake -B build -S abseil-cpp -DCMAKE_CXX_COMPILER=clang++ -GNinja` - `ninja -C build` https://github.com/llvm/llvm-project/pull/98547 __

Bug#1076172: pixman: FTBFS on armhf: Error: garbage following instruction -- `bne 01f'

Source: pixman Version: 0.42.2-1 Severity: serious Dear Maintainer, The package fails to build on armhf on current sid/testing with: ../../pixman/pixman-arm-simd-asm.h:821: Error: garbage following instruction -- `bne 01f' ../../pixman/pixman-arm-simd-asm.h:869: Info: macro invoked from here .

Bug#1076172: pixman: FTBFS on armhf: Error: garbage following instruction -- `bne 01f'

Source: pixman Version: 0.42.2-1 Severity: serious Dear Maintainer, The package fails to build on armhf on current sid/testing with: ../../pixman/pixman-arm-simd-asm.h:821: Error: garbage following instruction -- `bne 01f' ../../pixman/pixman-arm-simd-asm.h:869: Info: macro invoked from here .

Bug#1076172: pixman: FTBFS on armhf: Error: garbage following instruction -- `bne 01f'

Source: pixman Version: 0.42.2-1 Severity: serious Dear Maintainer, The package fails to build on armhf on current sid/testing with: ../../pixman/pixman-arm-simd-asm.h:821: Error: garbage following instruction -- `bne 01f' ../../pixman/pixman-arm-simd-asm.h:869: Info: macro invoked from here .

[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)

glandium wrote: This also breaks building the compiler-rt for older android versions, because pthread_spinlock_t is only defined when __ANDROID_API__ >= 24. https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists

Re: source tarballs vs. source from git

On Thu, Jun 13, 2024 at 08:28:28PM +0800, Sean Whitton wrote: > Hello, > > On Wed 12 Jun 2024 at 03:45pm +01, Simon McVittie wrote: > > > As far as I know, git-archive (and therefore git-deborig) doesn't guarantee > > that repeatedly archiving the same git tree produces the same tarball, > > whic

Bug#1073074: firefox: looses previous tabs

On Wed, Jun 12, 2024 at 10:55:58PM +0200, tv.debian wrote: > On Wed, 12 Jun 2024 22:40:01 +0200 Christoph Anton Mitterer > wrote: > > FYI: > > > > I haven't seen that behaviour after upgrading... and I do have quite a > > few tabs in many windows open. > > Maybe it happens not in all configurati

Bug#1073074: firefox: looses previous tabs

On Wed, Jun 12, 2024 at 10:55:58PM +0200, tv.debian wrote: > On Wed, 12 Jun 2024 22:40:01 +0200 Christoph Anton Mitterer > wrote: > > FYI: > > > > I haven't seen that behaviour after upgrading... and I do have quite a > > few tabs in many windows open. > > Maybe it happens not in all configurati

[clang] [llvm] [clang] Reland Add tanf16 builtin and support for tan constrained intrinsic (PR #94559)

glandium wrote: This broke building wasi-libc, with a crash: ``` Stack dump: 0. Program arguments: /builds/worker/fetches/clang/bin/clang-19 -cc1 -triple wasm32-unknown-wasi -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name ctanh.

Re: File descriptor hard limit is now bumped to the kernel max

On Thu, Jun 06, 2024 at 06:39:15PM +0200, Marco d'Itri wrote: > On Jun 06, Simon McVittie wrote: > > > I believe the change Luca describes is increasing rlim_max (hard limit) > > but not rlim_cur (soft limit), and the code touched by that patch is > > looking at rlim_cur, so it should be unaffect

[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

glandium wrote: Yes https://github.com/llvm/llvm-project/pull/90373 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

glandium wrote: Filed https://gitlab.kitware.com/cmake/cmake/-/issues/26031 https://github.com/llvm/llvm-project/pull/90373 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

glandium wrote: There is something wrong going on with cmake: STR: - Download [testcase.zip](https://github.com/user-attachments/files/15597940/testcase.zip) - Unzip it (it contains ClangRepl.cpp.obj and exports.def.objs) - Run `cmake -E __create_def exports.def exports.def.objs --nm=/path/to/ll

[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

glandium wrote: > Mainly about the commands of cmake building. However you build clang on windows using clang, with the addition of -DLLVM_BUILD_INSTRUMENTED=IR -DLLVM_BUILD_RUNTIME=No > Does this failure bind to a buildbot? I have no idea, but probably not, otherwise you'd have heard from it

[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

glandium wrote: What kind of detail are you looking for? https://github.com/llvm/llvm-project/pull/90373 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

glandium wrote: This broke building clang on Windows with PGO: ``` FAILED: bin/clang-repl.exe lib/clang-repl.lib cmd.exe /C "cmd.exe /C "D:\task_171745452431588\fetches\cmake\bin\cmake.exe -E __create_def D:\task_171745452431588\fetches\llvm-project\build\stage2\build\tools\clang\tools\clang-r

[clang] [Clang][Sema] Fix lookup of dependent operator= outside of complete-class contexts (PR #91498)

glandium wrote: Reverting just the SemaTemplate.cpp change fixes it. https://github.com/llvm/llvm-project/pull/91498 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix lookup of dependent operator= outside of complete-class contexts (PR #91498)

glandium wrote: This caused some breakage in something completely unrelated to operator= O_o This is from webrtc code in Firefox: ``` /tmp/gecko/third_party/libwebrtc/rtc_base/containers/flat_map.h:331:49: error: out-of-line definition of 'try_emplace' does not match any declaration in 'flat_m

How can you end up with a discrepancy between branchmap and heads?

Hi, I'm trying to reproduce a peculiarity of the (former) pypy mercurial repository (https://foss.heptapod.net/pypy/pypy) but I can't manage to reproduce locally, even if I stream-clone the original repository (with hg --config experimental.evolution=true clone --stream $url). So, what's peculiar

Outdated homepage and repository

Hi, As of writing, the www.mercurial-scm.org homepage is still showing version 6.6.3 as download, while the latest release is 6.7.2, although it's listed on https://www.mercurial-scm.org/downloads (I guess it could be related to mac and windows builds not being available?) Similarly, the main rep

Bug#1068008: rustc: Please package rust 1.75 or higher

On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote: > Hi Wesley, Yaroslav, Carsten and Mike, Hi Fabian, Let me start by thanking you for the work going into packaging rustc. > while we try to keep rustc somewhat current in sid, this is not always > possible in a timely manner. r

Bug#1068008: rustc: Please package rust 1.75 or higher

On Fri, Mar 29, 2024 at 11:14:44AM -0400, Wesley Schwengle wrote: > Package: rustc > Version: 1.70.0+dfsg1-9 > Severity: wishlist > X-Debbugs-Cc: wes...@schwengle.net > > Dear Maintainer, > > > I was trying to build a rust package from source when I noticed they use > traits. Async traits are su

Re: xz backdoor

On Wed, Apr 03, 2024 at 02:01:23AM -0400, Robert Edmonds wrote: > This backdoor abused the IFUNC mechanism in the GNU toolchain to hook into > the sshd process. Looking on my Debian sid workstation with about 1900 library > packages installed, I see a very small handful of source packages shipping

[dev-platform] --disable-bootstrap changed semantics

Hi, I know a few people are using `ac_add_options --disable-bootstrap` to avoid the regular toolchain updates when they update their tree, and rely on running `mach bootstrap` on their own schedule. Making things work for a ton of different use cases is difficult, but we've reached a different co

Bug#1061437: firefox-esr: Fails to build with Python 3.12 as default

On Tue, Feb 20, 2024 at 11:59:11PM -0500, Jeremy Bícha wrote: > Amin Bandali collected several other fixes that were necessary for > mozjs115 to build with Python 3.12 beyond the one that I noticed was > included in 115.8. > > You can find them in the python3.12 patches in > https://salsa.debian.o

Bug#1061437: firefox-esr: Fails to build with Python 3.12 as default

On Tue, Feb 20, 2024 at 11:59:11PM -0500, Jeremy Bícha wrote: > Amin Bandali collected several other fixes that were necessary for > mozjs115 to build with Python 3.12 beyond the one that I noticed was > included in 115.8. > > You can find them in the python3.12 patches in > https://salsa.debian.o

[clang] [Driver] Check the environment version except wasm case. (PR #80783)

@@ -1443,16 +1443,18 @@ Compilation *Driver::BuildCompilation(ArrayRef ArgList) { const ToolChain &TC = getToolChain( *UArgs, computeTargetTriple(*this, TargetTriple, *UArgs)); - // Check if the environment version is valid. - llvm::Triple Triple = TC.getTriple(); -

[Lldb-commits] [compiler-rt] [mlir] [clang] [libc] [flang] [clang-tools-extra] [lld] [openmp] [lldb] [llvm] [libcxx] [Driver] Report invalid target triple versions for all environment types. (PR #7865

glandium wrote: > Yes, I think so. I think adding these environment types in wasi-libc repo > could help fix those errors. WDYM? https://github.com/llvm/llvm-project/pull/78655 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.l

[compiler-rt] [mlir] [clang] [libc] [flang] [clang-tools-extra] [lld] [openmp] [lldb] [llvm] [libcxx] [Driver] Report invalid target triple versions for all environment types. (PR #78655)

glandium wrote: > Yes, I think so. I think adding these environment types in wasi-libc repo > could help fix those errors. WDYM? https://github.com/llvm/llvm-project/pull/78655 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llv

[compiler-rt] [openmp] [clang] [lldb] [mlir] [llvm] [libcxx] [flang] [libc] [lld] [clang-tools-extra] [Driver] Report invalid target triple versions for all environment types. (PR #78655)

glandium wrote: There's apparently also wasm32-wasi-preview2 and wasm32-wasi-pthread, which I suppose are equally broken by this change. https://github.com/llvm/llvm-project/pull/78655 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://li

[Lldb-commits] [compiler-rt] [openmp] [clang] [lldb] [mlir] [llvm] [libcxx] [flang] [libc] [lld] [clang-tools-extra] [Driver] Report invalid target triple versions for all environment types. (PR #7865

glandium wrote: There's apparently also wasm32-wasi-preview2 and wasm32-wasi-pthread, which I suppose are equally broken by this change. https://github.com/llvm/llvm-project/pull/78655 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://

[clang-tools-extra] [openmp] [compiler-rt] [llvm] [libcxx] [lldb] [lld] [clang] [flang] [libc] [mlir] [Driver] Report invalid target triple versions for all environment types. (PR #78655)

glandium wrote: We stumbled upon this downstream because we have jobs building wasi-sdk with clang-trunk, and wasi-sdk builds some things with that target. It apparently comes from https://github.com/WebAssembly/wasi-libc/pull/381 https://github.com/llvm/llvm-project/pull/78655 ___

[Lldb-commits] [clang-tools-extra] [openmp] [compiler-rt] [llvm] [libcxx] [lldb] [lld] [clang] [flang] [libc] [mlir] [Driver] Report invalid target triple versions for all environment types. (PR #7865

glandium wrote: We stumbled upon this downstream because we have jobs building wasi-sdk with clang-trunk, and wasi-sdk builds some things with that target. It apparently comes from https://github.com/WebAssembly/wasi-libc/pull/381 https://github.com/llvm/llvm-project/pull/78655 ___

[compiler-rt] [flang] [llvm] [openmp] [libc] [lldb] [mlir] [libcxx] [clang-tools-extra] [clang] [lld] [Driver] Report invalid target triple versions for all environment types. (PR #78655)

glandium wrote: This broke the wasi-threads target: `clang: error: version 'threads' in target triple 'wasm32-unknown-wasi-threads' is invalid` https://github.com/llvm/llvm-project/pull/78655 ___ cfe-commits mailing list cfe-commits@lists.llvm.org htt

[Lldb-commits] [compiler-rt] [flang] [llvm] [openmp] [libc] [lldb] [mlir] [libcxx] [clang-tools-extra] [clang] [lld] [Driver] Report invalid target triple versions for all environment types. (PR #7865

glandium wrote: This broke the wasi-threads target: `clang: error: version 'threads' in target triple 'wasm32-unknown-wasi-threads' is invalid` https://github.com/llvm/llvm-project/pull/78655 ___ lldb-commits mailing list lldb-commits@lists.llvm.org h

[PATCH] config.sub: recognise ARM64E machine type

ARM64E is a custom ABI for AArch64 8.3+ introducing pointer authentication codes. While technically just an ABI, it is treated as its own machine type, with triples in the format arm64e-*. Signed-off-by: Mike Hommey --- config.sub| 4 ++-- doc/config.sub.1 | 2

Re: [dev-platform] PSA: please manually update `moz-phab` to the latest version

On Tue, Jan 23, 2024 at 03:44:55PM -0800, Connor Sheehan wrote: > Hey folks, > > TL;DR: the latest version of `moz-phab` provides a fix to the update > checking mechanism. Please update your `moz-phab` install to automatically > check for the latest version. > > Slightly longer version: `moz-ph

Re: chromium and rustc in bookworm

On Mon, Jan 22, 2024 at 03:39:08AM +0200, Adrian Bunk wrote: > On Sun, Jan 21, 2024 at 06:55:31PM -0500, Andres Salomon wrote: > >... > > b) Backport the profiler patch to bookworm's rustc, and do a s-p-u update to > > Bookworm's rustc. Since this adds a new feature, I don't view it as too > > risk

[clang] [clang][PP] Add extension to predefine target OS macros (PR #74676)

glandium wrote: > We have provided a fix for zlib > ([madler/zlib#895](https://github.com/madler/zlib/pull/895)) which was > accepted by @madler. But nowhere released, not even in the repository :( https://github.com/llvm/llvm-project/pull/74676 ___

[clang] [clang][PP] Add extension to predefine target OS macros (PR #74676)

glandium wrote: > It looks like this breaks building at least `MultiSource` from > https://github.com/llvm/llvm-test-suite/. The first failure I see is when > building `llvm-test-suite/MultiSource/Applications/ClamAV/zlib_zutil.c` > > ``` > In file included from > /llvm-test-suite/MultiSource

Re: [dev-platform] Automated Recording of Pernosco Sessions in Bugzilla

On Wed, Jan 10, 2024 at 10:40:19AM -0500, Jason Kratzer wrote: > All, > > One limitation I forgot to mention is that this will only work for bugs > that trigger a crash or fatal assertion. Bugmon relies on these scenarios > in order to determine what a "failed" state looks like. Pernosco also ha

Bug#1059241: [firefox] hi-dpi broken for vertical tab list

On Fri, Dec 22, 2023 at 01:50:34AM +, Lyndon Brown wrote: > On Fri, 2023-12-22 at 10:31 +0900, Mike Hommey wrote: > > What happens if you run with MOZ_ENABLE_WAYLAND=0 ? > > > > Mike > > Back to normal. I can scroll the full list, and the list is no longer &g

Bug#1059241: [firefox] hi-dpi broken for vertical tab list

On Fri, Dec 22, 2023 at 01:09:01AM +, Lyndon Brown wrote: > Package: firefox > Version: 121.0-0 > Severity: important > > The vertical tab list (accessed via the 'down arrow' in the tab bar, to > the right of the new tab '+' button) is now no longer working correctly > for Hi-DPI as of version

Bug#1059171: firefox-esr: Firefox freezes after upgrade from 115.5 to 115.6.0esr-1~deb12u1

On Wed, Dec 20, 2023 at 10:47:19PM +0100, pierre wrote: > Package: firefox-esr > Version: 115.6.0esr-1~deb12u1 > Severity: important > X-Debbugs-Cc: pierre_aussag...@yahoo.fr, t...@security.debian.org > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropri

[clang] [Driver] Make ELF -nopie specific to OpenBSD (PR #72578)

glandium wrote: Weirdly, this leads to `warning: argument unused during compilation: '-nopie'` rather than `error: unknown argument: '-nopie'` https://github.com/llvm/llvm-project/pull/72578 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http

Bug#1056561: gcc-12: Upcoming firefox-esr FTBFS on stable

Package: gcc-12 Version: 12.2.0-14 Severity: important Dear Maintainer, Future versions of firefox-esr will contain code (related to security) that currently fails to compile with GCC 12.2. The failure is a regression from GCC 11, and was fixed in 12.3. Applying the patch[1] to 12.2 fixes the bui

Bug#1056561: gcc-12: Upcoming firefox-esr FTBFS on stable

Package: gcc-12 Version: 12.2.0-14 Severity: important Dear Maintainer, Future versions of firefox-esr will contain code (related to security) that currently fails to compile with GCC 12.2. The failure is a regression from GCC 11, and was fixed in 12.3. Applying the patch[1] to 12.2 fixes the bui

[PATCH] D138846: MC/DC in LLVM Source-Based Code Coverage: LLVM back-end and compiler-rt

glandium added a comment. There is a check already, but it's not enough: https://github.com/llvm/llvm-project/issues/52683 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D138846/new/ https://reviews.llvm.org/D138846

[PATCH] D138846: MC/DC in LLVM Source-Based Code Coverage: LLVM back-end and compiler-rt

glandium added a comment. FWIW, it's the first time for as long as I remember that mixing LLVM versions causes a runtime crash (that looks like a null deref). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D138846/new/ https://reviews.llvm.org/D1388

[PATCH] D138846: MC/DC in LLVM Source-Based Code Coverage: LLVM back-end and compiler-rt

glandium added a comment. In D138846#4656607 , @glandium wrote: > Code built with older versions of LLVM (e.g. rust) and running with the > updated runtime crash at startup with this change. FWIW, neither followups fixed this issue. The crash happens in

[PATCH] D138846: MC/DC in LLVM Source-Based Code Coverage: LLVM back-end and compiler-rt

glandium added a comment. Code built with older versions of LLVM (e.g. rust) and running with the updated runtime crash at startup with this change. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D138846/new/ https://reviews.llvm.org/D138846 __

[clang] [CMake]Fully delete the deprecated LLVM_USE_CRT* (PR #66850)

glandium wrote: > Which used to be MT and with this change is now MD. (because our script was still using LLVM_USE_CRT_RELEASE) https://github.com/llvm/llvm-project/pull/66850 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.

[clang] [CMake]Fully delete the deprecated LLVM_USE_CRT* (PR #66850)

glandium wrote: This unveiled an interesting problem in our builds: `llvm-config --cxxflags` doesn't include the `/MT`/`/MD` flag, so when building something that links with one of the .lib from LLVM, you can end up with a failure because you're not building with the same flag as LLVM was buil

Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

reassign 1052002 clang-16 affects 1052002 firefox affects 1052002 firefox-esr thanks On Fri, Sep 15, 2023 at 08:19:17PM +0200, Aurelien Jarno wrote: > Source: firefox > Version: 117.0.1-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the p

Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

reassign 1052002 clang-16 affects 1052002 firefox affects 1052002 firefox-esr thanks On Fri, Sep 15, 2023 at 08:19:17PM +0200, Aurelien Jarno wrote: > Source: firefox > Version: 117.0.1-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the p

[PATCH] D146664: Apply the same fallbacks as runtimes search for stdlib search

glandium abandoned this revision. glandium added a comment. Superseded by D159292 + D159293 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D146664/new/ https://reviews.llvm.org/D

[PATCH] D159293: [driver] Perform fallback target searches for stdlib

glandium resigned from this revision. glandium added a comment. This replaces D146664 quite nicely. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D159293/new/ https://reviews.llvm.org/D159293 _

[PATCH] D159292: [driver] Conditionally include installed libc++ headers for Android

glandium resigned from this revision. glandium added a comment. This + D159293 works great for me. Thanks a bunch. (I'm not a reviewer, though) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D159292/new/ https://re

[PATCH] D158475: [driver] Refactor getRuntimePaths. NFC

glandium added a comment. In D158475#4626636 , @smeenai wrote: > I'm halfway through an implementation of this, but I just realized that on > Android, Clang never searches for C++ headers installed alongside the driver: > https://github.com/llvm/llvm-pr

[PATCH] D158475: [driver] Refactor getRuntimePaths. NFC

glandium added a comment. In D158475#4623842 , @smeenai wrote: > In D158475#4623471 , @glandium > wrote: > >> This conflicts with D146664 > > It sounds like you want the same lo

[PATCH] D158475: [driver] Refactor getRuntimePaths. NFC

glandium added a comment. This conflicts with D146664 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D158475/new/ https://reviews.llvm.org/D158475 ___ cfe-commits mailing

Bug#1042859: cargo: Please upgrade to at least 0.67.0

Package: cargo Version: 0.66.0+ds1-1 Severity: normal 0.66 is the version of cargo that goes alongside rustc 1.65. 0.67 is the version of cargo that goes alongside rustc 1.66. Unstable and testing have rustc 1.66, so cargo should be updated to at least version 0.67. Mike

[dev-platform] The windows-sys crate is not restricted anymore

Hi, As of bug 1844001, it is now possible to import the windows-sys rust crate (only if it's version 0.48.x). It however hasn't been imported in tree, so that's still something that will be up to whoever needs to import it first. Note: the windows crate is still restricted, and will probably stay

Bug#1041016: RM: pkg-mozilla-archive-keyring -- ROM; Outdated and useless

Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove As per the RC bug against the package, the key it contains is expired, and the repository that was signed by the key has not been in use for years. It's time to retire the package completely. Mike

[PATCH] D152604: [Driver] Default -fsanitize-address-globals-dead-stripping to true for ELF

glandium added a comment. In D152604#4494975 , @rnk wrote: > It sounds like two users have hit this now: Chromium and Rust folks. s/Rust/Firefox/. And it looks like we're hitting it for the same reason: linking a static rust (LTOed) library with C++ cod

[PATCH] D145302: [clangd] Add library for clangd main function

glandium added a comment. This broke building with `-DLLVM_LINK_LLVM_DYLIB=ON`: /usr/bin/ld: tools/clang/tools/extra/clangd/refactor/tweaks/CMakeFiles/obj.clangDaemonTweaks.dir/AddUsing.cpp.o: in function `clang::clangd::(anonymous namespace)::AddUsing::prepare(clang::clangd::Tweak::Selectio

[PATCH] D152604: [Driver] Default -fsanitize-address-globals-dead-stripping to true for ELF

glandium added a comment. In the realm of unintended consequences, this broke ODR violation detection when linking a rust static library with asan enabled because, while __asan_globals_registered is COMDAT in clang, for some reason, it's not in rust... So you end up with two asan.module_ctor th

Re: Debian 13 release schedule and Debian 15 codename announcement

On Wed, Jul 05, 2023 at 10:50:34PM +0200, Joaquín Rufo Gutierrez wrote: > Hello Debian users, > > We are happy to announce that Debian 13, codenamed "Trixie", is > expected to be released sometime in 2024, following the usual 2-year > release cycle. Bookworm was released in 2023. The usual 2-year

Bug#1039566: "Uncaught exception" on crypto.getRandomValues(new Uint32Array(32))

On Tue, Jun 27, 2023 at 11:39:12AM +0200, Philipp Marek wrote: > Package: firefox > Version: 114.0-1 > Severity: grave > X-Debbugs-Cc: phil...@marek.priv.at > > Websites that need randomness ([1]) are broken, > on both Debian FF 113.0.2 and 114.0 (114.0.2 not yet available for amd64). > > Reprodu

Bug#1039566: "Uncaught exception" on crypto.getRandomValues(new Uint32Array(32))

On Tue, Jun 27, 2023 at 11:39:12AM +0200, Philipp Marek wrote: > Package: firefox > Version: 114.0-1 > Severity: grave > X-Debbugs-Cc: phil...@marek.priv.at > > Websites that need randomness ([1]) are broken, > on both Debian FF 113.0.2 and 114.0 (114.0.2 not yet available for amd64). > > Reprodu

[PATCH] D150646: [clang][X86] Add __cpuidex function to cpuid.h

glandium added a comment. In D150646#4382763 , @aidengrossman wrote: > Interesting. I would've thought `-fms-extensions` by itself would've declared > that macro (which is what I gathered reading what caused the MSVC compatible > builtins to get includ

Bug#1038889: (No Subject)

On Thu, Jun 22, 2023 at 08:48:23PM +, arizona.rover wrote: > Thread 1 "pidgin" received signal SIGILL, Illegal instruction. > 0x7fffdb7489ab in fadd (f2=0x7fffaa60, f1=0x7fffaa40, > out=0x7fffaac0) > at verified/curve25519-inline.h:40 > 40 verified/curve25519-inline.h:

Bug#1038889: (No Subject)

On Thu, Jun 22, 2023 at 08:48:23PM +, arizona.rover wrote: > Thread 1 "pidgin" received signal SIGILL, Illegal instruction. > 0x7fffdb7489ab in fadd (f2=0x7fffaa60, f1=0x7fffaa40, > out=0x7fffaac0) > at verified/curve25519-inline.h:40 > 40 verified/curve25519-inline.h:

Bug#1038889: (No Subject)

On Thu, Jun 22, 2023 at 06:38:15PM +, arizona.rover wrote: > Pidgin is dying on start-up too due to "an illegal instruction" > > Thread 1 "pidgin" received signal SIGILL, Illegal instruction. > 0x7fffdb7489ab in ?? () from /lib/x86_64-linux-gnu/libfreeblpriv3.so Can you install libnss3-db

Bug#1038889: (No Subject)

On Thu, Jun 22, 2023 at 06:38:15PM +, arizona.rover wrote: > Pidgin is dying on start-up too due to "an illegal instruction" > > Thread 1 "pidgin" received signal SIGILL, Illegal instruction. > 0x7fffdb7489ab in ?? () from /lib/x86_64-linux-gnu/libfreeblpriv3.so Can you install libnss3-db

Bug#1038434: zfsutils-linux: zfs-load-key is not run during (systemd) boot

Package: zfsutils-linux Version: 2.1.11-1 Severity: normal Dear Maintainer, There is a zfs-load-key service that is masked, and as such never starts, and the script in init.d doesn't do anything either because of that. The end result is that encrypted zfs volumes won't mount automatically during

Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

On Sun, Jun 18, 2023 at 08:15:43AM +0900, Mike Hommey wrote: > On Sun, Jun 18, 2023 at 06:09:57AM +0900, Mike Hommey wrote: > > On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote: > > > Control: tag -1 -moreinfo > > > Control: found -1 6.1.20-1 > > &

Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

On Sun, Jun 18, 2023 at 08:15:43AM +0900, Mike Hommey wrote: > On Sun, Jun 18, 2023 at 06:09:57AM +0900, Mike Hommey wrote: > > On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote: > > > Control: tag -1 -moreinfo > > > Control: found -1 6.1.20-1 > > &

Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

On Sun, Jun 18, 2023 at 06:09:57AM +0900, Mike Hommey wrote: > On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote: > > Control: tag -1 -moreinfo > > Control: found -1 6.1.20-1 > > > > On Saturday, 17 June 2023 01:00:58 CEST Mike Hommey wrote: > > &

Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

On Sun, Jun 18, 2023 at 06:09:57AM +0900, Mike Hommey wrote: > On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote: > > Control: tag -1 -moreinfo > > Control: found -1 6.1.20-1 > > > > On Saturday, 17 June 2023 01:00:58 CEST Mike Hommey wrote: > > &

  1   2   3   4   5   6   7   8   9   10   >