A prior commit removed `rake` as a development dependency on the
assumption that nothing in fpm's development process actually required
the use of `rake`.
However, I had forgotten about #756 (year 2014) which adds FPM::RakeTask
and some test coverage. FPM::RakeTask was added to allow folks to more
easily invoke FPM from within a Rake task.
At this time, I see no reason to remove FPM::RakeTask. Further, because
`rake` is typically (in my experience) used only in development
environments. Therefore, I believe the right solution is to restore
`rake` as a development_dependency in order to allow the test suite to
pass. For users of FPM::RakeTask, I would assume (hopefully correctly!)
that they already have `rake` installed as a dependency in their own
project, so the `fpm` gem has no need to specify `rake` as a general-use
dependency.
When studying newer versions of Rake, I found:
* Rake v13 requires Ruby 2.2 or newer.
* Rake v12.xx and older are flagged as having security vulnerabilities.
In order to minimize chaos, this commit adds an unversioned dependency
on rake. This is to help fpm service more versions of Ruby and resist
efforts by any dependency to dictate which version of Ruby is used.
This reverts db9db670c3.
Fixes#1877
When converting, we check if the original package was of a certain type.
In order for those types/constants to be available, we have to require
those files.
Test cases which now work correctly with this commit, but had failed
prior:
% bundle exec ruby -r./lib/fpm/package/rpm.rb -e 'FPM::Package::RPM.new.tap { |x| x.name = "fancy" }.convert(FPM::Package::RPM)'
% bundle exec ruby -r./lib/fpm/package/deb.rb -e 'FPM::Package::Deb.new.tap { |x| x.name = "fancy" }.convert(FPM::Package::Deb)'
Fixes#1854
Prior to this change, pip would download Python packages to $PWD which
leaves files hanging around.
The build_path is automatically removed when fpm exits.
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 should silence a warning in cases when packages do not contain any
/etc files. Prior to this commit, most debian package creation would
have this warning emitted:
```
Debian packaging tools generally labels all files in /etc as config files, as mandated by policy, so fpm defaults to this behavior for deb packages. You can disable this default behavior with --deb-no-default-config-files flag {:level=>:warn}
```
Fixes#1851
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
This changes the Dockerfile to create docker images suitable for running tests (fpm rspec suite in docker) and also as a normal release (using fpm through docker).
Fixes#1682, #1453
https://blog.readthedocs.com/build-errors-docutils-0-18/
For #1848
Hoping this fixes it. Readthedocs emails me whenever doc build fails, and
for the past week or two, it has said the following:
```
Running Sphinx v1.8.5
loading translations [en]... done
making output directory...
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 37 source files that are out of date
updating environment: 37 added, 0 changed, 0 removed
reading sources... [ 2%] changelog
reading sources... [ 5%] changelog_links
reading sources... [ 8%] cli-reference
Traceback (most recent call last):
File "/home/docs/checkouts/readthedocs.org/user_builds/fpm/envs/latest/lib/python2.7/site-packages/sphinx/cmd/build.py", line 304, in build_main
app.build(args.force_all, filenames)
[ ... cut for brevity ... ]
File "/home/docs/checkouts/readthedocs.org/user_builds/fpm/envs/latest/lib/python2.7/site-packages/sphinx/util/nodes.py", line 94, in apply_source_workaround
for classifier in reversed(node.parent.traverse(nodes.classifier)):
TypeError: argument to reversed() must be a sequence
```
I needed found this issue while trying to write documentation and
examples for fpm's cpan support. Fpm was generating invalid debian
packages as a result! This should fix things.
This example uses the `ascii-art` npm package. I have realized that
using this package with its example ascii art is likely not accessible
for screen readers. I'll keep the example for now and revise it later.
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
It's been hard to debug travis failures for a long time, and since the recent credentials-issue[1] being handled poorly, I think we can close this chapter.
> After 3 days of pressure from multiple projects, [Travis CI] silently patched the issue on the 10th. No analysis, no security report, no post mortem, not warning any of their users that their secrets might have been stolen
[1] https://arstechnica.com/information-technology/2021/09/travis-ci-flaw-exposed-secrets-for-thousands-of-open-source-projects/
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 is a simple workaround, which transforms the filenames inside the
tar archive so that they start with `/`. This happens only in case
the filename doesn't begin with `+`, which is expected (or at least is
very likely) to be a metadata file.
```
$ tar --list -f test-package-0.0.1.txz
+COMPACT_MANIFEST
+MANIFEST
/etc/config
/usr/bin/script
$ pkg install -y test-package-0.0.1.txz && echo OK
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
test-package: 0.0.1
Number of packages to be installed: 1
[1/1] Installing test-package-0.0.1...
Extracting test-package-0.0.1: 100%
OK
```
Fixes#1811
Signed-off-by: Vlastimil Holer <vholer@opennebula.io>
Jordan Sissel
Corey Quinn
Geoff Beier
seph
Andrey Tikhonov
Clayton Wong
Vlastimil Holer