Bug#1069027: Fixed upstream
This is fixed upstream in Jupyter Notebook 6.5.6 per https://github.com/jupyter/notebook/issues/7054 Best regards Thomas
Bug#1026810: Bring back "lit" tool
(with the bug email included) > I think it still exists, no? > llvm-15-tools: /usr/lib/llvm-15/build/utils/lit/lit.py Ah, yes, I've been searching for "lit" (and so was triton). Thank you. Best regards Thomas
Bug#1026810: Bring back "lit" tool
Package: llvm-toolchain-15 Hi, thank you for packaging LLVM! Back in the day (2016), the LLVM tool LIT (LLVM Integrated Testing) was deemed internal and removed from the binary packages (interestingly, the man-page stayed). It turns out that people/projects use lit, for example OpenAI Triton[1], and currently this does not work with the Debian LLVM. Would it be possible to bring it back? Best regards Thomas 1. https://github.com/openai/triton/
Bug#1022234: Cash in Prusa-Slicer
Hi,
so the crash reported here seems to be due to the font not being
initialized (it is passed as NULL in the traceback).
If we initialize a frame before calling the CalcTextsize, this works -
see the attached.
It still prints errors "could not initialize glew" and the plater tab
does not render, but I guess this is a first step towards something.
Best regards
Thomas--- a/src/slic3r/GUI/HintNotification.cpp
+++ b/src/slic3r/GUI/HintNotification.cpp
@@ -560,7 +560,9 @@
void NotificationManager::HintNotification::count_spaces()
{
- //determine line width
+ ImGuiWrapper& imgui = *wxGetApp().imgui();
+ imgui.new_frame();
+ //determine line width
m_line_height = ImGui::CalcTextSize("A").y;
Bug#1014868: Python 3.10 incompatibility should be severe
severity 1014868 grave thanks Hi, it seems that PyAudio < 0.2.12 is incompatible with Python 3.10 to the point of being not usable. As this is the only version built, the package is currently not working at all. Note that upstream appears to have released 0.2.12 with a fix. Best regards Thomas
Bug#1006226: libthrust: Version conflict with libcub
Package: libthrust Severity: important Hello. Thank you for maintaining thrust along with the cuda stack in Debian! While compiling PyTorch on Debian, I noticed that the version of cub is 0.1.15 and that of thrust is 0.1.14. My impression is that libthrust needs the locked version of libcub, i.e. libthrust 0.1.14 needs libcub=0.1.14, but the dependency currently is >=. I upgraded libthrust to 0.1.15 locally using uupdate and it seemed to work (but I avoided to get into a mismatch with 0.1.16 which is out now and I didn't try updating both to 0.1.16). Best regards Thomas
Bug#1003613: python3-notebook: javascript errors on loading notebooks
Package: python3-notebook Severity: important Version: 6.5.4-3 A recent sid upgrade with the new notebook version appears to have broken it due to javascript incompatibilities. One is in libjs-marked, I filed #1003600 for it. But after fixing that locally, showing directories works, but opening notebooks gets an error Uncaught TypeError: this.pager_element.resizable is not a function Pager pager.js:26 main.js:118 execCb require.js:1696 check require.js:883 enable require.js:1139 bind require.js:134 emit require.js:1189 each require.js:59 emit require.js:1188 check require.js:938 enable require.js:1176 init require.js:788 callGetModule require.js:1203 completeLoad require.js:1590 onScriptLoad require.js:1717 I haven't really found what to do. Apparently some dependency is either missing or has the wrong version, but I don't know which one. Best regards Thomas
Bug#1003601: libjs-marked: loading marked.js from the browser gives "export is not defined"
Package: libjs-marked Version: 4.0.5+ds-5 Severity: important Tags: patch Hi, marked.js currently links to marked.cjs, which seems to cause problems, see https://github.com/markedjs/marked/issues/2284 for the related upstream bug. The fix could be to ship the .umd.js and minified .umd.js, as the patch I'm using locally below shows. Thisis slightly different but should be equivalent to the upstream fix. My interest in this is because Jupyter Notebook (package: python3-notebook) seems to hit an error upon loading. (Sadly, not the only one.) Best regards Thomas diff -Nru node-marked-4.0.5+ds/debian/changelog node-marked-4.0.5+ds/debian/changelog --- node-marked-4.0.5+ds/debian/changelog 2022-01-12 11:37:46.0 +0100 +++ node-marked-4.0.5+ds/debian/changelog 2022-01-09 11:47:31.0 +0100 @@ -1,10 +1,3 @@ -node-marked (4.0.5+ds-5.1) UNRELEASED; urgency=medium - - * Non-maintainer upload. - * Fix browser use - - -- Thomas Viehmann Wed, 12 Jan 2022 11:37:46 +0100 - node-marked (4.0.5+ds-5) unstable; urgency=medium * Team upload diff -Nru node-marked-4.0.5+ds/debian/libjs-marked.install node-marked-4.0.5+ds/debian/libjs-marked.install --- node-marked-4.0.5+ds/debian/libjs-marked.install 2022-01-12 11:37:46.0 +0100 +++ node-marked-4.0.5+ds/debian/libjs-marked.install 2022-01-09 11:23:41.0 +0100 @@ -1,4 +1,2 @@ lib/marked.cjs usr/share/javascript/marked/ -lib/marked.umd.js usr/share/javascript/marked/ -lib/marked.umd.min.js usr/share/javascript/marked/ lib/marked.min.cjs usr/share/javascript/marked/ diff -Nru node-marked-4.0.5+ds/debian/libjs-marked.links node-marked-4.0.5+ds/debian/libjs-marked.links --- node-marked-4.0.5+ds/debian/libjs-marked.links 2022-01-12 11:37:46.0 +0100 +++ node-marked-4.0.5+ds/debian/libjs-marked.links 2022-01-09 11:27:30.0 +0100 @@ -1,2 +1,2 @@ -usr/share/javascript/marked/marked.umd.js usr/share/javascript/marked/marked.js -usr/share/javascript/marked/marked.umd.min.js usr/share/javascript/marked/marked.min.js +usr/share/javascript/marked/marked.cjs usr/share/javascript/marked/marked.js +usr/share/javascript/marked/marked.min.cjs usr/share/javascript/marked/marked.min.js diff -Nru node-marked-4.0.5+ds/debian/rules node-marked-4.0.5+ds/debian/rules --- node-marked-4.0.5+ds/debian/rules 2022-01-12 11:37:46.0 +0100 +++ node-marked-4.0.5+ds/debian/rules 2022-01-09 11:23:41.0 +0100 @@ -10,7 +10,6 @@ override_dh_auto_build: rollup -c rollup.config.js cd lib && terser --comments '/\*[^\0]+?Copyright[^\0]+?\*/' -o marked.min.cjs marked.cjs - cd lib && terser --comments '/\*[^\0]+?Copyright[^\0]+?\*/' -o marked.umd.min.js marked.umd.js override_dh_fixperms: dh_fixperms
Bug#995885: python3-nbconvert: error converting svg to pdf
Package: python3-nbconvert Version: 5.6.1-3 Hello, thank you for maintaining Jupyter. python3-nbconvert uses the now removed base64.encodestring in /usr/lib/python3/dist-packages/nbconvert/preprocessors/svg2pdf.py it as long been deprecated and should be replaced by base64.encodebytes. Best regards Thomas
Bug#995593: HTML sanitizing in 6.4-6.4.3 breaks user styling
Package: jupyter-notebook Version: 6.4.3 Severity: important Tags: fixed-upstream Hello, thank you for maintaining Jupyter Notebook, I am using it every day! With the upgrade to 6.4, the Jupyter Notebook html sanitizing got overly strict and throws out all style formatting[1]. This is quite bad people relying on styles in essential ways lose the ability to render their notebooks (eg many of my notebooks crucially set image widths with the style attribute and are unreadable now). The good news is that upstream has fixed it in 6.4.4. I would much appreciate if I could get the upgrade from Debian. Thank you again for doing the hard work of packaging Jupyter! Best regards Thomas 1: https://github.com/jupyter/notebook/issues/6172
Bug#702948: CUDA Toolkit Samples
I'm not entirely sure if they're the same as the CUDA Toolkit Samples, but if they are, the license situation might have improved: https://github.com/NVIDIA/cuda-samples Best regards Thomas
Bug#986996: More information
...apparently the fix was accidentally not included in the 0.3.14 release, see https://github.com/xianyi/OpenBLAS/issues/2715 for more information. Thank you Thomas
Bug#986996: openblas: SIGILL on arm64 due when HWCAP_CPUID is not set
Package: libopenblas-base Version: 0.3.13+ds-2 Severity: serious Thank you for maintaining openblas. There is a crashing bug (SIGILL) that also affects numpy on arm64. One line of processors affected are NVIDIA Tegra (Jetson devices). It would be great to have this fixed in bullseye. On ARM64, openblas uses feature registers to detect the detailed processor arch. It queries HWCAP_CPUID to check if the feature registers are used. But due to a missing volatile declaration, gcc seems to break this guarding in optimization. A fix is at: https://github.com/xianyi/OpenBLAS/pull/3060 It seems to me that this is not in the 0.3.14 Debian packages even though it seems to be in upstreams 0.3.14, not sure what is up with that. (I could be mistaken.) Best regards Thomas
Bug#972716: mutter spams logs in default config with up to >10k log messages per second
reassign 972716 mutter thank you Dear release team & GNOME maintainers, thank you for making Debian! I wonder if this bug (#972716) might be worth fixing before the release of bulleye. Upstream released a fixed version but a targeted backport would also help. Given that it is quite easy to hit, this will not only render people's GNOME desktop unusable but I would consider it very likely to cause damage, too, either from exhausting storage or damaging the drives. Best regards Thomas
Bug#979040: disfunctional Python package
Hi, the reason that this doesn't work is in debain/patches/support-python-module-in-place.patch: libs = ["-L../obj-%s/src -lsentencepiece -lsentencepiece_train" % arch] this needs to be a list of command line arguments, so libs = ["-L../obj-%s/src" % arch, "-lsentencepiece", "-lsentencepiece_train"] Currently it adds a bogus search path (containing spaces and the remaining "next args" and no libraries). Best regards Thomas
Bug#976379: Bring back /usr/lib/cuda/version.txt
Hi Andreas, thank you for the quick reply. So the documentation say that it still is installed, and given that TVM depends on it to run, I'd think that it still is there at least until v11: https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html#major-component-descriptions (search for version.txt) Best regards Thomas On 04/12/2020 16:26, Andreas Beckmann wrote: Control: tag -1 upstream wontfix On 12/4/20 12:15 PM, Thomas Viehmann wrote: thank you for maintaining the cuda packages! We used to have /usr/lib/cuda/version.txt, but recently it was removed. Would it be possible to bring it back? The background is that some software likes to detect the version by referencing the file (in my case Apache TVM). Thank you for your consideration. That file is no longer shipped by nvidia since they stopped shipping documentation in 11.1. AFAICT it is also neither part of their .deb packages for Ubuntu nor created by the .run installer scripts any more. As I don't want to encourage software development that only works with the Debian packaging of CUDA, but not with upstream's way of software distribution, I'm not bringing version.txt back. Andreas PS: IMO having version.txt was a good thing.
Bug#976379: Bring back /usr/lib/cuda/version.txt
Package: nvidia-cuda-toolkit Hi, thank you for maintaining the cuda packages! We used to have /usr/lib/cuda/version.txt, but recently it was removed. Would it be possible to bring it back? The background is that some software likes to detect the version by referencing the file (in my case Apache TVM). Thank you for your consideration. Best regards Thomas
Bug#972716: gnome-shell bombards the log to, being unresponsive and filling up multi-GBs of disk space
Package: gnome-shell Severity: important Hi, Debian gnome-shell seems to also suffer from https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2467 reverting the commit singled out as the culprit in the bug log seems to fix things for me. I've selected a "Gnome on Xorg" session in GDM rather than using the default, quite possibly, this was necessary to trigger the problem. To give you a taste for the severity, note that the below shows up to 21552 identical error messages being logged in a single second (per the timestamp). I had filled up gigabytes of log in no time at all. Personally, this make things totally unusable for me, but I've not put severity at serious because I forgot the exact definition. Best regards Thomas $ sudo uniq -c /var/log/user.log | sort -n | tail -n 20 12372 Oct 23 00:24:56 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 12372 Oct 23 00:24:57 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 12373 Oct 23 00:25:04 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 12373 Oct 23 00:25:07 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 12375 Oct 23 00:25:20 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 12376 Oct 23 00:25:34 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 12377 Oct 23 00:25:37 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9#012_finish@resource:///org/gnome/shell/ui/altTab.js:275:25#012vfunc_key_release_event@resource:///org/gnome/shell/ui/switcherPopup.js:209:22 12386 Oct 23 00:27:07 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 12388 Oct 23 00:27:24 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 12389 Oct 23 00:27:28 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 12389 Oct 23 00:27:35 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 13961 Oct 23 00:00:11 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 14067 Oct 23 00:09:53 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9#012actionMoveWorkspace@resource:///org/gnome/shell/ui/windowManager.js:2170:23#012_showWorkspaceSwitcher@resource:///org/gnome/shell/ui/windowManager.js:2144:18 14668 Oct 23 00:07:50 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9#012_addWindowClone/<@resource:///org/gnome/shell/ui/workspace.js:1886:23#012_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47#012_onShowChrome@resource:///org/gnome/shell/ui/workspace.js:715:14#012vfunc_enter_event@resource:///org/gnome/shell/ui/workspace.js:380:14 14875 Oct 23 00:00:03 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:121:13#012grabFocus@resource:///org/gnome/shell/ui/messageTray.js:91:26#012_ensureBannerFocused@resource:///org/gnome/shell/ui/messageTray.js:1541:40#012_updateState@resource:///org/gnome/shell/ui/messageTray.js:1326:22#012_onNotificationHoverChanged@resource:///org/gnome/shell/ui/messageTray.js:1210:18 15611 Oct 23 00:05:02 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9#012ungrabFocus@resource:///org/gnome/shell/ui/messageTray.js:121:26#012_hideNotification@resource:///org/gnome/shell/ui/messageTray.js:1470:40#012_updateState@resource:///org/gnome/shell/ui/messageTray.js:1322:22#012_onNotificationDestroy@resource:///org/gnome/shell/ui/messageTray.js:1138:18#012destroy@resource:///org/gnome/shell/ui/messageTray.js:515:14#012addButton/<@resource:///org/gnome/shell/ui/messageTray.js:602:35 18080 Oct 23 00:00:08 aComp gnome-shell[1258192]: JS ERROR: TypeError: null has no properties#012_onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 20316 Oct 23
Bug#971834: symlink Debian-provided nvcc
Package: ccache Severity: wishlist Hi, I know it's in nonfree, but /usr/bin/nvcc would be cool to automatically have symlinks or at least not remove the one I put in /usr/lib/ccache all the time. Thank you. Best regards Thomas
Bug#896684: fontconfig-config errors: Maybe tightening the dependencies is an option?
Hi, So the original report experienced this - like me - with emacs. I could also produce it with just running fc-cache. Damien's hint is spot-on, thank you Damien! I had a 2.13 fontconfig-config but 2.12 (lib)fontconfig: ii fontconfig 2.12.6-0.1 ii fontconfig-config 2.13.0-5 ii libfontconfig1:amd64 2.12.6-0.1 ii libfontconfig1-dev:amd64 2.12.6-0.1 After upgrading everything to 2.13.0-5, the errors are gone. Would it be an option to require the same (upstream?) version in the dependency on fontconfig on fontconfig-config. Clearly fontconfig may break if it get's a too new fontconfig-config. Best regards Thomas
Bug#836821: Patch to enable python 3
tag 836821 + patch
thank you
Hello,
thank you for maintaining protobuf in Debian.
As a token of appreciation, please find attached a patch to add support
for Python 3.
Best regards
Thomas
diff -Nru protobuf-3.0.0/debian/changelog protobuf-3.0.0/debian/changelog
--- protobuf-3.0.0/debian/changelog 2016-09-02 08:57:13.0 +0200
+++ protobuf-3.0.0/debian/changelog 2016-09-11 18:08:39.0 +0200
@@ -1,3 +1,9 @@
+protobuf (3.0.0-7.1) UNRELEASED; urgency=medium
+
+ * Patch to enable python 3. Closes: #836821
+
+ -- Thomas Viehmann <t...@beamnet.de> Sat, 10 Sep 2016 00:00:00 +
+
protobuf (3.0.0-7) unstable; urgency=medium
* Team upload.
diff -Nru protobuf-3.0.0/debian/control protobuf-3.0.0/debian/control
--- protobuf-3.0.0/debian/control 2016-08-26 00:28:51.0 +0200
+++ protobuf-3.0.0/debian/control 2016-09-11 15:38:55.0 +0200
@@ -20,7 +20,10 @@
, dh-python
, python-all (>= 2.7)
, libpython-all-dev (>= 2.7)
+ , python3-all (>= 3.3)
+ , libpython3-all-dev (>= 3.3)
, python-setuptools
+ , python3-setuptools
, python-google-apputils
# Manpage generator
, xmlto
@@ -180,6 +183,27 @@
need the protoc tool (in the protobuf-compiler package) to compile your
definition to Python classes, and then the modules in this package will allow
you to use those classes in your programs.
+
+Package: python3-protobuf
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Description: Python 3 bindings for protocol buffers
+ Protocol buffers are a flexible, efficient, automated mechanism for
+ serializing structured data - similar to XML, but smaller, faster, and
+ simpler. You define how you want your data to be structured once, then you can
+ use special generated source code to easily write and read your structured
+ data to and from a variety of data streams and using a variety of languages.
+ You can even update your data structure without breaking deployed programs
+ that are compiled against the "old" format.
+ .
+ Google uses Protocol Buffers for almost all of its internal RPC protocols and
+ file formats.
+ .
+ This package contains the Python 3 bindings for the protocol buffers. You will
+ need the protoc tool (in the protobuf-compiler package) to compile your
+ definition to Python classes, and then the modules in this package will allow
+ you to use those classes in your programs.
Package: libprotobuf-java
Architecture: all
diff -Nru protobuf-3.0.0/debian/python-protobuf3.README.Debian protobuf-3.0.0/debian/python-protobuf3.README.Debian
--- protobuf-3.0.0/debian/python-protobuf3.README.Debian 1970-01-01 01:00:00.0 +0100
+++ protobuf-3.0.0/debian/python-protobuf3.README.Debian 2016-09-11 15:39:56.0 +0200
@@ -0,0 +1,11 @@
+C++ backend
+===
+
+As of protobuf 2.6.0, a new C++ backend for the Python protobuf bindings is
+available, which is faster than the default pure Python implementation. It can
+be activated by setting the following environment variables:
+
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION_VERSION=2
+
+ -- Robert Edmonds <edmo...@debian.org> Thu, 28 Aug 2014 21:10:30 -0700
diff -Nru protobuf-3.0.0/debian/rules protobuf-3.0.0/debian/rules
--- protobuf-3.0.0/debian/rules 2016-08-25 02:28:25.0 +0200
+++ protobuf-3.0.0/debian/rules 2016-09-11 15:42:48.0 +0200
@@ -1,7 +1,7 @@
#!/usr/bin/make -f
%:
- dh $@ --with autoreconf,python2 --parallel
+ dh $@ --with autoreconf,python2,python3 --parallel
override_dh_auto_build-arch:
## Chicken<->Egg problem: protobuf requires self-generated .pb.go files to
@@ -13,9 +13,10 @@
# Generate the manpage.
xmlto man debian/protoc.xml
-
+ cp python python3 -r
# Python build.
cd python && python setup.py build --cpp_implementation
+ cd python3 && python3 setup.py build --cpp_implementation
override_dh_auto_build-indep:
dh_auto_build --indep
@@ -45,6 +46,9 @@
cd python && for python in $(shell pyversions -r); do \
$$python setup.py test --cpp_implementation; \
done
+ cd python3 && for python in $(shell py3versions -r); do \
+ $$python setup.py test --cpp_implementation; \
+ done
endif
override_dh_auto_test-indep:
@@ -58,6 +62,7 @@
$$python setup.py clean --all; \
done
rm -rf python/protobuf.egg-info
+ rm -rf python3
override_dh_auto_clean-indep:
dh_auto_clean --indep
@@ -76,7 +81,13 @@
--install-layout=deb --no-compile \
--root=$(CURDIR)/debian/python-protobuf; \
done
+ cd python3 && for python in $(shell py3versions -r); do \
+ $$python setup.py install --cpp_implementation \
+ --install-layout=deb --no-compile \
+ --root=$(CURDIR)/debian/python3-protobuf; \
+ done
find $(CURDIR)/debian/python-protobuf -name 'protobuf-*-nspkg.pth' -delete
+ find $(CURDIR)/debian/python3-protobuf -name 'protobuf-*-nspkg.pth' -delete
override_dh_auto_install-indep:
dh_auto_install --indep
Bug#833828: Migrations of stable's python3-django-markupfield (1.2.1) do not work with stable's django version (1.7.x).
Package: python3-django-markupfield Severity: serious Version: 1.2.1-2+deb8u1 Hello, database migrations generated when using markupfields with python3-django-markupfield 1.2.1 do not work with stable's django version 1.7.x. https://github.com/jamesturk/django-markupfield/issues/20 This makes python3-django-markupfield fairly useless on stable. What I did was port django-markupfield jessie's 1.4 to the backports django version (a mere recompile will do). Of course, that leaves the broken package in stable. Best regards Thomas
Bug#760385: Fix for CVE-2014-5256
Hi Jean Baptiste, thank you for looking into this. Note that the changelog entries for nodejs 0.10.31 and .32 include v8: backport CVE-2013-6668 v8: fix a crash introduced by previous release If libv8 in Debian is affected by those, you might also consider also backporting those fixes when preparing a new v8 package. (Elsewhere in NodeJS .33 there is crypto: Disable autonegotiation for SSLv2/3 by default, not sure whether the release team would let something like that through.) Best regards Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741834: patch to add LC_ALL=C
tag 741834 +patch thank you Hi, this is a tiny patch to address the test failures. Thank you Thomas diff -Nru python-babel-1.3+dfsg.1/debian/changelog python-babel-1.3+dfsg.1/debian/changelog --- python-babel-1.3+dfsg.1/debian/changelog 2014-06-24 09:06:24.0 +0200 +++ python-babel-1.3+dfsg.1/debian/changelog 2014-11-10 22:18:40.0 +0100 @@ -1,3 +1,10 @@ +python-babel (1.3+dfsg.1-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * Call test suite with LC_ALL=C to avoid test failures. Closes: #741834 + + -- Thomas Viehmann t...@beamnet.de Mon, 11 Nov 2014 11:11:11 +0100 + python-babel (1.3+dfsg.1-4) unstable; urgency=medium * Fixed removal of pyshared folder stuff (that directory doesn't exist diff -Nru python-babel-1.3+dfsg.1/debian/rules python-babel-1.3+dfsg.1/debian/rules --- python-babel-1.3+dfsg.1/debian/rules 2014-06-24 09:06:24.0 +0200 +++ python-babel-1.3+dfsg.1/debian/rules 2014-11-10 22:41:56.0 +0100 @@ -72,6 +72,6 @@ override_dh_auto_test: ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS))) - py.test - py.test-3 + LC_ALL=C py.test + LC_ALL=C py.test-3 endif
Bug#699325: Fixed in 24.4 (in unstable + testing)
Hi, from the upstream log and the comments it looks like the most recent upload to unstable and migration to testing should have fixed this. Vincent, are you having this with the 24.4 version? Best regards Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624589: clang support for ccache
Hi, thank you for maintaining ccache. The libreoffice page on building with clang[1] has the recommendation to apply at least the patch[2] to ccache 3.1.9 to support building with clang+ccache. Given that the patch is already upstream, would it be possible to include it in the Debian package? Thank you for your consideration Thomas [1] https://wiki.documentfoundation.org/Development/Building_LibreOffice_with_Clang [2] https://git.samba.org/?p=ccache.git;a=commitdiff;h=8e005b067d8c2423e24ee14ffdee8343f650f1e8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582148: build-deps
tag 582148 +patch thanks evolution-data-server-1.2.pc wants libnspr4-dev libnss3-dev to work. Kind regards T. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527792: apertium-en-es: diff for NMU version 0.6.0-1.1
Hey Francis, first off, thanks for the quick reply! Francis Tyers wrote: They shouldn't be arch specific, although some of them may be PCRE version specific. I'm not sure why we decided to install them in /usr/share, but probably because there was no better place. Could you give more details of which ones appear to differ between arches and which arches ? /usr/share is perfectly fine *if* the files are arch-independent. Then you should make the package declare Architecture: all (instead of any), though. What I did was download the .deb for various architectures (linked from packages.debian.org or on your favorite ftp mirror), extracted them with dpkg -x foo.deb /tmp/targetdir and ran diff or diff on the output of hexdump -c of several of them. I also tried copying the files from other architectures to into place on my system and it seemed to work. As such, my conclusion is tentitative as it is only based on experiments and not on analysis of the format. If someone with more knowledge about apertium and how these files work tells you that they are independent of e.g. endianness of integers and such, I think it is fully believable. I just try not to break your packages while meddling with them, when you do it yourself, it's a whole different story. :) By the way: What are your plans w.r.t. for fixing the build-dependencies? RC bugs should be closed within two weeks in all but the most exceptional circumstances (Developer's Reference is very precise about that), so I was a bit surprised that these were sitting there... If you have fixes and your sponsor is busy, I can try to see if we can find someone to help out if you send and URL with updated packages. As a final remark, I wonder whether the XML format is stable enough to rename the development package to not include the version number with the rationale that it'll break less often than now. Also, while it is recommendable to build packages using pbuilder or cowbuilder, it is also a useful exercise to try to run dpkg-buildpackage in a several times in a row in a directory to see if there are additional files showing up in diff.gz (that would indicate that you need to do better cleanup, just as I did). This is mostly a comfort issue when someone unfamiliar with your package (i.e. me) looks at it... OK, so this was very straightforward down-to-business talk and recommendations. Your contribution to Debian is very much appreciated! Please do not hesitate to ask if you have any questions on the above and tell me about your plans! Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539338: mkfontscale: add option to recurse subdirectories
Hi,
thanks, Julien, for the comments, and sorry about the half-baked patch...
Julien Cristau wrote:
+(stat(filename, statbuf) == 0) S_ISDIR(statbuf.st_mode)) {
this can lead to an infinite loop since you follow symlinks. Juliusz
suggested limiting the recursion to something like 100.
Indeed. There would be an implicit upper bound of 2048 by the dsprintf
implementation, but that's one more reason to check the return value and
probably not good to rely on.
Please find attached a revised patch. The fixes to the manpage are
mainly for reminding myself and I can split out the unrelated parts for
cleaner commits.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
diff -Nru xfonts-utils-7.4+1/mkfontscale/mkfontscale.c xfonts-utils-7.4+1/mkfontscale/mkfontscale.c
--- xfonts-utils-7.4+1/mkfontscale/mkfontscale.c 2008-05-11 00:01:42.0 +0200
+++ xfonts-utils-7.4+1/mkfontscale/mkfontscale.c 2009-08-01 23:34:02.0 +0200
@@ -31,6 +31,7 @@
#include unistd.h
#include errno.h
#include ctype.h
+#include sys/stat.h
#include X11/Xos.h
#include X11/fonts/fontenc.h
@@ -63,6 +64,8 @@
#define MAXFONTNAMELEN 1024
#endif
+#define MAXDEPTHINRECURSIVESCAN 100
+
char *encodings_array[] =
{ ascii-0,
iso8859-1, iso8859-2, iso8859-3, iso8859-4, iso8859-5,
@@ -103,6 +106,7 @@
static FT_Library ft_library;
static float bigEncodingFuzz = 0.02;
+static int recurse;
static int relative;
static int doScalable;
static int doBitmaps;
@@ -118,8 +122,8 @@
{
fprintf(stderr,
mkfontscale [ -b ] [ -s ] [ -o filename ] [-x suffix ]\n
-[ -a encoding ] [ -f fuzz ] [ -l ]
-[ -e directory ] [ -p prefix ] [ -n ] [ -r ] \n
+[ -a encoding ] [ -f fuzz ] [ -l ]\n
+[ -e directory ] [ -p prefix ] [ -n ] [ -r ] [ -R ] \n
[-u] [-U] [ directory ]...\n);
}
@@ -154,6 +158,7 @@
doScalable = 1;
onlyEncodings = 0;
relative = 0;
+recurse = 0;
reencodeLegacy = 1;
encodingsToDo = NULL;
@@ -217,6 +222,9 @@
} else if(strcmp(argv[argn], -r) == 0) {
relative = 1;
argn++;
+} else if(strcmp(argv[argn], -R) == 0) {
+recurse = 1;
+argn++;
} else if(strcmp(argv[argn], -l) == 0) {
reencodeLegacy = !reencodeLegacy;
argn++;
@@ -749,57 +757,20 @@
return 0;
}
+
static int
-doDirectory(char *dirname_given, int numEncodings, ListPtr encodingsToDo)
+scanDirectory(char *dirname, char *dir_prefix, int xl, HashTablePtr entries, int depthtogo)
{
-char *dirname, *fontscale_name, *filename, *encdir;
-FILE *fontscale, *encfile;
DIR *dirp;
struct dirent *entry;
+struct stat statbuf;
+ListPtr encoding, xlfd, lp;
+char* filename;
+char* prefixedname;
+int rc, found;
+int isBitmap=0;
FT_Error ftrc;
FT_Face face;
-ListPtr encoding, xlfd, lp;
-HashTablePtr entries;
-HashBucketPtr *array;
-int i, n, found, rc;
-int isBitmap=0,xl=0;
-
-if (exclusionSuffix)
-xl = strlen (exclusionSuffix);
-
-i = strlen(dirname_given);
-if(i == 0)
-dirname = dsprintf(./);
-else if(dirname_given[i - 1] != '/')
-dirname = dsprintf(%s/, dirname_given);
-else
-dirname = dsprintf(%s, dirname_given);
-
-if(dirname == NULL) {
-perror(dirname);
-exit(1);
-}
-
-if (onlyEncodings)
- goto encodings;
-
-entries = makeHashTable();
-if(doBitmaps !doScalable) {
-readFontScale(entries, dirname);
-}
-
-if(strcmp(outfilename, -) == 0)
-fontscale_name = NULL;
-else {
-if(outfilename[0] == '/')
-fontscale_name = dsprintf(%s, outfilename);
-else
-fontscale_name = dsprintf(%s%s, dirname, outfilename);
-if(fontscale_name == NULL) {
-perror(fontscale_name);
-exit(1);
-}
-}
dirp = opendir(dirname);
if(dirp == NULL) {
@@ -808,17 +779,6 @@
return 0;
}
-if(fontscale_name == NULL)
-fontscale = stdout;
-else
-fontscale = fopen(fontscale_name, wb);
-
-if(fontscale == NULL) {
-fprintf(stderr, %s: , fontscale_name);
-perror(fopen(w));
-return 0;
-}
-
while((entry = readdir(dirp)) != NULL) {
int have_face = 0;
char *xlfd_name = NULL;
@@ -831,7 +791,33 @@
}
filename = dsprintf(%s%s, dirname, entry-d_name);
-
+if (recurse depthtogo0 strcmp(entry-d_name, .) != 0
+ strcmp(entry-d_name, ..) != 0
+ stat(filename, statbuf) == 0 S_ISDIR(statbuf.st_mode)) {
+ char* prefix;
+ int retval;
+ free(filename);
+ filename = dsprintf(%s%s/, dirname, entry-d_name);
+ prefix = dsprintf(%s%s/, dir_prefix, entry-d_name);
+ if (filename == NULL || prefix == NULL
Bug#266003: status?
Brian May wrote: I am very short of time lately. The little time I have had has been on other more urgent tasks. First I need to test the latest version of Heimdal, and ensure it still has the problem. There have been a number of new upstream releases since the initial report, and somewhere I think I saw a hint that the problem may have been solved. Any changes would need to be coordinated with Sam Hartman, who was working on a patch to make it possible to install both Heimdal and MIT kerberos development packages at the same time, so I have CCed him. Brian, I appreciate that you are busy, but we are both talking about adding the single line sed -i /dependency_libs/ s/'.*'/''/ debian/heimdal-dev/usr/lib/*.la to the binary-post-install/heimdal-dev:: target in debian/rules? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ --- x/heimdal-1.2.e1.dfsg.1/debian/rules 2009-07-31 10:41:06.0 +0200 +++ heimdal-1.2.e1.dfsg.1/debian/rules 2009-07-31 10:23:19.0 +0200 @@ -68,7 +68,8 @@ rm -f debian/heimdal-dev/usr/lib/libss.a rm -f debian/heimdal-dev/usr/lib/libss.la rm -f debian/heimdal-dev/usr/lib/libss.so - + # remove libtool recursive linking mess + sed -i /dependency_libs/ s/'.*'/''/ debian/heimdal-dev/usr/lib/*.la binary-post-install/heimdal-servers:: mv debian/heimdal-servers/usr/sbin/kfd debian/heimdal-servers/usr/lib/heimdal-servers
Bug#528938: possible solutions
Hi Julien, two quick comments - is the security team aware that you are waiting on input? - if you want to compute a session ID in python, the easy way is to use ajaxterm.html only as a template, make sure it is not cached and pass the (computed and put in the template) session id in the instantiation there. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528938: one more thing
...as the session id is obviously not persistent, it is not strictly necessary to wait for upstream to come up with a solution. If you include a debian-specific patch and upstream doesn't like it, you can always use the upstream fix in the next version because you don't have to worry about compatibility between client and server. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539280: RM: workman -- RoQA: orphaned, RC buggy, low popcon (likely better alternatives)
Package: ftp.debian.org Hi, I would like to suggest to remove workman. It's orphaned, RC buggy, has a popcon of 65 (rapidly decreasing), with only 15 votes. It would appear that Debian has many CD players, apparently people prefer the alternatives. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#266003: status?
Hi Brian, it would seem that after Joss's and Steve's explanations the issue is clear and Joss also provided a code example. Yet the bug is still unfixed. Is there a reason to further postpone closing this any further? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539338: mkfontscale: add option to recurse subdirectories
X-Debbugs-CC: Juliusz Chroboczek juliusz.chroboc...@pps.jussieu.fr
Package: xfonts-utils
Version: 1:7.4+1
Severity: wishlist
Hi Juliusz, everyone,
in the medium run it might be nice to use /usr/share/fonts/truetype in
the X font path. However, fonts seem to be organized into subdirectories.
To facilitate using the directory with adding only one element to the X
font path, the attached patch implements recursive scanning of
subdirectories in mkfontscale.
I appreciate feedback and if you could consider adopting it.
Acknowledgement: Julien Cristau answered questions on IRC, so if I have
gotten anything right here, it's to his credit, all errors are my own.
Kind regards and thanks for your work on Debian and X
T.
P.S.: If this patch seems feasible (even if only in Debian), I would
submit a follow-up to add a packaging system trigger to keep font
information up to date in that directory.
--
Thomas Viehmann, http://thomas.viehmann.net/
diff -dur orig/xfonts-utils-7.4+1/mkfontscale/mkfontscale.c xfonts-utils-7.4+1/mkfontscale/mkfontscale.c
--- orig/xfonts-utils-7.4+1/mkfontscale/mkfontscale.c 2008-05-11 00:01:42.0 +0200
+++ xfonts-utils-7.4+1/mkfontscale/mkfontscale.c 2009-07-30 20:49:23.0 +0200
@@ -31,6 +31,7 @@
#include unistd.h
#include errno.h
#include ctype.h
+#include sys/stat.h
#include X11/Xos.h
#include X11/fonts/fontenc.h
@@ -103,6 +104,7 @@
static FT_Library ft_library;
static float bigEncodingFuzz = 0.02;
+static int recurse;
static int relative;
static int doScalable;
static int doBitmaps;
@@ -154,6 +156,7 @@
doScalable = 1;
onlyEncodings = 0;
relative = 0;
+recurse = 0;
reencodeLegacy = 1;
encodingsToDo = NULL;
@@ -217,6 +220,9 @@
} else if(strcmp(argv[argn], -r) == 0) {
relative = 1;
argn++;
+} else if(strcmp(argv[argn], -R) == 0) {
+recurse = 1;
+argn++;
} else if(strcmp(argv[argn], -l) == 0) {
reencodeLegacy = !reencodeLegacy;
argn++;
@@ -749,57 +755,20 @@
return 0;
}
+
static int
-doDirectory(char *dirname_given, int numEncodings, ListPtr encodingsToDo)
+scanDirectory(char *dirname, char *dir_prefix, int xl, HashTablePtr entries)
{
-char *dirname, *fontscale_name, *filename, *encdir;
-FILE *fontscale, *encfile;
DIR *dirp;
struct dirent *entry;
+struct stat statbuf;
+ListPtr encoding, xlfd, lp;
+char* filename;
+char* prefixedname;
+int rc, found;
+int isBitmap=0;
FT_Error ftrc;
FT_Face face;
-ListPtr encoding, xlfd, lp;
-HashTablePtr entries;
-HashBucketPtr *array;
-int i, n, found, rc;
-int isBitmap=0,xl=0;
-
-if (exclusionSuffix)
-xl = strlen (exclusionSuffix);
-
-i = strlen(dirname_given);
-if(i == 0)
-dirname = dsprintf(./);
-else if(dirname_given[i - 1] != '/')
-dirname = dsprintf(%s/, dirname_given);
-else
-dirname = dsprintf(%s, dirname_given);
-
-if(dirname == NULL) {
-perror(dirname);
-exit(1);
-}
-
-if (onlyEncodings)
- goto encodings;
-
-entries = makeHashTable();
-if(doBitmaps !doScalable) {
-readFontScale(entries, dirname);
-}
-
-if(strcmp(outfilename, -) == 0)
-fontscale_name = NULL;
-else {
-if(outfilename[0] == '/')
-fontscale_name = dsprintf(%s, outfilename);
-else
-fontscale_name = dsprintf(%s%s, dirname, outfilename);
-if(fontscale_name == NULL) {
-perror(fontscale_name);
-exit(1);
-}
-}
dirp = opendir(dirname);
if(dirp == NULL) {
@@ -808,17 +777,6 @@
return 0;
}
-if(fontscale_name == NULL)
-fontscale = stdout;
-else
-fontscale = fopen(fontscale_name, wb);
-
-if(fontscale == NULL) {
-fprintf(stderr, %s: , fontscale_name);
-perror(fopen(w));
-return 0;
-}
-
while((entry = readdir(dirp)) != NULL) {
int have_face = 0;
char *xlfd_name = NULL;
@@ -831,7 +789,24 @@
}
filename = dsprintf(%s%s, dirname, entry-d_name);
+if (recurse (strcmp(entry-d_name, .) != 0) (strcmp(entry-d_name, ..) != 0)
+ (stat(filename, statbuf) == 0) S_ISDIR(statbuf.st_mode)) {
+ char* prefix;
+ int retval;
+ free(filename);
+ filename = dsprintf(%s%s/, dirname, entry-d_name);
+ prefix = dsprintf(%s%s/, dir_prefix, entry-d_name);
+ retval = scanDirectory(filename, prefix, xl, entries);
+ free(filename);
+ free(prefix);
+ if (retval == 0) {
+ closedir(dirp);
+ return 0;
+ }
+ continue;
+ }
+prefixedname = dsprintf(%s%s, dir_prefix, entry-d_name);
if(doBitmaps)
rc = bitmapIdentify(filename, xlfd_name);
else
@@ -892,7 +867,7 @@
xlfd = listCons(s, xlfd);
} else
Bug#418642: smart bug #418642
Hi Free, you were working on smart the other day, so I wondered whether you'd have time to look into (and either close or fix) #418642, a fairly old RC bug that smart has. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539344: RM: pcsx-df -- RoQA: licence-violation, orphaned
Package: ftp.debian.org Hi, According to #514446 pcsx-df has a license problem. As it is orphaned an nobody seems to be working on seeing it resolved, maybe removing the package is the best option. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537631: Mail address?
Hi Dale, is something up with your maintainer address in the spider package? Please update a new version, if only to change the address, and close #537631 (or just close it, if your address works again). Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539060: RM: delo -- RoQA: RC buggy, obsolete
Hi, Florian Lohoff wrote: As the original Author i might be biased though ... Oh, thanks! So let me revise the request: delo seems to be well obsolete[1]. For reference, the last message from the maintainer seems to be [2]. Even the original author did not fix the RC bug open for months even though could have well known about the breakage and the package is dearly attached to his heart. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533652: electricsheep adoption
Hi Roberto, according to your d-de...@l.d.o, you are adopting electricsheep. As such, you inherit RC bug #533652, and here is a friendly prod if you could update the bug with your plans. If you need longer for an upload, maybe filing an ITA bug for the package would help to clarify the situation. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504283: egroupware adoption or removal?
Hi everyone (formerly) interested in egroupware, egroupware seems to be in need for attention #526878 [egroupware-wiki] egroupware-core sets open_basedir which disables hook_config_validate.inc.php (egroupware-wiki) sanity check Date: Mon, 4 May 2009 08:15:01 UTC #504283 CVE-2007-3215: phpmailer issue (embedded code-copy) Date: Sun, 2 Nov 2008 12:33:01 UTC It would seem that egroupware should either be adopted and fixed for squeeze or removed. Shipping it as an orphaned package sounds like a bad idea. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525826: flac maintenance RC bug
Hi Andres, given that Josh did not answer your mail[1] to #525826 about helping with flac and seems to be not too active (public lists seem to have last no posts later than August 2008) at the moment, I would suggest that the multimedia maintainers take over flac unless Josh objects in the next two weeks. I would suggest temporarily dropping Josh from the uploaders and adding him back when he returns to a more active role in maintaining flac in order to not split the maintainer housekeeping in too many steps if he has lost interest. Kind regards T. 1. http://bugs.debian.org/525826#17 -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#471801: egroupware adoption or removal?
On 2009-07-29 10:39:48.00 Martin Meredith m...@ubuntu.com wrote: I've suggested that I adopt this, however, the current maintainer seems to want to stay as maintainer, and just do everything through accessible by anyone svn. I'm not too sure exactly what he wants to do with this. Well, it is orphaned (if only for a few days). Kind regards T. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539145: RM: xpumon -- RoQA: RC-buggy, obsolete
X-Debbugs-CC: b...@debian.org Package: ftp.debian.org Hi, xpumon has an unanswered RC bug open since May 1st. Its description contains Requires a 2.4 kernel with the /proc/pmu interface. and the popcon is 3. Kind regards T. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539060: RM: delo -- RoQA: RC buggy, obsolete
Package: ftp.debian.org X-Debbugs-CC: debian-m...@lists.debian.org, mer...@debian.org Hi, delo seems to be well obsolete[1]. For reference, the last message from the maintainer seems to be [2]. Maintainer and mips list CCed just in case. Kind regards T. 1. http://lists.debian.org/debian-boot/2009/06/msg00051.html http://lists.debian.org/debian-release/2008/06/msg00362.html 2. http://lists.debian.org/debian-mips/2008/10/msg00027.html -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487638: opencv: diff for NMU version 1.0.0-6.2
Hi, Raphael Geissert wrote: I tried to build the package but failed because of some changes that could not be applied, could you please send me the the compressed diff to avoid any kind of spacing destruction? Oh. I thought I had tested it. Maybe if you cut the debian/changelog part? Unfortunately, my mail did not make the bug reports and as I work in /tmp to develop patches I do not have a copy any more, sorry. By the way, I took a look at upstream's vcs, and it looks like they've finally fixed it: http://opencvlibrary.svn.sourceforge.net/viewvc/opencvlibrary/trunk/opencv/src/highgui/ Yeah, but unless they backported the fix, it seems that opencv changed quite a bit (between 1.0 and current trunk). Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535855: matplotlib._path
Hi Fabrice,
thanks for sending the additional info.
In Fabrice's sys.path output:
...
/usr/share/pyshared
^^^
...
This seems to be the problem. While the matplotlib/__init__.py lives in
that dir, it should be loaded via the symlink in
/usr/lib/pymodules/python2.5. Then it finds the _path module in the
neighboring symlink.
Could you manually remove it and try again?
import sys
sys.path.remove('/usr/share/pyshared')
import matplotlib.transforms
should do the trick.
If that works, one would need to figure out where the pyshared entry in
sys.path comes from.
Kind regards
T.
For reference: My sys.path is
/usr/lib/python2.5
/usr/lib/python2.5/plat-linux2
/usr/lib/python2.5/lib-tk
/usr/lib/python2.5/lib-dynload
/usr/local/lib/python2.5/site-packages
/usr/lib/python2.5/site-packages
/usr/lib/python2.5/site-packages/Numeric
/usr/lib/python2.5/site-packages/PIL
/usr/lib/pymodules/python2.5
/usr/lib/pymodules/python2.5/gtk-2.0
/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535855: matplotlib._path
Fabrice Silva wrote: I will try tonight at home. Which are the mechanism that add items to sys.path ? sys.path is a regular python list, so sys.path.append(/foo) adds to the end, sys.path.insert(i, /foo) adds /foo in i-th position (put in your favorite integer). Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487638: opencv patch for libavcodec/ffmpeg api
Hi Gijs and Nicolau, (And hi Raphael, you are the last NMUer. Maybe you are interested in uploading a fixed package with a revised version of Gijs patch, if not, maybe Paul or Ondrej want to.) first, and most importantly, thanks for looking into fixing this problem and sharing your patch with Debian. Just a quick technical comment: The use of a static variable for the scaling context seems bogus. Similarly, allocating a context in icvRetreiveFrame seems too often. Also, not releasing it looks wrong. What should be done instead is amend the (internal) struct CvCaptureAVI_FFMPEG with the SwsContext (I'd name the struct member sws_context rather than img_conver_context, too, but that could be me), AFAICT this should not change the exported ABI. Then initialize the context in icvOpenAVI_FFMPEG and give it back in icvCloseAVI_FFMPEG. This is, of course, along the lines of don't use static vars where you should not. I have not reviewed any other aspect of the patch. Again, thanks for looking into fixing this bug. Let me know if I can be of further assistance. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535855: matplotlib._path
Hi Fabrice, Sandro, Sandro asked for debugging ideas, so here is mine: Fabrice, could you please see what sys.path is when the loading fails and also try to load the module with python -v -v -c 'import matplotlib.transform' 2 /tmp/import_log.txt ? Maybe that turns up something. Thanks! Kind regards T. P.S.: I think that technically 'grave' implicitly includes 'useless for everyone', so this should be 'important', but seeing this resolved is more interesting than setting the severity. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534242: ITP: antihex -- Converts hex to decimal
Hi,
Harry Rickards wrote:
Section : math
AntiHex is a pipe to convert hex values into decimal. Ex: # cat
/proc/iomem -0009fbff : System RAM 0009fc00-0009 : reserved
# cat /proc/iomem | ah -639K-1 : System RAM 639K -640K-1 :
reserved ...
I'm not sure the equivalent of
python -c 'import re,sys ; exec(for l in sys.stdin: \
sys.stdout.write(re.sub(r(?![0-9A-Fa-f])[0-9A-Fa-f]{3,8}(?![0-9A-Fa-f]),\
lambda x: ((lambda y: (y2**30 and (%.2f%(y/2.0**30))+G) or \
(y2**20 and (%.2f%(y/2.0**20))+M) or (y2**10 and \
(%.2f%(y/2.0**10))+K) or str(y))(int(x.group(),16))),l)))'
qualifies as math. And yes, I know that ah is much superior because it
has the -1 business.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534242: ITP: antihex -- Converts hex to decimal
On 2009-06-23 12:24:09.00 Harry Rickards hricka...@l33tmyst.com wrote: It's not actually my program, it's just a useful tool I found on Sourceforge. What would you suggest packaging it as? utils? spam would be the perfect section. And it is not a useful tool. It is package spam flooding the Debian archive, drowning whatever could have made a useful operating system. Given that a section spam does not exist, utils might be a good choice. Kind regards T. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526527: status?
Hi Adam, say, what is the state of this bug. Now that suitesparse is fixed, I would love to see this fixed as well. If you do not have the time at the moment, I am happy to help out with an NMU. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526527: status?
[sent to the bug report]
Hi,
Adam C Powell IV wrote:
Oh yeah, I've been neglecting this, haven't I... Can't take care of it
before the end of the week, so feel free to NMU.
it's easy to file the bugs initially (mistitled) NMU diff for ...
under no attention needed :).
For the record I'm attaching the NMU diff verbatim from the original
report but with the bug number added.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
diff -u pysparse-1.0.1/Src/superlumodule.c pysparse-1.0.1/Src/superlumodule.c
--- pysparse-1.0.1/Src/superlumodule.c
+++ pysparse-1.0.1/Src/superlumodule.c
@@ -89,8 +89,9 @@
dCreate_Dense_Matrix(B, self-n, 1, (double *)x-data, self-n, SLU_DN, SLU_D, SLU_GE);
#endif
+StatInit(dummy);
/* Solve the system, overwriting vector x. */
- dgstrs(trans, self-L, self-U, self-perm_r, self-perm_c, B, dummy, info);
+ dgstrs(trans, self-L, self-U, self-perm_c, self-perm_r, B, dummy, info);
/* free memory */
Destroy_SuperMatrix_Store(B);
@@ -197,20 +198,17 @@
SuperMatrix A; /* A in NC format used by the factorization routine. */
SuperMatrix AC; /* Matrix postmultiplied by Pc */
mem_usage_t mem_usage;
- int lwork = 0;
int *etree;
int info;
- optionst.Trans = NOTRANS;
- optionst.DiagPivotThresh = diag_pivot_thresh;
- statt.panel_histo = panel_size;
- statt.RefineSteps = relax;
+ set_default_options(optionst);
+ /* the below comment is interesting because statt is a local variable. eh?
/* make sure StatInit is only called once */
- if (!StatInit_done) {
+ //if (!StatInit_done) {
StatInit(statt);
-StatInit_done = 1;
- }
+ // StatInit_done = 1;
+ //}
/* Create SuperLUObject */
self = PyObject_New(SuperLUObject, SuperLUType);
@@ -231,16 +229,17 @@
etree = intMalloc(n);
self-perm_r = intMalloc(n);
self-perm_c = intMalloc(n);
- if (self-perm_r == NULL || self-perm_c == NULL) {
+ if (self-perm_r == NULL || self-perm_c == NULL || etree == NULL) {
PyErr_NoMemory();
goto fail;
}
get_perm_c(permc_spec, A, self-perm_c); /* calc column permutation */
sp_preorder(optionst, A, self-perm_c, etree, AC); /* apply column permutation */
-
+ panel_size = sp_ienv(1);
+ relax = sp_ienv(2);
/* Perform factorization */
dgstrf(optionst, AC, drop_tol, relax, panel_size,
- etree, NULL, lwork, self-perm_r, self-perm_c,
+ etree, NULL, 0, self-perm_c,self-perm_r,
self-L, self-U, statt, info);
/* free memory */
@@ -263,8 +262,8 @@
return (PyObject *)self;
fail:
- PyMem_Del(self-perm_r);
- PyMem_Del(self-perm_c);
+ SUPERLU_FREE(self-perm_r);
+ SUPERLU_FREE(self-perm_c);
PyObject_Del(self);
return NULL;
}
diff -u pysparse-1.0.1/debian/changelog pysparse-1.0.1/debian/changelog
--- pysparse-1.0.1/debian/changelog
+++ pysparse-1.0.1/debian/changelog
@@ -1,3 +1,11 @@
+pysparse (1.0.1-5.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix pysparse.superlu module port to superlu 3 based on reading
+the docs. Closes: #526527
+
+ -- Thomas Viehmann t...@beamnet.de Fri, 01 May 2009 20:56:39 +0200
+
pysparse (1.0.1-5) unstable; urgency=low
* Removed removal of /usr/lib and Build-Depends on python-central = 0.6
Bug#524588: Temporary removal of pythonmagick from testing?
tag 524588 + patch thanks Hi, Luk Claes wrote: So I wanted to request if removing it from testing for now would be an option? in case anyone is curious about what is required to build, I have attached a diff.gz that fixes the problems under discussion here. I cannot help but note that the overall quality of the module is fairly poor: #495025 raises some doubts, in particular since the classes are not self-contained. It is surprising that a python module segfaulting when not enough parameters are passed to methods is considered to be of adaequate quality for testing or stable when well-established alternatives like PIL exist. The way the python boost detection failure was handled upstream or the arbitrary increasing of the minimal python version is also not exactly confidence-inspiring. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ pythonmagick_0.9.1-0.1.diff.gz Description: application/gzip
Bug#503879: ITP: python-zanshin -- Python module to access CalDAV servers
Hi Jeremy, thanks for the swift reply. Jeremy Lainé wrote: Do you still have plans to submit python-zanshin to Debian? AFAICT, the main problem was the licensing info for davlib.py. I have actually pretty much given up on packaging python-zanshin, after playing around with it a bit more I have found it to be less useful / usable than I'd like it to be. If you want to pick up the packaging please feel free to do so, otherwise I think I'll retract my ITP. Well, I am not sure that I actually plan to maintain this package in current Debian, sorry. Maybe it's best to retitle to RFP then. It would be extra-cool if you could CC -devel with the RFP. Do you have a good alternative? I use it for CalDAV in a python-twisted-based webmail[1], so the twisted integration is a selling point, but if there is something better, I am all for introducing only the best possible software to Debian. Kind regards T. 1. http://beammail.org/ -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503879: ITP: python-zanshin -- Python module to access CalDAV servers
Hi Jeremy, how are you? Do you still have plans to submit python-zanshin to Debian? AFAICT, the main problem was the licensing info for davlib.py. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531960: segfault on exit
Package: python-clutter Version: 0.8.0-1 Severity: serious Hi Ross, thanks for maintaining pyclutter in Debian. The command python -c import clutter leads to a segfault on my up to date sid/amd64 installation. This seems to happen at exit time, but should not. Unfortunately, running the debug version seems to fail elsewhere, so no backtrace. I did try importing some of the dependencies (see the other bug), but they don't give segfaults. Kind regards T. Versions of packages python-clutter depends on: ii libc6 2.9-13 ii libcairo2 1.8.6-2+b1 ii libclutter-0.8-00.8.4-1 ii libclutter-cairo-0.8-0 0.8.2-1 ii libclutter-gst-0.8-00.8.0-1 ii libglib2.0-02.20.3-1 ii libgstreamer0.10-0 0.10.23-1 ii libgtk2.0-0 2.16.2-1 ii libpango1.0-0 1.24.2-1 ii libxml2 2.7.3.dfsg-1 ii python 2.5.4-2 ii python-support 1.0.3 -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531961: missing dependency declaration
Package: python-clutter Version: 0.8.0-1 Severity: serious Hi Ross, while verifying the segfault reported in the other bug, I noticed that after installing python-clutter, I needed to manually install python-gobject python-cairo python-gtk2 to be able to import clutter. It appears that the Depends: is not quite complete (though it would seem like python-gtk2 already depends on the other two). Kind regards T. Versions of packages python-clutter depends on: ii libc6 2.9-13 ii libcairo2 1.8.6-2+b1 ii libclutter-0.8-00.8.4-1 ii libclutter-cairo-0.8-0 0.8.2-1 ii libclutter-gst-0.8-00.8.0-1 ii libglib2.0-02.20.3-1 ii libgstreamer0.10-0 0.10.23-1 ii libgtk2.0-0 2.16.2-1 ii libpango1.0-0 1.24.2-1 ii libxml2 2.7.3.dfsg-1 ii python 2.5.4-2 ii python-support 1.0.3 -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524452: Bug#523596: problem of 523596 is in graphicsmagick
tag 524452 + patch thanks Thanks Daniel for the update. Unfortunately, psiconv still fails to build with this version because it apparently makes use of a prehistoric and long deprecated API function. It doesn't really make sense to schedule another bin-NMU until this is problem fixed with a psiconv upload. Then lets move the conversation to #524452. Tested with the Clipart file in tarball's examples directory. I will not comment on the nature of that file, though. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ diff -u psiconv-0.9.8/debian/changelog psiconv-0.9.8/debian/changelog --- psiconv-0.9.8/debian/changelog +++ psiconv-0.9.8/debian/changelog @@ -1,3 +1,11 @@ +psiconv (0.9.8-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Change DestroyImages to DestroyImageList in psiconv. +Closes: #524452 + + -- Thomas Viehmann t...@beamnet.de Fri, 08 May 2009 08:22:48 +0200 + psiconv (0.9.8-4) unstable; urgency=low * Added psiconv.1 manpage. only in patch2: unchanged: --- psiconv-0.9.8.orig/program/psiconv/gen_image.c +++ psiconv-0.9.8/program/psiconv/gen_image.c @@ -165,8 +165,8 @@ DestroyExceptionInfo(exc); DestroyImageInfo(image_info); if (image != images) -DestroyImages(image); - DestroyImages(images); +DestroyImageList(image); + DestroyImageList(images); } void gen_clipart(const psiconv_config config,psiconv_list list,
Bug#527329: patch eliminating segfault
tag 527329 patch thanks Hi Ray, with respect to the problem of pstoedit segfaulting at termination (this might not matter much for command line usage, so I downgraded the severity, but it does break programs using pstoedit, I found it with the inkscape Render LaTeX function), I propose to disable the dlclose call. It does not seem to be called except at program termination (when the static variable LoadedPlugins is deinitialized and deinitializes all DynLoader instances that have been add'ed to it), so there seems little gain in doing the dlclose. In the long term, another option might be to do away with the plugin regime completely. As it is presently used, there seems little advantage for Debian, but, naturally, you are more qualified to make this call. Please consider attached patch. If you are busy or something, I can try to find someone else to upload this as an NMU. Thanks for maintaining pstoedit. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527329: patch eliminating segfault
tag 527329 patch
thanks
Hi Ray,
[nothing as nice as attaching the patch to a mail claiming patch]
with respect to the problem of pstoedit segfaulting at termination (this
might not matter much for command line usage, so I downgraded the
severity, but it does break programs using pstoedit, I found it with the
inkscape Render LaTeX function), I propose to disable the dlclose call.
It does not seem to be called except at program termination (when the
static variable LoadedPlugins is deinitialized and deinitializes all
DynLoader instances that have been add'ed to it), so there seems little
gain in doing the dlclose.
In the long term, another option might be to do away with the plugin
regime completely. As it is presently used, there seems little advantage
for Debian, but, naturally, you are more qualified to make this call.
Please consider attached patch. If you are busy or something, I can try
to find someone else to upload this as an NMU.
Thanks for maintaining pstoedit.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
diff -u pstoedit-3.45/config.guess pstoedit-3.45/config.guess
diff -u pstoedit-3.45/config.sub pstoedit-3.45/config.sub
diff -u pstoedit-3.45/debian/changelog pstoedit-3.45/debian/changelog
--- pstoedit-3.45/debian/changelog
+++ pstoedit-3.45/debian/changelog
@@ -1,3 +1,16 @@
+pstoedit (3.45-6.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Disable unloading of plugins (comment out dlclose in dynload.cpp).
+This did lead to segmentation faults, aparently because something
+got deinitialized twice by plugins that were unloaded.
+However, libpstoedit does not support any way of unloading them
+except automatically calling the destructor at program termination,
+so we might just get by without unloading the libraries.
+Closes: #527329
+
+ -- Thomas Viehmann t...@beamnet.de Fri, 08 May 2009 23:35:38 +0200
+
pstoedit (3.45-6) unstable; urgency=medium
* [debian/control]
diff -u pstoedit-3.45/src/dynload.cpp pstoedit-3.45/src/dynload.cpp
--- pstoedit-3.45/src/dynload.cpp
+++ pstoedit-3.45/src/dynload.cpp
@@ -135,7 +135,8 @@
{
if (handle) {
#if defined(__linux) || defined(__linux__) || defined(__CYGWIN32__) || defined(__FreeBSD__) || defined(__hpux) || defined(__sparc) || defined(__OS2__) || defined(_AIX) || (defined (HAVE_DLFCN_H) (HAVE_DLFCN_H==1 ) )
- dlclose(handle);
+ /* disabled because deinitializing plugins seem to cause segfaults at program termination */
+ /* dlclose(handle); */
#elif defined(_WIN32)
(void) WINFREELIB((HINSTANCE) handle);
#else
Bug#527329: segfault loading plugins
Package: pstoedit Severity: grave Version: 3.45-6 Hi, thanks for maintaining pstoedit. $ gdb --args .libs/pstoedit GNU gdb 6.8-debian Copyright (C) 2008 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... (gdb) run Starting program: /tmp/pstoedit-3.45/src/.libs/pstoedit pstoedit: version 3.45 / DLL interface 108 (build May 6 2009 - release build - g++ 4.3.3) : Copyright (C) 1993 - 2007 Wolfgang Glunz [Thread debugging using libthread_db enabled] Error while reading shared library symbols: Cannot find new threads: generic error Cannot find new threads: generic error (gdb) bt #0 0x7fb95bde2947 in ?? () from /lib64/ld-linux-x86-64.so.2 #1 0x7fb95bdde406 in ?? () from /lib64/ld-linux-x86-64.so.2 #2 0x7fb95bde227b in ?? () from /lib64/ld-linux-x86-64.so.2 #3 0x7fb95b2cef5b in ?? () from /lib/libdl.so.2 #4 0x7fb95bdde406 in ?? () from /lib64/ld-linux-x86-64.so.2 #5 0x7fb95b2cf30c in ?? () from /lib/libdl.so.2 #6 0x7fb95b2ceec1 in dlopen () from /lib/libdl.so.2 #7 0x7fb95bb5c90a in DynLoader::open (this=0xca0840, libname_P=0xc9f180 /tmp/pstoedit-3.45/src/.libs/libp2edrvmagick++.so) at dynload.cpp:105 #8 0x7fb95bb5ca74 in DynLoader (this=0xca0840, libname_P=0xc9f180 /tmp/pstoedit-3.45/src/.libs/libp2edrvmagick++.so, verbose_p=0) at dynload.cpp:88 #9 0x7fb95bb5caf6 in loadaPlugin (filename=0xc9f180 /tmp/pstoedit-3.45/src/.libs/libp2edrvmagick++.so, errstre...@0x600e40, verbose=false) at dynload.cpp:218 #10 0x7fb95bb5ce4f in loadPlugInDrivers (pluginDir=0x7fff63fe7c80 /tmp/pstoedit-3.45/src/.libs, errstre...@0x600e40, verbose=false) at dynload.cpp:341 #11 0x7fb95bb730cc in loadpstoeditplugins (progname=0x7fff63fee7dd /tmp/pstoedit-3.45/src/.libs/pstoedit, errstre...@0x600e40, verbose=false) at pstoedit.cpp:265 #12 0x7fb95bb73a0d in pstoedit (argc=1, argv=0x7fff63fee558, errstre...@0x600e40, call_PI=0x7fb95bb5d7c5 callgs(int, char const* const*), whichPI=0x7fb95bb5d516 whichPI(std::ostream, int, char const*), pushinsPtr=0x0) at pstoedit.cpp:435 #13 0x7fb95bb77b05 in pstoeditwithghostscript (argc=1, argv=0x7fff63fee558, errstre...@0x600e40, pushinsPtr=0x0) at pstoedit.cpp:1281 #14 0x004009c2 in main (argc=1, argv=0x7fff63fee558) at cmdmain.cpp:39 (gdb) quit Versions of packages pstoedit depends on: ii ghostscript8.64~dfsg-1.1 The GPL Ghostscript PostScript/PDF ii libc6 2.9-9 GNU C Library: Shared libraries ii libpstoedit0c2a3.45-6PostScript to editable vector grap ii libstdc++6 4.4.0-2 The GNU Standard C++ Library v3 pstoedit recommends no packages. Versions of packages pstoedit suggests: ii transfig 1:3.2.5.a-1 Utilities for converting XFig figu ii xfig 1:3.2.5.a-2 Facility for Interactive Generatio Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523596: problem of 523596 is in graphicsmagick
reassign 523596 libgraphicsmagick1-dev retitle 523596 Bogus cflags returned by GraphicsMagick-config Hi Daniel, thanks for maintaining graphicsmagick $ GraphicsMagick-config --cflags -fopenmp -Wall -g -fno-strict-aliasing -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector -fPIE -O2 -Wall -pthread Not good. Here it is -fPIE causing trouble (FTBFS), but I do not think that it has any business specifying any of the above. Similar considerations probably apply to other options and other -config. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526422: suitesparse: diff for fix
tags 526422 + patch thanks Dear Debian Scientific Computing Team, here is a patch. Kind regards T. diff -u suitesparse-3.2.0/debian/changelog suitesparse-3.2.0/debian/changelog --- suitesparse-3.2.0/debian/changelog +++ suitesparse-3.2.0/debian/changelog @@ -1,3 +1,14 @@ +suitesparse (1:3.2.0-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Sprinkle some linking to KLU, UMFPACK shared libraries +to not have unresolved symbols. Remove some from CHOLMOD. +Now dpkg-shlibdeps does not warn anymore. +(changing debian/patches/*Makefile.dpatch) +Closes: #526422 + + -- Thomas Viehmann t...@beamnet.de Fri, 01 May 2009 11:19:05 +0200 + suitesparse (1:3.2.0-4) unstable; urgency=low * debian/control: Add an epoch to the version number of diff -u suitesparse-3.2.0/debian/patches/07-KLU_Lib_Makefile.dpatch suitesparse-3.2.0/debian/patches/07-KLU_Lib_Makefile.dpatch --- suitesparse-3.2.0/debian/patches/07-KLU_Lib_Makefile.dpatch +++ suitesparse-3.2.0/debian/patches/07-KLU_Lib_Makefile.dpatch @@ -55,7 +55,7 @@ -$(OBJ): $(INC) +libklu.so.3.2.0: $(OBJ_SL) -+ $(CC) -shared $^ -lm -Wl,-soname -Wl,$@ -o $@ ++ $(CC) -shared $^ -lm ../../AMD/Lib/libamd.so ../../BTF/Lib/libbtf.so ../../COLAMD/Lib/libcolamd.so -Wl,-soname -Wl,$@ -o $@ + ln -s $@ libklu.so + +$(OBJ) $(OBJ_SL): $(INC) diff -u suitesparse-3.2.0/debian/patches/12-CHOLMOD_Lib_Makefile.dpatch suitesparse-3.2.0/debian/patches/12-CHOLMOD_Lib_Makefile.dpatch --- suitesparse-3.2.0/debian/patches/12-CHOLMOD_Lib_Makefile.dpatch +++ suitesparse-3.2.0/debian/patches/12-CHOLMOD_Lib_Makefile.dpatch @@ -115,7 +115,7 @@ -$(OBJ): $(INC) +libcholmod.so.3.2.0: $(OBJ_SL) -+ $(CC) -shared $^ -lblas -llapack ../../AMD/Lib/libamd.so ../../CAMD/Lib/libcamd.so ../../COLAMD/Lib/libcolamd.so ../../CCOLAMD/Lib/libccolamd.so -lm -Wl,-soname -Wl,$@ -o $@ ++ $(CC) -shared $^ -lblas -llapack ../../AMD/Lib/libamd.so ../../COLAMD/Lib/libcolamd.so -lm -Wl,-soname -Wl,$@ -o $@ + ln -s $@ libcholmod.so + +$(OBJ) $(OBJ_SL): $(INC) diff -u suitesparse-3.2.0/debian/patches/11-UMFPACK_Lib_GNUmakefile.dpatch suitesparse-3.2.0/debian/patches/11-UMFPACK_Lib_GNUmakefile.dpatch --- suitesparse-3.2.0/debian/patches/11-UMFPACK_Lib_GNUmakefile.dpatch +++ suitesparse-3.2.0/debian/patches/11-UMFPACK_Lib_GNUmakefile.dpatch @@ -291,7 +291,7 @@ + - $(RANLIB) libumfpack.a + +libumfpack.so.3.2.0: $(II_SL) $(LL_SL) $(GN_SL) $(DI_SL) $(DL_SL) $(ZI_SL) $(ZL_SL) -+ $(CC) -shared $^ -lm -Wl,-soname -Wl,$@ -o $@ ++ $(CC) -shared $^ -lm -lblas ../../AMD/Lib/libamd.so -Wl,-soname -Wl,$@ -o $@ + ln -s $@ libumfpack.so #--- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526527: pysparse: diff for NMU version 1.0.1-5.1
Package: pysparse
Version: 1.0.1-5
Severity: serious
Tags: patch
Hi Adam,
thanks for maintaining pysparse. If I may venture a request: it would be
nice if pysparse.superlu worked instead of segfaulting. Attached is my
suggestion to fix it. (Yeah, it breaks some options which are
undocumented and in part have changed before without notice and it is
not segfaulting anymore, I would claim that that is strictly better.)
See this message for a test case:
https://lists.ubuntu.com/archives/ubuntu-users/2008-May/148160.html
Note, however, that unlike the claim of his code the output
should not be a vector with all ones.
I have allowed myself to fix some unrelated bogosities.
Kind regards
T.
diff -u pysparse-1.0.1/debian/changelog pysparse-1.0.1/debian/changelog
--- pysparse-1.0.1/debian/changelog
+++ pysparse-1.0.1/debian/changelog
@@ -1,3 +1,11 @@
+pysparse (1.0.1-5.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix pysparse.superlu module port to superlu 3 based on reading
+the docs.
+
+ -- Thomas Viehmann t...@beamnet.de Fri, 01 May 2009 20:56:39 +0200
+
pysparse (1.0.1-5) unstable; urgency=low
* Removed removal of /usr/lib and Build-Depends on python-central = 0.6
diff -u pysparse-1.0.1/Src/superlumodule.c pysparse-1.0.1/Src/superlumodule.c
--- pysparse-1.0.1/Src/superlumodule.c
+++ pysparse-1.0.1/Src/superlumodule.c
@@ -89,8 +89,9 @@
dCreate_Dense_Matrix(B, self-n, 1, (double *)x-data, self-n, SLU_DN,
SLU_D, SLU_GE);
#endif
+StatInit(dummy);
/* Solve the system, overwriting vector x. */
- dgstrs(trans, self-L, self-U, self-perm_r, self-perm_c, B, dummy,
info);
+ dgstrs(trans, self-L, self-U, self-perm_c, self-perm_r, B, dummy,
info);
/* free memory */
Destroy_SuperMatrix_Store(B);
@@ -197,20 +198,17 @@
SuperMatrix A; /* A in NC format used by the factorization routine. */
SuperMatrix AC; /* Matrix postmultiplied by Pc */
mem_usage_t mem_usage;
- int lwork = 0;
int *etree;
int info;
- optionst.Trans = NOTRANS;
- optionst.DiagPivotThresh = diag_pivot_thresh;
- statt.panel_histo = panel_size;
- statt.RefineSteps = relax;
+ set_default_options(optionst);
+ /* the below comment is interesting because statt is a local variable. eh?
/* make sure StatInit is only called once */
- if (!StatInit_done) {
+ //if (!StatInit_done) {
StatInit(statt);
-StatInit_done = 1;
- }
+ // StatInit_done = 1;
+ //}
/* Create SuperLUObject */
self = PyObject_New(SuperLUObject, SuperLUType);
@@ -231,16 +229,17 @@
etree = intMalloc(n);
self-perm_r = intMalloc(n);
self-perm_c = intMalloc(n);
- if (self-perm_r == NULL || self-perm_c == NULL) {
+ if (self-perm_r == NULL || self-perm_c == NULL || etree == NULL) {
PyErr_NoMemory();
goto fail;
}
get_perm_c(permc_spec, A, self-perm_c); /* calc column permutation */
sp_preorder(optionst, A, self-perm_c, etree, AC); /* apply column
permutation */
-
+ panel_size = sp_ienv(1);
+ relax = sp_ienv(2);
/* Perform factorization */
dgstrf(optionst, AC, drop_tol, relax, panel_size,
- etree, NULL, lwork, self-perm_r, self-perm_c,
+ etree, NULL, 0, self-perm_c,self-perm_r,
self-L, self-U, statt, info);
/* free memory */
@@ -263,8 +262,8 @@
return (PyObject *)self;
fail:
- PyMem_Del(self-perm_r);
- PyMem_Del(self-perm_c);
+ SUPERLU_FREE(self-perm_r);
+ SUPERLU_FREE(self-perm_c);
PyObject_Del(self);
return NULL;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526422: linking of the dynamic libraries
Severity: serious Package: libsuitesparse-3.2.0 Version: 1:3.2.0-4 Hi, thanks for providing packages of suitsparse. It might be nice to link dynamic libraries to those providing the needed symbols: Not only will it avoid warnings like dpkg-shlibdeps: warning: symbol amd_realloc used by debian/libsuitesparse-3.2.0/usr/lib/libklu.so.3.2.0 found in none of the libraries. at the end of the build, but also (after installing python-sparse) python -c import pysparse.umfpack might benefit. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#480056: same symptoms here, caused by misbehaving pam plugin
Hi, thanks for maintaining GDM. I got similar symptoms, i.e. gdm crashing on first login attempt with signal 6 and then being slow but working. I tracked this down to the pam_authenticate call in daemon/verify-pam.c. For me, this was likely caused by libpam-thinkfinger (i.e. removing and reinstalling turned the crshing off and on, also, judging by the bug-reports, it seems to be crash-happy) after a kernel update to Debian's linux 2.6.29(?). Just a thought, apologies for the noise. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516826: libdc1394 should be removed (transition blocker 516826)
Hi, as many of you are probably aware libdc1394 has been superseded by libdc1394-22 in February 2008. Given that it's broken now (using long-deprecated and now removed functions from libraw1394), it's time for it to go. Removal from testing will break the following rdependencies: player: will be able to use -22 with new upstream, maybe good to just remove now xmms2: is in the process of being fixed (it needed a binNMU on hppa and ia64, those have been built on 2009-03-12 but not uploaded yet). This leaves pwlib,pwlib-titan, two obsolete versions of ptlib (in experimental) courtesy of the Debian VoIP team. The options would be to wait (but some of these seem to be candidates for incurring other transition-related dependencies) or remove the following reverse dependencies from testing as well: openh323-titan,openmcu,asterisk,asterisk-oh323,ekiga,gnugk,ohphone,opal,openam,openh323,pstngw Now, this is quite a number of source packages. OTOH, it is a small price for getting obsolete libraries out of testing. I would fully expect none of libdc1394 (-13), pwlib, or pwlib-titan to be released with squeeze anyway. Based on observations from 2008, maybe the Debian VoIP team should be advised to revise its maintenance style in order to not need as much external intervention on its bugs as they did in the past. (And yes, I realize that #516826 is not a VoIP team bug. Without doubt all Debian developers looked at the transition-blocker bugs after it was in their debian-devel-announce required reading.) Kind regards T. P.S.: Thanks to Joerg and Barry for dak rm -nR output. Cut and paste errors and bad conclusions are my own. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487645: partial fix
tag 517465 patch tag 487645 patch thanks Hi, a fresh look at testing reveals that the problem with the output was the spurious printf I put in for debugging. Both video and audio of an ogg video downloaded from wikimedia commons for testing converted with ffmpeg2raw and then passed to rawplay (needs a .dv extension to work properly[1]) played fine, so I think this patch is ready to go. Kind regards T. 1. I could say something about having if ( strncasecmp( strrchr( ( char* ) src, '.' ), .avi, 4 ) == 0 ) et al. in smilutils/libkino/playlist.cc... -- Thomas Viehmann, http://thomas.viehmann.net/ diff -u smilutils-0.3.2+cvs20070731/debian/changelog smilutils-0.3.2+cvs20070731/debian/changelog --- smilutils-0.3.2+cvs20070731/debian/changelog +++ smilutils-0.3.2+cvs20070731/debian/changelog @@ -1,3 +1,18 @@ +smilutils (0.3.2+cvs20070731-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Move off removed ffmpeg functions: +- avcodec_audio_decode - avcodec_audio_decode2 +- img_convert - sws_scale (with tedium of context acquisiton etc.) +- add libswscale-dev to build-depends +Closes: #517465, #487645. + * Fix the not completely ideal pointer usage in ffmpeg2raw that +caused some compiler warnings and also impeded testing because +ffmpeg2raw invariably printed No video or audio stream found +instead of actually doing something. + + -- Thomas Viehmann t...@beamnet.de Sat, 07 Mar 2009 21:04:05 +0100 + smilutils (0.3.2+cvs20070731-4) unstable; urgency=low * Fix build with gcc 4.3 (closes: #455132) diff -u smilutils-0.3.2+cvs20070731/debian/control smilutils-0.3.2+cvs20070731/debian/control --- smilutils-0.3.2+cvs20070731/debian/control +++ smilutils-0.3.2+cvs20070731/debian/control @@ -4,7 +4,7 @@ Maintainer: Roland Mas lola...@debian.org Uploaders: Paul Brossier p...@debian.org Standards-Version: 3.7.3 -Build-Depends: debhelper (= 5), libquicktime-dev, libdv4-dev, libglib2.0-dev, libxml2-dev, libimlib2-dev, libsdl1.2-dev, autotools-dev, libltdl3-dev, ffmpeg, libavcodec-dev, libavformat-dev, libtool, libvorbis-dev, libogg-dev, libdts-dev, libgtk2.0-dev, autoconf, automake +Build-Depends: debhelper (= 5), libquicktime-dev, libswscale-dev, libdv4-dev, libglib2.0-dev, libxml2-dev, libimlib2-dev, libsdl1.2-dev, autotools-dev, libltdl3-dev, ffmpeg, libavcodec-dev, libavformat-dev, libtool, libvorbis-dev, libogg-dev, libdts-dev, libgtk2.0-dev, autoconf, automake Package: smilutils Architecture: any diff -u smilutils-0.3.2+cvs20070731/config.sub smilutils-0.3.2+cvs20070731/config.sub --- smilutils-0.3.2+cvs20070731/config.sub +++ smilutils-0.3.2+cvs20070731/config.sub @@ -1,10 +1,10 @@ #! /bin/sh # Configuration validation subroutine script. # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, -# 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, -# Inc. +# 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 +# Free Software Foundation, Inc. -timestamp='2007-06-28' +timestamp='2008-01-16' # This file is (in principle) common to ALL GNU software. # The presence of a machine in this file suggests that SOME GNU software @@ -72,8 +72,8 @@ version=\ GNU config.sub ($timestamp) -Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 -Free Software Foundation, Inc. +Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, +2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. @@ -369,10 +369,14 @@ | v850-* | v850e-* | vax-* \ | we32k-* \ | x86-* | x86_64-* | xc16x-* | xps100-* | xscale-* | xscalee[bl]-* \ - | xstormy16-* | xtensa-* \ + | xstormy16-* | xtensa*-* \ | ymp-* \ | z8k-*) ;; + # Recognize the basic CPU types without company name, with glob match. + xtensa*) + basic_machine=$basic_machine-unknown + ;; # Recognize the various machine names and aliases which stand # for a CPU type and a company and sometimes even an OS. 386bsd) @@ -443,6 +447,14 @@ basic_machine=ns32k-sequent os=-dynix ;; + blackfin) + basic_machine=bfin-unknown + os=-linux + ;; + blackfin-*) + basic_machine=bfin-`echo $basic_machine | sed 's/^[^-]*-//'` + os=-linux + ;; c90) basic_machine=c90-cray os=-unicos @@ -668,6 +680,14 @@ basic_machine=m68k-isi os=-sysv ;; + m68knommu) + basic_machine=m68k-unknown + os=-linux + ;; + m68knommu-*) + basic_machine=m68k-`echo $basic_machine | sed 's/^[^-]*-//'` + os=-linux + ;; m88k-omron*) basic_machine=m88k-omron ;; @@ -813,6 +833,14 @@ basic_machine=i860-intel os=-osf ;; + parisc) + basic_machine=hppa-unknown + os=-linux + ;; + parisc-*) + basic_machine=hppa-`echo $basic_machine | sed 's/^[^-]*-//'` + os=-linux + ;; pbd) basic_machine=sparc-tti ;; @@ -1021,6 +1049,10 @@ basic_machine
Bug#517465: partial fix
Hi, attached are some changes to ffmpeg2raw. I'm not sure that I got to a level where I can verify that ffmpeg2raw works corrctly, though. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ diff -u smilutils-0.3.2+cvs20070731/debian/changelog smilutils-0.3.2+cvs20070731/debian/changelog --- smilutils-0.3.2+cvs20070731/debian/changelog +++ smilutils-0.3.2+cvs20070731/debian/changelog @@ -1,3 +1,18 @@ +smilutils (0.3.2+cvs20070731-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Move off removed ffmpeg functions: +- avcodec_audio_decode - avcodec_audio_decode2 +- img_convert - sws_scale (with tedium of context acquisiton etc.) +- add libswscale-dev to build-depends +Closes: #517465, #487645. + * Fix the not completely ideal pointer usage in ffmpeg2raw that +caused some compiler warnings and also impeded testing because +ffmpeg2raw invariably printed No video or audio stream found +instead of actually doing something. + + -- Thomas Viehmann t...@beamnet.de Sat, 07 Mar 2009 21:04:05 +0100 + smilutils (0.3.2+cvs20070731-4) unstable; urgency=low * Fix build with gcc 4.3 (closes: #455132) diff -u smilutils-0.3.2+cvs20070731/debian/control smilutils-0.3.2+cvs20070731/debian/control --- smilutils-0.3.2+cvs20070731/debian/control +++ smilutils-0.3.2+cvs20070731/debian/control @@ -4,7 +4,7 @@ Maintainer: Roland Mas lola...@debian.org Uploaders: Paul Brossier p...@debian.org Standards-Version: 3.7.3 -Build-Depends: debhelper (= 5), libquicktime-dev, libdv4-dev, libglib2.0-dev, libxml2-dev, libimlib2-dev, libsdl1.2-dev, autotools-dev, libltdl3-dev, ffmpeg, libavcodec-dev, libavformat-dev, libtool, libvorbis-dev, libogg-dev, libdts-dev, libgtk2.0-dev, autoconf, automake +Build-Depends: debhelper (= 5), libquicktime-dev, libswscale-dev, libdv4-dev, libglib2.0-dev, libxml2-dev, libimlib2-dev, libsdl1.2-dev, autotools-dev, libltdl3-dev, ffmpeg, libavcodec-dev, libavformat-dev, libtool, libvorbis-dev, libogg-dev, libdts-dev, libgtk2.0-dev, autoconf, automake Package: smilutils Architecture: any diff -u smilutils-0.3.2+cvs20070731/config.sub smilutils-0.3.2+cvs20070731/config.sub --- smilutils-0.3.2+cvs20070731/config.sub +++ smilutils-0.3.2+cvs20070731/config.sub @@ -1,10 +1,10 @@ #! /bin/sh # Configuration validation subroutine script. # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, -# 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, -# Inc. +# 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 +# Free Software Foundation, Inc. -timestamp='2007-06-28' +timestamp='2008-01-16' # This file is (in principle) common to ALL GNU software. # The presence of a machine in this file suggests that SOME GNU software @@ -72,8 +72,8 @@ version=\ GNU config.sub ($timestamp) -Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 -Free Software Foundation, Inc. +Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, +2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. @@ -369,10 +369,14 @@ | v850-* | v850e-* | vax-* \ | we32k-* \ | x86-* | x86_64-* | xc16x-* | xps100-* | xscale-* | xscalee[bl]-* \ - | xstormy16-* | xtensa-* \ + | xstormy16-* | xtensa*-* \ | ymp-* \ | z8k-*) ;; + # Recognize the basic CPU types without company name, with glob match. + xtensa*) + basic_machine=$basic_machine-unknown + ;; # Recognize the various machine names and aliases which stand # for a CPU type and a company and sometimes even an OS. 386bsd) @@ -443,6 +447,14 @@ basic_machine=ns32k-sequent os=-dynix ;; + blackfin) + basic_machine=bfin-unknown + os=-linux + ;; + blackfin-*) + basic_machine=bfin-`echo $basic_machine | sed 's/^[^-]*-//'` + os=-linux + ;; c90) basic_machine=c90-cray os=-unicos @@ -668,6 +680,14 @@ basic_machine=m68k-isi os=-sysv ;; + m68knommu) + basic_machine=m68k-unknown + os=-linux + ;; + m68knommu-*) + basic_machine=m68k-`echo $basic_machine | sed 's/^[^-]*-//'` + os=-linux + ;; m88k-omron*) basic_machine=m88k-omron ;; @@ -813,6 +833,14 @@ basic_machine=i860-intel os=-osf ;; + parisc) + basic_machine=hppa-unknown + os=-linux + ;; + parisc-*) + basic_machine=hppa-`echo $basic_machine | sed 's/^[^-]*-//'` + os=-linux + ;; pbd) basic_machine=sparc-tti ;; @@ -1021,6 +1049,10 @@ basic_machine=tic6x-unknown os=-coff ;; + tile*) + basic_machine=tile-unknown + os=-linux-gnu + ;; tx39) basic_machine=mipstx39-unknown ;; diff -u smilutils-0.3.2+cvs20070731/config.guess smilutils-0.3.2+cvs20070731/config.guess --- smilutils-0.3.2+cvs20070731/config.guess +++ smilutils-0.3.2+cvs20070731/config.guess @@ -1,10 +1,10 @@ #! /bin/sh # Attempt to guess a canonical system name
Bug#517905: tesseract: ship training script and docs
Hi Jeffrey, jeffrey.ratcli...@gmail.com wrote: On Mar 2, 2009 9:28pm, Thomas Viehmann t...@beamnet.de wrote: it would be nice to have tesseractTrainer.py (in upstream download area, but with separate (free, GPL) license and author) and a copy of the online HTML docs (eg about training). I take your point. What do you suggest a. the package b. the executable be called? a. tesseract-training, or make it part of the main package? b. tesseractTrainer? We can't leave the .py extension. So many options. :) Personally, I'd probably look into putting it in the main package and maybe also get rid of the camelCase name. If you are in contact with upstream, maybe they have a suggestion. But really, whatever works for you is good for me as well. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518045: RFP: pywikipediabot -- Python wikipedia robot framework
Severity: wishlist Package: wnpp X-Debbugs-CC: debian-de...@lists.debian.org Hi, it might be neat to have pywikipediabot in Debian. Package: pywikipediabot URL: http://pywikipediabot.sourceforge.net/ see also http://meta.wikimedia.org/wiki/Interwiki_bot/Getting_started Authors: Various License: MIT (mostly) Language: Python Tools for maintenance of MediaWiki installations. This also contains parsers for wikipedia (et al) content. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517904: tesseract-deu: provide source data
Package: tesseract-deu Severity: important Version: 2.00-1 Tags: fixed-upstream Hi Jeffrey, thanks for maintaining tesseract and data packages. However, providing the data only in the preprocessed form is (bordering on the) problematic w.r.t. DFSG and inconvenient to the users. Please use the source upstream data for building the packages. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517905: tesseract: ship training script and docs
Package: tesseract Version: 2.03-2 Severity: wishlist Hi again, it would be nice to have tesseractTrainer.py (in upstream download area, but with separate (free, GPL) license and author) and a copy of the online HTML docs (e.g. about training). Thanks for maintaining tesseract. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517904: tesseract-deu: provide source data
Hi Jeffrey, first of all, thanks for the quick reply! I appreciate you for taking the time and even more so for doing so within only a few hours after my report. Jeffrey Ratcliffe wrote: 2009/3/2 Thomas Viehmann t...@beamnet.de: However, providing the data only in the preprocessed form is (bordering on the) problematic w.r.t. DFSG and inconvenient to the users. Please use the source upstream data for building the packages. How are the language packs problematic with respect to DFSG? Why are they inconvenient to the users? The training data is mostly not available, and even if it were, I don't see the advantage of building the language packs from it. Well, on the contrary, it seems that the training data is available in the boxtiff files[1]. The DFSG ask to ship source for your packages. The training data is arguably compiled from source, in particular when we see that both the compiler is provided and the source appears to be available. It is inconvenient when one wants to produce an enhanced dataset by training on more characters while incorporating previous data. (Mind you, the hard limit on the number of .tr files for the training programs - MAX_NUM_CONFIGS - also is a bit tedious, but this is a different matter.) Maybe there is another way, but looking at the training instructions[2], I was thinking well, I should just use my .tif and .box alongside the available ones. I've put the severity as important (as opposed to serious) because the source requirement is not as clear cut with statistical data, but here I ended up in a situation of the source would come in handy here and I'm using free software to not have to look for it rather than actively systematically looking into DFSG compliance. Also, it seems to be prudent to not deliberately stay in the more shady areas of source requirement when the source data sets are even available. But then, what do I know. You are a Debian maintainer and I am not, so you are the undisputed authority on the DFSG in this bug report. Thanks for your consideration. Kind regards T. 1. http://code.google.com/p/tesseract-ocr/downloads/list 2. http://code.google.com/p/tesseract-ocr/wiki/TrainingTesseract -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515207: pyusb: diff for NMU version 0.4.1-4.1
Package: pyusb
Version: 0.4.1-4
Severity: grave
Tags: patch
Hi Petter, Bernd,
build log:
pyusb.c: In function 'getBuffer':
pyusb.c:145: warning: passing argument 3 of 'PyString_AsStringAndSize'
from incompatible pointer type
Might not be too good.
In fact, on the current package, the python 2.5 value will overwrite
the value of index parameter passed to controlMsg. python 2.4 worked.
Mind you, I believe #476796 should be closed as invalid / reassigned
to libusb because the string comes from there and it does the right
thing. I'm saying this here because I could imagine that Tollef was
seeing his problem after a controlMsg failed for the same reason as it
did for me. Note that this bug was very hard to find (I actually added
a lot of debug statements in libusb before I found what happened
because I thought it was a problem with the USB protocol).
Unfortunately, the workaround needs a compatibility #defines (see
below).
Apologies for not auditing all python extensions for this bug when
seeing a previous instance in a different package.
Kind regards
T.
diff -u pyusb-0.4.1/debian/changelog pyusb-0.4.1/debian/changelog
--- pyusb-0.4.1/debian/changelog
+++ pyusb-0.4.1/debian/changelog
@@ -1,3 +1,12 @@
+pyusb (0.4.1-4.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Don't pass int* where we need Py_ssize_t*.
+Breaks (overwriting parameters) for python 2.5 on 64 bit arch.
+Needs the usual PEP353 compatibility bruhaha plus printf.
+
+ -- Thomas Viehmann t...@beamnet.de Sat, 14 Feb 2009 20:13:04 +0100
+
pyusb (0.4.1-4) unstable; urgency=low
[ Piotr Ożarowski ]
only in patch2:
unchanged:
--- pyusb-0.4.1.orig/pyusb.c
+++ pyusb-0.4.1/pyusb.c
@@ -13,6 +13,14 @@
#include stdio.h
#define DEFAULT_TIMEOUT 100
+/* see PEP353 */
+#if PY_VERSION_HEX 0x0205 !defined(PY_SSIZE_T_MIN)
+typedef int Py_ssize_t;
+# define PY_SSIZE_T_MAX INT_MAX
+# define PY_SSIZE_T_MIN INT_MIN
+# define PY_FORMAT_SIZE_T
+#endif
+
/*
* Necessary to compile successfully in python 2.3
* Thanks to Mark Rages for the patch
@@ -126,7 +134,7 @@
*/
PYUSB_STATIC char *getBuffer(
PyObject *obj,
- int *size
+ Py_ssize_t *size
)
{
char *p = NULL;
@@ -1104,7 +1112,7 @@
int index = 0;
char *bytes;
PyObject *data;
- int size;
+ Py_ssize_t size;
int timeout = DEFAULT_TIMEOUT;
int ret;
int as_read = 0;
@@ -1162,7 +1170,7 @@
timeout);
if (as_read) {
- fprintf(stderr, \tbuffer: %d\n, size);
+ fprintf(stderr, \tbuffer: % PY_FORMAT_SIZE_T d\n, size);
} else {
fprintf(stderr, controlMsg buffer param:\n);
printBuffer(bytes, size);
@@ -1386,7 +1394,7 @@
int endpoint;
int timeout = DEFAULT_TIMEOUT;
char *data;
- int size;
+ Py_ssize_t size;
PyObject *bytes;
int ret;
PyObject *retObj;
@@ -1493,7 +1501,7 @@
int endpoint;
int timeout = DEFAULT_TIMEOUT;
char *data;
- int size;
+ Py_ssize_t size;
PyObject *bytes;
int ret;
PyObject *retObj;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514015: Bug#514016: options for fixing
On 2009-02-06 09:57:36.00 Raphael Hertzog hert...@debian.org wrote: On Thu, 05 Feb 2009, Thomas Viehmann wrote: What would dpkg do with the symlinks in the the unpack phase? I have not tested it, but I would venture the same thing (calling tar, ergo having the same problem) from when I last looked at it. dpkg does not call tar, it has it own tar implementation (which explains why we don't support yet POSIX tar archives inside .deb). I'm not sure how it behaves in the situation that matters for this bug. Try it with dpkg --root=/target/dir/ … Thanks for stepping in to correct me here. dpkg does have its own tar, only dpkg-deb calls tar. Try it with dpkg --root=/target/dir/ … From looking at the code, it does the right thing. Kind regards T. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514015: options for fixing
Hi,
just as an exercise what might be done to fix this:
It would seem that the options are
- not fix it (for now),
- find something in current tar that works (I didn't),
- switch off tar,
- try to do something with tar
(new upstream - vs. release: ugh - has a apply to symlink target
--transform flag, but that also might need post-processing of
symlinks at end of bootstrapping),
- try to do some ld-preload(?) trickery for changing the way symlinks
are read,
- try to find some way to chroot before calling tar, one possibility
would be copying required files to some temp CWD, make tar look there
for the libraries, chrooting to the target and calling tar from (the
unchanged) CWD,
- add chroot option to tar (see patch).
It would seem that in terms of total invasiveness, the last option is
minimal, but it might be unwise to add options without consulting
upstream (however, it once upstream agrees to have an option with a
given spec, one could implement that locally).
Of course, the patch introduces new strings (translator-:( ), but they
only shown with the new option.
But then, this is just an idea, I'm sure you'll come up with a good, and
probably better solution.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
reverted:
diff -u tar-1.20/src/list.c tar-1.20/src/list.c
--- tar-1.20/src/list.c
+++ tar-1.20/src/list.c
@@ -72,6 +72,11 @@
name_gather ();
open_archive (ACCESS_READ);
+ if (chroot_option)
+ {
+ sys_chroot(chroot_option);
+ }
+
do
{
prev_status = status;
diff -u tar-1.20/debian/changelog tar-1.20/debian/changelog
--- tar-1.20/debian/changelog
+++ tar-1.20/debian/changelog
@@ -1,3 +1,10 @@
+tar (1.20-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Implement --chroot option for extraction.
+
+ -- Thomas Viehmann t...@beamnet.de Thu, 05 Feb 2009 17:32:49 +0100
+
tar (1.20-1) unstable; urgency=low
* new upstream version
only in patch2:
unchanged:
--- tar-1.20.orig/src/system.c
+++ tar-1.20/src/system.c
@@ -24,6 +24,11 @@
#if MSDOS
+void
+sys_chroot (char* dir)
+{
+}
+
bool
sys_get_archive_stat (void)
{
@@ -120,6 +125,21 @@
static struct stat archive_stat; /* stat block for archive file */
+void
+sys_chroot (char* dir)
+{
+ if (chroot(dir) 0)
+{
+ int e = errno;
+ FATAL_ERROR ((0, e, _(Cannot chroot to %s), dir));
+}
+ if (chdir(/) 0)
+{
+ int e = errno;
+ FATAL_ERROR ((0, e, _(Cannot chdir to '/' after chroot to %s), dir));
+}
+}
+
bool
sys_get_archive_stat (void)
{
only in patch2:
unchanged:
--- tar-1.20.orig/src/tar.c
+++ tar-1.20/src/tar.c
@@ -252,6 +252,7 @@
CHECK_DEVICE_OPTION,
CHECKPOINT_OPTION,
CHECKPOINT_ACTION_OPTION,
+ CHROOT_OPTION,
DELAY_DIRECTORY_RESTORE_OPTION,
HARD_DEREFERENCE_OPTION,
DELETE_OPTION,
@@ -613,6 +614,8 @@
{add-file, ARGP_KEY_ARG, N_(FILE), 0,
N_(add given FILE to the archive (useful if its name starts with a dash)), GRID+1 },
+ {chroot, CHROOT_OPTION, N_(DIR), 0,
+ N_(chroot to directory DIR for extraction), GRID+1 },
{directory, 'C', N_(DIR), 0,
N_(change to directory DIR), GRID+1 },
{files-from, 'T', N_(FILE), 0,
@@ -1590,6 +1593,10 @@
args-version_control_string = arg;
break;
+case CHROOT_OPTION:
+ chroot_option = arg;
+ break;
+
case DELAY_DIRECTORY_RESTORE_OPTION:
delay_directory_restore_option = true;
break;
only in patch2:
unchanged:
--- tar-1.20.orig/src/common.h
+++ tar-1.20/src/common.h
@@ -141,6 +141,9 @@
/* Print a message if not all links are dumped */
GLOBAL int check_links_option;
+/* Chroot option value. */
+GLOBAL char const *chroot_option;
+
/* Patterns that match file names to be excluded. */
GLOBAL struct exclude *excluded;
@@ -293,6 +296,7 @@
/* Specified value or pattern. */
GLOBAL const char *volume_label_option;
+
/* Other global variables. */
@@ -700,6 +704,7 @@
/* Module system.c */
+void sys_chroot (char* dir);
void sys_detect_dev_null_output (void);
void sys_save_archive_dev_ino (void);
void sys_drain_input_pipe (void);
only in patch2:
unchanged:
Bug#514015: options for fixing
Hi, thanks for your replies. Again, this is mostly because I needed some idle occupation and am not into sudoku. Apologies for presenting it a way that looked like a proposal. Bdale Garbee wrote: How about just fixing the offending package to use a relative symlink, like /lib64 - lib? This is well within policy since they're adjacent objects in the same directory, and is less likely to break things or be a pain to maintain over time than any of the options above. I can't think of any negative consequence to this change, offhand? Well, having 1000 maintainers do the right thing is difficult, as proven by the release process. Adding a Debian-specific option to tar would certainly not be my first choice. Other options do exist, my list probably is not exhaustive, but I would think that they cost a lot of code with a lot of opportunity to add bugs where things work now and it might be interesting to have an upper bound for how involved a minimal fix is. Thinking on a larger scale, what we actually want to do here is unpack a tarball into a chroot. I venture that this is a reasonable use case of tar and that it might just be possible to try to have upstream agree to have such an option in principle so that there is a plan to get rid of the debian-specificity of the option. Bastian Blank wrote: - switch off tar, I intend to replace tar with a custom unpack routine in cdebootstrap. TBH, I'm not that impressed by the implementation of ar (or a subset) in dpkg and am not sure that reimplementing tar extraction it is a good path to take when I would think that an option for tar to do the right thing (whether internally munging symlinks when resolving paths or using chroot) might have a general use beyond bootstrapping Debian systems. - try to do something with tar (new upstream - vs. release: ugh - has a apply to symlink target --transform flag, but that also might need post-processing of symlinks at end of bootstrapping), What would dpkg do with the symlinks in the the unpack phase? I have not tested it, but I would venture the same thing (calling tar, ergo having the same problem) from when I last looked at it. - try to do some ld-preload(?) trickery for changing the way symlinks are read, fakechroot have to do this someway, but I was unable to grok that code yet. Well, you'd have to intercept all the relevant calls (for dereferencing/reading symlinks). Seems doable, but IMO tar would be the better place. But if the masses want funny business, so be it. ... - add chroot option to tar (see patch). This is a root only option. Yes. It was my impression that (c)debootstrap are supposed to be called by root. At least I always used to call them as root when I was a developer. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481506: python-cairo+python-pygame work with default python in lenny?
tag 481506 patch
Hi,
apologies for lobbying for my pet peeves to be fixed in lenny, but the
attached python script (taking from upstream python-cairo 1.6.4[1],
needing python-pygame and python-cairo to be installed) works with
python 2.4 as is but not with the default python (2.5). Applying the
attached diff improves the situation making this also work with python
2.5. Some gory details below.
While the bug severity is set to normal, the error message is somewhat
opaque and searching the internet only reveals some maybe we should fix
this comment, so the Debian user's experience might be improved by
eliminating the need for the search. If this is interesting enough for
people to upload and later unblock...
And here the promised gory details:
- The signature changes (insofar as they are changes) to Py_ssize_t are
from the python 2.5 documentation. For python 2.4 they are actually
no changes thanks to the cairo-private.h compatibility typedefs that
seem to be based on PEP 353[2].
- python-pygame uses PyObject_AsCharBuffer from the abstract buffer
protocol to get hold of the image buffer. This function seems to exist
since Python 1.6 (certainly does in 2.4), but only python 2.5 changes
is to actually use the charbufferproc that is now missing in
python-cairo.
- I don't know why pycairo upstream does not seem to have implemented
this despite adding tests that fail on python 2.5. Maybe they still
use python 2.4 only?
Kind regards
T.
1. http://webcvs.cairographics.org/pycairo/test/pygame-test1.py
2. http://www.python.org/dev/peps/pep-0353/
--
Thomas Viehmann, http://thomas.viehmann.net/
#!/usr/bin/env python
demonstrate pycairo and pygame
method1: use a pycairo and pygame directly
import array
import math
import sys
import cairo
import pygame
def draw(surface):
x,y, radius = (250,250, 200)
ctx = cairo.Context(surface)
ctx.set_line_width(15)
ctx.arc(x, y, radius, 0, 2.0 * math.pi)
ctx.set_source_rgb(0.8, 0.8, 0.8)
ctx.fill_preserve()
ctx.set_source_rgb(1, 1, 1)
ctx.stroke()
def input(events):
for event in events:
if event.type == pygame.QUIT:
sys.exit(0)
else:
print event
Width, Height = 512, 512
surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, Width, Height)
pygame.init()
window = pygame.display.set_mode( (Width,Height) )
screen = pygame.display.get_surface()
draw(surface)
#Create PyGame surface from Cairo Surface
buf = surface.get_data()
image = pygame.image.frombuffer(buf,(Width,Height),ARGB,)
#Tranfer to Screen
screen.blit(image, (0,0))
pygame.display.flip()
while True:
input(pygame.event.get())
with pycairo 1.4.12 and pygame 1.7.1 you get the error message:
Traceback (most recent call last):
File ./pygame-test1.py, line 42, in module
image = pygame.image.frombuffer(buf,(Width,Height),ARGB,)
TypeError: char buffer type not available
This is because with
buf = surface.get_data()
pycairo provides a binary image buffer,
whereas with
image = pygame.image.frombuffer(buf,(Width,Height),ARGB,)
pygame is expecting a text-based character buffer!
diff -u pycairo-1.4.12/debian/changelog pycairo-1.4.12/debian/changelog
--- pycairo-1.4.12/debian/changelog
+++ pycairo-1.4.12/debian/changelog
@@ -1,3 +1,12 @@
+pycairo (1.4.12-1.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Python 2.5 compatibility of Image buffer interface.
+(needed e.g. for interaction with python-pygame).
+Closes: #481506
+
+ -- Thomas Viehmann t...@beamnet.de Tue, 13 Jan 2009 22:51:49 +0100
+
pycairo (1.4.12-1.1) unstable; urgency=low
* NMU.
only in patch2:
unchanged:
--- pycairo-1.4.12.orig/cairo/pycairo-surface.c
+++ pycairo-1.4.12/cairo/pycairo-surface.c
@@ -504,8 +504,8 @@
/* Buffer interface functions, used by ImageSurface.get_data() */
-static int
-image_surface_buffer_getreadbuf (PycairoImageSurface *o, int segment,
+static Py_ssize_t
+image_surface_buffer_getreadbuf (PycairoImageSurface *o, Py_ssize_t segment,
const void **ptr)
{
cairo_surface_t *surface = o-surface;
@@ -522,8 +522,8 @@
return height * stride;
}
-static int
-image_surface_buffer_getwritebuf (PycairoImageSurface *o, int segment,
+static Py_ssize_t
+image_surface_buffer_getwritebuf (PycairoImageSurface *o, Py_ssize_t segment,
const void **ptr)
{
cairo_surface_t *surface = o-surface;
@@ -540,25 +540,43 @@
return height * stride;
}
-static int
-image_surface_buffer_getsegcount (PycairoImageSurface *o, int *lenp)
+static Py_ssize_t
+image_surface_buffer_getsegcount (PycairoImageSurface *o, Py_ssize_t *lenp)
{
if (lenp) {
/* report the sum of the sizes (in bytes) of all segments */
cairo_surface_t *surface = o-surface;
int height = cairo_image_surface_get_height (surface);
int stride = cairo_image_surface_get_stride (surface);
- *lenp = height * stride;
+ *lenp = (Py_ssize_t) height * stride;
}
return 1; /* surface data is all in one segment */
}
+static
Bug#505714: handling of NMUs and reintroducing #505714
Hi Laurence, apologies for misspelling your name in my communication of this bug report. Nonetheless I would suggest to not drop the security bug fix for #505714. Generally, it might be a good idea to make a habit out of incorporating NMUs as per Developer's Reference 5.11.6. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505714: handling of NMUs and reintroducing #505714
# nitpicking the version tracking for Daniel Holbach's reference :)... found 505714 1.4.2-1 fixed 505714 1.4.2-2 thanks Hi, Thanks for the quick fix! Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi,
Luk Claes wrote:
Thanks for looking into this! Uploaded ghostscript 8.62.dfsg.1-3.2.
unblocked
Please allow me the liberty of proposing the attached NMU for fixing
#503712 (and opportunistically #510691 now that we know, but I've left
all other dependency stuff out).
If considered desirable, it would be nice if someone could sponsor this.
Packages are available[1].
Kind regards
T.
1. http://vman.de/debian/
--
Thomas Viehmann, http://thomas.viehmann.net/
diff -u ghostscript-8.62.dfsg.1/debian/control ghostscript-8.62.dfsg.1/debian/control
--- ghostscript-8.62.dfsg.1/debian/control
+++ ghostscript-8.62.dfsg.1/debian/control
@@ -121,7 +121,7 @@
Package: libgs-dev
Section: libdevel
Architecture: any
-Depends: ${shlibs:Depends}, libgs8
+Depends: ${shlibs:Depends}, libgs8 (= ${binary:Version})
Conflicts: libgs-esp-dev ( 8.62)
Replaces: libgs-esp-dev ( 8.62)
Provides: libgs-esp-dev
diff -u ghostscript-8.62.dfsg.1/debian/changelog ghostscript-8.62.dfsg.1/debian/changelog
--- ghostscript-8.62.dfsg.1/debian/changelog
+++ ghostscript-8.62.dfsg.1/debian/changelog
@@ -1,3 +1,14 @@
+ghostscript (8.62.dfsg.1-3.2lenny0) testing; urgency=low
+
+ * Non-maintainer upload to testing, mainly to get fix
+from 8.62.dfsg.1-3.2:
+- Make ghostscript depend on gs-common to prevent removal.
+ Drop gs-common - ghostscript-x dependency to not force the
+ X version on all users. Hopefully Closes: #503712.
+ * libgs-dev: version Depends: libgs8. Closes: #510691.
+
+ -- Thomas Viehmann t...@beamnet.de Mon, 05 Jan 2009 23:33:33 +0100
+
ghostscript (8.62.dfsg.1-3.2) unstable; urgency=low
* Non-maintainer upload.
Bug#510234: closed by Wolfram Quester wo...@sigxcpu.org (Bug#510234: fixed in inkscape 0.46-2.lenny2)
Hi Wolfram (and Salvatore), thanks for the quick fix and the effort to bring it into lenny! Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510225: RM: gtkfontsel -- RoQA; dead upstream, orphaned, gtk1.2, buggy
On 2009-01-02 11:01:52.00 Ingo Saitz ingo.sa...@stud.uni-hannover.de wrote: On Tue, Dec 30, 2008 at 12:22:57PM -0500, Barry deFreese wrote: Popcon is fairly high but while working on a patch to build it with Gtk2, I got in contact with the upstream developer who thinks it should no longer be needed and he has certainly done no development on it recently. (In the last 10 years in his words). I'd like to question that decision. If the package has a high popcon rating, there clearly IS demand from people. Maybe the author does not have any use for it anymore, but that is no reason to deny any use of the package. I'm afraid that I must have missed a few details of your plan w.r.t. gtkfontsel: - Who is going to maintain the Debian package? - Who is going to take over upstream development? - Who is going to port to gtk1.2 very soon? For reference: - the package has been orphaned for a year, - no-one stepped up to maintain it, - upstream is no longer interested, - it has bugs, - we are not keeping gtk1.2 post-lenny. Mind you, maybe the typical ways of configuring applications using fonts have advanced beyond needing a nice utility for browsing, previewing and selecting an X11 font to insert its correct name via the X clipboard into a configuration file. Kind regards T. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509861: RM of katapult: nosense
Martin Meredith wrote: CC:ing release list and my sponsor. (ftp team should already be notified) Are you sure you did that, I can't find the CC in the bug copy. Francois, will you re-upload this for me once I find where I've stored the package? (It's on a backup drive somewhere from when I had to reinstall?) Release Team, as this has already been in testing, and will be the same package, can you allow this to be pushed through to unstable? This is, of course, entirely up to the release team. Unless that is, the ftp team have some magic way of undoing the removal? No magic here. What your sponsor (or anyone with login to Debian machines) can do, though, is grab the version /org/ftp.debian.org/morgue/pool/2008-12-31/katapult_0.3.2.2-1.dsc and bump the version and upload that (*including* the source tarball!). Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504340: djvulibre-plugin/testing and #504340
Leon Bottou wrote:
On Monday 29 December 2008 18:39:17 Thomas Viehmann wrote:
Hi,
So here is something even better (IMHO): Change map_lookup to return the
return value (note that this would be funny if we stored NULLs in the
Ok. I am doing that upstream.
This is the best way to avoid the pitfalls of the ANSI C strict aliasing
rules.
These stupid rules basically prevent us from accessing
an arbitrary pointer using a void* type.
I wonder why they did not handle the case of void* pointers
in the rules. I did not find any explanation online...
The curse of post-midnight sending patches had me attach a broken
version, though, because I had only updated the binaries after the
initial compile.
Sorry about all the ill attempts, here is the hopefully final thing.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
--- djvulibre-3.5.20/debian/changelog
+++ djvulibre-3.5.20/debian/changelog
@@ -1,3 +1,13 @@
+djvulibre (3.5.20-8+lenny1) testing; urgency=low
+
+ * Non-maintainer upload.
+ * gui/nsdejavu/nsdejavu.c: Don't assume NPP_SetWindow is
+alsways passed good data. Patch from upstream.
+Make map_lookup return the result instead of an error code.
+Closes: #504340
+
+ -- Thomas Viehmann t...@beamnet.de Tue, 30 Dec 2008 00:11:49 +0100
+
djvulibre (3.5.20-8+lenny0) testing; urgency=low
* Non-maintainer upload to testing.
--- djvulibre-3.5.20.orig/gui/nsdejavu/nsdejavu.c
+++ djvulibre-3.5.20/gui/nsdejavu/nsdejavu.c
@@ -815,8 +815,8 @@
m-nbuckets = new_nbuckets;
}
-static int
-map_lookup(Map *m, void *key, void *pval)
+static void*
+map_lookup(Map *m, void *key)
{
int h;
struct map_entry_s *q;
@@ -824,12 +824,10 @@
h = hash(key, m-nbuckets);
for (q=m-buckets[h]; q; q=q-next)
if (q-key == key) {
-if (pval)
- *(void**)pval = q-val;
-return 1;
+return q-val;
}
}
- return -1;
+ return NULL;
}
static int
@@ -1167,12 +1165,12 @@
switch(reqp-req_num)
{
case CMD_SHOW_STATUS:
- if (map_lookup(instance, reqp-id, inst) = 0)
+ if ((inst = map_lookup(instance, reqp-id)))
if (inst-widget)
NPN_Status(inst-np_instance, reqp-status);
break;
case CMD_GET_URL:
- if (map_lookup(instance, reqp-id, inst) = 0)
+ if ((inst = map_lookup(instance, reqp-id)))
{
const char *target = (reqp-target reqp-target[0])
? reqp-target : 0;
@@ -1180,7 +1178,7 @@
}
break;
case CMD_GET_URL_NOTIFY:
- if (map_lookup(instance, reqp-id, inst) = 0)
+ if ((inst = map_lookup(instance, reqp-id)))
{
const char *target = (reqp-target reqp-target[0])
? reqp-target : 0;
@@ -1297,7 +1295,7 @@
{
Instance *inst;
void *id = (void*)cl_data;
- if (map_lookup(instance, id, inst) = 0)
+ if ((inst = map_lookup(instance, id)))
if (Resize(id) = 0)
ProgramDied();
}
@@ -1325,7 +1323,7 @@
Instance *inst;
void *id = (void*)cl_data;
*cont = True;
- if (map_lookup(instance, id, inst) = 0)
+ if ((inst = map_lookup(instance, id)))
{
Widget wid = inst-widget;
Display *dpy = XtDisplay(wid);
@@ -1567,7 +1565,7 @@
resizeCallback here and send the appropriate request to the
application */
Instance *inst;
- if (map_lookup(instance, id, inst) 0)
+ if (! (inst = map_lookup(instance, id)))
return 1;
if (inst-widget)
{
@@ -1591,7 +1589,7 @@
Detach(void * id)
{
Instance *inst;
- if (map_lookup(instance, id, inst) 0)
+ if (! (inst = map_lookup(instance, id)))
return 1;
if (inst-widget)
{
@@ -1630,7 +1628,7 @@
XColor cell;
XSync(displ, False);
- if (map_lookup(instance, id, inst) 0)
+ if (! (inst = map_lookup(instance, id)))
return 1;
widget = XtWindowToWidget(displ, window);
@@ -1968,7 +1966,7 @@
goto problem;
if (ReadPointer(pipe_read, id, 0, 0) = 0)
goto problem;
- if (map_lookup(instance, id, inst) = 0)
+ if ((inst = map_lookup(instance, id)))
/* This can happen because we do not clear
the instance array when restarting djview.
We just undo it... */
@@ -1988,7 +1986,7 @@
void * id = np_inst-pdata;
SavedData saved_data;
- if (map_lookup(instance, id, inst) 0)
+ if (! (inst = map_lookup(instance, id)))
return NPERR_INVALID_INSTANCE_ERROR;
/* Detach the main window, if not already detached */
NPP_SetWindow(np_inst, 0);
@@ -2035,7 +2033,7 @@
void * id = np_inst-pdata;
Window cur_window, new_window;
- if (map_lookup(instance, id, inst) 0)
+ if (! (inst = map_lookup(instance, id)))
return NPERR_INVALID_INSTANCE_ERROR;
cur_window = inst-window;
new_window = (win_str) ? (Window) win_str-window : 0;
@@ -2054,9 +2052,9 @@
}
if (new_window)
{
- NPSetWindowCallbackStruct
Bug#510234: inkscape: don't terminate on bad utf8(?) in pdf import
Hi Wolfram, thanks for the superquick response! Wolfram Quester wrote: OK, so you suggest we tru to make an 0.46-5 with this patch included and try to get it into Lenny? I'll try to do it, but I can't promise I get it right in time... This is really up to you, I don't really see it as RC in the Debian sense, OTOH if you want the fix for lenny, I'll be happy, too. I've put the bug as important (vs. normal) because it causes inkscape to terminate abruptly, but being personally annoyed by the bug to the point I tracked it down I don't think I'm in a position to declare it critical, so if you think it's just a random bug to be fixed whenever you do the next upload, so be it. I must admit I'm too lazy to send it upstream directly, so if you happen to talk to them anyways, it might more important to see if they have opinions about the bug than pestering the release team. Kind regards and thanks again for your work, T. P.S.: If I may venture an unrelated suggestion: replacing the patch perquisite of the config.status target by patch-stamp seems to avoid calling configure every time when doing multiple fakeroot debian/rules binary in a row as a means of debugging a problem. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: ghostscript: diff for NMU version 8.62.dfsg.1-3.2
tags 503712 + patch pending
thanks
Hi everyone,
so here is the NMU diff for ghostscript 8.62.dfsg.1-3.2 that I'm
uploading.
It is functionally identical to the proposed dependency change,
I just fixed the versioning and added a closes to the changelog.
Thanks to all bug commenters and Adeodato and Cyril comments on IRC.
Note that this is still not ideal (i.e. a user manually causing
gs-common to be uninstalled), but it seems that the dependency change
is strictly better than the .config hack and that it covers automatic
updates (as long as packages conflicting with gs-common are added),
but seems to be about as far as we get. When testing with Niko's
instructions for reproducing the problem ghostscript pulls in the
newer gs-common as expected and the upgrade seems to work.
Kind regards
T.
diff -u ghostscript-8.62.dfsg.1/debian/control
ghostscript-8.62.dfsg.1/debian/control
--- ghostscript-8.62.dfsg.1/debian/control
+++ ghostscript-8.62.dfsg.1/debian/control
@@ -10,10 +10,10 @@
Architecture: any
Conflicts: gs ( 8.62), gs-esp ( 8.62), gs-gpl ( 8.62), gs-afpl (
8.62), gs-aladdin ( 8.62), gs-cjk-resource ( 1.20010910-1), gs-pdfencrypt
( 7.00), gs-common ( 8.62)
Replaces: gs ( 8.62), gs-esp ( 8.62), gs-gpl ( 8.62), gs-afpl ( 8.62),
gs-aladdin ( 8.62), gs-pdfencrypt ( 7.00), gs-common ( 8.62)
-Provides: gs-pdfencrypt, postscript-viewer, gs-common
+Provides: gs-pdfencrypt, postscript-viewer
Recommends: psfontmgr
Suggests: ghostscript-x, hpijs
-Depends: ${shlibs:Depends}, gsfonts (= 6.0-1), defoma, debconf | debconf-2.0,
debianutils (= 1.6), libgs8 (= ${binary:Version})
+Depends: ${shlibs:Depends}, gs-common (= 8.62.dfsg.1-3.2), gsfonts (=
6.0-1), defoma, debconf | debconf-2.0, debianutils (= 1.6), libgs8 (=
${binary:Version})
Description: The GPL Ghostscript PostScript/PDF interpreter
Ghostscript is used for PostScript/PDF preview and printing. Usually as
a back-end to a program such as ghostview, it can display PostScript and PDF
@@ -65,12 +65,11 @@
Package: gs-common
Architecture: all
-Priority: extra
-Depends: ghostscript, ghostscript-x
-Description: Transitional package
+Priority: optional
+Depends: ghostscript
+Description: Dummy package depending on ghostscript
This dummy package is provided for a smooth transition from the
previous gs-.../gs-common combo (the packages are replaced by ghostscript).
- It may safely be removed after installation.
Package: ghostscript-x
Architecture: any
diff -u ghostscript-8.62.dfsg.1/debian/changelog
ghostscript-8.62.dfsg.1/debian/changelog
--- ghostscript-8.62.dfsg.1/debian/changelog
+++ ghostscript-8.62.dfsg.1/debian/changelog
@@ -1,3 +1,12 @@
+ghostscript (8.62.dfsg.1-3.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Make ghostscript depend on gs-common to prevent removal.
+Drop gs-common - ghostscript-x dependency to not force the
+X version on all users. Hopefully Closes: #503712.
+
+ -- Thomas Viehmann t...@beamnet.de Sun, 28 Dec 2008 11:18:18 +0100
+
ghostscript (8.62.dfsg.1-3.1) unstable; urgency=medium
* Non-maintainer upload.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Adeodato Simó wrote: * Thomas Viehmann [Sun, 28 Dec 2008 21:10:36 +0100]: As promised on IRC, the only way to end the madness of my mails on the subject is to either say no, no dependency funnies, we want .config hacks or fixing dependencies is better than .config hacks, or something entirely different 22:04 dato tomv_w: if both options work, I also lean towards the dependency on gs-common Thanks for looking into this! Uploaded ghostscript 8.62.dfsg.1-3.2. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504340: djvulibre-plugin/testing and #504340
Hi,
Adeodato Simó wrote:
How about using O2 for the plugin (or generally)?
22:08 dato tomv_w: and let's go for -O2 in djvulibre; for only the plugin
if
that's enough
So here is something even better (IMHO): Change map_lookup to return the
return value (note that this would be funny if we stored NULLs in the
hash table, but we actually don't). This avoids the pointer-type-funnies
in map_lookup altogether and works in my testing. Granted, the diff has
a couple of lines more, but it is very straightforward.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
diff -u djvulibre-3.5.20/debian/changelog djvulibre-3.5.20/debian/changelog
--- djvulibre-3.5.20/debian/changelog
+++ djvulibre-3.5.20/debian/changelog
@@ -1,3 +1,13 @@
+djvulibre (3.5.20-8+lenny1) testing; urgency=low
+
+ * Non-maintainer upload.
+ * gui/nsdejavu/nsdejavu.c: Don't assume NPP_SetWindow is
+alsways passed good data. Patch from upstream.
+Make map_lookup return the result instead of an error code.
+Closes: #504340
+
+ -- Thomas Viehmann t...@beamnet.de Tue, 30 Dec 2008 00:11:49 +0100
+
djvulibre (3.5.20-8+lenny0) testing; urgency=low
* Non-maintainer upload to testing.
only in patch2:
unchanged:
--- djvulibre-3.5.20.orig/gui/nsdejavu/nsdejavu.c
+++ djvulibre-3.5.20/gui/nsdejavu/nsdejavu.c
@@ -815,8 +815,8 @@
m-nbuckets = new_nbuckets;
}
-static int
-map_lookup(Map *m, void *key, void *pval)
+static void*
+map_lookup(Map *m, void *key)
{
int h;
struct map_entry_s *q;
@@ -825,11 +825,10 @@
for (q=m-buckets[h]; q; q=q-next)
if (q-key == key) {
if (pval)
- *(void**)pval = q-val;
-return 1;
+ return q-val;
}
}
- return -1;
+ return NULL;
}
static int
@@ -1167,12 +1166,12 @@
switch(reqp-req_num)
{
case CMD_SHOW_STATUS:
- if (map_lookup(instance, reqp-id, inst) = 0)
+ if (inst = map_lookup(instance, reqp-id))
if (inst-widget)
NPN_Status(inst-np_instance, reqp-status);
break;
case CMD_GET_URL:
- if (map_lookup(instance, reqp-id, inst) = 0)
+ if (inst = map_lookup(instance, reqp-id))
{
const char *target = (reqp-target reqp-target[0])
? reqp-target : 0;
@@ -1180,7 +1179,7 @@
}
break;
case CMD_GET_URL_NOTIFY:
- if (map_lookup(instance, reqp-id, inst) = 0)
+ if (inst = map_lookup(instance, reqp-id))
{
const char *target = (reqp-target reqp-target[0])
? reqp-target : 0;
@@ -1297,7 +1296,7 @@
{
Instance *inst;
void *id = (void*)cl_data;
- if (map_lookup(instance, id, inst) = 0)
+ if (inst = map_lookup(instance, reqp-id))
if (Resize(id) = 0)
ProgramDied();
}
@@ -1325,7 +1324,7 @@
Instance *inst;
void *id = (void*)cl_data;
*cont = True;
- if (map_lookup(instance, id, inst) = 0)
+ if (inst = map_lookup(instance, reqp-id))
{
Widget wid = inst-widget;
Display *dpy = XtDisplay(wid);
@@ -1567,7 +1566,7 @@
resizeCallback here and send the appropriate request to the
application */
Instance *inst;
- if (map_lookup(instance, id, inst) 0)
+ if (! inst = map_lookup(instance, reqp-id))
return 1;
if (inst-widget)
{
@@ -1591,7 +1590,7 @@
Detach(void * id)
{
Instance *inst;
- if (map_lookup(instance, id, inst) 0)
+ if (! inst = map_lookup(instance, reqp-id))
return 1;
if (inst-widget)
{
@@ -1630,7 +1629,7 @@
XColor cell;
XSync(displ, False);
- if (map_lookup(instance, id, inst) 0)
+ if (! inst = map_lookup(instance, reqp-id))
return 1;
widget = XtWindowToWidget(displ, window);
@@ -1968,7 +1967,7 @@
goto problem;
if (ReadPointer(pipe_read, id, 0, 0) = 0)
goto problem;
- if (map_lookup(instance, id, inst) = 0)
+ if (inst = map_lookup(instance, id))
/* This can happen because we do not clear
the instance array when restarting djview.
We just undo it... */
@@ -1988,7 +1987,7 @@
void * id = np_inst-pdata;
SavedData saved_data;
- if (map_lookup(instance, id, inst) 0)
+ if (! inst = map_lookup(instance, id))
return NPERR_INVALID_INSTANCE_ERROR;
/* Detach the main window, if not already detached */
NPP_SetWindow(np_inst, 0);
@@ -2035,7 +2034,7 @@
void * id = np_inst-pdata;
Window cur_window, new_window;
- if (map_lookup(instance, id, inst) 0)
+ if (! inst = map_lookup(instance, id))
return NPERR_INVALID_INSTANCE_ERROR;
cur_window = inst-window;
new_window = (win_str) ? (Window) win_str-window : 0;
@@ -2054,9 +2053,9 @@
}
if (new_window)
{
- NPSetWindowCallbackStruct *cbs
-= (NPSetWindowCallbackStruct *) win_str-ws_info;
- Display * displ=cbs-display;
+ Display *displ = 0;
+ if (NPN_GetValue(np_inst, NPNVxDisplay
Bug#503712: the gs-common problem
Hi Sylvain, thanks for your comments! Sylvain Beucler wrote: For the latter, it would be cool if the maintainers of the affected packages, Vincent for latex-make Sylvain and David for page-crunch the Zope guys and Andreas and Fabio for zope-textindexng3 could weigh in here. I'll look at your packages, but if you already know whether it works without ghostscript-x or not, it'd be great if you could give me a shout. page-crunch depends on gs-common for 'pdf2ps' and 'ps2pdf'. From what I understand we can replace 'gs-common' with 'ghostscript'. Do you want to sponsor a new package release? Thanks for offering to prepare an update. The idea is to not change reverse dependencies at this point but to reduce gs-common to only include ghostscript and not ghostscript-x, so your package would be fine depending on gs-common. All the best for the new year. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Thomas Viehmann wrote:
So this is how an NMU choosing the include hack in .config route would
look like.
I'm not quite convinced that this is actually better than having
ghosscript depend on gs-common, gs-common not depend on ghostscript-x
and checking the reverse (build-)depends for breakage.
So build logs for (all but the one contrib) reverse build depends are
at[1]. All seem to succeed, two seem to build-depend indirectly
ghostscript-x (via transfig via gs-gpl, latex-mk via transfig).
I'll check the debs somewhat, too, but if we think that ghostscript
depending on gs-common and living with the circular depends solves the
problem, this might be a more conservative way to fix this for lenny.
Two maintainers of reverse dependencies have replied already that their
packages don't need ghostscript-x, leaving one with some breakage potential.
Given that there are two possible vectors with more-or-less
ready-to-upload packages, we should want to decide this soonish.
I'm leaning towards the dependency change a bit. Note that ghostscript
seems to be the only package conflicting with gs-common.
Kind regards
T.
1.
http://people.debian.org/~tviehmann/building-with-gs-common-not-depending-on-ghostscript-x/
--
Thomas Viehmann, http://thomas.viehmann.net/
diff -u ghostscript-8.62.dfsg.1/debian/control ghostscript-8.62.dfsg.1/debian/control
--- ghostscript-8.62.dfsg.1/debian/control
+++ ghostscript-8.62.dfsg.1/debian/control
@@ -10,10 +10,10 @@
Architecture: any
Conflicts: gs ( 8.62), gs-esp ( 8.62), gs-gpl ( 8.62), gs-afpl ( 8.62), gs-aladdin ( 8.62), gs-cjk-resource ( 1.20010910-1), gs-pdfencrypt ( 7.00), gs-common ( 8.62)
Replaces: gs ( 8.62), gs-esp ( 8.62), gs-gpl ( 8.62), gs-afpl ( 8.62), gs-aladdin ( 8.62), gs-pdfencrypt ( 7.00), gs-common ( 8.62)
-Provides: gs-pdfencrypt, postscript-viewer, gs-common
+Provides: gs-pdfencrypt, postscript-viewer
Recommends: psfontmgr
Suggests: ghostscript-x, hpijs
-Depends: ${shlibs:Depends}, gsfonts (= 6.0-1), defoma, debconf | debconf-2.0, debianutils (= 1.6), libgs8 (= ${binary:Version})
+Depends: ${shlibs:Depends}, gs-common (= 8.62.dfsg.1-3.2b), gsfonts (= 6.0-1), defoma, debconf | debconf-2.0, debianutils (= 1.6), libgs8 (= ${binary:Version})
Description: The GPL Ghostscript PostScript/PDF interpreter
Ghostscript is used for PostScript/PDF preview and printing. Usually as
a back-end to a program such as ghostview, it can display PostScript and PDF
@@ -65,12 +65,11 @@
Package: gs-common
Architecture: all
-Priority: extra
-Depends: ghostscript, ghostscript-x
-Description: Transitional package
+Priority: optional
+Depends: ghostscript
+Description: Dummy package depending on ghostscript
This dummy package is provided for a smooth transition from the
previous gs-.../gs-common combo (the packages are replaced by ghostscript).
- It may safely be removed after installation.
Package: ghostscript-x
Architecture: any
diff -u ghostscript-8.62.dfsg.1/debian/changelog ghostscript-8.62.dfsg.1/debian/changelog
--- ghostscript-8.62.dfsg.1/debian/changelog
+++ ghostscript-8.62.dfsg.1/debian/changelog
@@ -1,3 +1,12 @@
+ghostscript (8.62.dfsg.1-3.2b) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Make ghostscript depend on gs-common to prevent removal.
+Drop gs-common - ghostscript-x dependency to not force the
+X version on all users.
+
+ -- Thomas Viehmann t...@beamnet.de Sun, 28 Dec 2008 11:18:18 +0100
+
ghostscript (8.62.dfsg.1-3.1) unstable; urgency=medium
* Non-maintainer upload.
Bug#503712: the gs-common problem
As promised on IRC, the only way to end the madness of my mails on the subject is to either say no, no dependency funnies, we want .config hacks or fixing dependencies is better than .config hacks, or something entirely different, so here is some more data: Thomas Viehmann wrote: I'll check the debs somewhat, too, but if we think that ghostscript depending on gs-common and living with the circular depends solves the problem, this might be a more conservative way to fix this for lenny. Using debdiff, the only file differences (aside from a few shlibs bumps, ordering, and minor size differences, the control fields matched up) are - one pdf in one package (geda-symbols) changed the paper format and then dropped below the compression threshold (building in a chroot?), - the doc package of log4c had a couple of more symlinked manpages, apparently due to changes in the manpage generating tex file. So IMO dropping ghostscript-x from gs-common build-deps looks reasonably safe as in not changing anything rebuild-wise. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504340: djvulibre-plugin/testing and #504340
Hi Leon, thanks for the excellent analysis. Leon Bottou wrote: Finally I would also try to reduce the plugin optimization level from -O3 to -O2, just to see if improvements appear. This is another difference between Bastien's experiments (no crash, plugin compiled from djview4 source with -O2) and the distribution (crash, plugin compiled from djvulibre source with -O3)... O3 vs. O2 is crash vs. no crash. Something goes wrong with the testing of the return value when map_lookup is inlined. So my patch is bogus, sorry. How about using O2 for the plugin (or generally)? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi, Thomas Viehmann wrote: Niko Tyni wrote: Maybe configure script is badly worded: It's most blatant abuse, but I'd just stick it into a /var/lib/dpkg/info/ghostscript.config unless there are apt-get-lookalikes that don't call that at the beginning of an upgrade. If the user produces the bad situation with dpkg by himself, well, who cares. I see. It's blatant abuse indeed, but it might work. The preconfiguration only happens if debconf and apt-utils are installed (see /etc/apt/apt.conf.d/70debconf and /usr/sbin/dpkg-preconfigure), but according to popcon more than 99.8% of all installations have them. If this is the chosen approach, the script could as well fix the etch gs-common.prerm script instead of removing it; I think something like if md5sum --status --check EOF 1959479be1e513d94a22f6fad8227fa3 /var/lib/dpkg/info/gs-common.prerm EOF then sed -i 's/defoma-app -t \(purge\|clean\) gs$/ || true/' \ /var/lib/dpkg/info/gs-common.prerm || true fi should do. So this is how an NMU choosing the include hack in .config route would look like. I'm not quite convinced that this is actually better than having ghosscript depend on gs-common, gs-common not depend on ghostscript-x and checking the reverse (build-)depends for breakage. I might investigate that option in some more detail, too, but now we have an NMU option from the gross hack that works for many situations department. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ diff -u ghostscript-8.62.dfsg.1/debian/changelog ghostscript-8.62.dfsg.1/debian/changelog --- ghostscript-8.62.dfsg.1/debian/changelog +++ ghostscript-8.62.dfsg.1/debian/changelog @@ -1,3 +1,14 @@ +ghostscript (8.62.dfsg.1-3.2) unstable; urgency=low + + * Non-maintainer upload. + * Gross hack: Add debian/ghostscript.config that attempts to fix +(etch) gs-common.prerm. This also necessitates the (otherwise +useless) ghostscript.templates. +Original idea from apache2-apache2.2, +details by Niko Tyni, bugs my own. Closes: #503712 + + -- Thomas Viehmann t...@beamnet.de Sat, 27 Dec 2008 20:58:00 +0100 + ghostscript (8.62.dfsg.1-3.1) unstable; urgency=medium * Non-maintainer upload. only in patch2: unchanged: --- ghostscript-8.62.dfsg.1.orig/debian/ghostscript.templates +++ ghostscript-8.62.dfsg.1/debian/ghostscript.templates @@ -0,0 +1,5 @@ +Template: ghostscript/dummy +Type: text +Description: Dummy template + to facilitate hack in ghostscript.config. + only in patch2: unchanged: --- ghostscript-8.62.dfsg.1.orig/debian/ghostscript.config +++ ghostscript-8.62.dfsg.1/debian/ghostscript.config @@ -0,0 +1,13 @@ +#!/bin/sh + +set -e + +# This is one gross hack, do not imitate. See bug #503712 for details. + +md5sum=$(md5sum /var/lib/dpkg/info/gs-common.prerm 2/dev/null | cut -f1 -d' ' || true ) +case $md5sum in +1959479be1e513d94a22f6fad8227fa3|7246294e40219cc849738edf49c1c852|0a6bfb6322d636faf08752d6427150c2) +sed -i 's/defoma-app -t \(purge\|clean\) gs$/ || true/' \ + /var/lib/dpkg/info/gs-common.prerm || true +;; +esac
Bug#503712: the gs-common problem
Hi, Niko Tyni wrote: Maybe configure script is badly worded: It's most blatant abuse, but I'd just stick it into a /var/lib/dpkg/info/ghostscript.config unless there are apt-get-lookalikes that don't call that at the beginning of an upgrade. If the user produces the bad situation with dpkg by himself, well, who cares. I see. It's blatant abuse indeed, but it might work. The preconfiguration only happens if debconf and apt-utils are installed (see /etc/apt/apt.conf.d/70debconf and /usr/sbin/dpkg-preconfigure), but according to popcon more than 99.8% of all installations have them. If this is the chosen approach, the script could as well fix the etch gs-common.prerm script instead of removing it; I think something like if md5sum --status --check EOF 1959479be1e513d94a22f6fad8227fa3 /var/lib/dpkg/info/gs-common.prerm EOF then sed -i 's/defoma-app -t \(purge\|clean\) gs$/ || true/' \ /var/lib/dpkg/info/gs-common.prerm || true fi should do. Barring objections, I'll test things and NMU along the lines Niko indicated on Sunday. Thanks to everyone for weighing in on the bug report. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi everyone, you have been involved in #503712 so it's been a while since the last activity here. contrary to Niko's last mail I propose to live with a circular dependency and - make ghostscript depend on gs-common ( -3.2 to be uploaded) - make gs-common NOT depend on ghostscript-x unless there is a compelling reason not to (i.e. massive breakage would a reason, that gs-common then will have to stay installed for lenny is not, the circular dependency in itself isn't, but if it causes problems...). IMO a single excess package is not that bad compared to requiring attention during an upgrade. I will check whether this is a problem for the reverse build-dependencies and dependencies. For the latter, it would be cool if the maintainers of the affected packages, Vincent for latex-make Sylvain and David for page-crunch the Zope guys and Andreas and Fabio for zope-textindexng3 could weigh in here. I'll look at your packages, but if you already know whether it works without ghostscript-x or not, it'd be great if you could give me a shout. Happy holidays and kind regards T. P.S.: When you reply, you might want to drop part of the CC madness. :) -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi again, immediately after I sent the last mail, Sune Vuorela pointed me to apache2's fix for #390823: They simply remove the problematic maintainer script. The question then is where to do this in so it is reliably done before stuff happens. In one of the perl packages (because the upgrade of perl triggers this) is probably too ugly, maybe the configure script of ghostscript? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
