Package Details: deheader 1.6-1

Git Clone URL: (read-only)
Package Base: deheader
Description: C and C++ file analyzer to determine which header enclusions can be removed while still allowing them to compile
Upstream URL:
Licenses: BSD
Provides: deheader
Submitter: anish
Maintainer: anish
Last Packager: anish
Votes: 9
Popularity: 0.000000
First Submitted: 2010-12-02 03:58
Last Updated: 2016-10-19 05:29

Latest Comments

anish commented on 2013-02-27 21:14

@esr Sent

Anonymous comment on 2013-02-25 23:02

I see a reference to deaheader patches sent to me, but I have not seen them. Please resent to

anish commented on 2011-06-01 19:46

Like I said, I'm only using python3 because it's the default on arch, not a fan of forcing people to install a whole new version of python for running a 20K program. That said, the PKGBUILD has always had the option for people to choose python2 instead

xyproto commented on 2011-06-01 09:16


I'm testing deheader against a utility I use at work, which is a single C file. It does include <string.h>, and always has, so your conclusion about it not being present is wrong. It was your broken version of deheader that gave the false report, indicating it was not.

Yes, namcap is great for improving packages, but it's not always correct. Coreutils is one such incident. The 2to3 tool is another example of a tool that can not always be trusted.

When that's said, the latest patched version of deheader does seem to work here now, but I still think it's a bad idea to patch it, instead of just using the official version and depend on python2.

anish commented on 2011-06-01 05:10

@trontonic What code are you testing against ? I can't find any differences and I tried comparing some client-server tcp code, kernel module code & a network simulator. This might be an issue with the code that you're running against. Updated with the 2to3 conversion tool that ships with python.

coreutils was a namcap suggestion, as you suggested.

deheader: in ./main.c, strcpy() portability requires <string.h>. is sorta obvious. If you're using string functions, you SHOULD be including string.h, I'd say the patched version is giving you the correct output.

xyproto commented on 2011-05-30 13:50

This package still does not work properly.

xyproto commented on 2011-05-26 16:31

Also, the package should not depend on coreutils.

xyproto commented on 2011-05-26 09:52

@anish, no it still does not work. When running your PKGBUILD, deheader gives a false report.

Here's the output for your patched version on a sample project:

deheader: in ./main.c, access() portability requires <unistd.h>.
deheader: in ./main.c, strcpy() portability requires <string.h>.
deheader: in ./main.c, popen() portability requires <stdio.h>.
deheader: in ./main.c, system() portability requires <stdlib.h>.
deheader: in ./main.c, tolower() portability requires <ctype.h>.
deheader: saw 1 files, 7 includes, 0 removable

And here's the output from the version produced by my working PKGBUILD, posted 6 days ago:

deheader: saw 1 files, 7 includes, 0 removable

Patches should be sent upstream instead of being included in the PKGBUILD.

anish commented on 2011-05-26 05:57

@trontonic I think I fixed the issue, can you check if it's working for you now ?

xyproto commented on 2011-05-25 23:15

Hey, we can make a deheader fork named decapitator, put it on github and upgrade it to python3. :)

anish commented on 2011-05-25 17:00

@trontonic weirdly with simply

-import sys, os, getopt, time, re, operator, commands
+import sys, os, getopt, time, re, operator

it is working on one of my machines. Just checked the other one, and I see the error again. I'd sent the patches to the author months ago, ESR is not interested. If I can't find a fix for this, I'll switch it back to python2. About the return 1, just habit :)

xyproto commented on 2011-05-25 10:09

Just installed and tested deheader. When running deheader in a directory containing .c-files, I get:

Traceback (most recent call last):
File "/usr/bin/deheader", line 1496, in <module>
remove, verbose))
File "/usr/bin/deheader", line 1416, in deheader
(st, t) = testcompile(sourcefile, maker, verbosity=max(1, verbose), showerrs=True)
File "/usr/bin/deheader", line 1353, in testcompile
(status, output) = commands.getstatusoutput(command)
NameError: global name 'commands' is not defined

The "commands" module is available in python2 but not in python3, so this is an issue with the python3 patches.

Just using the python2 version solves this problem and also has the bonus of leaving the problem of upgrading deheader to python3 to the developer(s) of deheader.
Sending the python3 patch to the deheader developer(s) would be the right course of action, IMO.

xyproto commented on 2011-05-25 09:58

Great, thanks for updating the package. Also, just to nitpick, "|| return 1" isn't needed anymore, ref: :)

anish commented on 2011-05-25 08:36

@trontonic Thanks for the suggestion. I'm going to stick with python 3, since that's the default on arch. Fixed to work with 3.2. Added in man pages and license change as suggested.

xyproto commented on 2011-05-20 09:55


Thanks for submitting this package in the first place.

Unfortunately, the package did not work here, when running /usr/bin/deheader, I got:

Traceback (most recent call last):
File "/usr/bin/deheader", line 32, in <module>
import sys, os, getopt, time, re, operator, commands
ImportError: No module named commands

Also, gzip is not a needed dependency, patches should (preferably) be sent to the author, the license file should be installed, the man-page doesn't have to be gzipped manually, the package name should not be in the description and the installed files should have the right permissions (755 for executables and 644 for the rest). (ref: the arch wiki) "Namcap" can be a helpful utility.

Here's a working PKGBUILD:

xyproto commented on 2011-05-20 09:47

Here's a working PKGBUILD:

The package did not work here, when running /usr/bin/deheader, I got:
Traceback (most recent call last):
File "/usr/bin/deheader", line 32, in <module>
import sys, os, getopt, time, re, operator, commands
ImportError: No module named commands

anish commented on 2011-02-15 04:00


anish commented on 2010-12-28 22:23

Updated to use python3. A python2 patch is still included in case anyone wants to stick with that. I'm no python expert, so please let me know if the patch causes any errors that I might have missed.

anish commented on 2010-12-28 21:32

@RedBeard0531 thanks. fixed & updated

Anonymous comment on 2010-12-28 06:14

You need updating for the python 2 -> 3 change