sorry i have no idea thanks
Printable View
sorry i have no idea thanks
Well, thanks! My pleasure; this is the kind cooperation that I'm so fond of: One person works out a solution to a problem, and that's the inspiration that another person needs to start looking for a solution to his problem, etc. And in the end, everyone benefits.Quote:
Originally Posted by BobSongs
That's the wonderful concept of "Standing on the shoulders of giants standing on the shoulders of giants standing on the shoulders of giants standing..."
The Goal.
If you want to set up a local Ubuntu mirror, you can download its contents from an online repository—as I documented in an earlier post in this thread. You will then, however, have to download a huge amount of data—which may be impractical to you.
To bypass the “Big Download,” you may prefer to obtain a set of Ubuntu Repository DVDs, and use these to initialise your local mirror instead. Once your local mirror is up and running, you can then keep it up-to-date by periodically rerunning the “debmirror” command.
Purchasing Ubuntu Repository DVDs.
In the initial post of this thread, BobSongs listed some of the vendors from which you can purchase a set of Ubuntu Repository DVDs.
To order your copy, first decide which Ubuntu release you want—e.g., Ubuntu 9.04 (the “Jaunty Jackalope”). The vendor may append a second set of numbers to the release, to identify when the DVD contents were brought up-to-date—e.g., “Ubuntu 9.04-9.06” identifies the Ubuntu 9.04 release, brought up-to-date as of June, 2009.
Also, decide for which CPU architecture you want to obtain the repository DVDs: i386 (i.e., the 32-bit version), or amd64 (i.e., the 64-bit version)—or, perhaps, both.
Note:
Before you order your set of discs, ensure that your computer meets the system requirements specified by the vendor—you may, for example, need a DVD drive that can read Dual Layer DVD±R media.
Once you have placed your order, you will simply have to wait until the discs are delivered. (In my case, the vendor announced that it would take some 10 working days for my order to arrive, but I actually received it after only five or six working days... Nice!)
Loading your Local Mirror from the DVDs.
Once you receive the set of discs, you can set up your local mirror, and load it from the discs. First, you will need to create a directory for your mirror—e.g., “~/UbuntuRepos”:
Next, insert the first DVD into your drive, and wait until your system mounts it (and, most likely, opens a file browser window for it). The DVD should contain two directories (or “folders,” in GUI-Speak):Code:mkdir ~/UbuntuRepos
- “dists”—which can help you identify the values that you will have to specify for the “--dist” and “--section” parameters on the “debmirror” command, later on;
- “pool”—which contains the actual software packages that you will have to copy into your local mirror.
To list the contents of the “dists” directory, you can execute the following command:
Code:ls /media/cdrom/dists
Note:
If your computer has more than one CD and/or DVD drive (or if the system doesn’t make the “cdrom” synonym available for some reason), then you may have to replace the “cdrom” device designation with some other name; you can identify the appropriate device name on the title bar of the file browser window that displays the DVD contents.
Alternatively, you can, of course, open the “dists” folder from the graphical desktop environment.
As an example, the “dists” directory may contain the following four subdirectories:
- jaunty
- jaunty-backports
- jaunty-security
- jaunty-updates
These are the values that you will have to use for the “--dist” parameter when you run the “debmirror” command—so, e.g.:
Each of these subdirectories will contain another set of subdirectories—e.g.:Code:--dist=jaunty,jaunty-backports,jaunty-security,jaunty-updates
- main
- multiverse
- restricted
- universe
From this list, you can construct the “--section” parameter for the “debmirror” command—e.g.:
Finally, in each of these subdirectories, you will find yet another subdirectory, which identifies the CPU architecture to which the disc set applies—either, “binary-i386” or “binary-amd64,” for the 32-bit or the 64-bit architecture, respectively. This directory corresponds to the “--arch” parameter for the “debmirror” command:Code:--section=main,multiverse,restricted,universe
or:Code:--arch=i386
or even (if you load the disc sets for both architectures into your local mirror):Code:--arch=amd64
Code:--arch=i386,amd64
Note:
You will not, at this point, have to actually use these parameter values. Just note them down, so you have them available when you need them, later on.
Now, run the following command to copy the contents of the “pool” directory into your local mirror:
Afterwards, you will have to update the permission flags on the directories and files that you copied to your harddisk; otherwise, they will remain read-only, and you will not be able to further update your local mirror (e.g., to copy the contents of the remaining discs into it). Just run the following command:Code:cp --recursive --verbose /media/cdrom/pool ~/UbuntuRepos
Next, insert each of the remaining DVDs in turn, and repeat the copy and “chmod” commands for each of them:Code:chmod --recursive --verbose u+w ~/UbuntuRepos/pool
Code:cp --recursive --verbose /media/cdrom/pool ~/UbuntuRepos
chmod --recursive --verbose u+w ~/UbuntuRepos/pool
Note:
You may want to verify if the “dists” directory on each of the DVDs contains any subdirectories that aren’t present on any earlier disc. If there are any, then you should add them to the “--dist” parameter for the “debmirror” command, as discussed above.
Theoretically, you could even encounter new subdirectories that should be added to the “--section” parameter for the “debmirror” command—though, in practice, I believe that won’t be very likely to happen.
Adding Packages for a Second CPU Architecture to your Local Mirror.
After you copy all packages for one CPU architecture (e.g., “i386”) to your local mirror, you may want to add the packages for the other architecture (e.g., “amd64”) to it as well. To this end, you can just repeat the copy and “chmod” commands for each of the DVDs for the second architecture. Some packages are common to both architectures, however; you may, therefore, want to avoid recopying these common packages, to help speed up this operation a little. In other words, you may want to add the “--update” option to the copy command, to ensure that only new (or newer versions of existing) files will be copied over:
Code:cp --recursive --update --verbose /media/cdrom/pool ~/UbuntuRepos
chmod --recursive --verbose u+w ~/UbuntuRepos/pool
Note:
Some DVD drives may become somewhat unstable, and report read errors when they are heavily used for relatively long periods of time. If you experience DVD read errors on, e.g., the third or fourth DVD that you are trying to copy in a single session, you may want to power down your computer for a few hours, and then retry. Only if you then keep getting DVD read errors should you assume that there is a problem with the disc.
Also, DVD read errors are almost guaranteed to occur if you perform these steps on a battery-powered laptop when the battery is running low.
Creating the Keyring for your Local Mirror.
As I explained in my earlier post, you will have to create a particular keyring, to allow “debmirror” to validate the integrity of your local mirror. Just run the following command (if you haven’t already done so on an earlier occasion):
OPTIONAL: Taking “debmirror” for a Test Drive.Code:gpg --no-default-keyring --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --export \
| gpg --no-default-keyring --keyring trustedkeys.gpg --import
You are now ready to run “debmirror” for the first time, to load the control files that will allow you to install software packages from your local mirror. In addition, “debmirror” will download any updates that may have become available since the DVDs were produced, and it will delete any obsoleted packages.
Since “debmirror” rather aggressively deletes from your local mirror any files that are not present in the online mirror with which it synchronises, large portions of your local mirror may get zapped if you make an error in any of its arguments. Therefore, you may prefer to take it for a test drive before you actually let it manipulate your local mirror. To request such a test drive, you can use the “--dry-run” parameter on the “debmirror” command, as follows:
where:Code:debmirror --dry-run --nosource --md5sums --passive \
--host=online-repository-host --root=ubuntu --method=http --progress \
--dist=dist-list --section=section-list --arch=arch-list \
~/UbuntuRepos
- “online-repository-host” represents the online mirror with which you want to synchronise your local mirror—e.g., the generic “archive.ubuntu.com” or your national mirror (which, in my case, would be “be.archive.ubuntu.com”).
- “dist-list” represents the “--dist” value, as discussed above—e.g.:
Code:jaunty,jaunty-backports,jaunty-security,jaunty-updates
- “section-list” represents the “--section” value, also discussed above—e.g.:
Code:main,multiverse,restricted,universe
- “arch-list” represents the CPU architecture(s) to which your local mirror applies—e.g., “i386” or “amd64” (or both: “i386,amd64”).
The actual “debmirror” command, with all values substituted into it, may, thus, look like this:
As part of its output, the “debmirror” command will list the updated packages that have become available, and that would be loaded into your local mirror if this were a real run—e.g.:Code:debmirror --dry-run --nosource --md5sums --passive \
--host=archive.ubuntu.com --root=ubuntu --method=http --progress \
--dist=jaunty,jaunty-backports,jaunty-security,jaunty-updates \
--section=main,multiverse,restricted,universe --arch=i386,amd64 \
~/UbuntuRepos
Furthermore, it will list the files that it considers obsoleted, and that it would delete—e.g.:Code:Getting: pool/main/f/firefox-3.0/abrowser-3.0-branding_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_amd64.deb... ok
Getting: pool/main/f/firefox-3.0/abrowser-3.0-branding_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_i386.deb... ok
Getting: pool/main/f/firefox-3.0/abrowser_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_all.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-3.0-branding_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_amd64.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-3.0-branding_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_i386.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-3.0-dev_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_amd64.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-3.0-dev_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_i386.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-3.0-gnome-support_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_amd64.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-3.0-gnome-support_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_i386.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-3.0_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_amd64.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-3.0_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_i386.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-dev_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_all.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-gnome-support_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_all.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-granparadiso-dev_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_all.deb... ok
Getting: pool/main/f/firefox-3.0/firefox-trunk-dev_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_all.deb... ok
Getting: pool/main/f/firefox-3.0/firefox_3.0.11+build2+nobinonly-0ubuntu0.9.04.1_all.deb... ok
If, at this point, you find that “debmirror” wants to remove whole subdirectories from your local mirror, then you should review the parameter values that you supplied, and correct them as required.Code:deleting pool/main/f/firefox-3.0/firefox_3.0.10+nobinonly-0ubuntu0.9.04.1_all.deb
deleting pool/main/f/firefox-3.0/firefox-3.0-branding_3.0.10+nobinonly-0ubuntu0.9.04.1_i386.deb
deleting pool/main/f/firefox-3.0/firefox-3.0-gnome-support_3.0.10+nobinonly-0ubuntu0.9.04.1_i386.deb
deleting pool/main/f/firefox-3.0/firefox-3.0-gnome-support_3.0.10+nobinonly-0ubuntu0.9.04.1_amd64.deb
deleting pool/main/f/firefox-3.0/firefox-gnome-support_3.0.10+nobinonly-0ubuntu0.9.04.1_all.deb
deleting pool/main/f/firefox-3.0/firefox-trunk-dev_3.0.10+nobinonly-0ubuntu0.9.04.1_all.deb
deleting pool/main/f/firefox-3.0/firefox-3.0_3.0.10+nobinonly-0ubuntu0.9.04.1_amd64.deb
deleting pool/main/f/firefox-3.0/firefox-3.0-dev_3.0.10+nobinonly-0ubuntu0.9.04.1_amd64.deb
deleting pool/main/f/firefox-3.0/abrowser_3.0.10+nobinonly-0ubuntu0.9.04.1_all.deb
deleting pool/main/f/firefox-3.0/abrowser-3.0-branding_3.0.10+nobinonly-0ubuntu0.9.04.1_i386.deb
deleting pool/main/f/firefox-3.0/firefox-3.0_3.0.10+nobinonly-0ubuntu0.9.04.1_i386.deb
deleting pool/main/f/firefox-3.0/firefox-3.0-branding_3.0.10+nobinonly-0ubuntu0.9.04.1_amd64.deb
deleting pool/main/f/firefox-3.0/firefox-dev_3.0.10+nobinonly-0ubuntu0.9.04.1_all.deb
deleting pool/main/f/firefox-3.0/abrowser-3.0-branding_3.0.10+nobinonly-0ubuntu0.9.04.1_amd64.deb
deleting pool/main/f/firefox-3.0/firefox-granparadiso-dev_3.0.10+nobinonly-0ubuntu0.9.04.1_all.deb
deleting pool/main/f/firefox-3.0/firefox-3.0-dev_3.0.10+nobinonly-0ubuntu0.9.04.1_i386.deb
You can repeat the “debmirror” test run as often as you want, until you are satisfied with the results.
Running “debmirror” for Real.
When you’re ready to let “debmirror” actually bring your local mirror up-to-date, just run the command without the “--dry-run” option, leaving all other parameters unchanged:
The following is an example of an actual “debmirror” command, with all values substituted into it:Code:debmirror --nosource --md5sums --passive \
--host=online-repository-host --root=ubuntu --method=http --progress \
--dist=dist-list --section=section-list --arch=arch-list \
~/UbuntuRepos
The output from the “debmirror” command will be mostly identical to that of the test run; this time, however, it will reallly perform the operations that it lists. As a result, your local mirror will have been properly set up and brought up-to-date once the command completes.Code:debmirror --nosource --md5sums --passive \
--host=archive.ubuntu.com --root=ubuntu --method=http --progress \
--dist=jaunty,jaunty-backports,jaunty-security,jaunty-updates \
--section=main,multiverse,restricted,universe --arch=i386,amd64 \
~/UbuntuRepos
Updating your APT Sources.
With the necessary infrastructure in place, it is now time to add your local mirror to your “/etc/apt/sources.list” file, to make it known to the APT system. For each of the values that you listed in the “--dist” parameter on the “debmirror” command, add a line of the following form to the top of the file:
As an example, if your username is “luvr,” and with the “--dist” and “--section” parameter values as above, these lines will look as follows:Code:deb file:///home/username/UbuntuRepos/ distname section-list
Code:deb file:///home/luvr/UbuntuRepos/ jaunty main,multiverse,restricted,universe
deb file:///home/luvr/UbuntuRepos/ jaunty-backports main,multiverse,restricted,universe
deb file:///home/luvr/UbuntuRepos/ jaunty-security main,multiverse,restricted,universe
deb file:///home/luvr/UbuntuRepos/ jaunty-updates main,multiverse,restricted,universe
Note:
Depending on your needs and preferences, you may want to leave out the “jaunty-backports” line. Backports are updates that were actually developed for later Ubuntu releases, and that were subsequently made available for the current version, albeit without any form of support.
Note:
Remember that you will need root privileges in order to edit the “/etc/apt/sources.list” file. For example, if you want to use the “gedit” text editor, you will have to run the following command:
Alternatively, you can start the editor from the GNOME desktop by pressing <Alt>-<F2> and running the following command line:Code:sudo gedit /etc/apt/sources.list
Code:gksudo gedit /etc/apt/sources.list
Next, update your local package indexes:
Keeping your Local Mirror Up-To-Date.Code:sudo apt-get update
To keep your local mirror up-to-date, you will periodically have to rerun the “debmirror” command to resynchronise your mirror with the online repository, and subsequently update your local package indexes again—e.g.:
Code:debmirror --nosource --md5sums --passive \
--host=archive.ubuntu.com --root=ubuntu --method=http --progress \
--dist=jaunty,jaunty-backports,jaunty-security,jaunty-updates \
--section=main,multiverse,restricted,universe --arch=i386,amd64 \
~/UbuntuRepos
sudo apt-get update
Simply art!
Added to my tutorial.
:D
The Problem.
I’m trying to set up a local mirror for the Canonical “Partner” repository—similar to the local Ubuntu mirror that I documented in an earlier post in this thread.
First, I create a directory in which I will download the repository files:
Next, I perform a “debmirror” test run (using the “--dry-run” option):Code:mkdir ~/PartnerRepos
However, instead of running to completion, “debmirror” complains about the following error:Code:debmirror --dry-run --md5sums --passive --host=archive.canonical.com --root=ubuntu \
--method=http --progress --dist=jaunty --section=partner --arch=i386 \
~/PartnerRepos
Apparently, “debmirror” expects the online repository to provide “Packages.bz2” and “Sources.bz2” files—which seem to be missing.Code:[ 60%] Getting: dists/jaunty/partner/binary-i386/Packages.bz2...
dists/jaunty/partner/binary-i386/Packages.bz2 failed 404 Not Found
[ 60%] Getting: dists/jaunty/partner/source/Sources.bz2...
dists/jaunty/partner/source/Sources.bz2 failed 404 Not Found
To verify what’s wrong with the online repository, I open a browser, and I navigate to the page from which “debmirror” attempts to download the “Packages.bz2” file—i.e., to the following URL:
There, I discover that “debmirror” is, indeed, correct in reporting that the “Packages.bz2” file is missing. There does, however, exist a “Packages.gz” file—which would work equally well, if only “debmirror” were intelligent enough to look for it instead.Code:http://archive.canonical.com/dists/jaunty/partner/binary-i386/
The Fix.
Obviously, the problem would instantly get solved if I could somehow create the “Packages.bz2” file in the online repository—but I can’t... :???:
Thus, I will have to find a way to tell “debmirror” that the “Packages.bz2” file is missing allright, but that it shouldn’t care, and that it should work with “Packages.gz” instead.
Fortunately, “debmirror” is really a Perl script—which I can study, and possibly even enhance. In the end, here’s how I decide to tackle the issue:
- I will define a new option—“--nopkgbz2”—which will make “debmirror” ignore the “Packages.bz2” file, and download “Packages.gz” instead.
- If “debmirror” is run without my new “--nopkgbz2” option, then it will continue to work as usual—i.e., it will want to download the “Packages.bz2” file, and it will create the “Packages.gz” and “Packages” files from it.
- If “debmirror” is run with my “--nopkgbz2” option, then it will download “Packages.gz” instead, and create the “Packages” file from it.
In the end, the patch to implement this “--nopkgbz2” option turns out to be fairly simple, and it can be applied as documented next.
Note:
The patch applies to the “debmirror” version that is available with Ubuntu 9.04 (the ”Jaunty Jackalope”) and with Ubuntu 9.10 (the ”Karmic Koala”); it does not work (nor is it required) on the “debmirror” version for Ubuntu 8.10 (the ”Intrepid Ibex”) or earlier.
Applying the patch to the “debmirror” script.
I don’t particularly like applying a patch to a system file in-place; instead, I prefer to copy the affected file to, e.g., my home directory, and apply the patch to the copy. Therefore, the following procedure will apply my patch to a copy of the “debmirror” script in the home directory of the user that is currently logged in to the system:
- Execute the following commands to copy the “debmirror” script to your home directory:
Code:cd
cp /usr/bin/debmirror .
- Download the “debmirror_pkgbz2_patch.zip” file attached to this post. Save it into your home directory (next to your “debmirror” copy), and run the following command to unzip it and create the “debmirror_pkgbz2_patch” file:
Code:unzip debmirror_pkgbz2_patch.zip
- Execute the following command to apply the patch (from the “debmirror_pkgbz2_patch” file) to your copy of the “debmirror” script:
Code:patch < debmirror_pkgbz2_patch
Assuming that the “patch” command reports no errors, your “debmirror” copy will now implement my new “--nopkgbz2” option.
Trying out the patched “debmirror” script.
To test the patched “debmirror” script, run it from your home directory (i.e., prepend “~/” to the command name), and add the “--nopkgbz2” option to the command line:
This time, “debmirror” should not try to download the (missing) “Packages.bz2” file, but address“Packages.gz” instead—which should allow the command to complete successfully.Code:~/debmirror --dry-run --md5sums --passive --host=archive.canonical.com --root=ubuntu \
--nopkgbz2 \
--method=http --progress --dist=jaunty --section=partner --arch=i386 \
~/PartnerRepos
The Problem.
I set up a local Ubuntu mirror in which I keep binary packages, but no sources. I would now like to add the source packages to my local mirror.
The “obvious” way to add the source packages, would be to simply remove the “--nosource” option from the “debmirror” command line—e.g.:
HOWEVER, this method has one major drawback, which becomes painfully clear with a huge repository such as in the given example, which consists of five “dists” of four “sections” each: There will be a huge amount of data to be downloaded, and until all source packages are downloaded, my repository will remain in an “unfinished,” inconsistent state.Code:debmirror --md5sums --passive --host=archive.ubuntu.com --root=ubuntu \
--method=http --progress \
--dist=jaunty,jaunty-backports,jaunty-proposed,jaunty-security,jaunty-updates \
--section=main,multiverse,restricted,universe --arch=i386,amd64 \
~/UbuntuRepos
I might be tempted to try and download the source packages in pieces—e.g., specifying only a single “dist” and a single “section” on the first run, and then expanding the parameters again on successive runs, until all source packages get included—but I should DEFINITELY NOT do that: if I omit any “dist” or “section” (or, for that matter, “arch”) value, then all data for the omitted parts will get erased from my local mirror, and I will have to redownload them later on.
It would be a far better idea to create a separate mirror, in which I can download the source packages independently, without affecting my existing (binary) mirror. Fortunately, “debmirror” will let me create a “source-only” mirror pretty easily—as described next.
The Solution: Creating a “Source-Only” Local Mirror.
Since I will be creating a new local mirror, I will first create a directory in which I will download the repository files:
Next, to tell “debmirror” to download only the source packages, and ignore any binary packages, I simply set the “--arch” parameter to “none”—e.g.:Code:mkdir ~/UbuntuSources
Code:debmirror --md5sums --passive --host=archive.ubuntu.com --root=ubuntu \
--method=http --progress --dist=jaunty --section=restricted --arch=none \
~/UbuntuSources
Note:Once my “source-only” mirror is loaded with all source packages from the exact same “dists” and “sections” as my binary mirror, I can copy the full contents of its “pool” directory to my binary mirror, to create a combined “binary-plus-source” mirror (or I might prefer to keep the binary and source packages in their own, separate, mirrors).
In this example, I download only a small sample from the (huge!) collection of source packages that are available in the Ubuntu repositories. Once this small sample is complete, I can expand the “dist” and “section” parameters step by step, until my “source-only” mirror is complete.
Important:
If you create a combined (binary-plus-source) mirror, then make sure that you remove the “--nosource” option from the “debmirror” command line whenever you want to bring it up-to-date again! If you ever run “debmirror” with the “--nosource” option again, then the source packages will be deleted from local the mirror.
It may be timely to discuss the "proposed" dist. "Proposed" is just that, a dist that contains packages that are proposed although in no way a certainty for the regular dists. It is in essence a testing area and it is possible using this dist may cause breakage to an otherwise excellent setup.Quote:
Originally Posted by luvr
What happens if I want to maintain a Repository for non i386,amd64 versions of Ubuntu from Hardy onwards? It's not that difficult and only requires minor changes to the normal script. So if you have a PowerPC and want to run Hardy, Intrepid, Jaunty or upcoming versions after they are released you can still have your arch and repository to :popcorn:
Here's the code:
Remember to modify the coloured text to suit your distribution (hardy, intrepid, jaunty, etc) and architecture (powerpc, sparc, lpia, ia64, hppa, armel)Code:debmirror --nosource -m --passive --host=ports.ubuntu.com --root=/ --method=http --progress --dist=hardy,hardy-security,hardy-updates,hardy-backports,hardy-proposed --section=main,restricted,universe,multiverse --arch=powerpc ~/PortsUbuntuPPCRepos --ignore-release-gpg
Also remember to make sure you name the Repo destination appropriately so you do not overwrite and inadvertently lose other Repos you have downloaded.
Edit: The size of the PowerPC repo for:
Hardy is 27859 MB.
Intrepid is 26968 MB.
Jaunty is 25322 MB.
Thanks so much for this guide!
I had three small problems that might be worth mentioning: : I had to find debpartial from an old distribution and use that. I'm using Hardy myself.
I downloaded the packages for Jaunty. I tried adding them through KPackageKit, but this didn't work as I had expected. So I added them with apt-cdrom like the guide said to, which worked just fine.
However, both KPackageKit and Adept failed to handle the DVD switching once I wanted to install something. Synaptic handles the DVD switching.
Did you try the link in the first post?Quote:
Originally Posted by silence150