Re: Status for 2.4.20
On Wed, Mar 30, 2016 at 11:02 AM, Nick Edwardswrote: > So after a thread stop message, why do you feel you need to troll bait them? > It's clear they both agreed to ignore each other, it's been clear one party > had no intention on keeping his word (having had myriad of clashes with the > fool reindl myself on other lists I'm not at all surprised he expected it to > all one way), so the other advises " gates of hell will open ", so, what's > your angle? My angle is that William's warning (seconded by mine, maybe unnecessarily) also applies to the friend(s) of the one or the other willing to continue on this road...
Re: Status for 2.4.20
So after a thread stop message, why do you feel you need to troll bait them? It's clear they both agreed to ignore each other, it's been clear one party had no intention on keeping his word (having had myriad of clashes with the fool reindl myself on other lists I'm not at all surprised he expected it to all one way), so the other advises " gates of hell will open ", so, what's your angle? what's the point of your post, posts like yours only invites trouble. If they don't want to adhere to thread stop William will wield his big stick as he clams to have, their problem. On Wed, Mar 30, 2016 at 8:15 AM, Yann Ylavicwrote: > On Wed, Mar 30, 2016 at 7:49 AM, William A Rowe Jr > wrote: > > FULL STOP. > > Really, NOW, simply don't talk to each other here (this way at least, > but anyway is fine too since it seems hopeless). > > You are able to block each other on your respective networks, well, > keep reading your logs for bounced emails if it pleases you, but this > list (or any @a.o one) is definitively not an loop-hole! >
Re: Status for 2.4.20
On Wed, Mar 30, 2016 at 7:49 AM, William A Rowe Jrwrote: > FULL STOP. Really, NOW, simply don't talk to each other here (this way at least, but anyway is fine too since it seems hopeless). You are able to block each other on your respective networks, well, keep reading your logs for bounced emails if it pleases you, but this list (or any @a.o one) is definitively not an loop-hole!
Re: Status for 2.4.20
FULL STOP. The next person to demand the last word of this thread will be iptables deleted from existence at a.o. Can you all appreciate that ~2000 people have to read all of your pissing contests? This is simply not acceptable. Be done with it.
Re: Status for 2.4.20
your short memory returns again, thank you, as that terminates any and all prior agreements we had about (not) responding to each other and your diatribe, the flood gates have now opened. But as for this post, so it seems I did, I probably stopped reading half way, my care factor isnt all that high On 29/03/2016 18:47, Reindl Harald wrote: you did -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/
Re: Status for 2.4.20
Am 29.03.2016 um 09:37 schrieb Noel Butler: On 29/03/2016 01:06, William A Rowe Jr wrote: @Everyone on this thread - keep it civil. On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler <noel.but...@ausics.net <mailto:noel.but...@ausics.net>> wrote: On 25/03/2016 19:52, Graham Leggett wrote: On 23 Mar 2016, at 1:58 PM, Noel Butler <noel.but...@ausics.net <mailto:noel.but...@ausics.net>> wrote: as stated previously, this shit will happen when certain people push with a release often mentality AFAIK there is *ZERO* critical exploit bugs to be patched by any pending release, so lets get house in order S T A B L E , then worry about releases, jesus christ, we are not ubuntu or redhat with set programs to release every 3 or 6 months regardless if shit is ready or not. It sounds like you're making drama where there is none. sounds like you only look at this from one perspective, and thats not of the users, especially, the larger users. Going by this, I've not seen some posts, Bills reply makes it appear I said the above, which I didnt you did Weitergeleitete Nachricht Betreff: Re: Status for 2.4.20 Datum: Wed, 23 Mar 2016 21:58:18 +1000 Von: Noel Butler <noel.but...@ausics.net> Antwort an: dev@httpd.apache.org An: dev@httpd.apache.org as stated previously, this shit will happen when certain people push with a release often mentality AFAIK there is *ZERO* critical exploit bugs to be patched by any pending release, so lets get house in order S T A B L E , then worry about releases, jesus christ, we are not ubuntu or redhat with set programs to release every 3 or 6 months regardless if shit is ready or not. flame away... IDGAF Weitergeleitete Nachricht ---- Betreff: Re: Status for 2.4.20 Datum: Sat, 26 Mar 2016 13:13:33 +1000 Von: Noel Butler <noel.but...@ausics.net> Antwort an: dev@httpd.apache.org An: dev@httpd.apache.org On 25/03/2016 19:52, Graham Leggett wrote: > It sounds like you're making drama where there is none. sounds like you only look at this from one perspective, and thats not of the users, especially, the larger users. signature.asc Description: OpenPGP digital signature
Re: Status for 2.4.20
On 29/03/2016 01:06, William A Rowe Jr wrote: > @Everyone on this thread - keep it civil. > > On Fri, Mar 25, 2016 at 10:13 PM, Noel Butlerwrote: > On 25/03/2016 19:52, Graham Leggett wrote: > On 23 Mar 2016, at 1:58 PM, Noel Butler wrote: > > as stated previously, this shit will happen when certain people push with a > release often mentality > > AFAIK there is *ZERO* critical exploit bugs to be patched by any pending > release, so lets get house in order S T A B L E , then worry about releases, > jesus christ, we are not ubuntu or redhat with set programs to release every > 3 or 6 months regardless if shit is ready or not. > It sounds like you're making drama where there is none. sounds like you only look at this from one perspective, and thats not of the users, especially, the larger users. Precisely the point. If httpd were commercial software, there would only be one perspective, that of the largest users with fairly static deployments that demand very small deltas - those that ensure few if any regressions. Smaller or more nimble users who need the most recent features are neglected in that scenario. Instead httpd does not operate as commercial software, it is open source. When it breaks, you get to keep (and patch) all the pieces. That's the origin story of this software and our continued model for success. No amount of pleas that "it shouldn't be that way" are going to change the mindset of the project participants. Please remember you are a guest on this list. When we decided during 1.3.x that things were so shaky (third party module recompilation was frequently necessary during the early 1.3.0-1.3.14 versions) that we could do better for user communities. Therefore, when we released 2.0 as GA, we declared the ABI stable, and proceeded on ABI and API breaking work on a 2.1-dev trunk branch. We all agreed that 2.1 wouldn't be GA, but we would release 2.2.0 once we believed that branch was ready to be ABI-stable. That model continues to this day, breaking changes are on 2.5-dev in trunk, and we seek 100% compatibility on the 2.4.x branch. There were contentious discussions that led us to this model, but it was driven by competing interests by the developers of this project, who are also users --- as opposed to external "demands". We will seek to continue to release early and often, and one of our current faults is that we haven't been releasing 2.5-dev often enough to engage users in the next release series, but pouring most of our energy into wedging these changes back into the 2.4.x branch. But unlike commercial software and many OSS projects, we don't declare 2.4.0 to be "feature complete", and we continue to improve it in straightforward ways throughout the 2.4 lifetime. If you want to package a stable "product", you can follow the RedHat and others' model. Just to take that single example, httpd 2.4.3 is the released flavor by RedHat. They go to the extra effort to backport fixes-only and plan to support that version for some 10 years or so. That is why many larger users choose to stick with something like RHEL or CentOS or similar distributions which are feature-frozen and much more stable than an active product undergoing constant enhancement. Just to wrap up another tl;dr post... others offered you a different option, skip those versions which are too "experimental" for your tastes, and wait for bugs to shake out. We assert that 2.4.newest is the best available version, but in such a large, modular and flexible project, it's impossible to assure that a change set (release) will be an improvement for each and every use case. Use the version that is most appropriate to your use case, and seek a commercial product if you expect the sort of stasis that your protest appears to seek. Going by this, I've not seen some posts, Bills reply makes it appear I said the above, which I didnt, but I'll leave it as I think this thread has run its course anyway, I've put my comments forward on behalf of myself and many admins, I accept you only see this as one opinion since they are not posting here, next time it comes up, I'll put a call on the other lists for every single one of them to sub to this list and put their thoughts forward :) -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/
Re: Status for 2.4.20
+1 Thanks! > Am 28.03.2016 um 17:06 schrieb William A Rowe Jr: > > @Everyone on this thread - keep it civil. > >> On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler wrote: >>> On 25/03/2016 19:52, Graham Leggett wrote: >>> On 23 Mar 2016, at 1:58 PM, Noel Butler wrote: >>> as stated previously, this shit will happen when certain people push with a release often mentality AFAIK there is *ZERO* critical exploit bugs to be patched by any pending release, so lets get house in order S T A B L E , then worry about releases, jesus christ, we are not ubuntu or redhat with set programs to release every 3 or 6 months regardless if shit is ready or not….. >>> >>> It sounds like you’re making drama where there is none. >> >> sounds like you only look at this from one perspective, and thats not of the >> users, especially, the larger users. > > Precisely the point. If httpd were commercial software, there would only be > one perspective, that of the largest users with fairly static deployments that > demand very small deltas - those that ensure few if any regressions. Smaller > or more nimble users who need the most recent features are neglected in that > scenario. > > Instead httpd does not operate as commercial software, it is open source. > When it breaks, you get to keep (and patch) all the pieces. That's the origin > story of this software and our continued model for success. No amount of > pleas that "it shouldn't be that way" are going to change the mindset of the > project participants. Please remember you are a guest on this list. > > When we decided during 1.3.x that things were so shaky (third party module > recompilation was frequently necessary during the early 1.3.0-1.3.14 versions) > that we could do better for user communities. > > Therefore, when we released 2.0 as GA, we declared the ABI stable, and > proceeded on ABI and API breaking work on a 2.1-dev trunk branch. We all > agreed that 2.1 wouldn't be GA, but we would release 2.2.0 once we believed > that branch was ready to be ABI-stable. That model continues to this day, > breaking changes are on 2.5-dev in trunk, and we seek 100% compatibility > on the 2.4.x branch. There were contentious discussions that led us to this > model, but it was driven by competing interests by the developers of this > project, who are also users --- as opposed to external "demands". > > We will seek to continue to release early and often, and one of our current > faults is that we haven't been releasing 2.5-dev often enough to engage users > in the next release series, but pouring most of our energy into wedging these > changes back into the 2.4.x branch. But unlike commercial software and > many OSS projects, we don't declare 2.4.0 to be "feature complete", and > we continue to improve it in straightforward ways throughout the 2.4 lifetime. > > If you want to package a stable "product", you can follow the RedHat and > others' model. Just to take that single example, httpd 2.4.3 is the released > flavor by RedHat. They go to the extra effort to backport fixes-only and plan > to support that version for some 10 years or so. That is why many larger > users choose to stick with something like RHEL or CentOS or similar > distributions which are feature-frozen and much more stable than an active > product undergoing constant enhancement. > > Just to wrap up another tl;dr post... others offered you a different option, > skip those versions which are too "experimental" for your tastes, and wait > for bugs to shake out. We assert that 2.4.newest is the best available > version, but in such a large, modular and flexible project, it's impossible > to assure that a change set (release) will be an improvement for each and > every use case. > > Use the version that is most appropriate to your use case, and seek a > commercial product if you expect the sort of stasis that your protest > appears to seek. > >
Re: Status for 2.4.20
@Everyone on this thread - keep it civil. On Fri, Mar 25, 2016 at 10:13 PM, Noel Butlerwrote: > On 25/03/2016 19:52, Graham Leggett wrote: > >> On 23 Mar 2016, at 1:58 PM, Noel Butler wrote: >> >> as stated previously, this shit will happen when certain people push with >>> a release often mentality >>> >>> AFAIK there is *ZERO* critical exploit bugs to be patched by any pending >>> release, so lets get house in order S T A B L E , then worry about >>> releases, jesus christ, we are not ubuntu or redhat with set programs to >>> release every 3 or 6 months regardless if shit is ready or not….. >>> >> >> It sounds like you’re making drama where there is none. >> > > sounds like you only look at this from one perspective, and thats not of > the users, especially, the larger users. Precisely the point. If httpd were commercial software, there would only be one perspective, that of the largest users with fairly static deployments that demand very small deltas - those that ensure few if any regressions. Smaller or more nimble users who need the most recent features are neglected in that scenario. Instead httpd does not operate as commercial software, it is open source. When it breaks, you get to keep (and patch) all the pieces. That's the origin story of this software and our continued model for success. No amount of pleas that "it shouldn't be that way" are going to change the mindset of the project participants. Please remember you are a guest on this list. When we decided during 1.3.x that things were so shaky (third party module recompilation was frequently necessary during the early 1.3.0-1.3.14 versions) that we could do better for user communities. Therefore, when we released 2.0 as GA, we declared the ABI stable, and proceeded on ABI and API breaking work on a 2.1-dev trunk branch. We all agreed that 2.1 wouldn't be GA, but we would release 2.2.0 once we believed that branch was ready to be ABI-stable. That model continues to this day, breaking changes are on 2.5-dev in trunk, and we seek 100% compatibility on the 2.4.x branch. There were contentious discussions that led us to this model, but it was driven by competing interests by the developers of this project, who are also users --- as opposed to external "demands". We will seek to continue to release early and often, and one of our current faults is that we haven't been releasing 2.5-dev often enough to engage users in the next release series, but pouring most of our energy into wedging these changes back into the 2.4.x branch. But unlike commercial software and many OSS projects, we don't declare 2.4.0 to be "feature complete", and we continue to improve it in straightforward ways throughout the 2.4 lifetime. If you want to package a stable "product", you can follow the RedHat and others' model. Just to take that single example, httpd 2.4.3 is the released flavor by RedHat. They go to the extra effort to backport fixes-only and plan to support that version for some 10 years or so. That is why many larger users choose to stick with something like RHEL or CentOS or similar distributions which are feature-frozen and much more stable than an active product undergoing constant enhancement. Just to wrap up another tl;dr post... others offered you a different option, skip those versions which are too "experimental" for your tastes, and wait for bugs to shake out. We assert that 2.4.newest is the best available version, but in such a large, modular and flexible project, it's impossible to assure that a change set (release) will be an improvement for each and every use case. Use the version that is most appropriate to your use case, and seek a commercial product if you expect the sort of stasis that your protest appears to seek.
Re: Status for 2.4.20
On 26/03/2016 22:54, Reindl Harald wrote: *yawn* grow up! especially with your off-list hate-mails while block responses off-list hate mails? The message was pretty clear you emailed me asking me never to reply to any of your posts some time ago, I emailed you reminding you that works both fscking ways and if you didnt like that hell will be unleashed upon you. also, the DNSBL blacklisting on you for your antics of past 2+ years or so still stands given what I've witnessed even in recent times. If you are going to be abusive, and blackmailing people, you have to live with reactions to your actions, it is only appropriate a DNSBL "tell" people why a host is blocked, just proudly doing my job :) if you were not a complete arsehole, none of those list moderations, bannings and so on would have occurred, but seems like you will never change, consider this the last time i reply to you on this list, and thank you for re-justifying the DNSBL listing. happy easter -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/
Re: Status for 2.4.20
On 3/23/2016 7:27 AM, Jim Jagielski wrote: > Release Often is hardly a Bad Thing, at least IMHO. When the > time is right for a release, then we release. It seemed a > good time, again IMHO. Kinda late to the party, but shouldn't what's committed to a stable branch _always_ be ready to release? Just my .02 on the side conversation. As a sysadmin, I have no strong preference for release often versus release seldom... just so long as what is released is stable and won't break my stuff. At $dayjob where I have to answer to regulatory and audit authorities, there have been plenty of releases of various software platforms that I have chosen not to pursue because they don't address anything I need to worry about. No harm done. So, my stance as a sysadmin (and probably a fairly common stance, I'd guess) can be summarized as: If there's a bug fix for a problem I'm seeing, I'd really like the release sooner rather than later. On the other hand, if there's a security fix, I need it released immediately. On yet another hand (because it seems I have three), if the release has nothing I care about... then I don't care. But whatever happens, don't break my configs :-) As an even further side note... after following this dev list (community) as long as I have, I'd happily put an httpd 2.4.nightly against just about any other released software. I can't think of a single case where something got *committed* to 2.4 that would break my configs let alone something that got formally released. Indeed, the few thousand httpd servers I run haven't been harmed by a release in all of my time as an admin (1.3, 2.0 and 2.4 alike). Our release process is, indeed, pretty damn good. So whether we release often or release seldom, we can at least hold our head high while we do it. -- Daniel Ruggeri
Re: Status for 2.4.20
Am 26.03.2016 um 04:44 schrieb Noel Butler: On 26/03/2016 13:32, Reindl Harald wrote: Am 26.03.2016 um 04:13 schrieb Noel Butler: On 25/03/2016 19:52, Graham Leggett wrote: On 23 Mar 2016, at 1:58 PM, Noel Butlerwrote: as stated previously, this shit will happen when certain people push with a release often mentality AFAIK there is *ZERO* critical exploit bugs to be patched by any pending release, so lets get house in order S T A B L E , then worry about releases, jesus christ, we are not ubuntu or redhat with set programs to release every 3 or 6 months regardless if shit is ready or not….. It sounds like you’re making drama where there is none. sounds like you only look at this from one perspective, and thats not of the users, especially, the larger users. if it has no relevant bugfixes for you - just don't upgrade - so what why should others wait for probably relevant fixes longer just because you are annoyed by an update nobody is forcing you to install? *yawn* grow up! especially with your off-list hate-mails while block responses signature.asc Description: OpenPGP digital signature
Re: Status for 2.4.20
On 26/03/2016 13:32, Reindl Harald wrote: Am 26.03.2016 um 04:13 schrieb Noel Butler: On 25/03/2016 19:52, Graham Leggett wrote: On 23 Mar 2016, at 1:58 PM, Noel Butlerwrote: as stated previously, this shit will happen when certain people push with a release often mentality AFAIK there is *ZERO* critical exploit bugs to be patched by any pending release, so lets get house in order S T A B L E , then worry about releases, jesus christ, we are not ubuntu or redhat with set programs to release every 3 or 6 months regardless if shit is ready or not….. It sounds like you’re making drama where there is none. sounds like you only look at this from one perspective, and thats not of the users, especially, the larger users. if it has no relevant bugfixes for you - just don't upgrade - so what why should others wait for probably relevant fixes longer just because you are annoyed by an update nobody is forcing you to install? *yawn* -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/
Re: Status for 2.4.20
Am 26.03.2016 um 04:13 schrieb Noel Butler: On 25/03/2016 19:52, Graham Leggett wrote: On 23 Mar 2016, at 1:58 PM, Noel Butlerwrote: as stated previously, this shit will happen when certain people push with a release often mentality AFAIK there is *ZERO* critical exploit bugs to be patched by any pending release, so lets get house in order S T A B L E , then worry about releases, jesus christ, we are not ubuntu or redhat with set programs to release every 3 or 6 months regardless if shit is ready or not….. It sounds like you’re making drama where there is none. sounds like you only look at this from one perspective, and thats not of the users, especially, the larger users. if it has no relevant bugfixes for you - just don't upgrade - so what why should others wait for probably relevant fixes longer just because you are annoyed by an update nobody is forcing you to install? signature.asc Description: OpenPGP digital signature
Re: Status for 2.4.20
On 25/03/2016 19:52, Graham Leggett wrote: On 23 Mar 2016, at 1:58 PM, Noel Butlerwrote: as stated previously, this shit will happen when certain people push with a release often mentality AFAIK there is *ZERO* critical exploit bugs to be patched by any pending release, so lets get house in order S T A B L E , then worry about releases, jesus christ, we are not ubuntu or redhat with set programs to release every 3 or 6 months regardless if shit is ready or not….. It sounds like you’re making drama where there is none. sounds like you only look at this from one perspective, and thats not of the users, especially, the larger users. -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/
Re: Status for 2.4.20
On 23 Mar 2016, at 1:58 PM, Noel Butlerwrote: > as stated previously, this shit will happen when certain people push with a > release often mentality > > AFAIK there is *ZERO* critical exploit bugs to be patched by any pending > release, so lets get house in order S T A B L E , then worry about releases, > jesus christ, we are not ubuntu or redhat with set programs to release every > 3 or 6 months regardless if shit is ready or not….. It sounds like you’re making drama where there is none. We have a release process designed to catch problems before they reach the public. That release process caught a problem, and that problem is being dealt with as per that release process. The system is working, nothing to see here. Regards, Graham —
Re: Status for 2.4.20
On 23/03/2016 22:27, Jim Jagielski wrote: I see your point and have no intent or desire to flame. Release Often is hardly a Bad Thing, at least IMHO. When the time is right for a release, then we release. It seemed a good time, again IMHO. My opinion that "this shit will happen" when, despite lots of notice of intent to tag, and reminders to test, etc.. people simply DON'T, wait for the test tarball, find breakage, and then apply major restructure/refactor "at the last minute". Sure, stuff that like occasionally will happen, and it is, after all, why we create test tarballs and call for a vote. But when it becomes the rule instead of the exception, then we have an issue w/ the process and the workflow. Frequent release, IMHO, are an indication of health and project vitality. When Apache httpd is suffering from the You also need to look at it from the side of system admins, not just as coder. Many admins see frequent releases as something that's bug riddled You don't hear them saying the same about other software, eg: postfix, which releases not so frequently (though puts new things in the unstable branch) Dovecot is a great example of release often with F-ups, and it doesn't take much to see that it has problems which need addressing soon after each release, phpmyadmin releases often, so often, even Marc got sick of it and decided there would be minimum monthly updates, instead of bi-weekly updates, I know admins running phpmyadmin thats over a year old because they got sick of upgrading every few days. So it works both ways, releasing every 5 or 6 months shows an active _stable_ project, evervy month or two and it raises alarms. But thats just my opinion which does tend to be a general consensus on many system admin lists/irc chans. -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
On Thu, Mar 24, 2016 at 11:40 AM, Jan Ehrhardtwrote: > William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 09:16:17 > -0500): > >> > http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html > > > >It's been a *long* time, and I know it hadn't been that well maintained > >for non-Linux (non-BSD) target architectures. > > On the contrary: Windows support for PHP has made a big jump. The release > master of PHP7 is even a Microsoft employee. > Excellent! >> Even in the 32-bits PHP 7 there are some: > >> > >> > http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html > > > >With a bit of luck - many of these are resolved by simply jumping up to > >Visual Studio 2015 (and removing any number of win32-specific bandaids > >that covered some warts in the earlier stdc lib)? > > Read carefully: these are the results when compiling with VC14 == VS2015. > This is the way the official PHP7 binaries are built. > And in fairness, not every "conversion from 'size_t' to 'unsigned int'" error is actually a lurking bug. If you know the memory allocation can't exceed some fixed size (e.g. passed as an httpd header value that already enjoys truncation or rejection much earlier in the process), then that flag would generally mean nothing. It's a long process to get such things 100% correct, we have a few defects lingering in httpd 2.4 release branch today - some due to binary ABI restrictions. My entire point is that VC14 makes such a thing possible, where it really wasn't possible while Microsoft was ignoring POSIX in many places.
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 09:16:17 -0500): >> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html > >It's been a *long* time, and I know it hadn't been that well maintained >for non-Linux (non-BSD) target architectures. On the contrary: Windows support for PHP has made a big jump. The release master of PHP7 is even a Microsoft employee. >> Even in the 32-bits PHP 7 there are some: >> >> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html > >With a bit of luck - many of these are resolved by simply jumping up to >Visual Studio 2015 (and removing any number of win32-specific bandaids >that covered some warts in the earlier stdc lib)? Read carefully: these are the results when compiling with VC14 == VS2015. This is the way the official PHP7 binaries are built. Jan
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
On Thu, Mar 24, 2016 at 3:40 PM, William A Rowe Jrwrote: > On Thu, Mar 24, 2016 at 9:31 AM, Yann Ylavic wrote: >> >> Not to talk about they very personal conception of sizeof(long) on >> 64bit systems... > > You might be too young to remember when pointers had little to > no relation to integer registers on many cpu architectures :) I'm afraid not :( I wasn't talking about pointers here, though, but I agree that numeric types have never been something consistent accross platforms either. Simply now that char/short/int/long types could have had (finally!) there own size, and a common and consistent agreement on, for all/most modern systems... it failed. They surely had good reasons to do so, though it might just have moved/postponed the issues (to portable coders, at least). But after all, let's all use the APR! :)
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
On Thu, Mar 24, 2016 at 9:31 AM, Yann Ylavicwrote: > >> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or > >> variable may be unsafe. Consider using vsnprintf_s instead. To disable > >> deprecation, use _CRT_SECURE_NO_WARNINGS. > > [sarcasm] > Microsoft being unable to provide a safe vsnprintf() in the first > place and now warning every user is kind of ironic. > Microsoft claims that all the non-MS foo_s variants that have buffer targets as defined by POSIX are insecure, and offer foo_s variants. We have apr's safe strncpy etc, so it's not like we didn't agree - at least for some cases. They are free to make any claim they like, but they offered an out... from these warnings ... -D_CRT_SECURE_NO_DEPRECATE > Not to talk about they very personal conception of sizeof(long) on > 64bit systems... > You might be too young to remember when pointers had little to no relation to integer registers on many cpu architectures :) [/sarcasm] > > Not a very constructive comment, I agree :) > :)
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
>> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or >> variable may be unsafe. Consider using vsnprintf_s instead. To disable >> deprecation, use _CRT_SECURE_NO_WARNINGS. [sarcasm] Microsoft being unable to provide a safe vsnprintf() in the first place and now warning every user is kind of ironic. Not to talk about they very personal conception of sizeof(long) on 64bit systems... [/sarcasm] Not a very constructive comment, I agree :)
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
On Thu, Mar 24, 2016 at 8:49 AM, Jan Ehrhardtwrote: > William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 07:58:45 > -0500): > >Precisely, Jan. We don't know where these truncation errors lead - do > they > >portentially open security holes? They cetainly interefere with serving > >huge resources such as .iso images. > > > >When I first tripped over this, I breifly pondered putting together a > >patch. PHP, httpd (through apr) dealt with all this long ago. > > Apparently, you never compiled PHP 5.5/5.6/7.0 on Windows 64-bits. There > are loads of 'possible loss of data' warnings. See for yourself: > > http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html It's been a *long* time, and I know it hadn't been that well maintained for non-Linux (non-BSD) target architectures. > Even in the 32-bits PHP 7 there are some: > > http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html With a bit of luck - many of these are resolved by simply jumping up to Visual Studio 2015 (and removing any number of win32-specific bandaids that covered some warts in the earlier stdc lib)? Remaining errors likely still need fixing. That sizeof(int) == sizeof(void *) assumption from 64ILP architectures is *not* part of the spec. We have 64ILP (int == long == void*), 64LP (long == void* != int) as well as 64P (long == int != void*) and each of these are valid architectures. The various types such as ptrdiff_t that POSIX exposes *should* resolve these all when the correct types are chosen, and that is now true with MSVC 14 on Windows as well. It just becomes a matter of using the true and correct type for various operations. Cheers, Bill
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 07:58:45 -0500): >Precisely, Jan. We don't know where these truncation errors lead - do they >portentially open security holes? They cetainly interefere with serving >huge resources such as .iso images. > >When I first tripped over this, I breifly pondered putting together a >patch. PHP, httpd (through apr) dealt with all this long ago. Apparently, you never compiled PHP 5.5/5.6/7.0 on Windows 64-bits. There are loads of 'possible loss of data' warnings. See for yourself: http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html Even in the 32-bits PHP 7 there are some: http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html Jan
mod_http2 on Windows (was: Re: Status for 2.4.20)
On Mar 23, 2016 22:19, "Jan Ehrhardt"wrote: > > William A Rowe Jr in gmane.comp.apache.devel (Wed, 23 Mar 2016 08:00:19 > -0500): > >On Wed, Mar 23, 2016 at 7:42 AM, William A Rowe Jr > >wrote: > > > >> Again, a C89 regression breaking the candidate, but in an experimental > >> module that we don't promise will always build. nghttp2 is filled with C99 > >> code, AIUI - due to bad decisions about basic C types - that library can > >> only build. > >> > >Whoops, answering too quickly... > > > >that library can only build *correctly* under the latest MSVC 14 (aka > >Studio 2015) when you are compiling for 64-bits on Windows (not an issue > >with 32 bit builds). > > How do you define 'correctly'? nghttp2 (git head) builds with only a > single warning on VC14 x86: > > c:\php-sdk\prebuilt\nghttp2\lib\nghttp2_session.c(6767) : warning C4715: > 'nghttp2_session_get_remote_settings': not all control paths return a > value > > VC11 x86 and VC9 x86 builds of nghttp2 give a couple of extra warnings: > > nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or > variable may be unsafe. Consider using vsnprintf_s instead. To disable > deprecation, use _CRT_SECURE_NO_WARNINGS. > > All x64 builds issue many more warnings: > > cl -nologo -MD -W3 -Z7 -DBUILDING_NGHTTP2 -I./includes -Dssize_t=long > -D_U_="" -FoMSVC_obj /r_nghttp2_session.obj -c nghttp2_session.c > nghttp2_session.c > nghttp2_session.c(5092): warning C4244: 'return': conversion from > '__int64' to 'long', possible loss of data > nghttp2_session.c(5122): warning C4244: 'return': conversion from > '__int64' to 'long', possible loss of data > nghttp2_session.c(5477): warning C4244: 'return': conversion from > '__int64' to 'long', possible loss of data > nghttp2_session.c(5704): warning C4244: 'return': conversion from > '__int64' to 'long', possible loss of data > nghttp2_session.c(5888): warning C4244: 'return': conversion from > '__int64' to 'long', possible loss of data > nghttp2_session.c(5952): warning C4244: 'return': conversion from > '__int64' to 'long', possible loss of data > nghttp2_session.c(6082): warning C4244: 'return': conversion from > '__int64' to 'long', possible loss of data > nghttp2_session.c(6191): warning C4244: 'return': conversion from > '__int64' to 'long', possible loss of data Precisely, Jan. We don't know where these truncation errors lead - do they portentially open security holes? They cetainly interefere with serving huge resources such as .iso images. When I first tripped over this, I breifly pondered putting together a patch. PHP, httpd (through apr) dealt with all this long ago. But nghttp2 is a modern C99/POSIX app, why ask the author to code around Win32-isms, now that MS finally got these right with the VC14 release?
Re: Status for 2.4.20
Tell you what. Let's delay for 1 week and I'll take up a T on Monday April 4th.
Re: Status for 2.4.20
William A Rowe Jr in gmane.comp.apache.devel (Wed, 23 Mar 2016 08:00:19 -0500): >On Wed, Mar 23, 2016 at 7:42 AM, William A Rowe Jr>wrote: > >> Again, a C89 regression breaking the candidate, but in an experimental >> module that we don't promise will always build. nghttp2 is filled with C99 >> code, AIUI - due to bad decisions about basic C types - that library can >> only build. >> >Whoops, answering too quickly... > >that library can only build *correctly* under the latest MSVC 14 (aka >Studio 2015) when you are compiling for 64-bits on Windows (not an issue >with 32 bit builds). How do you define 'correctly'? nghttp2 (git head) builds with only a single warning on VC14 x86: c:\php-sdk\prebuilt\nghttp2\lib\nghttp2_session.c(6767) : warning C4715: 'nghttp2_session_get_remote_settings': not all control paths return a value VC11 x86 and VC9 x86 builds of nghttp2 give a couple of extra warnings: nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or variable may be unsafe. Consider using vsnprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. All x64 builds issue many more warnings: cl -nologo -MD -W3 -Z7 -DBUILDING_NGHTTP2 -I./includes -Dssize_t=long -D_U_="" -FoMSVC_obj /r_nghttp2_session.obj -c nghttp2_session.c nghttp2_session.c nghttp2_session.c(5092): warning C4244: 'return': conversion from '__int64' to 'long', possible loss of data nghttp2_session.c(5122): warning C4244: 'return': conversion from '__int64' to 'long', possible loss of data nghttp2_session.c(5477): warning C4244: 'return': conversion from '__int64' to 'long', possible loss of data nghttp2_session.c(5704): warning C4244: 'return': conversion from '__int64' to 'long', possible loss of data nghttp2_session.c(5888): warning C4244: 'return': conversion from '__int64' to 'long', possible loss of data nghttp2_session.c(5952): warning C4244: 'return': conversion from '__int64' to 'long', possible loss of data nghttp2_session.c(6082): warning C4244: 'return': conversion from '__int64' to 'long', possible loss of data nghttp2_session.c(6191): warning C4244: 'return': conversion from '__int64' to 'long', possible loss of data Jan
Re: Status for 2.4.20
On Wed, Mar 23, 2016 at 7:42 AM, William A Rowe Jrwrote: > > branches/2.4.x/modules/http2/h2_filter.c > > Again, a C89 regression breaking the candidate, but in an experimental > module that we don't promise will always build. nghttp2 is filled with C99 > code, AIUI - due to bad decisions about basic C types - that library can > only build. > Whoops, answering too quickly... that library can only build *correctly* under the latest MSVC 14 (aka Studio 2015) when you are compiling for 64-bits on Windows (not an issue with 32 bit builds). In the past, size_t/ssize_t/ptrdiff_t and other alignment primitives failed to correspond to the width of their defined domain (size reflects memory, ergo thes must be the same size, bitwise, as a void*). This showed up very egregiously in nghttp2 which (fairly) demands that the POSIX types reflect their definitions. MS finally is catching up to POSIX with their Studio 2015 product release. So the antique .dsp is something of a red herring, you probably don't want to ever run an nghttp2 app or library compiled against VC98, if building to 64-bits. It is hardly a fully-conformant C99 compiler, but it comes a whole lot closer than previous attempts.
Re: Status for 2.4.20
On Mar 23, 2016 6:23 AM, "Steffen"wrote: > > Just did a export; > > Diff with the vote 2.4.19 one: > > branches/2.4.x/modules/cache/mod_socache_shmcb.c Correct. I'm not claiming this is win32-specific, it only happens to show up on that and other edge cases. > branches/2.4.x/modules/http2/h2_filter.c Again, a C89 regression breaking the candidate, but in an experimental module that we don't promise will always build. nghttp2 is filled with C99 code, AIUI - due to bad decisions about basic C types - that library can only build. > branches/2.4.x/modules/http2/mod_http2.dsp Looking good. > For remove mod_lbmethod-rr: > branches/2.4.x/Makefile.win > branches/2.4.x/Readme.cmake > branches/2.4.x/Apache.dsw > branches/2.4.x/Apache-apr2.dsw This may be reverted of course, if someone believes we should persist this non-compileable example. > And a bunch of .dep and mak files added This simplifies the process for users who don't want to go through a manual process of converting archaic project files to Windows. This is the same structure as in every httpd 2.2 tarball. But an explanation is in order... I haven't directly used these build files -myself- for creating anything other than ASF binaries in over a decade. They were not suited for building component-by-component, only for building the whole shooting match at once. I've been building each component (pcre, expat, zlib, apr etc etc) for forever now. The .mak/.dep files and Makefile.win (which invokes these) supports only the srclib/ subcomponents structure. You'll find Windows .mak/.dep files in those apr source projects as well. So this change neither breaks nor fixes - it is an alternative to a manual conversion - it merely simplifies building on Windows - until cmake builds are considered the replacement. The addition of these to the svn, rather than only a win32 source tarball, has a lengthy discussion and rational in dev@ archive already. But I have no preference as a user, myself - my entire interest lies in cmake.
Re: Status for 2.4.20
On Wed, Mar 23, 2016 at 6:56 AM, Jim Jagielskiwrote: > Let's see: I recalled the vote for 2.4.19 because of a > single issue, basically related to a missing few lines in > a file which prevented building on Win. Nice, easy, simple > fix. > > Now it appears that a slew of "fixes" related to Win have > been applied which, according to some, makes the whole build- > on-Win situation much much worse. > > Now I have no idea what the status of HEAD for 2.4 is and, > as a result, we are delaying the T and eventual release of > 2.4.19/20. All because a 4-line fix turned into a master-refactor > at the last minute. > > Slightly off-topic: 2.4.x HEAD builds fine and serves pages with VS 2012 using the cmake build. (I was initially sidetracked by the need for a higher level of nghttp2 to fix their Win32 linkage problem in APIs we didn't use last time I built on Windows, then by trunk build problems.) I am tempted to revert 2.4 back... > -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Status for 2.4.20
> On Mar 23, 2016, at 7:58 AM, Noel Butlerwrote: > > On 23/03/2016 20:56, Jim Jagielski wrote: >> Let's see: I recalled the vote for 2.4.19 because of a >> single issue, basically related to a missing few lines in >> a file which prevented building on Win. Nice, easy, simple >> fix. >> Now it appears that a slew of "fixes" related to Win have >> been applied which, according to some, makes the whole build- >> on-Win situation much much worse. >> Now I have no idea what the status of HEAD for 2.4 is and, >> as a result, we are delaying the T and eventual release of >> 2.4.19/20. All because a 4-line fix turned into a master-refactor >> at the last minute. >> I am tempted to revert 2.4 back... > > > as stated previously, this shit will happen when certain people push with a > release often mentality > > AFAIK there is *ZERO* critical exploit bugs to be patched by any pending > release, so lets get house in order S T A B L E , then worry about releases, > jesus christ, we are not ubuntu or redhat with set programs to release every > 3 or 6 months regardless if shit is ready or not. > > > flame away... IDGAF I see your point and have no intent or desire to flame. Release Often is hardly a Bad Thing, at least IMHO. When the time is right for a release, then we release. It seemed a good time, again IMHO. My opinion that "this shit will happen" when, despite lots of notice of intent to tag, and reminders to test, etc.. people simply DON'T, wait for the test tarball, find breakage, and then apply major restructure/refactor "at the last minute". Sure, stuff that like occasionally will happen, and it is, after all, why we create test tarballs and call for a vote. But when it becomes the rule instead of the exception, then we have an issue w/ the process and the workflow. Frequent release, IMHO, are an indication of health and project vitality. When Apache httpd is suffering from the FUD of being old, slow, behind-the-times, lacking features and capability, etc, I think showing our community that we are actively working the code, adding features, fixing bugs, making improvements, etc is a Good Thing.
Re: Status for 2.4.20
On 23/03/2016 20:56, Jim Jagielski wrote: Let's see: I recalled the vote for 2.4.19 because of a single issue, basically related to a missing few lines in a file which prevented building on Win. Nice, easy, simple fix. Now it appears that a slew of "fixes" related to Win have been applied which, according to some, makes the whole build- on-Win situation much much worse. Now I have no idea what the status of HEAD for 2.4 is and, as a result, we are delaying the T and eventual release of 2.4.19/20. All because a 4-line fix turned into a master-refactor at the last minute. I am tempted to revert 2.4 back... as stated previously, this shit will happen when certain people push with a release often mentality AFAIK there is *ZERO* critical exploit bugs to be patched by any pending release, so lets get house in order S T A B L E , then worry about releases, jesus christ, we are not ubuntu or redhat with set programs to release every 3 or 6 months regardless if shit is ready or not. flame away... IDGAF -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/
Re: Status for 2.4.20
On Wed, Mar 23, 2016 at 12:22 PM, Steffenwrote: > Just did a export; > > Diff with the vote 2.4.19 one: > > branches/2.4.x/modules/cache/mod_socache_shmcb.c > branches/2.4.x/modules/http2/h2_filter.c > branches/2.4.x/modules/http2/mod_http2.dsp > > For remove mod_lbmethod-rr: > branches/2.4.x/Makefile.win > branches/2.4.x/Readme.cmake > branches/2.4.x/Apache.dsw > branches/2.4.x/Apache-apr2.dsw > > And a bunch of .dep and mak files added Yes, so did it break (or fix) the Windows build? Thanks, Yann.
Re: Status for 2.4.20
Just did a export; Diff with the vote 2.4.19 one: branches/2.4.x/modules/cache/mod_socache_shmcb.c branches/2.4.x/modules/http2/h2_filter.c branches/2.4.x/modules/http2/mod_http2.dsp For remove mod_lbmethod-rr: branches/2.4.x/Makefile.win branches/2.4.x/Readme.cmake branches/2.4.x/Apache.dsw branches/2.4.x/Apache-apr2.dsw And a bunch of .dep and mak files added On Wednesday 23/03/2016 at 11:56, Jim Jagielski wrote: Let's see: I recalled the vote for 2.4.19 because of a single issue, basically related to a missing few lines in a file which prevented building on Win. Nice, easy, simple fix. Now it appears that a slew of "fixes" related to Win have been applied which, according to some, makes the whole build- on-Win situation much much worse. Now I have no idea what the status of HEAD for 2.4 is and, as a result, we are delaying the T and eventual release of 2.4.19/20. All because a 4-line fix turned into a master-refactor at the last minute. I am tempted to revert 2.4 back...
Re: Status for 2.4.20
> Am 23.03.2016 um 11:56 schrieb Jim Jagielski: > > Let's see: I recalled the vote for 2.4.19 because of a > single issue, basically related to a missing few lines in > a file which prevented building on Win. Nice, easy, simple > fix. > > Now it appears that a slew of "fixes" related to Win have > been applied which, according to some, makes the whole build- > on-Win situation much much worse. > > Now I have no idea what the status of HEAD for 2.4 is and, > as a result, we are delaying the T and eventual release of > 2.4.19/20. All because a 4-line fix turned into a master-refactor > at the last minute. > > I am tempted to revert 2.4 back... Sorry about missing the initial 4 lines. Being no Windows builder, but is the 2.4.19 + the missing lines not the same mechanism that we shipped in 2.4.18? If so, let's stick to it and defer any large-scale improvements to a later point.