On Monday 18 January 2016 06:04 PM, Antonio Terceiro wrote: > On Sat, Jan 16, 2016 at 03:58:23PM +0530, Pirate Praveen wrote: >> Hi Can anyone help me figure out why debconf is failing for gitlab? I >> have checked in my code in debconf branch (with upstream-8.4) on alioth. >> >> It just gives this error message, I tried DEBCONF_DEBUG=developer >> option, but not much details are shown >> >> dpkg: error processing package gitlab (--install): >> subprocess installed post-installation script returned error exit >> status 128 >> Processing triggers for systemd (228-4) ... >> Errors were encountered while processing: >> gitlab > > well the postinst exited with 128 ... you have to figure out why. you > can add a `set -x` to the top of the postinst to see the trace in the > dpkg output stream. > There is not much useful extra information, $ sudo dpkg -i gitlab_8.4.0+dfsg~rc1-1_all.deb Selecting previously unselected package gitlab. (Reading database ... 62155 files and directories currently installed.) Preparing to unpack gitlab_8.4.0+dfsg~rc1-1_all.deb ... Unpacking gitlab (8.4.0+dfsg~rc1-1) ... Setting up gitlab (8.4.0+dfsg~rc1-1) ... + echo I'm here............................ I'm here............................ + . /usr/share/debconf/confmodule + [ ! ] + PERL_DL_NONLAZY=1 + export PERL_DL_NONLAZY + [ ] + exec /usr/share/debconf/frontend /var/lib/dpkg/info/gitlab.postinst configure debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Configuring gitlab ------------------ Please choose the domain name which should be used to access this instance of Gitlab. This should be the fully qualified name as seen from the Internet, with the domain name that will be used to access the pod. If a reverse proxy is used, give the hostname that the proxy server responds to. Fully qualified domain name for this instance of Gitlab: gitlab.pxq.in Enabling https means that an SSL certificate is required to access this Gitlab instance (as Nginx will be configured to respond only to https requests). A self-signed certificate is enough for local testing (and can be generated using, for instance, the package easy-rsa), but it is recommended for a production instance. Some certificate authorities like StartSSL (startssl.com) or WoSign (buy.wosign.com/free) offer free SSL certificates. You can disable https if you want to access Gitlab only locally, via Unicorn on port 3000. If you disable https, Nginx configuration will be skipped. Enable https? [yes/no] yes dpkg: error processing package gitlab (--install): subprocess installed post-installation script returned error exit status 128 Processing triggers for systemd (228-4) ... Errors were encountered while processing: gitlab
Attachment:
signature.asc
Description: OpenPGP digital signature