Bug#399897: number of fonts is limited in pdfTeX (was: Bug#397571: debian-reference: FTBFS: ERROR: reference.zh-tw.pdf could not be generated properly)
Danai SAE-HAN (韓達耐) [EMAIL PROTECTED] wrote: I don't have the source, so if you could test pdflatex with test.tex? You can find it here: http://users.edpnet.be/vanmeel/test.tex Which fonts (or other things) do I need to have installed? With latex-cjk-chinese-arphic-bkai00mp installed, I get lots of error messages of the type kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+264/600 --dpi 864 bkaiu99 mktexpk: don't know how to create bitmap font for bkaiu99. kpathsea: Appending font creation commands to missfont.log. (see the transcript file for additional information) Warning: pdflatex (file bkaiu99): Font bkaiu99 at 864 not found kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 2+293/600 --dpi 1493 bkaiu93 mktexpk: don't know how to create bitmap font for bkaiu93. How strange. It shouldn't use bkaiu (which is the Unicode encoded font) but bkai. But the bkai fonts are all virtual fonts redirecting glyphs to those of bkaiu. Perhaps that's why mktexpk complains about missing bkaiu files, but I wonder. mktexpk shouldn't even be running, since all the fonts are already provided as Type1 fonts. I haven't changed anything in the file test.tex. latex runs without problems, and subsequently dvipdfmx produces a nice PDF file. Only pdftex wants to create the pk fonts. Moreover, the log file after a pdflatex run has many more instances of +Missing character: There is no 84 in font ... than the dvi version. If you run test.tex with latex, it should be fine. pdflatex should fail with this arithmetic bug. The packages you need are: latex-cjk-common, latex-cjk-chinese and latex-cjk-chinese-arphic-bkai00mp. $ dpkg -l latex-cjk-common latex-cjk-chinese latex-cjk-chinese-arphic-bkai00mp *arphic* | grep ^ii ii latex-cjk-chinese 4.7.0+cvs20061019-1 Chinese module of LaTeX CJK ii latex-cjk-chinese-arphic-bkai00mp 1.15traditional Chinese KaiTi fonts for CJK ii latex-cjk-chinese-arphic-bkai00mp 1.15traditional Chinese KaiTi fonts for CJK ii latex-cjk-chinese-arphic-bsmi00lp 1.15traditional Chinese KaiTi fonts for CJK ii latex-cjk-chinese-arphic-gbsn00lp 1.15traditional Chinese KaiTi fonts for CJK ii latex-cjk-chinese-arphic-gkai00mp 1.15traditional Chinese KaiTi fonts for CJK ii latex-cjk-common 4.7.0+cvs20061019-1 LaTeX macro package for CJK (Chinese/Japanes ii ttf-arphic-bsmi00lp 2.10-6.1AR PL Mingti2L Big5 Chinese TrueType font Is something missing here? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#399454: [autodir] [EMAIL PROTECTED]: Bug#399454: autodir: fails with alert: unexpected autofs packet type 3]
On Wed, Nov 22, 2006 at 07:26:17PM -0800, ramana wrote: --- Hanno G. Steinke [EMAIL PROTECTED] wrote: the problem occured with autofs4 module, not autofs. It's a debian kernel, maybe there are subtle differences in the modules, autofs or autodir packages compared to fedora. I can have a look at the sources if you direct me what to look for. The bug is not closed. I still need to hold at version 0.99.3. However autofs4 modules differ from Fedora4 or Debian, they should present same protocol numbers and packet type numbers. For a moment I still suspect it is module mismatch. I'm keeping in the loop autofs maintainer, for comments but for those of Kent. It seems a protocol mismatch, but I'm unsure what's changes in respect with Fedora packages (kernel and autofs4). -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398899: python-iconvcodec: Fails to upgrade
clone 398899 -1 reassign -1 python-central 0.5.10 retitle -1 python-central doesn't support packages providing only support for old/unsupported runtimes thanks On Thu, 16 Nov 2006, Yavor Doganov wrote: Package: python-iconvcodec Version: 1.1.2-3+b1 Severity: serious The package fails to upgrade with the following error: Setting up python-iconvcodec (1.1.2-3+b1) ... INFO: using old version '/usr/bin/python2.3' pycentral: pycentral pkginstall: python-iconvcodec needs unavailable runtime (2.3) pycentral pkginstall: python-iconvcodec needs unavailable runtime (2.3) dpkg: error processing python-iconvcodec (--configure): subprocess post-installation script returned error exit status 1 This is a bug in python-central (thus the clone). But the real underlying problem is that the package should be removed because this module is no more useful with python2.4 and python2.4 is the default python both in etch and in sid. I suggest removing the package from etch as a start (I see no point in providing support for python2.3 in etch: not all modules will support python 2.3 and python2.3 itself might be removed). If the maintainer agrees, he can also reassign this bug to ftp.debian.org and request its removal. On the python-central side I must say that fixing this bug is not trivial. python-central uses the same function requested_versions() for deciding versions to support at build time and versions to support at runtime. Obviously at runtime we want to be more open-minded and support old/unsupported runtimes if that's possible according to the Python-Version field. There's lots of code duplication within python-central and the initial design suffered a lot from incremental bug fixes, which renders writing this patch a painful task. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#399454: [autodir] [EMAIL PROTECTED]: Bug#399454: autodir: fails with alert: unexpected autofs packet type 3]
First thanks to Ian for providing valuable info for arrving at this conclusion. What happened? There is old autofs4 module which supported autofs4 protocol. Autofs team developed new autofs5 protocol but new module given name as autofs4. So this is where the problem is. New module is backward compatible with autofs4 protcol and also supports autofs5 but with the name 'autofs4'. Everything ok but with the autofs headers. What can be done? Until this is resolved, just compile autodir with old /usr/src/linux/auto_fs4.h and everthing should work fine. That is the reason older autodir compiled with older header file working fine with new kernel module autofs4 (which is autofs5) Since I do not have access to new autofs module on my Fedora, the testing is going fine -- which is compiled with older autofs module. And I can not say 100% sure about. (as I said I do not have access to the latest module and I can not confirm it myself doing tests). Regards ramana --- Francesco P. Lovergine [EMAIL PROTECTED] wrote: On Wed, Nov 22, 2006 at 07:26:17PM -0800, ramana wrote: --- Hanno G. Steinke [EMAIL PROTECTED] wrote: the problem occured with autofs4 module, not autofs. It's a debian kernel, maybe there are subtle differences in the modules, autofs or autodir packages compared to fedora. I can have a look at the sources if you direct me what to look for. The bug is not closed. I still need to hold at version 0.99.3. However autofs4 modules differ from Fedora4 or Debian, they should present same protocol numbers and packet type numbers. For a moment I still suspect it is module mismatch. I'm keeping in the loop autofs maintainer, for comments but for those of Kent. It seems a protocol mismatch, but I'm unsure what's changes in respect with Fedora packages (kernel and autofs4). -- Francesco P. Lovergine Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: python-iconvcodec: Fails to upgrade
Processing commands for [EMAIL PROTECTED]: clone 398899 -1 Bug#398899: python-iconvcodec: Fails to upgrade Bug 398899 cloned as bug 399986. reassign -1 python-central 0.5.10 Bug#399986: python-iconvcodec: Fails to upgrade Bug reassigned from package `python-iconvcodec' to `python-central'. retitle -1 python-central doesn't support packages providing only support for old/unsupported runtimes Bug#399986: python-iconvcodec: Fails to upgrade Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: python-central: diff for NMU version 0.5.12
Processing commands for [EMAIL PROTECTED]: tags 399986 + patch Bug#399986: python-central doesn't support packages providing only support for old/unsupported runtimes Tags were: sid Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399709: marked as done (gps_1.1.0-5(ia64/unstable): FTBFS: bad include?)
Your message dated Thu, 23 Nov 2006 10:02:05 + with message-id [EMAIL PROTECTED] and subject line Bug#399709: fixed in gps 1.1.0-6 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: gps Version: 1.1.0-5 Severity: serious There was an error while trying to autobuild your package: Automatic build of gps_1.1.0-5 on caballero by sbuild/ia64 85 Build started at 20061121-1418 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 5), libgtk1.2-dev (= 1.2.7), libglib1.2-dev (= 1.2.0) [...] In file included from /usr/lib/gcc/ia64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward/iostream.h:31, from gps.cc:27: /usr/lib/gcc/ia64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the X header for the X.h header for C++ includes, or iostream instead of the deprecated header iostream.h. To disable this warning use -Wno-deprecated. c++ -O2 -c history.cc -o history.o -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -DWDOC=\/usr/doc\ In file included from /usr/lib/gcc/ia64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward/iostream.h:31, from history.cc:27: /usr/lib/gcc/ia64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the X header for the X.h header for C++ includes, or iostream instead of the deprecated header iostream.h. To disable this warning use -Wno-deprecated. c++ -O2 -c linuxprocfs.cc -o linuxprocfs.o -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -DWDOC=\/usr/doc\ linuxprocfs.cc: In member function 'virtual void LinuxProcFsProcessListPoller::poll()': linuxprocfs.cc:272: error: 'PAGE_SHIFT' was not declared in this scope linuxprocfs.cc: In member function 'virtual void LinuxProcFsProcessDetailsPoller::poll(int)': linuxprocfs.cc:518: error: 'PAGE_SHIFT' was not declared in this scope make[1]: *** [linuxprocfs.o] Error 1 make[1]: Leaving directory `/build/buildd/gps-1.1.0' make: *** [build-stamp] Error 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=ia64pkg=gpsver=1.1.0-5 Not sure where PAGE_SHIFT used to come from, but that smells of using kernel defines in user space... lamont ---End Message--- ---BeginMessage--- Source: gps Source-Version: 1.1.0-6 We believe that the bug you reported is fixed in the latest version of gps, which is due to be installed in the Debian FTP archive: gps_1.1.0-6.diff.gz to pool/main/g/gps/gps_1.1.0-6.diff.gz gps_1.1.0-6.dsc to pool/main/g/gps/gps_1.1.0-6.dsc gps_1.1.0-6_i386.deb to pool/main/g/gps/gps_1.1.0-6_i386.deb rgpsp_1.1.0-6_i386.deb to pool/main/g/gps/rgpsp_1.1.0-6_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Roland Stigge [EMAIL PROTECTED] (supplier of updated gps package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Nov 2006 10:40:19 +0100 Source: gps Binary: rgpsp gps Architecture: source i386 Version: 1.1.0-6 Distribution: unstable Urgency: low Maintainer: Roland Stigge [EMAIL PROTECTED] Changed-By: Roland Stigge [EMAIL PROTECTED] Description: gps- Graphical Process Statistics using GTK+ rgpsp - Remote poller for GPS (Graphical Process Statistics) Closes: 399709 Changes: gps (1.1.0-6) unstable; urgency=low . * Replaced PAGE_SHIFT with sysconf() call (Closes: #399709) Files: 17b07e5aa4beb977b5c397d6130b36f7 600 admin optional gps_1.1.0-6.dsc a25b026c3543a7a821209ceb868a8522 5192 admin optional gps_1.1.0-6.diff.gz 9fb7908347745fd8988ce3c1c026bf23 121216 admin optional gps_1.1.0-6_i386.deb
Bug#399986: python-central: diff for NMU version 0.5.12
tags 399986 + patch
thanks
Hi,
Attached is the diff for my python-central 0.5.12 NMU.
I changed python-central accept installing packages providing only support
of old python versions. I didn't add unsupported versions since we now
have 2.5 in sid and we have no experience in handling addition of new
upstream version from that point of view.
But I suggest enabling that post-etch of course.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -Nru /tmp/YU1MgPcx9o/python-central-0.5.11/debian/changelog
/tmp/sdAGhjKHsf/python-central-0.5.12/debian/changelog
--- /tmp/YU1MgPcx9o/python-central-0.5.11/debian/changelog 2006-11-22
12:35:39.0 +0100
+++ /tmp/sdAGhjKHsf/python-central-0.5.12/debian/changelog 2006-11-23
11:13:11.0 +0100
@@ -1,3 +1,11 @@
+python-central (0.5.12) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Accept packages providing support of only old python runtimes.
+Closes: #399986
+
+ -- Raphael Hertzog [EMAIL PROTECTED] Thu, 23 Nov 2006 10:28:23 +0100
+
python-central (0.5.11) unstable; urgency=low
* Non-maintainer upload.
diff -Nru /tmp/YU1MgPcx9o/python-central-0.5.11/pycentral.py
/tmp/sdAGhjKHsf/python-central-0.5.12/pycentral.py
--- /tmp/YU1MgPcx9o/python-central-0.5.11/pycentral.py 2006-11-22
17:59:26.0 +0100
+++ /tmp/sdAGhjKHsf/python-central-0.5.12/pycentral.py 2006-11-23
11:01:54.0 +0100
@@ -867,14 +867,19 @@
bc_option = config.get('DEFAULT', 'byte-compile')
pkg = DebPackage('package', self.args[0], oldstyle=False)
pkg.read_version_info()
+requested =
pyversions.requested_versions_for_runtime(pkg.version_field, version_only=True)
+used_runtimes = [rt for rt in runtimes if rt.short_name in requested]
try:
pkg.set_default_runtime_from_version_info()
except ValueError:
-# package needs an unavailable runtime.
-self.error('%s needs unavailable runtime (%s)'
- % (self.pkgname, pkg.version_field))
-requested = pyversions.requested_versions(pkg.version_field,
version_only=True)
-used_runtimes = [rt for rt in runtimes if rt.short_name in requested]
+ # Package doesn't provide support for any supported runtime
+ if len(used_runtimes) == 0:
+ self.error('%s needs unavailable runtime (%s)'
+ % (self.pkgname, pkg.version_field))
+ else:
+ # Still byte compile for the available runtimes (with the
+ # first matching runtime)
+ pkg.default_runtime = get_runtime_for_version(used_runtimes[0])
logging.debug('\tavail=%s, pkg=%s, install=%s'
% ([rt.short_name for rt in runtimes],
pkg.version_field,
diff -Nru /tmp/YU1MgPcx9o/python-central-0.5.11/pyversions.py
/tmp/sdAGhjKHsf/python-central-0.5.12/pyversions.py
--- /tmp/YU1MgPcx9o/python-central-0.5.11/pyversions.py 2006-10-06
12:55:22.0 +0200
+++ /tmp/sdAGhjKHsf/python-central-0.5.12/pyversions.py 2006-11-23
11:05:42.0 +0100
@@ -152,6 +152,43 @@
else:
return ['python%s' % v for v in versions]
+# This function is used by python-central to decide which installed
+# runtimes must be supported. It's not nice, but it's designed to mimic
+# closely requested_versions in an attempt to avoid introducing bugs this
+# late in the release cycle. Some cleanup is in order post-etch though.
+def requested_versions_for_runtime(vstring, version_only=False):
+versions = None
+vinfo = parse_versions(vstring)
+old = old_versions(version_only=True)
+unsupported = unsupported_versions(version_only=True)
+supported = supported_versions(version_only=True)
+# You might want to add unsupported versions too... later.
+supported.extend(old)
+if len(vinfo) == 1:
+if 'all' in vinfo:
+versions = supported
+elif 'current' in vinfo:
+versions = [default_version(version_only=True)]
+else:
+versions = vinfo['versions'].intersection(supported)
+elif 'all' in vinfo and 'current' in vinfo:
+raise ValueError, both `current' and `all' in version string
+elif 'all' in vinfo:
+versions = versions = vinfo['versions'].intersection(supported)
+elif 'current' in vinfo:
+current = default_version(version_only=True)
+if not current in vinfo['versions']:
+raise ValueError, `current' version not in supported versions
+versions = [current]
+else:
+raise ValueError, 'error in version string'
+if not versions:
+raise ValueError, 'empty set of versions'
+if version_only:
+return versions
+else:
+return ['python%s' % v for v in versions]
+
def installed_versions(version_only=False):
import glob
supported =
Processed: severity of 398899 is important
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.22 # This bug is not RC any more since python-central 0.5.12 fixes the problem, the package is still useless severity 398899 important Bug#398899: python-iconvcodec: Fails to upgrade Severity set to `important' from `serious' End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 399986
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.22 tags 399986 - sid Bug#399986: python-central doesn't support packages providing only support for old/unsupported runtimes Tags were: patch sid Tags removed: sid End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399995: wodim: Error trying to dist-upgrade
Package: wodim Severity: serious Justification: Error trying to dist-upgrade I don't know if I reporting to the right package, and also dunno if serious is the right severity... sorry :-( While trying to apt-get dist-upgrade to etch, I got this: Unpacking wodim (from .../wodim_5%3a1.0-1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/wodim_5%3a1.0-1_i386.deb (--unpack): trying to overwrite `/usr/share/man/man1/readcd.1.gz', which is also in package cdrecord dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/wodim_5%3a1.0-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398629: libapache-mod-acct-{mysql,pgsql} db clients dependencies.
I think you also need to make libapache-mod-acct-mysql depend on mysql-client (the equivalent to the postgresql-client changes you made on libapache-mod-acct-pgsql) Currently libapache-mod-acct-mysql only recommends mysql-client. A suggestion on mysql-server would probably not hurt eigther. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399986: marked as done (python-central doesn't support packages providing only support for old/unsupported runtimes)
Your message dated Thu, 23 Nov 2006 10:32:02 + with message-id [EMAIL PROTECTED] and subject line Bug#399986: fixed in python-central 0.5.12 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: python-iconvcodec Version: 1.1.2-3+b1 Severity: serious The package fails to upgrade with the following error: Setting up python-iconvcodec (1.1.2-3+b1) ... INFO: using old version '/usr/bin/python2.3' pycentral: pycentral pkginstall: python-iconvcodec needs unavailable runtime (2.3) pycentral pkginstall: python-iconvcodec needs unavailable runtime (2.3) dpkg: error processing python-iconvcodec (--configure): subprocess post-installation script returned error exit status 1 -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-powerpc Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Versions of packages python-iconvcodec depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii python 2.4.4-1 An interactive high-level object-o ii python-central 0.5.10 register and build utility for Pyt python-iconvcodec recommends no packages. -- no debconf information ---End Message--- ---BeginMessage--- Source: python-central Source-Version: 0.5.12 We believe that the bug you reported is fixed in the latest version of python-central, which is due to be installed in the Debian FTP archive: python-central_0.5.12.dsc to pool/main/p/python-central/python-central_0.5.12.dsc python-central_0.5.12.tar.gz to pool/main/p/python-central/python-central_0.5.12.tar.gz python-central_0.5.12_all.deb to pool/main/p/python-central/python-central_0.5.12_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Raphael Hertzog [EMAIL PROTECTED] (supplier of updated python-central package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Nov 2006 10:28:23 +0100 Source: python-central Binary: python-central Architecture: source all Version: 0.5.12 Distribution: unstable Urgency: low Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Raphael Hertzog [EMAIL PROTECTED] Description: python-central - register and build utility for Python packages Closes: 399986 Changes: python-central (0.5.12) unstable; urgency=low . * Non-maintainer upload. * Accept packages providing support of only old python runtimes. Closes: #399986 Files: b09d373b3a372c8cc0d2d50f24ed2c87 600 python standard python-central_0.5.12.dsc d5b5e73b938e28a0e96fe33f6dfe0877 29712 python standard python-central_0.5.12.tar.gz d501264b680a5cd32e5a19f45b04ccdf 31922 python standard python-central_0.5.12_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFZXRKvPbGD26BadIRArTbAJ4peqQkw1cIty8TKpBknMHLGP0RYwCdG7n0 ++a3teQ/U1/RXQP8SzhvHCw= =xGO+ -END PGP SIGNATURE- ---End Message---
Processed: This only affects the sarge version, right?
Processing commands for [EMAIL PROTECTED]: tags 398770 + sarge Bug#398770: mysql-server-4.1: memleak - kernel: Out of Memory: Killed process There were no tags set. Tags added: sarge thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: sqlrelay: diff for NMU version 1:0.37.1-3.1
Processing commands for [EMAIL PROTECTED]: tags 398636 + patch Bug#398636: zope-sqlrelayda: postinst fails: __main__.PyCentralError: package has no field Python-Version There were no tags set. Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398636: sqlrelay: diff for NMU version 1:0.37.1-3.1
tags 398636 + patch
thanks
Hi,
Attached is the diff for my sqlrelay 1:0.37.1-3.1 NMU.
I fixed more than just this bug since the package was not bin-NMU safe and
since php5-sqlrelay was empty.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
reverted:
--- sqlrelay-0.37.1/debian/php4-sqlrelay.install
+++ sqlrelay-0.37.1.orig/debian/php4-sqlrelay.install
@@ -1,2 +0,0 @@
-usr/lib/php4/*
-usr/share/pear/DB/sqlrelay.php usr/share/doc/php4-sqlrelay/
reverted:
--- sqlrelay-0.37.1/debian/php4-sqlrelay.substvars
+++ sqlrelay-0.37.1.orig/debian/php4-sqlrelay.substvars
@@ -1 +0,0 @@
-php:Depends=phpapi-
diff -u sqlrelay-0.37.1/debian/control sqlrelay-0.37.1/debian/control
--- sqlrelay-0.37.1/debian/control
+++ sqlrelay-0.37.1/debian/control
@@ -9,7 +9,7 @@
Package: sqlrelay
Architecture: any
Depends: libxml2-utils, ${shlibs:Depends}, adduser
-Suggests: sqlrelay-doc (= ${Source-Version}), sqlrelay-config-gtk (=
${Source-Version}), sqlrelay-connection-daemon, sqlrelay-api
+Suggests: sqlrelay-doc (= ${source:Version}), sqlrelay-config-gtk (=
${binary:Version}), sqlrelay-connection-daemon, sqlrelay-api
Description: Database connection pooling, proxying and load balancing
SQL Relay is a persistent database connection pooling, proxying and
load balancing system for Unix and Linux supporting ODBC, Oracle,
@@ -37,7 +37,7 @@
Package: sqlrelay-dev
Section: devel
Architecture: any
-Depends: ${shlibs:Depends}, libsqlrelay-0.37 (= ${Source-Version}), sqlrelay
(= ${Source-Version}), sqlrelay-mysql (= ${Source-Version}), librudiments-dev
(= 0.29)
+Depends: ${shlibs:Depends}, libsqlrelay-0.37 (= ${binary:Version}), sqlrelay
(= ${binary:Version}), sqlrelay-mysql (= ${binary:Version}), librudiments-dev
(= 0.29)
Provides: sqlrelay-api
Suggests: sqlrelay-doc
Description: SQL Relay C and C++ APIs
@@ -76,7 +76,7 @@
Package: python-sqlrelay
Section: python
Architecture: any
-Depends: ${python:Depends}, sqlrelay (= ${Source-Version}), ${shlibs:Depends}
+Depends: ${python:Depends}, sqlrelay (= ${binary:Version}), ${shlibs:Depends}
Suggests: sqlrelay-doc
Conflicts: python2.3-sqlrelay, python2.4-sqlrelay
Replaces: python2.3-sqlrelay, python2.4-sqlrelay
@@ -90,8 +90,9 @@
Replaces: zsqlrelayda
Architecture: all
Provides: sqlrelay-api
-Depends: python-sqlrelay (= ${Source-Version}), zope2.9 | zope2.8 | zope,
${misc:Depends}
+Depends: python-sqlrelay (= ${source:Version}), zope2.9 | zope2.8 | zope,
${misc:Depends}
Suggests: sqlrelay-doc
+XB-Python-Version: ${python:Versions}
Description: SQL Relay Zope database adapter
SQL Relay is a persistent database connection pooling, proxying and
load balancing system for Unix and Linux.
@@ -168,7 +169,7 @@
Package: sqlrelay-config-gtk
Architecture: any
-Depends: sqlrelay (= ${Source-Version}), ${shlibs:Depends}
+Depends: sqlrelay (= ${binary:Version}), ${shlibs:Depends}
Suggests: sqlrelay-doc
Description: SQL Relay configuration GTK+ client
SQL Relay is a persistent database connection pooling, proxying and
@@ -178,7 +179,7 @@
Package: sqlrelay-test
Architecture: any
-Depends: ${shlibs:Depends}, sqlrelay (= ${Source-Version}), ${shlibs:Depends}
+Depends: ${shlibs:Depends}, sqlrelay (= ${binary:Version}), ${shlibs:Depends}
Suggests: sqlrelay-doc
Description: SQL Relay tests
SQL Relay is a persistent database connection pooling, proxying and
@@ -189,7 +190,7 @@
Package: libdbd-sqlrelay-perl
Section: perl
Architecture: all
-Depends: ${perl:Depends}, sqlrelay (= ${Source-Version}),
libfirstworks-sqlr-perl (= ${Source-Version})
+Depends: ${perl:Depends}, sqlrelay (= ${source:Version}),
libfirstworks-sqlr-perl (= ${source:Version})
Suggests: sqlrelay-doc
Provides: sqlrelay-api
Description: SQL Relay Perl DBD API
@@ -202,7 +203,7 @@
Package: libfirstworks-sqlr-perl
Section: perl
Architecture: any
-Depends: ${perl:Depends}, sqlrelay (= ${Source-Version}), ${shlibs:Depends}
+Depends: ${perl:Depends}, sqlrelay (= ${binary:Version}), ${shlibs:Depends}
Suggests: sqlrelay-doc
Provides: sqlrelay-api
Conflicts: libdbd-sqlrelay-perl ( 1:0.35-4)
@@ -216,7 +217,7 @@
Package: libsqlrelay-java
Architecture: any
-Depends: java-gcj-compat | java-runtime2, sqlrelay (= ${Source-Version}),
${shlibs:Depends}
+Depends: java-gcj-compat | java-runtime2, sqlrelay (= ${binary:Version}),
${shlibs:Depends}
Suggests: sqlrelay-doc
Provides: sqlrelay-api
Description: SQL Relay Java API
@@ -227,7 +228,7 @@
Package: libsqlrelay-ruby
Architecture: any
-Depends: ruby, sqlrelay (= ${Source-Version}), ${shlibs:Depends}
+Depends: ruby, sqlrelay (= ${binary:Version}), ${shlibs:Depends}
Suggests: sqlrelay-doc
Provides: sqlrelay-api
Description: SQL Relay Ruby API
@@ -238,7 +239,7 @@
Package: libsqlrelay-tcl
Architecture: any
-Depends: tcl8.4, sqlrelay (= ${Source-Version}), ${shlibs:Depends}
+Depends: tcl8.4, sqlrelay (= ${binary:Version}), ${shlibs:Depends}
Suggests: sqlrelay-doc
Provides:
Bug#398634: [phpgacl] alternative patch without hard dependencies on both db clients.
El mié, 22-11-2006 a las 13:57 +0100, Steinar H. Gunderson escribió: On Wed, Nov 22, 2006 at 01:44:43PM +0100, Andreas Henriksson wrote: Since I've already created it I'll send this patch to the BTS just for reference. This one takes the alternative route of not having a hard-dependency on both mysql- and postgresql-client, but instead recommends them both and checks which one is available during configuration. Shouldn't this code rather reside in dbconfig-common? I agree. Maybe I am completely wrong, but phpgacl does not need (mysql| postgresql)-client, dbconfig-common needs them (#353617). I am not happy to make phpgacl depends on (mysql|postgresql)-client since the package could be configured manually (not using dbconfig: there is a debconf question for this purpose). All packages using dbconfig-common are affected by this bug. I think it's better to improve dbconfig-common than adding more code and depends to all other packages. I've CCed to Sean Finney, the dbconfig-common maintainer. Thanks, David.
Processed: Re: Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade
Processing commands for [EMAIL PROTECTED]: clone 398771 -1 Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade Bug 398771 cloned as bug 41. reassign -1 python-support 0.5.5 Bug#41: installing mailman with python 2.3 causes loop condition during python upgrade Bug reassigned from package `mailman' to `python-support'. retitle -1 python-support should warn and not fail when some files can't be byte-compiled Bug#41: installing mailman with python 2.3 causes loop condition during python upgrade Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade
clone 398771 -1 reassign -1 python-support 0.5.5 retitle -1 python-support should warn and not fail when some files can't be byte-compiled thanks On Thu, 16 Nov 2006, Lionel Elie Mamane wrote: This bug, in my opinion, makes the package unsuitable for release with etch. It breaks upgrades from sarge to etch, if I understand well. The bug is both in python-support and in mailman. Python-support shouldn't fail when some files can't be byte-compiled but just warn the user that something is not 100% normal. It looks like wrong to make the installation of python2.4 fail when just one module is kind of broken. Thus the clone and reassign. That file usually is a symlink to /etc/mailman/mm_cfg.py, a configuration file. I'm not terribly convinced it should be compiled at all, actually. It is a bug for it to be compiled unless it is *automatically* read from source when the source is newer than the compiled version. Any python expert could tell me whether it is the case? Alex, you did have the file /etc/mailman/mm_cfg.py, right? At least the file doesn't exist when python2.4 got installed. If the mailman upgrade make the file disappear then this is the RC bug. But since it's a configuration file, it might also be that the user removed it manually and it doesn't get reinstalled because of dpkg's conffile handling. Unless someone comes up with evidence that the file gets removed during a normal upgrade I don't think that this bug is RC. That said I haven't tried the upgrade myself and someone should do that since the bug reporter hasn't confirmed/denied yet. Alex ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#399454: [autodir] [EMAIL PROTECTED]: Bug#399454: autodir: fails with alert: unexpected autofs packet type 3]
On Thu, Nov 23, 2006 at 01:54:40AM -0800, ramana wrote:
First thanks to Ian for providing valuable info for arrving at this
conclusion.
What happened? There is old autofs4 module which supported autofs4
protocol. Autofs team developed new autofs5 protocol but new module
given name as autofs4.
So this is where the problem is. New module is backward compatible with
autofs4 protcol and also supports autofs5 but with the name 'autofs4'.
Everything ok but with the autofs headers.
What can be done?
Until this is resolved, just compile autodir with old
/usr/src/linux/auto_fs4.h and everthing should work fine.
That is the reason older autodir compiled with older header file
working fine with new kernel module autofs4 (which is autofs5)
Since I do not have access to new autofs module on my Fedora, the
testing is going fine -- which is compiled with older autofs module.
And I can not say 100% sure about. (as I said I do not have access to
the latest module and I can not confirm it myself doing tests).
The autofs4-autofs5 update was quite clear. What I find strange
is the problem in cooperating with current (enclosed) auto_fs4.h
header file, which is quite old. Also I see an autofs5 related struct
in the union autofs_packet_union, but shouldn't all that thought
for being back-compatible?
--
Francesco P. Lovergine
/* -*- c -*-
* linux/include/linux/auto_fs4.h
*
* Copyright 1999-2000 Jeremy Fitzhardinge [EMAIL PROTECTED]
*
* This file is part of the Linux kernel and is made available under
* the terms of the GNU General Public License, version 2, or at your
* option, any later version, incorporated herein by reference.
*/
#ifndef _LINUX_AUTO_FS4_H
#define _LINUX_AUTO_FS4_H
/* Include common v3 definitions */
#include linux/auto_fs.h
/* autofs v4 definitions */
#undef AUTOFS_PROTO_VERSION
#undef AUTOFS_MIN_PROTO_VERSION
#undef AUTOFS_MAX_PROTO_VERSION
#define AUTOFS_PROTO_VERSION 5
#define AUTOFS_MIN_PROTO_VERSION 3
#define AUTOFS_MAX_PROTO_VERSION 5
#define AUTOFS_PROTO_SUBVERSION 0
/* Mask for expire behaviour */
#define AUTOFS_EXP_IMMEDIATE 1
#define AUTOFS_EXP_LEAVES 2
/* Daemon notification packet types */
enum autofs_notify {
NFY_NONE,
NFY_MOUNT,
NFY_EXPIRE
};
/* Kernel protocol version 4 packet types */
/* Expire entry (umount request) */
#define autofs_ptype_expire_multi 2
/* Kernel protocol version 5 packet types */
/* Indirect mount missing and expire requests. */
#define autofs_ptype_missing_indirect 3
#define autofs_ptype_expire_indirect 4
/* Direct mount missing and expire requests */
#define autofs_ptype_missing_direct 5
#define autofs_ptype_expire_direct 6
/* v4 multi expire (via pipe) */
struct autofs_packet_expire_multi {
struct autofs_packet_hdr hdr;
autofs_wqt_t wait_queue_token;
int len;
char name[NAME_MAX+1];
};
/* autofs v5 common packet struct */
struct autofs_v5_packet {
struct autofs_packet_hdr hdr;
autofs_wqt_t wait_queue_token;
__u32 dev;
__u64 ino;
__u32 uid;
__u32 gid;
__u32 pid;
__u32 tgid;
__u32 len;
char name[NAME_MAX+1];
};
typedef struct autofs_v5_packet autofs_packet_missing_indirect_t;
typedef struct autofs_v5_packet autofs_packet_expire_indirect_t;
typedef struct autofs_v5_packet autofs_packet_missing_direct_t;
typedef struct autofs_v5_packet autofs_packet_expire_direct_t;
union autofs_packet_union {
struct autofs_packet_hdr hdr;
struct autofs_packet_missing missing;
struct autofs_packet_expire expire;
struct autofs_packet_expire_multi expire_multi;
struct autofs_v5_packet v5_packet;
};
#define AUTOFS_IOC_EXPIRE_MULTI _IOW(0x93,0x66,int)
#define AUTOFS_IOC_EXPIRE_INDIRECT AUTOFS_IOC_EXPIRE_MULTI
#define AUTOFS_IOC_EXPIRE_DIRECT AUTOFS_IOC_EXPIRE_MULTI
#define AUTOFS_IOC_PROTOSUBVER _IOR(0x93,0x67,int)
#define AUTOFS_IOC_ASKREGHOST _IOR(0x93,0x68,int)
#define AUTOFS_IOC_TOGGLEREGHOST_IOR(0x93,0x69,int)
#define AUTOFS_IOC_ASKUMOUNT _IOR(0x93,0x70,int)
#endif /* _LINUX_AUTO_FS4_H */
Bug#398636: marked as done (zope-sqlrelayda: postinst fails: __main__.PyCentralError: package has no field Python-Version)
Your message dated Thu, 23 Nov 2006 11:47:04 + with message-id [EMAIL PROTECTED] and subject line Bug#398636: fixed in sqlrelay 1:0.37.1-3.1 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: zope-sqlrelayda Version: 0.37.1-3 Severity: serious Usertags: grid5000 Hi, During a piuparts run over all the packages in etch, I ran into a problem with your package: Setting up zope-sqlrelayda (0.37.1-3) ... Traceback (most recent call last): File /usr/bin/pycentral, line 1367, in ? main() File /usr/bin/pycentral, line 1361, in main rv = action.run(global_options) File /usr/bin/pycentral, line 868, in run pkg.read_version_info() File /usr/bin/pycentral, line 538, in read_version_info raise PyCentralError, package has no field Python-Version __main__.PyCentralError: package has no field Python-Version dpkg: error processing zope-sqlrelayda (--configure): subprocess post-installation script returned error exit status 1 The full log is available from http://ox.blop.info/bazaar/buildlogs/20061114/ The piuparts run was done on about 40 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | ---End Message--- ---BeginMessage--- Source: sqlrelay Source-Version: 1:0.37.1-3.1 We believe that the bug you reported is fixed in the latest version of sqlrelay, which is due to be installed in the Debian FTP archive: libdbd-sqlrelay-perl_0.37.1-3.1_all.deb to pool/main/s/sqlrelay/libdbd-sqlrelay-perl_0.37.1-3.1_all.deb libfirstworks-sqlr-perl_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/libfirstworks-sqlr-perl_0.37.1-3.1_i386.deb libsqlrelay-0.37_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/libsqlrelay-0.37_0.37.1-3.1_i386.deb libsqlrelay-java_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/libsqlrelay-java_0.37.1-3.1_i386.deb libsqlrelay-ruby_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/libsqlrelay-ruby_0.37.1-3.1_i386.deb libsqlrelay-tcl_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/libsqlrelay-tcl_0.37.1-3.1_i386.deb php5-sqlrelay_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/php5-sqlrelay_0.37.1-3.1_i386.deb python-sqlrelay_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/python-sqlrelay_0.37.1-3.1_i386.deb sqlrelay-config-gtk_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay-config-gtk_0.37.1-3.1_i386.deb sqlrelay-dev_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay-dev_0.37.1-3.1_i386.deb sqlrelay-doc_0.37.1-3.1_all.deb to pool/main/s/sqlrelay/sqlrelay-doc_0.37.1-3.1_all.deb sqlrelay-freetds_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay-freetds_0.37.1-3.1_i386.deb sqlrelay-mdb_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay-mdb_0.37.1-3.1_i386.deb sqlrelay-mysql_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay-mysql_0.37.1-3.1_i386.deb sqlrelay-odbc_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay-odbc_0.37.1-3.1_i386.deb sqlrelay-postgresql_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay-postgresql_0.37.1-3.1_i386.deb sqlrelay-sqlite_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay-sqlite_0.37.1-3.1_i386.deb sqlrelay-test_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay-test_0.37.1-3.1_i386.deb sqlrelay_0.37.1-3.1.diff.gz to pool/main/s/sqlrelay/sqlrelay_0.37.1-3.1.diff.gz sqlrelay_0.37.1-3.1.dsc to pool/main/s/sqlrelay/sqlrelay_0.37.1-3.1.dsc sqlrelay_0.37.1-3.1_i386.deb to pool/main/s/sqlrelay/sqlrelay_0.37.1-3.1_i386.deb zope-sqlrelayda_0.37.1-3.1_all.deb to pool/main/s/sqlrelay/zope-sqlrelayda_0.37.1-3.1_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Raphael Hertzog [EMAIL PROTECTED] (supplier of updated sqlrelay package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by
Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade
On Thu, Nov 23, 2006 at 12:42:10PM +0100, Raphael Hertzog wrote: On Thu, 16 Nov 2006, Lionel Elie Mamane wrote: That file usually is a symlink to /etc/mailman/mm_cfg.py, a configuration file. I'm not terribly convinced it should be compiled at all, actually. Alex, you did have the file /etc/mailman/mm_cfg.py, right? At least the file doesn't exist when python2.4 got installed. If the mailman upgrade make the file disappear then this is the RC bug. That's unlikely; reading the maintainer scripts shows that the only case where it moves it away is temporary and in the sequence: mv /etc/mailman/mm_cfg.py /etc/mailman/mm_cfg.py.old mv /etc/mailman/mm_cfg.py.new /etc/mailman/mm_cfg.py (It never rms it.) But since it's a configuration file, it might also be that the user removed it manually and it doesn't get reinstalled because of dpkg's conffile handling. I just checked, it is not a conffile. It is a configuration file, though. We have just found another RC bug in mailman: If the user removes it, it gets recreated with an automatically generated one: case $1 in configure|abort-upgrade|abort-remove|abort-deconfigure) if [ ! -e /etc/$PACKAGE/mm_cfg.py ]; then echo Configuring $PACKAGE for domain $DOMAIN ... sed s/thunderchild.aszi.sztaki.hu/$DOMAIN/g /usr/lib/mailman/Mailman/mm_cfg.py.dist \ /etc/$PACKAGE/mm_cfg.py fi ;; esac -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400005: Installs files in /var/lib/mailman in violation of FHS
Package: mailman Version: 1:2.1.8-3 Severity: serious Justification: Etch RC Policy 5.(c) Tags: pending (Bug is present up to and including 1:2.1.9-2.) Mailman installs architecture-independent program files not written except at install/upgrade time in /var/lib/mailman/pythonlib/email/ . That's a gross violation of the FHS, which mandates /usr/ instead of /var/ . 1:2.1.9-3 will make it /usr/lib/mailman/pythonlib/email, which is still suboptimal (the non-compiled files should be in /usr/share, being architecture-independent), and may technically still be a violation, although not a gross one, but more difficult to achieve (the files are compiled at install/upgrade time; the compiled versions must be in /usr/lib; not sure there even _is_ a way to have sources and compiled versions separated in Python - if any Python expert can contradict me on that, please do! Possibly the Debian python-packaging automating tools already handle this /usr/share and /usr/lib thing decently, but this has to be checked, and is doubtful, since /usr/lib/python2.4 contains so many .py files). -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399454: [autodir] [EMAIL PROTECTED]: Bug#399454: autodir: fails with alert: unexpected autofs packet type 3]
On Thu, Nov 23, 2006 at 12:49:18PM +0100, Francesco P. Lovergine wrote: The autofs4-autofs5 update was quite clear. What I find strange is the problem in cooperating with current (enclosed) auto_fs4.h header file, which is quite old. Also I see an autofs5 related struct in the union autofs_packet_union, but shouldn't all that thought for being back-compatible? As I was suspecting, also 0.99.3 does not work after rebuilding on 2.6.16 even. I think current protocol compatibility check in autodir requires changes, because 5 support both 3 and 4, as 4 supported 3 also. So checkin' in the way I see in the code is a bit rough. I checked around and also gentoo will have the same problem, and probably others (its header is exactly the same). Are u using the following edition of the auto_fs4.h header? http://www.google.com/codesearch?hl=itq=+auto_fs4.h+show:_rs8_UhtGC8:DyN5NdmJ0Bg:1Kn_jMjXj98sa=Ncd=1ct=rccs_p=http://www.kernel.org/pub/linux/daemons/autofs/testing-v4/autofs-4.0.0pre10.tar.bz2cs_f=autofs-4.0.0pre10/include/linux/auto_fs4.h#a0 it is indeed outdated. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade
On Thu, Nov 23, 2006 at 01:22:35PM +0100, Lionel Elie Mamane wrote: On Thu, Nov 23, 2006 at 12:42:10PM +0100, Raphael Hertzog wrote: On Thu, 16 Nov 2006, Lionel Elie Mamane wrote: That file usually is a symlink to /etc/mailman/mm_cfg.py, a configuration file. I'm not terribly convinced it should be compiled at all, actually. But since it's a configuration file, it might also be that the user removed it manually and it doesn't get reinstalled because of dpkg's conffile handling. I just checked, it is not a conffile. ... and not shipped by the package, but created by the postinst. Which means this also breaks _new_ installs as far as I understand it because if: - mailman gets unpacked _before_ - python2.4 gets configured _before_ - mailman gets configured That last bit _will_ tend to happen since dpkg tries to configure dependencies before the package itself. The first bit may or may not happen. That's also harder to fix from mailman's side, if possible at all. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#399995: wodim: Error trying to dist-upgrade
Processing commands for [EMAIL PROTECTED]: tags 35 + moreinfo Bug#35: wodim: Error trying to dist-upgrade There were no tags set. Tags added: moreinfo thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400010: mailman: Fails to respect admin deletion of configuration file
Package: mailman Version: 1:2.1.9-1 Severity: serious Justification: Etch RC policy: 3 - last paragraph Quoting Etch RC policy: Changes to configuration files must be preserved during a package upgrade. Configurations must be preserved on package removal, and only deleted when the package is purged. But a deleted /etc/mailman/mm_cfg.py gets recreated automatically the next time the postinst script is run in any way: case $1 in configure|abort-upgrade|abort-remove|abort-deconfigure) if [ ! -e /etc/$PACKAGE/mm_cfg.py ]; then echo Configuring $PACKAGE for domain $DOMAIN ... sed s/thunderchild.aszi.sztaki.hu/$DOMAIN/g /usr/lib/mailman/Mailman/mm_cfg.py.dist \ /etc/$PACKAGE/mm_cfg.py fi ;; esac This is further complicated by the fact that a missing /etc/mailman/mm_cfg.py makes the new-pyton-policy-mandated bytecode compile fail. We should probably not ship the symlink from /var/lib/mailman/Mailman/mm_cfg.py to /etc/mailman/mm_cfg.py in the package, but handle it manually in sync with the file itself. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400005: Installs files in /var/lib/mailman in violation of FHS
On Thu, Nov 23, 2006 at 01:41:08PM +0100, Lionel Elie Mamane wrote: 1:2.1.9-3 will make it /usr/lib/mailman/pythonlib/email, which is still suboptimal (the non-compiled files should be in /usr/share, being architecture-independent), and may technically still be a violation, although not a gross one, but more difficult to achieve (the files are compiled at install/upgrade time; the compiled versions must be in /usr/lib; POX on #debian-python informs me that .pyc files are architecture-independent, too. So we can safely move the whole bunch (directories Mailman, pythonlib, ...) to /usr/share/mailman/. We should also move bin, cron, scripts. Only mail should stay in /usr/lib. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399995: wodim: Error trying to dist-upgrade
tags 35 + moreinfo thanks #include hallo.h * Mind Booster Noori [Thu, Nov 23 2006, 10:58:22AM]: Package: wodim Severity: serious Justification: Error trying to dist-upgrade I don't know if I reporting to the right package, and also dunno if serious is the right severity... sorry :-( While trying to apt-get dist-upgrade to etch, I got this: Unpacking wodim (from .../wodim_5%3a1.0-1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/wodim_5%3a1.0-1_i386.deb (--unpack): trying to overwrite `/usr/share/man/man1/readcd.1.gz', which is also in package cdrecord dpkg-deb: subprocess paste killed by signal (Broken pipe) Unexplainable. Could be a bug in APT. Please send your /var/log/dpkg.log file (compressed with gzip). Eduard. -- -!- RomanK (Roman Kreisel) [EMAIL PROTECTED] has joined #debian.de RomanK oh mist! keine nackt-chats? -!- RomanK [EMAIL PROTECTED] has left #debian.de [] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400001: python-support: possible patch
tags 41 + patch
thanks
Hi,
Attached is a possible patch to fix this issue. I tested it here by
creating an error in a private module:
$ sudo /var/lib/dpkg/info/linda.postinst configure
WARNING: compile error while trying to byte-compile
/usr/share/linda/checks/shebang.py: File
/usr/share/linda/checks/shebang.py, line 4
; + beur
^
SyntaxError: invalid syntax
(sid) [EMAIL PROTECTED]:~/local/debian$ echo $?
0
Note however that the problem only existed with private modules since the
public modules are byte-compiled by compile_all which is spawned as a
separate process and whose return value we don't check. However the process
displays similar warnings.
For consistency of output I decided to ask compile() to raise an exception but
in fact it's not really needed. I could have checked only the IOError
exception (or only the generic one).
Feel free to adapt to suit your needs.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -Nru /tmp/9tKXsR3naN/python-support-0.5.5/debian/changelog
/tmp/9DkRb9y0Lf/python-support-0.5.6/debian/changelog
--- /tmp/9tKXsR3naN/python-support-0.5.5/debian/changelog 2006-11-14
21:27:26.0 +0100
+++ /tmp/9DkRb9y0Lf/python-support-0.5.6/debian/changelog 2006-11-23
14:12:08.0 +0100
@@ -1,3 +1,11 @@
+python-support (0.5.6) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Don't raise IOError while trying to byte-compile an *.py file (for example,
+when the file is a symlink to a non-existent file). Closes: #41
+
+ -- Raphael Hertzog [EMAIL PROTECTED] Thu, 23 Nov 2006 14:10:25 +0100
+
python-support (0.5.5) unstable; urgency=high
* dh_pysupport, pysupport-movemodules, debian/rules,
diff -Nru /tmp/9tKXsR3naN/python-support-0.5.5/update-python-modules
/tmp/9DkRb9y0Lf/python-support-0.5.6/update-python-modules
--- /tmp/9tKXsR3naN/python-support-0.5.5/update-python-modules 2006-09-22
21:12:04.0 +0200
+++ /tmp/9DkRb9y0Lf/python-support-0.5.6/update-python-modules 2006-11-23
14:19:45.0 +0100
@@ -6,7 +6,7 @@
import sys,os,os.path
from optparse import OptionParser
-from py_compile import compile
+from py_compile import compile, PyCompileError
basepath='/var/lib/python-support'
sourcepath='/usr/share/python-support'
@@ -87,7 +87,15 @@
if file.endswith('.py'):
fullpath=os.path.join(basedir,dir,file)
debug(compile +fullpath+'c')
-compile(fullpath)
+try:
+ # Not that compile doesn't raise PyCompileError by default
+ compile(fullpath, doraise=True)
+except IOError, (errno, strerror):
+ print sys.stderr, WARNING: I/O error while trying to byte-compile %s
(%s): %s % (fullpath, errno, strerror)
+except PyCompileError, inst:
+ print sys.stderr, WARNING: compile error while trying to byte-compile
%s: %s % (fullpath, inst.msg)
+except:
+ print sys.stderr, WARNING: unexpected error while trying to
byte-compile %s: %s % (fullpath, sys.exc_info()[0])
def clean_simple(basedir,dir,file):
if file.endswith('.py'):
Processed: python-support: possible patch
Processing commands for [EMAIL PROTECTED]: tags 41 + patch Bug#41: python-support should warn and not fail when some files can't be byte-compiled There were no tags set. Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399454: [autodir] [EMAIL PROTECTED]: Bug#399454: autodir: fails with alert: unexpected autofs packet type 3]
Yep. I missied your concerns.
Provided the problem is with upgradtion of module, then,
I though about second possibility without touching auto_fs4.h.
All that needed is to redefine following definitions.
#define AUTOFS_PROTO_VERSION5
#define AUTOFS_MIN_PROTO_VERSION3
#define AUTOFS_MAX_PROTO_VERSION5
I think this should be enough.
And I asked Ian for openion and waiting for his reply.
As for the compatibility check, Autodir supports only protocol 4 and in
the future 5. So only check for protocol 4 is needed at this moment.
Autodir was build on autofs 3 protocol initially but it was dropped as
it was planned to be discontinued by Ian.
Regards
ramana
--- Francesco P. Lovergine [EMAIL PROTECTED] wrote:
On Thu, Nov 23, 2006 at 01:54:40AM -0800, ramana wrote:
First thanks to Ian for providing valuable info for arrving at this
conclusion.
What happened? There is old autofs4 module which supported autofs4
protocol. Autofs team developed new autofs5 protocol but new module
given name as autofs4.
So this is where the problem is. New module is backward compatible
with
autofs4 protcol and also supports autofs5 but with the name
'autofs4'.
Everything ok but with the autofs headers.
What can be done?
Until this is resolved, just compile autodir with old
/usr/src/linux/auto_fs4.h and everthing should work fine.
That is the reason older autodir compiled with older header file
working fine with new kernel module autofs4 (which is autofs5)
Since I do not have access to new autofs module on my Fedora, the
testing is going fine -- which is compiled with older autofs
module.
And I can not say 100% sure about. (as I said I do not have access
to
the latest module and I can not confirm it myself doing tests).
The autofs4-autofs5 update was quite clear. What I find strange
is the problem in cooperating with current (enclosed) auto_fs4.h
header file, which is quite old. Also I see an autofs5 related struct
in the union autofs_packet_union, but shouldn't all that thought
for being back-compatible?
--
Francesco P. Lovergine
/* -*- c -*-
* linux/include/linux/auto_fs4.h
*
* Copyright 1999-2000 Jeremy Fitzhardinge [EMAIL PROTECTED]
*
* This file is part of the Linux kernel and is made available under
* the terms of the GNU General Public License, version 2, or at your
* option, any later version, incorporated herein by reference.
*/
#ifndef _LINUX_AUTO_FS4_H
#define _LINUX_AUTO_FS4_H
/* Include common v3 definitions */
#include linux/auto_fs.h
/* autofs v4 definitions */
#undef AUTOFS_PROTO_VERSION
#undef AUTOFS_MIN_PROTO_VERSION
#undef AUTOFS_MAX_PROTO_VERSION
#define AUTOFS_PROTO_VERSION 5
#define AUTOFS_MIN_PROTO_VERSION 3
#define AUTOFS_MAX_PROTO_VERSION 5
#define AUTOFS_PROTO_SUBVERSION 0
/* Mask for expire behaviour */
#define AUTOFS_EXP_IMMEDIATE 1
#define AUTOFS_EXP_LEAVES 2
/* Daemon notification packet types */
enum autofs_notify {
NFY_NONE,
NFY_MOUNT,
NFY_EXPIRE
};
/* Kernel protocol version 4 packet types */
/* Expire entry (umount request) */
#define autofs_ptype_expire_multi 2
/* Kernel protocol version 5 packet types */
/* Indirect mount missing and expire requests. */
#define autofs_ptype_missing_indirect 3
#define autofs_ptype_expire_indirect 4
/* Direct mount missing and expire requests */
#define autofs_ptype_missing_direct 5
#define autofs_ptype_expire_direct6
/* v4 multi expire (via pipe) */
struct autofs_packet_expire_multi {
struct autofs_packet_hdr hdr;
autofs_wqt_t wait_queue_token;
int len;
char name[NAME_MAX+1];
};
/* autofs v5 common packet struct */
struct autofs_v5_packet {
struct autofs_packet_hdr hdr;
autofs_wqt_t wait_queue_token;
__u32 dev;
__u64 ino;
__u32 uid;
__u32 gid;
__u32 pid;
__u32 tgid;
__u32 len;
char name[NAME_MAX+1];
};
typedef struct autofs_v5_packet autofs_packet_missing_indirect_t;
typedef struct autofs_v5_packet autofs_packet_expire_indirect_t;
typedef struct autofs_v5_packet autofs_packet_missing_direct_t;
typedef struct autofs_v5_packet autofs_packet_expire_direct_t;
union autofs_packet_union {
struct autofs_packet_hdr hdr;
struct autofs_packet_missing missing;
struct autofs_packet_expire expire;
struct autofs_packet_expire_multi expire_multi;
struct autofs_v5_packet v5_packet;
};
#define AUTOFS_IOC_EXPIRE_MULTI _IOW(0x93,0x66,int)
#define AUTOFS_IOC_EXPIRE_INDIRECTAUTOFS_IOC_EXPIRE_MULTI
#define AUTOFS_IOC_EXPIRE_DIRECT AUTOFS_IOC_EXPIRE_MULTI
#define AUTOFS_IOC_PROTOSUBVER_IOR(0x93,0x67,int)
#define AUTOFS_IOC_ASKREGHOST _IOR(0x93,0x68,int)
#define AUTOFS_IOC_TOGGLEREGHOST_IOR(0x93,0x69,int)
Bug#390429: Simple changes to build bcm5700 on 2.6.18
Package: bcm5700-source Version: 8.2.18-2 Followup-For: Bug #390429 Hi! Just wanted to mention that your patch is working fine here (Dell Optiplex GX260 with a BCM5751 Adapter, I wanted to test if a problem related to tg3 module). Ciao Sebastian -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399670:
any chance of an english translation of those error messages? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399776: apache2: Apache 2.2 spawns lots of processes and freeze the box
http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS also notes memory leaks in mod_deflate and mod_mem_cache. Do you use one of these? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400025: jokosher: cannot start jokosher 0.2-1
Package: jokosher Version: 0.2-1 Severity: grave Jokosher 0.2-1 will not run for me at all from the command line [EMAIL PROTECTED]:~/linux-audio/jokosher]% jokosher Error loading Jokosher: No module named pkg_resources -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-486 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages jokosher depends on: ii gstreamer0.10-gnomevfs0.10.10-2 GStreamer plugin for GnomeVFS ii gstreamer0.10-gnonlin 0.10.5-1 non-linear editing module for GStr ii gstreamer0.10-plugins-base0.10.10-2 GStreamer plugins from the base ii gstreamer0.10-plugins-good0.10.4-3 GStreamer plugins from the good ii librsvg2-common 2.14.4-2 SAX-based renderer library for SVG ii python2.4.4-1An interactive high-level object-o ii python-alsaaudio 0.2-1 Alsa bindings for Python ii python-cairo 1.2.0-1Python bindings for the Cairo vect ii python-dbus 0.71-3 simple interprocess messaging syst ii python-glade2 2.8.6-6GTK+ bindings: Glade support ii python-gst0.100.10.5-5 generic media-playing framework (P ii python-gtk2 2.8.6-6Python bindings for the GTK+ widge ii python-support0.5.5 automated rebuilding support for p jokosher recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399776: apache2: Apache 2.2 spawns lots of processes and freeze the box
We have mod_python, redirection with mod_proxy/mod_rewrite, PHP with memory limit set to 32M, DAV and DAV/SVN. The are no errors or other interesting entries in apache logs nor in any other log. Maybe you could try disabling modules one by one to see which one is the cause? There are reports about memory leaks in mod_python (with more than one handler): http://issues.apache.org/jira/browse/MODPYTHON-181?page=all and mod_proxy: http://www.modsecurity.org/blog/archives/2006/08/apache_reverse.html Try whether MaxRequestsPerChild, MaxKeepAliveRequests, etc. help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade
On Thu, 23 Nov 2006, Lionel Elie Mamane wrote: I just checked, it is not a conffile. ... and not shipped by the package, but created by the postinst. Which means this also breaks _new_ installs as far as I understand it because if: - mailman gets unpacked _before_ - python2.4 gets configured _before_ - mailman gets configured That last bit _will_ tend to happen since dpkg tries to configure dependencies before the package itself. The first bit may or may not happen. That's also harder to fix from mailman's side, if possible at all. There's the possibility of not including the symlink in the package but creating it at the same time when you create /etc/mailman/mm_cfg.py. This should do the trick although you must double check what's happening during upgrade since the config file might temporary disappear and this might lead to errors in the init script. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#399776: apache2: Apache 2.2 spawns lots of processes and freeze the box
Il giorno gio, 23/11/2006 alle 15.42 +0100, Stefan Fritsch ha scritto: http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS also notes memory leaks in mod_deflate and mod_mem_cache. Do you use one of these? Definitely no. -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] monja: che c'entra, l'importante è sapersi usare -- dani signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Processed (with 1 errors): close 400025
Processing commands for [EMAIL PROTECTED]: = Unknown command or malformed arguments to command. close #400025 Bug#400025: jokosher: cannot start jokosher 0.2-1 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Angelina Carlton [EMAIL PROTECTED] thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399995: wodim: Error trying to dist-upgrade
Unexplainable. Could be a bug in APT. Please send
your /var/log/dpkg.log file (compressed with gzip).
I would gladly do it, but I just found that my /var/log/dpkg.log was an
empty file... I enabeled logging, did an apt-get -f install, and the log
just says:
2006-11-23 15:28:45 install wodim none 5:1.0-1
2006-11-23 15:28:45 status half-installed wodim 5:1.0-1
2006-11-23 15:28:45 status not-installed wodim none
Can I give you any other info?
--
Marcos Marado [EMAIL PROTECTED]
Sonaecom ISP
$ cat sig.pl
''=~('(?{'.('^)@@*@'^'.[).^`').''.('`@@[EMAIL
PROTECTED]//[*;)@`//)@|'^'-).[`@@(^^[`.@@[)^').',$/})')
$
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400033: libopenal0a_0.0.8-1_i386.deb doesn't create /etc/openalrc
Package: libopenal0 Version: 1:0.0.8-1 Severity: grave OpenAL doesn't work, because libopenal0a_0.0.8-1_i386.deb doesn't create /etc/openalrc. File /etc/openalrc must contain string: (define devices '(arts alsa native sdl esd null)) Without this file sound in some games doesn't work (for example Chromium) or games crashes (Scorched3D). And Debian etch doesn't have man page about configure openal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 400021 is serious
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.22 severity 400021 serious Bug#400021: Missing depend on python-setuptools Severity set to `serious' from `normal' End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398634: [phpgacl] alternative patch without hard dependencies on both db clients.
hi guys, On Thu, 2006-11-23 at 12:30 +0100, David Gil wrote: Maybe I am completely wrong, but phpgacl does not need (mysql| postgresql)-client, dbconfig-common needs them (#353617). I am not happy to make phpgacl depends on (mysql|postgresql)-client since the package could be configured manually (not using dbconfig: there is a debconf question for this purpose). All packages using dbconfig-common are affected by this bug. I think it's better to improve dbconfig-common than adding more code and depends to all other packages. there's an open bug on this for the dbconfig-common package, actually. the tricky thing is we want to avoid depending on every supported database client (it'd be annoying to have to install postgres libs/clients for a mysql app and vice versa). but at the same time, it's silly to offer to configure an application for mysql if the mysql client isn't available. there have been a few propsed solutions, but nothing substantial has resulted from it yet. iirc, the general idea is that: (a) the packages in question should still have (foo | bar) depends on cmdline clients. (b) in dbconfig-common, if the user selects an option for cmdline clients that aren't installed, they're prompted with an error dialog, the dbconfig-common hooks gracefully stop (or perhaps they're given a choice to go back and choose another dbtype). (c) if the admin later installs the required cmdline packages, they should be able to dpkg-reconfigure the dbc-using package to use the new dbtype as always. sean signature.asc Description: This is a digitally signed message part
Bug#399995: wodim: Error trying to dist-upgrade
#include hallo.h * Marcos Daniel Marado Torres [Thu, Nov 23 2006, 03:36:01PM]: Unexplainable. Could be a bug in APT. Please send your /var/log/dpkg.log file (compressed with gzip). I would gladly do it, but I just found that my /var/log/dpkg.log was an empty file... I enabeled logging, did an apt-get -f install, and the log just says: 2006-11-23 15:28:45 install wodim none 5:1.0-1 2006-11-23 15:28:45 status half-installed wodim 5:1.0-1 2006-11-23 15:28:45 status not-installed wodim none Can I give you any other info? Maybe. The package dependencies state that apt shall remove the old cdrecord before installing wodim. How does the state of your current cdrecord look like? Do dpkg -l cdrecord please, don't reinstall it yet. Then, try: apt-get -o Debug::pkgProblemResolver=true -o Debug::pkgOrderList=true install wodim Eduard. -- HE Meine Güte, wegen euch verschwindet immer die Hälfte meines Tees im Schreibtisch...
Bug#400047: blitz++: FTBFS: build-depends on frozen debhelper = 5.0.41
Package: blitz++ Version: 1:0.9-1.2 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. Relevant parts: Setting up gettext (0.15-3) ... [...] Checking correctness of source dependencies... After installing, the following source dependencies are still unsatisfied: debhelper(inst 5.0.40 ! = wanted 5.0.41) Source-dependencies not satisfied; skipping blitz++ About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400049: dillo: FTBFS: error: freetype/config/ftheader.h: No such file or directory
Package: dillo Version: 0.8.5-4 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. Relevant parts: make[4]: Entering directory `/build/root/dillo-0.8.5/src/IO' if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -g -O2 -DENABLE_IPV6 -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -MT mime.o -MD -MP -MF .deps/mime.Tpo -c -o mime.o mime.c; \ then mv -f .deps/mime.Tpo .deps/mime.Po; else rm -f .deps/mime.Tpo; exit 1; fi In file included from /usr/include/X11/Xft/Xft.h:41, from ../dw_style.h:8, from ../dw_widget.h:8, from mime.h:12, from mime.c:14: /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory In file included from ../dw_style.h:8, from ../dw_widget.h:8, from mime.h:12, from mime.c:14: /usr/include/X11/Xft/Xft.h:42:10: error: #include expects FILENAME or FILENAME In file included from ../dw_style.h:8, from ../dw_widget.h:8, from mime.h:12, from mime.c:14: /usr/include/X11/Xft/Xft.h:62: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_XftFTlibrary' /usr/include/X11/Xft/Xft.h:96: error: expected specifier-qualifier-list before 'FT_UInt' /usr/include/X11/Xft/Xft.h:103: error: expected specifier-qualifier-list before 'FT_UInt' /usr/include/X11/Xft/Xft.h:200: error: expected ';', ',' or ')' before '*' token /usr/include/X11/Xft/Xft.h:305: error: expected ';', ',' or ')' before '*' token /usr/include/X11/Xft/Xft.h:364: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XftLockFace' /usr/include/X11/Xft/Xft.h:403: error: expected ';', ',' or ')' before '*' token /usr/include/X11/Xft/Xft.h:409: error: expected ';', ',' or ')' before '*' token /usr/include/X11/Xft/Xft.h:418: error: expected declaration specifiers or '...' before 'FT_UInt' /usr/include/X11/Xft/Xft.h:419: error: expected declaration specifiers or '...' before 'FT_UInt' /usr/include/X11/Xft/Xft.h:428: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XftCharIndex' /usr/include/X11/Xft/Xft.h:471: error: expected ';', ',' or ')' before '*' token make[4]: *** [mime.o] Error 1 make[4]: Leaving directory `/build/root/dillo-0.8.5/src/IO' make[3]: *** [all-recursive] Error 1 The full build log is available from http://ox.blop.info/bazaar/buildlogs/20061122/ About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400051: antigravitaattori: Segfault attempting to start; fail to load texture
Package: antigravitaattori Version: 0.0.2-2 Severity: grave Justification: renders package unusable Attempting to start the game, i get: [EMAIL PROTECTED]:~$ antigrav libpng error: Invalid image width setjmp: Success Invalid: can't load texture racer.png libpng error: Invalid image width setjmp: Success Can't load texture road.png Erreur de segmentation Erreur de segmentation translates to Segmentation fault. -Pascal -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-amd64 Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) Versions of packages antigravitaattori depends on: ii libalut0 1.0.1-1 OpenAL Utility Toolkit ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-20 GCC support library ii libgl1-mesa-glx [libgl1] 6.5.1-0.4 A free implementation of the OpenG ii libglu1-mesa [libglu1] 6.5.1-0.4 The OpenGL utility library (GLU) ii libopenal0a 1:0.0.8-1 OpenAL is a portable library for 3 ii libpng12-0 1.2.13-4PNG library - runtime ii libsdl1.2debian 1.2.11-7Simple DirectMedia Layer ii libstdc++6 4.1.1-20The GNU Standard C++ Library v3 antigravitaattori recommends no packages. -- no debconf information -- Homepage (http://organact.mine.nu) Debian GNU/Linux (http://www.debian.org) École de technologie supérieure (http://www.etsmtl.ca)
Bug#400050: brickos_0.9.0.dfsg-1(ia64/unstable): FTBFS: invalid operands
Package: brickos Version: 0.9.0.dfsg-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of brickos_0.9.0.dfsg-1 on caballero by sbuild/ia64 85 Build started at 20061123-0912 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper ( 4.0.0), binutils-h8300-hms, gcc-h8300-hms, sgmltools-lite, doxygen [...] /usr/bin/h8300-hms-as divsf3.s -o divsf3.o /usr/bin/h8300-hms-as floatsisf.s -o floatsisf.o floatsisf.s: Assembler messages: floatsisf.s:138: Warning: mismatch between opcode size and operand size /usr/bin/h8300-hms-as cmpsf2.s -o cmpsf2.o /usr/bin/h8300-hms-as fixsfsi.s -o fixsfsi.o fixsfsi.s: Assembler messages: fixsfsi.s:195: Error: invalid operands make[3]: *** [fixsfsi.o] Error 1 make[3]: Leaving directory `/build/buildd/brickos-0.9.0.dfsg/lib/float' make[2]: *** [all] Error 2 make[2]: Leaving directory `/build/buildd/brickos-0.9.0.dfsg/lib' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/brickos-0.9.0.dfsg' make: *** [build-arch-stamp] Error 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=ia64pkg=brickosver=0.9.0.dfsg-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400056: planet-penguin-racer: Xorg goes to 99.4% cpu usage on starting game
Package: planet-penguin-racer Version: 0.3.1-8 Severity: grave Justification: renders package unusable On start up of ppracer Xorg uses 99.4% cpu resources and ppracer gives extremely sluggish response. There is approximately a 2 second lag between moving the mouse and the cursor itself moving during setup. This is happening on an HP Pavillion laptop with a 2 ghz AMD Turion, an ATI XPress 200M graphics card, and 1 gig of ram. When ppracer is run inside a window rather than full screen I get normal keyboard and mouse response outside that window. Other applications do not seem to respond sluggishly either even though top is reporting such high cpu usage. It's just ppracer that acts extremely slugglishly. I have both KDE and Gnome installed, but have only run ppracer inside Gnome. My system is also fully up-to-date as I ran dist-upgrade just before installing ppracer. I have separate 32 and 64 bit installs on this same machine and ppracer acts the same way in both environments. I have also run this with the ati kernel module and with the fglrx module. I installed the fglrx kernel using m-a and it provided no performance improvement. I have also tried this with ATI's proprietary drivers and game performance was still the same. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-486 Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400055: loop-aes-modules: FTBFS: build-dep on removed package loop-aes-source
Package: loop-aes-modules Version: 3.1d+3+5 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. Your package depends on loop-aes-source (= 3.1d-3), but this package was removed from Debian. About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399995: wodim: Error trying to dist-upgrade
Do dpkg -l cdrecord please, don't reinstall it yet. [EMAIL PROTECTED]:~# dpkg -l cdrecord Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii cdrecord 2.01+01a01-5 command line CD writing tool Hmmm... Maybe this cdrecord version isn't official? [EMAIL PROTECTED]:~# apt-show-versions cdrecord cdrecord 8:2.01+01a01-5 newer than version in archive [EMAIL PROTECTED]:~# Maybe this is the problem? apt-get -o Debug::pkgProblemResolver=true -o Debug::pkgOrderList=true install wodim typescript.gz follows in attachment. typescript.gz Description: typescript.gz
Bug#400057: libbonobomm1.3: FTBFS: orbit-idl-2: Unknown option -lcpp
Package: libbonobomm1.3 Version: 1.3.8-3 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. Relevant parts: Making all in generated make[4]: Entering directory `/build/root/libbonobomm1.3-1.3.8/bonobomm/generated' /usr/bin/orbit-idl-2 --headerguardprefix=BONOBOMM_ -I//usr/share/idl/bonobo-2.0 -I//usr/share/idl/bonobo-activation-2.0 /usr/share/idl/ bonobo-2.0/Bonobo.idl orbit-idl-2 2.14.3 compiling mode, hide preprocessor errors, passes: stubs skels common headers Processing file /usr/share/idl/bonobo-2.0/Bonobo.idl /usr/bin/orbit-idl-2 -lcpp -D__Bonobo_COMPILATION -D__Bonobo_Unknown_COMPILATION -D__Bonobo_GenericFactory_COMPILATION -D__Bonobo_Acti vation_types_COMPILATION -I//usr/share/idl/bonobo-2.0 -I//usr/share/idl/bonobo-activation-2.0 /usr/share/idl/bonobo-2.0/Bonobo.idl orbit-idl-2: Unknown option -lcpp make[4]: *** [Bonobo.h] Error 1 The full build log is available from http://ox.blop.info/bazaar/buildlogs/20061122/ About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400052: autoprofile_2.14-2+b1(ia64/unstable): FTBFS: compiler errors
Package: autoprofile Version: 2.14-2+b1 Severity: serious There was an error while trying to autobuild your package: Automatic build of autoprofile_2.14-2+b1 on caballero by sbuild/ia64 85 Build started at 20061123-0556 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 4.0.0), gaim-dev (= 1:2.0.0), libgtk2.0-dev, dpatch [...] src/comp_logstats.c:386: warning: incompatible implicit declaration of built-in function 'strdup' src/comp_logstats.c:387: warning: incompatible implicit declaration of built-in function 'strlen' src/comp_logstats.c:412: warning: incompatible implicit declaration of built-in function 'strdup' src/comp_logstats.c: In function 'logstats_conv_created': src/comp_logstats.c:682: warning: incompatible implicit declaration of built-in function 'strdup' src/comp_logstats.c: In function 'logstats_generate': src/comp_logstats.c:987: warning: implicit declaration of function 'strcpy' src/comp_logstats.c:987: warning: incompatible implicit declaration of built-in function 'strcpy' src/comp_logstats.c:995: warning: incompatible implicit declaration of built-in function 'strcpy' gcc -O2 -Wall -fpic -g -I../gaim -I../gaim/src -I../.. -I../../src -I/usr/include/gaim -I/usr/include/gaim/src -I/usr/include -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/include -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include `pkg-config --cflags gtk+-2.0 gaim` -DHAVE_CONFIG_H -c src/comp_logstats_gtk.c -o src/comp_logstats_gtk.o In file included from src/comp_logstats_gtk.c:24: src/autoprofile.h:30:20: error: config.h: No such file or directory make[1]: *** [src/comp_logstats_gtk.o] Error 1 make[1]: Leaving directory `/build/buildd/autoprofile-2.14' make: *** [build-stamp] Error 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=ia64pkg=autoprofilever=2.14-2+b1 Also note that all those implicit declarations may result in segv's on 64-bit architectures. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400060: emacs-snapshot_1:20061117-1(ia64/unstable): FTBFS: mark_memory
Package: emacs-snapshot Version: 1:20061117-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of emacs-snapshot_1:20061117-1 on caballero by sbuild/ia64 85 Build started at 20061123-0510 [...] ** Using build dependencies supplied by package: Build-Depends: libncurses5-dev, texinfo, liblockfile-dev, libungif4-dev, libtiff-dev, xaw3dg-dev, libpng12-dev, libjpeg62-dev, libgtk2.0-dev, autotools-dev, autoconf (= 2.54), dpkg-dev ( 1.10.0), dpatch (= 2.0.9), debhelper (= 5.0.0), libxaw7-dev, libasound2-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] [...] ia64-linux-gnu-gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/build/buildd/emacs-snapshot-20061117/src -D_BSD_SOURCE -I/usr/include/alsa -DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2 casefiddle.c ia64-linux-gnu-gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/build/buildd/emacs-snapshot-20061117/src -D_BSD_SOURCE -I/usr/include/alsa -DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2 indent.c ia64-linux-gnu-gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/build/buildd/emacs-snapshot-20061117/src -D_BSD_SOURCE -I/usr/include/alsa -DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2 search.c ia64-linux-gnu-gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/build/buildd/emacs-snapshot-20061117/src -D_BSD_SOURCE -I/usr/include/alsa -DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2 regex.c ia64-linux-gnu-gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/build/buildd/emacs-snapshot-20061117/src -D_BSD_SOURCE -I/usr/include/alsa -DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2 undo.c ia64-linux-gnu-gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/build/buildd/emacs-snapshot-20061117/src -D_BSD_SOURCE -I/usr/include/alsa -DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2 alloc.c alloc.c: In function 'mark_stack': alloc.c:4609: error: too few arguments to function 'mark_memory' make[3]: *** [alloc.o] Error 1 make[3]: Leaving directory `/build/buildd/emacs-snapshot-20061117/src' make[2]: *** [bootstrap-build] Error 2 make[2]: Leaving directory `/build/buildd/emacs-snapshot-20061117' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/build/buildd/emacs-snapshot-20061117' make: *** [bootstrap-stamp] Error 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=ia64pkg=emacs-snapshotver=1:20061117-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400064: autopartkit: FTBFS: No rule to make target `mapdevfs.o'
Package: autopartkit Version: 1.21 Severity: serious Hello, There was a problem while autobuilding your package: At 1164265143 time_t, [EMAIL PROTECTED] wrote: Automatic build of autopartkit_1.21 on avidan by sbuild/i386 98 Build started at 20061123-0758 ** ... checking for ped_disk_write... no checking for ped_partition_get_path... yes configure: creating ./config.status /bin/sh ./config.status config.status: creating Makefile config.status: creating autopartkit.d/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands make[1]: Leaving directory `/build/buildd/autopartkit-1.21' make[1]: Entering directory `/build/buildd/autopartkit-1.21' cd . /bin/sh /build/buildd/autopartkit-1.21/missing --run autoheader /build/buildd/autopartkit-1.21/missing: line 52: autoheader: command not found WARNING: `autoheader' is missing on your system. You should only need it if you modified `acconfig.h' or `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. rm -f stamp-h1 touch config.h.in /usr/bin/make all-recursive make[2]: Entering directory `/build/buildd/autopartkit-1.21' Making all in autopartkit.d make[3]: Entering directory `/build/buildd/autopartkit-1.21/autopartkit.d' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/build/buildd/autopartkit-1.21/autopartkit.d' make[3]: Entering directory `/build/buildd/autopartkit-1.21' if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT distribute.o -MD -MP -MF .deps/distribute.Tpo -c -o distribute.o distribute.c; \ then mv -f .deps/distribute.Tpo .deps/distribute.Po; else rm -f .deps/distribute.Tpo; exit 1; fi distribute.c: In function 'distribute_partitions': distribute.c:167: warning: ISO C90 does not support 'long long' distribute.c:167: warning: ISO C90 does not support 'long long' if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT loadpartitions.o -MD -MP -MF .deps/loadpartitions.Tpo -c -o loadpartitions.o loadpartitions.c; \ then mv -f .deps/loadpartitions.Tpo .deps/loadpartitions.Po; else rm -f .deps/loadpartitions.Tpo; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT lvm.o -MD -MP -MF .deps/lvm.Tpo -c -o lvm.o lvm.c; \ then mv -f .deps/lvm.Tpo .deps/lvm.Po; else rm -f .deps/lvm.Tpo; exit 1; fi lvm.c: In function 'vg_exists': lvm.c:87: warning: unused variable 'devpath' lvm.c:86: warning: unused variable 'statbuf' make[3]: *** No rule to make target `mapdevfs.o', needed by `autopartkit'. Stop. make[3]: Leaving directory `/build/buildd/autopartkit-1.21' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/autopartkit-1.21' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/autopartkit-1.21' make: *** [build-stamp] Error 2 ** Build finished at 20061123-0759 FAILED [dpkg-buildpackage died] -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD pgpmPRNF6zfj2.pgp Description: PGP signature
Bug#357327: misdn-user: still broken dep on linux-headers-misdn
reopen 357327 thanks Hi, I am reopening #357327 (misdn-user build-deps on missing linux-headers-misdn) because misdn-kernel (source package for linux-headers-misdn) is not in testing and not likely to get in soon (RC buggy). -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: misdn-user: still broken dep on linux-headers-misdn
Processing commands for [EMAIL PROTECTED]: reopen 357327 Bug#357327: FTBFS: broken b-d linux-headers-misdn Bug reopened, originator not changed. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400061: lprof: FTBFS: AttributeError in /usr/lib/scons/SCons/Node/FS.py
Package: lprof Version: 1.11.4.dfsg+1.11.4.1-1 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. Relevant parts: Looking for build directory for platform 'linux2' Exact match not found, finding closest guess Found directory build/linux, will build there AttributeError: : File /build/root/lprof-1.11.4.dfsg+1.11.4.1/SConstruct, line 277: SConscript(os.path.join(target_dir,'SConscript')) File /usr/lib/scons/SCons/Script/SConscript.py, line 579: return apply(method, args, kw) File /usr/lib/scons/SCons/Script/SConscript.py, line 516: return apply(_SConscript, [self.fs,] + files, subst_kw) File /usr/lib/scons/SCons/Script/SConscript.py, line 244: exec _file_ in call_stack[-1].globals File /build/root/lprof-1.11.4.dfsg+1.11.4.1/build/linux/SConscript, line 16: lprof=env.Program(target='lprof', source=sources + moc_sources0 + moc_sources1 + moc_sources2 + moc_sources3 + moc_sources4 + moc_s ources5 + moc_sources6 + moc_sources7 + moc_sources8) File /usr/lib/scons/SCons/Environment.py, line 188: return apply(self.builder, (self.env, target, source) + args, kw) File /usr/lib/scons/SCons/Builder.py, line 615: return self._execute(env, target, source, OverrideWarner(kw), ekw) File /usr/lib/scons/SCons/Builder.py, line 794: return BuilderBase._execute(self, env, target, final_sources, overwarn) File /usr/lib/scons/SCons/Builder.py, line 567: tlist, slist = self._create_nodes(env, target, source) File /usr/lib/scons/SCons/Builder.py, line 536: target, source = self.emitter(target=tlist, source=slist, env=env) File /usr/lib/scons/SCons/Builder.py, line 357: target, source = e(target, source, env) File /usr/lib/scons/SCons/Tool/qt.py, line 143: cpp_contents = cpp.get_contents() File /usr/lib/scons/SCons/Node/FS.py, line 762: raise AttributeError make: *** [build-stamp] Error 2 The full build log is available from http://ox.blop.info/bazaar/buildlogs/20061122/ About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400063: hol88_2.02.19940316-1(ia64/unstable): FTBFS: SEGV during build
Package: hol88 Version: 2.02.19940316-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of hol88_2.02.19940316-1 on caballero by sbuild/ia64 85 Build started at 20061123-0909 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 5), gcl (= 2.6.7-28), tetex-extra [...] Error signalled by TML. Error: -1 is an illegal frs index. Fast links are on: do (si::use-fast-links nil) for debugging Error signalled by SYSTEM:UNIVERSAL-ERROR-HANDLER. Error handler called recursively (:ERROR NIL SYSTEM:UNIVERSAL-ERROR-HANDLER ~S is an illegal frs index. -1) Unrecoverable error: Segmentation violation.. /bin/sh: line 1: 7233 Doneecho -e 'install `'/usr/share/hol88-2.02.19940316'`;;\nlisp `(ml-save foo)`;;' 7234 Aborted | ./$i make: *** [build-arch-stamp] Error 134 A full build log can be found at: http://buildd.debian.org/build.php?arch=ia64pkg=hol88ver=2.02.19940316-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394153: #394153 also applies to version in testing
found 394153 1:0.8.1-1 thanks Hi, I just reproduced this serious bug with version 1:0.8.1-1, which is the version currently in testing. Lucas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399995: marked as done (wodim: Error trying to dist-upgrade)
Your message dated Thu, 23 Nov 2006 18:57:01 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#35: wodim: Error trying to dist-upgrade has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: wodim Severity: serious Justification: Error trying to dist-upgrade I don't know if I reporting to the right package, and also dunno if serious is the right severity... sorry :-( While trying to apt-get dist-upgrade to etch, I got this: Unpacking wodim (from .../wodim_5%3a1.0-1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/wodim_5%3a1.0-1_i386.deb (--unpack): trying to overwrite `/usr/share/man/man1/readcd.1.gz', which is also in package cdrecord dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/wodim_5%3a1.0-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) ---End Message--- ---BeginMessage--- #include hallo.h * Marcos Torres Marado [Thu, Nov 23 2006, 05:03:56PM]: Do dpkg -l cdrecord please, don't reinstall it yet. [EMAIL PROTECTED]:~# dpkg -l cdrecord Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii cdrecord 2.01+01a01-5 command line CD writing tool Hmmm... Maybe this cdrecord version isn't official? [EMAIL PROTECTED]:~# apt-show-versions cdrecord cdrecord 8:2.01+01a01-5 newer than version in archive Oh yes, this is the problem. We never had an 8: epoch, 5: is the one beginning with cdrkit, and those before are forced to be uninstalled. Where is this package coming from? We got another bug report saying the same thing. Eduard. -- dloer Joey was bist du eigentlich offiziell im debian projekt genau? ---End Message---
Processed: closing 398209
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.22 close 398209 1.4.9-1.1 Bug#398209: hyperestraier: FTBFS: upstream build rules look in $(HOME) for includes 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 1.4.9-1.1, send any further explanations to Steve Langasek [EMAIL PROTECTED] End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400069: systemimager: FTBFS: make[1]: rsync: Command not found
Package: systemimager Version: 3.6.3-2 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. Relevant parts: # boel_binaries.tar.gz installed. mkdir -p /build/root/systemimager-3.6.3dfsg1/debian/systemimager-boot-i386-standard/usr/share/systemimager/boot/i386/standard rsync -a /build/root/systemimager-3.6.3dfsg1/systemimager-3.6.3/initrd_source/build_dir/ /build/root/systemimager-3.6.3dfsg1/debian/sys temimager-boot-i386-standard/usr/share/systemimager/boot/i386/standard/initrd_template/ make[1]: rsync: Command not found make[1]: *** [install_initrd_template] Error 127 make[1]: Leaving directory `/build/root/systemimager-3.6.3dfsg1/systemimager-3.6.3' make: *** [install-arch] Error 2 The full build log is available from http://ox.blop.info/bazaar/buildlogs/20061122/ About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399454: [autodir] [EMAIL PROTECTED]: Bug#399454: autodir: fails with alert: unexpected autofs packet type 3]
On Thu, 2006-11-23 at 01:54 -0800, ramana wrote: First thanks to Ian for providing valuable info for arrving at this conclusion. What happened? There is old autofs4 module which supported autofs4 protocol. Autofs team developed new autofs5 protocol but new module given name as autofs4. So this is where the problem is. New module is backward compatible with autofs4 protcol and also supports autofs5 but with the name 'autofs4'. Everything ok but with the autofs headers. What can be done? Until this is resolved, just compile autodir with old /usr/src/linux/auto_fs4.h and everthing should work fine. That is the reason older autodir compiled with older header file working fine with new kernel module autofs4 (which is autofs5) Since I do not have access to new autofs module on my Fedora, the testing is going fine -- which is compiled with older autofs module. And I can not say 100% sure about. (as I said I do not have access to the latest module and I can not confirm it myself doing tests). I agree it is unfortunate that the module is named autofs4 not autofs and I apologize for the confusion I have caused. In my view of the world autofs4 should replace autofs in the kernel but that hasn't happened yet and I'm not pushing for it but in time I will. The way it is designed is that the module supports several different protocol versions that need not be related to the name of the module. The version 5 protocol has obviously been added recently and has new message type numbers and they use different size packets. It appears to me that the issue has come up because of the interpretation of the macro AUTOFS_MAX_PROTO_VERSION which is the maximum supported protocol version and is not meant to be used by an application when specifying the version that it wishes to use. The application should actually check the kernel module for the versions it supports at startup using the provided ioctls. I have code to do this (although it needs a little work). At least that's the way it is supposed to work. Ian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399454: [autodir] [EMAIL PROTECTED]: Bug#399454: autodir: fails with alert: unexpected autofs packet type 3]
On Thu, Nov 23, 2006 at 05:49:08AM -0800, ramana wrote: As for the compatibility check, Autodir supports only protocol 4 and in the future 5. So only check for protocol 4 is needed at this moment. FWIW, after etch I'll put autofs 5 into Debian; etch will, however, stay with autofs 4. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398619: Minor adaptations to this patch for acidbase
I went on this bug report where Andreas adds a debconf template as
part of his patch to fix the RC issue.
I'd like to recommend following the writing style in the Developer's
Reference and remove the dot at the end of the new template short
description and turn the new template into an error template.
See attached patch.
I can sponsor an upload if needed.
--
diff -ur acidbase-1.2.6/debian/changelog acidbase-1.2.6.fixed/debian/changelog
--- acidbase-1.2.6/debian/changelog 2006-11-22 14:15:21.0 +0100
+++ acidbase-1.2.6.fixed/debian/changelog 2006-11-22 14:07:31.0
+0100
@@ -1,3 +1,12 @@
+acidbase (1.2.6-1.1) unstable; urgency=medium
+
+ * NMU
+ * Recommend mysql-client and postgresql-client.
+ * Check for available db client in during package config. (Closes: #398619)
+ * Show a helpful note when no db client is available and safely abort.
+
+ -- Andreas Henriksson [EMAIL PROTECTED] Wed, 22 Nov 2006 14:05:42 +0100
+
acidbase (1.2.6-1) unstable; urgency=low
* New upstream release.
diff -ur acidbase-1.2.6/debian/config acidbase-1.2.6.fixed/debian/config
--- acidbase-1.2.6/debian/config2006-11-22 14:15:21.0 +0100
+++ acidbase-1.2.6.fixed/debian/config 2006-11-22 14:10:44.0 +0100
@@ -3,8 +3,30 @@
# Source debconf library.
. /usr/share/debconf/confmodule
+# check for available db clients
+MYSQLCLIENT=0
+PSQLCLIENT=0
+
+if which mysql /dev/null 21 ; then
+ MYSQLCLIENT=1
+fi
+if which psql /dev/null 21 ; then
+ PSQLCLIENT=1
+fi
+
+if [ $MYSQLCLIENT = 1 ] [ $PSQLCLIENT = 1 ]; then
+ dbc_dbtypes=mysql, pgsql
+elif [ $MYSQLCLIENT = 1 ]; then
+ dbc_dbtypes=mysql
+elif [ $PSQLCLIENT = 1 ]; then
+ dbc_dbtypes=pgsql
+else
+ db_input high acidbase/manualdb
+ db_go
+ exit 0
+fi
+
# source dbconfig-common stuff
-dbc_dbtypes=mysql, pgsql
dbc_dbuser=snort
dbc_dbname=snort
diff -ur acidbase-1.2.6/debian/control acidbase-1.2.6.fixed/debian/control
--- acidbase-1.2.6/debian/control 2006-11-22 14:15:21.0 +0100
+++ acidbase-1.2.6.fixed/debian/control 2006-11-22 14:05:37.0 +0100
@@ -9,6 +9,7 @@
Package: acidbase
Architecture: all
Depends: ${misc:Depends}, dbconfig-common, php5 | php4 | php5-cli | php4-cli,
php5-gd | php4-gd, libphp-adodb (= 4.62), php-image-graph, libwww-perl
+Recommends: mysql-client, postgresql-client
Suggests: snort-mysql | snort-pgsql
Description: Basic Analysis and Security Engine
BASE is based on the code from the Analysis Console for Intrusion Databases
diff -ur acidbase-1.2.6/debian/postinst acidbase-1.2.6.fixed/debian/postinst
--- acidbase-1.2.6/debian/postinst 2006-11-22 14:15:21.0 +0100
+++ acidbase-1.2.6.fixed/debian/postinst2006-11-22 14:11:15.0
+0100
@@ -3,8 +3,29 @@
# debconf
. /usr/share/debconf/confmodule
+# check for available db clients
+MYSQLCLIENT=0
+PSQLCLIENT=0
+
+if which mysql /dev/null 21 ; then
+ MYSQLCLIENT=1
+fi
+if which psql /dev/null 21 ; then
+ PSQLCLIENT=1
+fi
+
+if [ $MYSQLCLIENT = 1 ] [ $PSQLCLIENT = 1 ]; then
+ dbc_dbtypes=mysql, pgsql
+elif [ $MYSQLCLIENT = 1 ]; then
+ dbc_dbtypes=mysql
+elif [ $PSQLCLIENT = 1 ]; then
+ dbc_dbtypes=pgsql
+else
+ exit 0
+fi
+
+#
# source dbconfig-common stuff
-dbc_dbtypes=mysql, pgsql
. /usr/share/dbconfig-common/dpkg/postinst
dbc_generate_include=php:/etc/acidbase/database.php
dbc_generate_include_owner=root:www-data
diff -ur acidbase-1.2.6/debian/templates acidbase-1.2.6.fixed/debian/templates
--- acidbase-1.2.6/debian/templates 2006-11-22 14:15:21.0 +0100
+++ acidbase-1.2.6.fixed/debian/templates 2006-11-22 14:14:28.0
+0100
@@ -17,3 +17,13 @@
_Description: NOTE: Manual configuration required
You will need to go to http://localhost/acidbase first to force the
database modifications for BASE.
+
+Template: acidbase/manualdb
+Type: error
+_Description: No database client found
+ Configuration of database settings can't be completed since there's no
+ database client available. Please install atleast one of mysql-client
+ and/or postgresql-client. You can then rerun the configuration by
+ running the command dpkg-reconfigure acidbase.
+ Acidbase configuration will now abort...
+
signature.asc
Description: Digital signature
Bug#399205: libsmbios-dev: where is libsmbios.so ?
GOTO Masanori [EMAIL PROTECTED] wrote: Hi, libsmbios-dev does not provide libsmbios.so, making it impossible to link against libsmbios. libsmbios1 has libsmbios.so - or do I misunderstand your bug report? Nope, it does not, and libsmbios-dev ships an empty /usr/lib directory. debian/dists/unstable% zgrep libsmbios.so Contents-amd64.gz usr/lib/libsmbios.so.1 libs/libsmbios1 usr/lib/libsmbios.so.1.12 libs/libsmbios1 debian/dists/unstable% zgrep libsmbios.so Contents-i386.gz usr/lib/libsmbios.so.1 libs/libsmbios1 usr/lib/libsmbios.so.1.12 libs/libsmbios1 JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400072: museek+: FTBFS: IOError: [Errno 2] No such file or directory: 'mucipher.i':
Package: museek+
Version: 0.1.12-1
Severity: serious
Justification: FTBFS on i386, very likely to fail everywhere else
Usertags: grid5000
Hi,
During a rebuild of all packages in etch, I discovered that your package
failed to build on i386.
Relevant parts:
Headers for Mucipher...
IOError: [Errno 2] No such file or directory: 'mucipher.i':
File /build/root/museek+-0.1.12/SConstruct, line 381:
SConscript(os.path.join(dir, 'SConscript'), build_dir = bd,
duplicate = 1)
File /usr/lib/scons/SCons/Script/SConscript.py, line 579:
return apply(method, args, kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 516:
return apply(_SConscript, [self.fs,] + files, subst_kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 244:
exec _file_ in call_stack[-1].globals
File /build/root/museek+-0.1.12/workdir/Mucipher/SConscript, line
17:
SConscript(os.path.join('python', 'SConscript'))
File /usr/lib/scons/SCons/Script/SConscript.py, line 579:
return apply(method, args, kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 516:
return apply(_SConscript, [self.fs,] + files, subst_kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 244:
exec _file_ in call_stack[-1].globals
File /build/root/museek+-0.1.12/workdir/Mucipher/python/SConscript,
line 29:
mucipherc = env_swigpy.SharedLibrary('_mucipherc', sources,
SWIGFLAGS='-python')
File /usr/lib/scons/SCons/Environment.py, line 188:
return apply(self.builder, (self.env, target, source) + args, kw)
File /usr/lib/scons/SCons/Builder.py, line 615:
return self._execute(env, target, source, OverrideWarner(kw), ekw)
File /usr/lib/scons/SCons/Builder.py, line 784:
tlist = bld._execute(env, None, [snode], overwarn)
File /usr/lib/scons/SCons/Builder.py, line 784:
tlist = bld._execute(env, None, [snode], overwarn)
File /usr/lib/scons/SCons/Builder.py, line 567:
tlist, slist = self._create_nodes(env, target, source)
File /usr/lib/scons/SCons/Builder.py, line 536:
target, source = self.emitter(target=tlist, source=slist, env=env)
File /usr/lib/scons/SCons/Builder.py, line 204:
target, source = emitter(target, source, env)
File /usr/lib/scons/SCons/Tool/swig.py, line 88:
f = open(src)
make: *** [build-stamp] Error 2
The full build log is available from
http://ox.blop.info/bazaar/buildlogs/20061122/
About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes
of the Grid'5000 platform, using a clean chroot containing an etch i386
environment (not unstable). Internet was not accessible from the build
systems. The builds were processed as root.
About Grid'5000:
Grid'5000 is an highly reconfigurable experimental Grid platform
gathering 9 sites and featuring a total of 5000 CPUs. It serves as a
testbed for research in Grid Computing. See https://www.grid5000.fr/
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400068: rmysql: FTBFS: the names in signature for method (dbObj, snames, , , ) do not match function's arguments
Package: rmysql Version: 0.5.9-1 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. Relevant parts: [1] dbDataType In method for function make.db.names: expanding the signature to include omitted arguments in definition: keywords = missing, unique = missing, allow.keywords = missing Error in .MakeSignature(new(signature), def, signature) : the names in signature for method (dbObj, snames, , , ) do not match function's arguments (dbObj, snames, keywords, unique, all ow.keywords) Execution halted ERROR: execution of package source for 'RMySQL' failed The full build log is available from http://ox.blop.info/bazaar/buildlogs/20061122/ About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400066: lcdproc_0.5.1-1(hppa/unstable): FTBFS: impossible constraint in asm
Package: lcdproc Version: 0.5.1-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of lcdproc_0.5.1-1 on peri by sbuild/hppa 85 Build started at 20061123-0719 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 4), texinfo, libncurses5-dev, libusb-dev, doxygen [...] port.h:300: error: impossible constraint in 'asm' port.h:293: error: impossible constraint in 'asm' port.h:300: error: impossible constraint in 'asm' port.h:293: error: impossible constraint in 'asm' port.h:300: error: impossible constraint in 'asm' port.h:293: error: impossible constraint in 'asm' make[4]: *** [serialVFD_io.o] Error 1 make[4]: Leaving directory `/build/buildd/lcdproc-0.5.1/server/drivers' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/buildd/lcdproc-0.5.1/server' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/lcdproc-0.5.1' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/lcdproc-0.5.1' make: *** [build-stamp] Error 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=hppapkg=lcdprocver=0.5.1-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: #394153 also applies to version in testing
Processing commands for [EMAIL PROTECTED]: found 394153 1:0.8.1-1 Bug#394153: twinkle: FTBFS: undefined reference to gsm_decode Bug marked as found in version 1:0.8.1-1. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399205: libsmbios-dev: where is libsmbios.so ?
libsmbios-dev does not provide libsmbios.so, making it impossible to link against libsmbios. libsmbios1 has libsmbios.so - or do I misunderstand your bug report? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#400056: planet-penguin-racer: Xorg goes to 99.4% cpu usage on starting game
Processing commands for [EMAIL PROTECTED]: reassign 400056 ppracer Bug#400056: planet-penguin-racer: Xorg goes to 99.4% cpu usage on starting game Warning: Unknown package 'planet-penguin-racer' Bug reassigned from package `planet-penguin-racer' to `ppracer'. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399454: [autodir] [EMAIL PROTECTED]: Bug#399454: autodir: fails with alert: unexpected autofs packet type 3]
On Thu, Nov 23, 2006 at 06:58:10PM +0100, Steinar H. Gunderson wrote: On Thu, Nov 23, 2006 at 05:49:08AM -0800, ramana wrote: As for the compatibility check, Autodir supports only protocol 4 and in the future 5. So only check for protocol 4 is needed at this moment. FWIW, after etch I'll put autofs 5 into Debian; etch will, however, stay with autofs 4. Yep, the (recent) change is at header level and causes some problems due to how autodir checks for protocol version AFAIK. IMHO the right solution is checking minimal protocol level support as Ian suggested. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400064: marked as done (autopartkit: FTBFS: No rule to make target `mapdevfs.o')
Your message dated Thu, 23 Nov 2006 19:25:32 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#400064: autopartkit: FTBFS: No rule to make target `mapdevfs.o' has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: autopartkit Version: 1.21 Severity: serious Hello, There was a problem while autobuilding your package: At 1164265143 time_t, [EMAIL PROTECTED] wrote: Automatic build of autopartkit_1.21 on avidan by sbuild/i386 98 Build started at 20061123-0758 ** ... checking for ped_disk_write... no checking for ped_partition_get_path... yes configure: creating ./config.status /bin/sh ./config.status config.status: creating Makefile config.status: creating autopartkit.d/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands make[1]: Leaving directory `/build/buildd/autopartkit-1.21' make[1]: Entering directory `/build/buildd/autopartkit-1.21' cd . /bin/sh /build/buildd/autopartkit-1.21/missing --run autoheader /build/buildd/autopartkit-1.21/missing: line 52: autoheader: command not found WARNING: `autoheader' is missing on your system. You should only need it if you modified `acconfig.h' or `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. rm -f stamp-h1 touch config.h.in /usr/bin/make all-recursive make[2]: Entering directory `/build/buildd/autopartkit-1.21' Making all in autopartkit.d make[3]: Entering directory `/build/buildd/autopartkit-1.21/autopartkit.d' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/build/buildd/autopartkit-1.21/autopartkit.d' make[3]: Entering directory `/build/buildd/autopartkit-1.21' if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT distribute.o -MD -MP -MF .deps/distribute.Tpo -c -o distribute.o distribute.c; \ then mv -f .deps/distribute.Tpo .deps/distribute.Po; else rm -f .deps/distribute.Tpo; exit 1; fi distribute.c: In function 'distribute_partitions': distribute.c:167: warning: ISO C90 does not support 'long long' distribute.c:167: warning: ISO C90 does not support 'long long' if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT loadpartitions.o -MD -MP -MF .deps/loadpartitions.Tpo -c -o loadpartitions.o loadpartitions.c; \ then mv -f .deps/loadpartitions.Tpo .deps/loadpartitions.Po; else rm -f .deps/loadpartitions.Tpo; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT lvm.o -MD -MP -MF .deps/lvm.Tpo -c -o lvm.o lvm.c; \ then mv -f .deps/lvm.Tpo .deps/lvm.Po; else rm -f .deps/lvm.Tpo; exit 1; fi lvm.c: In function 'vg_exists': lvm.c:87: warning: unused variable 'devpath' lvm.c:86: warning: unused variable 'statbuf' make[3]: *** No rule to make target `mapdevfs.o', needed by `autopartkit'. Stop. make[3]: Leaving directory `/build/buildd/autopartkit-1.21' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/autopartkit-1.21' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/autopartkit-1.21' make: *** [build-stamp] Error 2 ** Build finished at 20061123-0759 FAILED [dpkg-buildpackage died] -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD pgpCXaE3RCYeQ.pgp Description: PGP signature ---End Message--- ---BeginMessage--- On Thursday 23 November 2006 18:28, Julien Danjou wrote: There was a problem while autobuilding your package: Already fixed with an upload (1.22) a bit later yesterday. ---End Message---
Bug#398540: marked as done (snmpd: postrm fails: /var/lib/dpkg/info/snmpd.postrm: line 24: deluser: command not found)
Your message dated Thu, 23 Nov 2006 18:17:04 + with message-id [EMAIL PROTECTED] and subject line Bug#398540: fixed in net-snmp 5.2.3-4 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: snmpd Version: 5.2.3-2 Severity: serious Usertags: grid5000 Hi, During a piuparts run over all the packages in etch, I ran into a problem with your package: Removing snmpd ... Purging configuration files for snmpd ... /var/lib/dpkg/info/snmpd.postrm: line 24: deluser: command not found dpkg: error processing snmpd (--purge): subprocess post-removal script returned error exit status 127 adduser is not essential, you must depend on it. The full log is available from http://ox.blop.info/bazaar/buildlogs/20061114/ The piuparts run was done on about 40 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | ---End Message--- ---BeginMessage--- Source: net-snmp Source-Version: 5.2.3-4 We believe that the bug you reported is fixed in the latest version of net-snmp, which is due to be installed in the Debian FTP archive: libsnmp-base_5.2.3-4_all.deb to pool/main/n/net-snmp/libsnmp-base_5.2.3-4_all.deb libsnmp-perl_5.2.3-4_sparc.deb to pool/main/n/net-snmp/libsnmp-perl_5.2.3-4_sparc.deb libsnmp9-dev_5.2.3-4_sparc.deb to pool/main/n/net-snmp/libsnmp9-dev_5.2.3-4_sparc.deb libsnmp9_5.2.3-4_sparc.deb to pool/main/n/net-snmp/libsnmp9_5.2.3-4_sparc.deb net-snmp_5.2.3-4.diff.gz to pool/main/n/net-snmp/net-snmp_5.2.3-4.diff.gz net-snmp_5.2.3-4.dsc to pool/main/n/net-snmp/net-snmp_5.2.3-4.dsc snmp_5.2.3-4_sparc.deb to pool/main/n/net-snmp/snmp_5.2.3-4_sparc.deb snmpd_5.2.3-4_sparc.deb to pool/main/n/net-snmp/snmpd_5.2.3-4_sparc.deb tkmib_5.2.3-4_all.deb to pool/main/n/net-snmp/tkmib_5.2.3-4_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jochen Friedrich [EMAIL PROTECTED] (supplier of updated net-snmp package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Nov 2006 17:40:32 +0100 Source: net-snmp Binary: libsnmp9 tkmib snmp libsnmp-perl libsnmp-base libsnmp9-dev snmpd Architecture: source all sparc Version: 5.2.3-4 Distribution: unstable Urgency: low Maintainer: Net-SNMP Packaging Team [EMAIL PROTECTED] Changed-By: Jochen Friedrich [EMAIL PROTECTED] Description: libsnmp-base - NET SNMP (Simple Network Management Protocol) MIBs and Docs libsnmp-perl - NET SNMP (Simple Network Management Protocol) Perl5 Support libsnmp9 - NET SNMP (Simple Network Management Protocol) Library libsnmp9-dev - NET SNMP (Simple Network Management Protocol) Development Files snmp - NET SNMP (Simple Network Management Protocol) Apps snmpd - NET SNMP (Simple Network Management Protocol) Agents tkmib - NET SNMP (Simple Network Management Protocol) MIB Browser Closes: 398540 Changes: net-snmp (5.2.3-4) unstable; urgency=low . [ Jochen Friedrich ] * Don't fail postrm on non-existant deluser (Closes: #398540) * Add LSB section to startup file. * Add Thomas Anders as co-Maintainer. . [ Thomas Anders ] * Add missing copyrights to copyright file. * Fix spelling errors and wrong path names in documentation. Files: 88ec0c6730698ebf2261a2e0f515b930 941 net optional net-snmp_5.2.3-4.dsc 35e124ca657f0d68cedaaaef6678ecd6 85526 net optional net-snmp_5.2.3-4.diff.gz b58b4e88d096d4dc5190b52e8e3f10ef 1199916 libs optional libsnmp-base_5.2.3-4_all.deb 6367aba3fab194237173e7dcd42bbc79 854688 net optional tkmib_5.2.3-4_all.deb e1778b4aae955744809489053c2dcc2c 832394 net optional snmpd_5.2.3-4_sparc.deb 1f5568ce4b603b7f2648fd27821c7729 924436 net optional
Bug#399995: wodim: Error trying to dist-upgrade
#include hallo.h * Marcos Marado [Thu, Nov 23 2006, 06:07:06PM]: On Thu, 2006-11-23 at 18:57 +0100, Eduard Bloch wrote: #include hallo.h * Marcos Torres Marado [Thu, Nov 23 2006, 05:03:56PM]: Do dpkg -l cdrecord please, don't reinstall it yet. [EMAIL PROTECTED]:~# dpkg -l cdrecord Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii cdrecord 2.01+01a01-5 command line CD writing tool Hmmm... Maybe this cdrecord version isn't official? [EMAIL PROTECTED]:~# apt-show-versions cdrecord cdrecord 8:2.01+01a01-5 newer than version in archive Oh yes, this is the problem. We never had an 8: epoch, 5: is the one beginning with cdrkit, and those before are forced to be uninstalled. Where is this package coming from? We got another bug report saying the same thing. Hmm, I wonder... Maybe from Knoppix? Is there any way to find it? apt-get remove'ing cdrecord and apt-get install'ing it again solves the problem, right? Yes. I found some traces of hacked cdrecord packages it in old Knoppix versions, so I assume that your system was installed from a such one. Eduard. -- -!- waldi_ [EMAIL PROTECTED] has joined #debian.de Yarihm volltreffer Yarihm morgen waldi_ Yarihm :)_ Yarihm gerade wollt ich gehen! du ... mist, nein, sorry, ich hab dich mit alfie verwexelt
Bug#398634: [phpgacl] alternative patch without hard dependencies on both db clients.
On tor, 2006-11-23 at 17:32 +0100, sean finney wrote: (a) the packages in question should still have (foo | bar) depends on cmdline clients. (b) in dbconfig-common, if the user selects an option for cmdline clients that aren't installed, they're prompted with an error dialog, the dbconfig-common hooks gracefully stop (or perhaps they're given a choice to go back and choose another dbtype). (c) if the admin later installs the required cmdline packages, they should be able to dpkg-reconfigure the dbc-using package to use the new dbtype as always. A slightly different way would be to: - have dbconfig-common depend on sqlite | mysql-client | postgresql-client to make sure atleast one of the supported clients is always installed. - When package doesn't pass any $dbc_dbtypes to dbconfig-common, detect at runtime which clients are available when adding the default set of db clients, and offer only those as choices (and possibly mention what other choices could be available and how to install the required db client). - offer to safely abort, so additional db client can be installed, and then the user can restart the configuration by running dpkg-reconfigure package-that-uses-dbconfig-common. That way the package that uses dbconfig-common doesn't need to depend on any specific client. There's also no possibility for the user to choose one that isn't installed, but he can still go on if he doesn't care which one is used since atleast one is always available. Sqlite would probably be a good first one in the dependency alternatives to make sure there's no problem connecting to the server (which would be the next step to help a clueless user, since I guess the common case is a user who runs with locally installed databases and doesn't understand that mysql-client is actually only half of mysql). Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357919: marked as done (rekall_2.2.6-4 (unstable/ia64): FTBFS: 64-bit ODBC errors)
Your message dated Thu, 23 Nov 2006 18:32:03 + with message-id [EMAIL PROTECTED] and subject line Bug#357919: fixed in rekall 2.2.6-5 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: rekall Version: 2.2.6-4 Severity: serious Tags: patch upstream Justification: no longer builds from source Hi Peter, A recent fix to unixodbc is causing rekall to fail to build on 64-bit architectures for the libmysqlclient15off transition[1]: [...] make[4]: Entering directory /build/buildd/rekall-2.2.6/db/odbc' /bin/sh ../../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libs/common -I ../srclib -I /usr/include -I/usr/include/kde -I/usr/share/qt3/include -I.-D__KB_KDE=1 -D__KB_TKC=0 -D__KB_EMBEDDED=0 -DODBC_NS=NS_KBODBC -DGET_EXTRA=0 -DQT_THREAD_SUPPORT -D_REENTRANT -Wl,--no-undefined -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 -g -Wall -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -c -o kb_odbc.lo kb_odbc.cpp kb_odbc.cpp: In member function 'virtual bool NS_KBODBC::KBODBC::doConnect(KBServerInfo*)': kb_odbc.cpp:693: warning: cast from 'char*' to 'SQLUSMALLINT*' increases required alignment of target type kb_odbc.cpp:714: warning: cast from 'char*' to 'SQLUSMALLINT*' increases required alignment of target type kb_odbc.cpp: In member function 'bool NS_KBODBC::KBODBC::doListTables(KBTableDetailsList, const QString, bool, uint)': kb_odbc.cpp:1051: error: cannot convert 'SQLINTEGER*' to 'SQLLEN*' for argument '6' to 'SQLRETURN SQLBindCol(void*, SQLUSMALLINT, SQLSMALLINT, void*, SQLLEN, SQLLEN*)' kb_odbc.cpp:1052: error: cannot convert 'SQLINTEGER*' to 'SQLLEN*' for argument '6' to 'SQLRETURN SQLBindCol(void*, SQLUSMALLINT, SQLSMALLINT, void*, SQLLEN, SQLLEN*)' kb_odbc.cpp:1053: error: cannot convert 'SQLINTEGER*' to 'SQLLEN*' for argument '6' to 'SQLRETURN SQLBindCol(void*, SQLUSMALLINT, SQLSMALLINT, void*, SQLLEN, SQLLEN*)' kb_odbc.cpp: In member function 'bool NS_KBODBC::KBODBC::bindParameters(void*, uint, const KBValue*, QPtrListKBODBCValue, QTextCodec*)': kb_odbc.cpp:1826: error: cannot convert 'SQLINTEGER*' to 'SQLLEN*' for argument '10' to 'SQLRETURN SQLBindParameter(void*, SQLUSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLULEN, SQLSMALLINT, void*, SQLLEN, SQLLEN*)' kb_odbc.cpp: In member function 'bool NS_KBODBC::KBODBC::getRowCount(void*, int)': kb_odbc.cpp:1847: error: cannot convert 'SQLINTEGER*' to 'SQLLEN*' for argument '2' to 'SQLRETURN SQLRowCount(void*, SQLLEN*)' kb_odbc.cpp: In constructor 'NS_KBODBC::KBODBCQrySelect::KBODBCQrySelect(NS_KBODBC::KBODBC*, void*, bool, const QString, bool)': kb_odbc.cpp:2011: error: cannot convert 'SQLUINTEGER*' to 'SQLULEN*' for argument '7' to 'SQLRETURN SQLDescribeCol(void*, SQLUSMALLINT, SQLCHAR*, SQLSMALLINT, SQLSMALLINT*, SQLSMALLINT*, SQLULEN*, SQLSMALLINT*, SQLSMALLINT*)' kb_odbc.cpp: In member function 'virtual bool NS_KBODBC::KBODBCQrySelect::execute(uint, const KBValue*)': kb_odbc.cpp:2157: error: cannot convert 'SQLUINTEGER*' to 'SQLULEN*' for argument '7' to 'SQLRETURN SQLDescribeCol(void*, SQLUSMALLINT, SQLCHAR*, SQLSMALLINT, SQLSMALLINT*, SQLSMALLINT*, SQLULEN*, SQLSMALLINT*, SQLSMALLINT*)' [...] The ODBC API standard includes bugs in the definition of several function calls which take cast pointers as one of their possible arguments, resulting in truncated pointers on 64-bit systems. The Debian unixodbc packages have deviated from this standard since before the sarge release, in order to provide libraries that are actually usable on 64-bit systems. However, owing to an upstream decision to favor standards-compliance over utility by default in this case, the headers did not by default declare this 64-bit-clean API; instead, they declared a 32-bit API that did not match the actual ABI presented by the unixodbc library. unixodbc 2.2.11-10 corrected this oversight on my part, by fixing the headers to export the proper 64-bit interface. The result is that ODBC-using packages which don't know to expect this 64-bit interface will now fail to build, as seen in this build log. The attached patch makes the necessary type changes from SQLINTEGER and SQLUINTEGER to SQLLEN and SQLULEN. Note that SQLLEN is a late addition to the ODBC standard, so its use will prevent rekall from building with older ODBC library versions; if this is a
Processed (with 3 errors): thoggen is beta software
Processing commands for [EMAIL PROTECTED]: severity 396148 grave Bug#396148: thoggen: only works with dvd source Severity set to `grave' from `important' Raising severity because thoggen is simply unusable for Etch release Unknown command or malformed arguments to command. (in addition to this bug, it has no option to disable video, and it's Unknown command or malformed arguments to command. just too slow). Etch should only have functional software... Unknown command or malformed arguments to command. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400082: sylpheed-claws-gtk2: CRAM-MD5 auth doesn't work anymore
Package: sylpheed-claws-gtk2 Version: 2.6.0-1 Severity: grave Justification: renders package unusable Hello, since yesterday, I'm unable to connect to my IMAP server, which uses CRAM-MD5 authentification mechanism (just that). The log window of sylpheed-claws give me the following output : = [19:57:23] IMAP4 * OK Dovecot ready. * IMAP connection is un-authenticated [19:57:23] IMAP4 1 CAPABILITY [19:57:23] IMAP4 * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS LOGINDISABLED AUTH=CRAM-MD5 [19:57:23] IMAP4 1 OK Capability completed. [19:57:23] IMAP4 Logging jon to multani.info using CRAM-MD5 [19:57:23] IMAP4 Error logging in to multani.info *** Connection to multani.info failed: login refused. CRAM-MD5 logins only work if libetpan has been compiled with SASL support and the CRAM-MD5 SASL plugin is installed. [19:57:25] IMAP4 Logging jon to multani.info using CRAM-MD5 [19:57:25] IMAP4 Error logging in to multani.info *** Couldn't login to IMAP server multani.info.[19:57:25] IMAP4 2 LOGOUT [19:57:25] IMAP4 * BYE Logging out [19:57:25] IMAP4 2 OK Logout completed. = libetpan is installed, so I don't know what's wrong ... Logging in with another IMAP client (Icedove) works like a charm. Maybe should I report against libetpan ? Thanks, - Jonathan -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-lsm Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages sylpheed-claws-gtk2 depends on: ii libaspell15 0.60.4-4GNU Aspell spell-checker runtime l ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libcompfaceg11:1.5.2-3 Compress/decompress images for mai ii libetpan10 0.48-1 mail handling library ii libglib2.0-0 2.12.4-2The GLib library of C routines ii libgnomeprint2.2-0 2.12.1-6The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.12.1-4GNOME 2.2 print architecture User ii libgtk2.0-0 2.8.20-3The GTK+ graphical user interface ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libldap2 2.1.30-13.2 OpenLDAP libraries ii libpango1.0-01.14.7-1Layout and rendering of internatio ii libpisock9 0.12.1-5library for communicating with a P ii libsm6 1:1.0.1-3 X11 Session Management library ii libssl0.9.8 0.9.8c-3SSL shared libraries Versions of packages sylpheed-claws-gtk2 recommends: ii aspell-en [aspell-dictionary] 6.0-0-5.1 English dictionary for GNU Aspell ii aspell-fr [aspell-dictionary] 0.50-3-6 French dictionary for aspell pn metamail none (no description available) ii sylpheed-claws-gtk2-i18n 2.6.0-1Locale data for Sylpheed-Claws GTK pn sylpheed-claws-scriptsnone (no description available) ii xfonts-100dpi 1:1.0.0-3 100 dpi fonts for X ii xfonts-75dpi 1:1.0.0-3 75 dpi fonts for X -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400083: Does not start (System.DllNotFoundException: libc)
Package: last-exit Version: 3.0-3 Severity: grave The application does not start: Unhandled Exception: System.DllNotFoundException: libc at (wrapper managed-to-native) LastExit.Driver:prctl (int,byte[],ulong,ulong,ulong) at LastExit.Driver.SetProcessName (System.String name) [0x0] at LastExit.Driver.Main (System.String[] args) [0x0] The strace shows: stat(./libc, 0x7fff802a5a20) = -1 ENOENT (No such file or directory) stat(./libc.so, 0x7fff802a5a20) = -1 ENOENT (No such file or directory) stat(./libc.la, 0x7fff802a5a20) = -1 ENOENT (No such file or directory) open(./libc.so, O_RDONLY) = -1 ENOENT (No such file or directory) stat(libc, 0x7fff802a5a20)= -1 ENOENT (No such file or directory) stat(libc.so, 0x7fff802a5a20) = -1 ENOENT (No such file or directory) stat(libc.la, 0x7fff802a5a20) = -1 ENOENT (No such file or directory) open(/etc/ld.so.cache, O_RDONLY) = 13 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory) open(/lib/libc.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib/libc.so, O_RDONLY) = 13 Unhandled Exception: System.DllNotFoundException: libc at (wrapper managed-to-native) LastExit.Driver:prctl (int,byte[],ulong,ulong,ulong) at LastExit.Driver.SetProcessName (System.String name) [0x0] at LastExit.Driver.Main (System.String[] args) [0x0] mkdir(/home/ch/.wapi, 0755) = -1 EEXIST (File exists) unlink(/home/ch/.wapi/shared_data-app109-Linux-x86_64-320-10-0) = 0 mkdir(/home/ch/.wapi, 0755) = -1 EEXIST (File exists) unlink(/home/ch/.wapi/shared_fileshare-app109-Linux-x86_64-40-10-0) = 0 Process 8182 detached bye, -christian- -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-amd64 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages last-exit depends on: ii gconf2 2.16.0-2GNOME configuration database syste ii gstreamer0.10-fluendo-mp 0.10.2.debian-1 Fluendo mp3 decoder GStreamer plug ii gstreamer0.10-plugins-ug 0.10.4-4GStreamer plugins from the ugly ii libatk1.0-0 1.12.3-1The ATK accessibility toolkit ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libcairo21.2.4-4 The Cairo 2D vector graphics libra ii libdbus-1-3 1.0.1-2 simple interprocess messaging syst ii libdbus-glib-1-2 0.71-3 simple interprocess messaging syst ii libfontconfig1 2.4.1-2 generic font configuration library ii libgconf2-4 2.16.0-2GNOME configuration database syste ii libgconf2.0-cil 2.8.3-2 CLI binding for GConf 2.12 ii libglade2.0-cil 2.8.3-2 CLI binding for the Glade librarie ii libglib2.0-0 2.12.4-2The GLib library of C routines ii libglib2.0-cil 2.8.3-2 CLI binding for the GLib utility l ii libgnome2.0-cil 2.8.3-2 CLI binding for GNOME 2.12 ii libgstreamer0.10-0 0.10.10-2 Core GStreamer libraries and eleme ii libgtk2.0-0 2.8.20-3The GTK+ graphical user interface ii libgtk2.0-cil2.8.3-2 CLI binding for the GTK+ toolkit 2 ii libmono-corlib1.0-cil1.1.18-3Mono core library (1.0) ii libmono-system-web1.0-ci 1.1.18-3Mono System.Web library ii libmono-system1.0-cil1.1.18-3Mono System libraries (1.0) ii libmono1.0-cil 1.1.18-3Mono libraries (1.0) ii liborbit21:2.14.3-0.1libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.14.7-1Layout and rendering of internatio ii libx11-6 2:1.0.3-3 X11 client-side library ii libxcursor1 1.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-4 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-3 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxml2 2.6.27.dfsg-1 GNOME XML library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii mono-runtime 1.1.18-3Mono runtime last-exit recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#400068: rmysql: FTBFS: the names in signature for method (dbObj, snames, , , ) do not match function's arguments
Processing commands for [EMAIL PROTECTED]: found 400068 0.5.9-1 Bug#400068: rmysql: FTBFS: the names in signature for method (dbObj, snames, , , ) do not match function's arguments Bug marked as found in version 0.5.9-1. close 400068 0.5.10-1 Bug#400068: rmysql: FTBFS: the names in signature for method (dbObj, snames, , , ) do not match function's arguments 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 0.5.10-1, send any further explanations to Lucas Nussbaum [EMAIL PROTECTED] thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396148: why I changed severity
Hi, I raised severity because thoggen is simply unusable for Etch, and Etch should only have functional software. Similar case with Pitivi (#359803) which was luckily removed from Etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400068: rmysql: FTBFS: the names in signature for method (dbObj, snames, , , ) do not match function's arguments
On 23/11/06 at 13:17 -0600, Dirk Eddelbuettel wrote: | During a rebuild of all packages in etch, I discovered that your package | failed to build on i386. 0.5.9 is outdated. 0.5.10 builds fine. 0.5.9 is still in testing, that's why I filed this bug (so we don't release etch with 0.5.9). I suspected that 0.5.10 would fix this bug, thank you for confirming this. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400068: rmysql: FTBFS: the names in signature for method (dbObj, snames, , , ) do not match function's arguments
found 400068 0.5.9-1 close 400068 0.5.10-1 thanks On 23 November 2006 at 18:35, Lucas Nussbaum wrote: | Package: rmysql | Version: 0.5.9-1 | Severity: serious | Justification: FTBFS on i386, very likely to fail everywhere else | Usertags: grid5000 | | Hi, | | During a rebuild of all packages in etch, I discovered that your package | failed to build on i386. 0.5.9 is outdated. 0.5.10 builds fine. Steve: Could you please trigger rebuilds of rmysql_0.5.10 on alpha and mips? They fell victim to a bug I had inadvertendly introduced in in r-base-core [ where I used cdbs, and added an autoMAGIC addition of a lintian override file if found -- and I had a bug in that for a day or two where the build failed if the package has no override file as a 'test -f' failed, and so dpkg-buildpackage stopped ] Both alpha and mips did build 0.5.10 without a hitch as shown in the logs, I merely screwed up the package build for about a day. Sorry about that. This not-really-relevant-bug can then get closed for good. Cheers, Dirk | Relevant parts: | [1] dbDataType | In method for function make.db.names: expanding the | signature to include omitted arguments in definition: | keywords = missing, unique = missing, allow.keywords | = missing | Error in .MakeSignature(new(signature), def, signature) : | the names in signature for method (dbObj, snames, , , ) do not | match function's arguments (dbObj, snames, keywords, unique, all | ow.keywords) | Execution halted | ERROR: execution of package source for 'RMySQL' failed | | The full build log is available from | http://ox.blop.info/bazaar/buildlogs/20061122/ | | About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes | of the Grid'5000 platform, using a clean chroot containing an etch i386 | environment (not unstable). Internet was not accessible from the build | systems. The builds were processed as root. | | About Grid'5000: | Grid'5000 is an highly reconfigurable experimental Grid platform | gathering 9 sites and featuring a total of 5000 CPUs. It serves as a | testbed for research in Grid Computing. See https://www.grid5000.fr/ | -- | | Lucas Nussbaum | | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | | -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400068: rmysql: FTBFS: the names in signature for method (dbObj, snames, , , ) do not match function's arguments
On 23 November 2006 at 20:21, Lucas Nussbaum wrote: | On 23/11/06 at 13:17 -0600, Dirk Eddelbuettel wrote: | | During a rebuild of all packages in etch, I discovered that your package | | failed to build on i386. | | 0.5.9 is outdated. 0.5.10 builds fine. | | 0.5.9 is still in testing, that's why I filed this bug (so we don't | release etch with 0.5.9). I suspected that 0.5.10 would fix this bug, | thank you for confirming this. Well,, you could have checked by looking at the build log, or buy building a simple heuristic of analysing whether it exists in unstable on N out M architecture, or, for crying out loud, by keeping a second chroot for unstable!! I find this testing-rebuild-exercise useful, but 'too early' as we haven't frozen -- so I take some exception to the overly harsh severities. I mean, it's not really my fault if the porters of two arches sit on their hands and don't rebuild failed attempts... grid5000.fr looks like cool. As a graduate of research group that was/is also associated with the CNRS, I wish I would have had something like that when I was still a student in France :) Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 400082 is important
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 severity 400082 important Bug#400082: sylpheed-claws-gtk2: CRAM-MD5 auth doesn't work anymore Severity set to `important' from `grave' End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398634: [Dbconfig-common-devel] Re: Bug#398634: [phpgacl] alternative patch without hard dependencies on both db clients.
hej andreas, On Thu, 2006-11-23 at 19:33 +0100, Andreas Henriksson wrote: A slightly different way would be to: - have dbconfig-common depend on sqlite | mysql-client | postgresql-client to make sure atleast one of the supported clients is always installed. unfortunately, this won't work because some apps work only with mysql, others with mysql | pgsql, others sqlite only, thus it's possible that unless it specified its own dependencies, the app would be installed without any supported db clients installed. (phpmysqladmin on a system with dbconfig+sqlite already installed, for example) - When package doesn't pass any $dbc_dbtypes to dbconfig-common, detect at runtime which clients are available when adding the default set of db clients, and offer only those as choices (and possibly mention what other choices could be available and how to install the required db client). - offer to safely abort, so additional db client can be installed, and then the user can restart the configuration by running dpkg-reconfigure package-that-uses-dbconfig-common. this part is more or less what i've suggested with things in a slightly different order. sean signature.asc Description: This is a digitally signed message part
Bug#399689: marked as done (firefox-locale-uk: add support for latest Firefox)
Your message dated Thu, 23 Nov 2006 19:32:07 + with message-id [EMAIL PROTECTED] and subject line Bug#399689: fixed in iceweasel-locale-uk 2.0-1 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: firefox-locale-uk Severity: grave Justification: renders package unusable -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (9, 'experimental'), (1, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) ---End Message--- ---BeginMessage--- Source: iceweasel-locale-uk Source-Version: 2.0-1 We believe that the bug you reported is fixed in the latest version of iceweasel-locale-uk, which is due to be installed in the Debian FTP archive: iceweasel-locale-uk_2.0-1.diff.gz to pool/main/i/iceweasel-locale-uk/iceweasel-locale-uk_2.0-1.diff.gz iceweasel-locale-uk_2.0-1.dsc to pool/main/i/iceweasel-locale-uk/iceweasel-locale-uk_2.0-1.dsc iceweasel-locale-uk_2.0-1_all.deb to pool/main/i/iceweasel-locale-uk/iceweasel-locale-uk_2.0-1_all.deb iceweasel-locale-uk_2.0.orig.tar.gz to pool/main/i/iceweasel-locale-uk/iceweasel-locale-uk_2.0.orig.tar.gz mozilla-firefox-locale-uk_2.0-1_all.deb to pool/main/i/iceweasel-locale-uk/mozilla-firefox-locale-uk_2.0-1_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Eugeniy Meshcheryakov [EMAIL PROTECTED] (supplier of updated iceweasel-locale-uk package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 21 Nov 2006 16:10:18 +0100 Source: iceweasel-locale-uk Binary: mozilla-firefox-locale-uk iceweasel-locale-uk Architecture: source all Version: 2.0-1 Distribution: unstable Urgency: low Maintainer: Eugeniy Meshcheryakov [EMAIL PROTECTED] Changed-By: Eugeniy Meshcheryakov [EMAIL PROTECTED] Description: iceweasel-locale-uk - Iceweasel Ukrainian language/region package mozilla-firefox-locale-uk - Iceweasel Ukrainian language/region property package (transitiona Closes: 399689 Changes: iceweasel-locale-uk (2.0-1) unstable; urgency=low . * New upstream release (closes: #399689) * Rename source package to iceweasel-locale-uk to follow firefox-iceweasel renaming * Add binary package iceweasel-locale-uk * Do not provide firefox-locale-uk binary package anymore (it is not in stable anyway), but keep mozilla-firefox-locale-uk transitional package * Apply rebranding patch to upstream source * Suggest myspell-uk for spellchecking support Files: b9691bacff7a8589020785d68724427e 670 web optional iceweasel-locale-uk_2.0-1.dsc 30d473ad2eb7134e4f74b91160d1df2a 215711 web optional iceweasel-locale-uk_2.0.orig.tar.gz a30a871a79ebe5e8e0883e683523b8c2 14159 web optional iceweasel-locale-uk_2.0-1.diff.gz 8d406d6739fdd90155014d50a147334f 231002 web optional iceweasel-locale-uk_2.0-1_all.deb 7d7315a00f187607a50708e2d0e84ede 11912 web optional mozilla-firefox-locale-uk_2.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFYx0hKaC6+zmozOIRAmZHAJ0fe+rne/lUT9tkRL4x5m6S79WscACaAzYT ldVMdZDCnrzYRD/JUXQz2wg= =inPl -END PGP SIGNATURE- ---End Message---
Bug#400068: rmysql: FTBFS: the names in signature for method (dbObj, snames, , , ) do not match function's arguments
On 23/11/06 at 13:39 -0600, Dirk Eddelbuettel wrote: On 23 November 2006 at 20:21, Lucas Nussbaum wrote: | On 23/11/06 at 13:17 -0600, Dirk Eddelbuettel wrote: | | During a rebuild of all packages in etch, I discovered that your package | | failed to build on i386. | | 0.5.9 is outdated. 0.5.10 builds fine. | | 0.5.9 is still in testing, that's why I filed this bug (so we don't | release etch with 0.5.9). I suspected that 0.5.10 would fix this bug, | thank you for confirming this. Well,, you could have checked by looking at the build log, or buy building a simple heuristic of analysing whether it exists in unstable on N out M architecture, or, for crying out loud, by keeping a second chroot for unstable!! The fact that the bug exists in the testing version is important from the release management POV. The only thing I can be blamed for is that I didn't test the unstable version (and issue the notfound command as you did). I take full responsibility for this :) I usually don't file bugs when there's a newer version in unstable which is going to get into testing soon (I plan to run another tests later, so I prefer to not spend too much time investigating such failures now). With rmysql, it wasn't clear if the version would get into testing soon (25 days in unstable, out-of-date on some archs). So I filed the bug, hoping that it would also force the maintainer to look at the package status and react accordingly. Which worked perfectly, I must say ;) I find this testing-rebuild-exercise useful, but 'too early' as we haven't frozen -- so I take some exception to the overly harsh severities. It's a chicken-and-egg problem. Before freezing, testing must be in a good-enough state. And archive-wide tests are good indicators to know if testing is in a good-enough state. I try to avoid filing bugs about transient issues if the issue is really transient, but it wasn't clear with this bug. Thank you for being that fast to reply :-) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400086: iceweasel connects only with one site and hangs afterwards.
Package: iceweasel Version: 2.0+dfsg-1 Severity: grave Justification: renders package unusable iceweasel connects only to the default homepage (not cached). Any attempt to connect with any other site afterwards makes it hang on the DNS lookup stage or later. It can only be removed by killing the process with SIGKILL. Moreover, it hangs the IP connection with it (no other application can connect with the Internet). -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages iceweasel depends on: ii debianutils 2.17.3 Miscellaneous utilities specific t ii fontconfig2.4.1-2generic font configuration library ii libatk1.0-0 1.12.3-1 The ATK accessibility toolkit ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libfontconfig12.4.1-2generic font configuration library ii libfreetype6 2.2.1-5FreeType 2 font engine, shared lib ii libgcc1 1:4.1.1-20 GCC support library ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgtk2.0-0 2.8.20-3 The GTK+ graphical user interface ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libmyspell3c2 1:3.1-17 MySpell spellchecking library ii libpango1.0-0 1.14.7-1 Layout and rendering of internatio ii libpng12-01.2.13-4 PNG library - runtime ii libstdc++64.1.1-20 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-4 X11 client-side library ii libxft2 2.1.8.2-8 FreeType-based font drawing librar ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library ii libxp61:1.0.0.xsf1-1 X Printing Extension (Xprint) clie ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii libxt61:1.0.2-2 X11 toolkit intrinsics library ii psmisc22.3-1 Utilities that use the proc filesy ii zlib1g1:1.2.3-13 compression library - runtime iceweasel recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400090: icedove: FTBFS: ld: cannot find -lnss3
Package: icedove Version: 1.5.0.8-2 Severity: serious Hi, Your package is failing to build with the following error: gcc -shared -Wl,-soname -Wl,libsoftokn3.so -Wl,--version-script,Linux2.6_x86_glibc_PTH_64_OPT.OBJ/softokn.def -o Linux2.6_x86_glibc_PTH_64_OPT.OBJ/libsoftokn3.so Linux2.6_x86_glibc_PTH_64_OPT.OBJ/alghmac.o Linux2.6_x86_glibc_PTH_64_OPT.OBJ/dbinit.o [...] Linux2.6_x86_glibc_PTH_64_OPT.OBJ/softkver.o Linux2.6_x86_glibc_PTH_64_OPT.OBJ/tlsprf.o /build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/lib/libfreebl.a /build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/lib/libsecutil.a /build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/lib/libdbm.a -L/build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/lib/ -lplc4 -lplds4 -lnspr4 gcc: /build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/lib/libfreebl.a: No s uch file or directory make[5]: *** [Linux2.6_x86_glibc_PTH_64_OPT.OBJ/libsoftokn3.so] Error 1 Happily continues to: gcc -shared -Wl,-soname -Wl,libnss3.so -Wl,--version-script,Linux2.6_x86_glibc_PTH_64_OPT.OBJ/nss.def -o Linux2.6_x86_glibc_PTH_64_OPT.OBJ/libnss3.so Linux2.6_x86_glibc_PTH_64_OPT.OBJ/nssinit.o Linux2.6_x86_glibc_PTH_64_OPT.OBJ/nssver.o ../certhigh/Linux2.6_x86_glibc_PTH_64_OPT.OBJ/certhtml.o [...] ../base/Linux2.6_x86_glibc_PTH_64_OPT.OBJ/whatnspr.o -L/build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/lib/ -lsoftokn3 -lplc4 -lplds4 -lnspr4 collect2: ld returned 1 exit status make[5]: *** [Linux2.6_x86_glibc_PTH_64_OPT.OBJ/libnss3.so] Error 1 Then happely continues, until it really fails with: gcc -o Linux2.6_x86_glibc_PTH_64_OPT.OBJ/shlibsign -O2 -fPIC -D_XOPEN_SOURCE -DLINUX1_2 -Di386 -DLINUX2_1 -ansi -Wall -pipe -D_POSIX_SOURCE -D_BSD_SOURCE -DHAVE_STRERROR -DLINUX -Dlinux -DXP_UNIX -DSHLIB_SUFFIX=\so\ -DSHLIB_PREFIX=\lib\ -UDEBUG -DNDEBUG -D_REENTRANT -I/build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/include -I../../../../dist/public/nss -I../../../../dist/private/nss -I../../../../dist/include -I/build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/include/nspr -I/build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/include/dbm -I../../../../dist/public/dbm -I../../../../dist/public/seccmd Linux2.6_x86_glibc_PTH_64_OPT.OBJ/shlibsign.o /build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/lib/libsectool.a -Wl,-rpath-link,/build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/lib -L/build/buildd/icedove-1.5.0.8/build-dir/mozilla/dist/lib -lssl3 -lsmime3 -lnss3 -lplc4 -lplds4 -lnspr4 -lpthread -ldl -lc /usr/bin/ld: cannot find -lssl3 collect2: ld returned 1 exit status make[4]: *** [Linux2.6_x86_glibc_PTH_64_OPT.OBJ/shlibsign] Error 1 The buildd log is also full of: syntax error at -e line 3, near while syntax error at -e line 7, near } Execution of -e aborted due to compilation errors. I think atleast everytime it enters a directory, and at various other places too. PS: Is there a reason why every mozilla derived package ships it's own libsoftokn3 and libssl3 and probably various other libraries? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379628: Problem persists with Vista Final
Hi Szaka, I can confirm that unfortunately the problem persists in the final version of Vista. :-( Regards, Andree PS: I was given the opportunity to test this but have not purchased a copy of Vista and don't intend to. I can possibly do some more testing but it would be easier (and quicker) if someone else stepped up that owns a copy him- or herself. This could of course also be a company. -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade
On Thu, Nov 23, 2006 at 03:55:15PM +0100, Raphael Hertzog wrote: On Thu, 23 Nov 2006, Lionel Elie Mamane wrote: I just checked, it is not a conffile. ... and not shipped by the package, but created by the postinst. Which means this also breaks _new_ installs as far as I understand it because if: There's the possibility of not including the symlink in the package but creating it at the same time when you create /etc/mailman/mm_cfg.py. Yes, but if the admin removes the configuration file we are out of sync... I'll have to think a bit about a good solution. Thinking aloud... If I can keep that file from being compiled _at_ _all_, this would seem a good solution... The file is small (just configuration), so having it not compiled is perfectly acceptable performance-wise... Thanks for your suggestions, -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400096: libimage-info-perl: FTBFS: t/svg randomly fails
Package: libimage-info-perl Version: 1.23-1 Severity: serious Usertags: grid5000 Hi, libimage-info-perl seems to randomly fails to build. Sometimes, the build goes perfectly fine. Internet access is not used at all (monitored using iptables rules). All tests pass. The other times, 6 tests fail, internet access is used, and the build fails. This case happens during 10% to 30% of the builds. I don't know if it's just an harmless race condition in the build system, or a more serious issue with the package. Here is a diff between a successful log and a failed log. Comments are enclosed. --- libimage-info-perl_1.23-1_etch32.buildlog.4 2006-11-23 21:30:39.0 +0100 +++ libimage-info-perl_1.23-1_etch32.buildlog.8 2006-11-23 21:30:47.0 +0100 @@ -1,5 +1,5 @@ -DC-Build-Header: libimage-info-perl 1.23-1 / Thu Nov 23 21:30:19 +0100 2006 -Automatic build of libimage-info-perl_1.23-1 on sagittaire-13.lyon.grid5000.fr by sbuild/amd64 0.52 +DC-Build-Header: libimage-info-perl 1.23-1 / Thu Nov 23 21:30:14 +0100 2006 +Automatic build of libimage-info-perl_1.23-1 on sagittaire-42.lyon.grid5000.fr by sbuild/amd64 0.52 Build started at 20061123-2130 ** Checking available source versions... == The builds were tried on different machines, but there's no relationship between the failed builds and the nodes they were run on. == @@ -170,165 +170,156 @@ t/pod_cov..ok 7/7 skipped: Test::Pod::Coverage 1.00 required for testing POD coverage t/string...ok -t/svg..ok +t/svg.. +# Failed test 'SVG_StandAlone' +# in t/svg.t at line 44. +# got: undef +# expected: 'yes' + +# Failed test 'file_ext' +# in t/svg.t at line 45. +# got: undef +# expected: 'svg' + +# Failed test 'file_media_type' +# in t/svg.t at line 46. +# got: undef +# expected: 'image/svg+xml' + +# Failed test 'title' +# in t/svg.t at line 47. +# got: undef +# expected: 'Untitled graph' + +# Failed test 'SVG_Version 1.1' +# in t/svg.t at line 48. +# got: undef +# expected: '1.1' + +# Failed test 'dim()' +# in t/svg.t at line 50. +# got: undef +# expected: '209x51' +# Looks like you failed 6 tests of 12. +dubious + Test returned status 6 (wstat 1536, 0x600) +DIED. FAILED tests 7-12 + Failed 6/12 tests, 50.00% okay t/tiff.ok t/tiff_e...ok t/tiny-pgm.ok -All tests successful, 18 subtests skipped. -Files=12, Tests=127, 0 wallclock secs ( 0.49 cusr + 0.06 csys = 0.55 CPU) +Failed Test Stat Wstat Total Fail Failed List of Failed +--- +t/svg.t6 1536126 50.00% 7-12 +18 subtests skipped. +Failed 1/12 test scripts, 91.67% okay. 6/127 subtests failed, 95.28% okay. +make[1]: *** [test_dynamic] Error 255 make[1]: Leaving directory `/build/root/libimage-info-perl-1.23' -touch build-stamp - /usr/bin/fakeroot debian/rules binary -dh_testdir -dh_testroot -dh_clean -k -dh_installdirs == I cut the rest of the successful build. == During the failed builds, the following HTTP requests are made, and are blocked by the firewall. During sucessful builds, internet is not used. IN= OUT=eth1 SRC=10.69.1.42 DST=128.30.52.31 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=31588 DF PROTO=TCP SPT=56384 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=128.30.52.31 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=31589 DF PROTO=TCP SPT=56384 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=128.30.52.45 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=57879 DF PROTO=TCP SPT=36403 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=128.30.52.45 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=57880 DF PROTO=TCP SPT=36403 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=128.30.52.46 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=6873 DF PROTO=TCP SPT=55388 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=128.30.52.46 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=6874 DF PROTO=TCP SPT=55388 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=128.30.52.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=61212 DF PROTO=TCP SPT=48409 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=128.30.52.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=61213 DF PROTO=TCP SPT=48409 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=193.51.208.69 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=10371 DF PROTO=TCP SPT=42920 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=193.51.208.69 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=10372 DF PROTO=TCP SPT=42920 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC=10.69.1.42 DST=193.51.208.70 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=45148 DF PROTO=TCP SPT=51817 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 IN= OUT=eth1 SRC
Bug#400024: mondo 2.20: wrong mountlist
reassign 400024 mindi thanks Hello Hugo, Thank you for reporting this problem. It would be great if you could run the following command (as root): mindi --makemountlist /tmp/mount.lst and send me: - the screen output - /tmp/mount.lst - /var/log/mindi Also, unless I am mistaken you are not running a stock Debian kernel but a custom one. Is there any particular reason for this? Could you retest with a stock Debian? Finally, I'd just like to confirm that what you are saying is that if you downgrade to 2.0.8 and run it on your *current* system, it works ok but 2.0.9 and 2.2.0 don't. Best regards, Andree -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#400024: mondo 2.20: wrong mountlist
Processing commands for [EMAIL PROTECTED]: reassign 400024 mindi Bug#400024: mondo 2.20: wrong mountlist Bug reassigned from package `mondo' to `mindi'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400103: nginx: Overwrites files in /var/www without warning.
Package: nginx Version: 0.4.13-1 Severity: critical Justification: breaks unrelated software I just lost /var/www/index.html that unfortunately has been heavily modified but not yet backed-up. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.31-bsd29c Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages nginx depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libpcre3 6.7-1 Perl 5 Compatible Regular Expressi ii zlib1g 1:1.2.3-13 compression library - runtime nginx recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
