|
61075eab
|
2025-01-01T14:31:02
|
|
maint: make update-copyright
|
|
|
b80b5c47
|
2024-01-01T11:29:06
|
|
maint: make update-copyright
|
|
34bdde96
|
2023-01-04T02:00:14
|
|
maint: make update-copyright
|
|
6c8ff6a8
|
2022-01-12T14:15:12
|
|
maint: make update-copyright
|
|
|
a470a47f
|
2021-07-11T19:19:42
|
|
maint: make update-copyright
|
|
|
cf27a3df
|
2020-01-01T11:44:41
|
|
maint: make update-copyright
|
|
|
5ae02cc8
|
2019-10-14T13:46:55
|
|
maint: make update-copyright
|
|
bbaa4cdc
|
2018-01-04T16:19:30
|
|
maint: Update copyright years to 2018
This update has been made with 'make update-copyright'.
|
|
|
c2757b97
|
2017-09-19T13:43:07
|
|
maint: Reset master
|
|
|
3562e384
|
2017-09-16T13:03:36
|
|
Prefer https: URLs
In Gnulib, Emacs, etc. we are changing ftp: and http: URLs to use
https:, to discourage man-in-the-middle attacks when downloading
software. The attached patch propagates these changes upstream to
Automake. This patch does not affect files that Automake is
downstream of, which I'll patch separately.
Althouth the resources are not secret, plain HTTP is vulnerable to
malicious routers that tamper with responses from GNU servers,
and this sort of thing is all too common when people in some other
countries browse US-based websites. See, for example:
Aceto G, Botta A, Pescapé A, Awan MF, Ahmad T, Qaisar
S. Analyzing internet censorship in Pakistan. RTSI
2016. https://dx.doi.org/10.1109/RTSI.2016.7740626
HTTPS is not a complete solution here, but it can be a significant
help. The GNU project regularly serves up code to users, so we should
take some care here.
|
|
|
199e7a44
|
2017-09-16T13:03:36
|
|
Prefer https: URLs
In Gnulib, Emacs, etc. we are changing ftp: and http: URLs to use
https:, to discourage man-in-the-middle attacks when downloading
software. The attached patch propagates these changes upstream to
Automake. This patch does not affect files that Automake is
downstream of, which I'll patch separately.
Althouth the resources are not secret, plain HTTP is vulnerable to
malicious routers that tamper with responses from GNU servers,
and this sort of thing is all too common when people in some other
countries browse US-based websites. See, for example:
Aceto G, Botta A, Pescapé A, Awan MF, Ahmad T, Qaisar
S. Analyzing internet censorship in Pakistan. RTSI
2016. https://dx.doi.org/10.1109/RTSI.2016.7740626
HTTPS is not a complete solution here, but it can be a significant
help. The GNU project regularly serves up code to users, so we should
take some care here.
|
|
|
d8add592
|
2017-03-02T18:55:53
|
|
maint: Update copyright years to 2017.
This update has been made with 'make update-copyright'.
|
|
|
1370ce5f
|
2017-01-01T08:34:49
|
|
maint: update copyright dates for 2017
* all files: Run this command, using update-copyright from gnulib:
UPDATE_COPYRIGHT_FORCE=1 \
UPDATE_COPYRIGHT_USE_INTERVALS=2 \
UPDATE_COPYRIGHT_MAX_LINE_LENGTH=79 \
update-copyright $(git ls-files)
|
|
5de75f07
|
2015-01-05T22:48:33
|
|
maint: update copyright years to 2015 (branch 'micro')
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
a78f63c5
|
2014-04-21T15:10:54
|
|
maint: update copyright years
We've been in 2014 already for few months now...
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
7df8b28c
|
2012-12-31T18:18:37
|
|
maint: update copyright year for 2013 (in branch maint)
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
c93cb22e
|
2012-02-21T10:03:17
|
|
cosmetics: few typofixes
|
|
|
641a5a4b
|
2012-02-16T10:46:23
|
|
maint: run "make update-copyright"
|
|
|
bd34a47c
|
2012-01-21T11:33:44
|
|
multilib: move to contrib
This follows up on commit v1.11-665-gc5df21e of 2012-01-17,
"multilib: deprecate, will be moved to contrib". See also:
<http://lists.gnu.org/archive/html/automake-patches/2012-01/msg00109.html>
* NEWS: Update.
* automake.in ($seen_multilib): Remove.
(scan_autoconf_traces): Don't trace 'AM_ENABLE_MULTILIB', and don't
handle it anymore.
(handle_multilib): Remove.
(generate_makefile): Don't call it anymore.
* doc/automake.texi: Remove documentation about multilib support,
related macros, and helper files.
* m4/multi.m4: Delete.
* m4/Makefile.am (dist_automake_ac_DATA): Remove it.
* lib/am/multilib.am: Delete.
* lib/am/Makefile.am (dist_am_DATA): Remove it.
* contrib/multilib/multilib.am: New file, adapted from extracts of
a Makefile.in generated with automake multilib support. We did
this instead of moving and editing 'lib/am/multilib.am' because it
allows us to license this file with a liberal license that will
permit users to copy-and-paste it in non-GPLed Makefile.am files
too).
* lib/symlink-tree, lib/config-ml.in: Move ...
* contrib/multilib: ... in here.
* lib/Makefile.am (dist_script_DATA, dist_pkgvdata_DATA): Update.
* contrib/multilib/README: New file.
* contrib/Makefile.am (EXTRA_DIST): Add the files created or moved
in 'contrib/multlib'.
* tests/multilib.test: Update and enhance a little.
* tests/help-multilib.test: Likewise.
|
|
|
c5df21e8
|
2012-01-17T19:48:06
|
|
multilib: deprecate, will be moved to contrib
As of 2012-01-17, according to Google codesarch, almost no active
package is using the 'multilib' feature offered by automake.
The only major exception seems to be GCC... But on a closer look,
it become clear that GCC basically carries its own version of
multilib support. In fact, Automake syncs its 'config-ml.in' and
'symlink-tree' scripts from GCC; and the GCC repository contains a
version of the 'multi.m4' file that is *more* updated than the one
in the automake repository (the former having being modified the
last time in 2008, the latter only in 2006).
The 'multilib' feature was anyway hardly documented at all, only
being briefly cited in the manual as an "obscure feature", "still
experimental", that was only for users "familiar with multilibs"
and which "can debug problems they might encounter". We expect
such users to be motivated and knowledgeable enough to make the
minor adjustments required to start using the contrib version of
multilib, if they really need to.
* NEWS (Future backward incompatibility): Update.
* doc/automake.texi: Deprecate multilib support. State that it
will be removed from automake core in the next major release.
* m4/multi.m4 (AM_ENABLE_MULTILIB): Deprecate. If called, now
gives a proper warning in the 'obsolete' category (while still
retaining its former behaviour for the rest).
* tests/multilib.test: Update.
* contrib/multilib/multi.m4: New, verbatim copy of the earlier
version of multi.m4, without the new deprecation warning.
* Makefile.am (fetch): Don't sync the 'config-ml.in' file nor
the 'symlink-tree' script from GCC SVN repository anymore.
(FETCHFILES): Adjust.
(WGET_GCC): Remove, it's not needed anymore.
|