mirror of
git://git.gnupg.org/gnupg.git
synced 2024-12-21 10:09:57 +01:00
doc: Replace README.maint content.
--
This commit is contained in:
parent
bf03925751
commit
8f0bf644bc
84
README.maint
84
README.maint
@ -1,85 +1,5 @@
|
||||
Notes for the GnuPG maintainer (GIT only)
|
||||
============================================
|
||||
|
||||
Here are some notes on how to maintain GnuPG.
|
||||
|
||||
Release Planning:
|
||||
=================
|
||||
|
||||
If you are planning a new release and strings have changed you should
|
||||
send a notification to all translators, so that they have time to
|
||||
update their translations. scripts/mail-to-translators is useful for
|
||||
this. It might need some tweaking and it needs to be armored for
|
||||
actual sending. Running it as is to see what will happen is a good
|
||||
idea, though.
|
||||
|
||||
|
||||
|
||||
Release process:
|
||||
================
|
||||
|
||||
* Make sure that all new PO files are checked in.
|
||||
|
||||
* Decide whether you want to update the automake standard files
|
||||
(Mainly config.guess and config.sub).
|
||||
|
||||
* [2.0] Copy needed texinfo files from master:
|
||||
make -C doc update-source
|
||||
|
||||
* Run:
|
||||
make -C po update-po
|
||||
|
||||
* Write NEWS entries and set the release date in NEWS.
|
||||
|
||||
* Commit all changes to GIT with a message of "Release n.m.o."
|
||||
|
||||
* Create a signed tag with the name "gnupg-x.y.z".
|
||||
|
||||
* Run "./autogen.sh --force"
|
||||
(--force is required for the git magic in configure.ac and a good
|
||||
idea in any case)
|
||||
|
||||
* Run "configure --enable-maintainer-mode".
|
||||
|
||||
* Run "make distcheck".
|
||||
|
||||
* Build and test the new tarball (best on a different machine).
|
||||
|
||||
* Build and test the W32 version.
|
||||
|
||||
* [2.x only] Using the final test build run a "make -C doc online".
|
||||
|
||||
* Sign the tarball
|
||||
|
||||
* Get the previous tarball and run "mkdiff gnupg".
|
||||
You might need to set a different signature key than mine. mkdiff
|
||||
has an option for this.
|
||||
|
||||
* Push the git changes and the tag.
|
||||
|
||||
* Copy the files to the FTP server
|
||||
|
||||
* Update the webpages - at least the file swdb.mac needs an update.
|
||||
|
||||
* Add a new headline to NEWS.
|
||||
|
||||
* Bump the version number in configure.ac up, add an empty NEWS
|
||||
entry, commit, and push that.
|
||||
|
||||
* Write an announcement.
|
||||
|
||||
* Update https://savannah.gnu.org/projects/gnupg .
|
||||
|
||||
|
||||
|
||||
Gotchas
|
||||
=======
|
||||
|
||||
- If during "make distcheck" you get an error about a permission
|
||||
problem moving foo.new.po to foo.po; this is caused by a check
|
||||
whether the po files can be re-created. Now if the first tarball
|
||||
has been created in a different top directory and if there exists a
|
||||
no distributed file with the string "GNU gnupg" (e.g. a log file
|
||||
from running make) you end up with different comments in the po
|
||||
files. Check out /usr/lib/gettext/project-id for that silliness.
|
||||
As a hack we added this string into configure.ac.
|
||||
Please see https://gnupg.org/devel/creating-a-release.html or the
|
||||
corresponding .org file in the gnupg-doc repo.
|
||||
|
@ -511,7 +511,7 @@ libdns_init (void)
|
||||
}
|
||||
else if (!strchr (ld.resolv_conf->lookup, 'b'))
|
||||
{
|
||||
/* No DNS resulution type found in the list. This might be
|
||||
/* No DNS resolution type found in the list. This might be
|
||||
* due to systemd based systems which allow for custom
|
||||
* keywords which are not known to us and thus we do not
|
||||
* know whether DNS is wanted or not. Becuase DNS is
|
||||
|
Loading…
x
Reference in New Issue
Block a user