Recommended sources.list for new etch installs.

0 views
Skip to first unread message

Gaute Strokkenes

unread,
Apr 19, 2006, 5:00:11 PM4/19/06
to
Recently I purchased a new amd64 PC, and proceeded to install debian
unstable on it. (I have been using debian unstable on an i386 as my
sole desktop system for several years, so I'm reasonably familiar with
debian.) I booted the system from a USB stick with the netinst ISO
image on it. (I used the etch beta 2 images.)

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

Goswin von Brederlow

unread,
Apr 21, 2006, 8:20:12 AM4/21/06
to
Try

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

hen...@topoi.pooq.com

unread,
Apr 21, 2006, 10:30:20 AM4/21/06
to
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
>
> 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?

-- hendrik

Aaron M. Ucko

unread,
Apr 22, 2006, 4:00:23 AM4/22/06
to
hen...@topoi.pooq.com writes:

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

Goswin von Brederlow

unread,
Apr 23, 2006, 9:30:12 AM4/23/06
to
hen...@topoi.pooq.com writes:

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

Reply all
Reply to author
Forward
0 new messages