Bug 192828 - [new port] add squid34 to ports
Summary: [new port] add squid34 to ports
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Many People
Assignee: John Marino
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-19 11:31 UTC by Pavel Timofeev
Modified: 2014-09-16 12:46 UTC (History)
6 users (show)

See Also:


Attachments
squid34 port dir old (12.02 KB, application/gzip)
2014-08-19 11:31 UTC, Pavel Timofeev
no flags Details
squid34 port dir (11.92 KB, application/gzip)
2014-08-19 11:43 UTC, Pavel Timofeev
no flags Details
based on today's squid33 (111.56 KB, text/plain)
2014-08-20 10:57 UTC, Pavel Timofeev
no flags Details
squid34.shar (110.86 KB, text/plain)
2014-08-20 12:09 UTC, takefu
no flags Details
Updates www/squid34 to 3.4.7 (108.84 KB, text/plain)
2014-08-27 22:13 UTC, Dennis Glatting
no flags Details
squid34.shar (108.17 KB, application/x-shellscript)
2014-09-16 05:17 UTC, takefu
no flags Details
shar for www/squid (3.4.7) (108.85 KB, text/plain)
2014-09-16 11:42 UTC, Pavel Timofeev
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Timofeev 2014-08-19 11:31:56 UTC
Created attachment 146026 [details]
squid34 port dir old

An attempt to make a port for squid34.
It's stable and the only one supported by upstream version of squid.
It's based on existing www/squid33 and port made by Dennis Glatting.

I know, it's a mess in PLIST_FILES, but it's the first step. I plan to convert it to normal pkg-plist format in future, but not now.

I checked and tried every option. FS_COSS and ECAP don't build. Don't know how to fix it. Marked as broken. Others are ok and they are staging without any problems.

No more "WARNING: no_suid: setuid(0): (1) Operation not permitted" messages in logs (thanks to the www/squid33).

What's the difference between www/squid33?
- latest squid-3.4.6 with latest patches.
- more files in SHEBANG_FILES.
- reorder a bit PLIST_FILES stuff + honor SSL.
- add squid_krb5_ktname to rc.d script.

Hope someone else will test it and maybe provide a patch to fix 2 broken oprions.

P.S. Maybe it should be at www/squid, not in www/squid34?
Comment 1 Pavel Timofeev 2014-08-19 11:43:27 UTC
Created attachment 146028 [details]
squid34 port dir
Comment 2 John Marino freebsd_committer freebsd_triage 2014-08-19 12:33:56 UTC
hi timp87,

We are in no rush for squid34, so please provide a version with a static plist.
Okay, I see this covers today's fixes, that's good.
We also need to get the option count down.

- also, I can't see the shar right now because it's gzipped, don't do that.  Just attach it plain text.

I'm fine with moving it to www/squid if we deprecate squid33 when it comes with a message that we'll only have one version of squid in the future and this is it.
Comment 3 Pavel Timofeev 2014-08-19 12:45:08 UTC
> We are in no rush for squid34, so please provide a version with a static plist.
Please, let's commit it to www/squid34? and when I provide static plist version we will move it to www/squid? And delete then other versions.

> We also need to get the option count down.
I'm not sure which one.

> - also, I can't see the shar right now because it's gzipped, don't do that. 
> Just attach it plain text.
Sorry. It's just a port's dir. Is it written somewhere in porters handbook?

> I'm fine with moving it to www/squid if we deprecate squid33 when it comes with a message that we'll only have one version of squid in the future and this is it.
Great!
Comment 4 John Marino freebsd_committer freebsd_triage 2014-08-19 12:52:09 UTC
(In reply to timp87 from comment #3)
> > We are in no rush for squid34, so please provide a version with a static plist.
> Please, let's commit it to www/squid34? and when I provide static plist
> version we will move it to www/squid? And delete then other versions.

sorry, no.  People are pretty upset with how PLIST is in squid 32 and 33, I won't commit another one on a promise to fix it.  Let's fix it first.


> 
> > We also need to get the option count down.
> I'm not sure which one.

Any option that doesn't require external dependencies, build by default (not an option).  The rest we have to see, but I'd say build common ones unconditionally.  Ask other squid people, I don't use it so I can't help.


> 
> > - also, I can't see the shar right now because it's gzipped, don't do that. 
> > Just attach it plain text.
> Sorry. It's just a port's dir. Is it written somewhere in porters handbook?

I am not aware of where is says "gzip your shar before providing it".  If the PBH says that it needs to be changed.  I am talking about bugzilla.  I want to set the shar's text without having to gunzip it first.  That' true for any file < 1 Mb (bugzilla's attachment size limit)
Comment 5 Pavel Timofeev 2014-08-19 13:07:56 UTC
> sorry, no.  People are pretty upset with how PLIST is in squid 32 and 33, I won't commit another one on a promise to fix it.  Let's fix it first.
it's a pitty :(. This kills my motivation a bit. We lived with that whole life.
It works now without problems. It stages with every option.
Any alternative is much better then no alternative.

> Any option that doesn't require external dependencies, build by default (not an option).  The rest we have to see, but I'd say build common ones unconditionally.  Ask other squid people, I don't use it so I can't help.


> I am not aware of where is says "gzip your shar before providing it".  If the PBH says that it needs to be changed.  I am talking about bugzilla.  I want to set the shar's text without having to gunzip it first.  That' true for any file < 1 Mb (bugzilla's attachment size limit)
I'm not arguing or grumbling here (I do it under the first quote). I just wanted to see an example or a place where I could learn.
Comment 6 John Marino freebsd_committer freebsd_triage 2014-08-19 13:13:37 UTC
(In reply to timp87 from comment #5)
> > sorry, no.  People are pretty upset with how PLIST is in squid 32 and 33, 
> > I won't commit another one on a promise to fix it.  Let's fix it first.
> it's a pitty :(. This kills my motivation a bit. We lived with that whole
> life.
> It works now without problems. It stages with every option.
> Any alternative is much better then no alternative.


If that is true, then converting it to a static plist will be relatively easy.  The hard part is making it work with the numerous options and testing that it actually works (which means running poudriere numerous times).  The plist is easy, it's the testing that is hard, and you claim that is complete.  (I am skeptical a bit though)

> I'm not arguing or grumbling here (I do it under the first quote). I just
> wanted to see an example or a place where I could learn.

I don't really know what you mean.  Why do you need an example to update unzipped files?  Just don't gzip them before you upload them.
Comment 7 Pavel Timofeev 2014-08-19 14:18:31 UTC
Look at error_dirs, error_dir_links and error_files in Makefile.
Do you have an idea how I can handle this bunch of same filenames in static pkg-plist?
Comment 8 Pavel Timofeev 2014-08-19 14:41:51 UTC
Sorry, nevermind
Comment 9 Dennis Glatting 2014-08-19 16:11:03 UTC
I use Squid in a production environment (three or four instances). It is on my task list to update my hack-a-package this month.

If no on else is stepping up to the plate to port Squid 3.4 to ports I'll accept the challenge.
Comment 10 Pavel Timofeev 2014-08-19 16:12:39 UTC
Give me a week or two
Comment 11 John Marino freebsd_committer freebsd_triage 2014-08-19 16:20:09 UTC
sure, update the PR when you are ready.
Comment 12 John Marino freebsd_committer freebsd_triage 2014-08-20 07:06:12 UTC
you will be very interested in bug 192846
Comment 13 Dennis Glatting 2014-08-20 07:21:17 UTC
(In reply to John Marino from comment #12)
> you will be very interested in bug 192846

Thanks. 

Squid has a lot of options. I was going through them earlier today looking to simplify.
Comment 14 Pavel Timofeev 2014-08-20 07:43:23 UTC
I think we must be careful with option cutting. IMO options are one of the killer feature of FreeBSD ports. Look at options for postfix or openldap-server, for example.
Squid is complex software and I don't think it's bad to have many options.
Comment 15 John Marino freebsd_committer freebsd_triage 2014-08-20 08:13:49 UTC
you are not "cutting" options in the sense the capability is lost.  You are building it with that capability as a default.

Any option that is off by default means it's not in a binary package.  The more options there are, the more likely the binary package is useless.  

Even there are tons of options, as many as possible should be turned on by default so the capability is in the binary package, leaving only source builders to remove them manually.

I get the idea you are focused on building from source.  You need to be looking at this from a useful binary package point of view.
Comment 16 Pavel Timofeev 2014-08-20 10:57:03 UTC
Created attachment 146062 [details]
based on today's squid33

it's supposed to be www/squid

Maybe we can switch back (remove expiration) fir those ports http://svnweb.freebsd.org/ports?view=revision&revision=365187
?
Comment 17 John Marino freebsd_committer freebsd_triage 2014-08-20 10:59:32 UTC
i disagree.  If they can't switch to squid33 before they get pruned, then they can't switch to squid 34 either.
Comment 18 Pavel Timofeev 2014-08-20 11:02:31 UTC
I think squid33 must exist for some time (a half of a year or even more) in parallel with squid 3.4.
Because it's already tested and check version
Comment 19 John Marino freebsd_committer freebsd_triage 2014-08-20 11:06:51 UTC
(In reply to timp87 from comment #18)
> I think squid33 must exist for some time (a half of a year or even more) in
> parallel with squid 3.4.
> Because it's already tested and check version

squid34 won't be committed until it's the same quality as squid33 and then squid33 will probably be deprecated because the company says they only support one (1) release at a time, which means squid33 is already not supported.
Comment 20 Pavel Timofeev 2014-08-20 11:51:38 UTC
> squid34 won't be committed until it's the same quality as squid33
So is new shar the same quality as squid33?
Comment 21 John Marino freebsd_committer freebsd_triage 2014-08-20 11:54:52 UTC
i haven't looked at yet, is it finished?  You did all the options refactoring to the best of your ability?

also the share should start with squid/ not ./squid.  I think in this case it doesn't matter though.
Comment 22 takefu 2014-08-20 12:09:27 UTC
Created attachment 146065 [details]
squid34.shar

fix OptionsNG
convert pkg-plist
Comment 23 Dennis Glatting 2014-08-20 19:58:17 UTC
(In reply to takefu from comment #22)
> Created attachment 146065 [details]
> squid34.shar
> 
> fix OptionsNG
> convert pkg-plist

I'm currently running this shar on one of my servers. Although it has been running less than an hour, it seems to be working fine (including ICAP).
Comment 24 Pavel Timofeev 2014-08-21 06:37:20 UTC
(In reply to takefu from comment #22)
> Created attachment 146065 [details]
> squid34.shar
> 
> fix OptionsNG
> convert pkg-plist

I've been running it since it was presented. No problems except squid 3.4 eats much more CPU than squid 3.3 in my setup (negotiate_kerberos_auth + ext_kerberos_ldap_group_acl). Perhaps it's not related to port, but to squid itself.
Comment 25 takefu 2014-08-21 08:41:10 UTC
(In reply to timp87 from comment #24)

> I've been running it since it was presented. No problems except squid 3.4
> eats much more CPU than squid 3.3 in my setup (negotiate_kerberos_auth +
> ext_kerberos_ldap_group_acl). Perhaps it's not related to port, but to squid
> itself.

Kerberos-related is corrupt. 
Especially in the clang is mad 'common'. 
Wait for the fix in the upstream.
Comment 26 Pavel Timofeev 2014-08-21 08:43:01 UTC
(In reply to takefu from comment #25)
> (In reply to timp87 from comment #24)
> 
> > I've been running it since it was presented. No problems except squid 3.4
> > eats much more CPU than squid 3.3 in my setup (negotiate_kerberos_auth +
> > ext_kerberos_ldap_group_acl). Perhaps it's not related to port, but to squid
> > itself.
> 
> Kerberos-related is corrupt. 
> Especially in the clang is mad 'common'. 
> Wait for the fix in the upstream.

Thank you!
Thats why I asked to safe squid33 for some time. But, no luck
Comment 27 Pavel Timofeev 2014-08-22 07:39:23 UTC
So what we going to do now/next?

Just in case.
John (or someone else responsible for ports commit), if you decide commit it to the www/squid then don't forget to remove PKGNAMESUFFIX from Makefile.
Comment 28 John Marino freebsd_committer freebsd_triage 2014-08-22 08:01:20 UTC
(In reply to takefu from comment #25)
> (In reply to timp87 from comment #24)
> Kerberos-related is corrupt. 
> Especially in the clang is mad 'common'. 
> Wait for the fix in the upstream.

I thought we are waiting for upstream as takefu said, "wait".

I'm actually fine with waiting until 15 September.
If we put it in before, we have to call it www/squid34 and then move it to www/squid after www/squid is removed.

We can't call it www/squid *NOW* because there's a port there.
Comment 29 Pavel Timofeev 2014-08-22 09:13:50 UTC
(In reply to John Marino from comment #28)
> (In reply to takefu from comment #25)
> > (In reply to timp87 from comment #24)
> > Kerberos-related is corrupt. 
> > Especially in the clang is mad 'common'. 
> > Wait for the fix in the upstream.
> 
> I thought we are waiting for upstream as takefu said, "wait".
> 
> I'm actually fine with waiting until 15 September.
> If we put it in before, we have to call it www/squid34 and then move it to
> www/squid after www/squid is removed.
> 
> We can't call it www/squid *NOW* because there's a port there.

Ok, understood.
I hope the upstream knows about that problem at least.
takefu, do you have any additional info?

Dennis Glatting, I looked at patches that you provided for initial version of this port. Sorry, if I ask stupid questions, but:

Are all of them still valid for 3.4.6?
For xample, is files/patch-src_base_Vector.h still valid? There was a similar fix included in 3.4.3 http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13082.patch
Comment 30 Dennis Glatting 2014-08-22 15:25:20 UTC
(In reply to timp87 from comment #29)
> (In reply to John Marino from comment #28)
> > (In reply to takefu from comment #25)
> > > (In reply to timp87 from comment #24)
> > > Kerberos-related is corrupt. 
> > > Especially in the clang is mad 'common'. 
> > > Wait for the fix in the upstream.
> > 
> > I thought we are waiting for upstream as takefu said, "wait".
> > 
> > I'm actually fine with waiting until 15 September.
> > If we put it in before, we have to call it www/squid34 and then move it to
> > www/squid after www/squid is removed.
> > 
> > We can't call it www/squid *NOW* because there's a port there.
> 
> Ok, understood.
> I hope the upstream knows about that problem at least.
> takefu, do you have any additional info?
> 
> Dennis Glatting, I looked at patches that you provided for initial version
> of this port. Sorry, if I ask stupid questions, but:
> 
> Are all of them still valid for 3.4.6?
> For example, is files/patch-src_base_Vector.h still valid? There was a
> similar fix included in 3.4.3
> http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13082.patch

3.4.6 compiles without patch-src_base_Vector.h whereas 3.4.2 does not. 
3.4.6 includes (integrated) 13082.patch whereas my version of 3.4.2 did not. If memory serves, it wasn't available at the time.

Without running the code I conclude patch-src_base_Vector.h is no longer valid. I'm installing the non-patch-src_base_Vector.h code now for test, before coffee.
Comment 31 Dennis Glatting 2014-08-22 15:37:54 UTC
(In reply to Dennis Glatting from comment #30)
> (In reply to timp87 from comment #29)
> > (In reply to John Marino from comment #28)
> > > (In reply to takefu from comment #25)
> > > > (In reply to timp87 from comment #24)
> > > > Kerberos-related is corrupt. 
> > > > Especially in the clang is mad 'common'. 
> > > > Wait for the fix in the upstream.
> > > 
> > > I thought we are waiting for upstream as takefu said, "wait".
> > > 
> > > I'm actually fine with waiting until 15 September.
> > > If we put it in before, we have to call it www/squid34 and then move it to
> > > www/squid after www/squid is removed.
> > > 
> > > We can't call it www/squid *NOW* because there's a port there.
> > 
> > Ok, understood.
> > I hope the upstream knows about that problem at least.
> > takefu, do you have any additional info?
> > 
> > Dennis Glatting, I looked at patches that you provided for initial version
> > of this port. Sorry, if I ask stupid questions, but:
> > 
> > Are all of them still valid for 3.4.6?
> > For example, is files/patch-src_base_Vector.h still valid? There was a
> > similar fix included in 3.4.3
> > http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13082.patch
> 
> 3.4.6 compiles without patch-src_base_Vector.h whereas 3.4.2 does not. 
> 3.4.6 includes (integrated) 13082.patch whereas my version of 3.4.2 did not.
> If memory serves, it wasn't available at the time.
> 
> Without running the code I conclude patch-src_base_Vector.h is no longer
> valid. I'm installing the non-patch-src_base_Vector.h code now for test,
> before coffee.

The code is running and servicing requests. I see in the log a problem related to the PID but that may be *my* problem because I'm running multiple instances and have to redefine the PID file in rc.conf. I'll look into that problem this weekend when I won't be (significantly) impacting users+machines.
Comment 32 Dennis Glatting 2014-08-22 16:36:32 UTC
(In reply to John Marino from comment #28)
> (In reply to takefu from comment #25)
> > (In reply to timp87 from comment #24)
> > Kerberos-related is corrupt. 
> > Especially in the clang is mad 'common'. 
> > Wait for the fix in the upstream.
> 
> I thought we are waiting for upstream as takefu said, "wait".
> 
> I'm actually fine with waiting until 15 September.
> If we put it in before, we have to call it www/squid34 and then move it to
> www/squid after www/squid is removed.
> 
> We can't call it www/squid *NOW* because there's a port there.

www/squid is 2.7.x. The Squid web site lists 2.7's "latest release date" as 16Mar2010. The site also says about 2.7 *and* 3.3:

   Provided for archival purposes only. Not intended for 
   general use in new installations.

The latest release date for 3.3 is listed as 08Mar2014.

http://www.squid-cache.org/Versions/
Comment 33 John Marino freebsd_committer freebsd_triage 2014-08-22 16:40:23 UTC
(In reply to Dennis Glatting from comment #32)
> www/squid is 2.7.x. The Squid web site lists 2.7's "latest release date" as
> 16Mar2010. The site also says about 2.7 *and* 3.3:
> 
>    Provided for archival purposes only. Not intended for 
>    general use in new installations.
> 
> The latest release date for 3.3 is listed as 08Mar2014.
> 
> http://www.squid-cache.org/Versions/


I don't know what you are getting at, honestly.

The Squid developers have explicitly defined 2.7 EOL as Aug 2012, and also explicitly said they only support one release at a time.  This was in response to the question, "Where are your EOL dates published?"
Comment 34 Dennis Glatting 2014-08-22 16:47:19 UTC
(In reply to Dennis Glatting from comment #31)
> (In reply to Dennis Glatting from comment #30)
> > (In reply to timp87 from comment #29)
> > > (In reply to John Marino from comment #28)
> > > > (In reply to takefu from comment #25)
> > > > > (In reply to timp87 from comment #24)
> > > > > Kerberos-related is corrupt. 
> > > > > Especially in the clang is mad 'common'. 
> > > > > Wait for the fix in the upstream.
> > > > 
> > > > I thought we are waiting for upstream as takefu said, "wait".
> > > > 
> > > > I'm actually fine with waiting until 15 September.
> > > > If we put it in before, we have to call it www/squid34 and then move it to
> > > > www/squid after www/squid is removed.
> > > > 
> > > > We can't call it www/squid *NOW* because there's a port there.
> > > 
> > > Ok, understood.
> > > I hope the upstream knows about that problem at least.
> > > takefu, do you have any additional info?
> > > 
> > > Dennis Glatting, I looked at patches that you provided for initial version
> > > of this port. Sorry, if I ask stupid questions, but:
> > > 
> > > Are all of them still valid for 3.4.6?
> > > For example, is files/patch-src_base_Vector.h still valid? There was a
> > > similar fix included in 3.4.3
> > > http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13082.patch
> > 
> > 3.4.6 compiles without patch-src_base_Vector.h whereas 3.4.2 does not. 
> > 3.4.6 includes (integrated) 13082.patch whereas my version of 3.4.2 did not.
> > If memory serves, it wasn't available at the time.
> > 
> > Without running the code I conclude patch-src_base_Vector.h is no longer
> > valid. I'm installing the non-patch-src_base_Vector.h code now for test,
> > before coffee.
> 
> The code is running and servicing requests. I see in the log a problem
> related to the PID but that may be *my* problem because I'm running multiple
> instances and have to redefine the PID file in rc.conf. I'll look into that
> problem this weekend when I won't be (significantly) impacting
> users+machines.

As for the other patches...

Several of the patches supporting a modified strlen(). The problem is Squid will call strlen() with NULL. As of r270339 the FreeBSD strlen() does not check for NULL. See the following comment from Dimitry on this problem.

http://lists.freebsd.org/pipermail/freebsd-ports/2014-February/089773.html
Comment 35 Dennis Glatting 2014-08-22 17:26:21 UTC
(In reply to John Marino from comment #33)
> (In reply to Dennis Glatting from comment #32)
> > www/squid is 2.7.x. The Squid web site lists 2.7's "latest release date" as
> > 16Mar2010. The site also says about 2.7 *and* 3.3:
> > 
> >    Provided for archival purposes only. Not intended for 
> >    general use in new installations.
> > 
> > The latest release date for 3.3 is listed as 08Mar2014.
> > 
> > http://www.squid-cache.org/Versions/
> 
> 
> I don't know what you are getting at, honestly.
> 
> The Squid developers have explicitly defined 2.7 EOL as Aug 2012, and also
> explicitly said they only support one release at a time.  This was in
> response to the question, "Where are your EOL dates published?"

I'm not sure there is a point to www/squid except for graceful deprecation.
Comment 36 John Marino freebsd_committer freebsd_triage 2014-08-22 17:33:45 UTC
sure, but it's due to be removed on 15 September so we are all in agreement.
Comment 37 Dennis Glatting 2014-08-27 22:13:03 UTC
Created attachment 146412 [details]
Updates www/squid34 to 3.4.7

Version 3.4.7 was released today. Attached is an updated shar file. I am running this version on one of my active servers but only for the last hour. I am NOT a Kerberos site.

There is a CVE against 3.4.6 /and/ the 3.3 version in ports but 3.4.7 is fixed. The impacted version also includes 3.4.6 previously posted here but another change set is all that is needed.


* CVE-2014-3609 : SQUID-2014:2 Denial of service in request processing

  http://www.squid-cache.org/Advisories/SQUID-2014_2.txt

This vulnerability allows any client who is allowed to use the proxy to
perform a denial of service attack on Squid. This issue is particularly
impacting reverse-proxy installations.

  A simple squid.conf workaround is available for quick use and those
  unable to upgrade. See the Advisory notice for details.
Comment 38 Dennis Glatting 2014-08-27 22:17:03 UTC
My comment about Squid 3.3 is not valid. My mirror caught the update while I was working on 3.4.7.
Comment 39 Pavel Timofeev 2014-08-28 03:00:00 UTC
They fixed my problem with kerberos in 3.4.7.
It works as expected now. But it still eats o lot of CPU.
Comment 40 John Marino freebsd_committer freebsd_triage 2014-09-12 07:11:02 UTC
In 3 days, www/squid and www/squid32 will be removed.

Please make sure all recent updates to www/squid33 are also captured in this shar.  I would imagine the diff between this shar and www/squid33 is not great (or should not be great)
Comment 41 Pavel Timofeev 2014-09-12 08:07:37 UTC
(In reply to John Marino from comment #40)
> In 3 days, www/squid and www/squid32 will be removed.
> 
> Please make sure all recent updates to www/squid33 are also captured in this
> shar.  I would imagine the diff between this shar and www/squid33 is not
> great (or should not be great)

Completely agree. The new port for squid34 should be based on existing www/squid33.
Comment 42 John Marino freebsd_committer freebsd_triage 2014-09-14 12:47:36 UTC
The 15th is tomorrow.  Is an update coming before then?
Comment 43 John Marino freebsd_committer freebsd_triage 2014-09-15 09:01:44 UTC
Can I have a status ASAP?  www/squid is expired right now.
Comment 44 Pavel Timofeev 2014-09-16 04:01:19 UTC
(In reply to John Marino from comment #43)
> Can I have a status ASAP?  www/squid is expired right now.

Sorry, status of what?
Comment 45 takefu 2014-09-16 05:17:27 UTC
Created attachment 147372 [details]
squid34.shar

Update squid3.4.7
https://redports.org/buildarchive/20140916045831-30528/
Comment 46 John Marino freebsd_committer freebsd_triage 2014-09-16 06:05:17 UTC
takefu: thanks

timp87: I've been expecting a final submission, one that captured the most recent changes of squid33.  My last few comments on this PR were about requesting that submission, you said, "I agree" and thus I expected it.  Since it didn't come, I was asking where it was and when it was coming.
Comment 47 Pavel Timofeev 2014-09-16 06:55:03 UTC
(In reply to John Marino from comment #46)
> takefu: thanks
> 
> timp87: I've been expecting a final submission, one that captured the most
> recent changes of squid33.  My last few comments on this PR were about
> requesting that submission, you said, "I agree" and thus I expected it. 
> Since it didn't come, I was asking where it was and when it was coming.

Ah, sorry. I decided I'm not good at this. takefu and Dennis are better choice.
Comment 48 takefu 2014-09-16 08:31:21 UTC
(In reply to timp87 from comment #47)
> (In reply to John Marino from comment #46)
> > takefu: thanks
> > 
> > timp87: I've been expecting a final submission, one that captured the most
> > recent changes of squid33.  My last few comments on this PR were about
> > requesting that submission, you said, "I agree" and thus I expected it. 
> > Since it didn't come, I was asking where it was and when it was coming.
> 
> Ah, sorry. I decided I'm not good at this. takefu and Dennis are better
> choice.

delete is squid32, add squid34.
It's the best choice to do so, I think.
Comment 49 John Marino freebsd_committer freebsd_triage 2014-09-16 09:06:11 UTC
The plan is:

1) delete all remaining ports dependent on www/squid
2) delete www/squid32
3) install this share in www/squid (not www/squid34!)
4) deprecate www/squid33 (say 4 months?)

It is not a good idea to have more than one squid port.  Only the current release is supported.
Comment 50 emz 2014-09-16 09:11:09 UTC
I tested the proposed port, it works fine.
It's September, 16, and we still don't have 3.4 in ports.
Do something. Add www/squid34 or replace 2.7 with 3.4, it doesn't matter. You're like wasting time discussing unimportant things. Squid 2.7 is long gone, those who still need this antiquity will still be able to fetch it with svn.
Comment 51 John Marino freebsd_committer freebsd_triage 2014-09-16 09:15:51 UTC
(In reply to emz from comment #50)
> I tested the proposed port, it works fine.
> It's September, 16, and we still don't have 3.4 in ports.
> Do something. Add www/squid34 or replace 2.7 with 3.4, it doesn't matter.
> You're like wasting time discussing unimportant things. Squid 2.7 is long
> gone, those who still need this antiquity will still be able to fetch it
> with svn.

You do realize the very earliest this was going to be committed was the 15 of september, right?  Are you really chastising somebody (e.g. me) for not having it in ports already?  I do have other things to do, including $REALJOB.  I find this comment very pushy and not helpful at all.
Comment 52 emz 2014-09-16 10:05:02 UTC
I have found this attitude spectacular. Real job. Yeah. Sorry I was messing with your real job with our 'FreeBSD MMORPG' game.
Comment 53 John Marino freebsd_committer freebsd_triage 2014-09-16 10:12:11 UTC
How old are you?
It's probably best if that's your last "contribution" to this PR.  Thanks.
Comment 54 emz 2014-09-16 10:31:33 UTC
You're absolutely right - everyone wondering why this isn't commited is either still a child or some slacker without a Real Job.

How old are you ? I guess early twenties.
Comment 55 Pavel Timofeev 2014-09-16 10:36:17 UTC
Please, let's not quarrel and offend each other.

John, if you do not mind (i hope it's right expression), I'll provide a shar file for www/squid which will be based on lastest www/squid33.
Comment 56 John Marino freebsd_committer freebsd_triage 2014-09-16 10:40:20 UTC
(In reply to timp87 from comment #55)
> John, if you do not mind (i hope it's right expression), I'll provide a shar
> file for www/squid which will be based on lastest www/squid33.

Isn't that what takefu provided (other than putting it at www/squid34 instead of www/squid)?

It would be helpful if you can verify what takefu provide and tell me if you agree with it.  If you agree, I'll just use that.
Comment 57 Pavel Timofeev 2014-09-16 10:44:33 UTC
(In reply to John Marino from comment #56)
> (In reply to timp87 from comment #55)
> > John, if you do not mind (i hope it's right expression), I'll provide a shar
> > file for www/squid which will be based on lastest www/squid33.
> 
> Isn't that what takefu provided (other than putting it at www/squid34
> instead of www/squid)?
> 
> It would be helpful if you can verify what takefu provide and tell me if you
> agree with it.  If you agree, I'll just use that.

Not just, but not so serious. That patch didn't catch thing like rename STRICT_HTTP option to LAX_HTTP, removal of FS_COSS and small fix for pkg-plist.
Comment 58 John Marino freebsd_committer freebsd_triage 2014-09-16 10:48:23 UTC
(In reply to timp87 from comment #57)
> Not just, but not so serious. That patch didn't catch thing like rename
> STRICT_HTTP option to LAX_HTTP, removal of FS_COSS and small fix for
> pkg-plist.

Okay, that's a productive review.  I would definitely appreciate an updated shar from you then, thanks!
Comment 59 Pavel Timofeev 2014-09-16 11:17:00 UTC
(In reply to John Marino from comment #58)
> (In reply to timp87 from comment #57)
> > Not just, but not so serious. That patch didn't catch thing like rename
> > STRICT_HTTP option to LAX_HTTP, removal of FS_COSS and small fix for
> > pkg-plist.
> 
> Okay, that's a productive review.  I would definitely appreciate an updated
> shar from you then, thanks!

Do you wanted a _shar_ file for www/squid34 or www/squid? =) Sorry.
Comment 60 John Marino freebsd_committer freebsd_triage 2014-09-16 11:29:03 UTC
Use "www/squid".

The PKGNAME should match as well.
Comment 61 Pavel Timofeev 2014-09-16 11:42:57 UTC
Created attachment 147376 [details]
shar for www/squid (3.4.7)

Done. It catches all recent changes to the www/squid33 port.
Comment 62 John Marino freebsd_committer freebsd_triage 2014-09-16 11:49:57 UTC
Thanks!

I don't see a reason to define SQUID_STABLE_VERSION or have the PKGNAMESUFFIX commented out, so I'll probably remove those and define PORTVERSION as 3.4.7

That's minor stuff though.
Comment 63 commit-hook freebsd_committer freebsd_triage 2014-09-16 12:29:24 UTC
A commit references this bug:

Author: marino
Date: Tue Sep 16 12:29:21 UTC 2014
New revision: 368307
URL: http://svnweb.freebsd.org/changeset/ports/368307

Log:
  www/squid: Upgrade version 2.7.9 => 3.4.7

  From now on, there will only be one squid port, this one.  Squid33 has
  been deprecated and will expire on 31 JAN 2015.

  PR:		192828
  Submitted by:	timp87 (gmail)
  Contributions:	takefu (airport.fm), Dennis Glatting

Changes:
  head/www/squid/Makefile
  head/www/squid/distinfo
  head/www/squid/files/extra-patch-src-cf.data.pre.aufs
  head/www/squid/files/patch-compat_Makefile.in
  head/www/squid/files/patch-compat_strlen.c
  head/www/squid/files/patch-configure
  head/www/squid/files/patch-helpers-basic_auth-SMB-Makefile.in
  head/www/squid/files/patch-helpers-basic_auth-SMB-smb_auth.sh
  head/www/squid/files/patch-include-squid_types.h
  head/www/squid/files/patch-squid_kerb_auth
  head/www/squid/files/patch-src-cf.data.pre
  head/www/squid/files/patch-src_tools.cc
  head/www/squid/files/patch-tools-Makefile.in
  head/www/squid/files/pkg-deinstall.in
  head/www/squid/files/pkg-install.in
  head/www/squid/files/pkg-message.in
  head/www/squid/files/squid.in
  head/www/squid/pkg-descr
  head/www/squid/pkg-plist
  head/www/squid33/Makefile
Comment 64 John Marino freebsd_committer freebsd_triage 2014-09-16 12:46:57 UTC
Thanks timp87.
There were a couple of more tweaks that were necessary, mainly the CONFLICTS needs to be updated but nothing major.  it built in poudriere just fine as well.

Closing this PR finally!