Bug#785300: xul-ext-pentadactyl: pentadactyl not compatible with iceweasel 38.0-1
Hi, On Thu, Aug 27, 2015 at 07:17:16AM -0400, David Prévot wrote: Whatever way you wish to follow, can you please take action now? “The next point release […] is scheduled for Saturday, September 5th. Processing of new uploads into jessie-proposed-updates will be frozen during the preceding weekend.” [0] Good point! Filed as #797072. Cheers, Michael
Bug#785300: xul-ext-pentadactyl: pentadactyl not compatible with iceweasel 38.0-1
Hey, I'm afraid that an update of dactyl in Jessie is unrealistic. Finding and backporting the compatibility-relevant changes is non-trivial to say the least. The diffs I had to import from the upstream repository to make it even start up amount to around 3000 changed lines, and even then most functionality does not work. It looks to me like a removal from stable is once again the most reasonable thing to do (this already happened once in wheezy), which I am going to call for if there are no objections within the next few days. (With the way Iceweasel security updates are dealt with these days, I'm beginning to doubt that a complex add-on like Pentadactyl is even worth maintaining in Debian at all.) Cheers, Michael
Bug#750032: [Pkg-mozext-maintainers] Bug#750359: Changes for the NMU
Hi Don, On Sun, Jun 15, 2014 at 06:09:57PM -0700, Don Armstrong wrote: The changes for this NMU are available from http://git.donarmstrong.com/dactyl.git If a different format would be more useful, let me know. Thank you very much for your assistance! The diff is okay like that. Best, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724070: python-docutils: FTBFS: Test failure in test_raw_url
severity 724070 normal tags 724070 - unreproducible retitle 724070 python-docutils: FTBFS: test_raw_url fails in case of NXDOMAIN DNS hijacking thanks Hey, On Wed, Sep 25, 2013 at 09:09:51AM -0700, Daniel Schepler wrote: It turns out my setting of preferences to opt out of broken redirection of nonexistent host names to a web search (HTTP only) had expired again. When I re-disabled it to fix DNS to properly return host not found errors, the build failure went away. So, feel free to downgrade the severity of this bug. Ugh, this nonsense. Thank you for the analysis; perhaps use of a .invalid domain will solve the issue. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724070: python-docutils: FTBFS: Test failure in test_raw_url
Hello Daniel, On Sun, Sep 22, 2013 at 10:55:53AM -0700, Daniel Schepler wrote: From my pbuilder build log: ... test_parsers/test_rst/test_directives/test_replace.py: totest['replace'][3]; test_parser (DocutilsTestSupport.ParserTestCase) ... ok test_parsers/test_rst/test_directives/test_replace.py: totest['replace'][4]; test_parser (DocutilsTestSupport.ParserTestCase) ... ok test_parsers/test_rst/test_directives/test_replace.py: totest['replace'][5]; test_parser (DocutilsTestSupport.ParserTestCase) ... ok == FAIL: test_raw_url (test_error_reporting.ErrorReportingTests) -- Traceback (most recent call last): File /tmp/buildd/python-docutils-0.11/test/test_error_reporting.py, line 324, in test_raw_url self.parser.parse, source, self.document) AssertionError: SystemMessage not raised -- Thank you for the report. Unfortunately I cannot reproduce this issue in a sid pbuilder chroot on amd64, even when no network interfaces are configured. Is there anything particular about the environment you're building in? Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721092: xul-ext-pentadactyl is incompatible with iceweasel
On Tue, Sep 10, 2013 at 11:42:19AM +0200, Michael Schutte wrote: You're right, and I'm afraid a removal does seem like the only feasible option to me. Request filed as #722884. Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721092: [Pkg-mozext-maintainers] Bug#721092: xul-ext-pentadactyl is incompatible with iceweasel
Hey David, On Mon, Sep 09, 2013 at 04:30:06PM -0400, David Prévot wrote: -BEGIN PGP SIGNED MESSAGE- Le 09/09/2013 06:25, Michael Schutte a écrit : Meanwhile, updating dactyl through stable-security is also not a possibility It may not be welcome, but it already happened for at least enigmail and adblockplus. In the mean time, the release team already accepted a bunch of minimal patches that allow some extensions to work in both stable-security and the current stable (at least a more invasive one has been proposed for firetray, and has not yet been rejected). Ah, I didn't know there was a precendent even for non-essential extensions. I'm afraid that Pentadactyl is a much trickier case; there is no release supporting 17.*, I'm not comfortable with uploading a revision from the upstream VCS to stable, and even a minimal patch would be an invasive mess. As 24.0 ESR is scheduled to be released next week it would be silly not to keep it in mind as well, and that situation is even worse. If there are no objections I'm therefore going to downgrade the severity of #721092, tag it wontfix and leave it for posterity. I would strongly disagree (SC#3 We will not hide problems), if dactyl happen to be broken in stable and no fix can address that, the package should be removed from stable. You're right, and I'm afraid a removal does seem like the only feasible option to me. Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720447: [Pkg-mozext-maintainers] Bug#721092: xul-ext-pentadactyl is incompatible with iceweasel
Hi! On Sun, Sep 08, 2013 at 03:30:45PM -0400, David Prévot wrote: It looks like xul-ext-pentadactyl is broken in both stable and unstable. Michael, can you please push your last changes into Git? Can you also have a look at this issue, the window for next stable update will close really soon. I'm on it for unstable (#720447). As far as stable (#721092) goes, I think that an upgrade through a point release is not the right approach because xul-ext-pentadactyl is in fact compatible with iceweasel in stable; the problem is with the version of iceweasel in stable-security, which can change again at any point in the future, breaking xul-ext-pentadactyl anew. Meanwhile, updating dactyl through stable-security is also not a possibility, at least judging by http://thread.gmane.org/gmane.linux.debian.devel.general/183487. In addition to all this, there hasn't been an upstream release of Pentadactyl in more than a year and the most recent version also doesn't support Fx/Iceweasel 17. I very much doubt that a patched version of 1.0 for the next point release is worth the trouble or even a good idea. If there are no objections I'm therefore going to downgrade the severity of #721092, tag it wontfix and leave it for posterity. I might also upload an updated version to wheezy-backports. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697065: ticgit fails with Inappropriate ioctl for device (Errno::ENOTTY)
Hi Wesley, hi Andrey,
thank you for bringing this bug to my attention.
On Mon, Dec 31, 2012 at 08:45:09AM -0700, Wesley J. Landaker wrote:
I just tried installing and using ticgit on unstable. Here is the
result:
$ ti
/usr/lib/ruby/vendor_ruby/ticgit-ng/cli.rb:156:in `ioctl': Inappropriate
ioctl for device (Errno::ENOTTY)
from /usr/lib/ruby/vendor_ruby/ticgit-ng/cli.rb:156:in `try_using'
from /usr/lib/ruby/vendor_ruby/ticgit-ng/cli.rb:145:in
`reset_window_width'
from /usr/lib/ruby/vendor_ruby/ticgit-ng/cli.rb:240
from /usr/lib/ruby/vendor_ruby/ticgit-ng.rb:37:in `require'
from /usr/lib/ruby/vendor_ruby/ticgit-ng.rb:37
from /usr/bin/ti:10:in `require'
from /usr/bin/ti:10
This error appears when attempting *any* ti subcommand.
I am able to reproduce the problem you are describing; whether or not it
occurs depends on the version of the kernel. I’m not convinced that
ticgit’s way of determining the size of the terminal (tentatively
calling ioctls) makes a lot of sense, so I’m probably going to make it
parse the output of stty instead.
Cheers,
--
Michael Schutte | michi@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670778: kdb: build-depends on gettext:any breaks the buildds
tags 670778 pending
thanks
Hi Kurt,
On Sat, Apr 28, 2012 at 11:06:15PM +0200, Kurt Roeckx wrote:
You added a build-depedency on gettext:any, and now no packages
are getting build as a result.
Ugh, of course; I blindly and stupidly applied the patch from #670653.
Reverting immediately.
Best,
--
Michael Schutte | michi@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506992: vtk: diff for NMU version 5.6.1-6.1
Hey,
I just uploaded vtk to DELAYED/0. Please see the attached nmudiff.
Cheers,
--
Michael Schutte | michi@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
diff -Nru vtk-5.6.1/debian/changelog vtk-5.6.1/debian/changelog
--- vtk-5.6.1/debian/changelog 2011-06-03 07:02:31.0 +0200
+++ vtk-5.6.1/debian/changelog 2011-08-22 07:07:12.0 +0200
@@ -1,3 +1,14 @@
+vtk (5.6.1-6.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Remove absolute paths to required libraries from
+/usr/lib/vtk-5.6/VTKLibraryDepends.cmake after building, closes:
+#506992. Due to the multiarch transition, the original behavior
+frequently causes reverse build-deps to FTBFS. This change should
+probably be reverted once all required libraries are multiarched.
+
+ -- Michael Schutte mi...@debian.org Mon, 22 Aug 2011 07:04:37 +0200
+
vtk (5.6.1-6) unstable; urgency=low
* VolumeRendering/vtkOpenGLGPUVolumeRayCastMapper.cxx:
diff -Nru vtk-5.6.1/debian/rules vtk-5.6.1/debian/rules
--- vtk-5.6.1/debian/rules 2011-02-22 03:54:32.0 +0100
+++ vtk-5.6.1/debian/rules 2011-08-22 07:04:18.0 +0200
@@ -121,6 +121,7 @@
if [ X$(DARTP) = XUSE_DART ]; then cd Build xvfb-run -s -screen 0 1024x768x24 $(MAKE) $(JOBS) Experimental; else cd Build $(MAKE) $(JOBS);fi
if [ X$(DARTP) = XUSE_DART ]; then cd Build $(MAKE) $(JOBS) ExperimentalSubmit; fi
+ sed -i -e s#/usr/lib/\(`dpkg-architecture -qDEB_HOST_MULTIARCH`/\)\?lib\([^;]*\)\.so#\2#g Build/VTKLibraryDepends.cmake
touch build-stamp
Bug#506992: vtk: diff for NMU version 5.6.1-6.1
On Mon, Aug 22, 2011 at 06:16:59PM +0200, Michael Schutte wrote:
I just uploaded vtk to DELAYED/0.
For the record, the updated package was rejected due to #638883.
All the best,
--
Michael Schutte | michi@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506992: Workaround for the *LibraryDepends.cmake issue
Hey,
On Sun, Aug 21, 2011 at 02:09:24PM +0200, Andreas Tille wrote:
if I uderstood Michael properly he just was waiting for confirmation of
testers, which is done hereby. So Michael it would be great if you
would go for a NMU (perhaps to delayed to enable mainteiners to insist).
I'm sitting behind a very slow connection currently.
I’ll take care of this tomorrow. ITK is a team effort anyway. VTK
maintainers: now it’s time to complain (or upload yourself) :-)
Cheers,
--
Michael Schutte | michi@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506992: Workaround for the *LibraryDepends.cmake issue
tags 506992 + patch
tags 635300 + pending
thanks
Hi everyone,
Yesterday I found some time to dive into the problem with full .so paths
in VTK and ITK, which currently cause frequent FTBFSes because of more
and more libraries moving down the directory hierarchy for multiarch. I
suggest this workaround for the issue: In debian/rules, run
sed -i -e s#/usr/lib/\(`dpkg-architecture
-qDEB_HOST_MULTIARCH`/\)\?lib\([^;]*\)\.so#\2#g \
$(path_to_library_depends)
after building. While I haven’t found a way to avoid getting the
absolute paths in the first place, CMake does manage to find libraries
in default locations. This isn’t pretty, but we can remove it again
after all required libraries are “multiarched” – particularly when VTK
and ITK undergo that transition themselves ;-)
The other fixes I tried, namely removing *LibraryDepends.cmake
altogether, and converting to another way to use CMake, sadly don’t work
satisfactorily. The former breaks some builds, the latter is a lot of
work and doesn’t fix the problem completely.
This one should be a low-maintenance solution, and AFAICT it works out
fine. I locally test-built ants, elastix, gdcm, ginkgocadx, gofigure2
and ifrit, all of which depend on libinsighttoolkit3-dev, libvtk5-dev or
both (there are more, but my machine is slow). The fix for ITK is
committed and ready to upload. For VTK, please try the attached patch.
Cheers,
--
Michael Schutte | michi@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
diff --git a/debian/rules b/debian/rules
index 8414100..df06a3d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -121,6 +121,7 @@ build-stamp: configure-stamp
if [ X$(DARTP) = XUSE_DART ]; then cd Build xvfb-run -s -screen 0 1024x768x24 $(MAKE) $(JOBS) Experimental; else cd Build $(MAKE) $(JOBS);fi
if [ X$(DARTP) = XUSE_DART ]; then cd Build $(MAKE) $(JOBS) ExperimentalSubmit; fi
+ sed -i -e s#/usr/lib/\(`dpkg-architecture -qDEB_HOST_MULTIARCH`/\)\?lib\([^;]*\)\.so#\2#g Build/VTKLibraryDepends.cmake
touch build-stamp
Bug#634548: vtkedge: FTBFS: make[3]: *** No rule to make target `/usr/lib/libGLU.so', needed by `bin/libVTKEdge.so'. Stop.
block 634548 by 506992
thanks
On Tue, Jul 19, 2011 at 08:31:01AM +0200, Lucas Nussbaum wrote:
make[3]: *** No rule to make target `/usr/lib/libGLU.so', needed by
`bin/libVTKEdge.so'. Stop.
This is because of the multiarch-capable directory structure in
libglu1-mesa, but the actual root of the problem are the full library
paths in libvtk5-dev, /usr/lib/vtk-5.6/VTKLibraryDepends.cmake. See
http://bugs.debian.org/506992 and others.
Cheers,
--
Michael Schutte | michi@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
signature.asc
Description: Digital signature
Bug#596351: ohai fails with: to_json: source sequence is illegal/malformed
Hi Christopher, On Fri, Sep 10, 2010 at 06:00:35PM +0200, Christopher Huhn, GSI wrote: Simply running ohai fails on my box with the following error: /usr/lib/ruby/1.8/json/common.rb:232:in `to_json': source sequence is illegal/malformed (JSON::GeneratorError) from /usr/lib/ruby/1.8/json/common.rb:232:in `pretty_generate' from /usr/lib/ruby/1.8/ohai/system.rb:222:in `json_pretty_print' from /usr/lib/ruby/1.8/ohai/application.rb:104:in `run_application' from /usr/lib/ruby/1.8/ohai/application.rb:75:in `run' from /usr/bin/ohai:47 I notice you are using an 8-bit charset; perhaps there is some non-UTF-8 data that might upset the JSON library. May I ask you the problem is still present when you run “LANG=C LC_ALL=C ohai”? I guess the results of “ohai -ldebug” could also be useful to diagnose the issue. Cheers, -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#595860: solfege: FTBFS in squeeze: tests failed
tag 595860 patch thanks On Tue, Sep 07, 2010 at 01:00:40AM +0200, Lucas Nussbaum wrote: Package: solfege Version: 3.16.4-1 Severity: serious Tags: squeeze sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20100906 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in a squeeze chroot, your package failed to build on amd64. Relevant part: […] == ERROR: test_add (solfege.mpd.tests.test_musicalpitch.TestMusicalPitch) -- Traceback (most recent call last): File /build/user-solfege_3.16.4-1-amd64-5srsJD/solfege-3.16.4/solfege/mpd/tests/test_musicalpitch.py, line 35, in test_add self.assertEquals(n.get_octave_notename(), 'd') File /build/user-solfege_3.16.4-1-amd64-5srsJD/solfege-3.16.4/solfege/mpd/musicalpitch.py, line 360, in get_octave_notename return self._format_notename(%(utnotename)s%(oct)s) File /build/user-solfege_3.16.4-1-amd64-5srsJD/solfege-3.16.4/solfege/mpd/musicalpitch.py, line 383, in _format_notename notename = _i(notename) File /build/user-solfege_3.16.4-1-amd64-5srsJD/solfege-3.16.4/solfege/i18n.py, line 37, in _i ns = _(s) TypeError: 'tuple' object is not callable […] Python 2.6’s doctest is the culprit, more specifically some new lines in doctest.DocTestRunner.run which override the displayhook provided by test.py. This causes _ to be set to the result of the last statement (like in the REPL), which overrides the _ alias for ugettext from solfege.i18n. Upstream has fixed the issue by abolishing doctest. Considering the freeze and the fact that test.py isn’t shipped in the binary packages, I have attached an alternative, ugly, but very simple patch to fix the problem. Cheers, -- Michael Schutte mi...@uiae.at Subject: Set sys.__displayhook__ = sys.displayhook in test.py From: Michael Schutte mi...@uiae.at Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595860 Forwarded: not-needed doctest from Python = 2.6 resets sys.displayhook whenever a test is run. The default displayhook sets _ to the evaluation result of the last line, but this messes with the global definition of _ in solfege.i18n. This patch implements an ugly fix by redefining sys.__displayhook__ in test.py. Upstream has already fixed the problem properly by avoiding doctest in the first place. Index: solfege-3.16.4/test.py === --- solfege-3.16.4.orig/test.py 2010-09-18 19:28:26.0 +0200 +++ solfege-3.16.4/test.py 2010-09-18 19:28:33.0 +0200 @@ -19,7 +19,7 @@ else: print s -sys.displayhook = f +sys.__displayhook__ = sys.displayhook = f from solfege import testlib import solfege.i18n signature.asc Description: Digital signature
Bug#592673: ticgit: fails to update git ref HEAD running 'ti new'
Hi again! On Thu, Aug 12, 2010 at 09:20:22AM +0200, Daniel Fanjul wrote: No, it is not an empty repository. I already have commits and other branches. For example: *...@rayado:~/tmp[master]$* mkdir ticgittesting *...@rayado:~/tmp[master]$* cd ticgittesting *...@rayado:~/tmp/ticgittesting[master]$ *git init Initialized empty Git repository in /home/dfanjul/tmp/ticgittesting/.git/ *...@rayado:~/tmp/ticgittesting$* for i in `seq 5`; do touch $i; git add $i; git ci -m $i $i; done [master (root-commit) 4403532] 1 ... *...@rayado:~/tmp/ticgittesting[master]$* git br * master *...@rayado:~/tmp/ticgittesting$** cat .git/HEAD ref: refs/heads/master* *...@rayado:~/tmp/ticgittesting[master]$* ti new I, [2010-08-12T08:56:44.996317 #4133] INFO -- : creating ticgit repo branch I, [2010-08-12T08:56:50.058287 #4133] INFO -- : saving 1281596210_foo_15 /usr/lib/ruby/1.8/git/lib.rb:643:in `command': git branch -a 21:fatal: Failed to resolve HEAD as a valid ref. (Git::GitExecuteError) from /usr/lib/ruby/1.8/git/lib.rb:615:in `command_lines' from /usr/lib/ruby/1.8/git/lib.rb:209:in `branches_all' from /usr/lib/ruby/1.8/ticgit/base.rb:241:in `load_tickets' from /usr/lib/ruby/1.8/ticgit/base.rb:72:in `reset_ticgit' from /usr/lib/ruby/1.8/ticgit/base.rb:67:in `ticket_new' from /usr/lib/ruby/1.8/ticgit/cli.rb:348:in `handle_ticket_new' from /usr/lib/ruby/1.8/ticgit/cli.rb:41:in `execute!' from /usr/lib/ruby/1.8/ticgit/cli.rb:12:in `execute' from /usr/bin/ti:10 Alright, I just had an idea … Is there any chance you have set color.ui or color.branch to always in your Git configuration? This seems to upset libgit-ruby’s handling of branches in the way you are describing. If so, try setting it to auto as a workaround (this still enables colour on the console, but disables it on pipes), and I’ll reassign to libgit-ruby. Cheers, -- Michael Schutte mi...@uiae.at -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592673: ticgit: fails to update git ref HEAD running 'ti new'
severity 592673 important reassign 592673 libgit-ruby retitle 592673 libgit-ruby: fails to interpret colored “git branch” output thanks Hi, On Thu, Aug 12, 2010 at 03:48:23PM +0200, Daniel Fanjul wrote: Yes, I have both properties set to 'always'. With 'auto' ticgit works fine, as expected. The bug should be reassigned to libgit-ruby. Thank you for the confirmation. All the best, -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#592673: ticgit: fails to update git ref HEAD running 'ti new'
Hi Daniel! On Wed, Aug 11, 2010 at 11:45:58PM +0200, Daniel Fanjul wrote: The package is not usable. Any update operation (like 'ti new') corrupts the file .git/HEAD. This is the first and unique ticgit command I have launched to test this bug: rayado:~/tmp/testing.git$ ti new I, [2010-08-11T23:35:30.157073 #23721] INFO -- : saving 1281562530_foo_55 /usr/lib/ruby/1.8/git/lib.rb:643:in `command': git branch -a 21:fatal: Failed to resolve HEAD as a valid ref. (Git::GitExecuteError) from /usr/lib/ruby/1.8/git/lib.rb:615:in `command_lines' from /usr/lib/ruby/1.8/git/lib.rb:209:in `branches_all' from /usr/lib/ruby/1.8/ticgit/base.rb:241:in `load_tickets' from /usr/lib/ruby/1.8/ticgit/base.rb:72:in `reset_ticgit' from /usr/lib/ruby/1.8/ticgit/base.rb:67:in `ticket_new' from /usr/lib/ruby/1.8/ticgit/cli.rb:348:in `handle_ticket_new' from /usr/lib/ruby/1.8/ticgit/cli.rb:41:in `execute!' from /usr/lib/ruby/1.8/ticgit/cli.rb:12:in `execute' After this command, the HEAD file is not pointing to any valid ref: rayado:~/tmp/testing.git$ cat .git/HEAD ref: refs/heads/ Thanks a lot for your report. I can indeed reproduce the bug if the ref .git/HEAD is pointing to does not exist beforehand, which happens with an empty repository, for example. Is this what you are describing? Try “git commit --allow-empty -m'initial commit'” before running “ti new” for the first time if this is a new repo. In case that this is indeed what you are reporting, would you be fine if I downgraded this bug to important for now? After all, most people will want to start tracking bugs well after the inital development, and the problem is easy to work around. If your case is different, I’m afraid I’ll need a little more information to understand and handle this issue. Cheers, -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#560541: pkgconfig file in libsvm-dev? [was: Bug#560541: libsvm-ruby: FTBFS]
On Tue, Dec 15, 2009 at 09:27:44AM +0800, Chen-Tse Tsai wrote: Sorry for the inconvenience. This is because we think libsvm is only a simple library(one header and one library), also we want to keep it as simple as possible and as close to upstream as possible. If it causes too many inconvenience, I will consider to re-introduce it back. Thanks for your suggestion. Ah, I see, so the pkgconfig file is a Debian-specific addition. In this case, the upstream version of libsvm-ruby also shouldn’t depend on the libsvm.pc file being available. I’d just go ahead and change libsvm-ruby’s extconf.rb to set $CFLAGS and $LDFLAGS instead of using pkgconfig. Rudi, what is your opinion as Debian and upstream maintainer? -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#560541: pkgconfig file in libsvm-dev?
Hey everyone, I’ve checked a “fix” to this bug into version control (it’s just hardcoding the include path and the -l option for libsvm in extconf.rb). So if anyone wants to have a look at it, there is an RC bug to be closed! On Tue, Dec 15, 2009 at 02:13:00PM +, Rudi Cilibrasi wrote: I am planning on abandoning libsvm-ruby like I orphaned the libsvm package. In my opinion there is little chance for the upstream packaging to be improved in LIBSVM as I have been trying to convince upstream to do certain improvements for years and they resisted. Now I am reducing my investment in LIBSVM related technology to 0. Best regards, I see. I’ve accordingly moved you to Uploaders in the SVN (and made the team the maintainer instead). I didn’t really want to remove you completely, though – thanks for you work :-) Cheers, -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#560541: pkgconfig file in libsvm-dev? [was: Bug#560541: libsvm-ruby: FTBFS]
Hi! libsvm-ruby relies on a libsvm.pc file to figure out how to build with libsvm. This convenience has gone away between the 2.89-1 and 2.90-1 uploads of your package, causing libsvm-ruby to FTBFS on a QA rebuild. The libsvm changelog simply states, | * Removed libsvm.pc from libsvm-dev. May I ask you to elaborate on the reason for this change (for the future, it is a good idea to do this right in the changelog, to avoid further confusion like this one)? And would it be possible for you to re-introduce the file in the next revision? Thanks in advance, -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#558492: kbd_1.15.1-1(ia64/unstable): FTBFS: compile errors
tag 558492 pending thanks On Thu, Dec 03, 2009 at 03:58:52AM +0300, Alexey Gladkov wrote: On 30.11.2009 22:05, Michael Schutte wrote: I guess the most “correct” fix is a memcpy() of the input buffer to the correctly aligned address of psfhdr. Yes. I think this is the most correct way. http://git.altlinux.org/people/legion/packages/kbd.git?p=kbd.git;a=commitdiff;h=d10c22e120863a4dc2dc6fd82431bdb962327891 Great. I’m applying this for the next Debian revision as well. This should fix the problem. But I checked the only cross-compilation for ARM. Can you confirm fix for other archs? I just tried a native build on an ARM machine; everything seems fine. Debian’s autobuilders will soon provide feedback regarding the other architectures :-) Cheers, -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#558492: kbd_1.15.1-1(ia64/unstable): FTBFS: compile errors
Hi Alexey! kbd fails to build on several architectures supported by Debian GNU/Linux, namely Alpha, ARM, PA-RISC, IA-64, MIPS and SPARC. This is the relevant part from the original bug report: On Sun, Nov 29, 2009 at 04:53:49AM -0700, lam...@debian.org wrote: There was an error while trying to autobuild your package: […] gcc -DHAVE_CONFIG_H -I. -I.. -DDATADIR=\/usr/share\ -DLOCALEDIR=\/usr/share/locale\ -Wall -Wextra -Wmissing-noreturn -Wdisabled-optimization -Wcast-align -Wshadow -Wmissing-format-attribute -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Werror -funit-at-a-time -Os -g -MT psffontop.o -MD -MP -MF .deps/psffontop.Tpo -c -o psffontop.o psffontop.c cc1: warnings being treated as errors psffontop.c: In function 'readpsffont': psffontop.c:253: error: cast increases required alignment of target type make[1]: *** [psffontop.o] Error 1 make[1]: Leaving directory `/build/buildd/kbd-1.15.1/src' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 (If you wish, you can find the full build logs for all architectures at https://buildd.debian.org/build.cgi?pkg=kbd.) As far as I can tell, the affected archs align data structures just like the member with the highest alignment. The cast from (char *) to (struct psf2_header *) fails as inputbuf is byte-aligned while the struct’s alignment matches that of int (likely word-aligned). I guess the most “correct” fix is a memcpy() of the input buffer to the correctly aligned address of psfhdr. Simply allowing unaligned access, as forced by “(struct psf_header2 *) (void *) inputbuf[0]”, might also work, but I don’t know enough about the situation to say this with certainty. I’d be glad about suggestions from your part :-) Cheers, -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#531280: fails to install, trying to overwrite other packages files
Replaces: alone is actually sufficient in this case.
--
Michael Schutte mi...@uiae.at
diff -u stardic-1.3.1/debian/control stardic-1.3.1/debian/control
--- stardic-1.3.1/debian/control
+++ stardic-1.3.1/debian/control
@@ -7,6 +7,7 @@
Package: stardic-common
Architecture: all
+Replaces: stardic ( 1.3.1-5)
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: stardic (= ${binary:Version})
Description: common files for the English-Chinese dictionary stardic
signature.asc
Description: Digital signature
Bug#531280: fails to install, trying to overwrite other packages files
tag 531280 + patch
On Sun, May 31, 2009 at 11:28:57AM +0200, Holger Levsen wrote:
From the attached log (scroll to the bottom...):
Unpacking stardic-common (from .../stardic-common_1.3.1-5_all.deb) ...
dpkg: error
processing /var/cache/apt/archives/stardic-common_1.3.1-5_all.deb (--unpack):
trying to overwrite `/usr/share/stardic/exitmask.xbm', which is also in
package stardic
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Preparing to replace stardic 1.3.1-4.2
(using .../stardic_1.3.1-5_amd64.deb) ...
Unpacking replacement stardic ...
Errors were encountered while processing:
/var/cache/apt/archives/stardic-common_1.3.1-5_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
stardic-common alone installs fine, so I file this bug against stardic.
stardic has been split up in stardic and stardic-common starting with
version 1.3.1-5, but the latter does not declare the necessary relations
to the stardic package before the split. The attached patch addresses
this problem.
Cheers,
--
Michael Schutte mi...@uiae.at
diff -u stardic-1.3.1/debian/control stardic-1.3.1/debian/control
--- stardic-1.3.1/debian/control
+++ stardic-1.3.1/debian/control
@@ -7,6 +7,8 @@
Package: stardic-common
Architecture: all
+Conflicts: stardic ( 1.3.1-5)
+Replaces: stardic ( 1.3.1-5)
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: stardic (= ${binary:Version})
Description: common files for the English-Chinese dictionary stardic
signature.asc
Description: Digital signature
Bug#534003: belpic, kio-locate, skim: scons-related FTBFSes
tag 525593 + patch tag 534003 + patch tag 534030 + patch thanks Hi, scons: *** […] TypeError : cannot concatenate 'str' and 'list' objects These bugs come from the behavior of _do_create_keywords() in /usr/lib/scons/SCons/Action.py (line 332, scons 1.2.0-2). It interprets this line from admin/generic.py la_file = env.Action(build_la_file, string_la_file, ['BKSYS_VNUM', 'BKSYS_DESTDIR']) by appending the list as a whole to another list. The correct usage appears to be la_file = env.Action(build_la_file, string_la_file, 'BKSYS_VNUM', 'BKSYS_DESTDIR') As at least three packages are affected, it might be an alternative to make scons accept this syntax; it seems to have been supported before, after all. Cheers, -- Michael Schutte mi...@uiae.at --- a/admin/generic.py 2009-07-11 16:25:14.0 +0200 +++ b/admin/generic.py 2009-07-11 16:25:30.0 +0200 @@ -492,7 +492,7 @@ def string_la_file(target, source, env): print building '%s' from '%s' % (target[0].name, source[0].name) - la_file = env.Action(build_la_file, string_la_file, ['BKSYS_VNUM', 'BKSYS_DESTDIR']) + la_file = env.Action(build_la_file, string_la_file, 'BKSYS_VNUM', 'BKSYS_DESTDIR') env['BUILDERS']['LaFile'] = env.Builder(action=la_file,suffix='.la',src_suffix=env['SHLIBSUFFIX']) ## Function for building shared libraries signature.asc Description: Digital signature
Bug#478187: RFS: trang 20030619-7 (QA upload, second try)
Vincent, On Sun, Feb 01, 2009 at 01:25:00AM +0100, Vincent Lefevre wrote: Any news? On http://lists.debian.org/debian-java/2008/09/msg00023.html, I see: Pushing. Yes, I tried to push the thread to let it get more attention. So, what's the status of this package? Unchanged. Anyway, this isn’t urgent at the moment, as trang is not in Lenny; since no Java or QA people reacted at the time I posted the fix, I decided to postpone it. -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#478187: RFS: trang 20030619-7 (QA upload, second try)
On Sun, Feb 01, 2009 at 02:45:51PM +0100, Vincent Lefevre wrote: On 2009-02-01 09:28:47 +0100, Michael Schutte wrote: Unchanged. Anyway, this isn´t urgent at the moment, as trang is not in Lenny; since no Java or QA people reacted at the time I posted the fix, I decided to postpone it. But trang is in Etch (and works well there). So, what about Etch users who need trang? When they upgrade to Lenny, they will have a bad surprise. Upgrades should not be affected, but you are of course still right for new installations. I understand that you would like to have trang in Lenny, but I don’t know whether it is a good idea to actively get an orphaned package into a stable release. I’m not willing to pick up this package, I merely provided a patch for it last September. I also see that there is movement on #454810, so I don’t really consider it my task to follow this further. Cheers, -- Michael Schutte mi...@uiae.at signature.asc Description: Digital signature
Bug#498700: Missing upgrade path from libdb4.2-ruby1.8 to libdb-ruby1.8
Pushing. On Sat, Sep 13, 2008 at 12:22:28PM +0200, Michael Schutte wrote: On Fri, Sep 12, 2008 at 01:19:58PM +0200, Frans Pop wrote: Package: libdb-ruby1.8 Version: 0.6.5-1 Severity: serious Justification: Causes unclean upgrades I have dhelp installed on a Lenny system, which depends on libdb4.2-ruby1.8. After upgrading the system at some point I was left with libdb4.2-ruby1.8 still installed as obsolete package. At first I thought this was some temporary inconsistency in testing, but I now find that libdb4.2-ruby1.8 has been renamed to libdb-ruby1.8, which provides the old package. However, it seems that no upgrade path is provided to ensure that users that already had the old package installed will get the new package. Only if libdb-ruby1.8 is selected manually will the old package get replaced. The obvious fix (dummy transitional packages) is in our SVN; it’a bit ugly, but seems to work. It certainly deserves a second pair of eyes, I might easily have missed something. Could someone please check and upload? -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#478187: RFS: trang 20030619-7 (QA upload, second try)
Hi everyone, Could any of you, preferably with more Java packaging experience than me, have a look at my proposed trang revision 20030619-7? Uploading it would close #478187 (G); the error described there is caused by gcj hiding an internal package of trang behind a built-in one. I’ve posted an RFS two weeks ago [1], but only one non-DD responded, which is why I’m adding -qa. The source package can be downloaded from: http://alioth.debian.org/~michi-guest/packages/trang_20030619-7.dsc It builds fine in pbuilder, the binary package as well as the source is lintian clean, and debdiff against the binary package from 6.1 shows no unexpected changes. I would greatly appreciate if someone could comment on what I’ve done and eventually upload it. [1] http://lists.debian.org/debian-java/2008/09/msg3.html Cheers, -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#498700: [DRE-maint] Bug#498700: Missing upgrade path from libdb4.2-ruby1.8 to libdb-ruby1.8
On Fri, Sep 12, 2008 at 01:19:58PM +0200, Frans Pop wrote: Package: libdb-ruby1.8 Version: 0.6.5-1 Severity: serious Justification: Causes unclean upgrades I have dhelp installed on a Lenny system, which depends on libdb4.2-ruby1.8. After upgrading the system at some point I was left with libdb4.2-ruby1.8 still installed as obsolete package. At first I thought this was some temporary inconsistency in testing, but I now find that libdb4.2-ruby1.8 has been renamed to libdb-ruby1.8, which provides the old package. However, it seems that no upgrade path is provided to ensure that users that already had the old package installed will get the new package. Only if libdb-ruby1.8 is selected manually will the old package get replaced. The obvious fix (dummy transitional packages) is in our SVN; it’a bit ugly, but seems to work. It certainly deserves a second pair of eyes, I might easily have missed something. Cheers, -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#495320: rubygems1.8: Package name change causes data loss
severity 495320 wishlist tag 495320 wontfix thanks On Mon, Sep 01, 2008 at 02:22:31AM +0900, Daigo Moriwaki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 severity 495320 wishlist tag 495320 wontfix thanks You seem to have forgotten control@ :-) Cheers, -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#494428: gonzui: incompatible with libdb-ruby 0.6.4
severity 494428 grave thanks After the removal of libdb4.?-ruby1.8, gonzui is now unusable in testing and unstable; raising severity again. -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#494415: aswiki: package is completely unusable
On Mon, Aug 11, 2008 at 09:38:47AM +0900, TANIGUCHI Takaki wrote: IndexPage /usr/lib/ruby/1.8/aswiki/backup.rb:40:in `ci' /usr/lib/ruby/1.8/aswiki/repository.rb:31:in `save' /usr/lib/ruby/1.8/aswiki/handler.rb:155:in `initialize' /home/schm/public_html/aswiki/aswiki.cgi:50:in `new' /home/schm/public_html/aswiki/aswiki.cgi:50 on saving a page, which was when I gave up. This is not a bug. You should install rcs package or set '$USEBACKUP = false' in aswiki.conf. Ah, I see. Sorry for the false report—I only tried to check aswiki with regard to the planned libdb-ruby transition [1] and did not take myself enough time to look into this :-) [1] http://lists.debian.org/debian-release/2008/08/msg00401.html Cheers, -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#494415: aswiki: package is completely unusable
Package: aswiki Version: 1.0.4-5 Severity: grave Justification: renders package unusable Hi, aswiki is broken. When running it as a CGI script, the following exception is shown: wrong number of arguments (1 for 0) /usr/lib/ruby/1.8/aswiki/handler.rb:229:in `initialize' /usr/lib/ruby/1.8/aswiki/handler.rb:229:in `new' /usr/lib/ruby/1.8/aswiki/handler.rb:229:in `makeeditpage' /usr/lib/ruby/1.8/aswiki/handler.rb:257:in `initialize' /home/schm/public_html/aswiki/aswiki.cgi:48:in `new' /home/schm/public_html/aswiki/aswiki.cgi:48 This is apparently caused by aswiki relying on Digest::MD5.new accepting an argument containing the text to digest, which it does not. After fixing this problem by monkey-patching Digest::MD5, aswiki reacted with IndexPage /usr/lib/ruby/1.8/aswiki/backup.rb:40:in `ci' /usr/lib/ruby/1.8/aswiki/repository.rb:31:in `save' /usr/lib/ruby/1.8/aswiki/handler.rb:155:in `initialize' /home/schm/public_html/aswiki/aswiki.cgi:50:in `new' /home/schm/public_html/aswiki/aswiki.cgi:50 on saving a page, which was when I gave up. As aswiki has a low popcon store and is seemingly unmaintained upstream, removing it might be the easiest solution. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (700, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_AT.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aswiki depends on: ii libalgorithm-diff-ruby1.8 0.4-5 Ruby conversion of the Perl's Algo ii libamrita-ruby1.8 1.0.2-4HTML/XML template library for Ruby ii libdbm-ruby1.81.8.7.22-2 DBM interface for Ruby 1.8 ii libruby1.8 [libstrscan-ruby1. 1.8.7.22-2 Libraries necessary to run Ruby 1. ii ruby1.8 1.8.7.22-2 Interpreter of object-oriented scr Versions of packages aswiki recommends: ii libdb4.4-ruby1.8 0.6.2-1Interface to Berkeley DB for Ruby pn rcs none (no description available) aswiki suggests no packages. -- no debconf information Cheers, -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#489088: libglib2-ruby1.8: must provide rbgcompat.h
reassign 489088 libglib2-ruby1.8 retitle 489088 libglib2-ruby1.8: must provide rbgcompat.h thanks On Thu, Jul 03, 2008 at 09:57:51AM +0200, Lucas Nussbaum wrote: Hi, During a rebuild of all packages in sid, your package failed to build on i386. Relevant part: cc -I. -I/build/user-ruby-gstreamer0.10_0.2.0-4-amd64-_PcZtL/ruby-gstreamer0.10-0.2.0-4/glib/src -I/build/user-ruby-gstreamer0.10_0.2.0-4-amd64-_PcZtL/ruby-gstreamer0.10-0.2.0-4/glib/src -I. -I/usr/lib/ruby/1.8/i486-linux -I. -DHAVE_RB_DEFINE_ALLOC_FUNC -DHAVE_RB_BLOCK_PROC -DHAVE_OBJECT_ALLOCATE -DHAVE_NODE_ATTRASGN -DRUBY_GST_COMPILATION -D_FILE_OFFSET_BITS=64 -I/usr/local/lib/site_ruby/1.8/i486-linux -fPIC -fno-strict-aliasing -g -g -O2 -fPIC -Wall -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -DHAVE_GST_OVERLAY -c rbgstpluginfeature.c In file included from rbgst.h:31, from rbgstpluginfeature.c:22: /usr/lib/ruby/1.8/i486-linux/rbgobject.h:256:23: error: rbgcompat.h: No such file or directory make[2]: *** [rbgstpluginfeature.o] Error 1 This is a problem in ruby-gnome2’s libglib2-ruby1.8. It is already fixed in SVN. -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#482242: [DRE-maint] Bug#482242: ruby-gnome2: FTBFS: rbpoppler-page.c:446: error: 'PopplerImageMapping' has no member named 'image'
On Wed, May 21, 2008 at 03:31:03PM +0200, Lucas Nussbaum wrote: Relevant part: cc -I. -I/build/user/ruby-gnome2-0.16.0/glib/src -I. -I/usr/lib/ruby/1.8/i486-linux -I.././poppler -DHAVE_RB_DEFINE_ALLOC_FUNC -DHAVE_RB_BLOCK_PROC -DHAVE_OBJECT_ALLOCATE -DHAVE_NODE_ATTRASGN -DHAVE_RB_CAIRO_H -DHAVE_POPPLER_PAGE_RENDER_SELECTION_TO_PIXBUF -DRUBY_POPPLER_COMPILATION -I/usr/local/lib/site_ruby/1.8/i486-linux -fPIC -g -O2 -g -Wall -O2 -Wall -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1-c rbpoppler-page.c rbpoppler-page.c: In function 'page_render_selection': rbpoppler-page.c:265: warning: passing argument 6 of 'poppler_page_render_selection' from incompatible pointer type rbpoppler-page.c:265: warning: passing argument 7 of 'poppler_page_render_selection' from incompatible pointer type rbpoppler-page.c: In function 'image_mapping_get_image': rbpoppler-page.c:446: error: 'PopplerImageMapping' has no member named 'image' rbpoppler-page.c: In function 'image_mapping_set_image': rbpoppler-page.c:446: error: 'PopplerImageMapping' has no member named 'image' make[3]: *** [rbpoppler-page.o] Error 1 libpoppler’s API has changed, fixed in r2732 by importing a patch from the upstream VCS. Would somebody please check and upload? Cheers, -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#472018: setting package to python-odtwriter odtwriter, tagging 472018
# Automatically generated email from bts, devscripts version 2.10.18.1 # # odtwriter (1.1a-3) unstable; urgency=low # # * python-central used to leave behind an empty /usr/lib directory (see ##452227). This was previously fixed by an rmdir invocation in #debian/rules; this line now causes an FTBFS bug. Removed the offending #line and build-depend on python-central = 0.6, closes: #472018. # package python-odtwriter odtwriter tags 472018 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464285: rails: FTBFS: private method `cp' called for File:Class
Adam,
Please find attached a simple patch to address this issue.
Cheers,
--
Michael Schutte [EMAIL PROTECTED]
diff -u rails-2.0.2/railties/Rakefile rails-2.0.2/railties/Rakefile
--- rails-2.0.2/railties/Rakefile
+++ rails-2.0.2/railties/Rakefile
@@ -264,7 +264,7 @@
end
task :generate_app_doc do
- File.cp doc/README_FOR_APP, #{PKG_DESTINATION}/doc/README_FOR_APP
+ cp doc/README_FOR_APP, #{PKG_DESTINATION}/doc/README_FOR_APP
system %{cd #{PKG_DESTINATION}; rake doc:app}
end
signature.asc
Description: Digital signature
Bug#464851: retitle 464851 to clarify package's nature in long description
# Automatically generated email from bts, devscripts version 2.10.13 # since nobody objected: retitle 464851 clarify package's nature in long description -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464851: [python-odtwriter] package name wrong?
On Sat, Feb 09, 2008 at 02:20:26PM +0100, Bernd Zeimetz wrote: So python-docutils-writers-odtwriter would be the right name in theory, but this doesn't make sense, indeed. Does anybody insist on that name? If not, I’m going to update the long description to mention the relationship to python-docutils, which probably would have avoided that bug report in the first place. Cheers, -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#464851: [python-odtwriter] package name wrong?
On Sat, Feb 09, 2008 at 12:55:33PM +0100, Rene Engelhard wrote: Hmm. Is it now a program or a module? In the latter case the pakcage name would be right but then rst2odt, the manpage etc. shoudln't be in there. OTOH, this looks like a private module for just the rst2odt program, in which case the package should be called rst2odt. Splitting the package up doesn't make that much sense given that it's a) a internal module and b) __init__.py is only 88K First of all, the package enhances python-docutils in that it adds an extra output format, a “writer,” to its capabilities. A minimum-size re-implementation of rst2odt could look like this: #!/usr/bin/python from docutils.core import publish_cmdline publish_cmdline(writer_name='odtwriter') (The real implementation of rst2odt is longer because of operating systems which make a difference between text and binary file output.) Therefore, the module is not really private; it is at least known to docutils and can be used in any program which uses docutils’ API. Then, the main reason why I have chosen to use this name is that calling it rst2odt would be inconsequent; python-docutils also contains rst2* scripts and is not named after them, even though they arguably provide the interface that is used most of the time. So I think it is not the worst solution to stick with “python-odtwriter”—something like “python-docutils-odtwriter” would still make sense to me, but that’s a bit bulky. Ccing debian-python to get some more opinions. Thanks for your comment, -- Michael Schutte [EMAIL PROTECTED] signature.asc Description: Digital signature
