Have you tried "dpkg --remove apt-listchanges" or
"dpkg --purge apt-listchanges"?
Daniel
--
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
| "You see, I've already stolen the spork of wisdom |
|and the spork of courage.. t
"David A. Greene" <[EMAIL PROTECTED]> writes:
> guarantee it will work because it seems as though apt thinks
> apt-listchanges is still installed.
This is a matter of configuration files; try purging apt-listchanges,
and if that doesn't work remove /etc/apt/apt.conf.d/20listchanges
yourself.
--
On Fri, Jun 20, 2003 at 10:27:14AM -0400, David A. Greene wrote:
> Matt Zimmerman wrote:
>
> >If you had wanted to find out the answer before sending this to
> >debian-devel, you would not have had to look very far.
> >bugs.debian.org/python-apt has the answer three times over.
> >
> >http://bugs
Matt Zimmerman wrote:
If you had wanted to find out the answer before sending this to
debian-devel, you would not have had to look very far.
bugs.debian.org/python-apt has the answer three times over.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193566
That's not particularly helpful. Consider
On Tuesday, Jun 17, 2003, at 10:50 US/Eastern, Bernd Eckenfels wrote:
On Tue, Jun 17, 2003 at 10:22:54AM -0400, Anthony DeRobertis wrote:
Yep. That's the point of my proposal. They would be. When you changed
a
package to use the new c103 (or whatever the next ABI is), you'd
change
the library dep
On Tue, Jun 17, 2003 at 10:22:54AM -0400, Anthony DeRobertis wrote:
> Yep. That's the point of my proposal. They would be. When you changed a
> package to use the new c103 (or whatever the next ABI is), you'd change
> the library dependencies to the c103 versions.
This will work, but it will sto
On Monday, Jun 16, 2003, at 16:43 US/Eastern, Bernd Eckenfels wrote:
On Mon, Jun 16, 2003 at 03:46:13PM -0400, Anthony DeRobertis wrote:
Now, if we changed sarge to use g++-c102 (as I briefly suggested),
would that prevent this problem in sarge+1 or sarge+2 or whenever the
ABI changes again?
no, be
On Mon, Jun 16, 2003 at 03:46:13PM -0400, Anthony DeRobertis wrote:
> Now, if we changed sarge to use g++-c102 (as I briefly suggested),
> would that prevent this problem in sarge+1 or sarge+2 or whenever the
> ABI changes again?
no, because we WANT the packages beeing build with the new abi. We
On Monday, Jun 16, 2003, at 11:04 US/Eastern, Matt Zimmerman wrote:
Which, of course, does not help with the situation he originally
reported
(building a woody package on testing with a newer compiler than was
originally used). Time travel is still required there. :-)
Agreed. To fix Woody require
On Monday, Jun 16, 2003, at 14:59 US/Eastern, Bernd Eckenfels wrote:
it works in this case if you build all the packages your package
depends on,
like the build is doing, because in that case apt wopuld habe been new
abi,
too.
Yeah, but then again, its quite superfluous in that situation, too.
D
On Monday, Jun 16, 2003, at 02:50 US/Eastern, Andreas Metzler wrote:
Build-Depends: g++ (>= 3:3.2.2-0)
Many transitioned packages use(d) this to guarantee that the correct
compiler was used.
That doesn't guarantee the correct compiler. It could, for example, use
gcc 3.4 which could have yet anothe
On Mon, Jun 16, 2003 at 11:04:17AM -0400, Matt Zimmerman wrote:
> Which, of course, does not help with the situation he originally reported
> (building a woody package on testing with a newer compiler than was
> originally used). Time travel is still required there. :-)
it works in this case if y
On Mon, Jun 16, 2003 at 08:50:59AM +0200, Andreas Metzler wrote:
> Build-Depends: g++ (>= 3:3.2.2-0)
>
> Many transitioned packages use(d) this to guarantee that the correct
> compiler was used.
Which, of course, does not help with the situation he originally reported
(building a woody package o
Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
[...]
> That could be. Somehow, the C++ ABI would have to be added to the
> Build-Dependency information. Either that, or C++ packages would have
> to use a specific C++ ABI compiler, e.g.,
> (control)
>Build-Depends: c102, ...
[...]
Build-D
14 matches
Mail list logo
