Bug#386652: Incomplete job
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 @@ test $svn_allowed_neon = any; then svn_allowed_neon_on_system=yes SVN_NEON_INCLUDES=`$neon_config --cflags | sed -e 's/-D[^ ]*//g'` -NEON_LIBS=`$neon_config --la-file` +NEON_LIBS=`$neon_config --libs` CFLAGS=$CFLAGS `$neon_config --cflags | sed -e 's/-I[^ ]*//g'` svn_lib_neon=yes break I'm asking because the version I built that way on Etch passes make check except some skipped tests which I did not skip manually. Shouldn't it be safe to apply this change to upstream subversion? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386652: Incomplete job
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 SVN_NEON_INCLUDES=`$neon_config --cflags | sed -e 's/-D[^ ]*//g'` -NEON_LIBS=`$neon_config --la-file` +NEON_LIBS=`$neon_config --libs` CFLAGS=$CFLAGS `$neon_config --cflags | sed -e 's/-I[^ ]*//g'` svn_lib_neon=yes break -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393954: trac: default_charset = utf-8 is a fix but is not a generic solution
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 actual change set content IIRC. as setting default_charset to utf-8 may not be desired for everyone I'm not sure what the correct fix is but installing python-chardet seems to handle the issue transparently without any need to make charset predictions. if I read it correctly default_charset is intended as a fallback charset definition to use if Trac is uncertain so manually configuring all trac.ini files might fix it for the time being with the uncertainty of hitting the problem again with different content in future change sets which are not utf-8. to reproduce you need a Trac which has actual revisions in the db and load that Trac right after restarting Apache as the error only shows up the first time you load that Trac instance and not at all if you load another empty Trac before. moreover the box has only en_US-UTF-8 configured, nothing else. [trac] #default_charset = iso-8859-15 default_charset = utf-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393954: it's still reproducable on Etch
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:
Location /trac
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDir /srv/trac
PythonOption TracUriRoot /trac
/Location
LocationMatch /trac/[^/]+/login
AuthType Basic
AuthName Trac
AuthUserFile /srv/svn/config/trac.passwd
Require valid-user
/LocationMatch
I've disabled most components of Trac except the browser:
[components]
trac.wiki.* = disabled
trac.ticket.* = disabled
trac.About.* = disabled
trac.Settings.* = disabled
and this is the custom site_header.cs we use:
script language=JavaScript
!--
function openurl() {
if (document.f.s.value != null) {
var url=?cs var:base_host ?+document.f.s.value
document.location.href=url
}
}
//--
/script
div align=right
form name=f
!--hlAvailable Projects/hl --
select name=s onchange=openurl()
!--
Here insert option for every project
Example: option value=/path/to/projectdescription of project/option
--
option value=null-- Available Projects --/option
option value=/trac/externalexternal/option
option value=/trac/resres/option
option value=/trac/srcsrc/option
option value=/trac/toolstools/option
option value=/trac/useruser/option
/select
!-- input type=button value=Go onclick=openurl() / --
/form
/div
div align=right
hlCurrent: /hlb?cs var:project.name ?/b
/div
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393954: not reproducable here also right now
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 in Etch does not have the problem I've encountered with Trac 0.10 from Unstable installed manually in Etch. maybe some other dependencies got also updated in the meantime. Closing the bug report is OK. thanks for your help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393954: on the first installation box it still issues codec errors but closing the bug report is OK
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) a) Debian Etch PPC on Mac Mini G4 b) everything from Etch, no Unstable package ever installed c) installed today for restesting only so the only cause I can see is that either Python support changed something which is only applied when installing with a post-beta3 d-i cd and therefore sometime later or me having installed Trac and SVN from Unstable before they migrated to Testing may have borked something. whatever it is the first installation still has the problem it may very well be a config issue of my own. it is still OK to close the bug as I can only reproduce it on the first installation box, not the second install I did today on another box. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393954: trac: codec search functions fixed by installing python-chardet
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 something which fixes the issue but in case the bug is also
reproducable
with Sid (right now libapache2-mod_python is not installable so I could not test
easily) I would suggest adding 'python-chardet' to trac's dependencies
as installing
that package solves the following error seen in Apache2's error.log.
[Wed Oct 18 13:12:27 2006] [notice] caught SIGTERM, shutting down
[Wed Oct 18 13:12:28 2006] [notice] mod_python: Creating 8 session
mutexes based on 6 max processes and 25 max threads.
[Wed Oct 18 13:12:28 2006] [notice] mod_python: using mutex_directory /tmp
[Wed Oct 18 13:12:28 2006] [notice] Apache/2.0.55 (Debian)
mod_python/3.2.10 Python/2.4.4c0 configured -- resuming normal
operations
[Wed Oct 18 13:12:34 2006] [error] [client 10.1.32.2] PythonHandler
trac.web.modpython_frontend: Traceback (most recent call last):,
referer: http://svn/trac/tools/chrome/common/cs
s/trac.css
[Wed Oct 18 13:12:34 2006] [error] [client 10.1.32.2] PythonHandler
trac.web.modpython_frontend: File
/usr/lib/python2.4/site-packages/mod_python/apache.py, line 299, in
Handle
rDispatch\nresult = object(req), referer:
http://svn/trac/tools/chrome/common/css/trac.css
[Wed Oct 18 13:12:34 2006] [error] [client 10.1.32.2] PythonHandler
trac.web.modpython_frontend: File
/var/lib/python-support/python2.4/trac/web/modpython_frontend.py,
line 87,
in handler\ngateway.run(dispatch_request), referer:
http://svn/trac/tools/chrome/common/css/trac.css
[Wed Oct 18 13:12:34 2006] [error] [client 10.1.32.2] PythonHandler
trac.web.modpython_frontend: File
/var/lib/python-support/python2.4/trac/web/wsgi.py, line 87, in
run\nr
esponse = application(self.environ, self._start_response), referer:
http://svn/trac/tools/chrome/common/css/trac.css
[Wed Oct 18 13:12:34 2006] [error] [client 10.1.32.2] PythonHandler
trac.web.modpython_frontend: File
/var/lib/python-support/python2.4/trac/web/main.py, line 328, in
dispatch_
request\nenviron['SCRIPT_NAME'] =
Href(environ['SCRIPT_NAME'])(env_name), referer:
http://svn/trac/tools/chrome/common/css/trac.css
[Wed Oct 18 13:12:34 2006] [error] [client 10.1.32.2] PythonHandler
trac.web.modpython_frontend: File
/var/lib/python-support/python2.4/trac/web/href.py, line 142, in
__call__\
npath = '/'.join([unicode_quote(unicode(arg).strip('/')) for arg
in args, referer: http://svn/trac/tools/chrome/common/css/trac.css
[Wed Oct 18 13:12:34 2006] [error] [client 10.1.32.2] PythonHandler
trac.web.modpython_frontend: File
/var/lib/python-support/python2.4/trac/util/text.py, line 68, in
unicode_q
uote\nreturn quote(value.encode('utf-8')), referer:
http://svn/trac/tools/chrome/common/css/trac.css
[Wed Oct 18 13:12:34 2006] [error] [client 10.1.32.2] PythonHandler
trac.web.modpython_frontend: LookupError: no codec search functions
registered: can't find encoding, referer: ht
tp://svn/trac/tools/chrome/common/css/trac.css
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383611: choose-mirror
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 automatically whenever it is needed and run at the appropriate time. 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 automatically anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383611: choose-mirror
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 automatically anyway. Well, it is not really the same module as it is called in two completely different places in the installation process (though the main code is shared of course). Ah, this is why d-i does not detect it. As it only happens in 'expert' mode it's ok to have-to-know what will happen if you select the module but confusing the first time to someone else. I can live with it as d-i is excellent in other ways compared to Anaconda for example. My actual wishlist-item is supporting ftp:// access to network repos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383611: choose-mirror
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 but it still does not allow specifying ftp:// instead of http:// access. IIRC, abandoning the FTP/HTTP choice was a deliberate action. opinions may have changed, especially for expert mode. therefore, let's reduce my problem set to: - allow complete repo url specification in choose-mirror Should be a wishlist bug, with the correct title, yes. [EMAIL PROTECTED] should take care of my request I sent a minute ago btw, as I had to enter the repo-info twice I'm not sure it was choose-mirror that was being called twice or another module the 2nd time although it looked the same. Strange. You really would need to explain the exact sequence of actions you ran to get to this. - start installer in expert mode - when asked for Installer Components to load select choose-mirror - you will be asked for repository-information twice - on a 2nd install I saw that you get repo-info questions (choose-mirror) even if you don't select choose-mirror to load, so it's a little logic error it seems that happens when you select choose-mirror which is only a a little irritating, no real problem. would it make sense to change the bug-report's package to choose-mirror? Certainly. The wishlist above belongs to it. so, depending on the bug-tracker's feature we should maybe close this bug and I will re-open it for choose-mirror instead. No, you can reassign and manipulate a bug report by mail. See http://bugs.debian.org as described in http://www.debian.org/Bugs/server-control Which is what I'm doing in this mail, BCC'ed to [EMAIL PROTECTED] (usual way, mostly meant to avoid users inadvertently replying to [EMAIL PROTECTED]) I've sent a request for setting the sever_ity to wishlist. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383611: choose-mirror
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 sure it was choose-mirror that was being called twice or another module the 2nd time although it looked the same. would it make sense to change the bug-report's package to choose-mirror? so, depending on the bug-tracker's feature we should maybe close this bug and I will re-open it for choose-mirror instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383611: debian-installer should provide fallback or config option for net-repo access
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-expert mode: - either an alternative security.debian.org repository which is accessible without additional proxy settings (yes there are LANs where the net-admin allows port 21 out but not 80 out) - or a ftp/http proxy for a 2nd try ideally, the user would be able to specify local mirror or ftp-accessed repos (apt-cacher, apt-proxy, ftp.TLD.debian.org, etc.) for main and security network install/update in the installer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349447: it works
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.
Bug#349596: it works
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.
Bug#349447: apt-proxy: patch does not work
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 might be a frontend problem (apt-get). If this is the case I'm not sure there will be a apt-proxy compatibility fix for apt-get released to Sarge and I'm also not sure that apt-get in Sarge is broken at all. To me apt-proxy is the point of failure, at least with my patched-(tried-to-fix-Twisted-incompatibility)-version. Re: The apt cache clean strangeness: On one of my tries (with the not yet completely patched version) apt-proxy exceptioned and apt-get failed with 503 and the only way to install with the completely patched apt-proxy (restarted of course) was to apt-get clean and re-download/-install package X. On Sarge and Sid I get 503s everytime right now with the patched apt-proxy (especially if it needs to download dependencies) and apt-get dist-upgrade on Sid against apt-proxy does not work at all. Is there anyone out there where the diff I posted fixes apt-proxy without any side-effects? Anyway, I'm not an APT, apt-proxy or Twisted expert, so don't take my word on it. There might be other problems I run into which are not related to the removed arm() calls.
Bug#349447: apt-proxy: patch does not work
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 need to be newer than in Sarge or Testing without pinning etc. 3) I can imagine apt-proxy having other bugs which only surfaced now in Sid and with the new Twisted 4) I may turn on debug logs and try again
Bug#349447: apt-proxy: Does not work with twisted 2.1.
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) * re-download if something goes wrong like external (Debian mirror) connection closed (apt-get clean ; apt-get install X helps though) Therefore I'm not sure removing the calls is sufficient. First I thought I might have to call callback() (hey, the samples do this :)) but dismissed that idea pretty soon after trying it out.
Bug#349447: patch does not work
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. advice of Twisted experts needed.
Bug#349596: patch does not work
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.
Bug#349447: apt-proxy: Does not work with twisted 2.1.
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 while downloading from the external
Debian mirror. If this happens you can try to work around by doing
apt-get clean
and installing/upgrading anew.
This is the Deferred api as present in current Twisted:
http://twistedmatrix.com/documents/current/api/twisted.internet.defer.Deferred.html#arm.
Evil hack (no cure to the python-twisted incompatibility) to
/usr/lib/python2.3/site-packages/apt_proxy/apt_proxy.py
until a real Python programmer adapts apt-proxy:
--- apt_proxy.py2005-08-19 19:15:20.0 +0200
+++ apt_proxy.py.new2006-01-23 13:48:24.0 +0100
@@ -819,7 +819,7 @@
d = self.ftpclient.queueStringCommand('SIZE ' + self.remote_file)
d.addCallbacks(apFtpSizeFinish, apFtpSizeFinish,
(self, 0), None, (self, 1), None)
-d.arm()
+#d.arm()
def ftpFetchList(self):
If ftpFetchSize didn't work try to get the size with a list command.
@@ -839,7 +839,7 @@
d.addCallbacks(apFtpListFinish, apFtpListFinish,
(filelist, self, 0), None,
(filelist, self, 1), None)
-d.arm()
+ #d.arm()
def ftpFetchFile(self):
And finally, we ask for the file.
@@ -851,7 +851,7 @@
d.addCallbacks(apFtpFetchFinish, apFtpFetchFinish,
(http.OK, good, self), None,
(http.NOT_FOUND, fail, self), None)
-d.arm()
+#d.arm()
def dataReceived(self, data):
self.setResponseCode(http.OK)
@@ -1486,7 +1486,7 @@
d.addCallbacks(fetch_real, fetch_real,
(dummyFetcher, 1, running,), None,
(dummyFetcher, 0, running,), None)
-d.arm()
+#d.arm()
return None
def simplify_path(self, old_path):
@@ -1574,7 +1574,7 @@
verifier.deferred.addCallbacks(file_ok, deferred.errback,
(deferred, self), None,
None, None)
-verifier.deferred.arm()
+#verifier.deferred.arm()
else:
deferred.errback()
Bug#301960: works if you run d-i in export mode
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 that is has to do with me running d-i in expert mode and not adding the additional raid0.
