Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
mån 2009-09-07 klockan 12:18 +1200 skrev Amos Jeffries: Tricky. That would place the hash at the wrong end of the file (last) where its most likely to be overlooked. Particularly on the longer config files. Doesn't matter if it's overlooked. There are also some distros (notably Gentoo and clones) which override our upgrades and move squid.conf.documented into place post-install as their main squid.conf. Distros using package managers is not a problem. Would embeding the hash(es) into Makefile or an install.state data file work instead? No thanks. make all/install should not modify Makefile, and I do not want yet another installed file. But here is another idea. Have uninstall compare with the source directory and not the target. Would probably be best. Will screw up if someone tries make clean before make uninstall but that's their problem. And if that's a problem then we can keep these built files until make distclean. Um, we might also have problems with distro like FreeBSD where md5sum is a non-standard script install. The srcformat scripts struggle with that already. The format proposed used is output-agnostic, as long as the hasher outputs something with a hash and no timestamps or other variable data it will work. but it's a bit messy as we also need to detect the proper binary for making hashes.. md5 / md5sum. Regards Henrik
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
Henrik Nordstrom wrote: mån 2009-09-07 klockan 12:18 +1200 skrev Amos Jeffries: Tricky. That would place the hash at the wrong end of the file (last) where its most likely to be overlooked. Particularly on the longer config files. Doesn't matter if it's overlooked. ?huh? if its overlooked it stays after an edit and the removal will find it and delete the changed file when it should not have. There are also some distros (notably Gentoo and clones) which override our upgrades and move squid.conf.documented into place post-install as their main squid.conf. Distros using package managers is not a problem. Would embeding the hash(es) into Makefile or an install.state data file work instead? No thanks. make all/install should not modify Makefile, and I do not want yet another installed file. But here is another idea. Have uninstall compare with the source directory and not the target. Would probably be best. Will screw up if someone tries make clean before make uninstall but that's their problem. And if that's a problem then we can keep these built files until make distclean. Thats more doable IMO. Um, we might also have problems with distro like FreeBSD where md5sum is a non-standard script install. The srcformat scripts struggle with that already. The format proposed used is output-agnostic, as long as the hasher outputs something with a hash and no timestamps or other variable data it will work. but it's a bit messy as we also need to detect the proper binary for making hashes.. md5 / md5sum. You misunderstood me. On FreeBSD from what I've seen of squid-cache the md5sum 'binary' is: /path/to/pythonversion /path/to/md5sum.py Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18 Current Beta Squid 3.1.0.13
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Amos Jeffries wrote: You misunderstood me. On FreeBSD from what I've seen of squid-cache the md5sum 'binary' is: /path/to/pythonversion /path/to/md5sum.py 'md5' - -Rob -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqkyFMACgkQ42zgmrPGrq5v1gCfVg5djbsXoG+wP/fe4vecUI43 SBMAmQHm96PZ0oZAm8FtPcO7THcvM/n7 =QiDt -END PGP SIGNATURE-
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
mån 2009-09-07 klockan 11:52 +1200 skrev Amos Jeffries: This seems to be related: http://www.squid-cache.org/bugs/show_bug.cgi?id=2719 I do't think so. Works for me. Regards Henrik
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
mån 2009-09-07 klockan 19:51 +1200 skrev Amos Jeffries: Henrik Nordstrom wrote: mån 2009-09-07 klockan 12:18 +1200 skrev Amos Jeffries: Tricky. That would place the hash at the wrong end of the file (last) where its most likely to be overlooked. Particularly on the longer config files. Doesn't matter if it's overlooked. ?huh? if its overlooked it stays after an edit and the removal will find it and delete the changed file when it should not have. No, the hash will differ if edited so it's not deleted. removing the line will just keep the file even if it happens to be identical to the original. Regards Henrik
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
mån 2009-09-07 klockan 19:51 +1200 skrev Amos Jeffries: But here is another idea. Have uninstall compare with the source directory and not the target. Would probably be best. Will screw up if someone tries make clean before make uninstall but that's their problem. And if that's a problem then we can keep these built files until make distclean. Thats more doable IMO. I think so too. Regards Henrik
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
n...@squid-cache.org wrote: See http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/14/changes Changes: [Amos Jeffries squ...@treenet.co.nz] Prep for 3.0.STABLE19 snip ERROR: files left after uninstall: ./etc/mime.conf ./etc/squid.conf make[1]: *** [distuninstallcheck] Error 1 make[1]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build' Is there a bleeping random generator deciding the order of these automake targets? This is ridiculous. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18 Current Beta Squid 3.1.0.13
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
mån 2009-09-07 klockan 00:16 +1200 skrev Amos Jeffries: ERROR: files left after uninstall: ./etc/mime.conf ./etc/squid.conf make[1]: *** [distuninstallcheck] Error 1 make[1]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build' Is there a bleeping random generator deciding the order of these automake targets? Yes. With no dependencies to guide it make reorders as it sees fit for the day, especially if running parallel jobs. squid.conf.default is listed as sysconf_DATA, which means it gets automatically installed and uninstalled as such. We also install that manually to $(DEFAULT_CONFIG_FILE).default in install-data-local (slightly misplaced, shold be a local variant ofthe sysconf_DATA targets, not general data) The best is probably to make these be manually installed only by the -local rules, marking them as noinst_sysconf_DATA in Makefile.am and making sure the -local rules properly install/uninstall them. Just remember to add a comment on why these are tagged as noinst_.. I guess it would also work adding a dependency that uninstall-sysconfDATA depends on uninstall-data-local, if automake accepts such dependency to be added, but we still have the issue of automake installing them in sysconf on the Makefile.am specified name, not caring about our DEFAULT_... variables. And looking closely I see what we don't even have a rule to install $(DEFAULT_MIME_TABLE). It's only installed by sysconf_DATA automatic rule as $(sysconfdir)/mime.conf Regards Henrik
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
On Sun, 2009-09-06 at 22:52 +0200, Henrik Nordstrom wrote: Yes. With no dependencies to guide it make reorders as it sees fit for the day, especially if running parallel jobs. We should be fine if we just list the dependencies. -Rob signature.asc Description: This is a digitally signed message part
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
mån 2009-09-07 klockan 07:08 +1000 skrev Robert Collins: On Sun, 2009-09-06 at 22:52 +0200, Henrik Nordstrom wrote: Yes. With no dependencies to guide it make reorders as it sees fit for the day, especially if running parallel jobs. We should be fine if we just list the dependencies. Not sure I am comfortable with adding dependencies to automakes own targets.. and no, we are not fine with just that. See the rest of previous response.. To repeat there is more issues here than uninstall racing, we don't even install properly if someone tries to override the default locations by make DEFAULT_CONFIG_FILE=... DEFAULT_MIME_TABLE=... Regards Henrik
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
On Sun, 2009-09-06 at 23:25 +0200, Henrik Nordstrom wrote: Not sure I am comfortable with adding dependencies to automakes own targets.. and no, we are not fine with just that. See the rest of previous response.. To repeat there is more issues here than uninstall racing, we don't even install properly if someone tries to override the default locations by make DEFAULT_CONFIG_FILE=... DEFAULT_MIME_TABLE=... We should definitely fix that :). If its plausible that automake should know and avoid the problem itself, lets file a bug. Otherwise we'll have to work around it I guess. -Rob signature.asc Description: This is a digitally signed message part
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
mån 2009-09-07 klockan 07:29 +1000 skrev Robert Collins: On Sun, 2009-09-06 at 23:25 +0200, Henrik Nordstrom wrote: Not sure I am comfortable with adding dependencies to automakes own targets.. and no, we are not fine with just that. See the rest of previous response.. To repeat there is more issues here than uninstall racing, we don't even install properly if someone tries to override the default locations by make DEFAULT_CONFIG_FILE=... DEFAULT_MIME_TABLE=... We should definitely fix that :). If its plausible that automake should know and avoid the problem itself, lets file a bug. Otherwise we'll have to work around it I guess. automake can't know. There is two things about this, both unsupported by automake a) The xxx.default construct, where xxx is only installed if missing and only removed if identical to xxx.default. b) make time override of certain filenames (full path including name) on a per-file basis. Support for 'a' is missing from automake, which is a shortcoming. Can imagine other projects may see benefit from this. The way automake expects 'b' to be done is to specify a different prefix at configure time for the whole category of files but keeping the filename as specified in automake.am (possibly with suffix depending type os, i.e. .exe on Windows). Regarding 'a' I have another idea.. we could just add a comment with the hash of the file. # Config install hash. Remove if editing the file: `md5sum squid.conf.default` and compare this hash instead of looking for squid.conf.default. At build time when making squid.conf: echo # Config install hash. Remove if editing the file:`md5sum squid.conf` squid.conf Uninstall: orig_sum=`grep ^# Config install hash. Remove if editing the file: squid.conf | cut -d: -f2` sum=`grep -v # Config install hash. Remove if editing the file: squid.conf | md5sum` test $sum = $orig_sum rm squid.conf Regards Henrik
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
On Sun, 06 Sep 2009 23:25:29 +0200, Henrik Nordstrom hen...@henriknordstrom.net wrote: mån 2009-09-07 klockan 07:08 +1000 skrev Robert Collins: On Sun, 2009-09-06 at 22:52 +0200, Henrik Nordstrom wrote: Yes. With no dependencies to guide it make reorders as it sees fit for the day, especially if running parallel jobs. We should be fine if we just list the dependencies. Not sure I am comfortable with adding dependencies to automakes own targets.. and no, we are not fine with just that. See the rest of previous response.. To repeat there is more issues here than uninstall racing, we don't even install properly if someone tries to override the default locations by make DEFAULT_CONFIG_FILE=... DEFAULT_MIME_TABLE=... Regards Henrik This seems to be related: http://www.squid-cache.org/bugs/show_bug.cgi?id=2719 Amos
Re: Build failed in Hudson: 3.1-amd64-CentOS-5.3 #14
On Sun, 06 Sep 2009 23:51:54 +0200, Henrik Nordstrom hen...@henriknordstrom.net wrote: mån 2009-09-07 klockan 07:29 +1000 skrev Robert Collins: On Sun, 2009-09-06 at 23:25 +0200, Henrik Nordstrom wrote: Not sure I am comfortable with adding dependencies to automakes own targets.. and no, we are not fine with just that. See the rest of previous response.. To repeat there is more issues here than uninstall racing, we don't even install properly if someone tries to override the default locations by make DEFAULT_CONFIG_FILE=... DEFAULT_MIME_TABLE=... We should definitely fix that :). If its plausible that automake should know and avoid the problem itself, lets file a bug. Otherwise we'll have to work around it I guess. automake can't know. There is two things about this, both unsupported by automake a) The xxx.default construct, where xxx is only installed if missing and only removed if identical to xxx.default. b) make time override of certain filenames (full path including name) on a per-file basis. Support for 'a' is missing from automake, which is a shortcoming. Can imagine other projects may see benefit from this. The way automake expects 'b' to be done is to specify a different prefix at configure time for the whole category of files but keeping the filename as specified in automake.am (possibly with suffix depending type os, i.e. .exe on Windows). Regarding 'a' I have another idea.. we could just add a comment with the hash of the file. # Config install hash. Remove if editing the file: `md5sum squid.conf.default` and compare this hash instead of looking for squid.conf.default. At build time when making squid.conf: echo # Config install hash. Remove if editing the file:`md5sum squid.conf` squid.conf Tricky. That would place the hash at the wrong end of the file (last) where its most likely to be overlooked. Particularly on the longer config files. There are also some distros (notably Gentoo and clones) which override our upgrades and move squid.conf.documented into place post-install as their main squid.conf. Would embeding the hash(es) into Makefile or an install.state data file work instead? Um, we might also have problems with distro like FreeBSD where md5sum is a non-standard script install. The srcformat scripts struggle with that already. Uninstall: orig_sum=`grep ^# Config install hash. Remove if editing the file: squid.conf | cut -d: -f2` sum=`grep -v # Config install hash. Remove if editing the file: squid.conf | md5sum` test $sum = $orig_sum rm squid.conf Regards Henrik Amos
