jamesdbloom / grunt-debian-package Goto Github PK

Specifying files as in the provided example does not work. It results in Warning: pattern.indexOf is not a function Use --force to continue.. Using --force makes it run, but then no source files are added.

I got it to work by wrapping it like so:

files: {
    files: [
        { /* files definitions */ }
    ]
}

Not actually sure why this works, but you may want to correct the docs. :)

Hi,

Using links I created a symlink in the init.d directory.

What is the best way to do the install of this daemon

update-rc.d install mypackage defaults

I'm asking this since it should also work when I release an update for this package.

Gather Options Before Execution Instead of During initConfig().
It would be very helpful if I could do this:

module.exports = function(grunt) {
  grunt.loadNpmTasks('grunt-shell');
  grunt.loadNpmTasks('grunt-debian-package');

  grunt.initConfig({
    shell: {
      get_version: {
        command: 'git describe',
        options: {
          stdout: false,
          callback: function(err, stdout, stderr, callback) {
            if (stdout.length !== 0) {
              grunt.option('version', stdout);
            } else {
              // fallback to the version in packge.json
              var package_json = grunt.file.readJSON('package.json');
              grunt.option('version', package_json.version);
            }
            callback();
          },
        },
      },
    },
    debian_package: {
      dist: {
        options: {
          version: grunt.option('version'),
          dependencies: '',
          maintainer: {
            name: 'JD',
            email: '[email protected]'
          },
        },
      },
    },
  });

  grunt.registerTask('package',[
    'shell:get_version',
    'debian_package:dist',
  ]);
}

Looking at the code you might even expect it to work. The problem is debian_package values are determined during grunt.initConfig(), so there's no opportunity to load values dynamically. When grunt.option('version') is called, shell:get_version has not yet run, so the value is undefined:

$ grunt package
Running "shell:get_version" (shell) task

Running "debian_package:dist" (debian_package) task
Warning: Cannot call method 'replaceAll' of undefined Use --force to continue.

I think this can be solved by making debian_package accept a function rather than an object during initConfig(). Something like this:

debian_package: {
  dist: function() {
    return {
      options: {
        version: grunt.option('version'),
        dependencies: '',
        maintainer: {
          name: 'JD',
          email: '[email protected]'
        },
      },
    };
  },
},

I was very excited to use grunt-debian-package, but until this is possible I cannot use it. If it is already possible somehow then I wasn't able to figure out how.

fixed replace version as currently using old of date version

Hello,

I can't seem to use :

        files: [
            {
             src: [ 
                'build/cache/linux64/0.9.2/nw.pak',
                'build/cache/linux64/0.9.2/nw',
                'build/cache/linux64/0.9.2/libffmpegsumo.so'
             ],
             dest: 'foo/nw/'
            },
            {
             expand: true,
             cwd: 'src/',
             src: '**',
             dest: 'foo/src/'
            }
        ]

Output is :

Running "debian_package:files" (debian_package) task
Verifying property debian_package.files exists in config...OK
Warning: Object #<Object> has no method 'indexOf' Use --force to continue.

File names should be transformed for safe use in https://github.com/jamesdbloom/grunt-debian-package/blob/master/tasks/debian_package.js#L35 expression.

Such trouble could occur if you use babel-core.

If I specify a file source of */ the expansion includes the directories themselves. This causes the Makefile to copy the original directory into itself (so to speak) due to the use of -a in the cp command.

For instance, if the Gruntfile included something like this:

var config = {
  debian_package: {
    dynamic_mappings: {
      files: [
        { expand: true, cwd: 'files', src: '**/*', dest: '/' }
      ]
    }
  }
}

This will cause the Makefile to include something like the following (example only):

mkdir -p $(DESTDIR) && cp -a /tmp/src/files/etc $(DESTDIR)/etc
mkdir -p $(DESTDIR)/etc && cp -a /tmp/src/files/etc/apt $(DESTDIR)/etc/apt
mkdir -p $(DESTDIR)/etc/apt && cp -a /tmp/src/files/apt/sources.list $(DESTDIR)/etc/apt/sources.list

When the package is built, this causes the following directory structure:

etc
`-- apt
|-- apt
|   `-- sources.list
`-- sources.list

As you can see, the apt directory is recursively copied into /etc (second line of the Makefile example above) and then the apt directory is copied into the previously created/copied directory.

My solution to this was to add a grunt.file.isDir(filepath) to preparePackageContents in tasks/debian_package.js. See abates/grunt-debian-package@946fb2d

If this solution is acceptable, I can submit a pull request.

Regards,
Andrew

I need to specify my own debian/rules file.

My file must contain this line:
override_dh_usrlocal:

I think the best approach is to allow users to specify the path to this file instead of assuming ./packaging/debian/rules within your plugin source.

I tried to package a simple angular app but I have the following error when I launch 'grunt debian_package --verbose'. debhelper is already installed but I'm asked to install it again.
Moreover is it normal that the source format is in '3.0 (native)' and not '3.0 (quirt)'?

dpkg-buildpackage: host architecture amd64
fakeroot debian/rules clean
dh clean
dh_testdir
dh_auto_clean
dh_clean
rm -f debian/adminui.substvars
rm -f debian/adminui..debhelper
rm -rf debian/adminui/
rm -f debian/.debhelper.log
rm -f debian/files
find . ( ( -type f -a
( -name '##' -o -name '.' -o -name '_' -o -name DEADJOE
-o -name '.orig' -o -name '.rej' -o -name '.bak'
-o -name '..orig' -o -name ..rej -o -name '.SUMS'
-o -name TAGS -o ( -path '/.deps/_' -a -name '*.P' )
) -exec rm -f {} + ) -o
( -type d -a -name autom4te.cache -prune -exec rm -rf {} + ) )
rm -f *-stamp
dpkg-source -b packaging
dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision
dpkg-buildpackage: error: dpkg-source -b packaging gave error exit status 255
debuild: fatal error at line 1364:
dpkg-buildpackage -rfakeroot -D -us -uc -sa failed
Reading tmp/adminui_2.1.0-1_amd64.build...OK

error running debuild!!
debhelper dependency not found try running 'sudo apt-get install debhelper'
Warning: Task "debian_package:files" failed. Use --force to continue.

Here is my Gruntfile.js config:

debian_package: {
  options: {
    maintainer: {
      name: 'FXG',
      email: '[email protected]'
    }
  },
  files: {
    src: [
      '<%= project.dist %>/**'
    ],
    dest: '/var/www/'
  }
}

On Debian Jessie this task fails with the following error message, which is only displayed when --verbose has been added to the grunt command:

can't build with source format '3.0 (native)': native package version may not have a revision

Without --verbose a generic and not helpful error message is displayed that may lead into the wrong direction. On a recent Ubuntu this error doesn't happen. (But probably will on future releases.)

The reason for this is that the package is built as a native package whereas the version number generated by this grunt task indicates that it is a non-native package because it uses a hyphen (like 1.2.3-4 instead of just 1.2.3).

My workaround for this is to simply replace the hyphen with a dot. In
node_modules/grunt-debian-package/packaging/debian/changelog
replace
${name} (${version}-${build_number}) experimental; urgency=low
with
${name} (${version}.${build_number}) experimental; urgency=low
Now packaging should work as expected, however the version number will now show up as 1.2.3.4

This is also probably the correct fix for this problem since revision and build number are two different things anyway.

Can we get the latest code released to npm?

debian_package: {
      files: [
        { src: ['src/**/*.js'], dest: '/var/test1/' },
        { src: ['test/**/*.js'], dest: '/var/test2/' }
      ],
  } // <=  debian_package

It failed to packaging:

# grunt debian_package
Running "debian_package:files" (debian_package) task
Warning: Object #<Object> has no method 'indexOf' Use --force to continue.

Aborted due to warnings.

However it will succeed if using single format:

files: { src: ['src/**/*.js'], dest: '/var/test1/' },

Here are the versions I used:

node: 0.10.26
grunt: 0.4.5
grunt-debian-package: 0.1.11

It would be nice to have ability to specify unpacked files owner and group via config.

Hello,

Excellent module you got here! Saved me a lot of trouble and really nice to not require a separate Makefile for building a deb package for our application.

I was wondering if there is any mechanism to specify dependencies for the built deb? I'd like to have the built debian depend on a specific version of node.js. The ability to freeform provide a list of dependencies (i.e.: nodejs (>= 0.10.30)) would be perfect. If not I'd be happy to add something like that.

Is there a way to have an empty directory picked up?

We'd like to include a logs directory, with our code generating the files in that directory after deployment. is this possible?

I use this for a project that doesn't include any native components, but the build package still has the amd64 arch. It would be good to be able to specify that a package should get the 'all' architecture.

Hey,
I found your grunt plugin and think it's quite nice, but there is one thing which prevents me from using it...

Is there a possibility to include own postinst, preinst,... scripts in a grunt-built Debian package?

I want to reconfigure the target system, on which the .deb package is installed and so I am highly dependent on those install scripts.

I checked your source and didn't find a hint of copying these extra files to */control/...
Is there an easy way to add this feature?

I may contribute some source if you could hint me to the right parts in the code