tags 304604 - experimental
severity 304604 serious
reassing 322746 perl
merge 322746 304604
thanks
On Fri, Aug 12, 2005 at 05:24:10PM +0200, martin f krafft wrote:
# dpkg --configure -a
Setting up locales (2.3.5-3) ...
Generating locales (this might take a while)...
[...]
Generation
On Tue, Jul 19, 2005 at 02:32:23PM +0200, Martin Pitt wrote:
Uh, that must be a big one. How long does VACUUM run?
Well, it's not that big (usually between 800-900M) rather than the disk
is really slow. It's not a problem for normal operation, but VACUUM
FULL is a killer. Even a simple VACUUM
On Fri, Jul 15, 2005 at 05:10:09PM +0300, Vesselin Peev wrote:
I know the problem is not present with valgrind on Debian, too, so the
above then holds for the Debian libc package, too. From his words one can
conclude that there must be a better integration between mudflap and glibc.
Well,
On Thu, Jul 14, 2005 at 10:17:32PM +0300, Vesselin Peev wrote:
Could you please elucidate what is this programming pattern that causes the
leaks, if it is possible to do with a programming snippet? I find it very
strange that a well-working program will have leaks that are considered
reassign 304604 perl
retitle 304604 perl: heap corruption causes installation of other packages to
fail (debconf is aborting) with new glibc
thanks
I've verified that the bug is also present on a freshly installed AMD64
system. It would be good to resolve this before glibc-2.3.5 enters
unstable.
On Mon, Jul 04, 2005 at 01:29:24PM +0200, Michael Vogt wrote:
See above, is your problem fixed with that release file?
Yes it is, although I had to change the URLs in my sources.list to use
that Release file. Shouldn't the old Release files be deleted, then?
Gabor
--
On Tue, May 10, 2005 at 12:04:01PM +0200, Michael Vogt wrote:
Can you please run apt-cache policy (without additional arguments)
and add the output to this bugreport? There are some known issues with
pinning on components, but pinning on archive should work.
Now that apt 0.6.38 is in unstable
On Mon, Jun 20, 2005 at 12:40:45AM +0200, Vincent Lefevre wrote:
This is annoying as this means that Debian machines won't integrate
correctly in foreign networks. Why don't these groups have a name
specific to Debian? For instance, I've noticed that exim4 creates
a Debian-exim group. So, why
On Mon, Jun 20, 2005 at 01:45:17PM +0200, Vincent Lefevre wrote:
OK, you didn't say that there was such a standard rule.
I've sent a mail to the admins.
The rules are:
1. If you want to support a certain operating system/distribution then
don't put any groups/users in NIS that conflict
On Sun, Jun 19, 2005 at 02:53:16AM +0200, Vincent Lefevre wrote:
Is this rule of not having NIS group IDs 1000 standard?
No. It's just a good rule of thumb for most cases.
If so, is it possible to request that the NIS client ignores
such groups? This would make sense.
No. There are very
On Fri, Jun 17, 2005 at 07:56:10PM +0200, Vincent Lefevre wrote:
Lots of Debian packages create local groups (and in fact, this is the
only problem I have with local groups). So, what do you suggest? Not
using Debian because it is a security bug?
No. But if you want to use NIS you have to be
On Fri, Jun 17, 2005 at 08:51:53AM +0200, Vincent Lefevre wrote:
So, that would also make programs that rely on /etc/group being used
buggy. IIRC, when I want to add a local group with addgroup, it checks
first if it exists with getgrnam, and refuses to create it if it can
be found. And this
On Wed, Jun 08, 2005 at 08:30:42PM +0200, Hans Ulrich Niedermann wrote:
The returned list
- does not contain all network interface names like the man page says.
It only includes those which have an IPv4 address configured on them.
- does not contain one [structure] for every
On Tue, May 10, 2005 at 12:04:01PM +0200, Michael Vogt wrote:
Can you please run apt-cache policy (without additional arguments)
and add the output to this bugreport? There are some known issues with
pinning on components, but pinning on archive should work.
Ok, this seems strange. Since the
Hi,
ERROR: could not access file /usr/lib/postgresql/lib/plpgsql.so: No such
file or directory
ERROR: function public.plpgsql_call_handler() does not exist
ERROR: function plpgsql_call_handler() does not exist
Despite the errors the result of the upgrade seems to be OK so far (at
Hi!
Do you use stored procedures in SQL? Apparently the database tries to
load the library from it's old location (i. e. where the legacy
packages stored them).
The output of pg_dumpall includes the following repeated for every
database being dumped:
CREATE FUNCTION plpgsql_call_handler()
16 matches
Mail list logo
