Re: 2.4.38
> The list is > included below and yet, I forgot to include it: 1-: clang static analyser 2-: lldb 3-: klee 4-: safecode 5-: googletest 6-: valgrind (with gdb and kgdb plugins) 7-: coccinelle 8-: sparse 9-: kcov & gcov 10-: kasan & ubsan 11-: kernel memleaks detectors 12-: linux kernel selftests 13-: kernelci 14-: oprofile 15-: Selenium WebDriver and its IDE 16-: Systemtap 17-: . goal of that is to test end to end from top to bottom of all the software stack at any granularity. Alain
Re: 2.4.38
> > You only have to look at the past few attempts (scrapped versions) > > to release apache to see the dangers in rush rush rush attitude. > > I’m assuming it’s a given that httpd should only release when ready > to. I don’t think any of the release-often advocates are suggesting > taking less care with releases or releasing untested code. My > question is would any more testing go on if we did release less > frequently? On one side I get the argument that more time between > releases theoretically allows for more testing time, but I question > whether anyone would use that time for that? My experience of > software development (outside of httpd) suggests not. To provide a 0.02$ answer to that question, last night, I went around and looked for the many amount of tools that can be used to take care of the continuous integration & continuous delivery, testing (both performance as well as debugging) and other assorted tools to help putting out the best releases of software as possible. The list is included below and include both userspace tools as well as Linux kernel tools (selftest, memleaks, kasan & ubsan...) The thing is, some software are famous for API and / or ABI breakage despite their release cycles (short like 2 weeks to a month, long like yearly releases). Which software? that is irrelevant. The few reasons I am working on that at the moment is purely for my own big@ss selfish benefits in that I was / am working for a long time as a computer tech, sysadmin, software developer and testing and I became irritated enough time by quality issues in build-it yourself distros (gentoo, funtoo, LFS+BLFS...among them, LFS+BLFS is the best quality one so far) that I want to put up a home server which will do nothing but testing using the toolset and releasing distributions images (kernel + userspace selected for various tasks, workstation or server). Side benefit is that, as soon as breakage happen (say, after a particular commit or something), I get to know immediately and report; optionally, provide a patch (which is my intended goal, short to medium-term). > Saying that, the releases do take effort and do take time to test, so > I don’t think httpd is ever going to be a fully automated “DevOps” > process that is comfortable releasing multiple times per day. As I > mentioned previous nginx seems to release once a month and that seems > about right to me but others may have a different opinion. Perhaps it > would be good to clarify that to make sure we are all on the same > understanding as to what to goal here is? Look at it this way. It is popular in software company to use scrum methodology and cut a release (internal or external) every two weeks, or, on a monthly basis with frequent new features but it can and does happen that a particular scrum cycle can be used for refactoring / bug fixes purpose with no new features added (I can't provide any more details than that). In many of those companies (those existing since a long time), it took some massive effort to migrate to a scrum based methodology from a waterfall methodology. It is my impression (and as always, I could be wrong), a similar pain look like it happen here. > Nonetheless scrapping a release is seen as a bad thing, as your > comment suggests so perhaps that needs to be addressed one way or > another. I won't comment on scrapping a release (number) but I do hope that the system I'm working on will prove useful when it is done and I can make it available. My constraints is that I can't provide any deadline for it given that my medical care now right now is tying up between 15 and 25 hours per weeks of work (medical consult, homework, helping with the number of differential diagnoses and some medical literature review to offload my medical team) for the next few years. > In summary I can understand why you got the stats you did, but I > still believe there are compelling reasons to release more frequently > (within reason). ultimately, I think frequent releases will prove useful but before, there is some pain needing to be overcome first. Alain
Offtopic: apachecon in Montréal, canucksland
Hello FYI, I can't attend apachecon for 2 reasons, I have school on all these evenings and also, it is out of my budget. That said, if any of you atteding and need a good tour guide for the local brewpubs, I'll be your guide. I do live in Montreal. Just let me know. Alain
Re: Time for 2.4.34?
Le jeudi 05 juillet 2018 à 11:43 -0400, Jim Jagielski a écrit : > Seems to me that we are just about due for a 2.4.34 release... > Anyone opposed? I volunteer to RM. +1, don't wait for my LFS patch. I'll submit for >2.4.34 (.35 or more). Alain
Re: 2.4.34 release
Le mardi 29 mai 2018 à 18:19 +0200, Graham Leggett a écrit : > On 29 May 2018, at 6:13 PM, Daniel Ruggeri > wrote: > > > I'm game for doing a T&R today and running the vote through Sunday > > (since I'm out of town starting tomorrow) if we're ready. > > > > Fellow devs? > > +1 and thanks for this. > > Regards, > Graham > — +1. Alain
Re: time for 2.4.34?
Le mardi 01 mai 2018 à 17:15 -0400, Jim Jagielski a écrit : > Considering that we have some regressions in .33 which > will soon be fixed (these are the 2 noted ShowStoppers) > as well as a limited number of "other" changes to the > codebase, maybe now is a Good Time to consider a 2.4.34...? > > I offer to RM using Daniel's updated release scripts so > we can get a different set of eyes using the scripts. I promised a patch for BLFS layout and haven't delivered yet. Will the release happen after Thursday? (I'll take Thursday to deliver the layout patch). Alain
Re: AW: A proposal...
> I would say that leaves us with Perl, Python or
> something like that as base language.
The reasons I suggested Lua previously is because it's the only programming
language modules found
in the sources of httpd:
https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/
specifically: https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/
mod_perl, mod_python and other languages modules are external to the project. I
don't know if the
presence of a particular module for a programming language is actually needed
but from the
documentation I've read about the Lua module is that it has excellent access to
the inard of httpd
which would facilitate white box testing (I'd assume the current perl framework
do the job for black
box testing).
As for platforms Lua run on: aix, bsd and {free,net,open}bsd, Linux, OSX,
windows, solaris. Probably
some more.
> If we switch the framework we need to consider that with all gaps we have, we
> already have
> a large amount of tests in the current framework that need to be ported over
> time.
Sadly, yes.
Alain
Re: A proposal...
> Hi, > +1000 on my side for more tests. > > But, IMHO, the perl framework is complex to understand for most of us. >From what I saw, the preferred scripting language having access to httpd's >internal seem to be lua at the present time. I also think that redoing (recoding) the testing framework to use Lua and get to the point where sufficient testing (for regression and anything else) is possible is a huge endeavor. I am also not aware of the history of httpd or its mailing list archive but I am willing to invest some time to make that happen (I also have 5 days of course per week and a part-time job 1 day a week plus editorship on BLFS to work on but BLFS and test case of httpd will be done jointly). Still, I will ask you all if reimplementation of the testing framework is possible / feasible in Lua? my 0.02$ Alain
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)
Le mercredi 18 avril 2018 à 19:31 -0500, Daniel Ruggeri a écrit : > On 4/18/2018 1:34 PM, Alain Toussaint wrote: > > > As an aside - httpd has a —enable-layout option in configure that defines > > > where things should > > > go. > > > If you patch the following file how you want it and submit it to us, we > > > can formally support > > > LFS > > > out the box and you can remove the need for your patch: > > > > > > https://svn.apache.org/repos/asf/httpd/sandbox/replacelimit/config.layout > > > > > > Regards, > > > Graham > > > — > > > > > > > Great idea which I'll submit to the power that be. > > > > Alain > > Minor correction to the URL for latest and greatest: > https://svn.apache.org/repos/asf/httpd/httpd/trunk/config.layout > > As we love to say, "patches welcome!" > > Feel free to just submit your diff here (since dev@ IS the power that be) > I've been tasked with the patch modification at BLFS. I'll handle it tomorrow morning and submit it. Alain
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)
Le mercredi 18 avril 2018 à 11:41 +0200, Graham Leggett a écrit : > On 17 Apr 2018, at 7:17 PM, Alain Toussaint wrote: > > > > No > > > distribution (that I am aware of) ships something called Apache httpd > > > v2.4.29. > > > > At LFS (linux from scratch), we're the exception confirming the rule of > > shipping v2.4.29 with > > the > > single patch of defining a preferred layout (the BLFS layout patch) in > > LFS/BLFS v8.2. > > > > B/LFS-svn is shipping with v2.4.33 currently. > > > > Alain (bug chaser for B/LFS and ALFS working toward editorship). > > Looking at http://www.linuxfromscratch.org/blfs/view/svn/server/apache.html > it doesn’t appear that > you’re shipping httpd at all, instead you’re directing people to get httpd > from the ASF, and are > supplying a patch to make it work with LFS. Both of these activities are > entirely fine. We do have mirrors for the cases where upstream changes deviate from the book's instruction and the automated ALFS tool draw primarily from the mirrors before hitting upstream but peoples doing thing by hands while reading the books do take the packages from upstream. > As an aside - httpd has a —enable-layout option in configure that defines > where things should go. > If you patch the following file how you want it and submit it to us, we can > formally support LFS > out the box and you can remove the need for your patch: > > https://svn.apache.org/repos/asf/httpd/sandbox/replacelimit/config.layout > > Regards, > Graham > — > Great idea which I'll submit to the power that be. Alain
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)
> No > distribution (that I am aware of) ships something called Apache httpd v2.4.29. At LFS (linux from scratch), we're the exception confirming the rule of shipping v2.4.29 with the single patch of defining a preferred layout (the BLFS layout patch) in LFS/BLFS v8.2. B/LFS-svn is shipping with v2.4.33 currently. Alain (bug chaser for B/LFS and ALFS working toward editorship).
Re: [RESULT] [VOTE] Release httpd-2.4.33
Le mercredi 21 mars 2018 à 15:38 +, Daniel Ruggeri a écrit : > Hi, all; > I am pleased to report that the vote to release httpd-2.4.33 has PASSED > with 7 binding votes > and 2 non-binding votes. I will begin the process of pushing the release out > to the mirrors today. > > Cheers! > > -- > Daniel Ruggeri Would it be possible to update the web site too (http://httpd.apache.org/download.cgi#apache24)? Thanks :) Alain
Re: apr trunk make test results on LFS
> If you are doing a 64 bit build, this is likely just a misleading output > message. See https://bz.apache.org/bugzilla/show_bug.cgi?id=45615 > comment 4 and 5. Indeed, it is a 64bit build. Forgot to add: gcc 7.3.0 with retpoline, no multilib binutils 2.30 glibc 2.27 At the moment, it's running under chroot on a debian 9.3 system. Kernel is 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u2 (2018-02-21) Alain
apr trunk make test results on LFS
Hello, I have a test log of trunk apr build with these configure settings: ./configure --prefix=/usr --disable-static --enable-nonportable-atomics --enable-threads --enable- posix-shm --enable-allocator-uses-mmap --enable-allocator-guard-pages --with-gdbm=/usr --with- openssl=/usr --with-crypto --with-installbuilddir=/usr/share/apr-dev/build --with-sqlite3=/usr -- with-libxml2=/usr of particular note, the errors I'm getting are: testlfs : |Line 345: Large Files not supported I'm compiling in a 16GB (half my ram) tmpfs on mode=0755,uid=0,gid=0 in /usr/src: (lfs chroot) root:/usr/src/apr# df -h Filesystem Size Used Avail Use% Mounted on /dev/loop0 16G 2.3G 13G 16% / udev 16G 0 16G 0% /dev tmpfs16G 0 16G 0% /run tmpfs16G 22M 16G 1% /usr/src the tmpfs might not support large file. testcrypto below: testcrypto : |Line 50: Crypto driver 'openssl' DSO could not be opened |Line 50: Crypto driver 'nss' DSO could not be opened |Line 50: Crypto driver 'commoncrypto' DSO could not be opened |Line 50: Crypto driver 'openssl' DSO could not be opened -Line 50: Crypto driver 'openssl' DSO could not be opened -Line 50: Crypto driver 'openssl' DSO could not be opened \Line 50: Crypto driver 'openssl' DSO could not be opened /Line 50: Crypto driver 'nss' DSO could not be opened |Line 50: Crypto driver 'nss' DSO could not be opened |Line 50: Crypto driver 'nss' DSO could not be opened -Line 50: Crypto driver 'nss' DSO could not be opened -Line 50: Crypto driver 'commoncrypto' DSO could not be opened [snip] SUCCESS This is on OpenSSL 1.1.0g 2 Nov 2017. Any issues between apr-2 and openssl 1.1.0g? I look at the BLFS version 2018-02-26 page (http://linuxfromscratch.org/blfs/view/systemd/general/apr-util.html) of apr-util and we don't need patches for apr-util-1.6.1 These are the only issues that I am having at the moment. Alain
Re: Fedora solved, Ubuntu still a problem?
> We entertain all test reports! No two build scenarios are identical, > so even on a given architecture, we need multiple attempts to build to > discover what we might have busted since the last release. Thanks for > the offer :) > Glad to help :) > This is based on the current svn rev building httpd against system > apr/apr-util and other packages, as well as a build of all > dependencies. I suspect the root cause exists in APR, and not httpd > itself. Ok, I'm on it. Alain
Re: Fedora solved, Ubuntu still a problem?
I've been registered to this mailing list for some time but this is my first posting. Le lundi 26 février 2018 à 15:39 -0600, William A Rowe Jr a écrit : > Somewhere along the way, this was fixed on Fedora; > I don't know whether it was a fix to system packages > or a patch we applied to apr/httpd; > > x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') > > This error message is from Ubuntu 16.04-LTS, it appears > we still have the same defect there. Just wondering if we > had applied a fix ourselves, or this was actually a packager > fix for this incredibly annoying side-effect? > > Cheers, > > Bill I volunteer on the Linux From Scratch project and have a built with the most current gcc, binutils and friends with as minimal patching as possible. Do you want me to test httpd 2.4.30 on it? (I do plan to test trunk later on...) Alain
