similar to: Sending bot emails to both Git authors and committers

Hello, Please join me in welcoming Gene Cumm as official committer to the Syslinux project. In 19 years, Gene is only the third committer to this project, a reflection of his technical and community contributions over the last several years. Thank you! -hpa

My inbox has been filled with llvm.buildmaster at lab.llvm.org build failure notifications lately. The two problems appear to be: 1) Getting notifications for breakage that was introduced by an unrelated commit, often in a module I don't work on. Usually the original committer is working on or has already landed the necessary fix. 2) A cascade of dozens of notifications from various

On Tue, Sep 01, 2015 at 11:40:14PM -0300, Raphael S Carvalho via Syslinux wrote: > On Tue, Sep 1, 2015 at 8:58 PM, Paulo Alcantara via Syslinux < > syslinux at zytor.com> wrote: > > > Hi, > > > > My name is Paulo Alcantara. I've been working on BIOS/UEFI firmware and > > file systems development for a long time already. For those does not > > know,

Hi, My name is Paulo Alcantara. I've been working on BIOS/UEFI firmware and file systems development for a long time already. For those does not know, in the past few years I used to be an active Syslinux contributor and added support to NTFS and XFS file systems, GSoC mentor for Syslinux in 2012, did some bugfixes and some code refactoring (e.g. x86 assembly to pure C) and currently working

Petr Hosek via llvm-dev <llvm-dev at lists.llvm.org> writes: > One of the design principles we're trying to follow is to make everything > read-only, unless it has be writable. The only reason for .dynamic to be > writable is DT_DEBUG which is something we never intend to support. FWIW in > Fuchsia all we need is a read-only .dynamic without emitting DT_DEBUG > altogether,

I'm happy to announce that I've added Roman Kagan as a committer to the https://github.com/libguestfs/libguestfs repo. Roman has contributed many high quality patches over a period of one year. Roman, the rules are: - Post patches first on the mailing list. - Uncontroversial patches should receive one ACK before being pushed upstream. - Very complex or "controversial"

+LLDB Dev <lldb-dev at lists.llvm.org> as well for visibility. +Pavel Labath <labath at google.com> since he and I have talked about such things. On Mon, Aug 31, 2020 at 7:26 PM David Blaikie <dblaikie at gmail.com> wrote: > [+debug info folks, just as FYI - since the immediate question's more > about 3rd party library deps than the nuances of DWARF, etc] > >

Erik> I am surprised noone has mentioned the one of the biggest Erik> advantages of Git which is proper author attribution for Erik> non-core and drive-by patch contributors. >From what I can make of the git-svn docs, that LLVM committers should be adding a "From: <email>" field to commit messages instead of "Patch by <name>". If the original author is

On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There are several options, I've looked at couple of them and the one I > like the most so far is https://github.com/yhirose/cpp-httplib for a few > reasons: > > * It's MIT licensed. > * It supports Linux, macOS and Windows (and presumably other platforms). > * It

While trying to compile an existing codebase which uses handwritten assembly with LLVM, I ran into an issue around using backward references in assembly absolute expressions. A simple example can be the following snippet: _foo: .fill 0x100 _bar: .fill _bar - _foo _baz: .fill 0x100 While gas compiles this snippet without any errors, the integrated assembler throws an error: expected

Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they will drop the lock and schedule. The transaction commit needs to take a write lock for this rwsem for a very short period to switch out the commit roots. If there are a lot of threads doing this caching operation we can starve out the

Hello, I have only negative experiences with cpp-netlib - I would not recommend it. If the discussion was around only the client part I think libcURL would be the best option since it's available everywhere and is a well maintained library. But as you mention it's only the client part. We use pion (https://github.com/splunk/pion) to build a HTTP server interface, but since it seems

> We have had no trouble using "Patch by <name>" as the form of attribution for a > lot of years with contributions from a wide range of companies. So I'm not really > inclined to change a process which leaves the system of record *exactly* the > same (a textual acknowledgement of attribution) and only makes one mirror of > it superficially better. Adding

> On Sep 24, 2020, at 23:52, Petr Hosek <phosek at chromium.org> wrote: > > Using more interface libraries is definitely the right direction and a modern way to use CMake. I'm not sure if we can get to a single interface target since different runtimes have different requirements. I was assuming that we would have one interface target per dependency and use the existing CMake

Hi, On 8/10/06, Mark Bucciarelli <mark@gaiahost.coop> wrote: > > > There's a scary security alert from yesterday out and no port > update so I judged it to be isp-related. I looked for > ports-security list but didn't see one. > > You know, that might be a very good ideea -- e.g. have a security team and list for ports as we have one for the base distribution.

Thanks a lot, but tried it and I get this: CMake Error at projects/libcxx/CMakeLists.txt:361 (message): LIBCXX_ENABLE_STATIC_ABI_LIBRARY is not supported on OS X Why is it not supported? If I manually embed libc++abi.a inside libc++.a it seems to work. Thanks! ardi On Mon, Oct 1, 2018 at 4:20 AM Petr Hosek <phosek at chromium.org> wrote: > > You can use

On 01/07/2014 21:28, Alp Toker wrote: > Specifically the problem I've been seeing is that people using the > website are unable to CC mailing list-based developers. As a result I > don't get copied in on responses to my review comments, and rarely get > any kind of direct mail with threading. You end up having to dig up > historic responses in the mailing list archive

Hey all, Every few weeks, a change is committed to trunk that breaks the AVR buildbot. A problem presents when commit authors do not fix the build, and just leave it because it passes on the core buildbots. The build stays red for a few days until I go and check it. In the meantime, it likely causes spam for most if not all developers when they commit new code. All commits should keep master

Below is a copy of the email I sent to llvm-admin. If it is lost in the ether, can you reply on this thread? There's an LLD contributor looking to add an ARMv7 backend. It's a significant contribution so I'd like to land the patch under the correct author. Hi LLVM admins, I'd like to commit patches on behalf of others, but I'm not comfortable simply adding "Patch by

Ian, this one is special just for you. I''m sending it as an attachment because my email client will mangle it. This patch will remove the cmake dependency from xen prior to autoconf stubdom This patch applies ontop of [VTPM v7 3/8] vtpm/vtpmmgr and required libs to stubdom/Makefile You can apply it to your tree by doing the following: git rebase -i <VTPM v7 3/8 revision>