Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
This makes it possible to select the current default behavior.
|
|
Mention the specific .specs files being used. Reword the description to
make it more clear what is going on.
Closes: #900088
|
|
This unifies the term with the rest of the codebase, and makes it more
descriptive.
|
|
Warned-by: i18nspector
Fixes: stray-previous-msgid
|
|
Warned-by: i18nspector
Fixes: boilerplate-in-initial-comments
|
|
Update to 2919t1f.
|
|
The Alioth site has shut down, let's move to the new dpkg.org hosting.
|
|
Update to 2919t1f.
|
|
Currently, in order to run dpkg, frontends have to release the database
lock before invoking dpkg and re-acquire it afterwards, leaving a short
time where the database is unlocked and a different dpkg process or
frontend could lock it.
Frontend locking addresses the problem by creating a "lock-frontend"
file that is acquired by the frontend and not released for dpkg
invocations. Thus, multiple frontends cannot race for the database lock.
This change extends the frontend lock to dpkg itself, acquiring it
whenever the variable DPKG_FRONTEND_LOCKED is not set, so that a user
manually running dpkg or a frontend not supporting this protocol cannot
interfere with a currently running frontend.
[guillem@debian.org:
- Add documentation.
- Rename frontend lock file.
- Fix error strings. ]
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Using --no-rename as the default optimizes for the wrong case, as that's
the exception, and while the safest option, it is needed only by packages
that are part of the pseudo-Essential set. It's also cumbersome for the
--local case.
We will emit a warning asking those to be explicit, so that we can switch
the default to --rename during the 1.20.x cycle.
Prompted-by: Paul Wise <pabs@debian.org>
|
|
Document its intended usage and how it differs from --rename.
This will make it possible to do a behavior switch during the 1.20.x
release cycle.
|
|
Update to 2915t1f.
|
|
Prompted-by: Mattia Rizzolo <mattia@debian.org> (on IRC)
|
|
Update to 2914t1f.
|
|
This new option makes it possible to force falling back to the legacy
behavior of assuming that debian/rules files require root.
|
|
This variable is set by the builder to notify debian/rules that it
supports this specification.
Wordsmithing-by: Niels Thykier <niels@thykier.net>
|
|
This variable should not be dpkg specific, as it is supposed to be set
by any builder driving the package build, and not just dpkg itself.
Introduce ephemereal backwards compatibility by mapping the old name to
the new one, even thught there are no known users.
|
|
Closes: #881401, #881403
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
|
|
Update to 2910t1f.
|
|
The initial color support only covered the C and perl programs, and
missed this shell script.
|
|
|
|
|
|
Update to 2907t1f.
|
|
Spotted-by: Helge Kreutzmann <debian@helgefjell.de>
|
|
Update to 2907t1f.
|
|
Update to 2890t12f6u.
|
|
|
|
Add support for negating the option via --no-uniform-compression.
|
|
This new area includes an lfs feature, to be used instead of the
getconf(1) interfaces which cannot support cross-building.
|
|
We support a new source package Description field in debian/control
that will be copied into the .dsc file. The field will also be used
to initialize the new source:Synopsis and source:Extended-Description
substvars that will be available when generating the DEBIAN/control
and .changes files.
Closes: #555743
|
|
This field can have substvars applied in the binary package, so it is a
safe replacement compared to all other output fields. More so with the
newly introduced S:<source-field> style automatic substvars.
Closes: #856547
|
|
Packages intended to be built in a generic way must never rely on the
currently running kernel on the build system (an exception could be an
optimization rebuild using the current system as the reference baseline).
But to be able to detect when a package might not be reproducible due to
varying kernel information it is still useful to be able to record this
information. Although that information can be very sensitive.
When the builder has explicitly enabled the Build-Kernel-Version field
with the new dpkg-genbuildinfo --always-include-kernel option, it will
get included in the generated .buildinfo file.
Closes: #873937
|
|
|
|
Update to 2892t1f.
|
|
This command is equivalent to --status but in deb822 format.
|
|
Implement the rootless-builds specification, by honoring the
Rules-Requires-Root (R³) field.
|
|
This sets the control member entries always to root:root, and makes it
possible to do the same for the data member entries via the new
--root-onwer-group option.
Closes: #291320
Based-on-patch-by: Niels Thykier <niels@thykier.net>
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Update to 2869t1f.
|
|
Closes: #864882
|
|
Ref: http://www.openwall.com/lists/oss-security/2016/02/17/9
|
|
For any dependency field found on debian/control, trailing commas are
accepted and eliminated when generating the binary control files. So
that things like substvars can be used at the end of the list even if
they produce no output.
Prompted-by: Mattia Rizzolo <mattia@debian.org>
|
|
|
|
Reported-by: Niels Thykier <niels@thykier.net>
|
|
Update to 2845t1f.
|
|
|
|
|
|
Update to 2845t1f.
|
|
|