On Feb 5, 2008 4:35 PM, Tuncer Ayaz <[EMAIL PROTECTED]> wrote:
> Just out of curiosity, would the following change break anything?
> --- configure.orig 2008-01-25 10:55:34.0 +0100
> +++ configure 2008-01-25 10:56:14.0 +0100
> @@ -4345,7 +4345,7 @@
Just out of curiosity, would the following change break anything?
--- configure.orig 2008-01-25 10:55:34.0 +0100
+++ configure 2008-01-25 10:56:14.0 +0100
@@ -4345,7 +4345,7 @@
test "$svn_allowed_neon" = "any"; then
svn_allowed_neon_on_system="yes"
when I set default_charset to utf-8 the error vanishes
but I'm not sure how good a fix this is. I mean our
Subversion repos should almost always contain utf-8
if I correctly understand the way Subversion works
but I may also err here. we can only ensure UTF-8
for the commit messages and not the ac
some more background.
first installation (aka not yet used production server):
a) Debian i386
b) originally Subversion 1.4 and Trac 0.10 packages
were installed manually from Unstable versions before
being available in Testing
c) installed one or two months ago
second installation (some test box
I've installed Trac with the same config on another fresh Etch box and
was unable to reproduce
the codec search issue.
actually it is also not reproducable on the original machine, maybe
Apache needed
another restart which I may have forgotten before retesting.
anyway, it looks like Trac 0.10-3
I've removed python-chardet from the server which is now pure-Etch
after Trac 0.10 entered Testing and the problem reappeared.
Some info on Trac config on that server:
/etc/apache2/conf.d/trac:
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDi
Package: trac
Version: 0.10-1
Severity: normal
I had installed trac-0.10-1 in Etch by manually downloading and installing with
dpkg -i without any pinning or whatever and encountered an issue with character
set detections handlers not being registered. Maybe the python2.4 package in Sid
contains
On 9/15/06, Frans Pop <[EMAIL PROTECTED]> wrote:
On Friday 15 September 2006 13:10, Tuncer Ayaz wrote:
> yup, of course. I loaded it as I thought I'd need it and was surprised
> to see it appear twice because of me loading it manually and d-i
> loading the module automatical
On 9/13/06, Frans Pop <[EMAIL PROTECTED]> wrote:
On Thursday 24 August 2006 11:19, Tuncer Ayaz wrote:
> - start installer in expert mode
> - when asked for Installer Components to load select choose-mirror
There should not be any need to load it manually. It will be loaded
a
On 8/24/06, Christian Perrier <[EMAIL PROTECTED]> wrote:
reassign 383611 choose-mirror
retitle 383611 Please allow to specify full URLs for the chosen mirror
thanks
Quoting Tuncer Ayaz ([EMAIL PROTECTED]):
> update:
> being able to select choose-mirror in expert mode helps a lot bu
update:
being able to select choose-mirror in expert mode helps a lot but
it still does not allow specifying ftp:// instead of http:// access.
therefore, let's reduce my problem set to:
- allow complete repo url specification in choose-mirror
btw, as I had to enter the repo-info twice I'm not su
Package: debian-installer
Version: etch beta3
debian-installer naturally tries to connect to security.debian.org
but I have a few issues with the current implementation:
the connection timeout is too long
a user should be able to specify - beforehand in expert mode and
as a fallback in non-expe
ok, my "evil-hack" as an inspiration plus some other changes which
were packaged up as apt-proxy-1.9.33 seems to work here ony
my very special server. thanks to all involved.
ok, my "evil-hack" as an inspiration plus some other changes which
were packaged up as apt-proxy-1.9.33 seems to work here on
my very special server. thanks to all involved.
Summary of my private reply to Andreas for the record:
1) I only use FTP backends
2) Yes all apt-get clients ran flawlessly before the upgrade with
apt-proxy and Twisted in Sarge. Actually I upgraded to Sid due
to other reasons and I'm not sure I will downgrade as there are
core packages which I n
Hi Andreas,
my proposal to remove/disable the calls to arm() may be the
correct fix but it's hard to guess whether apt-proxy has other
problems that I'm triggering from both a Sarge and Sid apt-get
client which results in 503 errors or if it is related to the missing
arm() calls.
You say that it
I wanted to clarify that (at least here ony my server) the proposed workaround
I posted to #349447 does not fix the problem. yes, apt-proxy seems to work
but fails in many places as presumably the success-/error-handlers are not
called correctly anymore. advice of Twisted experts needed.
after seeing that #349596 refers to my evil hack as a fix, I wanted to clarify
that (at least here ony my server) the proposed workaround does not fix
the problem. yes, apt-proxy seems to work but fails in many places as
presumably the success-/error-handlers are not called correctly anymore.
advic
Hi Andreas,
> So removing all arm-calls is actually correct and thus you can easily
> provide a repaired package with proper Depends on twisted-web and
> removed arm-calls.
Actually the patched apt-proxy here fails to:
* download dependencies when you install package X (no workaround
for this)
For the time being you can use the following diff. arm() is deprecated
in Twisted 2.1
and as I've got not much Python experience I failed to adapt apt_proxy.py to the
Twisted changes.
Beware that this will most probably only work for the case when there is no
error and fail if anything goes wrong
I also had the same problem first but after setting up /dev/cciss/c0d1
in addition
to the existent c0d0 and retrying the setup in expert mode grub-install worked
flawlessly.
c0d0p1 is one with ext3 mounted to / (including /boot)
c0d1p1 is ext3 mounted to /mnt/data
c0d1p2 is swap
I want to believe
21 matches
Mail list logo
