DEFECT in checkinstall: abort due to missing file or directory

Bug #78455 reported by Achim Spangler
146
This bug affects 32 people
Affects Status Importance Assigned to Milestone
CheckInstall
Confirmed
Medium
checkinstall (Ubuntu)
Triaged
Medium
Unassigned

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

Tags: patch
Revision history for this message
Achim Spangler (achim-spangler) wrote :

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

Revision history for this message
Achim Spangler (achim-spangler) wrote :

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

Revision history for this message
tokj (tokj-deactivatedaccount) wrote :

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

Changed in checkinstall:
status: Unconfirmed → Needs Info
Revision history for this message
Achim Spangler (achim-spangler) wrote :

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

Revision history for this message
Achim Spangler (achim-spangler) wrote : This is a known problem of checkinstall with usable workaround

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

Revision history for this message
Florian Rasche (florian-rasche) wrote : Re: confirm with a very simple Makefile

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

Revision history for this message
Daniel Hahler (blueyed) wrote :

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

Changed in checkinstall:
assignee: nobody → blueyed
status: Incomplete → Confirmed
assignee: blueyed → nobody
Revision history for this message
Bernhard Schuster (drahnr) wrote :

This is still present in hardy...

Daniel Hahler (blueyed)
Changed in checkinstall:
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
andrew.46 (andrew.46-deactivatedaccount) wrote :

And still in Intrepid ...

Revision history for this message
andrew.46 (andrew.46-deactivatedaccount) wrote :

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

Revision history for this message
Motin (motin) wrote :

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

It will at LEAST be fixed in Jaunty, right?

Revision history for this message
Daniel Hahler (blueyed) wrote :

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).

Changed in checkinstall:
status: Triaged → Fix Released
Revision history for this message
hackel (hackel) wrote :

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!

Revision history for this message
Alexander Kabakow (alexzak) wrote :

ubuntu 10.10 check install affected

Revision history for this message
Andreas Noteng (andreas-noteng) wrote :

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

Revision history for this message
Manjul Apratim (manzdagratiano) wrote :

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.

Changed in checkinstall (Ubuntu):
milestone: none → maverick-updates
status: Fix Released → Triaged
Revision history for this message
Zane (zanetu) wrote :

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

Revision history for this message
Νίκος Αλεξανδρής (nikos.alexandris) wrote :

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?

Revision history for this message
Andreas Noteng (andreas-noteng) wrote :
Revision history for this message
Fareed Qureshi (manticore7) wrote :

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.

Revision history for this message
Doug McMahon (mc3man) wrote :

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.

Revision history for this message
Jordan Farrell (feralbytes) wrote :

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.

Revision history for this message
McEye (spam-mceye) wrote :

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

Revision history for this message
jpfle (jpfle) wrote :

Still a problem with Ubuntu 11.10 Beta 1.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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).

Changed in checkinstall (Ubuntu):
milestone: maverick-updates → none
Revision history for this message
Stephen Brandt (ztefn) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in checkinstall (Ubuntu Maverick):
status: New → Confirmed
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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.]

tags: added: patch
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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

Revision history for this message
Andreas Noteng (andreas-noteng) wrote : Re: [Bug 78455] Re: DEFECT in checkinstall: abort due to missing file or directory

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

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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.

Changed in checkinstall (Ubuntu):
status: Triaged → Confirmed
Revision history for this message
Daniel Hahler (blueyed) wrote :

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.

Revision history for this message
Andreas Noteng (andreas-noteng) wrote :

Request to include workaround in Precise added as bug #975140

Revision history for this message
Andreas Noteng (andreas-noteng) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in checkinstall (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Andreas Noteng (andreas-noteng) wrote :

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

Changed in checkinstall (Ubuntu):
status: Fix Released → Triaged
Changed in checkinstall:
importance: Unknown → Medium
status: Unknown → Confirmed
no longer affects: checkinstall (Ubuntu Maverick)
Revision history for this message
Dirk F (fieldhouse) wrote :

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.

Revision history for this message
Dirk F (fieldhouse) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.