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.
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.
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.
--
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..
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
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,
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 stop
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, ...
[...]
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 on
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 you
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
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.
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
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
14 matches
Mail list logo
