Looks like at some point django changed the admin tool from
"django-admin" to "django-admin.py"
Possibly this changed in upstream in Django on this commit, though I
don't know for certain:
85efc14a2e
As part of making "internal pip" the default (#1820), the test suite
needed two main changes:
1) Don't check for easy_install anymore
2) Try to find the right python executable.
On my Ubuntu 20.04 system, installing Python gives Python v3 which only
makes the "python3" executable available. To compensate, the test suite
now tries to find any of "python", "python2", or "python3" to use with
the test suite. When found, it will set the appropriate `--python-bin`
flag in fpm for each test.
For #1820
This adds a new flag, --python-internal-pip, which is enabled by default.
"internal pip" means using 'python -m pip' to invoke pip. Ideally this will make fpm more correctly use pip.
Tested on python 2.7.17 and 3.6.9 on Ubuntu 18.04
All python tests passing 👍👍
Fixes #1820
This feels like the right default because empty packages have no files
(especially no binary, architecture-specific files) and therefore should
be installable on any architecture.
Fixes #1846
Identified in #1840/#1841, `lintian` will error due to invalid
control.tar file, as shown below.
This test ensures that `lintian` will not crash. There were two options
I found: First, to run `lintian` and, when it crashes, it exits code 2.
Second, to run `lintian` with a single always-successful check. I chose
the second option because this allows me to rely on success/failure
(exit code 0 vs non-zero) in the event that `lintian` ever changes its
exit code, or that the crash exit code changes across older versions of
Debian.
```
% lintian example_1.0_amd64.deb
dpkg-deb: error: archive '/home/jls/projects/fpm/example_1.0_amd64.deb' uses unknown compression for member 'control.tar.bz2', giving up
/bin/tar: This does not look like a tar archive
/bin/tar: *control: Not found in archive
/bin/tar: Exiting with failure status due to previous errors
Skipping example_1.0_amd64.deb: could not read control data in /home/jls/projects/fpm/example_1.0_amd64.deb: at /usr/share/perl5/Lintian/ProcessablePool.pm line 93.
```
This fixes a bug where fpm would create an invalid debian package file.
When `--deb-compression bzip2` was used, fpm would create
'control.tar.bz2' file inside the debian package. Debian does not
support bzip2-compressed control files. Per the deb(5) manpage:
> The second required member is named control.tar. It is a tar archive containing the package control information, either not compressed (supported since dpkg 1.17.6), or compressed with gzip (with .gz extension) or xz (with .xz extension, supported since 1.17.6)
With this commit, when bzip2 is chosen for data compression, fpm will
use gzip compression on the control.tar file.
- Files in the tarball should begin with / (#1811, #1844)
- Assert certain top-level manifest fields
- Assert manifest files are present
Idea from #1844
(note: fpm calls 'iteration' what rpm calls 'release')
rpmbuild will reject the `Release` tag containing a dash with the
following error (via fpm --verbose):
```
error: line 41: Illegal char '-' (0x2d) in: Release: 1-1 {:level=>:info}
Process failed: rpmbuild failed (exit code 1).
```
This patch copies the dash-to-underscore operation that is already
applied to the version field.
Adds tests for both iteration and version field.
Fixes: #1833
This resolves an issue caused by #1803 where a user was, historically, passing `--provides 'foo (<< 1.2.3)'` which was working correctly in prior versions of fpm but creating invalid Debian packages in the newer release.
This is a funny issue because previously fpm was removing the relationship text '(<< 1.2.3)' so it never made it into the resulting Debian package. Due to #1803, this text is now passed into the resulting package, and Debian package tooling rejects it.
Added tests to cover a few valid and invalid cases.
This change also adds code to validate other relationship fields (Depends, Suggests, etc) but does not actually do any validation.
This test was failing on a lintian check which reports:
```
E: name: init.d-script-needs-depends-on-lsb-base etc/init.d/test (line 14)
```
Added `lsb-base` dependency to resolve it.
This fixes #1788. This also reverts #280. For #280, at the time, this
change to ignore versions was correct. Two years after #280, Debian
began allowing `Provides` field to have versions.
This change also fixes bug in gem-to-deb conversion where previously an
incorrect Provides syntax would be generated (but thanks to #280,
removed), so this bug was only noticed after #280 was undone!
Computers are hard sometimes.
Added tests for gem-to-deb conversion specifically for the Provides
field.
Tested manually with Docker on Ubuntu 14.04 and 18.04 and results meet
expectations.
The history here is follows:
* In 2012, fpm was patched to remove version specifiers in Provides
field because Debian didn't support it.
* In 2014, Debian dpkg[1] added support for versions in Provides field
* Somewhere between 2015-2018, Debian and Ubuntu included this new
version of dpkg.
* Debian packaging policy docs (v4.4.0) was updated to allow versions
in the Provides field.
Expected impacts:
* Older versions of dpkg/etc should _ignore_ the presence of a version
specifier. Testing on Ubuntu 14.04 confirmed this.
* Newer versions of dpkg/etc should respect the presence of a version
specifier. Testing on Ubuntu 18.04 confirmed this.
[1] https://launchpad.net/debian/+source/dpkg/1.17.11
The previous method using :if actually hides the test entirely from the run.
Now an rspec run will correctly(I hope?) show any skipped tests. The
goal is to remind me that sometimes my dev environment is missing
important tooling needed to fully test fpm.
Also: Skip pacman tests if bsdtar and zstd programs are missing.
I'm not sure why this fails, but it seems to fail mostly on newer
rpm/rpmbuild systems. Maybe my arr-pm library is incorrectly parsing
these rpms somehow? Anyway... the tests are passing now.
The `Replaces` field needs to be formated 'package (operator version)'.
This makes use of the `fix_dependency` method for consistent formatting
with other dependencies.
[Snaps][1] are self-contained squashfs images. Add basic support for
using them as inputs and outputs.
Typically Snapcraft is used to create snaps, but #1149 indicated a
desire to not use Snapcraft, so the snap is created natively, using
mksquashfs at the end to actually create the squashfs image. This may
not work for all use-cases (e.g. when the source doesn't already have
its dependencies bundled).
[1]: https://snapcraft.io/
Resolve #1181
Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
PR #1253, while fixed the bug where `source.link=dest/source.link`
resulted in `source.link=dest/source.link/source.link` introduced a bug
where `source=dest/` syntax stopped working for symlinks (it is ok for
files). This is now fixed, as the symlink source now behaves the same as
it would with a single file input. Test case testing this behaviour is
also added.
Fixes #1395
Previously, if the symlink is included into the package and specified
with
my-sym-link.so=/usr/lib/my-sym-link.so
fpm would create directory, and put the
symlink inside `/usr/lib/my-sym-link.so/my-sym-link.so
which is very surprising and it doesn't follow the same
pattern as file copying is doing.
Fixes #1135
* Add test for copying symlinks
The test explicitly sets `preserve=true` and `remove_destination=true`
to show the currently broken behavior.
* Fix copy_entry for symlinks
The fourth argument to FileUtils.copy_entry is dereference_root to
which the value of remove_destination was passed.
The fix now passes the parameters in the required position.
* Add option --source-date-epoch-default and implement for deb output.
This is the first step towards supporting bit-for-bit identical
output files given identical inputs.
Alas, Apple's ar is not too good at reading gnu ar archives,
so always use ar_cmd to find ar.
* deb: remove lines duplicated in a tragic merge conflict
Probably introduced by 62d0060178 and not removed by 500f0c052fb52
* Add options --source-date-epoch-from-changelog and --gem-stagingdir to support bit-for-bit reproducible gem -> deb conversion
In those cases where we can get the release date out of the changelog,
use it; otherwise fall back to the value given by SOURCE_DATE_EPOCH aka --source-date-epoch-default.
--gem-stagingdir is a bit of a kludge, only needed because no
compiler supports https://reproducible-builds.org/specs/build-path-prefix-map/ yet.
Could have been global option, but not sure any other package handler
invokes compilers? Could hoist it up later.
Also:
- Defer initializing staging_path so subclasses can sneak in new value
- gem: remove build files
* gem: handle a few more gem changelog variants
* gem: also remove mkmf.log; lets ffi, kgio, raindrops, and ruby-ldap build reproducibly.
* deb: don't expect diffoscope to be installed in /usr/bin. Lets it be found on mac.
* gem: document new options
A bug pointed out by #1162 showed that `fpm --version` would fail when
a .fpm file was loaded.
Moving the short `fpm --version` handling to the `run` method lets us do
this check before we load FPMOPTS env or .fpm files.
Updated the tests to only try calling with a lone `-v` or `--version`
flag to verify this works with and without a .fpm file.
Fixes #1162 and #1125. Original work by @drwl!
The flags for chdir, input, and output aren't immediately intuitive
as to what they're short for. This commit adds long versions and a
spec stub for chdir. Resolves #1187.
