Bug#1077390: Rebooting the fort77 packaging
Hi Mark, fort77 is in the dependency chain of one of my packages, and it's currently blocked from testing because of an FTBFS. I was having a look at it, and found that the packaging was rather old-school :-) So I took the liberty of rebooting it using current tools and methods (format "3.0 (quilt)", git-buildpackage, pristine-tar, dh, and so on). Somehow that fixed the FTBFS, so I pushed the results to a new Salsa repository at https://salsa.debian.org/debian/fort77 Would you mind if I uploaded this new version to unstable as an NMU? I realize it's quite the opposite of usual practices for NMUs (minimal patches and so on), so I'd rather ask beforehand. I feel that not only the package doesn't seem to actually require much maintenance, but even when it does it's going to be easier with modern tools. I'll wait for your opinion before doing anything. Roland.
Bug#1079982: closing 1079982
close 1079982 9.5.0-6 thanks
Bug#1076970: closing 1076970
close 1076970 0.5.3~rc1-1 thanks
Bug#1079719: python-ipywidgets-doc: uninstallable; depends on unpackaged node-jupyter-widgets-html-manager
Le 26/08/2024 à 20:42, Colin Watson a écrit : ipywidgets has been stuck in unstable for a while because […] Roland, what was the plan here? Do you still have some work in progress lying around somewhere that could be polished up and pushed into unstable, or should we do something else instead? ipywidgets has been sort of stuck waiting for the jupyterlab situation to stabilize. Thanks to Yadd, jupyterlab is now in a better shape, and I'm resuming work on ipywidgets and related packages. Roland.
Bug#1076970: Debian bug #1076970 (napari FTBFS)
I had a look at this bug report. It seems the error comes from pydantic (pydantic code called by other parts of pydantic); it still occurs with the recent upload of pydantic 2.4.2. I tried doing a package for the newer upstream release (2.8.2) with a simple gbp import-orig --uscan (and refreshing the patches), but that one fails to build too, seemingly due to a too old pydantic-core. So I tried doing a package for the newer upstream release of pydantic-core (2.20.1) with the same procedure, but that one requires a Rust module (jiter) that doesn't seem to be packaged yet. I'm giving up on that for today, but if anyone is interested, here's the brain dump :-) Roland.
Bug#1058473: closing 1058473
close 1058473 3.6.23-1 thanks genx now builds successfully in an up-to-date chroot, so I suppose python3-numba has been fixed. Closing this bug accordingly.
Bug#1030905: closing 1030905
close 1030905 3.5.0-1 thanks
Bug#1075814: closing 1075814, closing 1075815
close 1075814 2.4.2-1 close 1075815 2.4.2-1 thanks
Bug#1073504: closing 1073504
close 1073504 0.5.0~a5-1 thanks
Bug#1073504: #1073504 napari: fails to build wheel with python3.12
Le 02/07/2024 à 16:52, Roland Mas a écrit : Hi Étienne, I'm unable to reproduce your bug in a clean up-to-date cowbuilder sid chroot. I uploaded a new upstream release while investigating (0.5.0~a5-1), let's see if the buildds manage to build it before comparing your log and mine line-by-line :-) Seems that the buildd network managed to build the package… could you try building the new version on your side? Roland.
Bug#1073504: #1073504 napari: fails to build wheel with python3.12
Hi Étienne, I'm unable to reproduce your bug in a clean up-to-date cowbuilder sid chroot. I uploaded a new upstream release while investigating (0.5.0~a5-1), let's see if the buildds manage to build it before comparing your log and mine line-by-line :-) Roland.
Bug#1071894: closing 1071894
close 1071894 0.7.10-1 thanks
Bug#1060772: [Debian-pan-maintainers] Unifying jupyterlab and node-jupyterlab
Le 02/06/2024 à 10:58, Yadd a écrit : On 6/2/24 12:53, Yadd wrote: On 6/2/24 10:38, Yadd wrote: In my last commit, I added also a fix for #1060772: - jupyter-lab uses yarnpkg by default - in Debian build context, this can be overridden using YARN_COMMAND=pkgjs-install-minimal Better hook with "YARN_COMMAND=pkgjs" which uses the adapted pkgjs-* command And this produces the final bundle without Internet access => fixes #1060772 :-D …wow, you rock. Thanks for all that! I had started a WIP branch but was nowhere near completion like yours. I'll do some testing on my side and see if anything needs to be tweaked on the Python side. Thanks! Roland.
Bug#1071315: Partial patch
Here's a partial patch that fixes the compilation-- but not the linking. I didn't manage to get the linking to work, but I'm sharing what I currently have. Roland. From: Roland Mas Date: Fri, 24 May 2024 16:01:50 +0200 Subject: Remove -pthread from hsc2hs invocation --- binoculars-ng/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/binoculars-ng/Makefile.am b/binoculars-ng/Makefile.am index ca255c1..5b2c5c7 100644 --- a/binoculars-ng/Makefile.am +++ b/binoculars-ng/Makefile.am @@ -18,7 +18,7 @@ AM_GHCFLAGS=\ -outputdir=$(builddir)/src .hsc.hs: - $(HSC2HS) $$(echo "$(AM_CFLAGS)" | sed "s%-ftrack-macro-expansion=0%%") -o $@ $< + $(HSC2HS) $$(echo "$(AM_CFLAGS)" | sed -e "s%-ftrack-macro-expansion=0%%" -e "s%-pthread%%") -o $@ $< .hs.o: $(GHC) --make $(AM_GHCFLAGS) -c -o $@ $<
Bug#1065662: closing 1065662
close 1065662 8.1.2-2 thanks
Bug#1070188: python3-spyder: uninstallable in unstable due to pylint
Le 02/05/2024 à 06:07, Julian Gilbey a écrit : On Wed, May 01, 2024 at 03:04:56PM +0200, Roland Mas wrote: Package: python3-spyder Version: 5.5.1+ds-1 Severity: important Dear Maintainer, python3-spyder is no longer installable in sid; it depends (and build-depends) on pylint (< 3.1~) but pylint is currently 3.1.0-1 in unstable. Loosening the versioned dependency is enough to allow spyder to build, but I don't know whether that introduces runtime changes or not. Dear Roland, That would be a reasonable thing to do. Version 5.5.4 depends on pylint >= 3.1. I don't have time to do this right now, unfortunately, so if someone else would like to make the required changes and upload a patched version of 5.5.1 in the meantime, please feel free to do so. I guess I could do that, but is there any reason not to upgrade to 5.5.4 directly? Maybe I'm fooled by only the "micro" part of the version number changing, but it doesn't sound like a big upgrade… Roland.
Bug#1056798: closing 1056798
close 1056798 0.5.9+git20240322-1 thanks
Bug#1063631: closing 1063631
close 1063631 5.0.0.3381-2 thanks
Bug#1063908: [Debian-pan-maintainers] Bug#1063908: node-jupyter-widgets-{base, base-manager, control}: ships files already in python3-widgetsnbextension
Le 15/02/2024 à 05:42, Yadd a écrit : Preparing to unpack .../node-jupyter-widgets-base_6.0.7+~cs14.23.94-1_all.deb ... Unpacking node-jupyter-widgets-base (6.0.7+~cs14.23.94-1) ... dpkg: error processing archive /var/cache/apt/archives/node-jupyter-widgets-base_6.0.7+~cs14.23.94-1_all.deb (--unpack): trying to overwrite '/usr/share/nodejs/@jupyter-widgets/base/css/index.css', which is also in package python3-widgetsnbextension 8.1.1-2 Errors were encountered while processing: /var/cache/apt/archives/node-jupyter-widgets-base_6.0.7+~cs14.23.94-1_all.deb Hi, why does python3-widgetsnbextension install an unusable node.js module into a nodejs directory ? This sounds like a remnant from the past, but since node-ipydatagrid started providing these node.js modules then I'll remove them from ipywidgets (and add a Depends:). I suggest adding the appropriate Provides/Conflicts/Replaces: field to your packages, to help user transitions. Roland.
Bug#1060432: closing 1060432
close 1060432 thanks rust-archery and rust-rpds (and rust-triomphe, a third dependency in the chain) are now part of unstable.
Bug#1060432: [Python-modules-team] Bug#1060432: rpds-py ftbfs in unstable
Le 11/01/2024 à 10:27, Matthias Klose a écrit : Package: src:rpds-py Version: 0.12.0-2 Severity: serious Tags: sid trixie ftbfs rpds-py ftbfs in unstable, because of missing build dependencies: Issues preventing migration: ∙ ∙ rpds-py unsatisfiable Build-Depends(-Arch) on amd64: librust-archery-dev ∙ ∙ rpds-py unsatisfiable Build-Depends(-Arch) on amd64: librust-rpds-dev I just uploaded these two packages to NEW, along with a third one on the dependency chain. Roland.
Bug#1042290: closing 1042290
close 1042290 0.12.3-2 thanks
Bug#1042810: [Debian-pan-maintainers] Bug#1042810: bornagain: FTBFS/BD-Uninstallable on !amd64
Le 01/08/2023 à 10:14, Sebastian Ramacher a écrit : Source: bornagain Version: 20.2+ds3-1 Severity: serious Tags: ftbfs sid trixie Justification: fails to build from source (but built successfully in the past) A partial patch fixing several testsuite failures has already been committed upstream and cherry-picked in the package, but other failures remain. Discussion is ongoing with upstream. Roland.
Bug#1040334: facet-analyser - build-depends on conflicting packages
Le 04/07/2023 à 17:53, Steven Robbins a écrit : On Tuesday, July 4, 2023 10:03:27 A.M. CDT Peter Green wrote: Package: facet-analyser Version: 0.0~git20221121142040.6be10b8+ds1-3 Tags: trixie, sid Severity: serious Justification: rc policy - "packages must be buildable within the same release" User: debian...@lists.debian.org Usertags: edos-uninstallable x-debbugs-cc: s...@debian.org facet-analyser build-depends on both python3-paraview and libinsighttoolkit5-dev unfortunately, libinsighttoolkit5-dev recently added a dependency on libvtk9-dev which depends on python3-vtk9 which conflicts with python3-paraview. I am not familiar enough with the packages in question to know what the most appropriate way to untangle this is. That's curious. I don't know either. My questions are: why do python3-vtk9 and python3-paraview conflict, and could the issue be solved another way? I think it's because python3-paraview uses its own vtk9, see #982601 and #654839. Roland.
Bug#1032547: facet-analyser: FTBFS in testing: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j8 test ARGS\+=--verbose ARGS\+=-j8 returned exit code 2
Le 08/03/2023 à 21:28, Lucas Nussbaum a écrit :
Source: facet-analyser
Version: 0.0~git20221121142040.6be10b8+ds1-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230307 ftbfs-bookworm
Hi,
During a rebuild of all packages in testing (bookworm), your package failed
to build on amd64.
Hi,
I can't seem to reproduce this FTBFS with a bookworm cowbuilder. The
relevant part of the log (where the error used to be):
2/4 Test #4: basicExampleTest01 ... Passed 2.04 sec
2: Traceback (most recent call last):
2: File
"/build/facet-analyser-0.0~git20221121142040.6be10b8+ds1/scripts/pvsm2x3d.py",
line 73, in
2: main()
2: File
"/build/facet-analyser-0.0~git20221121142040.6be10b8+ds1/scripts/pvsm2x3d.py",
line 57, in main
2: exporters= pvs.servermanager.createModule("exporters")
2: ^^
2: AttributeError: module 'paraview.servermanager' has no attribute
'createModule'. Did you mean: 'updateModules'?
1: Traceback (most recent call last):
1: File
"/build/facet-analyser-0.0~git20221121142040.6be10b8+ds1/scripts/pvsm2webgl.py",
line 73, in
1: main()
1: File
"/build/facet-analyser-0.0~git20221121142040.6be10b8+ds1/scripts/pvsm2webgl.py",
line 57, in main
1: exporters= pvs.servermanager.createModule("exporters")
1: ^^
1: AttributeError: module 'paraview.servermanager' has no attribute
'createModule'. Did you mean: 'updateModules'?
3/4 Test #2: basicPluginTest02 ***Skipped 4.49 sec
4/4 Test #1: basicPluginTest01 ***Skipped 4.51 sec
100% tests passed, 0 tests failed out of 4
Attaching the full build log for reference. The difference may be in
either the versions of packages installed as build-dependencies, or in
the xvfb setup, since you get X server errors in your log.
If a rebuild on the testing buildds works, then I'd be grateful if you
could close this bug before facet-analyser gets AUTORMed from bookworm;
otherwise I'll be happy to help pinpoint (and fix) the root cause.
Roland.
Bug#1030298: #1030298: Patch backported from upstream, 10-day delayed NMU uploaded
Hi all, Upstream has a patch that I successfully tested on barriere.d.o (i386 porterbox) after a minor tweak (the tolerance was not enough). I've committed it to a forked repository on salsa and submitted a merge request at https://salsa.debian.org/opencl-team/python-pyopencl/-/merge_requests/3 Also, given the urgency of the situation (since several dependent packages are at risk of getting thrown out of testing), I uploaded a 10-day delayed NMU. Thanks, Roland.
Bug#1029276: closing 1029276
close 1029276 3.12.1+dfsg3-4 thanks dials (3.12.1+dfsg3-4) unstable; urgency=medium * Fix autopkgtest script. -- Roland Mas Tue, 24 Jan 2023 12:18:11 +0100
Bug#1008465: #1008465 (python-fabio FTBFS): works for me
Hi, I was trying to reproduce bug #1008465 to see if I could fix it, but an up-to-date pbuilder and an up-to-date git clone build fine. Maybe something changed in the dependencies? I suggest closing this bug, because python-fabio is marked for autoremoval from testing and several packages will be removed as a consequence. Roland.
Bug#986525: Patch available for #986525
Hi,
The problem mentioned in #986525 has a fix upstream in
https://github.com/aio-libs/yarl/pull/575. I prepared a merge request at
https://salsa.debian.org/python-team/packages/yarl/-/merge_requests/3
with the patch, formatted according to DEP-3 guidelines, and a
debian/changelog entry.
This does fix the FTBFS for me.
I can NMU if needed.
Roland.
>From b35decabba16716bc505628ac0a45bb435ec6a4d Mon Sep 17 00:00:00 2001
From: Roland Mas
Date: Mon, 19 Apr 2021 13:47:06 +0200
Subject: [PATCH] Apply patch from github to fix #986525
---
debian/changelog | 6 +++-
debian/patches/fix-986525 | 74 +++
debian/patches/series | 1 +
3 files changed, 80 insertions(+), 1 deletion(-)
create mode 100644 debian/patches/fix-986525
diff --git a/debian/changelog b/debian/changelog
index edf9fd3..6f4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,12 @@
yarl (1.6.3-2) UNRELEASED; urgency=medium
+ [ Sandro Tosi ]
* Use the new Debian Python Team contact name and address
- -- Sandro Tosi Mon, 04 Jan 2021 17:09:22 -0500
+ [ Roland Mas ]
+ * Fix failing test with Python 3.9.2 (closes: #986525).
+
+ -- Roland Mas Mon, 19 Apr 2021 14:14:30 +0200
yarl (1.6.3-1) unstable; urgency=low
diff --git a/debian/patches/fix-986525 b/debian/patches/fix-986525
new file mode 100644
index 000..cf2d6d2
--- /dev/null
+++ b/debian/patches/fix-986525
@@ -0,0 +1,74 @@
+Description: Fix test with Python 3.9.2
+ This patch fixes a test that fails with Python 3.9.2.
+Origin: upstream, https://github.com/aio-libs/yarl/pull/575
+Bug: https://github.com/aio-libs/yarl/issues/563
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986525
+Last-Update: 2021-04-19
+
+---
+Index: yarl/tests/test_url_query.py
+===
+--- yarl.orig/tests/test_url_query.py
yarl/tests/test_url_query.py
+@@ -63,7 +63,7 @@ def test_ampersand_as_value():
+
+
+ def test_semicolon_as_separator():
+-u = URL("http://127.0.0.1/?a=1;b=2";)
++u = URL("http://127.0.0.1/?a=1;b=2";, separator=";")
+ assert len(u.query) == 2
+
+
+Index: yarl/yarl/_url.py
+===
+--- yarl.orig/yarl/_url.py
yarl/yarl/_url.py
+@@ -126,7 +126,7 @@ class URL:
+ # / path-noscheme
+ # / path-empty
+ # absolute-URI = scheme ":" hier-part [ "?" query ]
+-__slots__ = ("_cache", "_val")
++__slots__ = ("_cache", "_val", "_separator")
+
+ _QUOTER = _Quoter(requote=False)
+ _REQUOTER = _Quoter()
+@@ -142,7 +142,7 @@ class URL:
+ _PATH_UNQUOTER = _Unquoter(unsafe="+")
+ _QS_UNQUOTER = _Unquoter(qs=True)
+
+-def __new__(cls, val="", *, encoded=False, strict=None):
++def __new__(cls, val="", *, encoded=False, strict=None, separator="&"):
+ if strict is not None: # pragma: no cover
+ warnings.warn("strict parameter is ignored")
+ if type(val) is cls:
+@@ -188,6 +188,7 @@ class URL:
+ self = object.__new__(cls)
+ self._val = val
+ self._cache = {}
++self._separator = separator
+ return self
+
+ @classmethod
+@@ -551,7 +552,21 @@ class URL:
+ Empty value if URL has no query part.
+
+ """
+-ret = MultiDict(parse_qsl(self.raw_query_string, keep_blank_values=True))
++if (
++(3, 6, 13) <= sys.version_info < (3, 7)
++or (3, 7, 10) <= sys.version_info < (3, 8)
++or (3, 8, 8) <= sys.version_info < (3, 9)
++or sys.version_info >= (3, 9, 2)
++):
++ret = MultiDict(
++parse_qsl(
++self.raw_query_string,
++keep_blank_values=True,
++separator=self._separator,
++)
++)
++else:
++ret = MultiDict(parse_qsl(self.raw_query_string, keep_blank_values=True))
+ return MultiDictProxy(ret)
+
+ @property
diff --git a/debian/patches/series b/debian/patches/series
index 8b3b873..fd29cd1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
0002-docs-disable-intersphinx.patch
0003-docs-disable-sidebar_collapse-option.patch
0004-disable-privacy-breach-links-in-documentation.patch
+fix-986525
--
2.30.2
Bug#848156: libtext-unaccent-perl: Segmentation fault on unac_string
Package: libtext-unaccent-perl
Version: 1.08-1.2+b1
Severity: grave
The most useful method of Text::Unaccent seems to cause a segmentation
fault (which was not the case a few weeks ago):
$ locale
LANG=C
LANGUAGE=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
$ perl -MText::Unaccent -e 'print unac_string("utf-8","a")'
Segmentation fault
$
I tried various locales, to no avail. I also tried changing "utf-8" to
uppercase and/or removing the dash. I also tried rebuilding against
current perl, thinking maybe there was an ABI change.
After installing the debug packages, here's the backtrace I get in gdb:
$ gdb perl
GNU gdb (Debian 7.12-1) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from perl...Reading symbols from
/usr/lib/debug//usr/bin/perl...done.
done.
(gdb) run -MText::Unaccent -e 'print unac_string("utf-8","a")'
Starting program: /usr/bin/perl -MText::Unaccent -e 'print
unac_string("utf-8","a")'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x) at malloc.c:2963
2963malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_free (mem=0x) at malloc.c:2963
#1 0x76ed5ea4 in unac_string () from
/usr/lib/x86_64-linux-gnu/perl5/5.24/auto/Text/Unaccent/Unaccent.so
#2 0x76ed51dd in XS_Text__Unaccent_unac_string () from
/usr/lib/x86_64-linux-gnu/perl5/5.24/auto/Text/Unaccent/Unaccent.so
#3 0x556280b0 in Perl_pp_entersub (my_perl=0x55941010) at
pp_hot.c:3987
#4 0x556205d6 in Perl_runops_standard (my_perl=0x55941010) at
run.c:41
#5 0x555a66e9 in S_run_body (oldscope=1, my_perl=0x55941010) at
perl.c:2488
#6 perl_run (my_perl=0x55941010) at perl.c:2411
#7 0x5557f85d in main (argc=, argv=,
env=) at perlmain.c:116
(gdb) quit
A debugging session is active.
Inferior 1 [process 21916] will be killed.
Quit anyway? (y or n) y
$
I don't know whether the bug lies in libtext-unaccent-perl, in perl
itself, or in libc6. Feel free to reassign accordingly :-)
Roland.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libtext-unaccent-perl depends on:
ii libc6 2.24-8
ii perl5.24.1~rc4-1
ii perl-base [perlapi-5.24.1] 5.24.1~rc4-1
libtext-unaccent-perl recommends no packages.
libtext-unaccent-perl suggests no packages.
-- no debconf information
--
Roland Mas
Indépendant en informatique libre -- Free software freelance
http://www.gnurandal.com/
Bug#767460: [pkg-php-pear] Bug#767460: php-htmlpurifier: Missing versioned dependency on dpkg
David Prévot, 2014-10-31 12:24:05 -0400 : [...] >> However, according to dpkg's changelog, such relative symlinks have only >> been supported since 1.17.14. > > It worked before: I just successfully upgraded php-htmlpurifier using > dpkg 1.17.10. Looking closer at dpkg changelog, the regression seems to > have been introduced in dpkg 1.17.13: Oh. Sorry then. [...] > I’d rather reassign this bug to dpkg 1.17.13 and close it with dpkg > 1.17.14 (php-htmlpurifier is not the only package relying on > symlink_to_dir. As documented on dpkg-maintscript-helper(1), the > old-target must be provided, and such target are often relatives, as > expected by the policy). Fair enough. In this case, feel free to reassign/downgrade. I worked around the problem by upgrading dpkg by hand, and I guess it'll fix itself when dpkg migrates to testing anyway. Roland. -- Roland Mas Sauvez les castors, tuez les bûcherons. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767460: php-htmlpurifier: Missing versioned dependency on dpkg
Package: php-htmlpurifier Version: 4.6.0-1 Severity: serious Hi, When installing php-htmlpurifier on a testing system, I get the folowing error messages: , | Selecting previously unselected package php-htmlpurifier. | Preparing to unpack .../php-htmlpurifier_4.6.0-1_all.deb ... | dpkg-maintscript-helper: error: original symlink target is not an absolute path | dpkg: error processing archive /var/cache/apt/archives/php-htmlpurifier_4.6.0-1_all.deb (--unpack): | subprocess new pre-installation script returned error exit status 1 | dpkg-maintscript-helper: error: original symlink target is not an absolute path | dpkg: error while cleaning up: | subprocess new post-removal script returned error exit status 1 ` Indeed, the debian/maintscript involves relative symlinks. However, according to dpkg's changelog, such relative symlinks have only been supported since 1.17.14. So the php-htmlpurifier currently in testing can't be installed by the dpkg currently in testing. I guess a simple versioned dependency would fix that (alternatively, a rewrite of the maintscript to use absolute targets for the symlinks). Thanks, Roland. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages php-htmlpurifier depends on: ii dpkg 1.17.21 ii php5-common 5.6.2+dfsg-1 php-htmlpurifier recommends no packages. php-htmlpurifier suggests no packages. -- no debconf information -- Roland Mas La menace de la baffe pèse plus lourd que la baffe elle-même. -- in Sri Raoul le petit yogi (Gaudelette) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764885: php-htmlpurifier ready for tests (Security flaws in the current Debian version)
David Prévot, 2014-10-17 21:30:05 -0400 : [...] > The package ready for test and upload is online: [...] > Thanks in advance for your feedback. If I don’t get negative feedback > by Monday, I intend to upload the package as is (it will already be > late: two weeks before the freeze). I would much prefer get feedback > sooner, and upload this package as soon as you believe it’s OK. I just ran the FusionForge testsuite using your updated package, and it appears to work nice. So consider this an ACK from me :-) Roland. -- Roland Mas Despite rumour, Death isn't cruel - merely terribly, terribly good at his job. -- in Sourcery (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713672: NMU for xca
Hi, Since bugs #758440 and #713672 seem to have stayed unfixed for a long time, I took the liberty to NMU the xca package. I just pushed xca_0.9.3-1.1_amd64.changes to DELAYED/10 to give you time to react if needed. The only differences with 0.9.3-1 are the two patches mentioned in the two bug reports, which I can confirm fix the two problems (FTBFS and runtime errors). Roland. -- Roland Mas Sauvez une souris, mangez votre chat. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656088: gforge-web-apache2: prompting due to modified conffiles which where not modified by the user
Andreas Beckmann, 2012-07-05 15:30:37 +0200 : > On 2012-07-05 15:15, Roland Mas wrote: >> I can't limit that a posteriori, I'm afraid. Even for users who >> installed the very minimal set of packages and didn't customize >> anything, there's still at least the variability of the hostname. > > Well, you can extract the hostname and check, whether it was modified. > and you can remove the line with the hostname before running md5sum or > replace it with some placeholder first: I think that adding code that's only going to work in very specific conditions (ie. piuparts) but not in real-life scenarios, to a package that doesn't have a version in stable, isn't really something I want to spend much time on, as I feel there's not much call for it. I'm therefore going to downgrade the severity of this bug report; not closing, in case someone wants to do the necessary work. Thanks for detecting it in the first place anyway (and thanks for the other piuparts checks, they're much appreciated). Roland. -- Roland Mas 'And what would humans be without love?' RARE, said Death. -- in Sourcery (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719176: Patch for #719176
Hello, Here's a patch fixing bug #719176. >From 6e9918b67abb188200bf769d8deca195676e77a0 Mon Sep 17 00:00:00 2001 From: Roland Mas Date: Mon, 26 Aug 2013 10:07:17 +0200 Subject: [PATCH] Don't call sphinxdoc for binary-arch (#719176) --- debian/rules | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/rules b/debian/rules index c6b1dfd..b860b2f 100755 --- a/debian/rules +++ b/debian/rules @@ -5,6 +5,9 @@ export DEB_BUILD_HARDENING=1 export CSYNC_DIR=/usr/include/ocsync #export DEB_CXXFLAGS_MAINT_APPEND = -fvisibility=hidden -fvisibility-inlines-hidden +binary-arch: + dh $@ --with kde --parallel --with pkgkde_symbolshelper + %: dh $@ --with sphinxdoc --with kde --parallel --with pkgkde_symbolshelper -- 1.8.4.rc3 Roland. -- Roland Mas M-x execute-extended-command
Bug#716689: f-spot: Crashes on startup
?? () #13 0x in ?? () Thread 4 (Thread 0x7f9d71f9e700 (LWP 30671)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x005cd20b in ?? () #2 0x005e0e55 in ?? () #3 0x0059c788 in ?? () #4 0x406dda8d in ?? () #5 0x7f9d64000e40 in ?? () #6 0x in ?? () Thread 3 (Thread 0x7f9d713a7700 (LWP 30718)): #0 0x7f9d9cc6eacd in nanosleep () at ../sysdeps/unix/syscall-template.S:81 #1 0x005e30c7 in ?? () #2 0x0057e5bb in ?? () #3 0x0057ce52 in ?? () #4 0x005e3de1 in ?? () #5 0x005f2a19 in ?? () #6 0x006016e4 in ?? () #7 0x7f9d9cc67e0e in start_thread (arg=0x7f9d713a7700) at pthread_create.c:311 #8 0x7f9d9c99893d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 2 (Thread 0x7f9d721af700 (LWP 30719)): #0 0x7f9d70f2659a in jpeg_idct_islow () from /usr/lib/x86_64-linux-gnu/libjpeg.so.8 #1 0x7f9d70f14412 in ?? () from /usr/lib/x86_64-linux-gnu/libjpeg.so.8 #2 0x7f9d70f194de in ?? () from /usr/lib/x86_64-linux-gnu/libjpeg.so.8 #3 0x7f9d70f11c1e in jpeg_read_scanlines () from /usr/lib/x86_64-linux-gnu/libjpeg.so.8 #4 0x7f9d7116261a in ?? () from /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so #5 0x7f9d7116385c in ?? () from /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so #6 0x7f9d920d509d in gdk_pixbuf_loader_write () from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 #7 0x406dfb88 in ?? () #8 0x7f9d68000e40 in ?? () #9 0x7f9d8a5eb280 in ?? () #10 0x7f9d721ae920 in ?? () #11 0x7f9d721aecf8 in ?? () #12 0x7f9d68001240 in ?? () #13 0x7f9d721aea80 in ?? () #14 0x7f9d721ae940 in ?? () #15 0x7f9d721aecf8 in ?? () #16 0x7f9d8a5e9e38 in ?? () #17 0x7f9d8a309000 in ?? () #18 0x4011afe0 in ?? () #19 0x7f9d721ae9b8 in ?? () #20 0x7f9d8a309020 in ?? () #21 0x41eb2fa4 in ?? () #22 0x0001 in ?? () #23 0x0001 in ?? () #24 0x in ?? () Thread 1 (Thread 0x7f9d9d7b5740 (LWP 30461)): #0 0x7f9d9cc6ee07 in __libc_waitpid (pid=, stat_loc=, options=) at ../sysdeps/unix/sysv/linux/waitpid.c:40 #1 0x004a7258 in ?? () #2 #3 0x7f9d9c8e51e5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #4 0x7f9d9c8e8398 in __GI_abort () at abort.c:90 #5 0x006082bb in ?? () #6 0x00608352 in ?? () #7 0x00607fc6 in ?? () #8 0x00606ddd in ?? () #9 0x005a35e1 in mono_string_new () #10 0x4148cd5a in ?? () #11 0x7fffafb77720 in ?? () #12 0x52474220 in ?? () #13 0x7f9d7766eb18 in ?? () #14 0x7fffafb76f80 in ?? () #15 0x7f9d7766eb18 in ?? () #16 0x7fffafb76f80 in ?? () #17 0x7fffafb76ed0 in ?? () #18 0x in ?? () = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = guest@polymir:~$ Thanks, Roland. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages f-spot depends on: ii dbus1.6.12-1 ii gconf2 3.2.6-1 ii gvfs-bin1.16.3-1 ii libc6 2.17-7 ii libcairo2 1.12.14-5 ii libflickrnet2.2-cil 1:2.2.0-4 ii libgconf2.0-cil 2.24.2-3 ii libgdk-pixbuf2.0-0 2.28.2-1 ii libglib2.0-02.36.3-3 ii libglib2.0-cil 2.12.10-5 ii libgnome-keyring1.0-cil 1.0.0-4 ii libgnome2.24-cil2.24.2-3 ii libgnomeui-02.24.5-2 ii libgtk2.0-0 2.24.20-1 ii libgtk2.0-cil 2.12.10-5 ii liblcms11.19.dfsg-1.2 ii libmono-addins-gui0.2-cil 0.6.2-2 ii libmono-addins0.2-cil 0.6.2-2 ii libmono-cairo4.0-cil3.0.6+dfsg2-4 ii libmono-corlib4.0-cil 3.0.6+dfsg2-4 ii libmono-posix4.0-cil3.0.6+dfsg2-4 ii libmono-sharpzip4.84-cil3.0.6+dfsg2-4 ii libmono-simd4.0-cil 3.0.6+dfsg2-4 ii libmono-system-core4.0-cil 3.0.6+dfsg2-4 ii libmono-system-web4.0-cil 3.0.6+dfsg2-4 ii libmono-system-xml4.0-cil 3.0.6+dfsg2-4 ii libmono-system4.0-cil 3.0.6+dfsg2-4 ii libndesk-dbus1.0-cil0.6.0-6 ii libpango1.0-0 1.32.5-5+b1 ii libsqlite3-0 3.7.17-1 ii libunique-1.0-0 1.1.6-4 ii libx11-6
Bug#696369: Bug#700675: pu: package fusionforge/5.0.2-5+squeeze1
Andreas Beckmann, 2013-02-16 12:03:01 +0100 : [...] > The fusionforge packages are not really in a good shape for automated > testing (e.g. #678025, #662897) ... and I never used fusionforge > myself, so I don't know how to properly test it manually. Therefore > I'm a bit reluctant to NMU fusionforge without having a positive > comment on the patch by the maintainer. Thank you for looking into this; I must confess I'm slacking in my duty as a maintainer of the fusionforge packages these days. The patch looks good to me, and I'd appreciate the NMU, please. > Could the new version suffix "+squeeze1" break something? I don't think so; there's a bit of code that handles Debian version numbers, but it takes care to delegate version comparison to dpkg, so we should be safe. > But after having run piuparts install and upgrade tests on the patched > packages (that takes some time for fusionforge ...) I can now confirm that > * there are no previously unseen installation or upgrade errors > * the file conflict is solved by unpacking gforge-common before > gforge-web-apache2 Thanks again! Roland. -- Roland Mas La tradition orale, c'est comme un vieux fromage [...] -- Le Blaire -- Signatures à collectionner, série n°2, partie 1/3. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683655: #683655: Me too (different settings)
Slightly different settings, but similar behaviour here: $ gsettings list-recursively org.gnome.crypto.cache org.gnome.crypto.cache gpg-cache-authorize false org.gnome.crypto.cache gpg-cache-method 'timeout' org.gnome.crypto.cache gpg-cache-ttl 60 Roland. -- Roland Mas Despite rumour, Death isn't cruel - merely terribly, terribly good at his job. -- in Sourcery (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656088: gforge-web-apache2: prompting due to modified conffiles which where not modified by the user
Andreas Beckmann, 2012-07-05 13:34:52 +0200 : > Hi Roland, Hi, > sorry, it took me a while to answer this ... > > On 2012-03-20 14:24, Roland Mas wrote: >> I'm not sure there's a way to fix that without touching the packages >> in stable; > > Touching stable is not an option, this needs to be fixed by the package > in squeeze. > >> so, while I agree this bug is valid for the squeeze->wheezy >> upgrade, it should be tagged as only concerning versions up to 5.1.1-2. >> >> What do you think? > > How does /etc/gforge/httpd.conf get created? Is there any local > customization (like a hostname) by default or is it the sam efile in > all installations (until customized)? In 5.1 and 5.2 and beyond (ie. for wheezy), it's a standard conffile which will very rarely change from the shipped version. In 5.0 and older (ie. up until squeeze), it was generated from templates with variables filled in (including at the very least the hostname to be used by Apache for its virtual hosts). The list of templates itself was variable, since plugins could provide snippets of files that would be used when generating /etc/gforge/httpd.conf. > If you can limit the possible files created by the package in squeeze > just collect all possible md5sums of unmodified configuration files. I can't limit that a posteriori, I'm afraid. Even for users who installed the very minimal set of packages and didn't customize anything, there's still at least the variability of the hostname. Roland. -- Roland Mas Le weblog entièrement nu -- http://roland.entierement.nu/ Le photoblog entièrement net -- http://roland.entierement.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656088: gforge-web-apache2: prompting due to modified conffiles which where not modified by the user
Andreas Beckmann, 2012-03-19 18:23:27 +0100 : > Package: gforge-web-apache2 > Version: 5.1.1-3 > Followup-For: Bug #656088 > > Hi, > > the prompting due to modified /etc/gforge/httpd.conf has not been fixed > in 5.1.1-3: > > Setting up gforge-web-apache2 (5.1.1-3) ... > > Configuration file `/etc/gforge/httpd.conf' >==> File on system created by you or by a script. Hi, I'm trying to reproduce the error with a local piuparts, but apparently it lacks some of the magic you have (--allow-database, in particular :-) Nevertheless, I believe this particular problem is not really a problem in 5.1.1-* (wheezy/sid), but in 5.0.2-5 (squeeze) only. More precisely, the configuration scripts in 5.0.2-5 always regenerate this httpd.conf file from a template and fill some blanks with host names and IP addresses. So this file will always appear as locally modified on upgrades from 5.0. The 5.1 series replaces that large file with a single operative line (an Include directive for a set of smaller files), with no need for automated changes, so the "locally modified" thing should no longer happen. I'm not sure there's a way to fix that without touching the packages in stable; so, while I agree this bug is valid for the squeeze->wheezy upgrade, it should be tagged as only concerning versions up to 5.1.1-2. What do you think? Roland. -- Roland Mas Why did the tachyon cross the road? Because it was on the other side. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659688: [pkg-cryptsetup-devel] Bug#659688: cryptsetup: LVM on cryptsetup won't boot
retitle 659688 LVM on LUKS won't boot if not all LVs are available initially severity 659688 normal thanks Roland Mas, 2012-02-14 20:18:25 +0100 : > Feel free to downgrade it; I only picked "critical" because the effects > were the same as for #659235, but I agree my setup may be a bit more > involved than usual. Let's downgrade. >> Please remove --sysinit option from line 156 of >> /usr/share/initramfs-tools/scripts/local-top/cryptroot, update your >> initramfs with 'update-initramfs -u' and see whether the problem >> disappears. > > It doesn't. I still need to activate the LVs manually from the > initramfs shell, with --partial. I just split my VG in two; the obelix_crypt volume that's not available initially is no longer part of the big VG, which means that the VG is fully available and requires no --partial. The system is back to booting normally. I did a casual diff between 2:1.3.0-3.1 and 2:1.4.1-2 and found nothing obviously relevant to LVM partial stuff. I suppose the change occurred in the way the device dependencies are calculated, around lines 150-160 of cryptroot-hook. Roland. -- Roland Mas When I eat a biscuit, it stays eaten! -- Arthur Dent, in So Long, and Thanks for All the Fish (Douglas Adams) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659688: [pkg-cryptsetup-devel] Bug#659688: cryptsetup: LVM on cryptsetup won't boot
Jonas Meurer, 2012-02-14 00:03:37 +0100 : > Hey Roland, Hi, > Am 13.02.2012 09:35, schrieb Roland Mas: >> Package: cryptsetup Version: 2:1.4.1-2 Severity: critical > > To be honest I don't agree with you on the severity of this bug. Feel free to downgrade it; I only picked "critical" because the effects were the same as for #659235, but I agree my setup may be a bit more involved than usual. [...] > Are you confident that the bug didn't exist in 2:1.3.1-3 yet? Actually > the only change in activating LVM volume groups from 2:1.3.1-3 to > 2:1.4.1-1 was, that the option --sysinit is given to vgchange now. I don't seem to have a trace of any 2:1.3.1-3 version; I am confident it didn't exist with 2:1.3.0-3 or 2:1.3.0-3.1. I've been tracking unstable with this setup for ~6 months. > Please remove --sysinit option from line 156 of > /usr/share/initramfs-tools/scripts/local-top/cryptroot, update your > initramfs with 'update-initramfs -u' and see whether the problem > disappears. It doesn't. I still need to activate the LVs manually from the initramfs shell, with --partial. > 2:1.4.1-1 introduced much more changes in the initramfs cryptroot hook > than in the initramfs cryptroot script. Maybe these changes introduced > the bug you reported. Any messages given by 'update-initramfs -u' > would be helpful to identify possible problems here. Only the following: # update-initramfs -u update-initramfs: Generating /boot/initrd.img-3.2.0-1-686-pae cryptsetup: WARNING: target obelix_crypt uses a key file, skipped cryptsetup: WARNING: target obelix_crypt uses a key file, skipped # Roland. -- Roland Mas 'ALL your base? No!! One tiny base continue bravely to resist.' -- in #debian-devel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659688: cryptsetup: LVM on cryptsetup won't boot
busybox 1:1.19.3-5 ii dosfstools 3.0.12-1 ii initramfs-tools [linux-initramfs-tool] 0.99 ii liblocale-gettext-perl 1.05-7+b1 ii udev175-3 -- debconf information: cryptsetup/prerm_active_mappings: true -- Roland Mas When I eat a biscuit, it stays eaten! -- Arthur Dent, in So Long, and Thanks for All the Fish (Douglas Adams)
Bug#655506: iceowl: Fails to start with an "XML Parsing Error"
Guido Günther, 2012-01-16 10:15:03 +0100 : > Another reporter nailed it down to the iceowl-l10n-fr language pack. Do > you have that installed? Indeed I have, and removing it makes Iceowl start again. Good catch! Roland. -- Roland Mas Mou ichido ! Hayaku ! Ookii koede ! -- Atsuko Sasaki -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650995: #650995 dependency loop: a possible explanation
Hi all, Following the hints: - /etc/init.d/keymap.sh has Required-Start: $remote_fs - /etc/insserv.conf defines $remote_fs as including $local_fs - /etc/insserv.conf defines $local_fs as including mountall - mountall.sh has Required-Start: checkfs - checkfs.sh has Required-Start: checkroot - checkroot has Should-Start: keymap - and we loop. Roland. -- Roland Mas La menace de la baffe pèse plus lourd que la baffe elle-même. -- in Sri Raoul le petit yogi (Gaudelette) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#642507: gnucash: Missing dependency on libgoffice-0.8-8
Package: gnucash
Version: 1:2.4.7-2
Severity: serious
Gnucash refuses to start due to a missing library:
$ gnucash
gnucash: error while loading shared libraries: libgoffice-0.8.so.8: cannot open
shared object file: No such file or directory
$ ldd /usr/bin/gnucash |grep goffice
libgoffice-0.8.so.8 => not found
$
Installing libgoffice-0.8-8 by hand allows Gnucash to start again. I
guess this package should be a dependency. What's puzzling (to me) is
that libgoffice-0.8-dev is listed as a Build-Depends:, and the
debian/control file mentions ${shlibs:Depends}, but according to
http://packages.debian.org/sid/gnucash the dependency doesn't get added
on all architectures for some reason. A rebuild in an up-to-date
cowbuilder on my i386 doesn't add the dependency, for instance.
Roland.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gnucash depends on:
ii gnucash-common 1:2.4.7-2
ii guile-1.8 1.8.8+1-6
ii guile-1.8-libs 1.8.8+1-6
ii libart-2.0-2 2.3.21-1
ii libatk1.0-02.0.1-2
ii libbonobo2-0 2.24.3-1
ii libbonoboui2-0 2.24.3-1
ii libc6 2.13-21
ii libcairo2 1.10.2-6.1
ii libcrypt-ssleay-perl 0.57-2+b2
ii libdate-manip-perl 6.25-1
ii libfinance-quote-perl 1.17+git20110918-1
ii libfontconfig1 2.8.0-3
ii libfreetype6 2.4.6-2
ii libgconf2-42.32.4-1
ii libgdk-pixbuf2.0-0 2.24.0-1
ii libglib2.0-0 2.28.6-1
ii libgmp10 2:5.0.2+dfsg-1
ii libgnome2-02.32.1-1
ii libgnomecanvas2-0 2.30.3-1
ii libgnomeui-0 2.24.5-2
ii libgnomevfs2-0 1:2.24.4-1
ii libgtk2.0-02.24.6-1
ii libhtml-tableextract-perl 2.11-1
ii libhtml-tree-perl 4.2-1
ii libice62:1.0.7-2
ii libltdl7 2.4-4
ii liborbit2 1:2.14.18-0.2
ii libpango1.0-0 1.28.4-3
ii libpopt0 1.16-1
ii libsm6 2:1.2.0-2
ii libwww-perl6.02-1
ii perl 5.12.4-4
ii slib 3b1-3.1
Versions of packages gnucash recommends:
pn gnucash-docs
Versions of packages gnucash suggests:
pn libdbd-mysql
pn libdbd-pgsql
pn libdbd-sqlite3
-- no debconf information
--
Roland Mas
Sauvez un arbre, tuez un castor.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#632225: Investigating #632225 (subvertpy testsuite failure on ia64)
.so.0 (gdb) help bt Print backtrace of all stack frames, or innermost COUNT frames. With a negative argument, print outermost -COUNT frames. Use of the 'full' qualifier also prints the values of the local variables. (gdb) bt 10 #0 0x20df7f60 in run_cleanups () from /usr/lib/libapr-1.so.0 #1 0x20df44d0 in apr_pool_destroy () from /usr/lib/libapr-1.so.0 #2 0x20df4530 in apr_pool_destroy () from /usr/lib/libapr-1.so.0 #3 0x20df4530 in apr_pool_destroy () from /usr/lib/libapr-1.so.0 #4 0x20df4530 in apr_pool_destroy () from /usr/lib/libapr-1.so.0 #5 0x20df4530 in apr_pool_destroy () from /usr/lib/libapr-1.so.0 #6 0x20df4530 in apr_pool_destroy () from /usr/lib/libapr-1.so.0 #7 0x20df4530 in apr_pool_destroy () from /usr/lib/libapr-1.so.0 #8 0x20df4530 in apr_pool_destroy () from /usr/lib/libapr-1.so.0 #9 0x20df4530 in apr_pool_destroy () from /usr/lib/libapr-1.so.0 (More stack frames follow...) (gdb) bt -10 ^CQuit (gdb) I interrupted the bt after about 20 minutes without output, where gdb was consuming 1.7 GB of memory. Roland. -- Roland Mas Qu'est-ce qui est jaune, qui pèse deux cents kilos et qui chante ? Un canari. Belle bête, pas vrai ? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#632225: Investigating #632225 (subvertpy testsuite failure on ia64)
Hi,
I started having a look at the bug in the sid chroot of merulo (the ia64
porterbox). After a failed debuild, I re-ran the last command of the
debian/rules, and tried to separate the different tests to see which
were failing. My results:
(sid)lolando@merulo:~/subvertpy-0.8.5/build/lib.linux-ia64-2.7$ failed="";for i
in $(python2.7 -m testtools.run -v -f -l subvertpy.tests.test_suite); do
python2.7 -m testtools.run $i &>/dev/null || failed="$failed $i"; done;echo
$failed
Segmentation fault
Segmentation fault
Segmentation fault
subvertpy.tests.test_repos.TestClient.test_is_dir
subvertpy.tests.test_repos.TestClient.test_is_file
subvertpy.tests.test_repos.TestClient.test_paths_changed
(sid)lolando@merulo:~/subvertpy-0.8.5/build/lib.linux-ia64-2.7$
The three tests that fail are therefore test_is_dir, test_is_file and
test_paths_changed in the TestClient class. More precisely, the
segfault occurs in the
self.assertEquals(False,root.is_dir("nonexistant")) clause for
test_is_dir and test_is_file, and in
self.assertEquals({},root.paths_changed()) for test_paths_changed.
Commenting out these three lines ends in all the individual tests
passing, but running the full testsuite in a single invocation still
gets a segfault for some reason.
I haven't dug deeper, but hopefully this can help isolate the problem.
Roland.
--
Roland Mas
...sur un portable, quelque part dans le monde...
...on a laptop, somewhere in the world...
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606950: linux-image-2.6.32-5-kirkwood: USB drives not recognized anymore (sd_mod: Unknown symbol blk_queue_physical_block_size_fixed)
Package: linux-image-2.6.32-5-kirkwood Version: 2.6.32-29 Severity: grave This is a SheevaPlug computer running Squeeze. This morning's upgrade brought version 2.6.32-29 of linux-image-2.6.32-5-kirkwood (+ firmware-linux-free, linux-base and linux-libc-dev), and a reboot leaves me without access to the USB key plugged into it: no /dev/sd* devices appear, which makes the SheevaPlug almost useless (since only the system is on "embedded" storage, and the real data is on the USB key). I tried several USB keys with the same result. Reverting to 2.6.32-28 fixes that problem. Interestingly, linux-image-2.6.32-5-686 2.6.32-29 doesn't suffer from that problem, so it may be an armel-specific build error (or maybe even kirkwood-specific). My rationale for the severity is as follows: linux-image-*-kirkwood will most often be used on plug-like computers, where storage will most often happen on an USB drive rather than internal SATA/IDE/SCSD. In these circumstances, having no USB drive available turns the plug into an evolved brick; a pingable and ssh-able brick with blinking lights, but functionally a brick nevertheless :-) -- Package-specific info: ** Version: Linux version 2.6.32-5-kirkwood (Debian 2.6.32-28) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Fri Nov 26 07:01:06 UTC 2010 ** Command line: console=ttyS0,115200 ** Not tainted ** Kernel log: [ 22.771100] mv_xor mv_xor.0: Marvell XOR: ( xor cpy ) [ 22.811097] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy ) [ 22.851096] mv_xor mv_xor.2: Marvell XOR: ( xor cpy ) [ 22.891095] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy ) [ 22.897761] TCP cubic registered [ 22.901003] NET: Registered protocol family 17 [ 22.905501] Gating clock of unused units [ 22.905510] before: 0x00c701dd [ 22.905517] after: 0x00c701d9 [ 22.905809] registered taskstats version 1 [ 22.910528] rtc-mv rtc-mv: setting system clock to 2010-12-13 09:19:32 UTC (1292231972) [ 22.918591] Initalizing network drop monitor service [ 22.923645] Freeing init memory: 124K [ 23.001495] udev[44]: starting version 164 [ 23.318765] usbcore: registered new interface driver usbfs [ 23.337904] mmc0: mvsdio driver initialized, lacking card detect (fall back to polling) [ 23.346126] usbcore: registered new interface driver hub [ 23.353096] usbcore: registered new device driver usb [ 23.361129] MV-643xx 10/100/1000 ethernet driver version 1.4 [ 23.379339] mv643xx_eth smi: probed [ 23.387673] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 23.403921] net eth0: port 0 with MAC address 00:50:43:01:49:54 [ 23.410067] orion-ehci orion-ehci.0: Marvell Orion EHCI [ 23.416478] orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1 [ 23.432176] mmc0: host does not support reading read-only switch. assuming write-enable. [ 23.440314] mmc0: new high speed SDHC card at address 0007 [ 23.451132] orion-ehci orion-ehci.0: irq 19, io mem 0xf105 [ 23.468584] mmcblk0: mmc0:0007 SD08G 7.48 GiB [ 23.473109] orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00 [ 23.479109] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 23.485969] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 23.493233] usb usb1: Product: Marvell Orion EHCI [ 23.497956] usb usb1: Manufacturer: Linux 2.6.32-5-kirkwood ehci_hcd [ 23.504349] usb usb1: SerialNumber: orion-ehci.0 [ 23.509159] mmcblk0: [ 23.511915] usb usb1: configuration #1 chosen from 1 choice [ 23.518189] p1 p2 p3 < [ 23.520902] hub 1-0:1.0: USB hub found [ 23.524938] p5 > [ 23.527776] hub 1-0:1.0: 1 port detected [ 23.783632] device-mapper: uevent: version 1.0.3 [ 23.790358] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-de...@redhat.com [ 23.851100] usb 1-1: new high speed USB device using orion-ehci and address 2 [ 24.056325] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode [ 24.065665] usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 [ 24.073543] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 24.081492] usb 1-1: Product: USB2.0 Hub [ 24.102891] usb 1-1: configuration #1 chosen from 1 choice [ 24.116330] hub 1-1:1.0: USB hub found [ 24.136494] hub 1-1:1.0: 4 ports detected [ 24.421450] usb 1-1.2: new high speed USB device using orion-ehci and address 3 [ 24.647044] usb 1-1.2: New USB device found, idVendor=1b1c, idProduct=0c93 [ 24.653992] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 24.661370] usb 1-1.2: Product: Voyager GT [ 24.665488] usb 1-1.2: Manufacturer: Corsair [ 24.669778] usb 1-1.2: SerialNumber: 2863 [ 24.675454] usb 1-1.2: configuration #1 chosen from 1 choice [ 24.761439] usb 1-1.4: new full speed USB device using orion-ehci and address 4 [ 24.867327] udev[164]: starting version 164 [ 24.972410] usb 1-1.4: New USB device found, idVendor=03eb, idProduct=3
Bug#601545: bzr-rewrite: Depends on bzr (<< 2.3~)
Package: bzr-rewrite Version: 0.6.1-1 Severity: serious bzr-rewrite isn't installable in unstable currently, due to a versioned dependency on bzr that's not satisfied (unstable has 2.3.0~beta2 at the moment). Roland. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bzr-rewrite depends on: ii bzr 2.2.0-1 easy to use distributed version co ii python 2.6.6-3+squeeze1 interactive high-level object-orie ii python-central 0.6.16+nmu1 register and build utility for Pyt bzr-rewrite recommends no packages. bzr-rewrite suggests no packages. -- no debconf information -- Roland Mas Time is a drug. Too much of it kills you. -- in Small Gods (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596929: Bug#596931: gforge-db-postgresql: Database still not created on installation
reopen 596929 found 596929 5.0.2-1 tag 596929 + pending thanks Sascha Wilde, 2010-09-24 15:04:22 +0200 : [...] > Using the postgres user it turns out that there is no gforge database > in the cluster at all: Indeed. My previous fix to bug #596929 was wrong. I have committed a new one that should work. I can't do the upload right now (and I want to fix some other bugs in the next upload), but a temporary workaround is to replace , | invoke-rc.d postgresql restart || v=$? ` with , | v=0 ; invoke-rc.d postgresql restart || v=$? ` in files /var/lib/dpkg/info/gforge-db-postgresql.postinst, /var/lib/dpkg/info/gforge-db-postgresql.prerm and /usr/share/gforge/bin/install-db.sh. Then run "/var/lib/dpkg/info/gforge-db-postgresql.postinst configure" and the database should be created. Roland. -- Roland Mas Sauvez un arbre, tuez un castor. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597706: linux-image-2.6.32-5-kirkwood: Kernel panic during net initialization
Package: linux-image-2.6.32-5-kirkwood Severity: grave Version: 2.6.32-23 The latest kernel upgrade to my Sheevaplug this morning (from 2.6.32-20 to 2.6.32-23) ends up with the box not booting any longer. The box runs Squeeze, but I hadn't rebooted since upgrading to -20 (so maybe -21 was affected too). I managed to capture the attached output through the serial port. Several attempts to fiddle with stuff (restoring the previous kernel and/or initrd) have given me different backtraces, some involving ipv6 rather than ipv4, but I didn't manage to get full boot sequence, or even a ping. The logs on the DHCP server (on another box) seem to indicate that no DHCP query is sent, so I suspect something wrong in the network code. The NIC itself is probably fine, since the DHCP client built into the U-Boot firmware manages to negociate an IP address (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST and DHCPACK) and ping a host on the net. I'm not sure how I can help debug that, but I'm very willing. Roland. -- Roland Mas In every life you got some trouble, when you worry you make it double. -- in Don't worry, be happy (Bobby McFerrin) 512 MB Flash: 0 kB CPU : Marvell Feroceon (Rev 1) Streaming disabled Write allocate disabled USB 0: host mode PEX 0: interface detected no Link. Net: egiga0 [PRIME] Hit any key to stop autoboot: 3 2 1 0 SDHC found. Card desciption is: Manufacturer: 0x27, OEM "PH" Product name: "SD08G", revision 2.0 Serial number: 1832303665 Manufacturing date: 12/2009 CRC:0x00, b0 = 0 7361352 bytes read 1430120 bytes read ## Booting image at 0040 ... Image Name: Debian kernel 2.6.32-5-kirkwood Created: 2010-09-10 8:58:57 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1430056 Bytes = 1.4 MB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK OK ## Loading Ramdisk Image at 0080 ... Image Name: Debian ramdisk 2.6.32-5-kirkwood Created: 2010-09-10 8:58:59 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size:7361288 Bytes = 7 MB Load Address: Entry Point: Verifying Checksum ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-kirkwood (Debian 2.6.32-21) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 Thu Aug 26 03:31:56 UTC 2010 [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Marvell SheevaPlug Reference Board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyS0,115200 [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 256MB 256MB = 512MB total [0.00] Memory: 508032KB available (3508K code, 582K data, 124K init, 0K highmem) [0.00] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:114 [0.00] Console: colour dummy device 80x30 [ 21.474960] Calibrating delay loop... 1192.75 BogoMIPS (lpj=5963776) [ 21.714923] Security Framework initialized [ 21.714943] SELinux: Disabled at boot. [ 21.714969] Mount-cache hash table entries: 512 [ 21.715258] Initializing cgroup subsys ns [ 21.715273] Initializing cgroup subsys cpuacct [ 21.715282] Initializing cgroup subsys devices [ 21.715291] Initializing cgroup subsys freezer [ 21.715299] Initializing cgroup subsys net_cls [ 21.715341] CPU: Testing write buffer coherency: ok [ 21.716032] devtmpfs: initialized [ 21.717667] regulator: core version 0.5 [ 21.717881] NET: Registered protocol family 16 [ 21.718376] Kirkwood: MV88F6281-A0, TCLK=2. [ 21.718388] Feroceon L2: Enabling L2 [ 21.718421] Feroceon L2: Cache support initialised. [ 21.720259] bio: create slab at 0 [ 21.720521] vgaarb: loaded [ 21.720966] Switching to clocksource orion_clocksource [ 21.724587] NET: Registered protocol family 2 [ 21.724819] IP route cache hash table entries: 4096 (order: 2, 16384 bytes) [ 21.725647] TCP established hash table entries: 16384 (order: 5, 131072 bytes) [ 21.726000] TCP bind hash table entries: 16384 (order: 4, 65536 bytes) [ 21.726179] TCP: Hash tables configured (established 16384 bind 16384) [ 21.726188] TCP reno registered [ 21.726337] NET: Registered protocol family 1 [ 21.726506] Unpacking initramfs..
Bug#595951: argyll: FTBFS on kfreebsd-*: undefined reference to `linux_usbfs_backend'
Cyril Brulebois, 2010-09-07 16:57:13 +0200 : > your package no longer builds on kfreebsd-*: Indeed. Upstream switched from libusb0 to libusb1 (well, a patched version of it anyway), and libusb1 doesn't have FreeBSD support yet. The version of Argyll in unstable and Squeeze don't have this problem, so I'll ignore it for now; I'll check libusb1 from time to time for FreeBSD support, and poke upstream when appropriate. Roland. -- Roland Mas Food, shelter, source code. -- Cyclic Software -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591492: vala: FTBFS on armel: segfault
Package: vala Severity: serious Version: 0.9.4-1 Trying to build vala 0.9.4-1 in a pbuilder environment on armel fails with a segmentation fault. The full log is attached for reference. While still in the pbuilder environment, I installed gdb and libglib2.0-0-dbg, and obtained the following backtrace: , | r...@prismirale:~/vala-0.9.4# export LD_LIBRARY_PATH="/tmp/buildd/vala-0.9.4/bootstrap/install/usr/lib:$LD_LIBRARY_PATH" | r...@prismirale:~/vala-0.9.4# cd /tmp/buildd/vala-0.9.4/gee | r...@prismirale:~/vala-0.9.4/gee# gdb /tmp/buildd/vala-0.9.4/bootstrap/install/usr/bin/valac | GNU gdb (GDB) 7.1-debian | Copyright (C) 2010 Free Software Foundation, Inc. | License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> | This is free software: you are free to change and redistribute it. | There is NO WARRANTY, to the extent permitted by law. Type "show copying" | and "show warranty" for details. | This GDB was configured as "arm-linux-gnueabi". | For bug reporting instructions, please see: | <http://www.gnu.org/software/gdb/bugs/>... | Reading symbols from /tmp/buildd/vala-0.9.4/bootstrap/install/usr/bin/valac...done. | (gdb) r --target-glib=2.24 -C --vapidir ./../vapi --pkg gobject-2.0 -H valagee.h --library gee arraylist.vala collection.vala collectionobject.vala hashmap.vala hashset.vala iterable.vala iterator.vala list.vala map.vala set.vala | Starting program: /tmp/buildd/vala-0.9.4/bootstrap/install/usr/bin/valac --target-glib=2.24 -C --vapidir ./../vapi --pkg gobject-2.0 -H valagee.h --library gee arraylist.vala collection.vala collectionobject.vala hashmap.vala hashset.vala iterable.vala iterator.vala list.vala map.vala set.vala | [Thread debugging using libthread_db enabled] | | Program received signal SIGSEGV, Segmentation fault. | 0x402d7c4c in g_bsearch_array_create () | at /tmp/buildd/glib2.0-2.25.12/glib/gbsearcharray.h:137 | 137 /tmp/buildd/glib2.0-2.25.12/glib/gbsearcharray.h: No such file or directory. | in /tmp/buildd/glib2.0-2.25.12/glib/gbsearcharray.h | (gdb) bt | #0 0x402d7c4c in g_bsearch_array_create () | at /tmp/buildd/glib2.0-2.25.12/glib/gbsearcharray.h:137 | #1 g_value_c_init () at /tmp/buildd/glib2.0-2.25.12/gobject/gvalue.c:144 | #2 0x402cfcec in g_type_init_with_debug_flags ( | debug_flags=) | at /tmp/buildd/glib2.0-2.25.12/gobject/gtype.c:4313 | #3 0xe43c in main (argc=0, argv=0x18) | at ../../../compiler/valacompiler.c:1468 | (gdb) quit | A debugging session is active. | | Inferior 1 [process 23634] will be killed. | | Quit anyway? (y or n) y | r...@prismirale:~/vala-0.9.4/gee# ` The glib2.0 packages come from experimental (I built them in the same pbuilder environment, since there's no armel buildd for experimental). It's quite possible that this bug should be reassigned to glib2.0, but it's been too long since I last debugged segfault-related stuff so I'll leave that to you. Roland. -- Roland Mas ... all in all it's just another rule in the firewall. -- Ping Flood vala_0.9.4-1_armel.build.bz2 Description: Binary data
Bug#582012: gforge-web-apache2: PyFontify.py doesn't work with Python 2.6
Jakub Wilk, 2010-05-17 18:25:46 +0200 : > Hello, > > PyFontify.py uses "with" as a variable name, but "with" is a reserved > keyword in Python 2.6: FusionForge needs to switch away from ViewVC. As soon as it's done, this bug will no longer apply. Thanks, Roland. -- Roland Mas Time is a drug. Too much of it kills you. -- in Small Gods (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566768: src:argyll: FTBFS on GNU/kFreeBSD (due to usb stack switch?)
Roland Mas, 2010-01-25 09:40:41 +0100 : > Cyril Brulebois, 2010-01-25 02:26:16 +0100 : > > [...] > >> Hi, >> >> your package no longer builds on kfreebsd-*: >> | libtool: compile: gcc -DPACKAGE_NAME=\"argyll\" >> -DPACKAGE_TARNAME=\"argyll\" -DPACKAGE_VERSION=\"1.1.0\" >> "-DPACKAGE_STRING=\"argyll 1.1.0\"" -DPACKAGE_BUGREPORT=\"\" >> -DPACKAGE_URL=\"\" -DPACKAGE=\"argyll\" -DVERSION=\"1.1.0\" -DSTDC_HEADERS=1 >> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 >> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 >> -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBM=1 >> -DHAVE_LIBPTHREAD=1 -I. -I ./libusb -g -O2 -c libusb/bsd.c -fPIC -DPIC -o >> .libs/libargyllusb_la-bsd.o >> | In file included from libusb/usbi.h:4, >> | from libusb/bsd.c:44: >> | libusb/usb.h:72: error: redefinition of 'struct usb_string_descriptor' >> | libusb/usb.h:92: error: redefinition of 'struct usb_endpoint_descriptor' >> | libusb/usb.h:117: error: redefinition of 'struct usb_interface_descriptor' >> | libusb/usb.h:143: error: redefinition of 'struct usb_config_descriptor' >> | libusb/usb.h:160: error: redefinition of 'struct usb_device_descriptor' >> | […] >> | libusb/bsd.c:547: error: 'struct usb_device_info' has no member named >> 'udi_devnames' >> | libusb/bsd.c:552: error: 'struct usb_device_info' has no member named >> 'udi_devnames' >> >> Full build logs: >> https://buildd.debian.org/status/package.php?suite=&p=argyll >> >> It might have to do with a recent USB stack change on kfreebsd-*, I'm >> putting -bsd@ in Cc to get a wider audience. > > It's much more likely to be my fault: after consulting with the security > team, I'm now back to using Argyll's local copy of libusb, within the > Argyll build system. Obviously I got something wrong, and I'll need to > fix that (unless some kind soul on the -bsd list wants to :-) Actually, I think it might not be my fault after all: the libusb source package also fails to build from sources with a very similar error message, so help from the BSD porters would be welcome. [Cc:ing the libusb maintainer] Roland. -- Roland Mas Despite rumour, Death isn't cruel - merely terribly, terribly good at his job. -- in Sourcery (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566768: src:argyll: FTBFS on GNU/kFreeBSD (due to usb stack switch?)
Cyril Brulebois, 2010-01-25 02:26:16 +0100 : [...] > Hi, > > your package no longer builds on kfreebsd-*: > | libtool: compile: gcc -DPACKAGE_NAME=\"argyll\" > -DPACKAGE_TARNAME=\"argyll\" -DPACKAGE_VERSION=\"1.1.0\" > "-DPACKAGE_STRING=\"argyll 1.1.0\"" -DPACKAGE_BUGREPORT=\"\" > -DPACKAGE_URL=\"\" -DPACKAGE=\"argyll\" -DVERSION=\"1.1.0\" -DSTDC_HEADERS=1 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 > -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBM=1 > -DHAVE_LIBPTHREAD=1 -I. -I ./libusb -g -O2 -c libusb/bsd.c -fPIC -DPIC -o > .libs/libargyllusb_la-bsd.o > | In file included from libusb/usbi.h:4, > | from libusb/bsd.c:44: > | libusb/usb.h:72: error: redefinition of 'struct usb_string_descriptor' > | libusb/usb.h:92: error: redefinition of 'struct usb_endpoint_descriptor' > | libusb/usb.h:117: error: redefinition of 'struct usb_interface_descriptor' > | libusb/usb.h:143: error: redefinition of 'struct usb_config_descriptor' > | libusb/usb.h:160: error: redefinition of 'struct usb_device_descriptor' > | […] > | libusb/bsd.c:547: error: 'struct usb_device_info' has no member named > 'udi_devnames' > | libusb/bsd.c:552: error: 'struct usb_device_info' has no member named > 'udi_devnames' > > Full build logs: > https://buildd.debian.org/status/package.php?suite=&p=argyll > > It might have to do with a recent USB stack change on kfreebsd-*, I'm > putting -bsd@ in Cc to get a wider audience. It's much more likely to be my fault: after consulting with the security team, I'm now back to using Argyll's local copy of libusb, within the Argyll build system. Obviously I got something wrong, and I'll need to fix that (unless some kind soul on the -bsd list wants to :-) Roland. -- Roland Mas A lesson for you all: never fall in love during a total eclipse. -- Senex, in A Funny Thing Happened on the Way to the Forum -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545364: grub-pc: out of range pointer 0x400040
Package: grub-pc Version: 1.97~beta2-2 Severity: grave The recent grub update brought grub-pc onto my system and made it unbootable. I briefly see something appearing with the Grub version, then the screen blanks, and I get the following: , | out of range pointer 0x400040 | Aborted. Press any key to exit. ` If I press a key, I get the same behaviour again (presumably from the second drive), then the BIOS falls back on booting on the CD-ROM. At no point do I see a list of kernels or a shell. My setup: md0 is a Linux RAID-1 array made of hda1 and hdc1 and contains / (and /boot, which isn't separated onto its own partition). md1 and md2 are used in LVM for the other partitions. From other bug reports, it seems like the video card could be involved, so for the record it's an ATI Radeon 9200. I switched back to grub-legacy for now. Roland. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages grub-pc depends on: ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii grub-common 1.97~beta2-2 GRand Unified Bootloader, version ii libc6 2.9-26 GNU C Library: Shared libraries ii ucf 3.0021 Update Configuration File: preserv grub-pc recommends no packages. Versions of packages grub-pc suggests: ii desktop-base 5.0.5 common files for the Debian Deskto ii genisoimage 9:1.1.9-1 Creates ISO-9660 CD-ROM filesystem -- Roland Mas Mou ichido ! Hayaku ! Ookii koede ! -- Atsuko Sasaki -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530544: argyll: Confirmation that bug exists on Debian unstable
severity 530544 normal reassign 530544 fglrx-driver retitle 530544 fglrx-driver: Failed to get EDID for display thanks William Dutcher, 2009-05-26 08:10:32 -0500 : > Perhaps this bug shouldn't be categorized as grave. I'll follow up > with the upstream source. As far as I can see from the thread on the upstream mailing-list[1], the bug seems to be in fglrx rather than in argyll. I'm therefore reassigning the report to that package, hopefully its maintainers will be in a better position to fix it (although it's non-free). [1]http://www.freelists.org/post/argyllcms/dispwin-error-when-istalling-profile Roland. -- Roland Mas You can tune a filesystem, but you can't tuna fish. -- in the tunefs(8) manual page. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530544: argyll: dispwin fails to load profile
William Dutcher, 2009-05-25 11:33:59 -0500 : > When trying to install a profile I get the error shown below. > Note that in order to get past Bug #524478, I compiled the > package from the Argyll source. I don't want to sound overly grumpy, but if you're going to report a grave bug on a piece of software to the Debian bug tracking system, it would be in good taste to use the Debian package. Using a local build on Ubuntu doesn't help with reproducibility. Could you confirm this bug also exists on current Debian unstable? If you can't, I suggest you contact the upstream mailing-list (see http://www.freelists.org/list/argyllcms for details). You'll probably need to attach your .icc file. Roland. -- Roland Mas LinkedIn profile: http://www.linkedin.com/in/rolandmas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529283: gxmms2: Fails to build from source
Package: gxmms2 Severity: serious Version: 0.7.0-2 gxmms2 currently fails to build from source in an up-to-date pbuilder, with lots of "undefined reference" errors at link time. I guess this is related to the XMMS2 upstream release with its new API. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Roland Mas Seems to me, the only sensible thing is for people to know if they kill a whale, they've got a dead whale. -- Adam, in Good Omens (T. Pratchett and N. Gaiman) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524430: gforge-plugin-scmsvn: gforge doen't create the svn repositories automatically
Roland Mas, 2009-04-27 16:05:22 +0200 : > Are you sure the repositories aren't created after at least an hour? > If so, could you run the following command and report any errors? I just did a fresh installation on a Lenny system, and the repository is indeed created with no manual intervention. However, due to how the scripts work and how the crontabs are organised, it can take from fifteen minutes to an hour and fifteen minutes before that happens. Please confirm that your repositories really aren't created after that period of time. Roland. -- Roland Mas Bee There Orr Bee A Rectangular Thyng! -- in Soul Music (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524478: argyll: colprof crashes: Tag 'AToB1 Multidemntional Transform not found
Roland Mas, 2009-04-17 21:03:25 +0200 : > Mark Whitis, 2009-04-17 08:57:15 -0400 : > >> colprof -v -D "VT1760 USB Microscope" Camera >># colprof: Error - Write file: 2, icc_read_tag: Tag 'AToB1 >> Multidimentional Transform' not found > > A very similar problem has just been reported on the ArgyllCMS > mailing-list[1]. And another one got the reply at [1]. The upstream author believes the bug comes from the recent security patches applied on icclib. I'll see if he has an updated patch. http://www.freelists.org/post/argyllcms/Error-during-colprof-with-nVidia-on-Fedora-10,1 Roland. -- Roland Mas Why did the elephant cross the road? Because it was the chicken's day off. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524430: gforge-plugin-scmsvn: gforge doen't create the svn repositories automatically
marianoguerra, 2009-04-17 01:16:57 -0300 :
> when I create a project selecting the svn repository when I go to the
> scm page the following message appears:
>
> "The repository for this project isn't created yet. It will be created
> in the next few minutes."
>
> the repository is not created.
>
> then I tryed to run the script
>"/usr/share/gforge/plugins/scmsvn/cronjobs/create_svn.php" and after
>adding [0] it gave an error on line 55 saying that $err was not defined
Probably just a PHP warning (I think it's been fixed in recent
versions anyway).
> then I added the following line before line 55:
>
> if(!defined("err"))$err="";
>
> and executed again, the repositories were created ok.
>
> I checked the cronjob on /etc/cron.d/gforge-plugin-scmsvn and the
> create_svn.php file is not called.
Correct.
> maybe on this line:
>
> Repositories update 45 * * * * root [ -x
> /usr/share/gforge/plugins/scmsvn/cronjobs/svn_dump.pl ]
> && su -s /bin/sh gforge -c
> /usr/share/gforge/plugins/scmsvn/cronjobs/svn_dump.pl > /dev/null 2>&1
> && [ -x /usr/share/gforge/plugins/scmsvn/cronjobs/svn_update.pl ] &&
> /usr/share/gforge/plugins/scmsvn/cronjobs/svn_update.pl > /dev/null 2>&1
>
> should be added something line this?
>
> && [ -x /usr/share/gforge/plugins/scmsvn/cronjobs/create_svn.php ] &&
> /usr/share/gforge/plugins/scmsvn/cronjobs/create_svn.php > /dev/null
> 2>&1
No. In the Debian packages of GForge/FusionForge, the svn_update.pl
scripts handles the repository creation.
Are you sure the repositories aren't created after at least an hour?
If so, could you run the following command and report any errors?
su -s /bin/sh gforge -c /usr/share/gforge/plugins/scmsvn/cronjobs/svn_dump.pl
&& /usr/share/gforge/plugins/scmsvn/cronjobs/svn_update.pl
Thanks,
Roland.
--
Roland Mas
Indépendant en informatique libre -- Free software freelance
http://www.gnurandal.com/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524478: argyll: colprof crashes: Tag 'AToB1 Multidemntional Transform not found
Mark Whitis, 2009-04-17 08:57:15 -0400 : > colprof -v -D "VT1760 USB Microscope" Camera ># colprof: Error - Write file: 2, icc_read_tag: Tag 'AToB1 > Multidimentional Transform' not found A very similar problem has just been reported on the ArgyllCMS mailing-list[1]. The reporter there seems to think there might be a correlation with the NVidia proprietary drivers. Do you also use them? It might help track down the bug if you can confirm that you are; and if you're not, then it's probably something else. [1] http://www.freelists.org/post/argyllcms/Error-during-colprof-stage-nvidia-related Roland. -- Roland Mas It would be hard to be deader without special training. -- in Theatre of Cruelty (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522448: CVE-2008-0584/CVE-2008-0583: Security issues in ICC library
Updated version of the patch follows (this one even builds...).
--
Roland Mas
Je suis un anti-virus de signature.
Copiez-moi dans la vôtre pour éliminer les virus de signature !
=== modified file 'icc/icc.c'
--- icc/icc.c 2008-11-16 13:45:00 +
+++ icc/icc.c 2009-04-03 21:08:19 +
@@ -53,6 +53,8 @@
#define _ICC_C_/* Turn on implimentation code */
+#include
+#include
#include
#include
#include
@@ -146,8 +148,11 @@
icmFileMem *p = (icmFileMem *)pp;
size_t len;
+ if (count > 0 && size > SIZE_MAX / count)
+ return 0;
+
len = size * count;
- if ((p->cur + len) >= p->end) { /* Too much */
+ if (len > (p->end - p->cur)) { /* Too much */
if (size > 0)
count = (p->end - p->cur)/size;
else
@@ -1957,6 +1962,8 @@
/* Allocate a file write buffer */
len = p->get_size((icmBase *)p);
+ if (icp->errc)
+ return icp->errc;
if ((buf = (char *) icp->al->malloc(icp->al, len)) == NULL) {
sprintf(icp->err,"icmUInt8Array_write malloc() failed");
return icp->errc = 2;
@@ -2021,7 +2028,7 @@
if (p->size != p->_size) {
if (p->data != NULL)
icp->al->free(icp->al, p->data);
- if ((p->data = (unsigned int *) icp->al->malloc(icp->al, p->size * sizeof(unsigned int))) == NULL) {
+ if ((p->data = (unsigned int *) icp->al->calloc(icp->al, p->size, sizeof(unsigned int))) == NULL) {
sprintf(icp->err,"icmUInt8Array_alloc: malloc() of icmUInt8Array data failed");
return icp->errc = 2;
}
@@ -2072,6 +2079,10 @@
icmUInt16Array *p = (icmUInt16Array *)pp;
unsigned int len = 0;
len += 8; /* 8 bytes for tag and padding */
+ if (p->size > (UINT_MAX - len) / 2) {
+ p->icp->errc = 1;
+ return (unsigned int) -1;
+ }
len += p->size * 2; /* 2 bytes for each UInt16 */
return len;
}
@@ -2144,6 +2155,8 @@
/* Allocate a file write buffer */
len = p->get_size((icmBase *)p);
+ if (icp->errc)
+ return icp->errc;
if ((buf = (char *) icp->al->malloc(icp->al, len)) == NULL) {
sprintf(icp->err,"icmUInt16Array_write malloc() failed");
return icp->errc = 2;
@@ -2208,7 +2221,7 @@
if (p->size != p->_size) {
if (p->data != NULL)
icp->al->free(icp->al, p->data);
- if ((p->data = (unsigned int *) icp->al->malloc(icp->al, p->size * sizeof(unsigned int))) == NULL) {
+ if ((p->data = (unsigned int *) icp->al->calloc(icp->al, p->size, sizeof(unsigned int))) == NULL) {
sprintf(icp->err,"icmUInt16Array_alloc: malloc() of icmUInt16Array data failed");
return icp->errc = 2;
}
@@ -2259,6 +2272,10 @@
icmUInt32Array *p = (icmUInt32Array *)pp;
unsigned int len = 0;
len += 8; /* 8 bytes for tag and padding */
+ if (p->size > (UINT_MAX - len) / 4) {
+ p->icp->errc = 1;
+ return (unsigned int) -1;
+ }
len += p->size * 4; /* 4 bytes for each UInt32 */
return len;
}
@@ -2331,6 +2348,8 @@
/* Allocate a file write buffer */
len = p->get_size((icmBase *)p);
+ if (icp->errc)
+ return icp->errc;
if ((buf = (char *) icp->al->malloc(icp->al, len)) == NULL) {
sprintf(icp->err,"icmUInt32Array_write malloc() failed");
return icp->errc = 2;
@@ -2395,7 +2414,7 @@
if (p->size != p->_size) {
if (p->data != NULL)
icp->al->free(icp->al, p->data);
- if ((p->data = (unsigned int *) icp->al->malloc(icp->al, p->size * sizeof(unsigned int))) == NULL) {
+ if ((p->data = (unsigned int *) icp->al->calloc(icp->al, p->size, sizeof(unsigned int))) == NULL) {
sprintf(icp->err,"icmUInt32Array_alloc: malloc() of icmUInt32Array data failed");
return icp->errc = 2;
}
@@ -2446,6 +2465,10 @@
icmUInt64Array *p = (icmUInt64Array *)pp;
unsigned int len = 0;
len += 8; /* 8 bytes for tag and padding */
+ if (p->size > (UINT_MAX - len) / 8) {
+ p->icp->errc = 1;
+ return (unsigned int) -1;
+ }
len += p->size * 8; /* 8 bytes for each UInt64 */
return len;
}
@@ -2518,6 +2541,8 @@
/* Allocate a file write buffer */
len = p->get_size((icmBase *)p);
+ if (icp->errc)
+ return icp->errc;
if ((buf = (char *) icp->al->malloc(icp->al, len)) == NULL) {
sprintf(icp->err,"icmUInt64Array_write malloc() failed");
return icp->errc = 2;
@@ -2582,7 +2607,7 @@
if (p->size != p->_size) {
if (p->data != NULL)
icp->al->free(icp->al, p->data);
- if ((p->data = (icmUint64 *) icp->al->malloc(icp->al, p->size * sizeof(icmUint64))) == NULL) {
+ if ((p->data = (icmUint64 *) icp->al->calloc(icp->al, p->size, sizeof(icmUint64))) == NULL) {
sprintf(icp->err,"icmUInt64Array_alloc: malloc() of icmUInt64Array data failed");
return icp->errc =
Bug#522448: CVE-2008-0584/CVE-2008-0583: Security issues in ICC library
retitle 522448 CVE-2009-0584/CVE-2009-0583: Security issues in ICC library
thanks
Moritz Muehlenhoff, 2009-04-03 21:41:14 +0200 :
> Package: argyll
> Severity: grave
> Tags: security
>
> Let's welcome argyll in the archive with an RC security bug :-)
*grmbl* Thanks, I guess :-)
> argyll embeds a copy of icclib, which has recently been fixed in a DSA
> for ghostscript. I'm attaching the patch from the DSA, please pass it
> to argyll upstream and the maintainer of debian-multimedia.org
Okay. It doesn't apply cleanly, but I'm porting it as best I can and
submitting it upstream for validation. If you're aware of the workings
of the patch, I'd also value your input. The ported patch is attached,
and I'll upload it soon.
Roland.
--
Roland Mas
Magic is one thing, and reflected-sound-of-underground-spirits is another.
-- Twoflower, in The Colour of Magic (Terry Pratchett)
=== modified file 'icc/icc.c'
--- icc/icc.c 2008-11-16 13:45:00 +
+++ icc/icc.c 2009-04-03 20:33:33 +
@@ -53,6 +53,8 @@
#define _ICC_C_/* Turn on implimentation code */
+#include
+#include
#include
#include
#include
@@ -146,8 +148,11 @@
icmFileMem *p = (icmFileMem *)pp;
size_t len;
+ if (count > 0 && size > SIZE_MAX / count)
+ return 0;
+
len = size * count;
- if ((p->cur + len) >= p->end) { /* Too much */
+ if (len > (p->end - p->cur)) { /* Too much */
if (size > 0)
count = (p->end - p->cur)/size;
else
@@ -1957,6 +1962,8 @@
/* Allocate a file write buffer */
len = p->get_size((icmBase *)p);
+ if (icp->errc)
+ return icp->errc;
if ((buf = (char *) icp->al->malloc(icp->al, len)) == NULL) {
sprintf(icp->err,"icmUInt8Array_write malloc() failed");
return icp->errc = 2;
@@ -2021,7 +2028,7 @@
if (p->size != p->_size) {
if (p->data != NULL)
icp->al->free(icp->al, p->data);
- if ((p->data = (unsigned int *) icp->al->malloc(icp->al, p->size * sizeof(unsigned int))) == NULL) {
+ if ((p->data = (unsigned int *) icp->al->calloc(icp->al, p->size, sizeof(unsigned int))) == NULL) {
sprintf(icp->err,"icmUInt8Array_alloc: malloc() of icmUInt8Array data failed");
return icp->errc = 2;
}
@@ -2072,6 +2079,10 @@
icmUInt16Array *p = (icmUInt16Array *)pp;
unsigned int len = 0;
len += 8; /* 8 bytes for tag and padding */
+ if (p->size > (UINT_MAX - len) / 2) {
+ p->icp->errc = 1;
+ return (unsigned int) -1;
+ }
len += p->size * 2; /* 2 bytes for each UInt16 */
return len;
}
@@ -2144,6 +2155,8 @@
/* Allocate a file write buffer */
len = p->get_size((icmBase *)p);
+ if (icp->errc)
+ return icp->errc;
if ((buf = (char *) icp->al->malloc(icp->al, len)) == NULL) {
sprintf(icp->err,"icmUInt16Array_write malloc() failed");
return icp->errc = 2;
@@ -2208,7 +2221,7 @@
if (p->size != p->_size) {
if (p->data != NULL)
icp->al->free(icp->al, p->data);
- if ((p->data = (unsigned int *) icp->al->malloc(icp->al, p->size * sizeof(unsigned int))) == NULL) {
+ if ((p->data = (unsigned int *) icp->al->calloc(icp->al, p->size, sizeof(unsigned int))) == NULL) {
sprintf(icp->err,"icmUInt16Array_alloc: malloc() of icmUInt16Array data failed");
return icp->errc = 2;
}
@@ -2259,6 +2272,10 @@
icmUInt32Array *p = (icmUInt32Array *)pp;
unsigned int len = 0;
len += 8; /* 8 bytes for tag and padding */
+ if (p->size > (UINT_MAX - len) / 4) {
+ p->icp->errc = 1;
+ return (unsigned int) -1;
+ }
len += p->size * 4; /* 4 bytes for each UInt32 */
return len;
}
@@ -2331,6 +2348,8 @@
/* Allocate a file write buffer */
len = p->get_size((icmBase *)p);
+ if (icp->errc)
+ return icp->errc;
if ((buf = (char *) icp->al->malloc(icp->al, len)) == NULL) {
sprintf(icp->err,"icmUInt32Array_write malloc() failed");
return icp->errc = 2;
@@ -2395,7 +2414,7 @@
if (p->size != p->_size) {
if (p->data != NULL)
icp->al->free(icp->al, p->data);
- if ((p->data = (unsigned int *) icp->al->malloc(icp->al, p->size * sizeof(unsigned int))) == NULL) {
+ if ((p->data = (unsigned int *) icp->al->calloc(icp->al, p->size, sizeof(unsigned int))) == NULL) {
sprintf(icp->err,"icmUInt32Array_alloc: malloc() of icmUInt32Array data failed");
return icp->errc = 2;
}
@@ -2446,6 +2465,10 @@
icmUInt64Array *p = (icmUInt64Array *)pp;
unsigned int len = 0;
len += 8; /* 8 bytes for tag and padding */
+ if (p->size > (UINT_MAX - len) / 8) {
+ p->icp->errc = 1;
+ return (unsigned int) -1;
+ }
len += p->size * 8; /* 8 bytes for each UInt64 */
return len;
}
@@ -2518,6 +2541,8 @@
/* All
Bug#509285: Confirming bug #509285
As requested by Loïc, I tried building mbr 1.1.10-1 in an up-to-date cowbuilder environment, and I get exactly the same errors. So I'm letting the bug know :-) Roland. -- Roland Mas Meaning lies as much / In the mind of the reader / As in the haiku -- in Gödel, Escher, Bach: an Eternal Golden Braid (Douglas Hofstadter) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504258: CVE-2008-4796: missing input sanitising in embedded copy of Snoopy.class.php
severity 504258 important thanks Raphael Geissert, 2008-11-02 01:18:06 -0600 : > Package: gforge-plugin-scmcvs > Severity: grave > Version: 4.5.14-5 > Tags: security > > Hi, > > The following CVE (Common Vulnerabilities & Exposures) id was published for > snoopy, which affects the embedded copy shipped by gforge-plugin-scmcvs [0]. > > CVE-2008-4796[1]: >> The _httpsrequest function (Snoopy/Snoopy.class.php) in Snoopy 1.2.3 >> and earlier allows remote attackers to execute arbitrary commands via >> shell metacharacters in https URLs. Since gforge-plugin-scmcvs only uses Snoopy on fixed URLs that do not come from the user, I don't think it is affected by this particular security problem. I'm therefore downgrading the severity of this bug report. Roland. -- Roland Mas Qu'est-ce qui est jaune, qui pèse deux cents kilos et qui chante ? Un sumotori dans sa salle de bains. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504758: gforge-plugins-extra ships security issues-prone code copies
tag 504758 + help thanks Raphael Geissert, 2008-11-06 15:42:52 -0600 : > Package: gforge-plugins-extra > Severity: serious > Version: 4.7~rc2-5 > Tags: security > > Hi, > > By taking a look at the list of files shipped by > gforge-plugins-extra I can easily see several scripts which are > already in the Debian archive. I'm using 'serious' as the severity > given the fact that in many of the already packaged scripts security > issues have been found in the past. I'm sort of aware of that, but I'm undecided as to how to react. This package contains plugins that are not exactly supported (by me at least), and these plugins are not installed or made operational when the package is installed. They require manual intervention to set up, and are only shipped as part of a deb as a convenience. The way I see it, there are three ways out: - prepare a new upload that doesn't contain this binary package, and leave users with the task of getting the code from the source package and installing it by hand; - ignore this bug for lenny, since one could argue that the code isn't actually made operational by the mere installation of the package; - actually patch the code to use system-provided packages, and update dependencies accordingly. This has already been done for some libraries (Snoopy and FCKeditor), and it's not a huge task, but I probably won't have time to tackle it before the lenny release (real-life time constraints abound). I'm therefore soliciting advice and/or help on that problem. Roland. -- Roland Mas A lesson for you all: never fall in love during a total eclipse. -- Senex, in A Funny Thing Happened on the Way to the Forum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497688: Freeze exception request for kino 1.3.0-2.1
Hi release team, I would like to request a freeze exception for the kino package. Version currently in sid/lenny is 1.3.0-2 and fails to build from source (serious bug #497688) due to outdated build-dependencies. I prepared a 1.3.0-2.1 upload (currently on its way to sid) fixing the build-dep (and removing myself from the Uploaders field). Here's the diff between the current and proposed source packages: $ debdiff kino_1.3.0-2.dsc kino_1.3.0-2.1.dsc diff -u kino-1.3.0/debian/control kino-1.3.0/debian/control --- kino-1.3.0/debian/control +++ kino-1.3.0/debian/control @@ -2,12 +2,11 @@ Section: graphics Priority: extra Maintainer: Paul Brossier <[EMAIL PROTECTED]> -Uploaders: Roland Mas <[EMAIL PROTECTED]> Standards-Version: 3.7.3 Homepage: http://www.kinodv.org/ Vcs-Browser: http://kino.cvs.sourceforge.net/kino/ Vcs-Cvs: :pserver:[EMAIL PROTECTED]:/cvsroot/kino -Build-Depends: [...] libiec61883-dev, libdc1394-13-dev, libvorbis-dev, [...] +Build-Depends: [...] libiec61883-dev, libdc1394-22-dev, libvorbis-dev, [...] Build-Conflicts: autoconf2.13, automake1.4 Package: kino diff -u kino-1.3.0/debian/changelog kino-1.3.0/debian/changelog --- kino-1.3.0/debian/changelog +++ kino-1.3.0/debian/changelog @@ -1,3 +1,11 @@ +kino (1.3.0-2.1) unstable; urgency=low + + * Removed myself from Uploaders, which makes this a non-maintainer upload. + * Updated build-depends to match current versions of libraries (closes: +#497688). + + -- Roland Mas <[EMAIL PROTECTED]> Wed, 10 Sep 2008 09:40:01 +0200 + kino (1.3.0-2) unstable; urgency=low * Fix build-depends on libgl, use libgl1-mesa-dev | libgl-dev Thanks, Roland. -- Roland Mas When you have a hammer in your hand, most things look like a nail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497688: kino FTBFS
Hi Paul, I seem to remember you used to have problems with your GPG key. If that's still the case, would you like me to upload a fixed package for kino? The fix is, indeed, quite simple (just replace libdc1394-13-dev, with libdc1394-22-dev in the build-deps), and works in sid as well as lenny. Roland. -- Roland Mas C'est dans la boue la plus nauséeuse que plongent les racines de l'étincelante fleur de lotus. -- in Sri Raoul le petit yogi (Gaudelette) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495319: uswsusp: s2disk reboots instead of halting
Hi, I had this behaviour recently (a couple of weeks ago maybe) too. I fixed that by setting "shutdown method = shutdown" in /etc/uswsusp.conf (previous value was "reboot"). I don't know why that file was changed (I certainly didn't put the "reboot" in there), but that might be a possible direction to explore: maybe the maintainer scripts overwrite that data. Roland. -- Roland Mas OpenPGP keys on http://www.keyserver.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402010: How to deal with #402010?
Cajus Pollmeier, 2008-04-04 09:18:37 +0200 : > Hi, > > my position to this bug is written down in the bugtracker and I > don't consider this a bug. Any opinions about what to do with it? It > would apply to virtually any kind of web application accessing some > kind of database/ldap passwords somewhere in the filesystem. Depending on the web server, there may be a way around that problem. The following works with Apache, at least, and I guess it can be adapted to other servers as well. The thing is to store the passwords or sensitive info in files that are only readable by root, and have Apache read these files and export the information selectively to some webapps and not others, by wrapping the appropriate directives in VirtualHost (or similar) blocks. Then it's a simple matter (ahem) of passing the info to the webapp, and there are two ways to do that: with SetEnv (not ideal) or with RequestHeader (probably better). Roland. -- Roland Mas Et c'est tellement plus mignon de se faire traiter de con en chanson... -- in En chantant (Michel Sardou) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#472133: bzr-svn: uninstallable with current bzr
Package: bzr-svn Version: 0.4.8-1 Severity: serious Although bzr-svn 0.4.8-1 closed the letter of #468807, the spirit of that bug report remains: 0.4.8-1 depends on bzr (<< 1.3~), but bzr in sid is 1.3-1, which makes bzr-svn uninstallable in sid (and will prevent migration to lenny in a few days, too). A local rebuild with a loosened versioned dependency seems to work for me, though. Roland. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bzr-svn depends on: ii bzr 1.3-1easy to use distributed version co ii python 2.4.4-6 An interactive high-level object-o ii python-central 0.6.1register and build utility for Pyt ii python-pysqlite22.4.1-1 Python interface to SQLite 3 ii python-subversion 1.4.6dfsg1-2 Python bindings for Subversion Versions of packages bzr-svn recommends: ii bzr-rebase0.3-1 Rebase plugin for Bazaar -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459649: f-spot: Extensions broken on upgrade
Package: f-spot Version: 0.4.1-4 Severity: grave Upgrading f-spot makes some extensions unavailable (the ones shipped with F-Spot, but strangely not the external ones such as DevelopInUfraw and RawPlusJpeg). I'm pasting from IRC (with only minor edits), here's some context: - broken = the "Export To" menu has an empty submenu; - rebuilding DB = mautil -v --registry ~/.gnome2/f-spot reg-build With f-spot 0.4.1-3, the external extensions are operational, but the built-ins are not. (built-ins = exporters) Lo-lan-do: do you get assembly warnings again, right? Mono.Addins.Serialization... Not even Lo-lan-do: try rebuild of DB again Lo-lan-do: after upgrading to -4 it should be broken again, it seems to be an in issue of mono-addins, but knowing the f-spot code base I am pretty sure f-spot is fucked the code has such bad error handling, never saw something like that last time I saw such code was ifolder from novell monodevelop is extremly clean, mono-addins I dont remember After a DB rebuild, all extensions work and now upgrade to -4 should be broken again * Lo-lan-do upgrades back to 0.4.1-4 any change AFAIK breaks it Correct. Built-ins are broken again (but still no warning, and external extensions still not broken) I'll give it a go. Lo-lan-do: could you please file a bugreport about this case? the other one was about ABI breakage of flickrnet which is closed now Lo-lan-do: make it RC Roland. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages f-spot depends on: ii beagle 0.3.2-1 indexing and search tool for your ii dbus1.1.2-1 simple interprocess messaging syst ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libc6 2.7-5GNU C Library: Shared libraries ii libcairo2 1.4.12-2 The Cairo 2D vector graphics libra ii libexif12 0.6.16-2.1 library to parse EXIF files ii libflickrnet2.1.5-cil 25277-5 Flickr.Net API Library ii libgconf2.0-cil 2.16.0-10CLI binding for GConf 2.16 ii libgl1-mesa-glx [libgl1]7.0.2-3 A free implementation of the OpenG ii libglade2.0-cil 2.10.2-5 CLI binding for the Glade librarie ii libglib2.0-02.14.4-2 The GLib library of C routines ii libglib2.0-cil 2.10.2-5 CLI binding for the GLib utility l ii libgnome-vfs2.0-cil 2.16.0-10CLI binding for GnomeVFS 2.16 ii libgnome2.0-cil 2.16.0-10CLI binding for GNOME 2.16 ii libgnomeui-02.20.1.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.20.1-1 GNOME Virtual File System (runtime ii libgphoto2-22.4.0-8 gphoto2 digital camera library ii libgphoto2-port02.4.0-8 gphoto2 digital camera port librar ii libgtk2.0-0 2.12.3-2 The GTK+ graphical user interface ii libgtk2.0-cil 2.10.2-5 CLI binding for the GTK+ toolkit 2 ii libgtkhtml2.0-cil 2.16.0-10CLI binding for GtkHTML 3.8 ii libjpeg62 6b-14The Independent JPEG Group's JPEG ii liblcms11.16-8 Color management library ii libmono-addins-gui0.2-cil 0.3-2GTK# frontend library for Mono.Add ii libmono-addins0.2-cil 0.3-2addin framework for extensible CLI ii libmono-corlib2.0-cil 1.2.6+dfsg-5 Mono core library (2.0) ii libmono-sharpzip2.84-cil1.2.6+dfsg-5 Mono SharpZipLib library ii libmono-sqlite2.0-cil 1.2.6+dfsg-5 Mono Sqlite library ii libmono-system-data2.0-cil 1.2.6+dfsg-5 Mono System.Data Library ii libmono-system-web2.0-cil 1.2.6+dfsg-5 Mono System.Web Library ii libmono-system2.0-cil 1.2.6+dfsg-5 Mono System libraries (2.0) ii libmono2.0-cil 1.2.6+dfsg-5 Mono libraries (2.0) ii libndesk-dbus-glib1.0-cil 0.4.1-1 CLI implementation of D-Bus (GLib ii libndesk-dbus1.0-cil0.6.0-1 CLI implementation of D-Bus ii libx11-62:1.0.3-7X11 client-side library ii libxcomposite1 1:0.4.0-1X11 Composite extension library ii mono-runtime1.2.6+dfsg-5 Mono runtime Versions of packages f-spot recommends: ii dcraw 8.80-1 decode raw digital camera images pn sqlite (no description available) ii sqlite3 3.4.2-2A command line interface for SQLit -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [
Bug#436335: kinoplus: FTBFS: error: redefinition of 'class KeyFrameControllerClient'
tags 436335 + wontfix thanks Lucas Nussbaum, 2007-08-07 00:56:20 +0200 : > Package: kinoplus > version: 0.3.5-3 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: qa-ftbfs-20070806 qa-ftbfs > Justification: FTBFS on i386 Kinoplus, which previously was an external plugin, has now been merged into Kino. As such, it's not needed with the version of Kino currently in unstable, and I'll ask for removal as soon as that version is ready to enter testing (it's still needed in testing). Therefore, I don't think I'll work on fixing that bug :-) Roland. -- Roland Mas M-x execute-extended-command -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432827: docbook-doc: please consider not releasing this package with lenny
retitle 432827 RM: docbook-doc -- RoM; old and useless reassign 432827 ftp.debian.org thanks I fully agree with Lucas's reasons for removing that venerable old package. It's not as if I even used it anymore myself. Please consider removing docbook-doc from sid/lenny. Roland. -- Roland Mas ...sur un portable, quelque part dans le monde... ...on a laptop, somewhere in the world... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394933: Not yet fixed
John Goerzen, 2006-10-26 14:01:52 -0500 :
> I just installed 4.5.14-16 from scratch, and it still broke my
> Apache2 setup due to Listen and NameVirtualHost directives.
Ah, I had forgotten a "Listen 80" directive. Sorry about that. On
the other hand, I can't find any general NameVirtualHost directive;
the only remaining ones are now "NameVirtualHost {ip_address}:80" and
"NameVirtualHost {ip_address}:80" (with the IP address filled in,
obviously). Could you send me your
/etc/apache2/conf.d/gforge.httpd.conf so I can have a look?
Roland.
--
Roland Mas
Êtes vous sûr ? (O/N)
-- Derniers mots d'un ordinateur
Bug#395394: gforge-web-apache: Problem installing
John Goerzen, 2006-10-26 13:58:54 -0500 : > Package: gforge-web-apache > Version: 4.5.14-16 > Severity: grave > Justification: renders package unusable > > While installing, I got a ton of error messages: [...] Is this really in gforge-web-apache? I can't find any trace of this package trying to create files in htdocs... The log you pasted looks like it's the output of gforge-plugin-scmcvs instead, so I'm confused. I don't even see how this makes the package unusable. Would you enlighten me? Roland. -- Roland Mas Qui trop embrasse rate son train. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394142: Patch for #394142
Hi,
After a bit of talking with Mirco Bauer on IRC, I came up with this
patch, which seems to make F-Spot building again here.
diff -ru -x changelog f-spot-0.2.1-1/src/FlickrExport.cs f-spot-0.2.1+patched/src/FlickrExport.cs
--- f-spot-0.2.1-1/src/FlickrExport.cs 2006-10-27 09:45:15.0 +0200
+++ f-spot-0.2.1+patched/src/FlickrExport.cs 2006-10-27 09:42:19.0 +0200
@@ -145,12 +145,12 @@
}
Gtk.Application.Invoke (this, args, delegate (object sender, EventArgs sargs) {
-AuthorizationEventArgs args = (AuthorizationEventArgs) sargs;
+AuthorizationEventArgs args2 = (AuthorizationEventArgs) sargs;
-do_export_flickr.Sensitive = args.Auth != null;
+do_export_flickr.Sensitive = args2.Auth != null;
if (args.Auth != null) {
- token = args.Auth.Token;
- auth = args.Auth;
+ token = args2.Auth.Token;
+ auth = args2.Auth;
CurrentState = State.Authorized;
Preferences.Set (Preferences.EXPORT_FLICKR_TOKEN, fr.Token);
} else {
Roland.
--
Roland Mas
Meaning lies as much / In the mind of the reader / As in the haiku
-- in Gödel, Escher, Bach: an Eternal Golden Braid (Douglas Hofstadter)
Bug#392754: FTBFS: quicktime/quicktime.h: No such file or directory
Martin Michlmayr, 2006-10-13 11:49:15 +0100 : >> Automatic build of smilutils_0.3.0-10 on chico by sbuild/i386 0.49 [...] >> filehandler.h:167:33: error: quicktime/quicktime.h: No such file or >> directory This is fixed locally, but smilutils still fails to build from source because of bug #391849 in libquicktime-dev. I'll upload as soon as that is fixed. Thanks for the report, Roland. -- Roland Mas That's one of the good fings about not existin'; they leave you alone most of the time. -- in My Hero (Tom Holt) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358241: gforge-db-postgresql: Uninstallable and un-uninstallable :O
tag 358241 + fixed-in-experimental thanks Julien Cristau, 2006-04-20 21:42:22 +0200 : > gforge-db-postgresql seems to only work with the old postgresql > packages, as they are organized in sarge. > Now there are multiple versions of server packages, which can be > installed at the same time. This means that /usr/lib/postgresql/bin > doesn't exist, and that /etc/init.d/postgresql doesn't exist either, for > example. > Roland, do you plan on updating gforge to a newer upstream soon, or > should I try to work on a patch to update gforge to the new postgresql > packaging scheme? Packages for Gforge 4.5.14 have just been accepted into experimental, and they should work fine with current Postgresql packaging. I'm currently considering whether I should migrate the packages to dbconfig-common before uploading to unstable. Testing of the experimental packages would be welcome in the meantime. Roland. -- Roland Mas Death *was* hereditary. You got it from your ancestors. -- in Hogfather (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364440: Missing depend on libmono-sqlite1.0-cil
Paul van Tilburg, 2006-04-23 16:04:33 +0200 : > Package: f-spot > Version: 0.1.8-1.1 > Severity: grave > > The f-spot package is missing a depend on libmono-sqlite1.0-cil. This has been fixed in version 0.1.11-1, presently in unstable. Apparently the automatic build failed on powerpc, which explains your old version. Roland. -- Roland Mas Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life -- Solid Jackson, in Jingo (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337240: f-spot: still repro...
Benoît Dejean, 2006-04-21 08:17:43 +0200 : > Package: f-spot > Version: 0.1.8-1.1 > Followup-For: Bug #337240 > > Still reproducable. Why ppc is lagging that much ? why is it stuck > in 0.1.8 where i386 has 0.1.11 ? http://buildd.debian.org/fetch.php?&pkg=f-spot&ver=0.1.11-1&arch=powerpc&stamp=1145465876&file=log&as=raw Apparently Mono wasn't quite available yet on powerpc when F-Spot was last built. Roland. -- Roland Mas C r ' s d a ue ell r a u i r . -- Signatures à collectionner, série n°1, partie 1/3.
Bug#358241: gforge-db-postgresql: Uninstallable and un-uninstallable :O
Julien Cristau (2006-04-20 21:42:22 +0200) : > Roland, do you plan on updating gforge to a newer upstream soon, or > should I try to work on a patch to update gforge to the new > postgresql packaging scheme? I plan on updating Gforge to a newer upstream, but I'm not sure exactly when. There have been numerous changes in Gforge, some of which I don't quite agree with, and it'll take some time to check them all. In the meantime, you can use Christian Bayle's packages at http://gforge.grazian.org/, they mostly work on both sarge and etch. Roland. -- Roland Mas 'ALL your base? No!! One tiny base continue bravely to resist.' -- in #debian-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358551: Two bugs fixed in 0.1.11
Hi, I downloaded the 0.1.11 upstream tarball and ran uupdate on it. I then fiddled a bit with the debian/patches directory, and I now have an f-spot_0.1.11-0.1_i386.deb packages where bugs #358551 and #349501 are both fixed. The package (source+binary) is currently available on http://roland.mas.free.fr/debian/unstable/ (and will probably stay there at least until a fixed f-spot enters unstable). I haven't tried to reproduce the other outstanding bugs. Andrew: if you're still busy, I could clean up the package a bit (in particular 01_fix_wrapper.dpatch was ported very crudely) and NMU. Roland. -- Roland Mas Why did the tachyon cross the road? Because it was on the other side. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354973: Bug #354973: Needs a rebuild
Hi, I initially encountered the bug too. After rebuilding Gnucash against current libs, it seems to work again. I suspect some library was upgraded and broke things. Roland. -- Roland Mas All tribal myths are true, for a given value of 'true'. -- in The Last Continent (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348286: smilutils: links to libfreetype6, which is going away
Steve Langasek, 2006-01-15 20:20:12 -0800 : > I think this bug can be fixed with re-running libtool, aclocal, and > autoconf, but the build fails with what looks like a bug in ffmpeg: Just for the record: the FTBFS problem has been fixed by the recent 0.3.0-8 upload of smilutils, but even though I did rerun libtool and friends I still get a package depending on libfreetype6. Since I'm not exactly a guru when it comes to libtool black magic, I'll welcome any help on that point. Roland. -- Roland Mas OpenPGP keys on http://www.keyserver.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344032: [344032] bugfix for: bbdb: File error: "Cannot open load file", "bbdb-autoloads"
Erich Waelde (2006-01-06 16:05:53 +0100) : > Hi all, > > 1. The installation of bbdb fails due to a bug in > /usr/share/emacs/site-lisp/bbdb/lisp/Makefile The single quotes make > the ending backslashes show up in the lisp code passed to emacs. Hmm. So it's still a bug in bbdb (or in its packaging, more probably), but it was probably triggered by the recent change in make changing the syntax of makefiles. Roland. -- Roland Mas Bada, bada, ba-da-da-daaa, doudou, doudou, dou-dou-dou-dou-baaa. -- in Song without words #1 (Paul Leavitt) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344032: Same here + workaround
Just wanted to chime in: I have the same problem. I purged emacs-snapshot, but apparently that didn't fix anything. My quick and very dirty workaround: put the following into your .gnus file. (setq load-path (cons (concat "/usr/share/emacs21/site-lisp/bbdb") load-path)) (setq load-path (cons (concat "/usr/share/emacs/site-lisp/bbdb/lisp") load-path)) (provide 'bbdb/load-path) (load-library "bbdb") (provide 'bbdb-autoloads) (load-library "bbdb-com") (load-library "bbdb-gnus") (bbdb-initialize 'gnus 'message) Roland. -- Roland Mas Shyumiribirikku ga susunde imashyou ka ? -- Le Schmilblick en japonais -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
