Bug#1063916: RFP: freenginx -- a fork of nginx maintained by Maxim Dounin and the development community

[Jeffrey Walton]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: freenginx
  Version : 1.24.0
  Upstream Author : Maxim Dounin and the development community
  Section: web
* URL : http://freenginx.org/
* License : GPL
  Programming Lang: C
  Description : a fork of nginx maintained by Maxim Dounin and the
development community

-

In February 2024, Maxim Dounin forked Nginx and created the freenginx
project. According to Maxim's announcement on the nginx-users mailing
list 
():


Hello!

As you probably know, F5 closed Moscow office in 2022, and I no
longer work for F5 since then.  Still, we’ve reached an agreement
that I will maintain my role in nginx development as a volunteer.
And for almost two years I was working on improving nginx and
making it better for everyone, for free.

Unfortunately, some new non-technical management at F5 recently
decided that they know better how to run open source projects.  In
particular, they decided to interfere with security policy nginx
uses for years, ignoring both the policy and developers’ position.

That’s quite understandable: they own the project, and can do
anything with it, including doing marketing-motivated actions,
ignoring developers position and community.  Still, this
contradicts our agreement.  And, more importantly, I no longer able
to control which changes are made in nginx within F5, and no longer
see nginx as a free and open source project developed and
maintained for the public good.

As such, starting from today, I will no longer participate in nginx
development as run by F5.  Instead, I’m starting an alternative
project, which is going to be run by developers, and not corporate
entities:

http://freenginx.org/

The goal is to keep nginx development free from arbitrary corporate
actions.  Help and contributions are welcome.  Hope it will be
beneficial for everyone.

-- 
Maxim Dounin
http://freenginx.org/

Re: Ability to further support 32bit architectures

[Jeffrey Walton]

On Thu, Jan 11, 2024 at 5:45 AM Bastian Blank  wrote:
>
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more workarounds exist.  But none of them look really
> promising.

Also see .

> > Separately, I wish we had cross-builders available, and cross-build
> > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> > compiler.
>
> Real cross-builders would use some fast amd64/arm64/ppc64el (and for
> amd64 also reasonably cheap) machines to build all other architectures.

Jeff

Re: Hoping to donate/sell a Talos II motherboard

[Jeffrey Walton]

On Tue, Feb 28, 2023 at 7:46 PM  wrote:
>
> My friend has a spare Talos II motherboard that is currently sitting in his 
> house
> in Indiana USA collecting dust.
>
> https://www.raptorcs.com/TALOSII/
>
> I have convinced him to donate/sell it to an open source project or developer.
>
> I reached out to Richard Stallman, and he agreed to take the board.  I am 
> certain that the
> FSF would put it to good use.  My friend and I have not yet decided, to whom 
> we will give
> the motherboard.  Is it possible that I could give it to someone or project, 
> such that all
> parties here would benefit?
>
> Is there any project or developer here that would be willing to take this 
> motherboard and create
> virtual machines that other projects could have access to?
>
> Thoughts?

I trimmed some of the non-relevant lists.

The Talos workstations are PowerPC based. There are users on
debian-powerpc who would put it to good use.
https://lists.debian.org/debian-powerpc/ .

And I am envious of your friend. I've got a Talos on my wishlist for a
daily driver.

Jeff

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

>>> Is anybody else interested in helping? Thoughts/comments?
>>
>>Sorry to bump an old thread
>>
>>Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
>>the platform.
>>
>>Clang 3.5 and 3.6 are no longer maintained. The bugs we are
>>discovering and reporting are being closed as "invalid" and "won't
>>fix" because Clang is outside its freshness date.
>>
>>Also pick up this for glibc:
>>http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548
>>. Though it was first seen in Clang 3.3, its still a problem today.
>
> ACK, thanks for thinking about this still.
>
> Progress to date has been quiet, but work is ongoing. KiBi has a good
> set of patches ready for d-i already, and I'm working on debian-cd to
> add useful backports support. My first quick-hack attempt failed
> dismally, so I'm midway down a more disruptive but thorough set of
> changes now.

Another pothole for Clang... '-march=native' does not perform as
expected at least about one third of the time. I have not narrowed it
down, but it affects at least MacPorts and Ubuntu. Apple Clang appears
to be OK. I don't recall the results of Debian testing.

When we added code generation tests to our test script, we found Clang
was not generating SSE3, SSSE3, SSE4, AVX, BMI, etc. The work around
in the field is to cat /proc/cpuinfo, and then do something like the
following based on the CPU flags (from
http://github.com/weidai11/cryptopp/blob/master/cryptest.sh):

X86_CPU_FLAGS=$(cat /proc/cpuinfo 2>&1 | "$AWK" '{IGNORECASE=1}{if ($1
== "flags"){print;exit}}' | cut -f 2 -d ':')

if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse3") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse3"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "ssse3") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mssse3"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse4.1") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse4.1"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse4.2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse4.2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "aes") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-maes"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "pclmulqdq") -ne "0")
]]; then PLATFORM_CXXFLAGS+=("-mpclmul"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "rdrand") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mrdrnd"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "rdseed") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mrdseed"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "avx") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mavx"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "avx2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mavx2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "bmi") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mbmi"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "bmi2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mbmi2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "adx") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-madx"); fi

Most users don't realize the silent failure is occurring. Ideally,
this would be fixed in the compiler front end.

Also see Clang {3.4|3.5|3.6|3.7} only advertises SSE2:
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616723,
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616729,
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616731,
etc.

Jeff

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
>
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
>
> all rolled up with a small installer image build (netinst, maybe DVD#1).
>
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
>
> Is anybody else interested in helping? Thoughts/comments?

Sorry to bump an old thread

Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
the platform.

Clang 3.5 and 3.6 are no longer maintained. The bugs we are
discovering and reporting are being closed as "invalid" and "won't
fix" because Clang is outside its freshness date.

Also pick up this for glibc:
http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548
. Though it was first seen in Clang 3.3, its still a problem today.

Jeff

ARM64 (was: Summary of the ARM ports BoF at DC16)

[Jeffrey Walton]

> arm64
> =
>
> Most recent ARM port. All looking good now - we've been mostly able to
> move on from Juno development platforms to real server hardware
> now. We're using some APM Mustang machines and an AMD Seattle box
> hosted by ARM and Linaro at the moment, and even real arm64 server
> machines are finally coming available. Looking to move more of our ARM
> buildds over onto these arm64 servers in the future, as this will
> improve reliability and manageability.
>
> We're using a single kernel for arm64, using DTB or ACPI for
> configuration. Works well.
>
> Affordable, usable machines are available now, e.g. the Cello or
> SoftIron 1000 for ~$600. Linaro's 96boards machines are not using a
> standard form factor which is sub-optimal. There's a Marvell arm64
> board due soon (H2 2016) in ATX. The SoftIron 1000 doesn't have PCI,
> but should be good for development/buildd otherwise. Another cheap
> option is the Pine64. It's stuck on a vendor kernel for now, but
> that's being steadily worked on. Cheap: quad A53, 2GB RAM, $29.

Hats off for the ARM64 support. The best I can tell, the support is
complete - ARM64 performs just like its i386 and x86_64 older
brothers.

There are three other ARM64 gadgets worth mentioning... We purchased
them after our package maintainer, László Böszörményi, filed some bug
reports against us. We did not like playing catch-up in the QEMU
Chroot's; we wanted to get ahead of things.

* LeMaker HiKey (http://www.amazon.com/dp/B019O3QTSA), $169 USD
* SnapDragon 410c (http://www.amazon.com/dp/B01600X7IU), $75 USD
* Raspberry Pi 3 Model B (http://www.amazon.com/dp/B01CD5VC92), $38 USD

The Mustang board is a nice test platform because its an early ARMv8
board. While its ARMv8, it lacks CRC and Crypto extensions. Robert
Nelson lends us time on his Mustang, and it uncovered two bugs in our
CPU feature detection logic.

Jeff

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
>
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
>
> all rolled up with a small installer image build (netinst, maybe DVD#1).
>
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
>
> Is anybody else interested in helping? Thoughts/comments?

I think it would benefit more than Skylake users. The last few
processors are missing support. Below is from a Core i5-5300U (5th
gen) and a 3.19.0-64-generic kernel.

**

$ dmesg | egrep -i '(error|failed)'
...
[35679.953137] mce: [Hardware Error]: Machine check events logged
[35980.749723] mce: [Hardware Error]: Machine check events logged
[36280.594838] mce: [Hardware Error]: Machine check events logged
[36580.439940] mce: [Hardware Error]: Machine check events logged
[37029.202190] mce: [Hardware Error]: Machine check events logged
[37179.118743] mce: [Hardware Error]: Machine check events logged
[37629.831878] mce: [Hardware Error]: Machine check events logged
[37779.748453] mce: [Hardware Error]: Machine check events logged
[38229.510127] mce: [Hardware Error]: Machine check events logged

$ sudo mcelog
mcelog: Family 6 Model 3d CPU: only decoding architectural errors

Re: Debian package on Windows

[Jeffrey Walton]

On Wed, Mar 30, 2016 at 1:52 PM, Paul Wise  wrote:
> On Mon, Feb 22, 2016 at 10:05 PM, Jonathan Dowland wrote:
>
>> I think your message would be better addressed to the debian-devel mailing
>> list, who I have copied in to this reply so that more Debian Developers are
>> aware of it.  (There's also the Apt developer's mailing list at the
>> harder-to-discover de...@lists.debian.org who I have not copied in, as they 
>> are
>> likely all on -devel anyway)
>>
>> Personally (although I am not an Apt developer) I think it sounds like an
>> interesting idea, and there is some precedent as APT was the basis of the
>> "Fink" package management system for Apple Mac OS X.  Not re-inventing the
>> wheel is a very good idea, lots of package management problems have been
>> discovered and solved with APT already (and it's sad to see things like Ruby
>> gems, Go packages etc. re-discover the very same problems over and over 
>> again)
>
> Looks like Microsoft went with a Linux syscall emulation layer for the
> Windows kernel:
>
> http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html

Maybe worth mentioning... Some Microsoft tools use NuGet
(https://www.nuget.org/). Visual Studio uses it for its
developer-to-developer gallery of widgets and gadgets.

I don't think Microsoft will ever support a first class package
manager. They are trying to achieve exclusivity and vendor lock-in
through their app store, and a general package manager violates the
corporate goals.

Jeff

Please enable -Wabi-tag warning for C++ programs

[Jeffrey Walton]

We just took a report due to
http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

It appears Debian built the library with GCC, and GCC used
_GLIBCXX_USE_CXX11_ABI. The user then compiled with Clang and caught a
link error. The tools did not warn him about the problems, so the
report trickled downhill to us.

Would Debian please enable -Wabi-tag by default for C++ programs in
its compilers.

I think it can be done in a spec file for GCC. My apologies for not
offering the string for the specs file. Also see
http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html.

Thank you in advance.