For dh_make to find the package name and version, the current directory needs to be in the format of <package>-<version>. Alternatively use the-p flag using the format <name>_<version> to override it.I cannot understand the directory name or you have an invalid directory name!

Your current directory is /home/dbb/src/emerald/emerald_0.8.8, perhaps you could try going todirectory where the sources are?

Please note that this change is necessary ONLY during the initialDebianization with dh_make. When building the package, dpkg-sourcewill gracefully handle almost any upstream tarball.

There is no libwebkitgtk-dev in Squeeze, that must be backported also, which may open up a can of worms.

Hmmm---looks like that is a part of the Wheezy webkit package, which takes quite a while to build. Perhaps just using the Squeeze libwebkit-dev instead can help? Let's try changing that in the control file....

Hey, it works...no icon in the menu entry though. And I can browse in it, though the terminal throws messages like:

xxxterm: webkit does not have "enable-dns-prefetching" property

It would be happier with the newer webkit, but that is a big backport.

The icon in the menu may be due to the fact that upstream it comes with a png icon and the standard for the Debian menu is a xpm. I read in the mentors list that the uploader made a script to convert it.Of course you may be talking instead of the desktop file and so the above has nothing to do with it. In this case just edit xxxterm.desktop and correct the path for the icon as I remember that it used to ship several png icons.

Thanks for the replies. I was looking at having a browser with an alternative rendering engine and liked the small footprint and security features of xxxterm. I'm going to do some more reading on Debian package building prior to launching into this since one of my computers with Debian is my work system which I do not want to bork. I may just update an older, backup computer to wheezy.

Edit: There is a configuration file, xxxterm.conf that can be placed in your home directory - I think you possibly can disable dns-prefetch for xxxterm.

Similarly, many browsers perform full link prefetching by default, which is downloading the content of all the embedded links, not just looking up their DNS. xxxterm has both DNS and link prefetching disabled by default since these operations can be used to track users.

I've found that some sources, like the OpenCDE source tarballs, compile into a Debian package without a hitch. But upon closer inspection, it seems that only the manpages are in the package, while the required executable files are not.

What should be the best thing to de if something like this happens.

For me I just extracted the resulting .deb from the process, added the required executable in the correct directory order, ad repack them using

A worthy article. I've so far been using checkinstall to create DEB packages. But I would like to be able to automate the process a little more. This is especially useful for those packages not in the Debian repos and which need compiling or building.

DEB packages allows one to maintain control over the files installed in a system. Otherwise with the make install approach you get a spray of files everywhere and it gets tedious to remove/maintain/update them. Some people are still defending the make install approach.

Telemachus wrote:I get my bleeding edge Perl, and Debian can still find its version, just where it expects it. (By the way, if I'm completely wrong, and you can have two debs of one item at the same time, I will gladly eat my words.)

I think that you can have DEBs for both. I've never tried it, but if you were to pass the --prefix=/usr/local argument in the debian/rules file and change the name of the package (e.g. "etruscan-perl") in the debian/control file, then you might be able to have DEBs of both.

I try to install the sid version of qmmp media player under /usr/local/ on my wheezy/stable. I've managed to do it with htop earlier by issuing the --prefix=/usr/local in the Debian/control but the htop package used make tool and the qmmp uses some cmake.

Here is qmmp's Debian Control. There was --prefix=/usr. I changed it to --prefix=/usr/local. The other change which I did was commenting out the lines under "override_dh_install:":

Just don't try to put them into /usr/local. That goes against Debian policy. If you must identify them, give them a customized name. There's nothing that requires them to have a "bpo70+1" as part of the name, it's just convenient.

If you want two versions of something, the standard policy is to make it a different package. For example, I wanted to have both conky-manager 1.2 and 2.2 installed at the same time. I went and patched the /src/makefile and some other files to make the new package "conky-manager2", all files are installed in different directories in /usr, and don't conflict. It's more work, but it's the right way.

Perhaps your problem with CMAKE is that it requires a different syntax to install into /usr/local? Debhelper automatically recognizes cmake and issues the correct prefix command to install into /usr; you should see if it needs something different for /usr/local.