I am trying to get up the courage to update my debian etch system
after a few months of neglecting to do so, but am dreading the thought of
some mishap leaving the system unusable.
The system was installed back in April, and is on a Fujitsu P7120, and
aptitude produces quite a long list of things it wants to delete and
upgrade, so I want to be cautious about telling it to go ahead.
The first thing that gives me cause for concern is that the output
resulting from a 'apt-get update' does not look very clean:
Get:1 http://www.debian-multimedia.org etch Release.gpg [189B]
Get:2 http://mirror.ox.ac.uk etch Release.gpg [378B]
Hit http://www.debian-multimedia.org etch Release
Hit http://mirror.ox.ac.uk etch Release
Err http://www.debian-multimedia.org etch Release
Get:3 http://www.debian-multimedia.org etch Release [5560B]
Hit http://mirror.ox.ac.uk etch/main Packages
Ign http://www.debian-multimedia.org etch Release
Hit http://mirror.ox.ac.uk etch/main Sources
Hit http://www.debian-multimedia.org etch/main Packages
Get:4 http://security.debian.org etch/updates Release.gpg [189B]
Hit http://security.debian.org etch/updates Release
Hit http://security.debian.org etch/updates/main Packages
Hit http://security.debian.org etch/updates/main Sources
Fetched 5751B in 0s (7515B/s)
Reading package lists... Done
W: There are no public key available for the following key IDs:
A70DAF536070D3A1
W: GPG error: http://www.debian-multimedia.org etch Release: The following signa
tures couldn't be verified because the public key is not available: NO_PUBKEY 07
DC563D1F41B907
W: You may want to run apt-get update to correct these problems
Are any of these messages things that should concern me? Why the 'Err',
'Ign' and 'W:' messages?
My sources.list looks like this:
deb http://mirror.ox.ac.uk/debian/ etch main
deb-src http://mirror.ox.ac.uk/debian/ etch main
deb http://security.debian.org/ etch/updates main
deb-src http://security.debian.org/ etch/updates main
deb http://www.debian-multimedia.org etch main
The multimedia web site only mentions
deb-src http://www.debian-multimedia.org sid main
for sources - nothing specifically for Etch. Is it safe/desireble
to add that to my sources list?
I have tried adding the PGP key for the multimedia packages as
per the instructions on the web site, but get:
digbyt@fujitsu:~$ gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 1F41B907
gpg: requesting key 1F41B907 from hkp server wwwkeys.eu.pgp.net
gpg: keyserver timed out
gpg: keyserver receive failed: keyserver error
One other thing that I am unsure about is that aptitude reports a number
of packages being 'held back'. I havn't intentionally asked for this,
could it have occured automatically or have I unintentionally done
something when initially learning to use aptitude?
Any advice or reassurance would be appreciated.
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
Bookmark/Search this post with:
Militantly FREE software support.
update messages
On Thu, Dec 28, 2006 at 04:40:19AM +0000, Digby Tarvin wrote:
> One other thing that I am unsure about is that aptitude reports a number
> of packages being 'held back'. I havn't intentionally asked for this,
> could it have occured automatically or have I unintentionally done
> something when initially learning to use aptitude?
You probably just need to 'dist-upgrade'
Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
--
update messages
Digby Tarvin wrote:
> I am trying to get up the courage to update my debian etch system
> after a few months of neglecting to do so, but am dreading the thought of
> some mishap leaving the system unusable.
>
> The system was installed back in April, and is on a Fujitsu P7120, and
> aptitude produces quite a long list of things it wants to delete and
> upgrade, so I want to be cautious about telling it to go ahead.
>
> The first thing that gives me cause for concern is that the output
> resulting from a 'apt-get update' does not look very clean:
> Get:1 http://www.debian-multimedia.org etch Release.gpg [189B]
> Get:2 http://mirror.ox.ac.uk etch Release.gpg [378B]
> Hit http://www.debian-multimedia.org etch Release
> Hit http://mirror.ox.ac.uk etch Release
> Err http://www.debian-multimedia.org etch Release
>
> Get:3 http://www.debian-multimedia.org etch Release [5560B]
> Hit http://mirror.ox.ac.uk etch/main Packages
> Ign http://www.debian-multimedia.org etch Release
> Hit http://mirror.ox.ac.uk etch/main Sources
> Hit http://www.debian-multimedia.org etch/main Packages
> Get:4 http://security.debian.org etch/updates Release.gpg [189B]
> Hit http://security.debian.org etch/updates Release
> Hit http://security.debian.org etch/updates/main Packages
> Hit http://security.debian.org etch/updates/main Sources
> Fetched 5751B in 0s (7515B/s)
> Reading package lists... Done
> W: There are no public key available for the following key IDs:
> A70DAF536070D3A1
> W: GPG error: http://www.debian-multimedia.org etch Release: The following signa
> tures couldn't be verified because the public key is not available: NO_PUBKEY 07
> DC563D1F41B907
> W: You may want to run apt-get update to correct these problems
>
> Are any of these messages things that should concern me? Why the 'Err',
> 'Ign' and 'W:' messages?
>
> My sources.list looks like this:
> deb http://mirror.ox.ac.uk/debian/ etch main
> deb-src http://mirror.ox.ac.uk/debian/ etch main
> deb http://security.debian.org/ etch/updates main
> deb-src http://security.debian.org/ etch/updates main
> deb http://www.debian-multimedia.org etch main
>
> The multimedia web site only mentions
> deb-src http://www.debian-multimedia.org sid main
> for sources - nothing specifically for Etch. Is it safe/desireble
> to add that to my sources list?
>
> I have tried adding the PGP key for the multimedia packages as
> per the instructions on the web site, but get:
> digbyt@fujitsu:~$ gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 1F41B907
> gpg: requesting key 1F41B907 from hkp server wwwkeys.eu.pgp.net
> gpg: keyserver timed out
> gpg: keyserver receive failed: keyserver error
>
> One other thing that I am unsure about is that aptitude reports a number
> of packages being 'held back'. I havn't intentionally asked for this,
> could it have occured automatically or have I unintentionally done
> something when initially learning to use aptitude?
>
So don't upgrade / dist-upgrade a running partition.
Copy the partition to another one and upgrade *that* one.
Then if something goes wrong you lost nothing.
Hugo
--
update messages
On Thu, Dec 28, 2006 at 04:40:19AM +0000, Digby Tarvin wrote:
> I am trying to get up the courage to update my debian etch system
> after a few months of neglecting to do so, but am dreading the thought of
> some mishap leaving the system unusable.
>
> The system was installed back in April, and is on a Fujitsu P7120, and
> aptitude produces quite a long list of things it wants to delete and
> upgrade, so I want to be cautious about telling it to go ahead.
>
> The first thing that gives me cause for concern is that the output
> resulting from a 'apt-get update' does not look very clean:
> Get:1 http://www.debian-multimedia.org etch Release.gpg [189B]
> Get:2 http://mirror.ox.ac.uk etch Release.gpg [378B]
> Hit http://www.debian-multimedia.org etch Release
> Hit http://mirror.ox.ac.uk etch Release
> Err http://www.debian-multimedia.org etch Release
>
> Get:3 http://www.debian-multimedia.org etch Release [5560B]
> Hit http://mirror.ox.ac.uk etch/main Packages
> Ign http://www.debian-multimedia.org etch Release
> Hit http://mirror.ox.ac.uk etch/main Sources
> Hit http://www.debian-multimedia.org etch/main Packages
> Get:4 http://security.debian.org etch/updates Release.gpg [189B]
> Hit http://security.debian.org etch/updates Release
> Hit http://security.debian.org etch/updates/main Packages
> Hit http://security.debian.org etch/updates/main Sources
> Fetched 5751B in 0s (7515B/s)
> Reading package lists... Done
> W: There are no public key available for the following key IDs:
> A70DAF536070D3A1
> W: GPG error: http://www.debian-multimedia.org etch Release: The following signa
> tures couldn't be verified because the public key is not available: NO_PUBKEY 07
> DC563D1F41B907
> W: You may want to run apt-get update to correct these problems
I think Marillat is in the debian-archive-keyring now, just install
that.
[...]
>
> One other thing that I am unsure about is that aptitude reports a number
> of packages being 'held back'. I havn't intentionally asked for this,
> could it have occured automatically or have I unintentionally done
> something when initially learning to use aptitude?
Hugo is right, just fully backup the partition, if it will make you
feel better. The 'held-back' refers to packages which have newer
versions available but can't be installed because some dependency is
not available. 'Dist-upgrade' is what you need to resolve some of
these. You will at some point just have to "do it" and be prepared for
the results. Personally, I've done many very large upgrades in sid
with generally no problems. ymmv. Finally, if you aren't prepared to
maintain the system properly to avoid these issues, maybe you shouldn't
be running a more volatile set of packages like testing and focus on
stable instead. no offense intended if so perceived.
A
update messages
> >
> > One other thing that I am unsure about is that aptitude reports a number
> > of packages being 'held back'. I havn't intentionally asked for this,
> > could it have occured automatically or have I unintentionally done
> > something when initially learning to use aptitude?
>
> Hugo is right, just fully backup the partition, if it will make you
> feel better. The 'held-back' refers to packages which have newer
> versions available but can't be installed because some dependency is
> not available. 'Dist-upgrade' is what you need to resolve some of
> these. You will at some point just have to "do it" and be prepared for
> the results. Personally, I've done many very large upgrades in sid
> with generally no problems. ymmv.
Thanks - in that case I will give it a go. Just wanted to be sure
everything looked normal before letting it run.
I have had problems in the past after upgrades on gentoo which has led
me to be reticent about updating software in advance of actually needing
some new feature...
> Finally, if you aren't prepared to
> maintain the system properly to avoid these issues, maybe you shouldn't
> be running a more volatile set of packages like testing and focus on
> stable instead. no offense intended if so perceived.
Point taken, and it was my intention to stick to stable for my first
Debian install, but I was forced into Etch because the Toshiba Lifebook
included hardware that needed drivers not included in stable. In fact
even Etch hasn't managed to get everything working - but at least it
allowed me to get most of what was working under a Ubuntu live CD
also working in Debian. (I can survive with microphone and modem
problems, but not a non-working X server..)
Can you elaborate on what you consider to be necessary to 'maintain
the system properly'? I recall reading somewhere that it was considered
anti-social to update with excessive frequency, but I don't recall
seeing any warning that using unstable involved a commitment to a
minimum upgrade frequency.
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Thu, Dec 28, 2006 at 06:44:38PM +0000, Digby Tarvin wrote:
>
> Thanks - in that case I will give it a go. Just wanted to be sure
> everything looked normal before letting it run.
your caution is justified, don't get me wrong.
>
> I have had problems in the past after upgrades on gentoo which has led
> me to be reticent about updating software in advance of actually needing
> some new feature...
I have not used any distro but debian and can't speak to how it holds
up against others, but I do know... I have made some massive upgrades
in sid (like 300+ packages) with no real problems.
>
> > Finally, if you aren't prepared to
> > maintain the system properly to avoid these issues, maybe you shouldn't
> > be running a more volatile set of packages like testing and focus on
> > stable instead. no offense intended if so perceived.
>
> Point taken, and it was my intention to stick to stable for my first
> Debian install, but I was forced into Etch because the Toshiba Lifebook
> included hardware that needed drivers not included in stable. In fact
> even Etch hasn't managed to get everything working - but at least it
> allowed me to get most of what was working under a Ubuntu live CD
> also working in Debian. (I can survive with microphone and modem
> problems, but not a non-working X server..)
fair enough. and as I said, I truly meant no offense. You have to use
what works for you.
>
> Can you elaborate on what you consider to be necessary to 'maintain
> the system properly'? I recall reading somewhere that it was considered
> anti-social to update with excessive frequency, but I don't recall
> seeing any warning that using unstable involved a commitment to a
> minimum upgrade frequency.
>
testing, when its churning heavily post-release, and sid all the time,
have large numbers of packages upgraded quite regularly. If you aren't
upgrading regularly, you will quickly have a large number of packages
to upgrade, which can certainly be scary. For example, I upgrade
pretty often (maybe twice a week) and my last upgrade was about4 or 5
days ago (I think): I currently have 150 packages to upgrade (sid). It
doesn't take long to get a real backlog.
I don't think its anti-social to regularly upgrade your system. It is
anti-social to gratuitously download stuff and throw it away to
download it again. To spread the load, I use cron-apt to download
packages overnight (when, at least theortically, the load is lower) on
a nightly basis. This means that I get a few packages a night which
spread *MY* impact over several days. This is as opposed to waiting
for several days and hammering the server by downloading 150 packages
at once.
You are right, there is certainly no committment with any system to
any sort of upgrade frequency nor, frankly, any other committment at
all :). If one is running a more volatile system,
then one must be prepared to face a massive upgrade if one chooses to
upgrade the system at all. And, one must be prepared to handle a
massive upgrade at some point in the future as a result of just
installing a package as that package's dependencies may have moved so
far as to force the massive upgrade.
Maintaining a system properly is, of course, subjective. If you use a
volatile system and don't regularly upgrade, then you will have to face
a massive upgrade and be prepared for the consequences. I bet those
consequences are minimal at this time. My choice of words was
unfortunate. I should have said something like "if you aren't prepared
to handle the massive upgrades involved in a more volatile system,
maybe you should be running a less volatile one."
And I was definitely feeling a bit ornery this morning, so I apologise
if I came off wrong.
> Regards,
likewise
A
update messages
On Thu, Dec 28, 2006 at 11:36:10AM -0800, Andrew Sackville-West wrote:
> Maintaining a system properly is, of course, subjective. If you use a
> volatile system and don't regularly upgrade, then you will have to face
> a massive upgrade and be prepared for the consequences. I bet those
> consequences are minimal at this time. My choice of words was
> unfortunate. I should have said something like "if you aren't prepared
> to handle the massive upgrades involved in a more volatile system,
> maybe you should be running a less volatile one."
I think that rather than letting aptitude loose to do everything
it wants in one fell swoop, it might be more conservative to start
with an
apt-get update && apt-get upgrade
to get the easier updates done first, and then if that goes well
follow up with a hopefully smaller
apt-get dist-upgrade
to deal with the remainder in a separate run.
Then I can try running aptitude and hopefully it will have stopped
crashing and can tell me what else it thinks is left to be done....
One of the things that bothered me about what aptitude wanted to do
was that it included several packages it threatened to remove because
they were 'no longer used'. I don't know how it decided this, as the
list included packages like 'xv' and 'xearth' which I explicitly
installed and definately use quite regularly....
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Thu, Dec 28, 2006 at 08:40:41PM +0000, Digby Tarvin wrote:
>
> I think that rather than letting aptitude loose to do everything
> it wants in one fell swoop, it might be more conservative to start
> with an
> apt-get update && apt-get upgrade
as you know, running apt-get and aptitude can cause a database to get
out of sync... but your plan is not without merit. If you have
previously used aptitude exclusively, you can do the same thing as
above but s/apt-get/aptitude/g.
aptitude update && aptitude upgrade
will give you the same behavior as apt-get...
>
> to get the easier updates done first, and then if that goes well
> follow up with a hopefully smaller
> apt-get dist-upgrade
> to deal with the remainder in a separate run.
and then follow up with
aptitude dist-upgrade
>
> Then I can try running aptitude and hopefully it will have stopped
> crashing and can tell me what else it thinks is left to be done....
I missed the bit about it crashing. what's happening?
>
> One of the things that bothered me about what aptitude wanted to do
> was that it included several packages it threatened to remove because
> they were 'no longer used'. I don't know how it decided this, as the
> list included packages like 'xv' and 'xearth' which I explicitly
> installed and definately use quite regularly....
run aptitude in interactive mode and manually mark those packages:
aptitude
then 'u' to update, 'U' to mark for upgrade, then 'g' to see what it
want to do. scroll through and mark 'm' on those you want to keep,
which should mark them as manually installed. you may need to '+'
them as well, to keep them around. I have not been using aptitude long
(having used apt-get exclusively before), but am learning that you can
actually get it to do what *you* want with a little fiddling. Then it
will generally respect what you want...
good luck
A
update messages
On Thu, Dec 28, 2006 at 01:02:25PM -0800, Andrew Sackville-West wrote:
>
> as you know, running apt-get and aptitude can cause a database to get
> out of sync...
Actually I have only recently become aware of this. I had previously
just thought of aptitude as a menu based front end for apt, so I
tended to use 'apt-get install' when I knew exactly what I wanted,
and 'aptitude' when I needed to browse or couldn't remember the
command to do something :-/
> but your plan is not without merit. If you have
> previously used aptitude exclusively, you can do the same thing as
> above but s/apt-get/aptitude/g.
>
> aptitude update && aptitude upgrade
>
> will give you the same behavior as apt-get...
Ah, thanks. That is worth knowing.
> > to get the easier updates done first, and then if that goes well
> > follow up with a hopefully smaller
> > apt-get dist-upgrade
> > to deal with the remainder in a separate run.
>
> and then follow up with
>
> aptitude dist-upgrade
Is that last line what is needed to get aptitude back into
sync? If not, how is that achieved?
> > Then I can try running aptitude and hopefully it will have stopped
> > crashing and can tell me what else it thinks is left to be done....
>
> I missed the bit about it crashing. what's happening?
It only started happening after I had tried an 'apt-get install aptitude'
to upgrade to the latest version (and co-incidentally after I had done
the 'apt-get install' of the pgp keyring - so I am not certain which
was responsible).
What happens now is that after any attempt to issue a 'u' command in
aptitude, I get an abort leaving me back in the command line (with a
garbled display) and the error message:
aptitude: symbol lookup error: aptitude: undefined symbol: _ZN9pkgPolicyD2Ev
> > One of the things that bothered me about what aptitude wanted to do
> > was that it included several packages it threatened to remove because
> > they were 'no longer used'. I don't know how it decided this, as the
> > list included packages like 'xv' and 'xearth' which I explicitly
> > installed and definately use quite regularly....
>
> run aptitude in interactive mode and manually mark those packages:
>
> aptitude
>
> then 'u' to update, 'U' to mark for upgrade, then 'g' to see what it
> want to do. scroll through and mark 'm' on those you want to keep,
> which should mark them as manually installed. you may need to '+'
> them as well, to keep them around. I have not been using aptitude long
> (having used apt-get exclusively before), but am learning that you can
> actually get it to do what *you* want with a little fiddling. Then it
> will generally respect what you want...
So this behaviour could be the result of my having installed some
applications using 'apt-get install' rather than aptitude, leaving
aptitude unaware of them being manual rather than automatic
installs? That would explain things.
Thanks for the advice.
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Thu, Dec 28, 2006 at 09:33:10PM +0000, Digby Tarvin wrote:
> On Thu, Dec 28, 2006 at 01:02:25PM -0800, Andrew Sackville-West wrote:
> >
> > and then follow up with
> >
> > aptitude dist-upgrade
>
> Is that last line what is needed to get aptitude back into
> sync? If not, how is that achieved?
no, it won't. there are a variety of ways to do this. I prefer the
method below where you watch for problems and fix them as they
appear. There are several threads on this int he recent archives that
detail other methods of solving this problem (I think they essentially
mark *everything* as manual).
>
> > > Then I can try running aptitude and hopefully it will have stopped
> > > crashing and can tell me what else it thinks is left to be done....
> >
> > I missed the bit about it crashing. what's happening?
>
> It only started happening after I had tried an 'apt-get install aptitude'
> to upgrade to the latest version (and co-incidentally after I had done
> the 'apt-get install' of the pgp keyring - so I am not certain which
> was responsible).
>
> What happens now is that after any attempt to issue a 'u' command in
> aptitude, I get an abort leaving me back in the command line (with a
> garbled display) and the error message:
> aptitude: symbol lookup error: aptitude: undefined symbol: _ZN9pkgPolicyD2Ev
yuck. that sounds like a bug. does it do the same from command line?
aptitude update
>
> > > One of the things that bothered me about what aptitude wanted to do
> > > was that it included several packages it threatened to remove because
> > > they were 'no longer used'. I don't know how it decided this, as the
> > > list included packages like 'xv' and 'xearth' which I explicitly
> > > installed and definately use quite regularly....
> >
> > run aptitude in interactive mode and manually mark those packages:
> >
> > aptitude
> >
> > then 'u' to update, 'U' to mark for upgrade, then 'g' to see what it
> > want to do. scroll through and mark 'm' on those you want to keep,
> > which should mark them as manually installed. you may need to '+'
> > them as well, to keep them around. I have not been using aptitude long
> > (having used apt-get exclusively before), but am learning that you can
> > actually get it to do what *you* want with a little fiddling. Then it
> > will generally respect what you want...
>
> So this behaviour could be the result of my having installed some
> applications using 'apt-get install' rather than aptitude, leaving
> aptitude unaware of them being manual rather than automatic
> installs? That would explain things.
absolutely correct.
keep on pluggin' away
A
update messages
On Thu, Dec 28, 2006 at 02:45:56PM -0800, Andrew Sackville-West wrote:
> > Is that last line what is needed to get aptitude back into
> > sync? If not, how is that achieved?
>
> no, it won't. there are a variety of ways to do this. I prefer the
> method below where you watch for problems and fix them as they
> appear. There are several threads on this int he recent archives that
> detail other methods of solving this problem (I think they essentially
> mark *everything* as manual).
Ah, ok. I'll guess I will just have to keep an eye on what aptitude
says it wants to do and intervene if it isn't what I want...
I think it was my initial ignorance of the problems of mixing
apt-get and aptitude that lead to my initial inability to
understand why aptitude wanted to do what it threatened to
do, so I am glad I asked...
> > > > Then I can try running aptitude and hopefully it will have stopped
> > > > crashing and can tell me what else it thinks is left to be done....
> > >
> > > I missed the bit about it crashing. what's happening?
> >
> > It only started happening after I had tried an 'apt-get install aptitude'
> > to upgrade to the latest version (and co-incidentally after I had done
> > the 'apt-get install' of the pgp keyring - so I am not certain which
> > was responsible).
> >
> > What happens now is that after any attempt to issue a 'u' command in
> > aptitude, I get an abort leaving me back in the command line (with a
> > garbled display) and the error message:
> > aptitude: symbol lookup error: aptitude: undefined symbol: _ZN9pkgPolicyD2Ev
>
> yuck. that sounds like a bug. does it do the same from command line?
>
> aptitude update
Not sure, but the 'apt-get upgrade' which just finished seems to
have fixed it - whew!.
I'm still stuck with the big red warning box complaining about the
missing public key for multimedia.org after an update, and I'm still
not clear if this is normal and expected (which would be annoying), or
something specific to me (which would be worrying).
If it is the former, I would have thought it would be better to
just have some way of just not signing packages rather than signing
with a key that can't be checked.
Anway, guess its time to hold my breath and see if the system
still boots after the initial upgrade...
Thanks,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Thu, Dec 28, 2006 at 11:14:23PM +0000, Digby Tarvin wrote:
> On Thu, Dec 28, 2006 at 02:45:56PM -0800, Andrew Sackville-West wrote:
> > > Is that last line what is needed to get aptitude back into
> > > sync? If not, how is that achieved?
> >
> > no, it won't. there are a variety of ways to do this. I prefer the
> > method below where you watch for problems and fix them as they
> > appear. There are several threads on this int he recent archives that
> > detail other methods of solving this problem (I think they essentially
> > mark *everything* as manual).
>
> Ah, ok. I'll guess I will just have to keep an eye on what aptitude
> says it wants to do and intervene if it isn't what I want...
>
> I think it was my initial ignorance of the problems of mixing
> apt-get and aptitude that lead to my initial inability to
> understand why aptitude wanted to do what it threatened to
> do, so I am glad I asked...
seems to be a common problem.
> > > > > Then I can try running aptitude and hopefully it will have stopped
> > > > > crashing and can tell me what else it thinks is left to be done....
> > > >
> > > > I missed the bit about it crashing. what's happening?
> > >
> > > It only started happening after I had tried an 'apt-get install aptitude'
> > > to upgrade to the latest version (and co-incidentally after I had done
> > > the 'apt-get install' of the pgp keyring - so I am not certain which
> > > was responsible).
> > >
> > > What happens now is that after any attempt to issue a 'u' command in
> > > aptitude, I get an abort leaving me back in the command line (with a
> > > garbled display) and the error message:
> > > aptitude: symbol lookup error: aptitude: undefined symbol: _ZN9pkgPolicyD2Ev
> >
> > yuck. that sounds like a bug. does it do the same from command line?
> >
> > aptitude update
>
> Not sure, but the 'apt-get upgrade' which just finished seems to
> have fixed it - whew!.
see Joey's message. yay! one down!
>
> I'm still stuck with the big red warning box complaining about the
> missing public key for multimedia.org after an update, and I'm still
> not clear if this is normal and expected (which would be annoying), or
> something specific to me (which would be worrying).
>
> If it is the former, I would have thought it would be better to
> just have some way of just not signing packages rather than signing
> with a key that can't be checked.
so this is really a minor problem. basically, it prevents you from
knowing for sure that you're getting the right, uncorrupted
packages. you can solve this problem later.
>
> Anway, guess its time to hold my breath and see if the system
> still boots after the initial upgrade...
go baby go!
A
update messages
On Thu, Dec 28, 2006 at 23:14:23 +0000, Digby Tarvin wrote:
[...]
> I'm still stuck with the big red warning box complaining about the
> missing public key for multimedia.org after an update, and I'm still
> not clear if this is normal and expected (which would be annoying), or
> something specific to me (which would be worrying).
>
> If it is the former, I would have thought it would be better to
> just have some way of just not signing packages rather than signing
> with a key that can't be checked.
Marillat's key is not part of the debian-archive-keyring package,
therefore it is not added to apt's trusted keys automatically. You can
download it from the usual public key servers or you can take it from
the debian-keyring package. The latter method is more secure because the
integrity of the debian-keyring package is checked by apt before
installation. Once this package is installed you can run
gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg -a --export 07DC563D1F41B907 | sudo apt-key add -
(The first two options make sure that the key is taken from the Debian
keyring; the rest tells gpg to export the key in ASCII-armored format,
which can be piped to apt-key directly.)
--
Regards,
Florian
--
update messages
On Fri, Dec 29, 2006 at 11:01:00AM +0100, Florian Kulzer wrote:
> On Thu, Dec 28, 2006 at 23:14:23 +0000, Digby Tarvin wrote:
>
> [...]
>
> > I'm still stuck with the big red warning box complaining about the
> > missing public key for multimedia.org after an update, and I'm still
> > not clear if this is normal and expected (which would be annoying), or
> > something specific to me (which would be worrying).
> >
> > If it is the former, I would have thought it would be better to
> > just have some way of just not signing packages rather than signing
> > with a key that can't be checked.
>
> Marillat's key is not part of the debian-archive-keyring package,
> therefore it is not added to apt's trusted keys automatically. You can
> download it from the usual public key servers or you can take it from
> the debian-keyring package. The latter method is more secure because the
> integrity of the debian-keyring package is checked by apt before
> installation. Once this package is installed you can run
>
> gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg -a --export 07DC563D1F41B907 | sudo apt-key add -
>
> (The first two options make sure that the key is taken from the Debian
> keyring; the rest tells gpg to export the key in ASCII-armored format,
> which can be piped to apt-key directly.)
Ah - that did it. I already had the debian-keyring package installed, but
didn't realise that last step was necessary to make the required key
visible to apt...
Thanks,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
> > > > One of the things that bothered me about what aptitude wanted to do
> > > > was that it included several packages it threatened to remove because
> > > > they were 'no longer used'. I don't know how it decided this, as the
> > > > list included packages like 'xv' and 'xearth' which I explicitly
> > > > installed and definately use quite regularly....
> > >
> > > run aptitude in interactive mode and manually mark those packages:
> > >
> > > aptitude
> > >
> > > then 'u' to update, 'U' to mark for upgrade, then 'g' to see what it
> > > want to do. scroll through and mark 'm' on those you want to keep,
> > > which should mark them as manually installed. you may need to '+'
> > > them as well, to keep them around. I have not been using aptitude long
> > > (having used apt-get exclusively before), but am learning that you can
> > > actually get it to do what *you* want with a little fiddling. Then it
> > > will generally respect what you want...
> >
> > So this behaviour could be the result of my having installed some
> > applications using 'apt-get install' rather than aptitude, leaving
> > aptitude unaware of them being manual rather than automatic
> > installs? That would explain things.
>
> absolutely correct.
>
> keep on pluggin' away
It seems I am not out of the woods yet. I just tried executing
apt-get install libx11-dev
which is the package I needed to install in the first place when I
got distracted onto upgrading my system..
Amoungst the actions it threatened to do was:
The following packages will be REMOVED
gnome gnome-core gnome-desktop-environment gnome-doc-utils gnome-office
lbxproxy libapache2-mod-php4 libapache2-mod-python proxymngr python-libxml2
python-newt python2.3-imaging-tk python2.3-tk skencil sketch totem
x-window-system xdm xearth xfs xfwp xlibs xlibs-data xlockmore-gl xprint
xserver-common xv xvfb yelp
I was again disturbed by the threatened removal of some applications I
know I regularly use (such as xearth, xv and totem), so I did some
digging starting with 'xearth', and it seems that package has been
removed from testing (but not stable or unstable) and the version I
had installed (1.1-10.1) requires xbase < 3.3.2.3a-2 which presumably
conflicts with other packages which are required for for the libx11-dev
package..
The page which I found indicating the removal of xearth from testing is
http://packages.qa.debian.org/x/xearth.html
but it doesn't give any explanation of why, and I am not sure where to
look next.
Should I be fetching the unstable version? Or would it be better to
just install from source and forget the debian packages for this
application?
Not sure about the other packages - totem for example appears to
have a newer version available, so I don't understand why the threat
to delete it.
And xv I havn't found at all in the packages database :-/
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Fri, Dec 29, 2006 at 01:04:24AM +0000, Digby Tarvin wrote:
> > > > > One of the things that bothered me about what aptitude wanted to do
> > > > > was that it included several packages it threatened to remove because
> > > > > they were 'no longer used'. I don't know how it decided this, as the
> > > > > list included packages like 'xv' and 'xearth' which I explicitly
> > > > > installed and definately use quite regularly....
> > > >
> > > > run aptitude in interactive mode and manually mark those packages:
> > > >
> > > > aptitude
> > > >
> > > > then 'u' to update, 'U' to mark for upgrade, then 'g' to see what it
> > > > want to do. scroll through and mark 'm' on those you want to keep,
> > > > which should mark them as manually installed. you may need to '+'
> > > > them as well, to keep them around. I have not been using aptitude long
> > > > (having used apt-get exclusively before), but am learning that you can
> > > > actually get it to do what *you* want with a little fiddling. Then it
> > > > will generally respect what you want...
> > >
> > > So this behaviour could be the result of my having installed some
> > > applications using 'apt-get install' rather than aptitude, leaving
> > > aptitude unaware of them being manual rather than automatic
> > > installs? That would explain things.
> >
> > absolutely correct.
> >
> > keep on pluggin' away
>
> It seems I am not out of the woods yet. I just tried executing
> apt-get install libx11-dev
> which is the package I needed to install in the first place when I
> got distracted onto upgrading my system..
was this before or after a successful upgrade?
>
> Amoungst the actions it threatened to do was:
> The following packages will be REMOVED
> gnome gnome-core gnome-desktop-environment gnome-doc-utils gnome-office
> lbxproxy libapache2-mod-php4 libapache2-mod-python proxymngr python-libxml2
> python-newt python2.3-imaging-tk python2.3-tk skencil sketch totem
> x-window-system xdm xearth xfs xfwp xlibs xlibs-data xlockmore-gl xprint
> xserver-common xv xvfb yelp
>
you're losing all of X here. that's not good. are you running xorg or
xfree86 still? there was a transition, to xorg, did you miss it? maybe
the transition packages have already been pulled? you may have to go
in and mark xorg for installation.
> I was again disturbed by the threatened removal of some applications I
> know I regularly use (such as xearth, xv and totem), so I did some
> digging starting with 'xearth', and it seems that package has been
> removed from testing (but not stable or unstable) and the version I
> had installed (1.1-10.1) requires xbase < 3.3.2.3a-2 which presumably
> conflicts with other packages which are required for for the libx11-dev
> package..
>
> The page which I found indicating the removal of xearth from testing is
> http://packages.qa.debian.org/x/xearth.html
> but it doesn't give any explanation of why, and I am not sure where to
> look next.
>
> Should I be fetching the unstable version? Or would it be better to
> just install from source and forget the debian packages for this
> application?
well, its probably got bugs that prevent it from being included in
etch. With etch frozen, I imagine you're sol for using it when etch
goes stable, so you'll either have to backport it from sid or install
from source. Either way, you'll probably have to let that one go.
>
> Not sure about the other packages - totem for example appears to
> have a newer version available, so I don't understand why the threat
> to delete it.
I believe totem depends on gnome which you are losing altogether
above.
>
> And xv I havn't found at all in the packages database :-/
I can only vaguely recall xv. what is it?
A
update messages
On Thu, Dec 28, 2006 at 05:28:55PM -0800, Andrew Sackville-West wrote:
> > It seems I am not out of the woods yet. I just tried executing
> > apt-get install libx11-dev
> > which is the package I needed to install in the first place when I
> > got distracted onto upgrading my system..
>
> was this before or after a successful upgrade?
After a successful upgrade, but I haven't yet attempted
a 'dist-upgrade'..
> > Amoungst the actions it threatened to do was:
> > The following packages will be REMOVED
> > gnome gnome-core gnome-desktop-environment gnome-doc-utils gnome-office
> > lbxproxy libapache2-mod-php4 libapache2-mod-python proxymngr python-libxml2
> > python-newt python2.3-imaging-tk python2.3-tk skencil sketch totem
> > x-window-system xdm xearth xfs xfwp xlibs xlibs-data xlockmore-gl xprint
> > xserver-common xv xvfb yelp
> >
>
> you're losing all of X here. that's not good. are you running xorg or
> xfree86 still? there was a transition, to xorg, did you miss it? maybe
> the transition packages have already been pulled? you may have to go
> in and mark xorg for installation.
aptitude shows:
xserver-xorg 6.9.0.dfsg.1-6
as being installed, and isn't one of the packages listed for removal
(but is listed for upgrade)
There is quite a list of new packages to be installed - perhaps too
much to post to the list. Here is a sample:
The following NEW packages will be installed
cdrdao epiphany-browser evolution-common evolution-data-server-common
gnome-cards-data gnome-media-common gtk2-engines industrial-cursor-theme
libavcodec0d libcamel1.2-8 libdbus-1-3 libdrm2 libecal1.2-6
libedata-cal1.2-5 libedataserver1.2-7 libegroupwise1.2-10
libexchange-storage1.2-1 libfontenc1 libglu1-mesa libgnome-media0
libgnome-window-settings1 libgnutls13 libgtop2-7 libgtop2-common
libnautilus-burn3 libnm-glib0 libpisock9 libpostproc0d libtasn1-3
libtotem-plparser1 libx11-data libx11-dev libxau-dev libxdmcp-dev
libxext-dev libxfont1 python-central python-gnome2-desktop python-pyorbit
python-support type-handling wodim x11proto-core-dev x11proto-input-dev
x11proto-kb-dev x11proto-xext-dev xbitmaps xfonts-encodings xfonts-utils
xkb-data xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev
xserver-xorg-input-kbd xserver-xorg-input-mouse xserver-xorg-input-synaptics
xserver-xorg-input-wacom xserver-xorg-video-all xserver-xorg-video-apm
> > I was again disturbed by the threatened removal of some applications I
> > know I regularly use (such as xearth, xv and totem), so I did some
> > digging starting with 'xearth', and it seems that package has been
> > removed from testing (but not stable or unstable) and the version I
> > had installed (1.1-10.1) requires xbase < 3.3.2.3a-2 which presumably
> > conflicts with other packages which are required for for the libx11-dev
> > package..
> >
> > The page which I found indicating the removal of xearth from testing is
> > http://packages.qa.debian.org/x/xearth.html
> > but it doesn't give any explanation of why, and I am not sure where to
> > look next.
> >
> > Should I be fetching the unstable version? Or would it be better to
> > just install from source and forget the debian packages for this
> > application?
>
> well, its probably got bugs that prevent it from being included in
> etch. With etch frozen, I imagine you're sol for using it when etch
> goes stable, so you'll either have to backport it from sid or install
> from source. Either way, you'll probably have to let that one go.
I suppose my own build from source with static libraries in /usr/local/bin
should prevent future problems with it for some time.
> > Not sure about the other packages - totem for example appears to
> > have a newer version available, so I don't understand why the threat
> > to delete it.
>
> I believe totem depends on gnome which you are losing altogether
> above.
I don't really understand what is happening with gnome. I do seem
to be getting some gnome related packages added and upgraded...
> >
> > And xv I havn't found at all in the packages database :-/
>
> I can only vaguely recall xv. what is it?
John Bradley's image viewer program. Probably frowned upon
by Debian for being non-free, but I registered my copy years
ago so I feel entitled to keep using it ;)
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Fri, Dec 29, 2006 at 02:23:27AM +0000, Digby Tarvin wrote:
> On Thu, Dec 28, 2006 at 05:28:55PM -0800, Andrew Sackville-West wrote:
> > > It seems I am not out of the woods yet. I just tried executing
> > > apt-get install libx11-dev
> > > which is the package I needed to install in the first place when I
> > > got distracted onto upgrading my system..
> >
> > was this before or after a successful upgrade?
>
> After a successful upgrade, but I haven't yet attempted
> a 'dist-upgrade'..
you might do that and see what it says.
>
> > > Amoungst the actions it threatened to do was:
> > > The following packages will be REMOVED
> > > gnome gnome-core gnome-desktop-environment gnome-doc-utils gnome-office
> > > lbxproxy libapache2-mod-php4 libapache2-mod-python proxymngr python-libxml2
> > > python-newt python2.3-imaging-tk python2.3-tk skencil sketch totem
> > > x-window-system xdm xearth xfs xfwp xlibs xlibs-data xlockmore-gl xprint
> > > xserver-common xv xvfb yelp
> > >
> >
> > you're losing all of X here. that's not good. are you running xorg or
> > xfree86 still? there was a transition, to xorg, did you miss it? maybe
> > the transition packages have already been pulled? you may have to go
> > in and mark xorg for installation.
>
> aptitude shows:
> xserver-xorg 6.9.0.dfsg.1-6
> as being installed, and isn't one of the packages listed for removal
> (but is listed for upgrade)
>
xorg is trying to go to 7.x, this is a big move, IIRC.
> There is quite a list of new packages to be installed - perhaps too
> much to post to the list. Here is a sample:
>
> The following NEW packages will be installed
> cdrdao epiphany-browser evolution-common evolution-data-server-common
> gnome-cards-data gnome-media-common gtk2-engines industrial-cursor-theme
> libavcodec0d libcamel1.2-8 libdbus-1-3 libdrm2 libecal1.2-6
> libedata-cal1.2-5 libedataserver1.2-7 libegroupwise1.2-10
> libexchange-storage1.2-1 libfontenc1 libglu1-mesa libgnome-media0
> libgnome-window-settings1 libgnutls13 libgtop2-7 libgtop2-common
> libnautilus-burn3 libnm-glib0 libpisock9 libpostproc0d libtasn1-3
> libtotem-plparser1 libx11-data libx11-dev libxau-dev libxdmcp-dev
> libxext-dev libxfont1 python-central python-gnome2-desktop python-pyorbit
> python-support type-handling wodim x11proto-core-dev x11proto-input-dev
> x11proto-kb-dev x11proto-xext-dev xbitmaps xfonts-encodings xfonts-utils
> xkb-data xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev
> xserver-xorg-input-kbd xserver-xorg-input-mouse xserver-xorg-input-synaptics
> xserver-xorg-input-wacom xserver-xorg-video-all xserver-xorg-video-apm
>
>
its trying to install xorg, but to that it has to remove the older
x. That means's its probably going to try to pull all its dependent
packages out with it.
I suggest you go back into aptitude insteractive mode and try to
manually sort this out. -OR- you could bite the bullet and let it do
what it wants, and then reinstall all of gnome again when its done.
> > > I was again disturbed by the threatened removal of some applications I
> > > know I regularly use (such as xearth, xv and totem), so I did some
> > > digging starting with 'xearth', and it seems that package has been
> > > removed from testing (but not stable or unstable) and the version I
> > > had installed (1.1-10.1) requires xbase < 3.3.2.3a-2 which presumably
> > > conflicts with other packages which are required for for the libx11-dev
> > > package..
> > >
> > > The page which I found indicating the removal of xearth from testing is
> > > http://packages.qa.debian.org/x/xearth.html
> > > but it doesn't give any explanation of why, and I am not sure where to
> > > look next.
> > >
> > > Should I be fetching the unstable version? Or would it be better to
> > > just install from source and forget the debian packages for this
> > > application?
> >
> > well, its probably got bugs that prevent it from being included in
> > etch. With etch frozen, I imagine you're sol for using it when etch
> > goes stable, so you'll either have to backport it from sid or install
> > from source. Either way, you'll probably have to let that one go.
>
> I suppose my own build from source with static libraries in /usr/local/bin
> should prevent future problems with it for some time.
>
> > > Not sure about the other packages - totem for example appears to
> > > have a newer version available, so I don't understand why the threat
> > > to delete it.
> >
> > I believe totem depends on gnome which you are losing altogether
> > above.
>
> I don't really understand what is happening with gnome. I do seem
> to be getting some gnome related packages added and upgraded...
I think its because of the xorg transition you're seeing this
happen. go into interactive aptitude and move up the chain to some
gnome metapackage and try to '+' it.
>
> > >
> > > And xv I havn't found at all in the packages database :-/
> >
> > I can only vaguely recall xv. what is it?
>
> John Bradley's image viewer program. Probably frowned upon
> by Debian for being non-free, but I registered my copy years
> ago so I feel entitled to keep using it ;)
oh yeah. not in deb.
A
update messages
On Thu, Dec 28, 2006 at 07:50:34PM -0800, Andrew Sackville-West wrote:
> > > was this before or after a successful upgrade?
> >
> > After a successful upgrade, but I haven't yet attempted
> > a 'dist-upgrade'..
>
> you might do that and see what it says.
I was trying to find a way to ease into the dist-upgrade
by explicitly upgrading a few of the more problematic
packages explicitly...
But it is looking like I might just have to let it run and
see what happens.
I'm doing a full backup now in preparation, so it will probably
be tomorrow before that and the dist-upgrade attempt are all
done...
Thanks for the advice. I'll let you know what the result it.
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Thu, Dec 28, 2006 at 07:50:34PM -0800, Andrew Sackville-West wrote:
> On Fri, Dec 29, 2006 at 02:23:27AM +0000, Digby Tarvin wrote:
> > On Thu, Dec 28, 2006 at 05:28:55PM -0800, Andrew Sackville-West wrote:
> >
> > > >
> > > > And xv I havn't found at all in the packages database :-/
> > >
> > > I can only vaguely recall xv. what is it?
> >
> > John Bradley's image viewer program. Probably frowned upon
> > by Debian for being non-free, but I registered my copy years
> > ago so I feel entitled to keep using it ;)
>
> oh yeah. not in deb.
Then why is Debian trying to remove it if ti isn't a package?
Could it be trying to remove another thing called xv, which I think is
some X thing relating to video?
-- hendrik
--
update messages
On Sat, Dec 30, 2006 at 03:41:31PM -0500, wrote:
> On Thu, Dec 28, 2006 at 07:50:34PM -0800, Andrew Sackville-West wrote:
> > On Fri, Dec 29, 2006 at 02:23:27AM +0000, Digby Tarvin wrote:
> > > On Thu, Dec 28, 2006 at 05:28:55PM -0800, Andrew Sackville-West wrote:
> > >
> > > > >
> > > > > And xv I havn't found at all in the packages database :-/
> > > >
> > > > I can only vaguely recall xv. what is it?
> > >
> > > John Bradley's image viewer program. Probably frowned upon
> > > by Debian for being non-free, but I registered my copy years
> > > ago so I feel entitled to keep using it ;)
> >
> > oh yeah. not in deb.
>
> Then why is Debian trying to remove it if ti isn't a package?
> Could it be trying to remove another thing called xv, which I think is
> some X thing relating to video?
>
> -- hendrik
I think I may have confused matters by not knowing exactly what
the 'standard' Debian terminology is.
To Clarify:
1. John Bradley's xv program was in the debian archive for Etch
when I installed it back in April:
/var/cache/apt/archives/xv_3.10a-1duo+etch1_i386.deb
2. It is not there now.
3. When I referred to it not being in the 'package database' I meant
that I didn't find any mention of its existance (or removal) in
http://packages.qa.debian.org/common/index.html
which is where I had found messages referring to the removal
of xearth.
So what puzzles me is why it is no longer in 'non-free', and if
it was removed because of some objection to the licensing terms,
surely there should be something documenting this??
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Sat, 2006-12-30 at 22:03 +0000, Digby Tarvin wrote:
> 1. John Bradley's xv program was in the debian archive for Etch
> when I installed it back in April:
> /var/cache/apt/archives/xv_3.10a-1duo+etch1_i386.deb
>
> 2. It is not there now.
>
> 3. When I referred to it not being in the 'package database' I meant
> that I didn't find any mention of its existance (or removal) in
> http://packages.qa.debian.org/common/index.html
> which is where I had found messages referring to the removal
> of xearth.
>
> So what puzzles me is why it is no longer in 'non-free', and if
> it was removed because of some objection to the licensing terms,
> surely there should be something documenting this??
Are you quite sure it was in the official Debian archives? I can only
find it in the non-free section on debian-unofficial.org, and the
package name seems to match.
http://ftp.debian-unofficial.org/debian/pool/non-free/x/xv/
I also found this old bug from 2001, dealing with removing xv from the
archive as distribution of modified binaries is prohibited.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98215
--
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22
update messages
Digby Tarvin wrote:
> So what puzzles me is why it is no longer in 'non-free', and if
> it was removed because of some objection to the licensing terms,
> surely there should be something documenting this?
It may have been removed simply because no one was willing to maintain it
any more. That often happens when a non-free package ceases to provide any
functionality not available in a Free package.
--
John Hasler
--
update messages
On Sat, Dec 30, 2006 at 04:59:40PM -0600, John Hasler wrote:
> Digby Tarvin wrote:
> > So what puzzles me is why it is no longer in 'non-free', and if
> > it was removed because of some objection to the licensing terms,
> > surely there should be something documenting this?
>
> It may have been removed simply because no one was willing to maintain it
> any more. That often happens when a non-free package ceases to provide any
> functionality not available in a Free package.
>
> --
> John Hasler
Its not so much the removal of a package that disturbs me - it is
the apparent lack of warning or explanation.
It makes me rather reluctant to upgrade if some package that I have
come to rely on might unexpectedly disappear - perhaps unnoticed
until it is urgently needed...
Another package I just noticed is missing since my dist-upgrade is
xlockmore. I searched packages.qa.debian.org and all I found was
what looks like an automated logging of the fact that the package
is gone - no reason or dialogue that I can see:
http://packages.qa.debian.org/x/xlockmore/news/20061119T233918Z.html
Is there some mailing list I should be on to receive warnings about
packages being considered for removal (assuming the disappearance
was intentional)?
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
Missing packages (was update messages)
Further to the loss of 'xv', 'xearth' and 'xlock' after my recent
'apt-get dist-upgrade' of my etch system....
I tried adding
deb http://ftp.debian-unofficial.org/debian etch main contrib non-free restricted
To my '/etc/apt/sources.list', and this does give me an 'xv' package to
try to install. However when I attempt to do so I get:
fujitsu:/etc/apt# apt-get install xv
Reading package lists... Done
Building dependency tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:
The following packages have unmet dependencies.
xv: Depends: libx11-6 but it is not going to be installed
E: Broken packages
Which looks reasonable enough if there is an unsatisfied dependency,
but
fujitsu:/etc/apt# apt-get install libx11-6
Reading package lists... Done
Building dependency tree... Done
libx11-6 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.
Which leaves me thinking that apt-get hasn't really provided a
sufficient explanation of why the installation couldn't be
completed?
Could it be that the message is just misleading and it really meant
that libx11-6 is an incompatable version rather than simply not
installed??
If it is a library version problem, then I assume the best
solution is to find and install a debian source package for
this application?
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
Missing packages (was update messages)
On Sun, Dec 31, 2006 at 06:01:39PM +0000, Digby Tarvin wrote:
> Further to the loss of 'xv', 'xearth' and 'xlock' after my recent
> 'apt-get dist-upgrade' of my etch system....
>
> I tried adding
> deb http://ftp.debian-unofficial.org/debian etch main contrib non-free restricted
>
> To my '/etc/apt/sources.list', and this does give me an 'xv' package to
> try to install. However when I attempt to do so I get:
> fujitsu:/etc/apt# apt-get install xv
> Reading package lists... Done
> Building dependency tree... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
>
> Since you only requested a single operation it is extremely likely that
> the package is simply not installable and a bug report against
> that package should be filed.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies.
> xv: Depends: libx11-6 but it is not going to be installed
> E: Broken packages
>
> Which looks reasonable enough if there is an unsatisfied dependency,
> but
> fujitsu:/etc/apt# apt-get install libx11-6
> Reading package lists... Done
> Building dependency tree... Done
> libx11-6 is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.
>
> Which leaves me thinking that apt-get hasn't really provided a
> sufficient explanation of why the installation couldn't be
> completed?
well again, this *is* a package outside the official repositories so...
>
> Could it be that the message is just misleading and it really meant
> that libx11-6 is an incompatable version rather than simply not
> installed??
probably. use apt-cache show xv | grep Depends
and compare it to apt-cache policy libx11-6 for definitive
information.
>
> If it is a library version problem, then I assume the best
> solution is to find and install a debian source package for
> this application?
if you can get source, then that's prbably you're best bet.
A
update messages
On Sun, Dec 31, 2006 at 05:31:59PM +0000, Digby Tarvin wrote:
> On Sat, Dec 30, 2006 at 04:59:40PM -0600, John Hasler wrote:
> > Digby Tarvin wrote:
> > > So what puzzles me is why it is no longer in 'non-free', and if
> > > it was removed because of some objection to the licensing terms,
> > > surely there should be something documenting this?
> >
> > It may have been removed simply because no one was willing to maintain it
> > any more. That often happens when a non-free package ceases to provide any
> > functionality not available in a Free package.
> >
> > --
> > John Hasler
>
> Its not so much the removal of a package that disturbs me - it is
> the apparent lack of warning or explanation.
well, since it was removed from the official repositories in 2001:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98215
it is very unlikely that you successfully installed it from official
repositories in 2006. you obviously installed it from another
source. so technically, it was not "Removed without notice". You have
simply lost track of where it came from ;-P
>
> It makes me rather reluctant to upgrade if some package that I have
> come to rely on might unexpectedly disappear - perhaps unnoticed
> until it is urgently needed...
that is the problem with using packages outside the official debian
repositories. You got caught because a non-official package you were
using has gotten out of sync with the official libraries that support
it. best bet is to file a bug report with the group that is supplying
the package. or use the source, luke.
>
> Another package I just noticed is missing since my dist-upgrade is
> xlockmore. I searched packages.qa.debian.org and all I found was
> what looks like an automated logging of the fact that the package
> is gone - no reason or dialogue that I can see:
> http://packages.qa.debian.org/x/xlockmore/news/20061119T233918Z.html
>
> Is there some mailing list I should be on to receive warnings about
> packages being considered for removal (assuming the disappearance
> was intentional)?
probably. or you can subscribe to DWN which will list orphan packages
and removed packages as they appear. the W is currently a misnomer,
but we are grateful for the issues we get...
A
xv resolved (was update messages)
On Sun, Dec 31, 2006 at 11:55:38AM -0800, Andrew Sackville-West wrote:
> > Its not so much the removal of a package that disturbs me - it is
> > the apparent lack of warning or explanation.
>
> well, since it was removed from the official repositories in 2001:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98215
>
> it is very unlikely that you successfully installed it from official
> repositories in 2006. you obviously installed it from another
> source. so technically, it was not "Removed without notice". You have
> simply lost track of where it came from ;-P
I don't remember doing it, but it looks like I must have done, so
mea culpa on that one...
Mind you - it still looks like xlockmore and xearth disappeared from
the official packages with only an automated acknowledgement that
they are gone rather than an explanation:
http://packages.qa.debian.org/x/xlockmore/news/20061119T233918Z.html
http://packages.qa.debian.org/x/xearth/news/20060610T210838Z.html
And a were it not for those examples of things that had disappeared
from the official packages I probably would have been less quick
to jump to conclusions about xv ;)
> > It makes me rather reluctant to upgrade if some package that I have
> > come to rely on might unexpectedly disappear - perhaps unnoticed
> > until it is urgently needed...
>
> that is the problem with using packages outside the official debian
> repositories. You got caught because a non-official package you were
> using has gotten out of sync with the official libraries that support
> it. best bet is to file a bug report with the group that is supplying
> the package. or use the source, luke.
Don't want to sound like I am just complaining without offering anything
constructive, so here is the solution I have found to obtaining xv for
the current Etch system:
1. Visit http://bok.fas.harvard.edu/debian/xv/index.html and
obtain:
xv-3.10a.tar.gz
xv-3.10a-jumbo-patches-20050501.tar.gz
xv-3.10a-jumbo20050501-1.diff.gz
2. Make sure the following packages are installed
xlibs-dev, dpkg-dev, libc6-dev, libtiff4-dev, libjpeg62-dev
libpng-dev, zlib1g-dev, debhelper, libxt-dev
3. Follow the instructions on the URL as follows:
tar -xvzf xv-3.10a.tar.gz
mv xv-3.10a xv-3.10a-jumbo20050501-1
cd xv-3.10a-jumbo20050501-1
patch -p1 < ../xv-3.10a-jumbo-fix-patch-20050410.txt
patch -p1 < ../xv-3.10a-jumbo-enh-patch-20050501.txt
patch -p1 < ../xv-3.10a-jumbo20050501-1.diff
chmod 755 debian/rules
dpkg-buildpackage -rfakeroot -uc -b
cd ..
sudo dpkg -i xv_3.10a-jumbo20050501-1_i386.deb
sudo dpkg -i xv-doc_3.10a-jumbo20050501-1_all.deb
It would be nice if that procedure could be bundled up into a debian
source package if my understanding is correct and the problem with xv
was that the licence prohibits distribution of modified binaries.
Perhaps it is possible - I don't know enough about debian packages
to know for sure.
The good thing about that is the entire dist-upgrade requirement
stemmed from my needing the X development libraries, and at least
this exercise has verified my ability to build X applications now :)
Now to see if I can find the other two applications that I lost in
the process of the upgrade...
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
xv resolved (was update messages)
On Sun, 2006-12-31 at 21:46 +0000, Digby Tarvin wrote:
> Mind you - it still looks like xlockmore and xearth disappeared from
> the official packages with only an automated acknowledgement that
> they are gone rather than an explanation:
> http://packages.qa.debian.org/x/xlockmore/news/20061119T233918Z.html
> http://packages.qa.debian.org/x/xearth/news/20060610T210838Z.html
>
> And a were it not for those examples of things that had disappeared
> from the official packages I probably would have been less quick
> to jump to conclusions about xv ;)
xlockmore is only removed from testing, not from the entire Debian
archive. http://packages.qa.debian.org/x/xlockmore.html (See the section
Problems and the "Check why" link).
xearth was removed from Debian as it was orphaned, non-free, and
succeeded by xplanet. Once again, a link from packages.qa.debian.org
reveals this information.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400948
By the way, I did find this link,
http://ftp-master.debian.org/removals.txt
it seems to list all removed packages with corresponding bug numbers.
Isn't this what you were looking for?
--
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22
update messages
On Sun, Dec 31, 2006 at 05:31:59PM +0000, Digby Tarvin wrote:
> It makes me rather reluctant to upgrade if some package that I have
> come to rely on might unexpectedly disappear - perhaps unnoticed
> until it is urgently needed...
Not to belabor the obvious, but no one seems to have pointed this out in
the remainder of the thread...
If you're using stable, there's no chance that a package is going to
disappear from your box unless you deliberately remove it, or deliberately
install something that conflicts with it and forces it off. See the
definition of a stable distribution....
If you're using testing or unstable, implicit in that use is that you have
a modicum of clue. If you have such clue, exactly how is this package
going to disappear? You're actually going to be paying attention to what
dselect, or apt-get, or aptitude (shudder), or synaptic, or whatever, tell
you when you attempt to upgrade, and you won't give them permission to
remove it.
Aren't you?
> Another package I just noticed is missing since my dist-upgrade is
> xlockmore.
And there's the answer. Obviously not. Noticed *since* the dist-upgrade?
Why didn't you notice *before* the dist-upgrade? It's not like you weren't
told. For that matter, why did you give explicit permission to remove
packages by using dist-upgrade in the first place?
--
Marc Wilson | The longest part of the journey is said to be the
| passing of the gate. -- Marcus Terentius Varro
--
update messages
On Sun, Dec 31, 2006 at 05:05:27PM -0800, Marc Wilson wrote:
> On Sun, Dec 31, 2006 at 05:31:59PM +0000, Digby Tarvin wrote:
> > It makes me rather reluctant to upgrade if some package that I have
> > come to rely on might unexpectedly disappear - perhaps unnoticed
> > until it is urgently needed...
>
> Not to belabor the obvious, but no one seems to have pointed this out in
> the remainder of the thread...
>
> If you're using stable, there's no chance that a package is going to
> disappear from your box unless you deliberately remove it, or deliberately
> install something that conflicts with it and forces it off. See the
> definition of a stable distribution....
>
> If you're using testing or unstable, implicit in that use is that you have
> a modicum of clue. If you have such clue, exactly how is this package
> going to disappear? You're actually going to be paying attention to what
> dselect, or apt-get, or aptitude (shudder), or synaptic, or whatever, tell
> you when you attempt to upgrade, and you won't give them permission to
> remove it.
>
> Aren't you?
Actually yes, it was covered earlier in the thread, but to re-iterate:
I agree it would have been better to start with stable having had no
previous Debian experience, and I did attempt to, but it wouldn't install
on my Fujitsu notebook.
The Debian release system is very good in theory, but the rate at
which hardware changes means that stable if often not usable on
new hardware :(
However even if I had been able to run on stable initially, at
some point the disincentive to upgrade would have become relevent
because upgrading would have involved moving to a new stable release
(Etch), and at that point things could apparently disappear.
> > Another package I just noticed is missing since my dist-upgrade is
> > xlockmore.
>
> And there's the answer. Obviously not. Noticed *since* the dist-upgrade?
> Why didn't you notice *before* the dist-upgrade? It's not like you weren't
> told. For that matter, why did you give explicit permission to remove
> packages by using dist-upgrade in the first place?
Again, it was covered earlier - but the upgrade was because I *needed*
to install the X development libraries, and the only was to satisfy
the dependicies after exploring all suggested alternatives was to
go with the dist-upgrade and accepting the fact that I was going
to lose some packages that I needed. (apparently xorg had undergone
a significant modularity change since my last upgrade).
As to xlockmore - I described the situation badly. Yes, xlockmore
was listed as one of the packages that had to go, but I didn't
recognise it as one that I routinely used. It was afterwards that I
noticed that xlock was gone and then worked out that it was part of
the xlockmore package (rather than an alternative package as I had
mistakenly assumed).
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Sat, Dec 30, 2006 at 11:37:01PM +0100, Sven Arvidsson wrote:
> > So what puzzles me is why it is no longer in 'non-free', and if
> > it was removed because of some objection to the licensing terms,
> > surely there should be something documenting this??
>
> Are you quite sure it was in the official Debian archives? I can only
> find it in the non-free section on debian-unofficial.org, and the
> package name seems to match.
> http://ftp.debian-unofficial.org/debian/pool/non-free/x/xv/
>
> I also found this old bug from 2001, dealing with removing xv from the
> archive as distribution of modified binaries is prohibited.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98215
If so then I forgot to make a note of it, but I suppose in all the
excitement of the initial install that is possible.
Is there any way to check the origin of an deb archive in my
/var/cache/apt/archives?
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages
On Sun, Dec 31, 2006 at 00:17:29 +0000, Digby Tarvin wrote:
> On Sat, Dec 30, 2006 at 11:37:01PM +0100, Sven Arvidsson wrote:
> > > So what puzzles me is why it is no longer in 'non-free', and if
> > > it was removed because of some objection to the licensing terms,
> > > surely there should be something documenting this??
> >
> > Are you quite sure it was in the official Debian archives? I can only
> > find it in the non-free section on debian-unofficial.org, and the
> > package name seems to match.
> > http://ftp.debian-unofficial.org/debian/pool/non-free/x/xv/
> >
> > I also found this old bug from 2001, dealing with removing xv from the
> > archive as distribution of modified binaries is prohibited.
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98215
>
> If so then I forgot to make a note of it, but I suppose in all the
> excitement of the initial install that is possible.
>
> Is there any way to check the origin of an deb archive in my
> /var/cache/apt/archives?
You could try
dpkg-deb --info /var/cache/apt/archives/.deb
As far as I know there is no standard field to denote the origin of a
.deb file, but maybe you will find a clue somewhere, e.g. in the
"Maintainer" field.
You could also check if you can find the .deb on snapshot.debian.net or
with a google search.
--
Regards,
Florian
--
update messages
On Sun, Dec 31, 2006 at 11:56:07AM +0100, Florian Kulzer wrote:
> > Is there any way to check the origin of an deb archive in my
> > /var/cache/apt/archives?
>
> You could try
>
> dpkg-deb --info /var/cache/apt/archives/.deb
>
> As far as I know there is no standard field to denote the origin of a
> .deb file, but maybe you will find a clue somewhere, e.g. in the
> "Maintainer" field.
Here is what it says:
new debian package, version 2.0.
size 471666 bytes: control archive= 1534 bytes.
752 bytes, 15 lines control
1300 bytes, 22 lines md5sums
351 bytes, 12 lines * postinst #!/bin/sh
293 bytes, 8 lines * postrm #!/bin/sh
Package: xv
Version: 3.10a-1duo+etch1
Section: non-free/graphics
Priority: optional
Architecture: i386
Depends: libc6 (>= 2.3.5-1), libjpeg62, libpng12-0 (>= 1.2.8rel), libtiff4, libx11-6, zlib1g (>= 1:1.2.1)
Suggests: xv-doc, gs
Installed-Size: 1156
Maintainer: Fabian Greffrath
Description: An image viewer and manipulator for the X Window System
xv is an interactive image manipulation program for the X Window System. It
can operate on images in the GIF, JPEG, TIFF, PBM, PGM, PPM, XPM, X11 bitmap,
Sun Rasterfile, Targa, RLE, RGB, BMP, PCX, FITS, and PM formats on all known
types of X displays. It can generate PostScript files, and if you have
ghostscript installed on your machine, it can also display them.
Looks consistent with Debian 'non-free' to me.
> You could also check if you can find the .deb on snapshot.debian.net or
> with a google search.
I have tried google, and whilest I have found the same deb package
that I have (or derivatives) elsewhere, I haven't found any explanation
as to why its gone - though I did find one site mirroring it because
'debian hates XV'...??
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
update messages