# Automatically generated email from bts, devscripts version 2.10.35lenny3
# via tagpending
#
# apt-cacher (1.6.9) unstable; urgency=low
#
# * Rescan cached files after checking for diff_Index parents (closes: #537189)
# * Fix initscript for dependency based boot sequencing. Patch from Petter
R
# Automatically generated email from bts, devscripts version 2.10.35lenny3
# via tagpending
#
# apt-cacher (1.6.9) unstable; urgency=low
#
# * Rescan cached files after checking for diff_Index parents (closes: #537189)
# * Fix initscript for dependency based boot sequencing. Patch from Petter
R
Thanks again for the great work!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Fri, 2009 Aug 21 10:35-0400, Daniel Richard G. wrote:
>
> I've set up a Web server to simulate a repository, and now I'm seeing
> yet another bug: both apt-cacher and apt-get come to a point where
> each is expecting network traffic from the other, but nothing ever
> comes---a sort of network de
On Fri, 2009 Aug 21 10:55+0100, Mark Hindley wrote:
>
> I will roll all these (apart from the multiple distro) and get 1.6.9
> uploaded.
Yay! That'll be great, to get all these changes checkpointed.
It's possible that the remaining "Connection reset by peer" error
messages I'm seeing are not actu
On Thu, Aug 20, 2009 at 06:29:25PM -0400, Daniel Richard G. wrote:
> Okay, I think I've found out what was going on with server-hopping!
>
> Look at the libcurl() routine, starting on line 1297 of version 1.6.8.
> In there you have the bit that interacts with the curl download thread,
> notably th
Okay, I think I've found out what was going on with server-hopping!
Look at the libcurl() routine, starting on line 1297 of version 1.6.8.
In there you have the bit that interacts with the curl download thread,
notably the while(<$libcurl>) loop starting at line 1331.
First, you read in the HTTP
OK, the client had been hibernating during the daily
cron job to run apt updates so the periodic update
stamp (/var/lib/apt/periodic/update-success-stamp)
was very old, thus the 'update-notifier' nag icon/message.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a su
I ran 'aptitude update' on the server (which is a client of
itself), then update-manager on the client, and things seemed
to have settled down for now.
I haven't applied the patch or done another 'LANG=C' run
since the last one, but the 'LANG=C' fix seemed to
keep the client from trying to get
I have not altered the 'path_map' from the distribution
package.
Originally I had 2 warnings in my client machine regarding
'File not found' during an 'update-manager' run. After reading the bug
report I ran 'env LANG=C aptitude update' from the client and
got only one warning, then ran again a
Dominique,
The known workarounds at this point are as follows:
1. (Client-side) Set LANG=C when running "apt-get update".
2. (Server-side) Apply Mark's patch in message #125, and if you are
using path_map, edit it so that each map component has only one
server behind it.
--
To UNSUBSCR
On Wed, Aug 19, 2009 at 04:53:31PM -0400, Dominique Brazziel wrote:
> Is there a simple workaround for this problem until the
> bug is fixed? Perhaps deleting some header files (I see
> many '404 Not found' headers for i18n files in the 'headers'
> directory)?
You could try this patch on /usr/sha
Is there a simple workaround for this problem until the
bug is fixed? Perhaps deleting some header files (I see
many '404 Not found' headers for i18n files in the 'headers'
directory)?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
On Sat, Aug 15, 2009 at 02:10:16AM -0400, Daniel Richard G. wrote:
> 8<
> Hit http://midnight jaunty-security Release.gpg
> Ign http://midnight jaunty-security/main Translation-en_US
> Err http://midnight jaunty-security/restricted Translation-en_US
> Error reading from server - read (104
On Mon, 2009 Aug 17 21:25+0100, Mark Hindley wrote:
> >
> > I'll gladly put one together, but what should the behavior be? My
> > preliminary patch had it not closing the connection for 404 errors.
> > Should that be broadened to all errors (in which case, the whole if-
> > conditional can be remov
On Mon, Aug 17, 2009 at 04:04:06PM -0400, Daniel Richard G. wrote:
> On Mon, 2009 Aug 17 19:24+0100, Mark Hindley wrote:
> >
> > I still don't see it. But I am happy with your analysis. My default
> > LANG is en_GB, so I would have expect to have seen it with that as
> > that is also a missing Tran
On Mon, 2009 Aug 17 19:24+0100, Mark Hindley wrote:
>
> I still don't see it. But I am happy with your analysis. My default
> LANG is en_GB, so I would have expect to have seen it with that as
> that is also a missing Translation file
I'd feel better if you were able to reproduce it, but if you're
On Mon, Aug 17, 2009 at 01:24:53PM -0400, Daniel Richard G. wrote:
> On Sun, 2009 Aug 16 21:10+0100, Mark Hindley wrote:
> >
> > OK. Thanks for this. I have been unable to reproduce.
>
> Could you try with LANG=en_US.UTF-8? (And you have pipelining enabled,
> and are using path_map, yes?)
I still
On Sun, 2009 Aug 16 21:10+0100, Mark Hindley wrote:
>
> OK. Thanks for this. I have been unable to reproduce.
Could you try with LANG=en_US.UTF-8? (And you have pipelining enabled,
and are using path_map, yes?)
I can reproduce this bug in a minimal en_US Lenny install, with a hand-
built apt-cach
On Sat, Aug 15, 2009 at 02:10:16AM -0400, Daniel Richard G. wrote:
> 8<
> Hit http://midnight jaunty-security Release.gpg
> Ign http://midnight jaunty-security/main Translation-en_US
> Err http://midnight jaunty-security/restricted Translation-en_US
> Error reading from server - read (104
On Fri, Aug 14, 2009 at 01:56:11PM -0400, Daniel Richard G. wrote:
> I've investigated this bug further, and found the problem. Here is a
> walk-through of it, in apt-cacher 1.6.8:
>
> 1. First, in the handle_connection() subroutine (line 243), you read in
>the request. apt-get(8) typically us
8<
Hit http://midnight jaunty-security Release.gpg
Ign http://midnight jaunty-security/main Translation-en_US
Err http://midnight jaunty-security/restricted Translation-en_US
Error reading from server - read (104 Connection reset by peer)
Ign http://midnight jaunty-security/universe Trans
I believe Bug#517761 is a duplicate of this one, if I've diagnosed the
problem correctly. Please have a look at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517761#69
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe
I've investigated this bug further, and found the problem. Here is a
walk-through of it, in apt-cacher 1.6.8:
1. First, in the handle_connection() subroutine (line 243), you read in
the request. apt-get(8) typically uses HTTP Keep-Alive for efficiency
(i.e. download multiple files in one TCP
Mark,
There is a bug report on this same issue on Launchpad; it has a bit of
background that may be informative:
https://bugs.launchpad.net/bugs/366293
Note that the Translation file that apt-get(8) attempts to download is
dependent on the current value of LANG. I have LANG="en_US.UTF-8", an
On Mar 25, Mark Hindley wrote:
> Could you try this patch which fixes the header line terminations and
> Content-Length for error pages.
I don't know about the original bug, but this patch fixed one I
experienced where missing i18n translation files from security.d.o
broke apt-get update.
--
c
On Wed, Mar 25, 2009 at 12:13:26AM +0100, Thomas Hahn wrote:
> On Sun, Mar 22, 2009 at 10:06:34AM +, Mark Hindley wrote:
> > On Wed, Mar 18, 2009 at 12:45:42AM +0100, Thomas Hahn wrote:
> >
> > > with
> > > LANG=C apt-get update
> > >
> > > the update runs without problems.
> > > Why am I th
On Sun, Mar 22, 2009 at 10:06:34AM +, Mark Hindley wrote:
> On Wed, Mar 18, 2009 at 12:45:42AM +0100, Thomas Hahn wrote:
>
> > with
> > LANG=C apt-get update
> >
> > the update runs without problems.
> > Why am I the only one having this problem?
>
> I don't know. I can't reproduce it so it
On Wed, Mar 18, 2009 at 12:45:42AM +0100, Thomas Hahn wrote:
> with
> LANG=C apt-get update
>
> the update runs without problems.
> Why am I the only one having this problem?
I don't know. I can't reproduce it so it is hard to get a handle on.
Can you run apt-get update with -o Debug::Acquire:
On Sun, Mar 15, 2009 at 09:09:17PM +, Mark Hindley wrote:
> Could you try this patch against /usr/share/apt-cacher/apt-cacher and
> see if it helps.
>
> Thanks
>
> Mark
>
> diff --git a/apt-cacher b/apt-cacher
> index 48741b6..13e19f0 100755
> --- a/apt-cacher2
> +++ b/apt-cacher2
> @@ -861
Could you try this patch against /usr/share/apt-cacher/apt-cacher and
see if it helps.
Thanks
Mark
diff --git a/apt-cacher b/apt-cacher
index 48741b6..13e19f0 100755
--- a/apt-cacher2
+++ b/apt-cacher2
@@ -861,7 +861,7 @@ sub return_file {
debug_message("Header sent: $headstring
On Sat, Mar 07, 2009 at 03:30:31PM +0100, Thomas Hahn wrote:
> On Tue, Mar 03, 2009 at 09:14:09AM +, Mark Hindley wrote:
> > On Sun, Mar 01, 2009 at 10:58:57PM +0100, Thomas Hahn wrote:
> > > Package: apt-cacher
> > > Version: 1.6.7
> > > Severity: important
> > >
> > > After some upgrade on a
On Tue, Mar 03, 2009 at 09:14:09AM +, Mark Hindley wrote:
> On Sun, Mar 01, 2009 at 10:58:57PM +0100, Thomas Hahn wrote:
> > Package: apt-cacher
> > Version: 1.6.7
> > Severity: important
> >
> > After some upgrade on apt-get or apt-cacher, apt-get update fails if
> > LANG on client is differe
On Sun, Mar 01, 2009 at 10:58:57PM +0100, Thomas Hahn wrote:
> Package: apt-cacher
> Version: 1.6.7
> Severity: important
>
> After some upgrade on apt-get or apt-cacher, apt-get update fails if
> LANG on client is different from the settings on the server.
>
> sipia:~# echo $LANG
> en_US.UTF-8
>
Package: apt-cacher
Version: 1.6.7
Severity: important
After some upgrade on apt-get or apt-cacher, apt-get update fails if
LANG on client is different from the settings on the server.
sipia:~# echo $LANG
en_US.UTF-8
sipia:~# apt-get update
Ign http://ochenta unstable/main Translation-en_US
35 matches
Mail list logo
