Lots of packets are missing in amd64/etch...
Alexander Vlasov
I've just received a new server on amd64 (em64t) platform and tried to
install sarge.
Unfortunately, hardware is hardly supported by sarge, so I dist-upgraded
to etch immediately after install.
But now I faced the strange problem: a lot of packages aren't available
in amd64 etch.
And one of the nastiest things is unavailable gcc 8( So I can't install
pbuilder and rebuild packages by myself.
Can anyone explain me what's going on? Is official arch inclusion not
over yet? Where can I find the progress reports?
Thanks a lot in advance.
PS. Please CC me, I'm not on the list
--
Alexander Vlasov
ZULU-UANIC
JID: zulu <at> jabber.kiev.ua
--
To UNSUBSCRIBE, email to debian-amd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Goswin von Brederlow
> Hello.
>
> I've just received a new server on amd64 (em64t) platform and tried to
> install sarge.
> Unfortunately, hardware is hardly supported by sarge, so I dist-upgraded
> to etch immediately after install.
>
> But now I faced the strange problem: a lot of packages aren't available
> in amd64 etch.
> And one of the nastiest things is unavailable gcc 8( So I can't install
> pbuilder and rebuild packages by myself.
>
> Can anyone explain me what's going on? Is official arch inclusion not
> over yet? Where can I find the progress reports?
>
> Thanks a lot in advance.
>
> PS. Please CC me, I'm not on the list
Debian sid amd64 is being autobuild. From there packages slowly
migrate to etch simultanious for every architecture with the usual
rules (minimum age, no new bugs, depends are there). For etch to have
all amd64 packages every package has to migrate to etch. That just
takes time.
Looking at gcc packages.qa.debian.org tells me the following:
http://packages.qa.debian.org/g/gcc-defaults.html
* 10 days old (needed 10 days)
* gcj/m68k unsatisfiable Depends: gcj-4.1 (>= 4.1.0-2)
* gij/m68k unsatisfiable Depends: gij-4.1 (>= 4.1.0-2)
* gobjc++/m68k unsatisfiable Depends: gobjc++-4.1 (>= 4.1.0-2)
* libgcj-dev/m68k unsatisfiable Depends: libgcj7-dev (>= 4.1.0-2)
* cpp (i386, alpha, hppa, ia64, mips, mipsel, powerpc, amd64, arm, m68k, s390, sparc) is (less) buggy! (1 <= 1)
* Valid candidate
* Invalidated by dependency
* Not considered
* Depends: gcc-defaults gcj-4.1 (not considered)
An gcj-4.1 is blocked by freetype which in turn is only 5 out of 10
days old.
MfG
Goswin
Eduardo M KALINOWSKI
>For etch to have
>all amd64 packages every package has to migrate to etch. That just
>takes time.
>
>
>
And if packages happen to have RC bugs, then that takes an even longer
time. ;-)
--
Please ignore previous fortune.
Eduardo M KALINOWSKI
eka...@bol.com.br
http://move.to/hpkb
Goswin von Brederlow
> Goswin von Brederlow wrote:
>
>>For etch to have
>>all amd64 packages every package has to migrate to etch. That just
>>takes time.
>>
>>
>>
> And if packages happen to have RC bugs, then that takes an even longer
> time. ;-)
Time is ageless. :)
MfG
Goswin
Koen Vermeer
> >For etch to have
> >all amd64 packages every package has to migrate to etch. That just
> >takes time.
> And if packages happen to have RC bugs, then that takes an even longer
> time. ;-)
So, what is the right way to handle things if one has a running etch
system (based on debian-amd64, with a line in sources.list such as 'deb
ftp://ftp.nl.debian.org/debian-amd64/debian/ testing contrib main
non-free')? Do nothing until the full official etch repository is
available? Or should one add a line to sources.list that includes the
new, official stuff?
Koen
Gleidson Echeli Leopoldo
>
> So, what is the right way to handle things if one has a running etch
> system (based on debian-amd64, with a line in sources.list such as 'deb
> ftp://ftp.nl.debian.org/debian-amd64/debian/ testing contrib main
> non-free')?
For etch/testing the mirror is:
ftp://ftp.XX.debian.org/debian/ testing main contrib non-free
> Do nothing until the full official etch repository is
> available?
ftp://ftp.XX.debian.org/debian etch main contrib non-free
=)
_______________________________________________________
Navegue com o Yahoo! Acesso Grátis, assista aos jogos do Brasil na Copa e ganhe prêmios de hora em hora!
http://br.yahoo.com/artilheirodacopa/
Goswin von Brederlow
> On Sun, 2006-05-28 at 09:34 -0300, Eduardo M KALINOWSKI wrote:
>> >For etch to have
>> >all amd64 packages every package has to migrate to etch. That just
>> >takes time.
>> And if packages happen to have RC bugs, then that takes an even longer
>> time. ;-)
>
> So, what is the right way to handle things if one has a running etch
> system (based on debian-amd64, with a line in sources.list such as 'deb
> ftp://ftp.nl.debian.org/debian-amd64/debian/ testing contrib main
> non-free')? Do nothing until the full official etch repository is
> available? Or should one add a line to sources.list that includes the
> new, official stuff?
>
> Koen
The old archive is discontinued. You should also remove any sarge line
as that confuses apt-get (sarge and etch/sid have some packages with
the same version but debian has different debs).
Just put the official etch in there and things will upgrade as they
move into etch.
MfG
Goswin
Koen Vermeer
> The old archive is discontinued. You should also remove any sarge line
> as that confuses apt-get (sarge and etch/sid have some packages with
> the same version but debian has different debs).
> Just put the official etch in there and things will upgrade as they
> move into etch.
OK, I'll try that. I just delayed messing with it after I saw some
people reporting problems. I'll replace my old deb-line with the new
one, and sew what happens...
Thanks!
Koen
Francesco Pietra
I wish you success in your frontiersman initiative. Please report in detail
for conservativeman. It will avoid wasting energies.
francesco pietra
Koen Vermeer
> OK, I'll try that. I just delayed messing with it after I saw some
> people reporting problems. I'll replace my old deb-line with the new
> one, and sew what happens...
My apologies for that "'Allo 'Allo"-ish error...
Anyway, I did the replacement of that deb-line, and while I still have a
working system, the result isn't what I expected. I now have the 'some
packages keep getting updated'-syndrom, which was one of the things I
was trying to avoid. In my case, it's libgnokii2, libbonobo2-0 and
libselinux1. One other thing is that xserver-xorg cannot be updated due
to a missing dependency, but that's not a major issue. I just hope the
updates of those three packages will be fixed automagically some time in
the near future.
Francesco Pietra
francesco
Koen Vermeer
> So, your hope is in sorcery.
Well, I guess that once there is a truly newer version of those packages
in the official etch repository, the confusion is over. We'll see what
happens. In my case, it's only three packages, so I can live with it for
now. On the other hand, I am not very happy with it, but I don't have
any idea to whom I should complain.
Francesco Pietra
sure that I appreciate very much your efforts.
francesco pietra
Goswin von Brederlow
> On Mon, 2006-05-29 at 09:07 +0200, Koen Vermeer wrote:
>> OK, I'll try that. I just delayed messing with it after I saw some
>> people reporting problems. I'll replace my old deb-line with the new
>> one, and sew what happens...
>
> My apologies for that "'Allo 'Allo"-ish error...
>
> Anyway, I did the replacement of that deb-line, and while I still have a
> working system, the result isn't what I expected. I now have the 'some
> packages keep getting updated'-syndrom, which was one of the things I
> was trying to avoid. In my case, it's libgnokii2, libbonobo2-0 and
> libselinux1. One other thing is that xserver-xorg cannot be updated due
> to a missing dependency, but that's not a major issue. I just hope the
> updates of those three packages will be fixed automagically some time in
> the near future.
>
> Koen
Run apt-get clean and don't have any inofficial amd64 archive in your
sources.list.
MfG
Goswin
Koen Vermeer
> Run apt-get clean and don't have any inofficial amd64 archive in your
> sources.list.
Cool, that's better than waiting for the automagical fix! :-) Thanks for
the pointers!
Koen
Anthony DeRobertis
>
> I now have the 'some
> packages keep getting updated'-syndrom, which was one of the things I
> was trying to avoid.
One alternative to Goswin's suggestion of apt-get clean is to manually
go in to /var/cache/apt/archives and remove the specific package/version
involved.