DEFECT in checkinstall: abort due to missing file or directory

[Achim Spangler]

Binary package hint: checkinstall

I get the following debug information and abort, when I try to create a new package with:

"checkinstall unsermake install"
#####
========================= Installation results ===========================
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/usr/lib/python2.4/site-packages/unsermake/__init__.py", line 1362, in ?
    main()
  File "/usr/lib/python2.4/site-packages/unsermake/__init__.py", line 1047, in main
    files = os.listdir(sourcedir)
OSError: [Errno 2] No such file or directory: '/usr/lib/python2.4/site-packages/unsermake'

**** Installation failed. Aborting package creation.

Cleaning up...OK

Bye.

#####
This worked with the OLD checkinstall version in Dapper (the newest checkinstall version for Dapper stopped also correct work).
The strange thing:
The indicated directory EXISTS. But somehow the program doesn't find it.

My system is a fresh Edgy install with pure *.deb based system setup.
Checkinstall is version: 1.6.0-2ubuntu1 from universe/admin

Is it possible, that I'm missing any python helper package? Or should I reconfigure some packages or define suitable alternatives? Maybe it works only with some special python versions?

This happens in all following call scenarios:
+ KDE _user_ session with "sudo checkinstall unsermake install"
+ KDE konsole with calling "su" before --> calling checkinstall in super user mode with "checkinstall unsermake install"
+ console mode (no X11) with direct login as "root" --> calling directly "checkinstall unsermake install"
I did this to avoid any problems that might be caused by old .dot files from my old $HOME which is containing config files from very old OS versions.
But the "/root" account is fresh, so that the problem shouldn't be caused by old .dot-files.

I will have to switch back to the last working checkinstall version 1.5.3 right now.

Thanks,
Achim

[Achim Spangler (achim-spangler)]

Am I the only one who is suffering this problem?
Was my description not exact enough?

The combination:
checkinstall unsermake install

is the only way that I know to get packages from self compiled KDE-Programs, when testing SVN states (i.e. no prevu or src-package usable for other package build strategy).
--> this is a severe problem for a package from Universe package list

Thanks,
Achim

[Achim Spangler (achim-spangler)]

Is checkinstall so unimportant, that nobody is reacting here?
Or should I look for a KUBUNTU Bug-Tracking system, as my problem happens only with a KDE specific install call?

Or are any bugs in universe area ignored?

I do NOT get "checkinstall unsermake install" - the _standard_ install procedure for KDE program - to work on my Kubuntu Edgy box!!

Thanks for anybody who can help here,
Achim

[tokj (tokj-deactivatedaccount)]

Hello and thank you for your report

Sorry, but this problem wasn't reproducible on my system. This issue occurs also if you're using only "sudo checkinstall" to make the deb package?

Regards

[Achim Spangler (achim-spangler)]

This problem happens only if I want to create a DEB package from a KDE application, where I have to call "unsermake install" or "checkinstall unsermake install" to install the KDE program.

So please try to install a KDE package e.g. from a SVN checkout (e.g. the kdevelop 3.4 trunk from svn://anonsvn.kde.org/home/kde/branches/kdevelop/3.4) with the standard KDE program install method "unsermake install".

If you can create this way valid DEB packages from KDE program sources without this error, the set of installed python packages would be very interesting for me. I didn't explicitly install any special python packages, that weren't installed by any dependency from another package.

Thanks,
Achim

[Achim Spangler (achim-spangler)]

I got a usable workaround for the reported problem from the checkinstall email list:
<<start-cite from the email list: <email address hidden>
> Hello,
> I reported one month ago about a problem with the call of
> "checkinstall unsermake install" - the recommended way to install KDE
> programs from source.
>
> Am I the only one who suffers this problem?
> Does this command work in other Linux distributions than Kubuntu Edgy?

This seems to fail mostly everywere, and appears to be a bug in the
filesystrem translation code. If you pass --fstrans=no to checkinstall, it
should work.
/end-cite>>

I tried this with the checkinstall version that is installed by edgy - and it WORKS! ;-)

Maybe this workaround could be spread in the ubuntu community, or some developers might help the checkinstall developers to get the 2.0 version finished, which is said to be a big much more modular rewrite.

Thanks,
Achim

[Florian Rasche (florian-rasche)]

I can confirm this Problem in Ubuntu Feisty checkinstall version 1.6.1
This very simple makefile-code tries to copy a dummy config file to /etc/ci_test :

install:
 mkdir -p /etc/ci_test
 cp config /etc/ci_test

checkinstall fails on this makefile if not using the above mentioned workaround.

Greetings
Florian

[Daniel Hahler (blueyed)]

I can confirm both problems here. See the official mail about it: http://checkinstall.izto.org/cklist/msg00319.html

[Bernhard Schuster (drahnr)]

This is still present in hardy...

[andrew.46 (andrew.46-deactivatedaccount)]

And still in Intrepid ...

[andrew.46 (andrew.46-deactivatedaccount)]

Hi,

Can I suggest an easier solution that could be rolled out from the repository? Checkinstall has a configuration file /etc/checkinstallrc. If this could be set with:

# Are we going to use filesystem translation?
TRANSLATE=0

This would get around the well known problem with checkinstall as acknowledged on their website:

http://www.asic-linux.com.mx/~izto/checkinstall/

and further discussed here:

http://checkinstall.izto.org/cklist/msg00319.html

  Andrew

[Motin (motin)]

Why on earth hasn't this been fixed in neither Feisty, Hardy nor Intrepid?

It will at LEAST be fixed in Jaunty, right?

[Daniel Hahler (blueyed)]

This has been fixed in checkinstall 1.6.1-8 (from Debian), by changing the TRANSLATE default as suggested in previous comments above.
Marking "Fix released", since Jaunty has 1.6.1-8 now.
IMHO it would make sense to have a SRU (StableReleaseUpdate) for this, but somebody else would have to get the ACK and provide the debdiffs (see https://wiki.ubuntu.com/SRU).

[hackel (hackel)]

I don't think this can be called "fixed" as turning filesystem translation off is really not a viable option. With it off, it's impossible to create packages that install to /usr without root privileges, and I certainly do not want to run checkinstall as root! According to the checkinstall website, the git repository contains code to fix this bug, so perhaps Ubuntu should upgrade to a git version of checkinstall, if it's stable enough. But until then, this bug should be re-opened!

[Alexander Kabakow (alexzak)]

ubuntu 10.10 check install affected

[Andreas Noteng (andreas-noteng)]

Are you sure you are experiencing the exact same bug? If not, please file a separate report using "ubuntu-bug checkinstall".

[Manjul Apratim (manzdagratiano)]

I can confirm this on my Maverick installation - the system is up-to-date. It is the exact same bug. The file translation options in /etc/checkinstallrc are set to 1 by default. The system had a clean install of Lucid when it was released and upgraded to the Maverick RC, so the file could not have been present from prior versions. I did not encounter this under Lucid.

[Zane (zanetu)]

Achim Spangler's workaround works for me on Kubuntu 10.10 (amd64). Didn't encounter this bug on Kubuntu 9.10.

[Νίκος Αλεξανδρής (nikos.alexandris)]

Problem confirmed under Kubuntu 10.10. I don't remember (either) having this problem under 10.04, what has been changed? How safe is it to turn "file system translation" off?

[Fareed Qureshi (manticore7)]

I encountered the same problem when installing LyX 1.6.8 today on Ubuntu 10.10. Previous installations of previous versions of LyX on older Ubuntu versions went fine.

Running checkinstall with --fstrans=0 obviated the problem, though perhaps that is not a permanent solution.

[Doug McMahon (mc3man)]

If the debian maintainer was unable to make fstrans work
https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/599163
then just go ahead and make the 1 word edit in checkinstallrc and be done with it.
The trains already left the station for maverick so do in natty.

[Jordan Farrell (feralbytes)]

Confirmed on Ubuntu Maverick 10.10 AMD64. I am going to edit the easy compile wiki to reflect that users may need to use "--fstrans=0" in-case of installation failure.

[McEye (spam-mceye)]

Still the same problem in Natty. At least when intalling Ruby from source.

[jpfle (jpfle)]

Still a problem with Ubuntu 11.10 Beta 1.

[Clint Byrum (clint-fewbar)]

unsubscribing ubuntu-sru .. please re-subscribe only when the bug has a full SRU justification (and, preferably, after it is definitely fixed in the dev release).

[Stephen Brandt (ztefn)]

Still a problem in Ubuntu 11.10 Beta 2. The --fstrans=0 workaround did the job for me.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Turn off file system translation by default" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Marc Deslauriers (mdeslaur)]

Could someone please open an upstream Debian bug about this issue and link the bug here? Thanks.

[Andreas Noteng (andreas-noteng)]

Afaik the bug is not present in Debian. If you've seen otherwise you could file a bug yourself.

Sent from my android device.

-----Original Message-----
From: Marc Deslauriers <email address hidden>
To: <email address hidden>
Sent: 6, 21 10 2011 16:01
Subject: [Bug 78455] Re: DEFECT in checkinstall: abort due to missing file or directory

Could someone please open an upstream Debian bug about this issue and
link the bug here? Thanks.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/78455

Title:
  DEFECT in checkinstall: abort due to missing file or directory

Status in “checkinstall” package in Ubuntu:
  Triaged
Status in “checkinstall” source package in Maverick:
  Confirmed

Bug description:
  Binary package hint: checkinstall

  I get the following debug information and abort, when I try to create
  a new package with:

  "checkinstall unsermake install"
  #####
  ========================= Installation results ===========================
  Traceback (most recent call last):
    File "<string>", line 1, in ?
    File "/usr/lib/python2.4/site-packages/unsermake/__init__.py", line 1362, in ?
      main()
    File "/usr/lib/python2.4/site-packages/unsermake/__init__.py", line 1047, in main
      files = os.listdir(sourcedir)
  OSError: [Errno 2] No such file or directory: '/usr/lib/python2.4/site-packages/unsermake'

  **** Installation failed. Aborting package creation.

  Cleaning up...OK

  Bye.

  #####
  This worked with the OLD checkinstall version in Dapper (the newest checkinstall version for Dapper stopped also correct work).
  The strange thing:
  The indicated directory EXISTS. But somehow the program doesn't find it.

  My system is a fresh Edgy install with pure *.deb based system setup.
  Checkinstall is version: 1.6.0-2ubuntu1 from universe/admin

  Is it possible, that I'm missing any python helper package? Or should
  I reconfigure some packages or define suitable alternatives? Maybe it
  works only with some special python versions?

  This happens in all following call scenarios:
  + KDE _user_ session with "sudo checkinstall unsermake install"
  + KDE konsole with calling "su" before --> calling checkinstall in super user mode with "checkinstall unsermake install"
  + console mode (no X11) with direct login as "root" --> calling directly "checkinstall unsermake install"
  I did this to avoid any problems that might be caused by old .dot files from my old $HOME which is containing config files from very old OS versions.
  But the "/root" account is fresh, so that the problem shouldn't be caused by old .dot-files.

  I will have to switch back to the last working checkinstall version
  1.5.3 right now.

  Thanks,
  Achim

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/78455/+subscriptions

[Clint Byrum (clint-fewbar)]

Its unclear what the solution to this bug is. The fstrans workaround seems to introduce regressions, and upstream's git repo seems inaccessible so its hard to say if its being addressed there.

Please Andreas, if you have a clear path ahead for sponsors to take, re-subscribe ubuntu-sponsors. Otherwise I don't see what we can do.

Unsubscribing ubuntu-sponsors

Also changing status from "Triaged" to "Confirmed" .. this appears to be an upstream problem, and so needs to be reported upstream (in Debian if applicable, and in the upstream bug tracker) before it can be considered Triaged.

[Daniel Hahler (blueyed)]

OT: @clint-fewbar: why would it go from Triaged to Confirmed, only because it's an upstream issue ("Confirmed" => confirmed by others, "Triaged" => triaged, ready to be worked on by a developer). Please revert it.

[Andreas Noteng (andreas-noteng)]

Request to include workaround in Precise added as bug #975140

[Andreas Noteng (andreas-noteng)]

Workaround uploaded to Precise.
I still won't consider this bug closed though..

[Launchpad Janitor (janitor)]

This bug was fixed in the package checkinstall - 1.6.2-3ubuntu1

---------------
checkinstall (1.6.2-3ubuntu1) precise; urgency=low

  * Sync from Debian (LP: #975140)
  * 0002-Change-default-configuration.patch: Disable file system translation by
    default (LP: #78455)
  * debian/copyright: fixed GPL-2+ licence name
 -- Andreas Noteng <email address hidden> Fri, 06 Apr 2012 15:16:05 +0200

[Andreas Noteng (andreas-noteng)]

Reopening because the bug has only been worked around, fil system translation is still broken.

[Dirk F (fieldhouse)]

As the upstream bug is still unfixed and there's no Debian or Ubuntu fix (other than not using the important fstrans=yes option), this is unsurprisingly still a problem in Trusty and no doubt later versions through to Yakkety.

Simple test:

# checkinstall -D --fstrans=yes mkdir -p /usr/doc/test
...
Installing with mkdir -p /usr/doc/test...

========================= Installation results ===========================
mkdir: cannot create directory ‘/usr/doc’: No such file or directory

**** Installation failed. Aborting package creation.

Cleaning up...OK

Bye.

[Dirk F (fieldhouse)]

And the root cause, presumably in the hook library /usr/lib/checkinstall[64]/installwatch.so, pre-loaded in the installwatch script before running the install command passed into it:

# installwatch -t mkdir -p /usr/doc/test

INFO : Using a default root directory : /tmp/tmp.INhvkPHuIR

mkdir: cannot create directory ‘/usr/doc’: No such file or directory

[Hachmann (marenhachmann)]

Apparently, this bug is *still* present as of.... Feb 11, 2022, in Ubuntu 22.04 .

A fix has already been suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717778

Could this be patched, please? It's really sad to not be able to use checkinstall for what it is meant for - a quick way to make one's own packages.