Advanced search
Log In
New Account
Home My Page Project Cloud Code Snippets Project Openings ESbox
Summary Forums Tracker Lists Tasks News SCM Files Wiki

Bugs: Browse | Download .csv

[#4708] Import Project from Debian Repository fails

Please login

2009-10-21 13:33
Submitted By:
Ilja Pyykkonen (ilpyykko)
Assigned To:
Ilja Pyykkonen (ilpyykko)
Import Project from Debian Repository fails

Detailed description
Tested with ESbox build 551 on Ubuntu Linux.

The ESbox fails to import Project from Debian repository if two (or more?) repositories contain package with same name
but different prefix.


Logged in to scratchbox (DIABLO_ARMEL)

Modified (removed deb-src lines) /etc/apt/source.list to

deb diablo/sdk free non-free
deb diablo/tools free non-free
deb file:/home/sboxuser/maemo-sdk-nokia-binaries_4.1.2/ diablo explicit
deb diablo free
deb diablo free non-free

and ensured that there is no other files in sources.list.d

Executed: apt-get update

Restarted ESbox.

From ESbox launched wizard:
 File -> Import -> Esbox -> Project

Selected DIABLO_ARMEL from dropdown and gzip from packages.

No other options changed.

The process fails at Fetching and Importing page with following error

* Extracting source for package gzip to /home/sboxuser/workspace/gzip under DIABLO_ARMEL
dpkg-source: error: cannot open .dsc file /home/sboxuser/workspace/gzip/gzip_1.3.5-10sarge1.dsc: No such file or

* Could not extract the source components
Cause: Did not detect the directory where the sources were extracted

The project directory does not contain gzip_1.3.5-10sarge1.* files, but gzip_1.3.12-1maemo4.* files instead.

[sbox-DIABLO_ARMEL: ~/workspace/gzip] > ls
gzip_1.3.12-1maemo4.diff.gz  gzip_1.3.12-1maemo4.dsc  gzip_1.3.12.orig.tar.gz

The contains
gzip_1.3.5-10sarge1.* files, but the contains
gzip_1.3.12-1maemo1.* files.


Date: 2009-12-11 11:52
Sender: Ilja Pyykkonen

Verified with ESbox build 636 on Ubuntu Linux.
Date: 2009-11-10 11:29
Sender: Ilja Pyykkonen

Fixed in rev 3323, 2009-11-10
Date: 2009-10-22 01:42
Sender: Ed Swartz

Aah, good catch.  I handled something like this once, with a
less complex case (multiple versions available from the same

I think we lose information about the versions because we only
store one entry for any given package.  Thus only the latest
(or last?) version of a package is recorded in

Probably instead of tearing that code apart, we could attach
a stream monitor to the dpkg-source step so we know which version
of archive got downloaded.

(This may still puzzle some users, though... the package selection
page shows a specific version, and the sources may yet be from
a different version.  But this will at least prevent outright

Attached Files:

Name Download
No Files Currently Attached


Field Old Value Date By
ResolutionFixed2009-12-11 11:52ilpyykko
ResolutionNone2009-11-10 11:29ilpyykko
assigned_tonone2009-11-06 10:31ilpyykko
File Added640: command.log2009-10-21 13:34ilpyykko

Terms of Use    Privacy Policy    Contribution Guidelines    Feedback

Powered By GForge Collaborative Development Environment