On Sun, 04 Feb 2007 10:26:54 -0500
Jim Heck <jsurf@heckheck.com> wrote:
> Neil,
>
> I've done some testing and here are the results. I hacked up the 0.0.5
> version of apt-cross.
The dpkg warning you refer to later (which is completely spurious and
can be ignored anyway) is fixed in 0.0.6.
> The #include does work, but does complain if the
> file is not there, resulting in an error.
Thanks for testing that.
> So the .local file will need
> to be touched if referenced in the apt.conf-<suite> file. Also, I did
> have to quote the name of the .local file, and a full path was needed.
Not a problem but useful to know.
> the lines I added (note I did not try to parameterize the touch filename).
>
> $ diff -u 0.0.5/apt-cross 0.0.5-patched/apt-cross
> --- 0.0.5/apt-cross 2007-01-26 11:57:58.000000000 -0500
> +++ 0.0.5-patched/apt-cross 2007-02-04 01:42:13.000000000 -0500
> @@ -276,7 +276,7 @@
> sub setup_config()
> {
> @dirs = qw/ alternatives info parts updates/;
> - @touch = qw/ diversion statoverride status lock/;
> + @touch = qw/ apt.conf-unstable.local diversion statoverride
> status lock/;
> #set up necessary dirs for cross-dpkg database
> if (not -e "$dpkg_cross_dir/$suite") {
> mkdir "$dpkg_cross_dir/$suite";
> @@ -316,6 +316,7 @@
> State "$suite/";
> Cache "$suite/";
> };
> +#include "$dpkg_cross_dir/apt.conf-$suite.local";
> END
> close CONF;
> }
> androcross: /usr/src/emdebian/apt-cross
Those look fine. I can ensure that the @touch array uses the correct
filename.
> Now with these changes, I still ran into some issues, as things were
> still not working. I found that my ./dpkg-cross/sources.unstable file
> was created with only the lines for www.emdebian.org, and did not have
> any lines for the Debian repository that I have in my
> /etc/apt/sources.list file (a previous posting has the contents of my
> sources.list file). The 0.0.5 apt-cross tool doesn't seem to pickup any
> lines from the system sources.list file even though there is an unstable
> source in the file. I fixed this by manually editing the
> sources.unstable file.
This is the --mirror problem I considered in another email. The reason
is quite simple, emdebian-tools will be used to build packages for the
main Emdebian target repository upon which Emdebian users will need to
rely. That repository, therefore, needs to ensure that all packages are
installable (they are not at the moment) and that packages are compiled
in a consistent manner (which is true). I'm not sure about enabling
support for 'apt-cross --mirror' from within the emdebian-tools until
such time as I have a fully working set of tools scripts that can form
the basis of an automated Emdebian buildd. My main target is unchanged:
getting an Emdebian distribution based on GPE for arm by DebConf7.
Today, I've been working on 'emsource' which is a wrapper for 'apt-get
source' that also manages the incorporation of the emdebian patch files
(changelog, control, control.in and rules) into Emdebian SVN. emsource
creates the SVN working copy tree, checks out any existing emdebian
patch files and gets or updates the source, then runs em_make on the
unpacked source or patches debian/changelog, debian/control and
debian/rules instead if patches already exist in Emdebian SVN.
'emdebuild' has gained an 'svn' awareness too, both emdebuild and
emsource use automated SVN checkins (if a valid username is specified
and SSH access is available) to update the patch files. There's more to
do on this tool but it is coming along. In particular, the location of
the patch files within Emdebian SVN currently follows Julian's original
plan and I do think I need to modify that to put the $package under a
sub-directory:
source/target/trunk/$package/trunk/
becomes (for $package eq "apt")
source/target/trunk/a/apt/trunk/
(Thankfully, using SVN makes it trivial to move these files around
AFTER the automated commit made by emsource.)
This is similar to the main repository and makes navigating and listing
directories more manageable. Once that and a few other minor bits are
done, emdebian-tools 0.0.4 will be ready for upload - possibly before
0.0.3 leaves NEW but that's OK because 0.0.4 also closes two i18n
wishlist bugs. apt-cross 0.0.6 will be uploaded at the same time,
probably alongside 1.35 of dpkg-cross (again i18n wishlist bug closure).
Beyond that, I need to get empdebuild usable (the chroot version of
emdebuild) for emdebian-tools 0.0.5. This will be the most useful layer
in emdebian-tools, it should enable lots of packages to be built. I'm
hoping that I can build a lot of the Gtk dependencies without too much
editing, just by running empdebuild from within an emdebianised source
tree (either via em_make or emsource). The more packages become
available from the Emdebian target repository, the less dependencies
need to be calculated and the quicker the whole thing grows. At least,
that's the theory. The sequence will be important, building just the
packages that depend on what we have before building packages that
depend on packages we haven't built yet. I'm hoping that the infant
'empath' program can pick out which packages to build and in which
order but the current recursive algorithm is not up to the job. (empath
is written in C, if anyone fancies taking a look at it, it's in SVN:
tools/empath.)
emsource will be an entirely optional component of emdebian-tools,
there's absolutely nothing wrong with using 'apt-get source' or 'dget
-x' followed by em_make - emsource just makes it easy (hopefully) for
collaborative maintenance of Emdebian packages.
(Some of this also needs to get onto the Wiki and website. I thought
about a 'manpage' section under emdebian/ because the XML used to
create the manpages can also be used to create HTML representations of
the manpages.)
> Next, I had the problem that running apt-get as user jh150702 could not
> get the lock file for /var/lib/dpkg/lock (the error message asked if I
> was root). If I tried to run the command using sudo, then it couldn't
> open the /home/jh150702/.dpkg-cross/unstable/lists/lock file due to a
> permission problem. I finally got it to run by changing the permissions
> on the file /var/lib/dpkg/lock file to allow r/w by everyone. Once I
> did this, I ran the apt-get as user jh150702 and finally succeeded and
> filled my cache.
If you'd used the Status stanza from apt-cross 0.0.6, you would have
prevented the permissions error from dpkg. It only happens because the
underlying apt calls default to using a status lock file in the same
directory as the dpkg status file which is (necessarily) in a
privileged system folder. I wouldn't recommend your chmod
666 /var/lib/dpkg/lock fix. If you port your changes to apt-cross 0.0.6
in current SVN, you should get a much better result and you can revert
to safer permissions.
> Now I tried this both with and without the proxy line in the .local
> file. It worked both ways. I think the proxy line was not the true
> problem, but rather one/both of the above problems instead.
Interesting. Have you tried apt-cross 0.0.6 from SVN? It includes the
fixes to the permissions error and it may therefore work for you.
> My read of
> the apt.conf man page leads me to believe that the settings for apt.conf
> are built up using a combination of the conf files, including the main
> system file that is matched by the Dir::Etc::main filename (see below),
> as well as the one specified on the command line with -c
>
> The result of this is that I think we don't specifically need the proxy
> line in the .local file. That file still could be useful for people to
> override settings that shouldn't be set in the system apt.conf file, but
> as for the proxy line, it would already be set.
So you've set the proxy as system-wide rather than user-specific. That
makes sense. If the proxy is required for all apt access, including
system-wide apt-get upgrade and normal apt-get install operations, then
the user-specific configuration in ~/.dpkg-cross should not be
necessary (or desirable).
> Below find some listings with the errors I encoutered. Let me know if
> you need further testing tomorrow.
No rush, but if you could test with apt-cross 0.0.6 from SVN - without
any changes initially - under your new config with the proxy set
system-wide, it would be very useful. You can do:
$ mkdir tools/build-area
$ cd tools/build-area
tools/apt-cross$ svn-buildpackage -uc -us -rfakeroot -D --svn-ignore
to build a test package of apt-cross 0.0.6 which you can install and
then use with emdebian-tools.
If you haven't built a package straight from SVN before, you may need
to edit tools/apt-cross/.svn/deb-layout : apt-cross$ cat .svn/deb-layout
buildArea=/opt/working/emdebian/svn/tools/build-area
tagsDir=/opt/working/emdebian/svn/tools/apt-cross/tags
....
> E: Could not open lock file /var/lib/dpkg/lock - open (13 Permission denied)
> E: Unable to lock the administration directory (/var/lib/dpkg/), are you
> root?
Use the Status stanza from 0.0.6 and this error (which is safe to
ignore) goes away.
> $ ./jim.pl
...
> 1 = 3.2
> gcc-3.3
> 1 = 3.3
> gcc-3.4
> 1 = 3.4
> gcc-3.4-base
> gcc-4.0
> 1 = 4.0
> gcc-4.1
> 1 = 4.1
...
> final choice = 4.1
That's good to see.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgp6AW_6wGcKA.pgp
Description: PGP signature