| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This man page does not describe a file format, move it to the
conventions section.
|
|
Using libdir is wrong, and doubly so when being referred from
architecture independent files such as perl modules. This affects
non-Debian based systems, which might by default use an arch varying
libdir per architecture, for example when using the obsolete multilib
layout.
|
|
The .buildinfo files are a new type of control files, similar to
the .changes files, meant to describe the environment of a build
and its artifacts. They are meant to be added to the Debian archive
to allow independent parties to reproduce a build and verify the
result.
Specifications for .buildinfo are available at:
<https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification>
This patch adds support for .buildinfo files in Dpkg::Control,
adds new .buildinfo fields to Dpkg::Control::Fields, a new
builtin-system-build-paths Dpkg::Vendor hook, and adds a new script
named dpkg-genbuildinfo, that will now be called by dpkg-buildpackage
before generating the .changes file.
[ntyni@debian.org: small changes. ]
Closes: #138409
Based-on-patch-by: Jérémy Bobbio <lunar@debian.org>
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
This makes it possible to filter them and update several variable
strings such as system and package pathnames, the release date and
the dpkg suite version. And will make it possible to use UTF-8 in
the source and convert to the more conservative groff escape
sequences on the output.
|
|
Prompted-by: Johannes Schauer <josch@debian.org>
|
|
These document the bare minimum, with a brief description of the
maintainer scripts and the ways they can get called.
|
|
The former is more portable and has not been marked as deprecated by
POSIX.
|
|
|
|
|
|
|
|
Adapted from the Debian policy manual.
|
|
|
|
These programs were moved from …/sbin/ to …/bin/ but the man pages
did not follow suit.
|
|
|
|
This allows us to use the new --add-location option with the file
argument, which will remove a huge amount diff noise on source code
changes, while still retaining the useful origin of the string.
|
|
This is similar to commit a17d469cc3d5ccca9daa84f98fed3cc8e51e656d,
but this was just never assigned a proper copyright holder so it
defaulted to the FSF, which is not correct.
|
|
Use @AM_V@ and @AM_DEFAULT_V@ instead of directly using the variables,
so that configure can detect if make supports nested variables and use
valid values for each case.
|
|
Warned-by: i18nspector
|
|
Warned-by: i18nspector
|
|
Autoconf provides an AC_PROG_MKDIR_P macro defining MKDIR_P which is
called by AM_INIT_AUTOMAKE; the obsolete mkdir_p, currently aliased to
MKDIR_P will disappear with automake 1.13.
|
|
The standard way to select if a specific component of the build is to
be enabled or disabled is through --enable-foo and --disable-foo
options, --with-foo and --without-foo are used for selecting external
modules to be used.
|
|
Closes: #608884
[guillem@debian.org:
- Hook into po4a and build infrastructure.
- Place Vendor-URL just after Vendor field.
- Add SEE ALSO reference in dpkg-vendor.5. ]
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
|
|
This avoids the absolute paths in the po4a Discard output messages,
and simplifies the build infrastructure by not needing the change
directory gymnastics and builddir po4a variable in the po4a.cfg file.
It's been enough time now since #538136 was filed precisely for dpkg
needs, to rely on these “new” options.
|
|
There's no way to invoke po4a for the clean target w/o it possibly
modifying the .pot file, which makes the distcheck target fail in
that case.
|
|
|
|
|
|
Missed in commit 4be28d99de2c8fe27c6c16bc9c114f7cef550f79.
|
|
Commit 39c6dab89bbea9fe336f869b65e33102ba238205 introduced a regression:
make install during a package build in a tree generated by make dist would
no longer install the manual page... because they are already built and
available in $(srcdir) while $(CURDIR) was ok for the case where the
manual pages are not pre-built.
No we try both paths and pick the first one that exists.
|
|
It is a public interface even if working around known limitations.
|
|
Up to now it was only working in a directory obtained by make dist and
not when building the debian package directly from the git repository.
|
|
|
|
This program is designed to be run within maintainer scripts to achieve
some tasks that dpkg can't (yet) handle natively either because of design
decisions or due to current limitations.
Many of those tasks require coordinated actions from several maintainer
scripts (preinst, postinst, prerm, postrm). To avoid mistakes the same
call simply needs to be put in all scripts and the program will automatically
adapt its behaviour based on the environment variable DPKG_MAINTSCRIPT_NAME
and on the maintainer scripts arguments that you have to forward after
a double dash.
|
|
Forcing the value of compilation flags through environment variables set
by dpkg-buildpackages has not been very successful up to now and suffered
from the fact that calling debian/rules directly could lead to a different
build than what dpkg-buildpackage would have done.
This commit is the start of a new solution: dpkg-buildflags is a tool that
package maintainers are supposed to use in order to retrieve compilation
flags. It offers a way to control their default values at the distribution
level while still allowing customizations by users who recompile the
source packages.
|
|
Users should be able to choose which locales to install by setting the
environment variable LINGUAS, or passing it as a make argument. Honour
the user setting and introduce a new LINGUAS_DIST to avoid undesired
behaviour on “make dist”.
Reported-by: Yuri Vasilevski <yvasilev@gentoo.org>
|
|
Some distributions already ship their own reimplementation of
update-alternatives, so we allow them to disable our own.
|
|
|
|
Use the po4a command found when doing the availability checks.
Reported-by: Felipe Contreras <felipe.contreras@gmail.com>
|
|
Make it verbose when building the Debian packages.
|
|
Suggested-by: Christian Perrier <bubulle@debian.org>
|
|
|
|
Switch to use builddir for the destination files instead of srcdir for
the source files, therefore avoiding unneeded changes in the paths in
po files regardless of where the object files get stored during build.
|
|
Factorize description of the extra override file in a new manual page.
Refer to this manpage in dpkg-scanpackages(1) and dpkg-scansources(1).
|
|
In order to properly transition to GNU's install-info, dpkg's install-info
is modified to be a simple wrapper around /usr/bin/install-info. That
wrapper warns when the user explicitely calls /usr/sbin/install-info since
the new install-info is in /usr/bin/.
This wrapper is meant to be removed at some point when all references
to /usr/sbin/install-info have gone (most probably in squeeze+1).
Also remove the manual page since there's nothing to document any more
and add a lintian override until the wrapper is removed.
Reference: http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo
|
|
It has long been superseeded by ‘date -R’.
|
|
This tool is meant to be used in debian/rules files to have common source
packages across multiple distributions and yet still have slightly
different binary packages.
To automatically conserve customizations across derivatives of a given
distribution, one can use “dpkg-vendor --derives-from vendor” so that all
derivatives keep the same customizations when they rebuild the source
package even if the current vendor is no more the same.
|
|
When configuring with --without-dselect or --without-start-stop-daemon,
do not install the man pages related to those programs.
|
|
The backticks are treated like text, until the shell expands them, thus
making this solution portable.
|
|
Keep the old ChangeLog files as ChangeLog.old, and distribute them.
Automatically genereate the ChangeLog from “git log”. And update the
information for translators.
|
