| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
dpkg-source will now clean up after a failed application of a quilt patch.
This required passing “--reject-file=-” to patch to avoid the creation
of *.rej files that would clutter the source package and intercepting
the failure to restore the files from .pc/$patch/.
dpkg-source will also display a message explaining the most likely cause
of failure (patch applying with fuzz).
Closes: #652970
|
|
When coming out of eval blocks and reporting on errors, make sure $@ is
included as part of the textual output so that the real underlying error
is reported.
dpkg-source: error: source package format `3.0 (native)' is not supported
(Perl module Dpkg::Source::Package::V3::native is required)
Of course, that file is being required just fine, the problem turned out
to be missing File::Temp, but without including $@, it was not obvious
due to the custom error message completely hiding this detail.
Improved-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
With the “3.0 (quilt)” source format, dpkg-source would happily ignore the
patch-file parameter if it was not found, instead of properly erroring
out. Furthermore a relative filename would also not be found when the
given directory is "." since dpkg-source does a chdir("..") in that case.
Both issues are fixed by this commit.
Closes: #652414
Reported-by: Sam Hartman <hartmans@debian.org>
|
|
Regression introduced in commit 383247f0d2dfbd3d0d6388f87869ac1abaa8b7cd.
Closes: #652113
Reported-by: Vincent Danjean <vdanjean@debian.org>
|
|
The location of programs on the filesystem is not standardized, and as
such using absolute paths is not a portable assumption to make. This
causes test suite errors on at least Mac OS X.
Use just the program name on perl system() calls, when needing the full
path use Dpkg::Path::find_command() in perl code and “which” in shell
code.
Reported-by: Stuart Ambler <stuart@zulazon.com>
|
|
With 2.0 source packages, dpkg-source records as a comment in
debian/patches/.dpkg-source-applied whether the patches have
been applied at build time or at unpack time.
This can lead to differences between the file in the build tree
and the file in the reference tree used to check for changes.
Thus we need to ignore that file in the diff process or the build
might fail considering this difference as a local change that
has not been recorded in a patch.
Reported-by: Jakub Wilk <jwilk@debian.org>
|
|
Reported-by: Jakub Wilk <jwilk@debian.org>
|
|
changes
The former behaviour to always generate the automatic patch required to
not apply it on the tree used as a basis for the patch generation. That
way it could be updated at each build.
With the new behaviour to fail on any new change, we should no longer
ignore it. It must be applied on the reference tree except when
--auto-commit is on.
This should fix 227 (source package) build failures in Debian unstable.
|
|
The single-debian-patch option usage in Dpkg::Source::Package::V2
was typoed as single_debian_patch, and thus not avoiding aborting
on upstream changes. Instead of fixing the typo, let's just not
expose single-debian-patch in Dpkg::Source::Package::V2, as it's
Dpkg::Source::Package::V3::quilt specific and as such a layer
violation, the code will just set auto_commit when single-debian-patch
is specified, which is the actual intended behaviour. Reflect this
explicitly in the man page.
Regression introduced in commit 46b688e4824f00842568b517b119eec34a5f7286.
Reported-by: Bernhard R. Link <brlink@debian.org>
|
|
|
|
The supplementary arguments suggested are awkward and are generally not
needed unless your package is huge and takes a long time to uncompress
and diff.
The best advice is thus “dpkg-source --commit” without any parameter.
Maintainers of big packages will read the manual package and learn
by themselves how to reuse the generated patch.
|
|
patch"
The message should only be printed if such a patch has really
been created.
Reported-by: Sven Joachim
|
|
Navite packages (both "1.0" and "3.0 (native)") failed to remove
the temporary tarball if the process is interrupted during its
generation.
Reported-by: Cyril Brulebois <kibi@debian.org>
|
|
Formats "2.0" and "3.0 (quilt)" now fail by default in presence of
changes to upstream files that are not managed by their respective patch
system. The user is invited to run dpkg-source --commit if he
wants to keep the changes.
This will avoid that maintainers upload packages with unexpected changes.
The old behaviour can be kept with the option --auto-commit. The option
--abort-on-upstream-changes is now useless with formats "2.0" and "3.0
(quilt)" except to cancel the effect of a former --auto-commit.
See http://lists.debian.org/20110529085303.GA17707@rivendell.home.ouaza.com
for the discussion that enterined this change.
|
|
Drop all references to $autopatch which has nothing to do with
generating a patch. Move the message explaining where the
changes have been recorded outside of the function.
Drop unused parameter to get_patch_header().
Drop intermediary variables which are only used once.
|
|
This commit extracts the logic to create automatic patches in a new
generate_patch() method. It's expected that this function will be
reused to implement dpkg-source --commit.
The code is mainly moved around as-is to simplify reviews. All
desired changes have been left for further commits.
|
|
While register_autopatch() is only able to register a patch as the
automatic patch, register_patch() can register a patch under any
desired patch name.
Also it doesn't not drop the input patch file, leaving that responsibility
to whoever called it. However if the input patch file is empty, it will
remove the target patch from the debian source package.
|
|
Formats "2.0" and "3.0 (quilt)" now generate the patch header
with the same code. Drop some useless duplication.
|
|
Now we include the template corresponding to files that we try to look
for.
|
|
The list of ignored files was only generated by expanding the patterns
relative to the current directory (which usually is the directory above
the source package). Instead what we want is to expand them at the
top-level directory of the source package and at the directory being
inspected.
Reported-by: Joachim Breitner <nomeata@debian.org>
|
|
There are perfectly legitimate cases where the patches are not applied
and there's no need to output a long warning about this. A brief message
is more than enough.
|
|
Implement this logic for the "2.0" and "3.0 (quilt)" source formats.
|
|
Useful to use in combination with a --single-debian-patch option
in debian/source/local-options.
The commit also changes the place where the local-options file is ignored.
Instead of using the default diff_ignore regexp, it's hardcoded in the
initialization function in case the default regexp is not used.
Suggested-by: Russ Allbery <rra@debian.org>
|
|
Add the extraction part of Dpkg::Source::Package to the supported API.
It's useful to extract source packages without having to depend on
dpkg-source (and hence dpkg-dev).
Suggested-by: Niels Thykier
|
|
Closes: #627462
Based-on-patch-by: Jakub Wilk <jwilk@debian.org>
|
|
The "." was not escaped and the regex incorrectly matched an "ipc"
directory for example.
Reported-by: Mike Hommey <glandium@debian.org>
|
|
Closes: #620490
|
|
Commit 255e73e11d1365fbb1e8d78287fad751a8ebc6e5 introduced a regression
with empty patches by assuming that a patch analysis would always give
back at least one filename.
Reported-by: Niels Thykier <niels@thykier.net>
|
|
It will now accept seeing the same file twice
Reported-by: Bastian Blank <waldi@debian.org>
It will no longer match on the English text "No newline at end of file" as
it might be translated in some cases. It will only consider the intial
"\ ".
Reported-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
|
|
Colin's change in 40dcf24632684ec726210dd4437fdedbdbe6134e meant that the
autopatch is parsed while it's already applied and this can trigger some
undue warnings.
This patch silences them. And also deals with similar cases that were
unnoticed up to now.
|
|
Since 1.13.14~20 (2006-02-10), dpkg-source touches the files it
patches when unpacking, with a single date. This way, the order of
mtimes does not depend on the order in which the files were patched,
which is convenient when e.g. configure.in and configure are patched.
More precisely, dpkg-source does something like the following:
my $now = time();
foreach my $fn (@patched_files) {
utime($now, $now, $fn);
}
Unfortunately when the filesystem is NFS, "touch" and normal
modification set mtime and atime to the current time on the server
side, while time() returns the current time on the client side.
The two clocks can disagree, producing breakage.
So unless a timestamp has been passed explicitly, use utime(undef,
undef, $fn) to set mtime for the first file to the server side time
and copy it (rounded down to a number of seconds) to all patched
files.
Reported-by: Stéphane Glondu <glondu@debian.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Raphaël Hertzog <hertzog@debian.org>
Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
|
|
Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
|
|
|
|
- Enhance checks to catch maliciously crafted patches which could modify
files outside of the unpacked source package.
- Do not consider a top-level symlink like a directory when
extracting a tarball.
- Exclude .pc while extracting the upstream tarball in 3.0 (quilt)
as patch blindly writes in that directory during unpack (and would
follow any existing symlink).
|
|
The code was erroneously assuming that $newdirectory was always
a simple filename, but it can be a complete path.
|
|
If you have debian/patches/ubuntu.series and you were unpacking the source
package on ubuntu, quilt was still directed to debian/patches/series
instead of debian/patches/ubuntu.series.
|
|
commit 2290a1248af081c6df98805295d921e919624356 introduced a regression
for V1 native packages since they were no longer excluding
debian/source/local-options.
|
|
It should be excluded even if the user provides -I or -i options to
override the lists of files to ignore.
Reported-by: Robert Luberda <robert@debian.org>
|
|
tarballs
dpkg-source only extracts tarballs in directories that it has created
itself, there's no risk of overwriting any user files. Furthermore in
the few cases where we do extract a tarball on a non-empty directory,
we really want to be able to overwrite files already present. That's the
case with a debian.tar.gz file.
Reported-by: James Westby <james.westby@linaro.org>
|
|
Some of the singular forms are not currently used, but we keep them for
consistency, and to avoid confusing translators.
Closes: #594218
|
|
place
In source formats "2.0" and "3.0 (quilt)", make sure to remove the
upstream-provided debian directory before copying the debian-provided
version of that directory in place. Closes: #590297
|
|
It was looking in the current directory, which works most of the time,
but not always.
|
|
With this change, it can't match the top-level directory anymore
and the source package directory can again end with a tilde without
creating problems.
|
|
Much better than the old approach of a tarball of the .git repository,
the git bundle format is simple to understand and work with, and
doesn't need to be sanitized for security. Much code went away.
Supports limiting history depth by creating a shallow clone.
Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
|
|
patch is now run without its -s flag and thus outputs the usual messages
about which file it's patching and gives more verbose error messages.
Those messages are captured and only displayed to the user when the
patch application failed.
|
|
This option can be used with source formats 1.0, 2.0 and 3.0 (quilt). It
aborts every time that you try to build a source package which
contains (unmanaged) changes to the upstream source code.
|
|
This option is used by source formats 2.0 and 3.0 (quilt) to unapply
patches after a successful build. It's useful for people who manage their
packages in a VCS repository and prefer to have patches unapplied, even
after a package build.
Given that this option is a matter of personal taste, do not allow it
in debian/source/options so that the resulting source package cannot
have this behaviour by default and so that all source packages behave
in a consistent way: patches applied by default is a major feature
of the new formats.
|
|
Conflicts:
debian/changelog
|
