```
Installing with make install...
========================= Installation results ===========================
test -d /usr/local/bin || /usr/bin/install -c -d /usr/local/bin
test -d /usr/local/include/znc || /usr/bin/install -c -d /usr/local/include/znc
/usr/bin/install: cannot change permissions of `/usr/local/include/znc': No such file or directory
make: *** [install] Error 1
**** Installation failed. Aborting package creation.
Cleaning up...OK
Bye.
```
My distro is Ubuntu 11.10 and I used `./configure --enable-extra` to configure (successfully). Checkinstall reports that it is version 1.6.2.
Edit:
I tried building the latest git version (b450fde4f6) and checkinstall still fails with the same error.
## <bountysource-plugin>
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3421-checkinstall-fails-to-build-a-deb-with-0-204-and-later?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
</bountysource-plugin>
<!-- github-sync-id:3183778 -->
This looks more like a checkinstall problem. My man page for "install" says:
-d, --directory
treat all arguments as directory names; create all components of the specified directories
So "install -d /usr/local/include/znc" should not only try to create /usr/local/include/znc, but also /usr/local/include (I am assuming here it fails because /usr/local/include/ doesnt exist).
This looks more like a checkinstall problem. My man page for "install" says:
```
-d, --directory
treat all arguments as directory names; create all components of the specified directories
```
So "install -d /usr/local/include/znc" should not only try to create /usr/local/include/znc, but also /usr/local/include (I am assuming here it fails because /usr/local/include/ doesnt exist).
<!-- github-comment-id:3919620 -->
Running sudo checkinstall --fstrans=no works around this issue, though when uninstalling the package with apt, there are a bunch of warnings thrown that aren't usually there (IIRC):
The following packages will be REMOVED:
znc{p}
0 packages upgraded, 0 newly installed, 1 to remove and 55 not upgraded.
Need to get 0 B of archives. After unpacking 5,157 kB will be freed.
Do you want to continue? [Y/n/?]
(Reading database ... 255469 files and directories currently installed.)
Removing znc ...
dpkg: warning: while removing znc, directory '/usr/local/bin' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/share/man/man1' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/share/man' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/share' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/lib' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/include' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local' not empty so not removed.
Processing triggers for man-db ...
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB
localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB
Total disk space freed by localepurge: 0 KiB
Though those seem pretty innocuous. I'll close the issue for now.
Running `sudo checkinstall --fstrans=no` works around this issue, though when uninstalling the package with apt, there are a bunch of warnings thrown that aren't usually there (IIRC):
```
The following packages will be REMOVED:
znc{p}
0 packages upgraded, 0 newly installed, 1 to remove and 55 not upgraded.
Need to get 0 B of archives. After unpacking 5,157 kB will be freed.
Do you want to continue? [Y/n/?]
(Reading database ... 255469 files and directories currently installed.)
Removing znc ...
dpkg: warning: while removing znc, directory '/usr/local/bin' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/share/man/man1' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/share/man' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/share' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/lib' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local/include' not empty so not removed.
dpkg: warning: while removing znc, directory '/usr/local' not empty so not removed.
Processing triggers for man-db ...
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB
localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB
Total disk space freed by localepurge: 0 KiB
```
Though those seem pretty innocuous. I'll close the issue for now.
<!-- github-comment-id:3920053 -->
Could someone create a Makefile which just runs test -d /usr/local/include/znc || /usr/bin/install -c -d /usr/local/include/znc on make install, run that through checkinstall, notice that this is enough to break things and finally report this bug to the checkinstall devs so that they can fix their stuff?
If the above isn't enough to reproduce the problem, feel free to experiment with znc's Makefile and remove stuff until you have a minimal example that reproduce the problem. Then this can be reported to the checkinstall guys as well.
Plan C would be: Tell us what we are doing wrong.
(But since things work as long as you don't use checkinstall, I have a hard time believing that this is our fault).
Could someone create a Makefile which just runs `test -d /usr/local/include/znc || /usr/bin/install -c -d /usr/local/include/znc` on `make install`, run that through checkinstall, notice that this is enough to break things and finally report this bug to the checkinstall devs so that they can fix their stuff?
If the above isn't enough to reproduce the problem, feel free to experiment with znc's Makefile and remove stuff until you have a minimal example that reproduce the problem. Then this can be reported to the checkinstall guys as well.
Plan C would be: Tell us what we are doing wrong.
(But since things work as long as you don't use checkinstall, I have a hard time believing that this is our fault).
<!-- github-comment-id:53185424 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
My distro is Ubuntu 11.10 and I used
./configure --enable-extrato configure (successfully). Checkinstall reports that it is version 1.6.2.Edit:
I tried building the latest git version (
b450fde4f6) and checkinstall still fails with the same error.Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
This looks more like a checkinstall problem. My man page for "install" says:
So "install -d /usr/local/include/znc" should not only try to create /usr/local/include/znc, but also /usr/local/include (I am assuming here it fails because /usr/local/include/ doesnt exist).
Running
sudo checkinstall --fstrans=noworks around this issue, though when uninstalling the package with apt, there are a bunch of warnings thrown that aren't usually there (IIRC):Though those seem pretty innocuous. I'll close the issue for now.
I am having this issue as well with 1.2.
Debian 7, ZNC 1.4, just the same. This should be fixed, it should work by default.
Could someone create a Makefile which just runs
test -d /usr/local/include/znc || /usr/bin/install -c -d /usr/local/include/znconmake install, run that through checkinstall, notice that this is enough to break things and finally report this bug to the checkinstall devs so that they can fix their stuff?If the above isn't enough to reproduce the problem, feel free to experiment with znc's Makefile and remove stuff until you have a minimal example that reproduce the problem. Then this can be reported to the checkinstall guys as well.
Plan C would be: Tell us what we are doing wrong.
(But since things work as long as you don't use checkinstall, I have a hard time believing that this is our fault).