Bug#702267: Security update is pending
Thank you very very much for this, Salvatore. Please prepare the NMU, but hold off on it for upstream's opinion. Also, please try to engage the security team. Unless you're part of it, of course ;-) On Apr 22, 2013, at 11:02 AM, Salvatore Bonaccorso wrote: Control: tags 702267 + patch Hi Michal On Thu, Apr 18, 2013 at 08:35:10AM +0200, Michal Trojnara wrote: This is a security vulnerability that may result in remote code execution. It should be fixed immediately. Current stunnel Debian package is based on stunnel 4.53. This upstream version is over a year old. Please update the package to stunnel 4.56. This version seems to be very stable. Unfortunately stunnel4 package cannot be updated to latest upstream version due to the freeze and wheezy beeing relased very soon. So the version based on 4.53 needs to be patched. I tried to extract the correspondig diff from 5.54 to 4.55 also based on what Red Hat did[1]. [1]: http://rhn.redhat.com/errata/RHSA-2013-0714.html Does this looks good form your upstream point of view on it? Luis, can you work on it, else I can prepare the NMU as per debdiff. Regards, Salvatore CVE-2013-1762.patchstunnel4_4.53-1.1.debdiff -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653882: Upstream fix
On Sun, Jan 01, 2012 at 11:06:54PM +0100, Michal Trojnara wrote: Hi Guys, I think I fixed this issue in ftp://ftp.stunnel.org/stunnel/beta/stunnel-4.51b5.tar.gz Would you be so kind to test it, so I can release this fix in stunnel 4.51? For your testing convenience, I've uploaded this to experimental as 3:4.51~b1-1. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621987: stunnel4: FTBFS: options.c:1201: undefined reference to `SSLv2_client_method'
tag 621987 + fixed-upstream thanks On Sat, Apr 09, 2011 at 02:14:39PM +0200, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: gcc -Wall -g -O2 -Wall -Wshadow -Wcast-align -Wpointer-arith -I/usr/include -o stunnel file.o client.o log.o options.o protocol.o network.o resolver.o ssl.o ctx.o verify.o sthreads.o stunnel.o pty.o libwrap.o -ldl -lutil -lnsl -lpthread -L/usr/lib -lssl -lcrypto -lwrap options.o: In function `service_options': /build/user-stunnel4_4.29-1-amd64-VwTzyZ/stunnel4-4.29/src/options.c:1201: undefined reference to `SSLv2_client_method' /build/user-stunnel4_4.29-1-amd64-VwTzyZ/stunnel4-4.29/src/options.c:1202: undefined reference to `SSLv2_server_method' collect2: ld returned 1 exit status Fixed by 4.35, just added to packaging SCM, but not quite ready for upload yet. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570719: librep: diff for NMU version 0.90.2-1.1
On Thu, Oct 14, 2010 at 07:15:40PM +0100, dioc...@debian.org wrote: Dear maintainer, I've prepared an NMU for librep (versioned as 0.90.2-1.1) and uploaded it to DELAYED/5, as suggested by section 5.11.1 of the Developer's Reference for NMUs fixing RC bugs less than 7 days old. Please feel free to tell me if I should delay it longer. Thanks. I was preparing a line by line identical patch for this, but hadn't had time to build and test it. As a matter of fact, if you want to, feel free to upload it directly. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595880: Patch for FTBFS
tag 595880 +pending block 595880 by 599762 thanks On Sun, Oct 10, 2010 at 01:54:14PM +0200, Julien Cristau wrote: Looks fine, please do upload to tpu. Upload was rejected by ftp-master: Reject Reasons: sawfish_1.3.5.2-2.dsc: old version (1:1.3.5.2-1) in unstable = new version (1:1.3.5.2-2) targeted at testing-proposed-updates. I have requested removal of the ia64, kfreebsd-i386 and m68k binary packages and will re-attempt the upload later. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503205: twitux cannot connect but can get public timeline
On Tue, Oct 05, 2010 at 08:51:36AM -0400, Sterling MacNay wrote: I have moved to wicd from nm and have started gnome-keyring-daemon in my xfce session (I now have xfce starting gnome session cruft). I can receive the Twitux and public timelines but cannot connect to twitter. Debian sid here. I might run a gnome session and see if there is a difference in how it works. This is actually quite a different bug and the reason we requested twitux to be removed from testing: Twitter now requires use of OAuth authentication, which twitux does not implement. Thus, it can no longer access anything other than public info. There is, afaik, a patch available for this, but it requires a library not yet in sid. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595880: Patch for FTBFS
tag 595880 +patch
bye
The patch aatached fixes the FTBFS. I will test the resulting package
for a couple days before asking release for permission to upload to
testing-proposed-updates.
--
Rodrigo Gallardo
diff --git a/debian/control b/debian/control
index f6a7a46..a0077ed 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends: gettext (= 0.10.37), debhelper (= 5.0.0),
libxinerama-dev,
libesd0-dev, rep-gtk (= 1:0.18.3), libgmp3-dev (= 4.1.4-8),
texinfo ( 4.11) | texinfo (= 4.11.dfsg.1-3),
libgtk2.0-dev (= 2.6), libxrender-dev, libxext-dev, libxt-dev,
- autotools-dev, automake1.10, quilt (=0.40), librep-dev (= 0.17.3),
+ autotools-dev, automake1.10, quilt (=0.40), librep-dev (= 0.17.3), rep,
libtool
Vcs-Browser: http://git.debian.org/?p=collab-maint/sawfish.git
Vcs-Git: git://git.debian.org/git/collab-maint/sawfish.git
@@ -16,7 +16,7 @@ Homepage: http://sawfish.wikia.com/
Package: sawfish
Architecture: any
-Depends: ${shlibs:Depends}, rep-gtk (= 0.18.4), gnome-terminal |
x-terminal-emulator, sawfish-data (= ${source:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, rep, rep-gtk (= 0.18.4),
gnome-terminal | x-terminal-emulator, sawfish-data (= ${source:Version})
Suggests: menu, gnome-control-center, yelp
Provides: x-window-manager
Replaces: sawfish-lisp-source (= 0.38-6), sawfish2
@@ -29,7 +29,7 @@ Description: a window manager for X11
Package: sawfish-dbg
Architecture: any
-Depends: sawfish (= ${binary:Version})
+Depends: ${misc:Depends}, sawfish (= ${binary:Version})
Recommends: sawfish-lisp-source
Section: debug
Priority: extra
@@ -42,6 +42,7 @@ Description: sawfish debugging symbols
Package: sawfish-data
Architecture: all
+Depends: ${misc:Depends}
Replaces: sawfish (= 1:1.3+cvs20060518-2)
Conflicts: sawfish (= 1:1.3+cvs20060518-2)
Description: sawfish architecture independent data
@@ -53,6 +54,7 @@ Description: sawfish architecture independent data
Package: sawfish-lisp-source
Architecture: all
+Depends: ${misc:Depends}
Description: sawfish lisp files
This package contains the lisp source files in case you want to modify,
study or debug the behaviour of the window manager.
Bug#589360: propose to remove twitux package from testing (was twitux: lack of OAuth support)
On Fri, Aug 06, 2010 at 11:18:51AM -0400, Hideki Yamane wrote: This package is twitter client, but it seems to lack OAuth support. Twitter will drop Authentication method like Basic Auth other than OAuth, so this should support OAuth until 16th August (it means twitux would be completely unusable after that day). And I suggest once to remove it from tesing. Since I reported this 3 weeks ago, there is no progress and upstream seems to be dead, see http://twitux.svn.sourceforge.net/viewvc/twitux/ So, I'll propose twitux package from testing once. I agree with your assesment, please go ahead. Luke, I think you were interested in this package. If you have the time to take over its upstream let me know and we can work on updating it so it can go back into testing. Otherwise, I think we should actually go all the way and ask for it to be removed from the archive. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556991: /usr/share/doc/sawfish is empty
severity 556991 serious thanks On Wed, Nov 18, 2009 at 03:57:53PM -0500, Philipp Weis wrote: $ ll -d /usr/share/doc/sawfish* drwxr-xr-x 2 root root6 Nov 18 14:54 sawfish $ ll /usr/share/doc/sawfish total 0 Oh, no :( Thanks for the report, I'll handle it asap. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540015: librep-dev: Embeded libtool has /bin/sh shebang, but relies on bashisms
Package: librep-dev Version: 0.17.3-4 Severity: critical Justification: breaks unrelated software librep-dev carries a copy of the libtool used to build it, for use by its rdepends. The version currently in the archive was built when bash was still the default shell, and so the libtool script has #!/bin/sh as its shebang. Now that dash is the default shell, the script fails because it contains bashisms I will request a binNMU, as I have verified that a rebuild will cause the script to pickup #!/bin/bash as its shebang. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537332: liferea: gdb and strace
tag 537332 upstream thsnks On Sat, Jul 18, 2009 at 09:30:56AM +0200, Helmut Grohne wrote: So my theory currently is: Liferea runs into updating the feed http://forum.psi-im.org/forum.php?req=rsstype=1forum=5. The update interval is 24 hours which explains the timing above. It then fails in some strange way and updates again. Requesting that feed by hand gives a 301 redirect followed by a 404. It would appear that that combination of codes confuses liferea. I'm adding here a copy of the response headers I get, followed by a trace of running with --debug-net and --debug-parse I'll get this forwarded to upstream's bugtracker later. Headers: --- GET http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 User-Agent: lwp-request/5.824 libwww-perl/5.826 GET http://forum.psi-im.org/forum.php?req=rsstype=1forum=5 -- 301 Moved Permanently GET http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 -- 404 Not Found Connection: close Date: Sat, 18 Jul 2009 14:06:19 GMT Accept-Ranges: bytes Server: Apache/2.2.6 (Unix) mod_ssl/2.2.6 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635 mod_bwlimited/1.4 PHP/5.2.5 Content-Type: text/html Content-Type: text/html; charset=utf-8 Client-Date: Sat, 18 Jul 2009 14:07:07 GMT Client-Peer: 69.61.121.170:80 Client-Response-Num: 1 Client-Transfer-Encoding: chunked Content-Base: http://psi-im.org/ Link: images/favicon.png; rel=shortcut icon Link: http://forum.psi-im.org/forum.php?req=rsstype=1forum=5; rel=alternate; title=Psi News; type=application/rss+xml Link: styles.css; rel=stylesheet; type=text/css Link: content.css; rel=stylesheet; type=text/css Title: Psi, the Cross-Platform Jabber/XMPP Client for Power Users - Not Found X-Meta-Description: Psi is a multi-platform and standards-based instant messaging client available for Windows, Linux, Mac and more. X-Meta-ROBOTS: NOODP --- Trace: --- NET: downloading http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 NET: 1836 bytes downloaded PARSING: xml_parse_feed(): could not parse feed New Subscription! NET: downloading http://forum.psi-im.org NET: downloading http://forum.psi-im.org/forum.php?req=rsstype=1forum=5 NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 NET: 1836 bytes downloaded PARSING: xml_parse_feed(): could not parse feed New Subscription! NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/ NET: 1836 bytes downloaded NET: downloading http://psi-im.org/forum/forum/images/favicon.png NET: downloading http://forum.psi-im.org/forum.php?req=rsstype=1forum=5 NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/images/favicon.png NET: 1836 bytes downloaded ** (liferea:7126): WARNING **: Unrecognized image file format NET: downloading http://forum.psi-im.org/favicon.ico NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 NET: 1836 bytes downloaded PARSING: xml_parse_feed(): could not parse feed New Subscription! NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/favicon.ico NET: 1836 bytes downloaded ** (liferea:7126): WARNING **: Unrecognized image file format NET: downloading http://forum.psi-im.org/favicon.ico NET: downloading http://forum.psi-im.org/forum.php?req=rsstype=1forum=5 NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/favicon.ico NET: 1836 bytes downloaded ** (liferea:7126): WARNING **: Unrecognized image file format NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 NET: 1836 bytes downloaded PARSING: xml_parse_feed(): could not parse feed New Subscription! NET: downloading http://forum.psi-im.org/forum.php?req=rsstype=1forum=5 NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 NET: 1836 bytes downloaded PARSING: xml_parse_feed(): could not parse feed New Subscription! NET: downloading http://forum.psi-im.org/forum.php?req=rsstype=1forum=5 NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 NET: 1836 bytes downloaded PARSING: xml_parse_feed(): could not parse feed New Subscription! NET: downloading http://forum.psi-im.org/forum.php?req=rsstype=1forum=5 NET: download status code: 404 NET: source after download: http://psi-im.org/forum/forum/forum.php?req=rsstype=1forum=5 NET: 1836 bytes downloaded PARSING:
Bug#536816: Testing transition of liferea is to be blocked until we have a non-rc 1.6.0 release upstream
Package: liferea Version: 1.6.0~rc6-1 Severity: serious 1.6.0~rcX releases are just that, release candidates. As such, we will not allow them to transition into testing until upstream declares them stable. Using my package maintainer's hat to set the severity. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521047: liferea: Empty /usr/share/doc/liferea/
On Tue, Mar 24, 2009 at 03:59:05PM +0100, Axel Beckert wrote: Package: liferea, liferea-dbg Version: 1.5.13-1, 1.5.14-1 Severity: serious Justification: Debian Policy, Sections 12.5 and 12.7 31/0/0 r...@kiva6:pts/ttyp4 [~] # ls -alF /usr/share/doc/liferea* /usr/share/doc/liferea: total 64 drwxr-xr-x2 root root 4096 2009-03-12 14:32 ./ drwxr-xr-x 1521 root root 57344 2009-03-24 15:49 ../ /me scratches his head: rodr...@nabiki:~$ ls -alF /usr/share/doc/liferea* lrwxrwxrwx 1 root root 12 2009-03-20 10:15 /usr/share/doc/liferea - liferea-data/ lrwxrwxrwx 1 root root 12 2009-03-20 10:15 /usr/share/doc/liferea-dbg - liferea-data/ /usr/share/doc/liferea-data: total 100 drwxr-xr-x2 root root 4096 2009-03-20 10:15 ./ drwxr-xr-x 1470 root root 57344 2009-03-20 15:50 ../ -rw-r--r--1 root root 4015 2009-03-12 12:28 AUTHORS -rw-r--r--1 root root 9599 2009-03-19 22:06 changelog.Debian.gz -rw-r--r--1 root root 7338 2009-03-14 11:36 changelog.gz -rw-r--r--1 root root 3081 2009-03-19 22:06 copyright lrwxrwxrwx1 root root22 2009-03-20 10:15 html - ../../liferea/doc/html/ -rw-r--r--1 root root 4247 2009-02-19 13:51 README.gz rodr...@nabiki:~$ As expected from rodr...@nabiki:~$ dpkg --contents /var/cache/pbuilder/result/liferea_1.5.14-1_amd64.deb [ skip 31 lines ] lrwxrwxrwx root/root 0 2009-03-23 22:39 ./usr/share/doc/liferea - liferea-data rodr...@nabiki:~$ Could you please check your downloaded .deb? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520981: libwebkit-1.0-2: Library package contains non-versioned files
Package: libwebkit-1.0-2 Version: 1.1.3-1 Severity: serious Justification: Policy 8.2 $ dpkg -L libwebkit-1.0-2 /. /usr /usr/share /usr/share/doc /usr/share/doc/libwebkit-1.0-2 /usr/share/doc/libwebkit-1.0-2/copyright /usr/share/doc/libwebkit-1.0-2/changelog.Debian.gz /usr/lib /usr/lib/libwebkit-1.0.so.2.1.0 /usr/lib/webkit-1.0 /usr/lib/webkit-1.0/libexec /usr/lib/webkit-1.0/libexec/GtkLauncher /usr/lib/webkit-1.0/libexec/DumpRenderTree /usr/lib/libwebkit-1.0.so.2 Policy 8.2: If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Otherwise, several versions of the shared library cannot be installed at the same time without filename clashes, making upgrades and transitions unnecessarily difficult. In particular, this keeps me from installing experimental liferea and unstable gimp at the same time. (Well, the experimental liferea I'm about to upload in a couple hours, rather). Please move the libexec files to a different package. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514563: xulrunner-dev: can no longer compile liferea 1.4 branch (missing gtkmozembed_glue.cpp, etc.)
On Mon, Mar 09, 2009 at 05:16:11AM +0100, Vincent Lefevre wrote: I've found the problem. It is due to a conflict between libxul-dev (version 1.8) and xulrunner-dev (version 1.9), which are both installed on my machine. ... Concerning the liferea Debian package, if I do apt-get source liferea, cd liferea-1.4.26, change the above line in the configure script directly, then dpkg-buildpackage -b -uc, the failure disappears. And you still have both -dev packages installed, right? I only need to apply this patch and not try to add a Build-Conflicts? I'll upload a new version ASAP. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510765: Neil McGovern's NMU patch from 503907 LGTM
I will try to upload a webkit-less version of liferea early next week, but I explicitely aprove NMUs with Neil's patch from 503907 anyhow. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503205: twitux: Will not connect to twitter.
On Fri, Oct 24, 2008 at 09:54:22AM +0100, Lawrence Woodman wrote: Rodrigo, Therefore I started twitux with: $ strace -otwitux.strace twitux Then clicked on Connect from the Twitter menu. Left it for a few seconds. Then clicked on Quit. The strace output is attached. I think I have reproduced this: Are you using NetworkManager (gnome's default is yes)? If so, does *it* think the network is active? I think twitux is asking nm about the network status and silently failing to do *anything* if the answer from there is off. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503205: [EMAIL PROTECTED]: Re: Bug#503205: twitux: Will not connect to twitter.]
- Forwarded message from Lawrence Woodman [EMAIL PROTECTED] - Subject: Re: Bug#503205: twitux: Will not connect to twitter. From: Lawrence Woodman [EMAIL PROTECTED] To: Rodrigo Gallardo [EMAIL PROTECTED] Date: Wed, 05 Nov 2008 15:54:26 + Rodrigo, I think I have reproduced this: Are you using NetworkManager (gnome's default is yes)? If so, does *it* think the network is active? I think twitux is asking nm about the network status and silently failing to do *anything* if the answer from there is off. I am using NetworkManager, mainly because I haven't had the time to work out how to remove it without removing other things that I want to keep. Anyway, Network Manager thinks that there is no connection. So it ties in with your theory so far. bfn Lawrence - End forwarded message - - Forwarded message from Lawrence Woodman [EMAIL PROTECTED] - Subject: Re: Bug#503205: twitux: Will not connect to twitter. From: Lawrence Woodman [EMAIL PROTECTED] To: Rodrigo Gallardo [EMAIL PROTECTED] Date: Wed, 05 Nov 2008 16:21:09 + Rogdrigo, I think I have reproduced this: Are you using NetworkManager (gnome's default is yes)? If so, does *it* think the network is active? I think twitux is asking nm about the network status and silently failing to do *anything* if the answer from there is off. As a follow-up to my last email. I have just uninstalled NetworkManager and twitux works fine. This is great. Well done. Lawrence P.S. If you want me to test anything on my machine I am more than happy to help. - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503205: twitux: Will not connect to twitter.
On Wed, Nov 05, 2008 at 04:21:09PM +, Lawrence Woodman wrote: Rogdrigo, I think I have reproduced this: Are you using NetworkManager (gnome's default is yes)? If so, does *it* think the network is active? I think twitux is asking nm about the network status and silently failing to do *anything* if the answer from there is off. As a follow-up to my last email. I have just uninstalled NetworkManager and twitux works fine. great! P.S. If you want me to test anything on my machine I am more than happy to help. No need. Now that I know what's going on I can conduct futher testing locally. Thanks for the report, I will probably forward this upstream for them to work out some sort of solution. I believe that twitux should at least warn somehow about its thinking there is no network. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503205: twitux: Will not connect to twitter.
On Fri, Oct 24, 2008 at 07:57:05AM +0100, Lawrence Woodman wrote: Hello Rodrigo, Some answers to your questions follow: ... [ Everything OK ] ... This probably doesn't help much, other than to eliminate the obvious. If you want me to try anything else, please don't hesitate to contact me. Yes, it all looks good. And I just can't reproduce it, for me it's working all right, which leaves me empty of ideas on how to debug :( Ok, since you've been willing to strace before: Can you try to strace *while* it's trying to connect? I think a way to do that would be to click on 'Disconnect', start the trace (or note the timestamp, or something) then click on 'Connect'. Let's try to see if it's getting stuck somewhere in particular. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503205: twitux: Will not connect to twitter.
On Thu, Oct 23, 2008 at 03:08:00PM +0100, Lawrence Woodman wrote: Package: twitux Version: 0.62-1 Severity: grave Justification: renders package unusable No matter what I do when ever I run twitux, it will not connect. I have switched to using gtwitter without any problems, but twitux refuses. Mmm. Are you *running* gnome-keyring-daemon? It's part of a default Gnome session, but if you are using Twitux outside of Gnome you need to start it yourself. Not having it running causes twitux to hang on trying to connect, without any message. You also need dbus running in your session, but unless you have heavily customized your X session scripts, that runs by default. I have done a partial strace on it which I will include at the bottom of the post which shows that it is having problems with all sorts of libraries not being symbolically linked to places where it is expecting it. This cannot posibly be the problem. If twitux did not find these libraries at all, it would not even start. So, what you are seeing is the result of twitux looking for them in a lot of places before actually finding them. In any case, to confirm, run $ ldd /usr/bin/twitux That will print out the locations where the libraries are ultimately found, or a message if they are not. open(/usr/lib32/xorg/tls/x86_64/libgconf-2.so.4, O_RDONLY) = -1 ENOENT (No such file or directory) stat(/usr/lib32/xorg/tls/x86_64, 0x7fff3dcac5d0) = -1 ENOENT (No such file or directory) open(/usr/lib32/xorg/tls/libgconf-2.so.4, O_RDONLY) = -1 ENOENT (No such file or directory) stat(/usr/lib32/xorg/tls, 0x7fff3dcac5d0) = -1 ENOENT (No such file or directory) open(/usr/lib32/xorg/x86_64/libgconf-2.so.4, O_RDONLY) = -1 ENOENT (No such file or directory) stat(/usr/lib32/xorg/x86_64, 0x7fff3dcac5d0) = -1 ENOENT (No such file or directory) open(/usr/lib32/xorg/libgconf-2.so.4, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/xorg/tls/x86_64/libgconf-2.so.4, O_RDONLY) = -1 ENOENT (No such file or directory) stat(/usr/lib64/xorg/tls/x86_64, 0x7fff3dcac5d0) = -1 ENOENT (No such file or directory) open(/usr/lib64/xorg/tls/libgconf-2.so.4, O_RDONLY) = -1 ENOENT (No such file or directory) stat(/usr/lib64/xorg/tls, 0x7fff3dcac5d0) = -1 ENOENT (No such file or directory) open(/usr/lib64/xorg/x86_64/libgconf-2.so.4, O_RDONLY) = -1 ENOENT (No such file or directory) stat(/usr/lib64/xorg/x86_64, 0x7fff3dcac5d0) = -1 ENOENT (No such file or directory) open(/usr/lib64/xorg/libgconf-2.so.4, O_RDONLY) = -1 ENOENT (No such file or directory) BTW, none of these are default locations for shared libraries in Debian. I don't think it's related to the problem, but you should look at your /etc/ld.so.conf and the LD_LIBRARY_PATH environment var. Something is messing with them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474736: Downgrading Bug#474736 to important
Eric Cooper [EMAIL PROTECTED] When I click on this feed: http://www.borowitzreport.com/, the first item is (currently) the following. Liferea pops up a browser window for the embedded URL in the iframe whenever I try to display headlines -- I'm not even trying to read the body of the item. The fact that the link points to a site in Changzhou, China, and the strange nesting of the end tag -- /iframe/iframe -- makes me think this feed was hijacked, so liferea's behavior is a security hole. As I stated in the original bug report, I don't quite agree with the security hole characterization of this bug, as it is essentially imposible for liferea to detect a hijacked feed. This bug is currently the only reason for liferea not to be in lenny. Since upstream has stated that the 1.4 series will *not* be updated to deal with this issue, and I lack the time for now to attempt a backport, this means a fix for this will not be ready before the freeze. Would I be justified in downgrading this to important? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487629: keytouch blocks logout
On Fri, Jul 18, 2008 at 11:49:25PM +0200, Javier Ortega Conde (Malkavian) wrote: Yeah!, these are first lines from keytouch changelog: Version 2.4.0: - Updated kernel keycode to X keycode mapping. - Updated translations. * keytouchd: - XCloseDisplay is not called anymore, because on some systems it may not return from this call. Sorry, everyone, I have been extremely busy lately *and* without internet access at home. If someone is able to create an updated package you have my blessing to upload it as an NMU. Otherwise, you'll just have to wait for me to get a little time off my day job, in a couple weeks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482644: nmu proposal for stunnel
Looks OK, please go ahead with the NMU. On Tue, May 27, 2008 at 12:31:23AM +1000, Steffen Joeris wrote: Hi Attached you'll find a proposed NMU patch including the upstream bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474736: liferea: opens browser for titles and descriptions with embedded URLs
[Sorry about the delay answering, I've been (and wil remain for a while) busy and kind of disconected, so there will likely be more delays.] On Mon, Apr 07, 2008 at 09:43:08AM -0400, Eric Cooper wrote: When I click on this feed: http://www.borowitzreport.com/, the first item is (currently) the following. Liferea pops up a browser window for the embedded URL in the iframe whenever I try to display headlines -- I'm not even trying to read the body of the item. I've tried without success to reproduce this. Could you send me the settings you have in the browser tab, please. Also, I assume you're not using the webkit backend, but please confirm this. The fact that the link points to a site in Changzhou, China, and the strange nesting of the end tag -- /iframe/iframe -- makes me think this feed was hijacked, so liferea's behavior is a security hole. The problem with this characterization is that liferea has no way of knowing whether a feed's content is unauthorized. I do agree that opening a browser window is wrong, but there's no way we could filter quite a bit of other hijackable behaviour, such as including images in a feed's description, for example. Thus, i kind of question calling this a security issue. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#433393: liferea doesn't update any feeds after migration to new format
On Mon, Mar 17, 2008 at 02:21:14PM +0200, Eddy Petrișor wrote: Luis Rodrigo Gallardo Cruz wrote: On Thu, Mar 13, 2008 at 02:33:54AM +0200, Eddy Petrișor wrote: On to more promising lands: Could you try running with --debug-update, please? I moved away the ~/.liferea_1.4 directory (safe copy) and ran: liferea --debug-update 21 | tee liferea_update The log is attached. I hate Heisenbugs. Not sure this is one. I see nothing obviously wrong in this log. Even worse, there are entries there about updating the feeds, mentioning relatively recent entries in, for example, Debian Planet. Did it keep failing after this update? Yes, for instance, Debian Planet is still stuck at that post, Sami Haahtinen: Installing Debian on NSLU2 from the 6th of March. Mmm. This makes me think it's reading them but then not commiting them to the database. Maybe something in the cache settings is malfunctioning. Do you want me to send also the .liferea dir on which the upgrade is based? Yes, please, unless it contains private data. Note that the message after the update refers to an inexistent ~/.liferea_1.2 directory. You might want to fix that, too. Should I open another bug about this? Yes, please. Still, could it be because the upgrade is not made through an intermediate 1.2 version? I don't think so. I tried updating a default 1.0 install directly to 1.4 and it all worked without fault. So the whole thing has probably something to do with your data. signature.asc Description: Digital signature
Bug#433393: liferea doesn't update any feeds after migration to new format
On Mon, Mar 17, 2008 at 09:48:40PM +0200, Eddy Petrișor wrote: Lars Lindner wrote: Nonetheless I identified the problem. You do massively mark posts as important (flagged). Which is not forbidden, but was totally unexpected by me when I implemented the merging algorithm. Heh :-) . I usually do that so I can come back to them at any time I want to do read about the subject of the post. Is a way of archiving for me (since I saw is he only way to make liferea keep those posts from being lost into nothingness). Flagged items do have the property of never being dropped from Which is good :-), from my PoV. cache, but at the same moment we have a cache limit that the merging algorithm has to cope with. And the current calculation is simple: if the cache limit is 100 (like in your case and per default) and there are 100 (or more) flagged items that must never be dropped, then there is just no room to add new items. kaboom :-) As a temporary workaround you should increase the cache limit for all affected feeds (like the Debian Planet feed). I have, but it seems it already lost some of the items of the day... I'll probably change the limit first, then upgrade once more to the new format ;-) . If this works for you, please let me know. I'll then downgrade this report's severity but leave it open as a hint for others. (BTW, I'll probably send another BR about it disrupting with my desire to have low battery consumption since it does polling and wakes up the CPU rather often.) Does it? We had a round of updates back in 1.2 dealing with this. According to powertop we got down to a rather acceptable level, IIRC. signature.asc Description: Digital signature
Bug#433393: liferea doesn't update any feeds after migration to new format
On Thu, Mar 13, 2008 at 02:33:54AM +0200, Eddy Petrișor wrote:
Luis Rodrigo Gallardo Cruz wrote:
And the migration of *that* is done by a simple copying over of the
file to the new .liferea_1.4 dir. Which pretty much rules out an error
there. Still, just to make sure, please take a look at that file and
try to see the entries for the failing feeds and compare them with the
file in the new dir.
0 [EMAIL PROTECTED] ~ $ grep -n 'updateInterval' ~/.liferea/feedlist.opml |
sed
-r -e 's#^.*(text=[^]*).*(updateInterval=[^]*).*$#\1 \2#g'
/tmp/strippeduiold
0 [EMAIL PROTECTED] ~ $ grep -n 'updateInterval' ~/.liferea_1.4/feedlist.opml
|
sed -r -e 's#^.*(text=[^]*).*(updateInterval=[^]*).*$#\1 \2#g'
/tmp/strippeduinew
0 [EMAIL PROTECTED] ~ $ diff -u /tmp/strippedui{old,new}
--- /tmp/strippeduiold2008-03-13 01:35:38.0 +0200
+++ /tmp/strippeduinew2008-03-13 01:35:48.0 +0200
@@ -17,7 +17,7 @@
text=Heron's Perch updateInterval=-1
text=Schneier on Security updateInterval=-1
text=Joel on Software updateInterval=-1
-text=mariuss' weblog - updateInterval=-1
+text=mariuss' weblog - updateInterval=-1
text=Planet Haskell updateInterval=-1
text=Stevey's Blog Rants updateInterval=-1
text=Razvan Patrascioiu - public_html updateInterval=-1
@@ -28,9 +28,6 @@
text=Programming updateInterval=-1
text=Real World Haskell: recent comments updateInterval=-1
text=Natali Del Conte updateInterval=-1
-text=Unread updateInterval=-2
-text=Flagged updateInterval=-2
text=ATI Proprietary Linux Driver Releases updateInterval=360
text=Syllable.org updateInterval=-1
-text=svn-buildpackage updateInterval=-2
text=Latest Secunia Security Advisories updateInterval=30
Nothing wrong here, it seems.
On to more promising lands:
Could you try running with --debug-update, please?
I moved away the ~/.liferea_1.4 directory (safe copy) and ran:
liferea --debug-update 21 | tee liferea_update
The log is attached.
I hate Heisenbugs.
I see nothing obviously wrong in this log. Even worse, there are
entries there about updating the feeds, mentioning relatively recent
entries in, for example, Debian Planet.
Did it keep failing after this update?
Note that the message after the update refers to an inexistent
~/.liferea_1.2 directory. You might want to fix that, too. Should I open
another bug about this?
Yes, please.
signature.asc
Description: Digital signature
Bug#433393: liferea doesn't update any feeds after migration to new format
On Tue, Mar 11, 2008 at 01:07:04AM +0200, Eddy Petrișor wrote: Luis Rodrigo Gallardo Cruz wrote: Otherwise, please check the feed properties to see if the update intervals were imported correctly. Check also the default interval set in preferences. I don't care about each feed's update interval, I override all with the default interval which is 15 minutes. But, did liferea import that setting correctly from the previous version? signature.asc Description: Digital signature
Bug#433393: liferea doesn't update any feeds after migration to new format
On Wed, Mar 12, 2008 at 12:34:47AM +0200, Eddy Petrișor wrote: On 11/03/2008, Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: On Tue, Mar 11, 2008 at 01:07:04AM +0200, Eddy Petrișor wrote: Luis Rodrigo Gallardo Cruz wrote: Otherwise, please check the feed properties to see if the update intervals were imported correctly. Check also the default interval set in preferences. I don't care about each feed's update interval, I override all with the default interval which is 15 minutes. But, did liferea import that setting correctly from the previous version? REPLY=have to check and need help to see the old setting [ $that ==$deafult_update_interval ] REPLY=yes (grumble grumble) I've taken a look at a migration from 1.0. The update interval setting is stored in an attribute of the feed entry in ~/.liferea/feedlist.opml And the migration of *that* is done by a simple copying over of the file to the new .liferea_1.4 dir. Which pretty much rules out an error there. Still, just to make sure, please take a look at that file and try to see the entries for the failing feeds and compare them with the file in the new dir. On to more promising lands: Could you try running with --debug-update, please? signature.asc Description: Digital signature
Bug#433393: liferea doesn't update any feeds after migration to new format
On Fri, Mar 07, 2008 at 08:05:45PM +0200, Eddy Petrișor wrote: Since liferea I updated to this version and liferea updated its database to the new format, none of the feeds are updated anymore. For instance, Planet Debian has the tip stuck on http://ressukka.net/blog/posts/20070517_debian_on_nslu2/ It seems either the upgrade or the database format upgrade, it has stuck. Does liferea start up correctly after the update? If not, maybe you hit #469245, please try the workaround suggested there (delete ~/.liferea_1.4/new_subscription and restart liferea). Otherwise, please check the feed properties to see if the update intervals were imported correctly. Check also the default interval set in preferences. Thanks. signature.asc Description: Digital signature
Bug#464139: Fwd: [Debian Bug#464139: sawfish crash openoffice]
On Tue, Feb 05, 2008 at 04:07:10PM +0100, Janek Kozicki wrote: Christian Marillat said: Each time I try to open the options window, sawfish crash and openoffice is also dead. Hi, What is the openoffice version? On debian etch I'm unable to reproduce this: File-Templates-Organize File-Templates-Edit Tools-Options all work fine. Very likely the version is the one in debian unstable, 1:2.3.1-3. Is this right, Christian? Luis Rodrigo Gallardo Cruz said: Can someone here try to reproduce this? I don't have openoffice installed, and I'd rather avoid it if I can. why 'aptitude install openoffice.org' and 'aptitude remove openoffice.org' (after testing) wouldn't work for you? ;- Beacuse I'd rather not download I don't even know how many megabytes :) But well, it seems I'll have to. signature.asc Description: Digital signature
Bug#464139: Fwd: [Debian Bug#464139: sawfish crash openoffice]
On Tue, Feb 05, 2008 at 04:27:34PM +0100, Christian Marillat wrote: Janek Kozicki [EMAIL PROTECTED] writes: Christian Marillat said: Each time I try to open the options window, sawfish crash and openoffice is also dead. Hi, Hi, What is the openoffice version? On debian etch I'm unable to reproduce this: Woah! Reproduced. I just killed my whole session. It's locale related, with OOo in English nothing happens. With the fr translation it dies immediately. That points to my patch :( I'll run sawfish+OOo in an Xnest and try to get a backtrace. signature.asc Description: Digital signature
Bug#464139: Fwd: [Debian Bug#464139: sawfish crash openoffice]
tag 464139 confirmed upstream thanks On Tue, Feb 05, 2008 at 05:11:34PM +0100, Janek Kozicki wrote: Luis Rodrigo Gallardo Cruz said: (by the date of Tue, 5 Feb 2008 09:58:08 -0600) Woah! Reproduced. I just killed my whole session. It's locale related, with OOo in English nothing happens. With the fr translation it dies immediately. That points to my patch :( I'll run sawfish+OOo in an Xnest and try to get a backtrace. Remember that there is Timo's UTF8 patch waiting in queue. Try it. http://sawfish.wikia.com/wiki/Utf_8_names_fix The patch solves the crash. But I'm completely confused. The problem here was that OOo does not set the NET_ properties, only the WM_ ones. My patch was trying unconditionaly to convert the strings there from the locale encoding to UTF-8, causing the crash since they came as ISO-8859-1 but the locales (all of them, sawfish, the nested x server and OOo) *were* UTF-8. Adding to my confusion, the patch solves this by passing the property to Xutf8TextPropertyToTextList, which correctly decodes it to UTF-8, despite its name making me think it was supposed to do the oposite or something. Whatever. Given this, I say we should do a new point release with this patch. I'll test the other patch (Titlebar updates) in a little while, but it seems to me it should be included, too. signature.asc Description: Digital signature
Bug#464001: FTBFS: hardcodes architecture-specific path to rep's rules.mk
Version: 1:1.3.2+debian-1 From http://buildd.debian.org/fetch.cgi?pkg=sawfish;ver=1%3A1.3.2-1;arch=amd64;stamp=1202040828 : [...] /usr/bin/fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp [ ! -f Makefile ] || /usr/bin/make distclean make[1]: Entering directory `/build/buildd/sawfish-1.3.2' Makedefs:85: /usr/lib/rep/i486-pc-linux-gnu/rules.mk: No such file or directory make[1]: *** No rule to make target `/usr/lib/rep/i486-pc-linux-gnu/rules.mk'. Stop. make[1]: Leaving directory `/build/buildd/sawfish-1.3.2' make: *** [clean] Error 2 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules clean gave error exit status 2 [...] This appears to stem from a conjunction of sloppiness on upstream's part (shipping platform-specific generated files) and increased strictness on Debian's. AFAICT, you can work around it without having to prepatch anything by specifying repexecdir via a command-line wildcard: [ ! -f Makefile ] || /usr/bin/make distclean repexecdir=/usr/lib/rep/*-* I didn't even try this. My workaround was to repack upstream's tarball without the generated files. Already uploaded, as 1.3.2+debian-1 Thanks for the report. signature.asc Description: Digital signature
Bug#431855: Unreproducible bug#431855
tag 431855 unreproducible thanks This bug might have been caused by some transient error. I see nothing in the postrm script nor in update-rc.d that could obviously fail with error code 20, and a run of piuparts -t /var/cache/pbuilder/build/ -N --warn-on-others -i /var/log/apt/term.log --apt isdnutils-base has just finished without error in my system. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#451268: Bug in makeinfo or install-info?
reopen 451268 block 456791 451268 thanks On Mon, Dec 17, 2007 at 07:01:11PM +0100, Santiago Ruano Rincón wrote: ... Unpacking replacement bzip2 ... Setting up bzip2 (1.0.3-7) ... install-info(/usr/share/info/bzip2.info): warning, ignoring confusing INFO-DIR-ENTRY in file. No `START-INFO-DIR-ENTRY' and no `This file documents'. install-info(/usr/share/info/bzip2.info): unable to determine description for `dir' entry - giving up dpkg: error processing bzip2 (--install): subprocess post-installation script returned error exit status 1 The problem is with bzip2.info, produced by makeinfo during the building process. A very similar bug hit librep-doc about a week ago (#451265) and, just today, sawfish (#456791) It was cloned as #451268 and supposedly solved on Nov 14, but it seems to have come back. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#454184: liferea: Segmentation fault during startup on lenny
tag 454184 unreproducible severity 454184 important thanks On Mon, Dec 03, 2007 at 10:31:36PM +0100, Andrzej Adam Filip wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb72eab20 (LWP 21768)] 0xb7ef4c1b in mozsupport_set_zoom () from /usr/lib/liferea/liblihtmlx.so Well, no matter what I try, I can't reproduce this bug. Maybe it's being triggered by a specific feed in your configuration. Since it's probably a configuration specific thing, I'm reducing the severity to important, as it only seems to affect you and not every user. I recommend you to update to the version of liferea in sid and re-test. Liferea 1.4 is stable enough for lenny, but it hasn't been able to transition because it's failed to build on some architectures. Sorry about the long time between answers. signature.asc Description: Digital signature
Bug#456372: libwebkitgtk0d: uninstallable due to dependency on libicu36
On Sat, Dec 15, 2007 at 12:25:02AM +, brian m. carlson wrote: libwebkitgtk0d depends on libicu36, but it is not in the archive. It has since been superseded by libicu38. Since the package's build-depends are correct, this bug will be solved by a simple rebuild of the package. Mike stated that he plans to upload soonish, so it probably doesn't make sense to ask -release for binNMUs. It will be better to just wait a few days. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#451265: postinst still fails. Should librep-doc be rebuilt with a fixed texinfo?
Package: librep-doc Version: 0.17+svn20070119-5 Followup-For: Bug #451265 Even tough the reason of this bug was in texinfo, it seems that caused the info files in librep-doc to be badly generated. I suppose a simple rebuild of the package ought to fix this, but this probably needs to be done by an upload, since this is an Arch: all package. $ sudo env -u LANG dpkg --configure librep-doc Setting up librep-doc (0.17+svn20070119-5) ... install-info(/usr/share/info/librep.info): warning, ignoring confusing INFO-DIR-ENTRY in file. No `START-INFO-DIR-ENTRY' and no `This file documents'. install-info(/usr/share/info/librep.info): unable to determine description for `dir' entry - giving up dpkg: error processing librep-doc (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: librep-doc -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#454184: liferea: Segmentation fault during startup on lenny
On Mon, Dec 03, 2007 at 08:36:41PM +0100, Andrzej Filip wrote: Below please find tail of output produced by liferea --debug-all --debug-verbose TRACE: + update_request_new TRACE: - update_request_new TRACE: - feedlist_auto_update GUI: Setting threePane mode: off UPDATE: download result - HTTP status: 200, error: 0, netio error:0, data: 138812600 UPDATE: request finished UPDATE: waiting for request... UPDATE: processing received request (http://art.gnome.org/backend.php) UPDATE: downloading http://art.gnome.org/backend.php GUI: Setting threePane mode: off Segmentation fault Could you test with the version from sid? Also, if you could obtain a backtrace, it would be enormously helpful. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#454184: liferea: Segmentation fault during startup on lenny
On Mon, Dec 03, 2007 at 10:31:36PM +0100, Andrzej Adam Filip wrote: Luis Rodrigo Gallardo Cruz wrote: Could you test with the version from sid? Also, if you could obtain a backtrace, it would be enormously helpful. I have used modified startup script to start liferea-bin under gdb. Below please find tail of the debug output: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb72eab20 (LWP 21768)] 0xb7ef4c1b in mozsupport_set_zoom () from /usr/lib/liferea/liblihtmlx.so Please send the whole backtrace as an attachment. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#451016: liferea: Crash after startup
merge 451016 444888 thanks On Mon, Nov 12, 2007 at 10:53:40PM +0100, Pau Rul-lan Ferragut wrote: It seams that the problem is this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+444888 Could you make my bug duplicated and forward the info to the other one? Ups. Sorry, didn't look at your locale settings, I would have suspected much earlier. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#451016: liferea: Crash after startup
On Mon, Nov 12, 2007 at 10:53:40PM +0100, Pau Rul-lan Ferragut wrote: With a vanilla unstable at today liferea starts and shortly crashes. Were you doing anythin in particular? Do you know if an update was running at the time? How much is 'shortly'? warning: .dynamic section for /usr/lib/libglib-2.0.so.0 is not at the expected address (wrong library or version mismatch?) ERROR: No output during decompression Did your update go ok? Does the problem persist after restaring liferea? Just for the record, the following are the libraries you have on a different version than I do. The problem _might_ be there, but I don't know. lib| my version | yours gconf2 2.20.0-1 2.20.1-1 libgconf2-4 2.20.0-1 2.20.1-1 libc6 2.6.1-1+b12.6.1-6 libfontconfig1 2.4.2-1.2 2.4.91-1 libglib2.0-02.14.1-5 2.14.3-1 libnm-glib0 0.6.5-1 0.6.5-3 libnspr4-0d 1.8.0.14~pre071019b-0lenny1 4.6.7-1 libxul0d1.8.1.4-1 1.8.1.9-1 zlib1g 1:1.2.3.3.dfsg-6 1:1.2.3.3.dfsg-7 -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#444888: Segfault on feed update
On Mon, Oct 01, 2007 at 07:48:54PM -0500, Luis Rodrigo Gallardo Cruz wrote: In case you'd like to try, there is an i386 1.4.4 package available at http://www.nul-unu.net/quien/rodrigo/debian/liferea/liferea_1.4.4-1~1_i386.deb I've finally managed to reproduce the bug. My fault all along, for not using the ca_ES locale. Turns out the ca translation for this string is: #: ../src/ui/ui_mainwindow.c:1228 #, c-format msgid (%d new) msgid_plural (%d new) msgstr[0] (% nova) msgstr[1] (% noves) Note the missing 'd' I have not, however, been able to reproduce anything under es. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#448272: liferea-webkit segfaults with embedded flash in feeds
# On Mon, Oct 29, 2007 at 09:59:06PM +0100, Lars Lindner wrote: # WebKit is known to crash regularily in curl. It is usually # reproducable within Liferea when the viewed headline contains images # that are loaded asynchronously. clone 448272 -1 reassign -1 libwebkitgtk0d block 448272 -1 thanks -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#438704: [patch] grun: As of gtk 2.12, #438704 causes a segfault on
I have created a complete patch for this bug. I will ask for sponsorship to upload this as an NMU in 7 days. This patch has been uploaded as -14.1 and is currently waiting in the delayed/6 queue. Please, if you don't agree with the patch, cancel the delayed upload by making a higher numbered one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406729: Patch from ubuntu fixes this bug
tag 406729 patch thanks The diff to ubuntu version scanerrlog_2.01-4ubuntu1 is a complete patch to this bug, as suggested by the original reporter. http://patches.ubuntu.com/s/scanerrlog/scanerrlog_2.01-4ubuntu1.patch signature.asc Description: Digital signature
Bug#406729: Patch from ubuntu fixes this bug
On Sat, Oct 06, 2007 at 09:44:34AM +0200, Josselin Mouette wrote: Le samedi 06 octobre 2007 à 01:20 -0500, Luis Rodrigo Gallardo Cruz a écrit : The diff to ubuntu version scanerrlog_2.01-4ubuntu1 is a complete patch to this bug, as suggested by the original reporter. http://patches.ubuntu.com/s/scanerrlog/scanerrlog_2.01-4ubuntu1.patch Of course this patch is wrong as well, because it adds XS-Python-Version: current, which is incorrect for an architecture: all package. Where is this documented? And what's the proper value for an application package, shipping no modules? signature.asc Description: Digital signature
Bug#406729: Patch from ubuntu fixes this bug
On Sat, Oct 06, 2007 at 08:31:17AM -0500, Luis Rodrigo Gallardo Cruz wrote: On Sat, Oct 06, 2007 at 09:44:34AM +0200, Josselin Mouette wrote: Of course this patch is wrong as well, because it adds XS-Python-Version: current, which is incorrect for an architecture: all package. Where is this documented? And what's the proper value for an application package, shipping no modules? I found http://people.debian.org/~srivasta/manoj-policy/x316.html which states that the correct value is 'all'. Could you please confirm that? Thanks. signature.asc Description: Digital signature
Bug#423349: RM: mozilla-locale-tr
severity 423349 normal reassign 423349 ftp.debian.org retitle 423349 RM: mozilla-locale-tr -- RoQA, old, depends on mozilla thanks - Forwarded message from Roberto C. Sánchez [EMAIL PROTECTED] - On Wed, Oct 03, 2007 at 07:43:27PM -0500, Luis Rodrigo Gallardo Cruz wrote: As Michael Ablassmeier stated in #423349, back in May, mozilla-locale-tr is superfluous due to mozilla removal. The package's maintainer never responded to that bug. Has anyone any objection if I file for removal on behalf of QA? Go ahead. I am all about removing cruft. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com - End forwarded message - -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#444888: Segfault on feed update
In case you'd like to try, there is an i386 1.4.4 package available at http://www.nul-unu.net/quien/rodrigo/debian/liferea/liferea_1.4.4-1~1_i386.deb Look at http://www.nul-unu.net/quien/rodrigo/debian/liferea/liferea_1.4.4-1~1_i386.changes for filenames, in case you need the -dbg package, or the sources. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#438704: [patch] grun: As of gtk 2.12, #438704 causes a segfault on
program startup
Reply-To:
In-Reply-To: [EMAIL PROTECTED]
I have created a complete patch for this bug. I will ask for
sponsorship to upload this as an NMU in 7 days.
--
diff -u grun-0.9.2/debian/changelog grun-0.9.2/debian/changelog
--- grun-0.9.2/debian/changelog
+++ grun-0.9.2/debian/changelog
@@ -1,3 +1,13 @@
+grun (0.9.2-14.1) unstable; urgency=low
+
+ * grun.c: Call bind_textdomain_codeset() to have gettext recode strings
+to UTF-8. (Closes: #438704).
+ * po/*.po: Set ISO-8859-1 encoding headers.
+ * debian/rules: Remove po/*gmo files on configure, to force regenerating
+with correct encoding headers.
+
+ -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Mon, 24 Sep 2007 14:26:41
-0500
+
grun (0.9.2-14) unstable; urgency=low
* grun.c: yet another fix of auto-completion (closes: #281334)
diff -u grun-0.9.2/debian/rules grun-0.9.2/debian/rules
--- grun-0.9.2/debian/rules
+++ grun-0.9.2/debian/rules
@@ -23,7 +23,7 @@
dh_testdir
# Add here commands to configure the package.
./configure --with-default-xterm=x-terminal-emulator --enable-testfile
--enable-associations --prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info
-
+ -rm po/*gmo
touch configure-stamp
build: configure-stamp build-stamp
diff -u grun-0.9.2/config.guess grun-0.9.2/config.guess
diff -u grun-0.9.2/config.sub grun-0.9.2/config.sub
diff -u grun-0.9.2/grun.c grun-0.9.2/grun.c
--- grun-0.9.2/grun.c
+++ grun-0.9.2/grun.c
@@ -40,6 +40,7 @@
#include grun2.xpm
#if defined (HAVE_GETTEXT) || defined (HAVE_CATGETS)
#include libintl.h
+#define UTF8 UTF-8
#else
#include intl/libintl.h
#endif
@@ -1107,6 +1108,7 @@
#ifndef WIN32
setlocale (LC_ALL, );
bindtextdomain (PACKAGE, LOCALEDIR);
+ bind_textdomain_codeset (PACKAGE, UTF8);
textdomain (PACKAGE);
#endif /* WIN32 */
only in patch2:
unchanged:
--- grun-0.9.2.orig/po/de.po
+++ grun-0.9.2/po/de.po
@@ -7,12 +7,12 @@
msgstr
Project-Id-Version: gRun 0.9.2\n
POT-Creation-Date: 1999-02-06 15:28+0200\n
-PO-Revision-Date: 1999-02-06 13:54+0200\n
+PO-Revision-Date: 2007-09-24 14:24-0500\n
Last-Translator: Dominik Brettnacher [EMAIL PROTECTED]\n
Language-Team: Dominik Brettnacher [EMAIL PROTECTED]\n
MIME-Version: 1.0\n
-Content-Type: text/plain; charset=CHARSET\n
-Content-Transfer-Encoding: ENCODING\n
+Content-Type: text/plain; charset=ISO-8859-1\n
+Content-Transfer-Encoding: 8bit\n
#: grun.c:838
msgid Choose Application
only in patch2:
unchanged:
--- grun-0.9.2.orig/po/es.po
+++ grun-0.9.2/po/es.po
@@ -2,17 +2,16 @@
# Copyright (C) 1999 Southern Gold Development
# Esteban Manchado [EMAIL PROTECTED], 1999.
#
-#, fuzzy
msgid
msgstr
Project-Id-Version: gRun 0.9.2\n
POT-Creation-Date: 1999-02-06 15:28+0200\n
-PO-Revision-Date: 1999-02-06 13:54+0200\n
+PO-Revision-Date: 2007-09-21 19:51-0500\n
Last-Translator: Esteban Manchado [EMAIL PROTECTED]\n
Language-Team: Esteban Manchado [EMAIL PROTECTED]\n
MIME-Version: 1.0\n
-Content-Type: text/plain; charset=CHARSET\n
-Content-Transfer-Encoding: ENCODING\n
+Content-Type: text/plain; charset=ISO-8859-1\n
+Content-Transfer-Encoding: 8bit\n
#: grun.c:838
msgid Choose Application
only in patch2:
unchanged:
--- grun-0.9.2.orig/po/fr.po
+++ grun-0.9.2/po/fr.po
@@ -7,12 +7,12 @@
msgstr
Project-Id-Version: gRun 0.9.2 \n
POT-Creation-Date: 1999-02-06 15:28+0200\n
-PO-Revision-Date: 1999-02-06 14:+0200\n
+PO-Revision-Date: 2007-09-24 14:23-0500\n
Last-Translator: Mathieu Lutfy [EMAIL PROTECTED]\n
Language-Team: Mathieu Lutfy [EMAIL PROTECTED]\n
MIME-Version: 1.0\n
-Content-Type: text/plain; charset=CHARSET\n
-Content-Transfer-Encoding: ENCODING\n
+Content-Type: text/plain; charset=ISO-8859-1\n
+Content-Transfer-Encoding: 8bit\n
#: grun.c:838
msgid Choose Application
only in patch2:
unchanged:
--- grun-0.9.2.orig/po/pt.po
+++ grun-0.9.2/po/pt.po
@@ -7,12 +7,12 @@
msgstr
Project-Id-Version: gRun 0.9.2\n
POT-Creation-Date: 1999-02-06 15:28+0200\n
-PO-Revision-Date: 1999-02-06 13:58+0200\n
+PO-Revision-Date: 2007-09-24 14:23-0500\n
Last-Translator: Frédéric L.W.Meunier [EMAIL PROTECTED]\n
Language-Team: Frédéric L.W.Meunier [EMAIL PROTECTED]\n
MIME-Version: 1.0\n
-Content-Type: text/plain; charset=CHARSET\n
-Content-Transfer-Encoding: ENCODING\n
+Content-Type: text/plain; charset=ISO-8859-1\n
+Content-Transfer-Encoding: 8bit\n
#: grun.c:838
msgid Choose Application
--
--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
signature.asc
Description: Digital signature
Bug#432829: Status of grokking-the-gimp in Debian
On Mon, Sep 03, 2007 at 01:09:58PM -0500, Luis Rodrigo Gallardo Cruz wrote: I have noticed that your grokking-the-gimp package has not been updated in a long while, including not answering a RC bug report (#432829). Given Aaron's lack of response to this queries, I assume he has lost interest in the package. I will wait until the end of the month and then mark this package as orphaned. I will not ask for removal, given Roberto's statement about the package's continued usefulness. signature.asc Description: Digital signature
Bug#432829: Status of grokking-the-gimp in Debian
Hello. I have noticed that your grokking-the-gimp package has not been updated in a long while, including not answering a RC bug report (#432829). If you are no longer interested in this package, please consider orphaning it so someone else with interest may pick it up. Alternatively, if you consider the package is no longer relevant, please ask for its removal. In making a decision do take into account the concerns expressed in the bug report. Please note that I'm not interested in adopting the package. Thank you for your work in Debian. signature.asc Description: Digital signature
Bug#427326: Patch for libgdchart-gd2 #427326
tags 427326 patch
usertags 427326 patch-provided
thanks
The attached patch makes use of d-shlibs --override feature
(introduced in 0.30) to solve this problem.
I'm not certain if this override should be included by d-shlibs, since
it is different for each of the packages, depending on whether one is
using {xpm,no-xpm}.
--
diff -r 9b17011c4e7e debian/control
--- a/debian/controlMon Sep 03 14:20:02 2007 -0500
+++ b/debian/controlMon Sep 03 16:55:21 2007 -0500
@@ -2,7 +2,7 @@ Section: libs
Section: libs
Priority: optional
Maintainer: Jonas Smedegaard [EMAIL PROTECTED]
-Build-Depends: cdbs (= 0.4.23-1.1), debhelper (= 4.1.0), dh-buildinfo,
patchutils (= 0.2.25), d-shlibs ( 0.23), libgd2-noxpm-dev ( 2.0.28),
libxpm-dev | xlibs-dev ( 4.3.0), libxt-dev | xlibs-dev ( 4.3.0)
+Build-Depends: cdbs (= 0.4.23-1.1), debhelper (= 4.1.0), dh-buildinfo,
patchutils (= 0.2.25), d-shlibs ( 0.30), libgd2-noxpm-dev ( 2.0.28),
libxpm-dev | xlibs-dev ( 4.3.0), libxt-dev | xlibs-dev ( 4.3.0)
Standards-Version: 3.6.2
Package: libgdchart-gd2-noxpm-dev
diff -r 9b17011c4e7e debian/rules
--- a/debian/rules Mon Sep 03 14:20:02 2007 -0500
+++ b/debian/rules Mon Sep 03 16:55:21 2007 -0500
@@ -118,12 +118,12 @@ binary-install/$(package)-noxpm-dev::
ln -sf $(library).so.$(version)
debian/$(package)-noxpm-dev/usr/lib/$(library).so
binary-fixup/$(package)-xpm-dev::
- d-devlibdeps debian/$(package)-xpm-dev.substvars
$(package)-xpm/$(library).so.$(version)
+ d-devlibdeps --override 's/libgd2-dev/libgd2-xpm-dev/'
debian/$(package)-xpm-dev.substvars $(package)-xpm/$(library).so.$(version)
# We don't actually use the XPM calls, so noxpm version is ok
perl -i -pne 's/libgd2-dev/libgd2-noxpm-dev \| libgd2-xpm-dev/g'
debian/$(package)-xpm-dev.substvars
binary-fixup/$(package)-noxpm-dev::
- d-devlibdeps debian/$(package)-noxpm-dev.substvars
$(package)-noxpm/$(library).so.$(version)
+ d-devlibdeps --override 's/libgd2-dev/libgd2-noxpm-dev/'
debian/$(package)-noxpm-dev.substvars $(package)-noxpm/$(library).so.$(version)
# We don't actually use the XPM calls, so noxpm version is ok
perl -i -pne 's/libgd2-dev/libgd2-noxpm-dev \| libgd2-xpm-dev/g'
debian/$(package)-noxpm-dev.substvars
--
signature.asc
Description: Digital signature
Bug#435841: Security issues in slim.
tag 435841 security
thanks
Looking at bug #435841, I came across the following code, which is the
direct source of the problem:
--
void SwitchUser::SetEnvironment() {
char *term = getenv(TERM);
*char** environ;
*environ = (char **) new char*[2];
*environ[0] = 0;
if(term)
putenv(StrConcat(TERM=, term));
putenv(StrConcat(HOME=, Pw-pw_dir));
... [ several more calls to putenv, no further use of environ ] ...
chdir(...)
}
--
Changing the starred lines to a call to clearenv() ought to solve this
particular bug.
However, those lines are such a silly mistake that it makes me
think the author was either sleep or very inexperienced. This app
being a login manager, it really needs careful coding to make sure
there are as few as possible security issues.
Thus, I *do not* recommend this fix be applied as is, but to have
someone with security experience have a *good* look at the code.
signature.asc
Description: Digital signature
Bug#435692: keytouch: Xsession startup script contains syntax errors
Package: keytouch Version: 2.3.1-1 Severity: grave Tags: patch pending Justification: renders package unusable /etc/X11/Xsession.d/55keytouchd_launch contains syntax errors that make the X session fail to start. The following patch solves the problem. It will be included in the next upload. --- Index: debian/55keytouchd_launch === --- debian/55keytouchd_launch (revisión: 4046) +++ debian/55keytouchd_launch (copia de trabajo) @@ -5,10 +5,9 @@ STARTKEYTOUCH=yes KEYTOUCHLAUNCH=/usr/bin/keytouchd-launch -if grep -qs ^disable-session-keytouch $OPTIONFILE +if grep -qs ^disable-session-keytouch $OPTIONFILE \ || ! [ -x $KEYTOUCHLAUNCH ]; then STARTKEYTOUCH='' - fi fi if [ -n $STARTKEYTOUCH ]; then --- -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#435599: keytouch-data: Fails on installation, trying to overwrite a file owned by keytouch
Package: keytouch-data Version: 2.3.1-1 Severity: serious Justification: Policy 7.5.1 Tags: pending Package installation fails if upgrading from a previous version of keytouch, since the keyboard files used to belong to that package, and keytouch-data does not specify a Replaces: field. Current workaround is to retry the installation *after* the error. By that time the previous version of keytouch will have been installed, removing the file ownership. The fix is already applied to the svn repo and will be uploaded soon. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#433586: is serious
# It seems this bug will affect every system with acpi enabled # Raising the severity so it won't migrate to testing. severity 433586 serious thanks -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#422475: 422475 is fixed in experimental
fixed 422475 0.90.1-1 thanks I have verified that the version of matplotlib in experimental builds properly. In case someone wants to backport the patch to unstable, instead of uploading that version to unstable, it appears that the propper change would be to define DEFPY := $(shell pyversions -v -d) at the start of debian/rules plus the following minor change to Amit's patch --- --- matplotlib-0.90.0/debian/rules 2007-06-15 15:53:45.0 +0300 +++ matplotlib-0.90.0.nw/debian/rules 2007-06-15 14:50:10.0 +0300 @@ -70,7 +70,7 @@ # autobuilders. # The plugin abbreviations are: # ns_ = numpy, na_ = numarray, nc_ = numeric - for v in $(PYVERS); do \ + for v in $(DEFPY); do \ for p in na ns nc; do \ for f in transforms.so image.so cntr.so nxutils.so; do \ # Check for these four files for each plugin: \ --- signature.asc Description: Digital signature
Bug#418841: libxerces-java: FTBFS: xerces.jar not found
On Tue, Jun 12, 2007 at 01:14:25PM +0200, Arnaud Vandyck wrote: Thanks to take care of the bug. The build log is gzipped and attached. From the build log: ---snip-- fakeroot debian/rules binary dh_testdir dh_testroot dh_clean -k dh_clean: Compatibility levels before 4 are deprecated. dh_installdirs dh_installdirs: Compatibility levels before 4 are deprecated. ... cd ../class;fastjar cf ../bin/xerces.jar *.info org javax META-INF ; cd ../src make[1]: Leaving directory `/home/arnaud/debian/packages/xerces-j/build-area/xerces-j-1.4.4/src' install -m 644 bin/xerces.jar debian/libxerces-java/usr/share/java/xerces-1.4.4.jar install: cannot create regular file `debian/libxerces-java/usr/share/java/xerces-1.4.4.jar': No such file or directory make: *** [install] Error 1 ---/snip- The error message from install means that the debian/libxerces-java/usr/share/java/ was not created, as was expected, by dh_installdirs. From the warning message from it, I assume what happened is that it created instead debian/tmp/usr/share/java/ which is the behaviour for debhelper compatibility mode 1. The question is, how did it get into such mode? The package includes a debian/compat file with a '4' on it, and the build-dependencies are set to debhelper (= 4.1.0) Are you sure you're working from a pristine copy of the sources? Do you have the propper build-dependencies installed? Are you building on sid? Thanks for any extra info. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#422397: #422397 is due to a missing #include
tag 422397 patch thanks Bug #422397 is caused by a missing #include libgnomeprint/gnome-print-paper.h in src/print.c --[PATCH]--- diff -r b271f6b92571 debian/changelog --- a/debian/changelog Mon Jun 11 23:42:48 2007 -0500 +++ b/debian/changelog Mon Jun 11 23:57:08 2007 -0500 @@ -1,3 +1,11 @@ oregano (0.60.0-1) unstable; urgency=low +oregano (0.60.0-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Add missing include for gnome-print-paper.h to src/print.c +(Closes: #422397). + + -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Mon, 11 Jun 2007 23:56:15 -0500 + oregano (0.60.0-1) unstable; urgency=low * New upstream release. diff -r b271f6b92571 debian/patches/00list --- a/debian/patches/00list Mon Jun 11 23:42:48 2007 -0500 +++ b/debian/patches/00list Mon Jun 11 23:55:37 2007 -0500 @@ -1,3 +1,4 @@ scons.env.cflags scons.env.cflags +include.gnomeprintpaper.dpatch upstream.sync desktop.update diff -r b271f6b92571 debian/patches/include.gnomeprintpaper.dpatch --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/debian/patches/include.gnomeprintpaper.dpatch Mon Jun 11 23:55:18 2007 -0500 @@ -0,0 +1,18 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## include.gnomeprintpaper.dpatch by [EMAIL PROTECTED] +## +## DP: Add missing include for gnome-print-paper.h + [EMAIL PROTECTED]@ +diff -urNad oregano-0.60.0~/src/print.c oregano-0.60.0/src/print.c +--- oregano-0.60.0~/src/print.c2006-09-29 23:47:24.0 -0500 oregano-0.60.0/src/print.c 2007-06-11 23:50:26.551880404 -0500 +@@ -31,6 +31,8 @@ + #include math.h + #include gnome.h + #include libgnomeprint/gnome-print.h ++#include libgnomeprint/gnome-print-paper.h ++ + #include schematic.h + #include schematic-view.h + #include sheet.h --[/PATCH]-- signature.asc Description: Digital signature
Bug#418841: libxerces-java: FTBFS: xerces.jar not found
Can you provide a full build log for this, as well as the installed versions of your build-dependencies? I attempted to work on this problem, but was unable to reproduce it. Thanks signature.asc Description: Digital signature
Bug#424445: Proposed patch for #424445 (turkey FTBFS)
The attached patch sets JAVA_HOME and ant's build.compiler property, as recomended by the java packaging team. This solves the FTBFS. The resulting package works correctly with sun's java, but I have not been able to make it run with gcj. I do not know if it's a problem with the package or with my environment. Thus, I'm not tagging the bug as 'patch' yet. -- diff -r dc7e7243f5a5 debian/control --- a/debian/controlWed May 30 00:33:48 2007 -0500 +++ b/debian/controlWed May 30 07:59:53 2007 -0500 @@ -2,7 +2,7 @@ Section: text Section: text Priority: optional Maintainer: Debian QA Group [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.0.0), jikes, ant, bzip2, txt2man, imagemagick, java-gcj-compat-dev +Build-Depends: debhelper (= 4.0.0), ant, bzip2, txt2man, imagemagick, java-gcj-compat-dev Standards-Version: 3.6.2 Package: turkey diff -r dc7e7243f5a5 debian/rules --- a/debian/rules Wed May 30 00:33:48 2007 -0500 +++ b/debian/rules Wed May 30 08:07:48 2007 -0500 @@ -1,13 +1,14 @@ #!/usr/bin/make -f DESTDIR=$(CURDIR)/debian/turkey +export JAVA_HOME=/usr/lib/jvm/java-1.5.0-gcj-4.1-1.5.0.0/jre build: build-stamp build-stamp: dh_testdir - ant release - ant doc + ant -Dbuild.compiler=modern release + ant -Dbuild.compiler=modern doc txt2man -s 1 -t turkey -B turkey turkey.1.txt2man turkey.1 convert resources/icon.png -resize 32x32 turkey.xpm @@ -19,6 +20,7 @@ clean: rm -f build-stamp configure-stamp rm -f turkey.1 rm -f turkey.png + rm -f turkey.xpm ant clean -- signature.asc Description: Digital signature
Bug#422605: [Patch] #422605 caused by gcjh being replaced by gjavah in gcj = 4.2
tag 422605 patch
thanks
The folowwing patch takes care of the rename and tightens
build-depends to make sure the replacement is caught.
BTW, since this builds entirely with free tools, it might be possible
to build it in all arches, instead of only i386 and amd64 (it seems to
be blocked by the autobuilders, as the package is arch: any).
-[Patch]---
diff -r 75343eaaea8c debian/changelog
--- a/debian/changelog Mon May 14 23:58:18 2007 -0500
+++ b/debian/changelog Tue May 15 01:16:20 2007 -0500
@@ -1,3 +1,12 @@ nbio (2.0-14) unstable; urgency=low
+nbio (2.0-15) unstable; urgency=low
+
+ * QA upload.
+ * Change call of gcjh to gjavah in make-libnbio.sh.
+Update Build-depends to gcj (= 4:4.1.2-2) and added java-gcj-compat
+(Closes #422605).
+
+ -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Tue, 15 May 2007 00:47:53
-0500
+
nbio (2.0-14) unstable; urgency=low
* QA upload.
diff -r 75343eaaea8c debian/control
--- a/debian/controlMon May 14 23:58:18 2007 -0500
+++ b/debian/controlTue May 15 01:07:13 2007 -0500
@@ -2,7 +2,7 @@ Section: libs
Section: libs
Priority: optional
Maintainer: Debian QA Group [EMAIL PROTECTED]
-Build-Depends: debhelper ( 4.1.0), fastjar (= 1:3.2.1-0pre6), gcj (=
3:3.2.1-0pre6), doxygen
+Build-Depends: debhelper ( 4.1.0), fastjar (= 1:3.2.1-0pre6), gcj (=
3:3.2.1-0pre6), java-gcj-compat, doxygen
Standards-Version: 3.7.2
Package: libnbio2-java
diff -r 75343eaaea8c debian/make-libnbio.sh
--- a/debian/make-libnbio.shMon May 14 23:58:18 2007 -0500
+++ b/debian/make-libnbio.shTue May 15 01:02:00 2007 -0500
@@ -41,7 +41,7 @@ PACKAGE=seda.nbio
# the versioned gcc-x.y and gcj-x.y programs are no longer used.
JAVA=/usr/bin/gcj-wrapper
JAVAC=/usr/bin/gcj -C
-JAVAH=/usr/bin/gcjh
+JAVAH=/usr/bin/gjavah
JAR=/usr/bin/fastjar
DOXYGEN=/usr/bin/doxygen
@@ -75,7 +75,7 @@ for classfile in *.class; do
header=jni/${class}.h
echo ${PACKAGE}.${class}...
cd ${BASE_DIR}/${BUILD_DIR}
- ${JAVAH} -jni -o ${PACKAGE_DIR}/${header} ${PACKAGE}.${class}
+ ${JAVAH} -jni -I . -o ${PACKAGE_DIR}/${header} ${PACKAGE}.${class}
if [ $? -ne 0 ]; then
echo Error: unable to build all header files. Terminating.
exit 1
-[/Patch]--
signature.asc
Description: Digital signature
Bug#421047: muine fails to start
I believe the bug is causes by the lack of an audio sink. Could you test removing gstreamer0.10-plugins-good and installing one of gstreamer0.10-alsa or gstreamer0.10-esd. If that works, the solution for this bug is to add a dependency on gstreamer0.10-audiosink. signature.asc Description: Digital signature
Bug#421060: nagios-plugins - FTBFS: Build-depends against unavailable package libsnmp9-dev
It appears libsnmp9-dev was uninstalable at the time of the build due to mirrors being unsynced or something like it. The problem is fixed now, and as the autobuild has succeded, I'd recommend to close this bug. signature.asc Description: Digital signature
Bug#422047: #422047 caused by changes in libgnome2.0-cil packaging
Bug #422047 is caused by changes in the packaging of cil bindings to the gnome libraries. The following patch fixes the build dependencies. Unfortunately, that only allows the compile to proceed forward to a new error which I cannot help with, as my knowdledge of C# is close to 0. New Error --- make[3]: Entering directory `/tmp/buildd/blam-1.8.3/src' sed -e s|[EMAIL PROTECTED]@|1.8.3| \ -e s|[EMAIL PROTECTED]@|/usr/share| \ Defines.cs.in Defines.cs /usr/bin/mcs -debug -lib:../lib -resource:blam.glade,blam.glade -resource:../icons/blam-add-news.png,blam-add-news.png -resource:../icons/blam-edit-news.png,blam-edit-news.png -resource:../icons/blam-about.png,blam-about.png -resource:../icons/blam.png,blam.png -resource:../icons/blam-tray-icon.png,blam-tray-icon.png -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/pango-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/atk-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gdk-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gtk-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/glib-sharp.dll -r:/usr/lib/mono/gecko-sharp-2.0/gecko-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gconf-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gconf-sharp-peditors.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gnome-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/art-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gnome-vfs-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/glade-sharp.dll -r:System.Web -r:RSS.NET -r:Mono.Posix -r:Atom.NET.dll Application.cs ChannelDialog.cs Channel.cs ChannelCollection.cs ChannelList.cs Conf.cs Delegates.cs Dialogs.cs FeedUpdater.cs HigUtils.cs HtmlUtils.cs Item.cs ItemList.cs ItemView.cs MainloopEmitter.cs MessageConnection.cs Opml.cs PreferencesDialog.cs Printing.cs Theme.cs ThemeManager.cs TrayIcon.cs Utils.cs Proxy.cs egg-sharp.cs Defines.cs -out:blam.exe Printing.cs(17,10): error CS0104: `PrintJob' is an ambiguous reference between `Gnome.PrintJob' and `Gtk.PrintJob' Compilation failed: 1 error(s), 0 warnings make[3]: *** [blam.exe] Error 1 -- Build-Depends patch - diff -r df8551beb682 debian/control --- a/debian/controlThu May 10 17:27:46 2007 -0500 +++ b/debian/controlThu May 10 18:23:51 2007 -0500 @@ -3,7 +3,7 @@ Priority: optional Priority: optional Maintainer: Carlos MartÃn Nieto [EMAIL PROTECTED] Uploaders: Gerardo Curiel [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.0.0), mono-mcs (= 1.1.17) | c-sharp-compiler, gtk-sharp2 (= 2.8.0), libmono-dev (= 1.1.17), cli-common-dev (= 0.4.0), libgecko2.0-cil (= 0.11), libgtk2.0-dev (= 2.2.0), libgconf2-dev (= 2.4), libgnomeui-dev (= 2.2), libxul-dev (= 1.8), cdbs, libxml-parser-perl +Build-Depends: debhelper (= 4.0.0), mono-mcs (= 1.1.17) | c-sharp-compiler, gtk-sharp2 (= 2.8.0), libmono-dev (= 1.1.17), cli-common-dev (= 0.4.0), libgecko2.0-cil (= 0.11), libgnome2.0-cil, libgconf2.0-cil, libgnomeui-dev (= 2.2), libxul-dev (= 1.8), cdbs, libxml-parser-perl Standards-Version: 3.7.2 Package: blam -- signature.asc Description: Digital signature
Bug#421139: Proposed patch for Bug#421139
tag 421139 patch thanks For some reason, including libgnome/libgnome.h *before* gm-support.h undefines the gettext alias _ (or keeps it from being defined at all, I don't know). Changing the order of the includes allows the package to build. I have done no further testing of the resulting package. diff -r 4adf809f4cad debian/changelog --- a/debian/changelog Sat May 05 14:01:40 2007 -0500 +++ b/debian/changelog Sat May 05 23:39:53 2007 -0500 @@ -1,3 +1,15 @@ gnoemoe (2.2.0+dfsg-1) unstable; urgency +gnoemoe (2.2.0+dfsg-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Move #include libgnome/libgnome.h after + #include gm-support.h in + gnoemoe/dialogs/gm-world-info-dialog.c + gnoemoe/gm-app.c +Otherwise, the gettext _ function gets undefined +(Closes: #421139). + + -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Sat, 5 May 2007 23:39:44 -0500 + gnoemoe (2.2.0+dfsg-1) unstable; urgency=low [ Jesse van den Kieboom ] diff -r 4adf809f4cad gnoemoe/dialogs/gm-world-info-dialog.c --- a/gnoemoe/dialogs/gm-world-info-dialog.cSat May 05 14:01:40 2007 -0500 +++ b/gnoemoe/dialogs/gm-world-info-dialog.cSat May 05 23:18:45 2007 -0500 @@ -4,13 +4,13 @@ #include gtk/gtk.h #include glade/glade.h -#include libgnome/libgnome.h #include gm-world-info-dialog.h #include gm-world.h #include gm-support.h #include gm-pixbuf.h #include gm-debug.h +#include libgnome/libgnome.h #define GM_WORLD_INFO_DIALOG_XML PACKAGE_DATA_DIR / PACKAGE /ui/gm-world-info.glade diff -r 4adf809f4cad gnoemoe/gm-app.c --- a/gnoemoe/gm-app.c Sat May 05 14:01:40 2007 -0500 +++ b/gnoemoe/gm-app.c Sat May 05 23:21:05 2007 -0500 @@ -3,7 +3,7 @@ #endif #include gtk/gtk.h -#include libgnome/libgnome.h + #include libgnomevfs/gnome-vfs.h #include libgnomeui/libgnomeui.h #include strings.h @@ -19,7 +19,7 @@ #include gm-pixbuf.h #include gm-support.h #include gm-scripts.h - +#include libgnome/libgnome.h static gchar *debug_level = NULL; static gboolean show_version = FALSE; static gboolean recover = FALSE; signature.asc Description: Digital signature
Bug#420041: edict_doc was removed from edict package in version 2007.02.09-1
edict_doc was removed from edict package in version 2007.02.09-1. Thus, in order to build, this package will have to either supply it itself or do without. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#419455: Patch for #419455
tag 419455 patch
thanks
The bug was caused because zaptel-source installs zaptel.h in
/usr/include/zaptel, but the configure script expects it in
/usr/include/linux. This disabled the building of modules/zapchan.yate
The following patch fixes this:
-
diff -r eb1ba09dbd92 debian/changelog
--- a/debian/changelog Sat Apr 21 22:45:47 2007 -0500
+++ b/debian/changelog Sun Apr 22 01:41:33 2007 -0500
@@ -1,3 +1,11 @@ yate (1.1.0-1.dfsg-1) unstable; urgency=
+yate (1.1.0-1.dfsg-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add debian/patches/zaptel-header.dpatch to look for zaptel.h in
+the right place (Closes: #419455).
+
+ -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Sun, 22 Apr 2007 01:40:28
-0500
+
yate (1.1.0-1.dfsg-1) unstable; urgency=low
[ Mikael Magnusson ]
diff -r eb1ba09dbd92 debian/patches/00list
--- a/debian/patches/00list Sat Apr 21 22:45:47 2007 -0500
+++ b/debian/patches/00list Sun Apr 22 01:39:50 2007 -0500
@@ -5,3 +5,4 @@ configure_ilbc
configure_ilbc
ymd5_endian
osschan
+zaptel-header
diff -r eb1ba09dbd92 debian/patches/zaptel-header.dpatch
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/debian/patches/zaptel-header.dpatch Sun Apr 22 01:39:16 2007 -0500
@@ -0,0 +1,44 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## zaptel-header.dpatch by [EMAIL PROTECTED]
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Debian's zaptel-source package places zaptel.h in
+## DP: /usr/include/zaptel, instead of /usr/include/linux
+
[EMAIL PROTECTED]@
+diff -urNad yate-1.1.0-1.dfsg~/configure yate-1.1.0-1.dfsg/configure
+--- yate-1.1.0-1.dfsg~/configure 2007-04-22 01:34:11.0 -0500
yate-1.1.0-1.dfsg/configure2007-04-22 01:38:01.669933500 -0500
+@@ -5544,7 +5544,7 @@
+ cat conftest.$ac_ext _ACEOF
+ /* end confdefs.h. */
+
+-#include linux/zaptel.h
++#include zaptel/zaptel.h
+
+ int
+ main ()
+diff -urNad yate-1.1.0-1.dfsg~/configure.in yate-1.1.0-1.dfsg/configure.in
+--- yate-1.1.0-1.dfsg~/configure.in2007-04-22 01:34:11.0 -0500
yate-1.1.0-1.dfsg/configure.in 2007-04-22 01:38:01.669933500 -0500
+@@ -294,7 +294,7 @@
+ HAVE_ZAP=no
+ AC_MSG_CHECKING([for Zaptel linux headers])
+ AC_TRY_COMPILE([
+-#include linux/zaptel.h
++#include zaptel/zaptel.h
+ ],[],
+ HAVE_ZAP=yes
+ )
+diff -urNad yate-1.1.0-1.dfsg~/modules/zapchan.cpp
yate-1.1.0-1.dfsg/modules/zapchan.cpp
+--- yate-1.1.0-1.dfsg~/modules/zapchan.cpp 2007-04-22 01:34:11.0
-0500
yate-1.1.0-1.dfsg/modules/zapchan.cpp 2007-04-22 01:38:01.669933500
-0500
+@@ -29,7 +29,7 @@
+ #else
+
+ extern C {
+-#include linux/zaptel.h
++#include zaptel/zaptel.h
+ };
+
+ #include stdio.h
-
signature.asc
Description: Digital signature
Bug#419455: Patch for #419455
On Sun, Apr 22, 2007 at 11:42:37AM +0300, Tzafrir Cohen wrote: On Sun, Apr 22, 2007 at 01:48:40AM -0500, Luis Rodrigo Gallardo Cruz wrote: Does this mean that yate will build-depend on zaptel = 1.4.0 ? I assume you mean zaptel-source = 1.4.0 Yes, I believe so. Sorry for not having put that in the patch. signature.asc Description: Digital signature
Bug#419270: 419270 happens with sid's libc6 but not with testing's
On a testing system with libc6 2.3.6.ds1-13 zsnes starts properly. On sid, with 2.5-2, it dies as reported. Installing/removing libc6-i686 makes no difference. signature.asc Description: Digital signature
Bug#419072: 419072 appears to be caused by missing build-depends on libtool (but there's more errors lurking)
On Thu, Apr 19, 2007 at 04:43:13PM +0200, Mirco Bauer wrote: On Wed, 2007-04-18 at 19:59 -0500, Luis Rodrigo Gallardo Cruz wrote: On Wed, Apr 18, 2007 at 07:15:30PM -0500, wrote: I'm currently testing a build with such build dependency added, I'll post the (rather minimal) patch if it works. Well. If fixes the posted error, and allows the build to continue to another error. I know absolutely nothing about mono, so I can't be of any further help here. how could you solve the first issue? I built this package last week or so and it was fine, using autoconf 2.5 (or so), is that a new restriction in autoconf 2.61 or do I need something else as build-dep? Oh, sorry. I said in the the Subject: instead of in the message itself. libtool is needed as build-dependency. I don't know what introduced the need. this one is easy, libmono-system-runtime2.0-cil is missing as build-depedency. Cool! Then this bug can be solved, I guess. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#419072: 419072 appears to be caused by missing build-depends on libtool
I'm currently testing a build with such build dependency added, I'll post the (rather minimal) patch if it works. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332602: Patch for #332602
tag 332602 patch tag 416609 patch thanks Both bugs are in fact the same. --- diff -r a80dd48e23c3 debian/changelog --- a/debian/changelog Wed Apr 18 19:18:42 2007 -0500 +++ b/debian/changelog Wed Apr 18 19:29:27 2007 -0500 @@ -1,3 +1,11 @@ socks4-server (4.3.beta2-14) unstable; u +socks4-server (4.3.beta2-14.1) unstable; urgency=low + + * NMU + * Add call to dh_makeshlibs and fix call to dh_shlibdeps in +debian/rules (Closes: #332602, #416609). + + -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Wed, 18 Apr 2007 19:29:27 -0500 + socks4-server (4.3.beta2-14) unstable; urgency=low * make code compatible with gcc-4.0 (closes: #294371) diff -r a80dd48e23c3 debian/rules --- a/debian/rules Wed Apr 18 19:18:42 2007 -0500 +++ b/debian/rules Wed Apr 18 19:45:09 2007 -0500 @@ -76,7 +76,8 @@ binary-arch: build install dh_fixperms # dh_suidregister dh_installdeb - dh_shlibdeps + dh_makeshlibs + dh_shlibdeps -L libsocks4 -l debian/libsocks4/usr/lib dh_gencontrol dh_makeshlibs dh_md5sums --- -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#419072: 419072 appears to be caused by missing build-depends on libtool (but there's more errors lurking)
On Wed, Apr 18, 2007 at 07:15:30PM -0500, wrote: I'm currently testing a build with such build dependency added, I'll post the (rather minimal) patch if it works. Well. If fixes the posted error, and allows the build to continue to another error. I know absolutely nothing about mono, so I can't be of any further help here. - dh_testdir /usr/bin/make make[1]: Entering directory `/tmp/buildd/stetic-0.1.0~svn.74962+dfsg' Making all in libstetic make[2]: Entering directory `/tmp/buildd/stetic-0.1.0~svn.74962+dfsg/libstetic' mkdir -p ../bin cp ./libstetic.dll.config ../bin/. mkdir -p ../bin /usr/bin/mcs -debug -pkg:glade-sharp-2.0 -pkg:gnome-sharp-2.0 -pkg:gtk-sharp-2.0 -r:Mono.Posix -r:System -target:library -out:../bin/libstetic.dll @sources.rsp ./editor/ActionToolItem.cs(170,37): warning CS0612: `Gtk.Toolbar.IconSize' is obsolete ./editor/ActionToolItem.cs(249,25): warning CS0612: `Gtk.Toolbar.IconSize' is obsolete ./wrapper/ActionToolbarWrapper.cs(80,17): warning CS0612: `Gtk.Toolbar.IconSize' is obsolete ./wrapper/ActionToolbarWrapper.cs(81,10): warning CS0612: `Gtk.Toolbar.IconSize' is obsolete ./GladeUtils.cs(290,21): warning CS0169: The private method `Stetic.GladeUtils.ParseUnichar(string)' is never used Compilation succeeded - 5 warning(s) make[2]: Leaving directory `/tmp/buildd/stetic-0.1.0~svn.74962+dfsg/libstetic' Making all in libsteticui make[2]: Entering directory `/tmp/buildd/stetic-0.1.0~svn.74962+dfsg/libsteticui' /usr/bin/gmcs -debug -unsafe -main:Stetic.ApplicationBackend -pkg:gconf-sharp-2.0 -pkg:gnome-sharp-2.0 -pkg:gtk-sharp-2.0 -r:../bin/libstetic.dll `pkg-config --libs mono-cecil` -r:Mono.Posix -r:System.Runtime.Remoting -out:../bin/libsteticui.dll @sources.rsp error CS0006: cannot find metadata file `System.Runtime.Remoting' Compilation failed: 1 error(s), 0 warnings make[2]: *** [../bin/libsteticui.dll] Error 1 make[2]: Leaving directory `/tmp/buildd/stetic-0.1.0~svn.74962+dfsg/libsteticui' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/buildd/stetic-0.1.0~svn.74962+dfsg' make: *** [build-stamp] Error 2 pbuilder: Failed autobuilding of package - -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#415667: ksudoku FTBFS also in powerpc and sparc autobuilders
It would appear that the FTBFS is triggered by some difference in the s390, powerpc and sparc autobuilders, respect to the rest. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#410731: python-twisted-runner should not provide modules for 2.3
tag 410731 patch thanks Given that python-twisted-runner depends: python-twisted-core (= 2.4) python twisted-core depends: python-twisted-bin (= 2.4.0-3) python-twisted-bin depends: python (= 2.4) It appears that python-twisted-runner won't actually work on python 2.3. Thus, providing modules for 2.3 is pointless. Setting Python-Version: 2.4 instead of Python-Version: 2.4, 2.3 should be enough to solve this bug, without the extra cruft that adding a Replaces: python2.3-twisted-bin would be. The included patch does that. I have tested it by installing python-twisted in a sarge chroot then upgrading the chroot to current etch. --- diff -u twisted-runner-0.2.0/debian/changelog twisted-runner-0.2.0/debian/changelog --- twisted-runner-0.2.0/debian/changelog +++ twisted-runner-0.2.0/debian/changelog @@ -1,3 +1,9 @@ +twisted-runner (0.2.0-1.1) unstable; urgency=low + + * NMU. Set XS-Python-Version to (= 2.4) (closes #410731). + + -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Fri, 16 Feb 2007 19:32:39 -0600 + twisted-runner (0.2.0-1) unstable; urgency=low * New upstream version. diff -u twisted-runner-0.2.0/debian/control twisted-runner-0.2.0/debian/control --- twisted-runner-0.2.0/debian/control +++ twisted-runner-0.2.0/debian/control @@ -3,7 +3,7 @@ Priority: optional Maintainer: Matthias Klose [EMAIL PROTECTED] Build-Depends: debhelper (= 5.0.37.1), python-central (= 0.4.17), python-all-dev, python-twisted-core (= 2.4), patch -XS-Python-Version: all +XS-Python-Version: (= 2.4) Standards-Version: 3.7.2 Package: python-twisted-runner --- -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Bug#391937: An upload of gnue-common would fix these bugs
tag 391937 patch tag 391941 patch tag 391942 patch tag 391947 patch tag 391950 patch thanks I've manually tested building these packages after installing in a chroot the proposed NMU by Adam Cécile available in #380825 with excelent results. Thus, making that upload would also take care of these bugs. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Bug#361376: liferea-gtkhtml will be removed from etch
tag 379900 pending tag 407152 pending tag 361376 pending thanks Due to the numerous reports that liferea-gtkhtml is unstable and basically unusable on 64bit platforms I have decided to remove this rendering plugin from liferea. As of the next upload the only supported rendering engine for liferea in Debian will be xulrunner. Anyone really wishing to keep this rendering engine better be ready to take on upstream maintenance for it, at least as regards its working on 64bit platforms. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Bug#361376: Can liferea-gtkhtml be removed from etch?
[Summary for -release: Is removing liferea-gtkhtml too disruptive for etch?] On Tue, Jan 23, 2007 at 03:04:29PM -0800, Steve Langasek wrote: On Tue, Jan 23, 2007 at 04:36:20PM -0600, Luis Rodrigo Gallardo Cruz wrote: Upstream's response to #361376 is to recommend the dropping of liferea-gtkhtml from 64bit arches. How does one go about that? Change the Architecture: field for liferea-gtkhtml in debian/control to list the 32-bit archs, instead of any. But wouldn't it be fine to just drop this binary package on all archs? I seem to remember that liferea-gtkhtml has had other problems on all archs in the past, and that the -xulrunner variant was recommended? Yes, Lars has stated his intention to completely remove this rendering engine. To do so, I'd assume the right way to go would be to turn -gtkhtml into a dummy package that pulls -xulrunner in. In that case, the separate liferea-xulrunner package would be rather pointless, as liferea would just pull it inconditionally. Should both packages be just merged into one? Would *that* be too much of a change to get into etch? -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Bug#403930: #403930 is not in smptmail.el but in sendmail.el
smptmail.el sends mail using SMTP *instead* of sendmail. The workaround described by the poster 'fixes' the problem by disabling the use of sendmail.el. Thus, the bug is almost surely contained in sendmail.el. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Bug#403930: #403930: Could you run a few more tests?
tag 403930 moreinfo thanks Hi. I'm taking a look at xemacs bug #403930, but I don't have a postfix to run some tests with. Could you retry the mail sending from the command line using the options: /usr/sbin/sendmail -oem -odb other options and check the error status returned. Also, please check whether the error message (if any) is printed on stderr or stdout. With those options, sendmail is supposed to return immediately after receiving the message and report any error via mail to the user. Is this not happening? And, finally, xemacs is using this options to talk with sendmail if mail-interactive is set to nil. This is the default option, but please check that it is still true. And, you might also want to check if setting it to 't is usefull as a workaround. Thanks. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Bug#403953: #403953: Appears to be a postfix problem
I believe this is more a bug either in postfix or in the submitter's postfix configuration. See #403930 Pending confirmation from the submitter I will merge these two bugs and either reassign them to postfix or outright close them. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Bug#404875: toolbar-fancy: Appears to do nothing
Package: toolbar-fancy Version: 0.07-7.1 Severity: grave Justification: renders package unusable This package appears to have no effect on anything when installed. Given the long time it has been efectively unmaintained and the fact that upstream's page no longer exists, I assume it was meant for some earlier xemacs version. This might make the package a candidate for removal. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Bug#403978: Does playground-plugin-xmms work with xmms in testing?
I see you're using the unstable version of xmms. Could you test with the testing version? Thanks. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Bug#403935: Patch is slightly wrong
Gunnar seems to have been a little sleepy yesterday. For his patch to work you also need to manually create debian/compat with the single line: --snip-- 4 --snap-- -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#403935: Patch is slightly wrong
On Thu, Dec 21, 2006 at 05:24:34PM -0600, Gunnar Wolf wrote: Luis Rodrigo Gallardo Cruz dijo [Thu, Dec 21, 2006 at 11:55:38AM -0600]: Gunnar seems to have been a little sleepy yesterday. For his patch to work you also need to manually create debian/compat with the single line: 4 Umgh... It is included in the pending NMU, blame it on diff - Look at line 27: Only in toolbar-fancy-0.07/debian: compat That's what diff -N is for :-) Anyway, I set it to 5, as in debian/control it now depends on debhelper = 5.0 - Any reason to leave it on 4? My stupidly not looking at your build-depends. Meaning: You're right, it ought to be 5. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Bug#401515: Patch for #401515
tag 401515 patch thanks --- diff -u dict-bouvier-6.revised/debian/control dict-bouvier-6.revised/debian/control --- dict-bouvier-6.revised/debian/control +++ dict-bouvier-6.revised/debian/control @@ -2,7 +2,7 @@ Section: text Priority: optional Maintainer: John Goerzen [EMAIL PROTECTED] -Build-Depends-Indep: debhelper ( 3.0.0), python2.3, python2.3-dictdlib (= 1.0.3), dictzip +Build-Depends-Indep: debhelper ( 3.0.0), python (= 2.4.3), python-dictdlib (= 2.0.4), dictzip Standards-Version: 3.5.2 Package: dict-bouvier diff -u dict-bouvier-6.revised/debian/rules dict-bouvier-6.revised/debian/rules --- dict-bouvier-6.revised/debian/rules +++ dict-bouvier-6.revised/debian/rules @@ -8,7 +8,7 @@ # This is the debhelper compatibility version to use. export DH_COMPAT=3 -PYTHON=python2.3 +PYTHON=$(shell pyversions -d) ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g --- -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Billboard billboard burning bright / in my windshield every night. Lead me to a decent joint / where I can stop and get a bite. signature.asc Description: Digital signature
Bug#401516: Patch for #401516
tag 401516 patch thanks -- diff -u dict-moby-thesaurus-1.0/debian/rules dict-moby-thesaurus-1.0/debian/rules --- dict-moby-thesaurus-1.0/debian/rules +++ dict-moby-thesaurus-1.0/debian/rules @@ -8,7 +8,7 @@ # This is the debhelper compatibility version to use. export DH_COMPAT=3 - +PYTHON=$(shell pyversions -d) ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g @@ -31,7 +31,7 @@ dh_testdir # Add here commands to compile the package. - python2.3 conv.py mthesaur.txt + $(PYTHON) conv.py mthesaur.txt dictzip moby-thesaurus.dict touch build-stamp diff -u dict-moby-thesaurus-1.0/debian/control dict-moby-thesaurus-1.0/debian/control --- dict-moby-thesaurus-1.0/debian/control +++ dict-moby-thesaurus-1.0/debian/control @@ -2,7 +2,7 @@ Section: text Priority: optional Maintainer: John Goerzen [EMAIL PROTECTED] -Build-Depends-Indep: debhelper ( 3.0.0), python2.3, python2.3-dictdlib (= 1.0.3), dictzip +Build-Depends-Indep: debhelper ( 3.0.0), python (= 2.4.3), python-dictdlib (= 2.0.4), dictzip Standards-Version: 3.5.2 Package: dict-moby-thesaurus -- -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Billboard billboard burning bright / in my windshield every night. Lead me to a decent joint / where I can stop and get a bite. signature.asc Description: Digital signature
Bug#398107: #398107 seems to be caused by some change to the build tools
Looking at the package's file lists in packages.debian.org/yasr the bug is only present in amd64. The only difference between it and te rest of the archs is build date, all others are from march 2004, amd64 is from march 2006. A current rebuild in i386 does trigger the bug. signature.asc Description: Digital signature
Bug#398107: patch for #398107
package yasr tag 398107 patch thanks The following patch works, by avoiding running make inside the m4 subdir. - --- yasr-0.6.5.orig/Makefile.am +++ yasr-0.6.5/Makefile.am @@ -7,7 +7,6 @@ SUBDIRS = \ $(yasr_DDIRS) \ -m4 \ po pkgdata_DATA = \ only in patch2: unchanged: --- yasr-0.6.5.orig/Makefile.in +++ yasr-0.6.5/Makefile.in @@ -132,7 +132,6 @@ SUBDIRS = \ $(yasr_DDIRS) \ -m4 \ po - signature.asc Description: Digital signature
Bug#394178: Patch for #394178
package deskbar-applet
tag 394178 patch
thanks
Attached is a patch for this bug. It also closes #380771.
diff -u deskbar-applet-2.14.2/debian/changelog
deskbar-applet-2.14.2/debian/changelog
--- deskbar-applet-2.14.2/debian/changelog
+++ deskbar-applet-2.14.2/debian/changelog
@@ -1,3 +1,10 @@
+deskbar-applet (2.14.2-4.1) unstable; urgency=low
+
+ * NMU.
+ * New python policy transition, using python-support. (Closes: #394178,
#380771).
+
+ -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Sun, 5 Nov 2006 00:42:26
-0600
+
deskbar-applet (2.14.2-4) unstable; urgency=low
* debian/control: Restored build dependencies.
diff -u deskbar-applet-2.14.2/debian/rules deskbar-applet-2.14.2/debian/rules
--- deskbar-applet-2.14.2/debian/rules
+++ deskbar-applet-2.14.2/debian/rules
@@ -12,0 +13,4 @@
+
+# New python policy
+binary-install/deskbar-applet::
+ dh_pysupport -pdeskbar-applet handlers /usr/lib/deskbar-applet/handlers
\ No hay ningún carácter de nueva línea al final del fichero
diff -u deskbar-applet-2.14.2/debian/control
deskbar-applet-2.14.2/debian/control
--- deskbar-applet-2.14.2/debian/control
+++ deskbar-applet-2.14.2/debian/control
@@ -2,13 +2,15 @@
Section: gnome
Priority: optional
Maintainer: Sebastian Rittau [EMAIL PROTECTED]
-Build-Depends: cdbs, debhelper (= 5.0.0), autotools-dev, pkg-config (=
0.9.0), python-gtk2-dev (= 2.8.6-1), python-glade2 (= 2.8.6-1),
python-gnome2-dev (= 2.12.4-1), python-gnome2-desktop-dev, intltool (= 0.33),
python2.4-dev (= 2.4), libgtk2.0-dev (= 2.6), libebook1.2-dev,
libcamel1.2-dev, libgnome-desktop-dev
+Build-Depends: cdbs (= 0.4.43), debhelper (= 5.0.38), autotools-dev,
pkg-config (= 0.9.0), python-gtk2-dev (= 2.8.6-1), python-glade2 (=
2.8.6-1), python-gnome2-dev (= 2.12.4-1), python-gnome2-desktop-dev, intltool
(= 0.33), python-dev (= 2.4), libgtk2.0-dev (= 2.6), libebook1.2-dev,
libcamel1.2-dev, libgnome-desktop-dev, python-support (= 0.5.3)
Standards-Version: 3.7.2
+XS-Python-Version: current, = 2.4
Package: deskbar-applet
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, python-gtk2
(= 2.8.6-1), python-glade2 (= 2.8.6-1), python-gnome2 (= 2.12.4-1),
python-gnome2-desktop, python2.4
-Recommends: python2.4-beagle, python-soappy (= 0.11.3-1.6), gnome-utils (=
2.14.0)
+XB-Python-Version: ${python:Versions}
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, python-gtk2
(= 2.8.6-1), python-glade2 (= 2.8.6-1), python-gnome2 (= 2.12.4-1),
python-gnome2-desktop
+Recommends: python-beagle (= 0.2.8), python-soappy (= 0.11.3-1.6),
gnome-utils (= 2.14.0)
Description: universal search and navigation bar for GNOME
Deskbar-applet is intended as a browser-like keyword-driven url bar.
You type a web address, or an email address, or a file name, or some
Bug#393049: Patch for #393049
package unsermake tag 393049 patch thanks Replace debian/patches/unsermake.diff by the attached patch, which works by pointing the executable wrapper to the proper directory. This patch also makes the package work even if default python version changes and eliminates the useless setting of PYTHONPATH. --- unsermake.orig 2006-11-04 15:56:25.0 -0600 +++ unsermake 2006-11-04 15:59:36.0 -0600 @@ -1,16 +1,9 @@ -#! /bin/sh +#! /bin/bash -self=$0 -if test -L $self; then -try=`readlink $self 2/dev/null` self=$try -fi -mods=`dirname $self` -directory=`dirname $mods` -mod=`basename $mods` -if test -n $PYTHONPATH; then - export PYTHONPATH=$directory:$PYTHONPATH -else - export PYTHONPATH=$directory -fi -exec python -c import $mod; $mod.main() --modules $mods $@ +PYTHON=$(pyversions -d) + +mods=/var/lib/python-support/$PYTHON/unsermake +mod=unsermake + +exec $PYTHON -c import $mod; $mod.main() --modules $mods $@
Bug#390573: adonthell-data: Partial patch
Package: adonthell-data
Version: 0.3.4.cvs.20050903-2.1
Followup-For: Bug #390573
The attached patch is a first approximation. As it is, it causes a
failure on postinst, when it tries to byte compile
/usr/share/games/adonthell/games/wastesedge/scripts/modules/player_text.py
In order to finish the patch, some way of avoiding byte compilation
for that specific file needs to be found.
Otherwise, the patch seems to work fine.
diff -u adonthell-data-0.3.4.cvs.20050903/debian/changelog
adonthell-data-0.3.4.cvs.20050903/debian/changelog
--- adonthell-data-0.3.4.cvs.20050903/debian/changelog
+++ adonthell-data-0.3.4.cvs.20050903/debian/changelog
@@ -1,3 +1,9 @@
+adonthell-data (0.3.4.cvs.20050903-2.2) unstable; urgency=low
+
+ * NMU. Stop shipping *.pyc files (Closes: #390573).
+
+ -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Fri, 20 Oct 2006 00:27:44
-0500
+
adonthell-data (0.3.4.cvs.20050903-2.1) unstable; urgency=low
* Non-maintainer upload. (Closes: #390573)
diff -u adonthell-data-0.3.4.cvs.20050903/debian/control
adonthell-data-0.3.4.cvs.20050903/debian/control
--- adonthell-data-0.3.4.cvs.20050903/debian/control
+++ adonthell-data-0.3.4.cvs.20050903/debian/control
@@ -2,12 +2,12 @@
Section: games
Priority: optional
Maintainer: Gordon Fraser [EMAIL PROTECTED]
-Build-Depends-Indep: debhelper (= 4), python-dev (= 2.3), adonthell (=
0.3), adonthell ( 0.4), python-support
+Build-Depends-Indep: debhelper (= 4), python-dev (= 2.3), adonthell (=
0.3), adonthell ( 0.4), python-support (= 0.4.0), quilt
Standards-Version: 3.6.1
Package: adonthell-data
Architecture: all
-Depends: adonthell (= 0.3.3.cvs.20031022), adonthell ( 0.4)
+Depends: ${python:Depends}, adonthell (= 0.3.3.cvs.20031022), adonthell (
0.4)
Description: Data files needed by Adonthell
This is the official game for Adonthell 0.3
.
diff -u adonthell-data-0.3.4.cvs.20050903/debian/rules
adonthell-data-0.3.4.cvs.20050903/debian/rules
--- adonthell-data-0.3.4.cvs.20050903/debian/rules
+++ adonthell-data-0.3.4.cvs.20050903/debian/rules
@@ -6,6 +6,7 @@
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL} -p -o root -g root -m 755
+PYVERSION=$(shell pyversions -d -v)
#ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
# CFLAGS += -g
@@ -16,6 +17,7 @@
config.status: configure
dh_testdir
+ QUILT_PATCHES=debian/patches quilt push -a || test $$? = 2
./configure --host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) \
--prefix=/usr \
@@ -45,6 +47,7 @@
-rm -f config.status
-rm -f `find . -name *~`
-rm -f `find . -name *.pyc`
+ QUILT_PATCHES=debian/patches quilt pop -a -R || test $$? = 2
dh_clean
@@ -71,7 +74,12 @@
dh_installmenu
dh_installman debian/adonthell-wastesedge.6
dh_installchangelogs ChangeLog
- dh_pysupport
+ dh_pysupport -V $(PYVERSION) adonthell-wastesedge \
+ /usr/share/games/adonthell/games/wastesedge/scripts/init.py \
+ /usr/share/games/adonthell/games/wastesedge/scripts/actions \
+ /usr/share/games/adonthell/games/wastesedge/scripts/dialogues \
+ /usr/share/games/adonthell/games/wastesedge/scripts/game_events \
+ /usr/share/games/adonthell/games/wastesedge/scripts/schedules
dh_link
dh_strip
dh_compress
only in patch2:
unchanged:
--- adonthell-data-0.3.4.cvs.20050903.orig/debian/patches/series
+++ adonthell-data-0.3.4.cvs.20050903/debian/patches/series
@@ -0,0 +1 @@
+01_do_not_ship_pyc_files
only in patch2:
unchanged:
---
adonthell-data-0.3.4.cvs.20050903.orig/debian/patches/01_do_not_ship_pyc_files
+++ adonthell-data-0.3.4.cvs.20050903/debian/patches/01_do_not_ship_pyc_files
@@ -0,0 +1,371 @@
+Index: adonthell-data-0.3.4.cvs.20050903/scripts/Makefile.am
+===
+--- adonthell-data-0.3.4.cvs.20050903.orig/scripts/Makefile.am 2006-10-22
18:27:48.0 -0500
adonthell-data-0.3.4.cvs.20050903/scripts/Makefile.am 2006-10-22
18:28:49.0 -0500
+@@ -2,12 +2,12 @@
+
+ pkgdatadir = $(gamedatadir)/scripts
+
+-pkgdata_DATA = *.pyc
++pkgdata_DATA = *.py
+
+ EXTRA_DIST = init.py
+
+ all:
+- $(adonthell_binary) -c
++ #$(adonthell_binary) -c
+
+ *.pyc: *.py
+
+Index: adonthell-data-0.3.4.cvs.20050903/scripts/Makefile.in
+===
+--- adonthell-data-0.3.4.cvs.20050903.orig/scripts/Makefile.in 2006-10-22
18:27:48.0 -0500
adonthell-data-0.3.4.cvs.20050903/scripts/Makefile.in 2006-10-22
18:28:49.0 -0500
+@@ -127,7 +127,7 @@
+ target_alias = @target_alias@
+ SUBDIRS = dialogues game_events modules schedules actions
+
+-pkgdata_DATA = *.pyc
++pkgdata_DATA = *.py
+
+ EXTRA_DIST = init.py
+
+@@ -439,7 +439,7 @@
+
+
+ all
Bug#394178: deskbar-applet: Package ships .pyc and .pyo files
Package: deskbar-applet Version: 2.14.2-4 Severity: serious Justification: python policy 3.1.1 This package ships .pyc and .pyo files for its python modules. This is a violation of both the new and the old python policy. This bug would be fixed by converting the package to use one of the new python policy helpers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394181: mailman: Package is shipping .pyc files
Package: mailman Version: 1:2.1.9-2 Severity: serious Justification: python policy 3.1.1 This package is shipping .pyc files for the private module in /var/lib/mailman/pythonlib/email in violation of the new python policy. The module should be installed to /usr/share/mailman After the move, adding email path to module to the dh_pysupport call should fix the problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390573: Shipping .pyc files violates python policy
# -2.1 NMU did not fix this package adonthell-data tag 390573 -fixed thanks Shipping .pyc files is a violation of python policy 2.6. This package has a rather obnoxious upstream build system, that actually ships *only* the .pyc files and not the .py ones. Thus, adding dh_pysupport did not solve the problem at all (I assume it did kill the symptoms, by virtue of rebuilding with 2.4). A fix for this problem requires patching the build system to avoid all this. Then maybe python-support will be able to do its job. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
