What does “dpkg-buildpackage -rfakeroot -d -us -uc -S failed” mean

dpkgpackaging

I was trying to build a simple Debian package,
I did these steps with user root:

First, I downloaded the upstream tarball, then:

 $ mv hithere-1.0.tar.gz hithere_1.0.orig.tar.gz

Then:

 $ tar xf hithere_1.0.orig.tar.gz

After that:

 $ cd hithere-1.0
 $ dch --create -v 1.0-1 --package hithere 
 $ cd debian/
 $ rm *.ex *.EX

Then I edited "control file" and "copyright file":

 $ nano control
 $ nano copyright


 $ cd ..
 $ debuild -S

After the last command, This error was generated:

root@mehrnaz-MS-A934:/home/fabdollahei/hithere-1.0# debuild -S dpkg-buildpackage -rfakeroot -d -us -uc -S
dpkg-buildpackage: warning: using a gain-root-command while being root
dpkg-buildpackage: source package hithere
dpkg-buildpackage: source version 1.0-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by root <f.abdollahei@itrc.ac.ir>
dpkg-source --before-build hithere-1.0
dpkg-source: error: syntax error in hithere-1.0/debian/control at line 15: block lacks the 'Package' field
dpkg-buildpackage: error: dpkg-source --before-build hithere-1.0 gave error exit status 255
dpkg-source: error: syntax error in hithere-1.0/debian/control at line 15: block lacks the 'Package' field
dpkg-buildpackage: error: dpkg-source --before-build hithere-1.0 gave error exit status 255
debuild: fatal error at line 1364:
dpkg-buildpackage -rfakeroot -d -us -uc -S failed

How do I get rid of that fatal error?

Best Answer

The message is just saying that dpkg-buildpackage command failed. If you read the messages you will notice where's the problem right away:

dpkg-source: error: syntax error in hithere-1.0/debian/control at line 15:
block lacks the 'Package' field
dpkg-buildpackage: error: dpkg-source --before-build hithere-1.0 gave error exit status 255

If you fix that (and maybe other problems it has, that could show up later) it should work.

Yeah, but how do I solve it?

There is no single way to solve it. There are so many reasons why this can happen that it's futile to attempt to list them all in a single post. Each and every circumstance is almost unique to that package/environment.

But, there's redemption. The fact that you see this message means that probably there is more relevant information in the lines before the message. For illustrative purposes I will use a example:

(Reading database ... 81657 files and directories currently installed.)
 Removing mongodb-10gen ...
 arg: remove
 invoke-rc.d: unknown initscript, /etc/init.d/mongodb not found.
 dpkg: error processing mongodb-10gen (--remove):
  subprocess installed pre-removal script returned error exit status 100
 invoke-rc.d: unknown initscript, /etc/init.d/mongodb not found.
 dpkg: error while cleaning up:
  subprocess installed post-installation script returned error exit status 100
 Errors were encountered while processing:
  mongodb-10gen
 E: Sub-process /usr/bin/dpkg returned an error code (1)

Now, to find the problem, you need to read backwards:

E: Sub-process /usr/bin/dpkg returned an error code (1) doesn't tell me anything useful. So moving on.
Errors were encountered while processing: mongodb-10gen just tells me what package have problems. Is useful but not enough.
subprocess installed post-installation script returned error exit status 100: this tells me that the script that failed was the postinst, the one executed in post-installation. This will come handy in some situations, but not in this one.
dpkg: error while cleaning up: nothing useful here.
invoke-rc.d: unknown initscript, /etc/init.d/mongodb not found. BINGO! This tells us that invoke-rc.d, a binary that controls the init script in most Debian-like system, failed. It failed because it couldn't find the /etc/init.d/mongodb script. This is bad. We need to create it or copy from somewhere else so it starts working again. Reinstalling the package is also normally an option for file not found errors.

In this case, reporting a bug is not necessary because is probable that we were the ones that removed the script, but if you are completely sure you didn't touch the file (a debsums -sla should confirm it) then report a bug.

So, what exactly do you need to get help? Ideally, the complete output of the problem. It's also helpful to include the output of sudo dpkg -C and sudo apt-get check, and the output of apt-cache policy package1 package2... where "package1 package2 ..." includes all the packages with problems.

Debugging dpkg configure failure with grub

So, at the time of writing, you brilliantly narrowed down your problem to grub-mkconfig and wonder how to debug it.

grub-mkconfig is a shell script that basically build your grub.cfg configuration file by executing every script in /etc/grub.d. There is a set -e command at the beginning of grub-mkconfig, meaning "stop at the first non-managed error you encounter". Chances are your problem is due to the failure of one of the grub.d scripts.

First, let's identify the culprit. Run:

dash -vx grub-mkconfig -o /boot/grub/grub.cfg

dash, the Bourne Shell interpreter that is most likely bound to /bin/sh, will output every line it executes. Since the script probably fails due to the set -e command, the last line is likely to be the grub.d sub-script that fails. I assume you will get something like:

+ echo ### BEGIN /etc/grub.d/99_buggy_script ###
+ /etc/grub.d/99_buggy_script

The script name itself won't probably give you enough evidence on what is going on. Since it's also a Bourne shell script, you can debug it the same way. Change the first line of the grub.d script from

#!/bin/sh

To:

#!/bin/sh -vx

And run grub-mkconfig -o /boot/grub/grub.cfg (dash -vx is no longer necessary). The trace you will get is from the grub.d script.

Hopefully, the problem will be obvious now. Once you have fixed it, don't forget to remove the -vx flags at the beginning of the grub.d sub-script.

Best Answer

Related Solutions

DPKG Error Code 1 – What Does This Mean?

Yeah, but how do I solve it?

Debugging dpkg configure failure with grub

Related Question