The install itself went fairly smoothly. There were a few hickups:
The install will not complete unless a network connection is
available, and some of the decisions made by the partitioning tool
seem a bit odd: My root partition is only just over a quarter of a
gigabyte large (on a 300GB drive), and I didn't succeed in enlargening
it during the installation process. Eventually I decided to just
trust the default settings. However, my root partition is already 43%
full...but I digress.
After the install was done I noticed that very few packages were
installed, and that some packages were simply not available via the
default sources.list, for instance I was initally unable to install
make (404 error). After some fiddling and googling about I ended up
with the following:
--8<--
#
# deb cdrom:[Debian GNU/Linux testing _Etch_ - Official Snapshot amd64 Binary-1 (20060314)]/ etch main
deb ftp://mirror.espri.arizona.edu/debian-amd64/debian/ etch main contrib non-free
deb-src ftp://mirror.espri.arizona.edu/debian-amd64/debian/ etch main contrib non-free
deb ftp://debian.csail.mit.edu/debian-amd64/debian/ etch main contrib non-free
deb ftp://ftp.uk.debian.org/debian etch main contrib non-free
deb-src ftp://ftp.uk.debian.org/debian etch main contrib non-free
deb ftp://ftp.us.debian.org/debian etch main contrib non-free
deb-src ftp://ftp.us.debian.org/debian etch main contrib non-free
# Line commented out by installer because it failed to verify:
#deb http://security.debian.org/ etch/updates main
deb-src http://security.debian.org/ etch/updates main
--8<--
Even with this I was unable to do "apt-get install gnome", for
instance. I am somewhat curious whether this is broken in testing in
general right now or whether this is amd64-specific breakage.
Another package that I can't find is "nvidia-kernel-source", though
its companion package "nvidia-common" is available.
I've looked briefly through the debian-amd64 mailing list archives and
I understand that the amd64 port is transitioning from its own buildd
and package repository infrastructure to the debian proper
infrastructure. Unfortunately, I have not quite been able to work out
on my own just how this translates into sources.list entries etc. I'd
be grateful if someone could give me a pointer in the right direction.
--
Gaute Strokkenes
I'm having a MID-WEEK CRISIS!
--
To UNSUBSCRIBE, email to debian-amd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
deb http://amd64.<cc>.mirrors.debian.net/debian sid main contrib non-free
etch still needs time for packages to drift into it from the official
sid. It will be some more weeks/month before that populated enough to
be usable.
MfG
Goswin
Are there any problems involved in *adding* a line like this to an
existing sources.list, rather than replacing an existing one?
-- hendrik
> Are there any problems involved in *adding* a line like this to an
> existing sources.list, rather than replacing an existing one?
I'm (still) using a "hybrid" setup along those lines; it seems to work
fine, though you need to take some care to ensure that you always get
official packages. With the old autobuilder shut off, I believe the
following should be sufficient:
- Run apt-cache clean to get rid of unofficial binaries.
- Give unofficial packages a lower priority in /etc/apt/preferences:
Explanation: Discount the unofficial amd64 archive, as the official
Explanation: archive is finally starting to gain amd64 binary packages.
Package: *
Pin: release l=Debian AMD64 archive
Pin-Priority: 300
- For good measure, also list them later in your sources.list.
Also, be advised that most of the old archive's binary-only rebuilds
have been superseded; here's the code I use to determine what needs
"downgrading":
#unofficial=unofficial package lists (filenames)
#official=official package lists
grep-dctrl -n -sPackage -FVersion -e '\+b[0-9]+$' $unofficial | \
sed -e 's/^/\^/; s/[.+]/\\\\&/g;
s/$/\$~S~i~V\\\\+b[0-9]+$/' | \
xargs --no-run-if-empty aptitude -F '%p' search | \
sed -e 's/^/\^Package: /; s/[.+]/\\&/; s/ *$/\$/' > bin-nmu-patterns
grep-dctrl -sPackage ! -FVersion -e '\+b[0-9]+$' $official | \
grep -Ehf bin-nmu-patterns | \
sed -e 's/^Package: /\^/; s/[.+]/\\\\&/g; s/$/\$~i/' | \
xargs --no-run-if-empty aptitude -F '%p =%V#' search | \
sed -ne 's/ *//g; s/+b[0-9]*$//p'
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger a...@monk.mit.edu (NOT a valid e-mail address) for more info.
> On Fri, Apr 21, 2006 at 02:12:12PM +0200, Goswin von Brederlow wrote:
>> Try
>>
>> deb http://amd64.<cc>.mirrors.debian.net/debian sid main contrib non-free
sorry, this actualy needs to be
deb http://<cc>.amd64.mirror.debian.net/debian sid main contrib non-free
which seems to be still missing from the aliases list. For now you can
use
deb http://<cc>.i386.mirror.debian.net/debian sid main contrib non-free
since all main mirrors must have i386 and amd64.
>> etch still needs time for packages to drift into it from the official
>> sid. It will be some more weeks/month before that populated enough to
>> be usable.
>
> Are there any problems involved in *adding* a line like this to an
> existing sources.list, rather than replacing an existing one?
That would result in different builds of the same package and version
to be available to apt. Often that results in apt reinstalling the
package on every upgrade. Apart from that nothing bad should happen.